エージェント実行税：ブラウザ自動化における真のボトルネック

エージェント実行税：構造化出力の信頼性が推論能力よりも重要な理由

基礎モデルはますます賢くなり、推論ベンチマークで優秀な成績を収め、流暢なコードを書き、専門試験に合格しています。しかし、それらをエージェントループ内に置き、ウェブページを観察し、決定を下し、構造化されたアクションを10回連続で出力させる必要がある場合、約半分の確率で失敗します。

Fireworks AIはNotteと協力し、4つの大規模言語モデルに対して720回のブラウザ自動化タスクを実行し、その理由を調べました。答えは「知能」ではなく「実行」でした。あるモデルでは、LLM呼び出しのほぼ5回に1回が不正なJSONフォーマットのために再試行を余儀なくされ、その信頼性のギャップが高レイテンシ、コストの膨張、および成功率の低下につながりました。

このオーバーヘッドを「エージェント実行税」と呼びます。これは無駄な推論と生産的な推論の比率です。ベンチマークで最悪のモデルではこの税率が22.9％、最良ではゼロでした。

エージェントシステムでは、信頼性は知能よりも強く増幅されます。勝利したモデルは推論スコアが最も高いものではなく、要求されたフォーマットで毎回確実に指示を実行したモデルでした。

実行税の定義と計算

ブラウザエージェントタスクは外見上は単純です：Amazonにアクセスし、製品を検索し、価格を抽出する。しかし内部では多段階のループです：ページを観察 → LLMがアクションを生成（JSON形式） → アクションを実行 → 新しいページを観察 → 繰り返し。典型的なタスクは約10ステップかかります。各ステップはLLM呼び出しであり、クリックする要素、入力するテキスト、または抽出するデータを指定する有効な構造化出力を返さなければなりません。JSONが不正な場合、フレームワークは再試行します。この再試行は非表示であり、タスク成功率や推論ベンチマークには現れず、エンジン自体を計測した場合にのみ呼び出し回数、レイテンシ、コストとして表面化します。

実行税の計算式：（総推論呼び出し数 - 生産的呼び出し数）/ 生産的呼び出し数。生産的呼び出しは初回で有効な構造化出力を返したものです。税率は、行われた有用な作業に対してどれだけ余分な推論を支払っているかを測定します。

我々のデータでは、Kimi K2.5の生産的呼び出しは852回、総呼び出し852回、税率0.0％；GLM-5は869回の生産的呼び出し、総884回、税率0.6％；MiniMax M2.5は815回の生産的呼び出し、総828回、税率1.6％；Gemini 2.5 Flashは721回の生産的呼び出し、総886回、税率22.9％でした。つまり、Geminiが1ドルの生産的推論を生み出すたびに、23セントの無駄が追加で発生します。

税の複合効果

実行税は単一のコストではなく、3つの次元で積み重なります：

トークン税：不正な応答による無駄なトークン、および再試行ごとに再送信される完全な入力コンテキストのトークン。Geminiはステップあたり平均15,482入力トークンを使用し、再試行ごとにその全コンテキストをゼロの生産的出力のために再送信します。

レイテンシ税：再試行ごとに完全なLLMラウンドトリップ（Geminiの中央値約2.5秒）が追加され、タスクあたり約5.7秒のデッドタイムとなります。

カスケード税：ステップ8での再試行によりエージェントの内部状態が非同期になり、後続のステップがページを誤解釈して失敗する可能性があります。測定が最も難しく、規模が大きくなると最も危険です。

一般化された式：タスクあたりの期待再試行回数 = ステップ数 × 再試行率 / (1 - 再試行率)。10ステップタスクでGeminiの再試行率18.6％の場合、期待再試行回数は約2.3回、タスクあたり約36,500トークンの無駄、約5.7秒のデッドタイムになります。

構造化出力の信頼性：根本原因

実行税はレンズであり、構造化出力の信頼性がその原動力であり、生産エージェントで最も報告されていないボトルネックの1つです。本ベンチマークでは、Gemini 2.5 Flashの総LLM呼び出しは886回、パース再試行は165回（再試行率18.6％）、タスクあたり呼び出し数14.7回でした。一方、3つのFireworksモデル（Kimi K2.5、GLM-5、MiniMax M2.5）は2,564回の呼び出しで合計18回の再試行（0.7％）でした。

10ステップエージェントタスクで、少なくとも1ステップが再試行を必要とする確率：Gemini 86.7％、MiniMax 14.9％、Kimi 0％。Geminiではタスクの87％が少なくとも1回のパース再試行を経験します。これはエッジケースではなく、デフォルトの体験です。Geminiのタスクあたり平均LLM呼び出し数は14.7回、Fireworksモデルは約10回で、余分な約4.7回の呼び出しはほぼすべて再試行とそれによって引き起こされる下流ステップです。

信頼性調整済み精度

生のタスク精度はエージェントがどのくらい成功するかを示しますが、そこに到達するためのコストは考慮しません。複合指標「信頼性調整済み精度」は、タスク成功率に(1 - 実行税)を掛けて計算します。結果：GLM-5は生精度57.1％、税後56.8％；MiniMax M2.5は生精度57.5％、税後56.6％；Kimi K2.5は生精度49.7％、税後49.7％；Geminiは生精度45.0％、税後34.7％。Geminiの生精度（45.0％）と信頼性調整済み精度（34.7％）の差は実行税の最も明確な図解であり、Geminiの運用容量の3分の1以上が実行オーバーヘッドによって消費されていることを示しています。

なぜ誰もこれを測定しないのか

パース再試行はLLMエンジン内部で発生し、エージェントフレームワークが結果を認識する前に起こります。エンジンを計測しない限り、再試行は見えません。静的なベンチマーク（MMLU、HumanEval、ARC）はモデルの知能を個別に測定しますが、モデルが多段階ループ全体で構造化出力のコンプライアンスを維持できるかどうかは測定しません。パース再試行率はすべてのエージェントベンチマークで第一級の指標であるべきです。

実践例

タスク：「シカゴ、イリノイ州にあるすべてのユニクロ店舗を検索せよ。」（Google Maps、WebVoyagerベンチマークより）

Kimi K2.5：12ステップ、12回LLM呼び出し、パース再試行0回、総所要時間51.2秒、LLM時間23.2秒、入力トークン87,063、出力トークン3,236。

Gemini 2.5 Flash：16ステップ、25回LLM呼び出し、パース再試行9回、総所要時間97.9秒、LLM時間57.5秒、入力トークン207,971、出力トークン8,411。

両方とも答えを見つけましたが、一方は51秒と12回のクリーンな呼び出しで完了し、もう一方は98秒と25回の呼び出しを要しました。違いは推論能力ではなく、実行オーバーヘッドでした。

デプロイ準備スコアカード

本ベンチマークは3つのモデルに意思決定ガイドを提供します：

• GLM-5：最高精度（57.1％）、最高コスト。コンプライアンスワークフロー、研究自動化、エラーが下流の結果に影響を及ぼすタスクに適しています。
• MiniMax M2.5：最高のコストパフォーマンス。タスクあたりの成功コストが最低（0.062ドル、Geminiの2.3倍安い）。RLで訓練されたエージェントで、ステップ数が最も少なく（平均9.8）、再試行がほとんどありません（1.6％）。規模化された本番ワークロードのデフォルト選択肢。年間4万ドルの無駄の計算により、量的に経済的に支配的な選択肢となります。
• Kimi K2.5：最速、実行税ゼロ。LLM中央値レイテンシ2.1秒、852回の呼び出しでパース再試行ゼロ。顧客向けエージェント、ライブデモ、および応答レイテンシがユーザーの信頼に影響するワークフローに最適です。

結論

エージェントシステムでは、信頼性は知能よりも重要です。構造化出力の信頼性、実行税、およびタスクあたりの成功コストは、モデル選択と調達の中心的な指標となるべきです。本ベンチマークの完全なデータと方法論は付録を参照してください。