エージェントには「燃料計」と「ブレーキ」が必要:論文で、エージェントの「曖昧な帳簿」を暴露する

想象一下这个场景:

あなたはAIエージェントにコードのバグ修正を頼む。彼はプロジェクトを開き、20個のファイルを読み、少し修正し、テストを走らせる。結果は失敗、また修正して再実行……何度も繰り返し、十数回やっても、結局—修正できない。

あなたはパソコンを閉じて、ほっと一息つく。そしてAPIの請求書を受け取る。

上記の数字に思わず息を呑む——AIエージェントが自主的にバグを修正する際、海外の公式APIの下では、未修正のタスク一回あたり何百万ものトークンを消費し、費用は数十ドルから百ドル超に達することもある。

2026年4月、スタンフォード大学、MIT、ミシガン大学などの共同研究による論文が初めて、AIエージェントのコードタスクにおける「消費のブラックボックス」を体系的に解明した——お金は一体どこに、どれだけ使われているのか、価値はあるのか、事前に予測できるのか、その答えは衝撃的だった。

発見一:エージェントがコードを書くのにかかるコストは、普通のAI対話の1000倍

皆さんは、「AIにコードを書かせる」と「AIとコードについて話す」のにかかる費用は大差ないと思うかもしれない。

しかし、論文の比較によると:

エージェントによるコーディングタスクのトークン消費量は、普通のコード質問や推論タスクの約1000倍に達している。

これはまさに三桁の差だ。

なぜこうなるのか?論文は一つの事実を指摘している——お金は「コードを書く」ことに使われているのではなく、「コードを読む」ことに使われている。

ここでの「読む」とは、人間がコードを読むことではなく、エージェントが作業中に、プロジェクトの全体の文脈、履歴操作記録、エラーメッセージ、ファイル内容を絶えずモデルに「喂える」ことを指す。対話のたびにこの文脈は長くなり、モデルはトークン数に基づいて課金される——喂えれば喂えるほど、支払う額は増える。

例えるなら、修理工に頼むようなものだ。彼が扳手を動かす前に、あなたは建物全体の設計図を最初から最後まで読み上げる必要がある——設計図を読む費用は、ネジを締める費用よりもはるかに高い。

論文はこの現象を一言でまとめている:エージェントのコストを駆動するのは、出力トークンではなく、入力トークンの指数関数的増加だ。

発見二:同じバグを2回走らせると、費用は倍近くなる——しかも高価なバグほど不安定

さらに厄介なのは、ランダム性だ。

研究者は同じエージェントに同じタスクを4回走らせ、その結果を比較した。

結果は次の通り:

異なるタスク間では、最も高価なタスクは最も安価なタスクより約700万トークン多く消費している(図2a)

同じモデル・同じタスクの複数回実行では、最も高価な一回は最も安価な一回の約2倍(図2b)

さらに、モデル間の比較では、同じタスクでも最高消費と最低消費の差は30倍に達することもある。

最後の数字は特に注目すべきだ:これは、モデルの選択次第でコスト差が「少し高い」から「桁違い」に変わることを意味している。

より痛いのは——多く使えば良い結果が得られるわけではない。

論文は「逆U字型」の曲線を発見した:

コストと正確性の関係は、低コストでは正確性も低い(投入不足の可能性)、中程度のコストでは最も高くなる、高コストでは逆に正確性が低下し、「飽和区間」に入る。

なぜこうなるのか?論文はエージェントの具体的な操作を分析し、その答えを示している——

高コストの運用では、エージェントは「反復作業」に多くの時間を費やしている。

研究によると、高コスト運用の約50%のファイル閲覧と修正操作は重複している——つまり、エージェントは同じファイルを何度も読み、同じ行を何度も修正し、まるで部屋の中をぐるぐる回っているようだ。回るほどに酔い、酔うほどに回る。

お金は問題解決に使われず、「迷子」になっている時間に浪費されている。

発見三:モデル間の「効率比」は天と地ほど違う——GPT-5が最も省エネ、多くのモデルは150万トークン以上も消費

論文は、業界標準のSWE-bench Verified(500件の実際のGitHub Issue)で、8つの最先端大規模モデルのエージェント性能をテストした。ドルに換算すると、トークン効率の良いモデルは、1つのタスクに数十ドルの差を生む。企業レベルの運用では、1日に数百のタスクを処理することもあり、その差はまさに金貨の山だ。

さらに面白い発見は、トークン効率はモデルの「固有の性格」であり、タスクの性質によるものではない。

研究者は、すべてのモデルが成功したタスク(230個)と、すべてのモデルが失敗したタスク(100個)を比較したところ、モデルの相対的な順位はほとんど変わらないことを見出した。

これは、あるモデルは生まれつき「おしゃべり」な性格であり、タスクの難易度とは関係ないことを示している。

もう一つ深刻な発見は、モデルには「損切り意識」が欠如していることだ。

すべてのモデルが解決できない困難なタスクに直面したとき、理想的なエージェントは早めに諦めるべきだが、実際には、失敗したタスクに対してより多くのトークンを消費している——彼らは「負け」を認めず、探索や再試行、文脈の再読を続ける。まるで燃料計の警告灯のない車のように、故障まで走り続ける。

発見四:人間が難しいと感じることは、エージェントにとっては必ずしも高コストではない——難易度の感知は完全にズレている

あなたはこう思うかもしれない:「少なくとも、タスクの難易度に応じてコストを予測できるはずだ」と。

論文は、専門家に500のタスクの難易度を評価させ、その値とエージェントの実際のトークン消費と比較した。

結果は:両者の相関は弱い。

ざっくり言えば:人間が死ぬほど難しいと感じるタスクでも、エージェントはあまりお金をかけずに済むこともあれば、人間が簡単だと思うタスクに多額のコストをかけることもある。

これは、人間とAIが「見る」難しさの基準が根本的に異なるためだ。

人間が見るのは:論理の複雑さ、アルゴリズムの難しさ、業務理解のハードル

エージェントが見るのは:プロジェクトの規模、読む必要のあるファイル数、探索経路の長さ、同じファイルの繰り返し修正の有無

ある人間の専門家が「一行修正すれば良い」と思ったバグでも、エージェントはまずコード全体の構造を理解しなければその行を特定できない——「読む」だけで大量のトークンを消費する。一方、「ロジックが複雑」と感じるアルゴリズム問題でも、エージェントは標準解法を知っていればあっという間に解決できる。

こうした違いにより、開発者は直感だけでエージェントの運用コストを予測するのはほぼ不可能だ。

発見五:モデル自身さえ、自分がどれだけコストを使うか正確に予測できない

人間ですら予測できないのに、AIに自己予測させるのはどうか?

研究者は巧妙な実験を設計した。エージェントに実際にバグ修正を始める前に、「コードベースを検査」させ、必要なトークン数を予測させる——ただし、実際には修正は行わない。

結果はどうだったか?

すべてのモデルが大きく外れた。

最も良かったのはClaude Sonnet-4.5の予測の相関性——0.39(1.0が完全一致)。他のモデルは0.05から0.34の範囲で、Gemini-3-Proは最低の0.04で、ほぼ的外れの予測だった。

さらにひどいのは、すべてのモデルが自己のトークン消費を過小評価していることだ。図11の散布図を見ると、ほとんどの点が「完璧な予測線」の下側に位置し、モデルは「そんなに使わないだろう」と思っているのに、実際にはもっと多く使っている。そして、この過小評価は、例示を提供しない場合ほど顕著になる。

皮肉なことに、予測自体もコストがかかる。

Claude Sonnet-3.7とSonnet-4の予測コストは、タスクの実コストの2倍以上に達することもある。つまり、先に「見積もり」をさせる方が、実作業よりも高くつく場合もある。

論文の結論はストレートだ:

現段階では、最先端モデルは自分のトークン消費量を正確に予測できない。エージェントを「動かす」たびに、まるでガチャを回すようなもの——請求書が届いて初めて、いくら使ったかがわかる。

この「曖昧な会計」の裏には、より大きな業界の問題が潜んでいる。

これを読んで、あなたはこう疑問に思うかもしれない:「これらの発見は、企業にとって何を意味するのか?」

  1. 「月額定額」の価格設定モデルは、エージェントによって引き裂かれつつある

論文は、ChatGPT Plusのようなサブスクリプションモデルが成立しているのは、普通の対話のトークン消費が比較的コントロール可能で予測可能だからだと指摘する。しかし、エージェントのタスクはこの仮定を完全に打ち破る——あるタスクはエージェントのループに陥り、巨大なトークンを消費する。

これにより、純粋なサブスクリプション料金はエージェントのシナリオには持続不可能となり、従量制(Pay-as-you-go)が長期的には最も現実的な選択肢となる。ただし、従量制の問題は——使用量自体が予測できないことだ。

  1. トークン効率は、モデル選択の「第三の指標」となるべき

従来、企業はモデル選択の基準として、「能力(できるか)」と「速度(速いか)」の二つを重視してきた。この論文は、もう一つの同等に重要な次元——「能効(どれだけコストをかけて成し遂げるか)」を提案している。

能力は少し劣るが、効率が3倍高いモデルは、スケールのシナリオでは「最強だが高コスト」のモデルよりも経済的価値が高い場合がある。

  1. エージェントには「油計」と「ブレーキ」が必要

論文は、将来の重要な方向性として、「予算意識を持つツール使用ポリシー」(Budget-aware tool-use policies)を挙げている。簡単に言えば、エージェントに「油計」を装備させることだ——トークン消費が予算に近づいたら、無駄な探索を強制的に停止させる。そうすれば、無駄に燃料を使い続けることを防げる。

現状、多くの主流エージェントフレームワークにはこの仕組みが欠如している。

エージェントの「燃費問題」は、バグではなく、業界の避けられない痛みだ。

この論文は、単なるモデルの欠陥ではなく、エージェントのパラダイムそのものの構造的課題を明らかにしている——AIが「一問一答」から「自主的な計画、多段階の実行、反復的な調整」へと進化するにつれ、トークン消費の予測不能性は避けられない。

良いニュースは、これが初めて体系的にこの「曖昧な会計」を明らかにしたことだ。このデータをもとに、開発者はモデルの選択や予算設定、止損メカニズムの設計をより賢明に行えるようになる。モデルメーカーも、新たな最適化の方向性を見出せる——より強くなるだけでなく、より省エネにすることだ。

結局のところ、AIエージェントが産業のあらゆる場面に本格的に入り込む前に、一円一円を明確に把握して使うことが、コードの見た目の美しさよりも重要になるだろう。(この記事は最初に钛媒体APPに掲載されたもので、著者は硅谷Tech news、編集は赵虹宇)

原文表示
このページには第三者のコンテンツが含まれている場合があり、情報提供のみを目的としております(表明・保証をするものではありません)。Gateによる見解の支持や、金融・専門的な助言とみなされるべきものではありません。詳細については免責事項をご覧ください。
  • 報酬
  • コメント
  • リポスト
  • 共有
コメント
コメントを追加
コメントを追加
コメントなし