5万回の評価で判明 VS Code開発チームが明かす「小型AI」の罠：30種類のモデルを検証 理論値の「約74倍」トークンを浪費したモデルも

コーディングエージェントの導入が進む中、「トークン浪費」が課題となっている。MicrosoftのVS Code Eval Teamは、30種類のモデルを対象に累計5万回以上の検証を実施し、AIエージェントがタスク遂行の裏側で引き起こす「過剰思考」の実態を明らかにした。今後のエージェント運用においては「評価の自動化」も焦点となりそうだ。

[石川俊明，＠IT]

　生成AI活用がソフトウェア開発におけるスタンダードとなる一方、LLM（大規模言語モデル）を呼び出すコストが課題として顕在化している。

　OpenAIやAnthropicなどが提供する主要モデルのAPIは、その多くが従量課金制だ。そのため、ループ処理や複雑なツールの呼び出しが重なると、利用コストが一気に跳ね上がってしまう。

　モデルの利用料や利用上限は、主に入出力のトークン数によって決まる。1回で扱える情報量を示す「コンテキストウィンドウ」の制限もあるため、いかにトークン数を抑えて効率的にモデルを動かすかが、エージェント開発・運用において極めて重要とされる。

　では、AIエージェントが消費するトークン数を抑えるためにどう取り組めばよいのか。MicrosoftのVS Code Eval Teamがモデル評価の取り組みを解説するとともに、トークンコストの最適化に取り組むためのポイントを解説した。

AIエージェントの振る舞いを「極小タスク」で実験する理由

　同チームはコーディングエージェントの健全性を評価する極めて小さなテスト「say_hello」を繰り返し実行させてきたという。そのタスクとは「HELLO.txtというファイルを作成し、中に『HELLO』と書き込む」という内容だ。

　理論上の最短実行ルート（「ファイル作成ツール」の呼び出し1回、約50トークン消費）に対し、30種類のモデルで累計5万974回検証した結果、一部のモデルはタスク自体には成功しつつも、平均して3676トークン（理論値の約74倍）ものトークンを浪費している実態が明らかになった。

各モデルにおける最短実行ルートでのタスク達成率 ※検証された具体的なモデル名およびベンダー名は、特定の提供元の優劣を競うことが目的ではないとして、匿名化されている（提供：Microsoft）

　同チームによれば、トークンを浪費していたモデルは以下のような振る舞いをしていたという。

1. 空のワークスペースを「探索」し続ける

　事前にコンテキストとして「空のワークスペースである」と共有されているにもかかわらず、96％の確率でディレクトリ内を検索し始めた。何もない空の部屋に入ってきて、執拗に手掛かりを探すような無駄なAPIコールが発生していた。

2. 終わらない「思考プロセスのナレーション」

　ツールを実行してファイルを作成することを指示しているにもかかわらず、エージェント自身の思考プロセスや「なぜその作業をするのか」という解説、すなわちリーズニングのプロセスをそのまま出力していた。これが数千トークン規模の浪費に直結した。

3. タスクに対して「高級過ぎるツール」の選択

　テキストファイル作成を指示したのにもかかわらず、既存の複雑なコードを書き換えるための「差分修正ツール」を呼び出していた。紙を1枚切るために、わざわざ精密な工業用カッターを準備するような手段のミスマッチが起きていたという。

4. 1ステップの作業に「4工程の計画」を策定

　1回のアクションで終わるタスクに対し、自ら「チェックリスト」や「計画書」を作成し、ステップを細分化して実行しようとする。

　これらは実行エラーとして検出されないため、「外部からは正常に動いているように見えるが、裏で想定外のトークン課金が生じる」という最も厄介なケースと言える。

「小型モデル＝低コスト」は誤解？

　同チームは検証結果を踏まえ、この「過剰思考」による無駄なコストを抑えるために、現場のアーキテクトやITエンジニアが今すぐ取るべき具体的なアプローチを3つ提示している。

　1つ目は、タスクに合ったモデルを選択することだ。従量課金のモデルを選定する上では、「モデルのサイズ（パラメーター数）が小さいほど低コストになる」という先入観を捨てる必要があるという。

　「大規模モデルである『Model-F』が平均160トークンで規律正しくタスクを処理したのに対し、同ファミリーの小規模モデル『Model-H』は平均485トークンを消費した。さらにミニモデルと位置付けられる最小の『Model-AB』に至っては、平均3676トークンという最大の浪費を記録した。つまり、パラメーター数の少なさが必ずしもトークンの節約にはつながらない」（Microsoft）

　2つ目は、明確な正解がある最小のタスクで、継続的に測定することだ。

　最初から複雑なベンチマークを用意する必要はないという。同チームのように、曖昧さがなく結果が固定された最小のタスクを定義し、それを毎晩のテストやインフラ変更時、新しいモデルの導入前チェックとして一貫して実行する。タスクを極小かつ安定させることで、合格率やレイテンシ、トークン消費量の変化が「システムやモデルの純粋な変調」として可視化できるようになる。

　3つ目は、単なる成否や回数ではなく、ツール呼び出しのシーケンス（順序）をログに記録することだ。「エージェントの計画」「ディレクトリ一覧取得」「ファイル検索」「ファイル作成」という詳細な行動プロセスの履歴を残しておくことが重要になるという。

　「こうした記録があれば『なぜこのタスクの実行にこれほどのコストがかかったのか』というオーバーヘッドの正体を突き止めることが可能になる」（Microsoft）

　同チームは、Visual Studio Codeの「Chat Debug View」などを活用してツール呼び出しを検査し、「最小の有益なタスク」を定義してモデルの測定を始めることを推奨している。

記者の目：

　開発者がAIモデルを選定する際の論点は、ベンチマークが示す性能や、APIのトークン単価を並べた比較表だろう。数値だけを見れば、単価が圧倒的に安い小型モデル（ミニモデル）を選択することが、コスト最適化における最短ルートに見える。

　しかし、いくら1トークン当たりの単価が安くても、同チームの検証のように消費量が何倍、何十倍にも膨らんでしまえば、当初期待していたコストメリットは相殺されかねない。加えて、同チームがこれを課題として重く受け止めている理由は、AIの請求金額の問題だけにとどまらない。過剰思考がもたらす「実行速度の低下」や「処理の不確実性」といった、ユーザー体験（UX）やシステムの信頼性を揺るがすリスクにも気を配る必要があるためだ。

　2026年3月に、ツール呼び出しの「軌跡」を評価することや、設計の初期段階からその評価基盤を組み込むことの重要性を先行企業の講演内容とともに報じた（参考記事）。VS Codeのチームによる検証事例も、そのアプローチの正当性を裏付けたものと言える。

　だが、あらゆる企業がこうした評価環境の構築や運用に人的リソースを割けるわけでもないのが現実だろう。評価のための仕組み作りにもAIの力を借り、人手を介さずにチェックさせる「LLM-as-a-Judge」のようなエコシステムを自社内に構築できるかどうかも、AIを活用した開発・運用の成否を分けるポイントとなりそうだ（石川俊明）。