バイブコーディングの精度は、モデルの性質ではなく測定結果です
同じモデルを使っていても、2つのチームが得る結果は大きく異なります。実際に気にすべきレベルの精度は、生成のあとに何が起きるかで決まるからです。誰かが確認したか。何を基準に確認したか。誤った結果が修正のために戻ってくるまで、どれくらいの時間がかかったか。
そう捉え直すと、問いは「どのモデルが最も正確か」ではなく「自分たちのフィードバックループはどうなっているか」に変わります。そしてこちらは、自分たちでコントロールできるものです。
測る価値があるもの
記述した挙動が実際に起きるか
ユーザーとの接触に耐えうる、唯一の「正しさ」の定義です。
コードを読むのではなく、フローを実際に動かして測定します。
昨日動いていたものが今日も動くか
最初の1週間を過ぎれば、初回の正答率よりもリグレッション率のほうが重要になります。
機能変更のおよそ5回に1回は、それまで動いていたものを壊します。
正しい結果に到達するまでの時間
グリーンになるまでの試行回数は、初回で成功したかどうかよりも有用な指標です。
それは実際に体感しているもの、つまりループ1周にかかる時間を捉えています。
落とし穴:同じ書き手が書いたテスト
精度を測る方法としてまず思いつくのは、エージェントにテストを書かせて通るかどうかを見ることです。しかしこのやり方で得られる数値は、ほぼ常に高くなり、ほとんど意味を持ちません。実装と同じ前提から生成されたテストは、構造上その実装と一致します。両方が間違っている箇所も含めてです。
精度の測定には、独立した検証が必要です。コード自身が想定する動作ではなく、意図された挙動を基準にプロダクトを動かして確かめるものです。
測定の仕組みを用意する
次の変更に取りかかる前に、自社プロダクトにとっての「正しさ」を定めるフローを、平易な言葉で記述します。それをデプロイ済みのアプリに対して実行します。最初の実行がベースラインとなり、それ以降の実行はリグレッションのシグナルになります。
ここにターミナルは一切必要ありません。TestSprite のダッシュボードでプロジェクトを作成し、確認したい内容を平易な言葉で記述して、対象のアプリを指定するだけです。コマンドラインのほうが好みであれば、チームの開発者は同じことをそこから実行できます。それが CLI リポジトリです。
知っておく価値のあるデータ
コーディングエージェントが同じアプリケーションを構築する公開リーダーボードでは、検証ループを組み込んだ状態で、参加したなかで最も安価なモデルが最も正確なアプリを作り上げました。しかも、最も高価な参加モデルの半分のコストでです。興味深いのは順位そのものではありません。モデルよりもループのほうが効いたという事実であり、これは精度をめぐる議論の通常の流れとは正反対です。
その数値は何のためにあるのか
精度の数値は多くの場合、モデルが優れているかどうかといった、誰も尋ねていない問いに答えるために集められます。本当に有用な問いはもっと狭いものです。この変更をマージしてよいか、です。
そう捉えると、測定の意味づけが変わります。プロダクト全体のスコアは必要ありません。必要なのは、この変更がそれまで動いていたものを壊していないかを知ることです。重要なフローを押さえた少数のチェックをデプロイ済みのビルドに対して実行すれば、数分で答えが出ます。網羅的なベンチマークは、1週間かけて別の問いに答えるものです。
悪い数値の意味合いも変わります。ベンチマーク上で精度の数値が下がっているのは、興味深い事実です。一方、昨日は動いていたのに今日は動かない具体的なフローは、すぐに手を打てる情報です。ユーザーのもとに問題が届くのを食い止めるのは、後者のほうです。
測定を継続的なものにする
一度きりの測定が教えてくれるのは、その一瞬のことだけです。精度は継続するプロセスの性質なので、チェックはすべての変更に対して行うべきものです。
方法は2つあり、選択のポイントは実のところ、誰がパイプラインを所有しているかです。ダッシュボードから GitHub App を接続する方法なら、リポジトリに一切変更を加える必要はありません。ビルドがすでに出力しているデプロイに反応する仕組みだからです。一方、 GitHub Actions のステップを追加する方法では、チェックがリポジトリ内に置かれ、ビルドの他の部分と同じようにレビューの対象になります。
精度を「測れるもの」に変える
TestSprite は、この測定に必要な独立した検証を担います。コード自身が想定する動作ではなく、あなたが記述した挙動を基準に、デプロイ済みのプロダクトを実際に動かして確かめます。実装もテストも同じエージェントから生まれた場合に数値が意味を持つのは、この点があるからです。
実際の運用では、自社プロダクトにとっての「正しさ」を定めるフローを一度記述しておけば、以降はすべての変更で実行されます。最初の実行がベースラインです。それ以降の実行は、本当に知りたい問い、つまりこの変更が昨日まで動いていたものを壊していないかに答えてくれます。
これにより、追跡する価値のある2つの数値が手に入ります。変更あたりのリグレッション率と、グリーンに戻るまでに要する試行回数です。どちらもループが締まれば動き、テストを増やすだけで水増しすることはできません。
バイブコーディングで最も精度が高いモデルはどれですか?
多くのチームにとって、それは的外れな問いです。検証を行うかどうかによって生じる差のほうが、現在のフロンティアモデル間の差よりも大きいからです。
テストを書かずに精度を測れますか?
測れます。フローを平易な言葉で記述し、アプリに対して実行させるだけです。測っているのは挙動であり、挙動を観察するのにテストコードは必要ありません。
精度の数値は、どれくらいなら良いと言えますか?
プロダクトをまたいで使える有用な基準値はありません。代わりに自分たちの推移を追ってください。変更あたりのリグレッション率と、正しい結果に至るまでの試行回数です。どちらもループが締まるにつれて下がっていくはずです。
カバレッジが高ければ精度も高いのですか?
必ずしもそうとは限りません。カバレッジが数えているのは何が実行されたかであって、期待値が正しかったかどうかではありません。生成された大量のテスト群が、誤った前提のうえで高いカバレッジを示すこともあります。
どのくらいの頻度で測り直すべきですか?
変更のたびに、自動でです。スケジュールに沿って測った精度がわかるのは、そのスケジュールについてであって、何かを壊した変更についてではありません。