5行の評価を5万回実行してわかったこと

2026年6月19日 VS Code評価チーム、@code

過去6ヶ月間、私たちは同じ小さな評価を5万回以上実行してきました。VS Codeエージェントに与える指示は1つだけです。「ファイルに文字列を書き込む」。理解すべき大規模なコードベースも、デバッグすべきテストスイートも、下すべきアーキテクチャの決定もありません。これは私たちのスモークテストであり、エンドツーエンドのモデルの相互作用が正常に機能していることを素早く確認するための方法です。

これほど単純なタスクからは、システムの健全性を即座に読み取ることができます。エージェントがどれほど確実に作業を完了できるか、そして実際にどのような種類の障害が発生するかです。私たちはそれ以上のものにするつもりはありませんでした。しかし、この規模になると、モデルが最も単純なリクエストにさえどのようにアプローチするかについて、驚くほど豊富な洞察の源となりました。

前の投稿では、VS Codeにおけるエージェントの動作を測定するために使用しているオフライン評価スイート「VSC-Bench」を紹介しました。今回のブログ記事では、モデルがシンプルなタスクをどのように解決するのか、そしてそれが効率性、モデル選択、そして小さく安定した評価の価値について何を教えてくれるのかを見ていきます。

5行の評価

シンプルなタスクが価値を持つのは、まさに変数を排除できるからです。作業が明確で正解が固定されている場合、実行間で変化するものはすべて、タスク自体からではなく、モデルやその周辺のシステムから生じるものです。そのため、小さな評価は感度の高い測定器となります。複雑な問題を解釈する際のノイズなしに、ハーネスの回帰、インフラのインシデント、モデルの動作の違いに反応するのです。

この目的で使用する say_hello タスクは、そのアイデアに基づいて構築されています。すべての実行は、同じ空のワークスペースで、同じツールと固定されたプロンプトを使用し、VS Codeエージェントハーネスを使用して開始されます。このタスクはエージェントに「HELLO.txtにHELLOを追加する」よう求め、2つのアサーション（ファイルが存在すること、および期待される内容が含まれていること）を確認します。

promptSteps:
  - text: Add HELLO to HELLO.txt.
    assertions:
        - check: file_exists("HELLO.txt")
        - check: file_contains("HELLO.txt", "HELLO")

say_hello はすべてのベンチマークスイートの前にスモークテストとして実行されるため、6ヶ月間で30モデルにわたって50,974回の実行がひそかに蓄積されました。そのデータ量により、基本的な健全性チェックが、モデルがいかに異なる方法で最も単純な作業を処理するかについての有用なデータセットへと変わりました。

このタスクを行う開発者であれば、ワークスペースが空であることを認識し、HELLO.txt を作成し、要求されたコンテンツを追加するでしょう。最も直接的なVS Codeエージェントのパスでは、これは HELLO をファイルコンテンツとする単一の create_file ツールの呼び出しに変換されます。

tool : create_file
args : {
  "filePath": "/path/to/workspace/HELLO.txt",
  "content": "HELLO"
}

モデルが say_hello をどのように解決するか

予想通り、say_hello タスクは非常に簡単で、ほとんどのモデルがほとんどの場合に合格します。興味深いのは、彼らがその作業をこなせるかどうかではなく、どのようにそれをこなすかです。モデルはこれが単純な解決策しか必要としない基本的なリクエストであると認識できるでしょうか？それとも、依然として計画、探索、検索を必要とする複雑な問題のように扱うでしょうか？

ベースラインを確立するために、この1回のツール呼び出しパスを使用した合格した実行を抽出し、そのグループの中で最も低い出力トークン数を確認しました。それらの実行では、ツール呼び出しの構造を含めて平均して約50個の出力トークンが使用されていました。次に、各モデルがそのパスをどのくらいの頻度で選択したかを測定しました。

あるモデルは常に直接的なパスを選択します。より広い傾向として際立っているのは、いくつかのモデルは頻繁に直接的なパスを選択し、ほとんどのモデルは時々しか選択せず、5つのモデルは決して選択しないということです。

最上位には、Model-Aが単独で位置しています。合格した実行の100%でファイルの作成に直行し、毎回単一のツール呼び出しを使用しています。この単純なリクエストに対して、Model-Aは事前に計画や探索を行うことなく、常に直接ファイルを作成します。Model-BとModel-Cがそれぞれ73%と71%でそれに続きます。

中央の大きなクラスターであるModel-DからModel-Pまでは、19%から52%の確率で直接的なパスを選択します。これらのモデルは単純なタスクを認識できますが、一貫してではありません。多くの場合、ファイルを作成する前に、内部状態の読み取りや軽いワークスペースの探索などの小さなステップを最初に追加します。

その下のModel-QからModel-Xまでは、直接的なパスを選択することはめったになく、合格した実行の0.2%から6%にとどまり、5つのモデルは1%を下回っています。これらのモデルにとって、余分な作業がデフォルトです。同じ5文字のファイルを作成する前に、ほとんどの場合、計画、探索、または検索を行います。

最下位のModel-YからModel-ACまでの5つのモデルは、何千もの合格した実行において、一度も直接的なパスを選択しませんでした。それらは常に最初に別のことを行います：計画を立てる、簡単なファイル作成ではなくパッチツールに手を伸ばす、検索と計画を行う、あるいはファイル作成の前に長々とナレーションを入れるなどです。彼らにとっては、最も単純なリクエストであっても、複雑なリクエスト用のフル機能の仕組みがトリガーされてしまいます。

すべてのモデルが適切なコンテンツを持つファイルを作成しますが、到達するまでの作業量は大きく異なります。ほとんど曖昧さのないタスクであっても、一部のモデルは依然として計画や検索を行ったり、より複雑な編集ツールを選択したりします。それらはすべて評価に合格しますが、合格するために同じ量の労力を費しているわけではありません。

モデルがオーバーヘッドを費やす方法

当社のオフライン評価ハーネスは完全なツール呼び出しシーケンスをキャプチャするため、それらのトレースをモデルの動作パターンに変換することができます。実行全体を通して、モデルはいくつかのよく知られた方法で余分な労力を費やす傾向があります

これらは正当性の失敗ではありません。最短経路で十分なときに、それをモデルが一貫して認識できていない兆候です。より長いタスクでは、計画や探索が価値を持つこともあります。1ステップのタスクにおいては、それらは結果を改善することなく、遅延とコストを増加させるだけです。

考えすぎのコスト

なぜモデルが5文字のファイルを書くためにどれだけ余分なステップを踏むかを気にする必要があるのでしょうか？それらの余分なステップは無料ではなく、出力トークンの使用量に直接結びつき、実際のコストが発生するからです。

この単純なタスクでは、約50個の出力トークンが現実的な最小値です。次のチャートは、さまざまなモデルによって使用された出力トークンの範囲を示しています。選択されたモデルは、その最小値から、同じ5文字の結果に対して数千トークンにまで及んでいます！

このチャートは4つの明確なバンドに分かれています。極端なグループにはModel-AB、Model-M、Model-Uが含まれており、それぞれ平均3,676、2,120、1,441個の出力トークンを使用しています。これは、同じ5文字の結果に対する現実的な最小値の29〜74倍です。400〜1,000トークンの高オーバーヘッドグループには、Model-AA、Model-B、Model-N、Model-H、Model-V、Model-E、Model-S、Model-Kが含まれます。これらのモデルは数千トークンに達するわけではありませんが、それでも現実的な最小値の約8〜12倍を費やしています。

150〜400トークンの中程度グループには、Model-P、Model-D、Model-X、Model-T、Model-G、Model-Z、Model-I、Model-AC、Model-F、Model-J、Model-Qが含まれます。これらはオーバーヘッドを追加しますが、タスクの本来の規模により近くなっています。150トークン未満の効率的グループには、Model-R、Model-A、Model-Y、Model-W、Model-O、Model-C、Model-Lが含まれます。Model-Lは55トークンで私たちの現実的な最小値に最も近く、直接的なツールパスを常にたどらなくても、モデルが非常に少ない追加のナレーションでタスクを完了できることを示しています。

考えすぎないモデルを選ぶことは時間と費用の両方を節約しますが、どのモデルがタスクにとって最も効率的かを知るには、通常、独自のベンチマークを実行する必要があります。その負担を軽減するために、VS CodeとGitHub Copilotのチームは最適化とモデルルーティングへの投資を続けています。たとえば、自動モデル選択機能により、VS Codeがタスクに最適なモデルを選択してくれます。

モデルのサイズはオーバーヘッドを予測しない

私たちの最初の仮説は、大規模なモデルほど考えすぎる傾向があるというものでしたが、データはそれに反する結果を示しています

• Model-F（大型モデル）は、平均して160個の出力トークンと2.1回のツール呼び出しを使用します。そのファミリーの中で最も規律正しいモデルです。

• Model-H（同じファミリーの小型モデル）は、平均して485個の出力トークンと3.7回のツール呼び出しを使用します。大型の兄弟モデルよりも多くのオーバーヘッドがあります。

• Model-AB（「ミニ」モデル）は、平均3,676個の出力トークンで、単一の最高オーバーヘッドモデルとなっています。このサンプルの中で最も小さなモデルが、最も多くの作業を行っています。

私たちの見解では、各モデルファミリー内の新しい世代ほど、パラメータ数に関係なく、より規律正しくなる傾向があります。これはトレーニングの成熟度を示しています。つまり、モデルが目の前のタスクに合わせてどれほど適切に労力をスケーリングできるかということです。そして、そのキャリブレーションは単なる学術的な興味の対象ではなく、請求書に直接現れます。

今後の方針

私たちのチームがこれらの実行から得たいくつかの重要な洞察と、皆さんの日々のワークフローに応用できるいくつかの学びを共有したいと思います。

タスクにモデルを合わせる

従量制課金では、出力トークンは金銭と時間の両方を表します。このタスクにおける最も軽量なモデルと最も重量級のモデルの差は、同一の出力に対して約70倍です。明白な教訓は「HELLOを書くために最大のモデルを使うな」ということでしょう。しかし、その教訓はあまりにも単純であり、その理由を理解することこそが、say_hello が教えてくれた最も有用なことです。

これらの結果には重要な注意点があります。say_hello は、1つのステップと1つの正解を持つ短期的なタスクです。長期的な作業においては、計画、探索、推論が高価なミスを防ぎ、完了の確率を高めることができます。目標は計画を排除することではありません。モデルが1ステップのタスクと30ステップのタスクの違いを見分けられるかを理解することです。

これが、モデル選択が開発者の負担になるべきではない私たちが考える理由の1つです。労力の調整、トークン効率、ツールの規律といったシグナルは、開発者があらゆるトレードオフについて検討しなくても、自動モデルルーティングが目の前のタスクに適したモデルを選択するのに役立ちます。私たちはVS Codeにおける自動モデル選択への投資と研究を続けており、プロダクトが時間の経過とともにこうした選択をより多く代行できるようにしていきます。

小さく始め、しっかりと測定する

ほとんどのチームは、毎日実行できる独自のオフラインベンチマークスイートから始めるわけではありません。たとえ単純なタスクであっても、一貫して実行され、適切にログに記録されていれば、モデルやシステムの動作における有用な変化を明らかにすることができます。

曖昧さのない正解を持つ最小のタスクから始めましょう。次に、それを継続的に実行します。ナイトリー評価、モデルのオンボーディング、インフラストラクチャの変更前のプリフライトチェックとして使用します。タスクに巧妙さは必要ありません。合格率、レイテンシ、ツール使用状況、失敗モードの変化に意味が生じる程度に安定している必要があります。

重要な部分は、何が変化したかを説明するのに十分な構造をキャプチャすることです。単なるカウントではなく、ツール呼び出しのシーケンスを記録します。4回のツール呼び出しがあったことを知ることは有用ですが、不十分です。モデルが計画し、探索し、検索し、それからファイルを作成したことを知ることで、オーバーヘッドがどこから来たのか、そしてなぜその実行のコストが高くなったのかが分かります。

// What most harnesses log:
{ "tool_calls": 4, "pass": true }

// What you actually need:
{
  "tool_sequence": ["plan", "list_directory", "search_files", "create_file"],
  "output_tokens": 617,
  "pass": true
}

スモークテストからシグナルへ

say_hello の驚くべき部分は、モデルが HELLO.txt を書けたことではありませんでした。5文字の編集によって労力が可視化されたことでした。どのモデルが労力を縮小し、どのモデルが計画や検索を続け、どのシステム障害が何千回もの実行後にのみ現れたのかが明らかになったのです。

VS Codeでお好みのモデルを使用して同じリクエストを試し、チャットデバッグビューでそのツール呼び出しを検査し、あなた自身の最も小さくて有用なタスクが何であるかを考えてみてください。VS Codeリポジトリで見つけたことを共有してください。

ハッピーコーディング！💙