信頼性がモデルのスケーリングではなくエンジニアリング規律を要求する理由、そして本番環境で機能するエージェントを構築することについて、数学・ベンチマーク・市場データが何を語っているのか。Contextual Agentic Vision Platform を構築するチームからのノートである。

複数のステップを連鎖させる AI エージェントは、よく知られた数学的問題に直面する。ステップごとの成功率が固定で、実効的なリカバリ機構を持たない単純な逐次パイプラインでは、信頼性はステップを追加するごとに指数関数的に劣化する。各ステップが 95% で成功するシステムでも、20 ステップを通したエンドツーエンド成功率はわずか 36% にとどまる。これはパッチで修正すべきバグではない。リカバリ機構を持たない逐次システムの構造的性質であり、モデルレベルの対症療法ではなく アーキテクチャ上の 解決を要求する。分解、投票、状態の外部化といったアーキテクチャ上の選択は、減衰曲線を実質的に変えうるが、それは意図的に設計に組み込まれた場合に限られる。

コーディングおよびウェブタスクのエージェント向けベンチマークスコアは、近年急速に向上している。SWE-bench と WebArena のリーダーボードは（いずれも本稿後段で詳述する [9][11]）、2024 年から 2025 年にかけて意味のある幅で動いた。それでも、本番デプロイメントが描き出す姿は対照的である。調査によって手法は異なるが、方向性は一貫している。エージェント AI を「完全にスケールさせた」と回答した企業はわずか 2% 程度にとどまり [1]、エンタープライズ AI 展開のうちコパイロットではなく「真のエージェント」と呼べるものはごく一部に過ぎず [2]、Gartner は 2027 年までにエージェント AI プロジェクトの 40% が本番投入前にキャンセルされると予測している [3]。導入は依然として初期段階にあり、もろい状態にある。

本稿は、その差分に関する一般的なサーベイではない。信頼性の複合劣化問題が Contextual Agentic Vision Platform のアーキテクチャをどう形作ったかについての記述である。VLM がオーケストレーションを担い、スカウトが仲介し、ジャッジが検証する構成が、なぜスタイル上の選好ではなく、深さ・リカバリ・経済性に関する数学が示す結論への直接的応答であるのかを示す。

複合的故障の数学は容赦ない

パイプラインが n 個の逐次ステップで構成され、各ステップが独立に成功確率 p を持つ場合、エンドツーエンド成功確率は pⁿ となる。この指数減衰は厳しい地形を生み出す。

図 1。 逐次ステップ数の関数としてのエンドツーエンド成功率を、ステップごとの信頼性水準別に示したもの。ステップごとの精度が 99% であっても、50 ステップで成功率は 60% にとどまる。

この単純なモデルは、実際の問題を 過小評価 している。エージェントパイプラインのステップは独立であることが稀であり、誤りは意味的に伝播し、下流のコンテキストを検出も回復もしにくい形で汚染する。Pedder の 「failure stickiness（故障の粘着性）」 という概念はこれを定式化する。誤りがパイプラインを通じて不可視に伝播する場合（Pedder の用語では「absorbing failures」）、ステップごとの信頼性が 95% で粘着性が高いシステムは、独立性仮定が予測する水準よりも著しく悪いパフォーマンスを示す [4]。彼の分析によれば、誤りから 回復する 能力は、各ステップの信頼性を 2.7 倍 高めることに等価である。これは、信頼性の問題を本質的に「リカバリのアーキテクチャ」の問題として捉え直す知見であり、単なるステップレベルの精度の問題ではない。

UC Berkeley から 2025 年に出た論文 Why Do Multi-Agent LLM Systems Fail?（Cemri ら、NeurIPS 2025）[5] は、7 つの代表的なマルチエージェントフレームワーク上で 1,600 を超える実行トレース にアノテーションを付与し、14 種類の故障モードを同定した。クロスアプリケーションテストでは、OpenHands や MetaGPT のようなフレームワークで故障率が 86.7% に達した。提案されたロール仕様の改善などの介入では不十分であり、著者らは故障の解消には「より複雑な解決策」が必要だと結論づけている。

最も厳密な信頼性フレームワークは、Princeton の Rabanser、Kapoor、Narayanan（「Towards a Science of AI Agent Reliability」、2026）[6] による。彼らはエージェント信頼性を、整合性・頑健性・予測可能性・安全性にまたがる 12 個の指標へと分解した。中心的な発見は次の通りである。18 ヶ月にわたるフロンティアモデル 14 種の能力向上にもかかわらず、信頼性はほとんど動いていない。 Pass@1 指標は真の信頼性を 20〜40% 過大評価する。

重要な洞察。 精度（accuracy）と信頼性（reliability）は本質的に異なる性質である。モデルは問題を解く能力が劇的に向上しても、どの 問題を解けるかについては同程度に予測不可能なままでありうる。

エージェント型ビジョンにとってこの問題が特に重要な理由

信頼性の複合劣化の問題はテキストエージェントにとっても深刻だが、エージェント型ビジョンにおいてはより深刻になる。本設定に固有の三つの理由がある。

ビジュアルスカウトはテキストスカウトより高価である。 専門 CV モデルの一回の呼び出しは、テキストツール呼び出しよりも計測可能な分だけ多くの計算を要する。「スカウトをもっと呼んで投票させる」という素朴な対応は、ビジョンではテキストよりも急峻なコスト曲線を持つ。スカウト総呼び出し回数を有界に保つアーキテクチャ上の選択は、不釣り合いに重要となる。

視覚的証拠は安価に再導出できない。 テキストエージェントの推論ステップが誤った場合、同じプロンプトを同じコンテキストに対して再実行すると、通常は同じ故障を再現するか、比較的安価なリトライが得られる。ビジョンスカウトが、見たフレームがオクルードされていたために欠陥を誤分類した場合、修正策は「同じフレームに対してモデルを再実行する」ことではない。「別のフレームを見る、別の角度を取る、次の検査パスを待つ」ことである。ビジョンにおけるリカバリは、エージェントステップ間の協調だけでなく、エージェントとセンシング層との間の構造的協調を要求する。

下流の消費者はしばしば物理的である。 ビジョンパイプラインは、ロボットを動かし、保守をスケジュールし、オペレータに警告を発する判断を駆動する。誤った判断のコストは「ユーザが修正できる一文」ではない。誤った鉄塔に派遣される保守クルーであり、顧客に出荷される欠陥である。アクションを正当化する信頼性のバーは、段落を正当化する水準よりはるかに高い。

これら三つの性質ゆえに、信頼性の複合劣化へのアーキテクチャ上の応答は、本設定では選択肢ではない。本番システムを成立させるための代価そのものである。

エージェントの成功率はタスクの複雑性に対して指数的に減衰する

METR の Measuring AI Ability to Complete Long Tasks（Kwa ら、2025）[7] は、この件に関する決定版の経験的描像を与える。研究者らは「50% タイムホライズン」、すなわちエージェントが半数の確率で成功するタスク長（人間換算の所要時間）を測定した。Claude 3.7 Sonnet では、このホライズンは約 50 分であった。

これに続く Toby Ord の分析 [8] は、ハザード率を一定とおく単純化モデル（故障確率をタスク継続時間にわたって一様とする）の下での含意を探っている。この枠組みでは、50 分タスクで 50% の成功率を達成するエージェントは、約 7 分 のタスクでようやく 90%、43 秒 程度のタスクでようやく 99% の成功率に達する。99.9% の信頼性が要求されるエンタープライズ用途では、実用可能なタスク長は秒の単位に縮退する。これらは運用上の計測値ではなく封筒裏の外挿だが、深刻さを示すには十分である。重要なのは、Ord が人間の生存曲線がこの定ハザードモデルよりも顕著に良好であることを示した点である。これは、現状のエージェントよりも人間のほうがミスから効果的に回復していることを示唆する。

図 2。 ベンチマークと本番のギャップ。同一のモデル構成が、SWE-bench の各派生（Verified、Pro、Live）、WebArena、OSWorld にまたがって劇的に異なる成功率を示している。統制されたベンチマークは実世界の能力を実質的に過大評価する。

ベンチマークデータは複数ドメインでこの傾向を裏付ける。SWE-bench Verified では上位エージェントが 80% 超を記録するのに対し、SWE-bench Pro では同システムが 〜46% へ落ち [10]、SWE-bench Live では 19〜43% にとどまる [9]。WebArena では、最良の単一エージェントシステムが 61.7% に達するのに対し、人間ベースラインは 78% である [11]。OSWorld のデスクトップタスクでは、当初のベストモデル成功率 12.24% が一部の構成で 76% にまで上昇したものの、Epoch AI はそれらのタスクのおよそ 45% が、真の GUI 推論ではなく簡易なターミナルコマンドで完遂できる点を指摘している [12]。

ベンチマーク性能と本番信頼性は、異なるものを計測している。 前者は統制条件下でのピーク能力を捉え、後者は実世界の長い裾を貫いた一貫した性能を要求する。

トークン経済学が複合的なコスト危機を生み出す

信頼性の問題には経済的な双子が存在する。各ステップが膨らみ続ける会話履歴の全体を再処理するような素朴な反復型エージェントループでは、トークンコストは線形ではなく 二次関数的に 累積する。SWE-bench リーダーボードの分析によれば、高性能エージェントはタスクあたり、ワンショット手法と比べて 10〜50 倍 のトークンを消費する [13]。

図 3。 左。トークンコストは、各エージェントターンが先行コンテキストを再処理するため二次関数的に増大する。右。「モンスタートラック・パラドックス」。トークン単価は年率約 10 倍で低下しているが、タスクあたりの消費量はそれ以上に速いペースで増加しており、エージェント型ワークロードがその原動力となっている。

スケールは目を引く。チャットからエージェントへの進化は、セッションあたりのトークン消費量を桁単位で押し上げており、個人のヘビーユーザの中には月あたり数十億トークンを消費しているケースも報告されている [14]。トークン単価は 2023 年以降毎年約 10 倍のペースで低下しているが、タスクあたりの消費量はコスト低下を上回るペースで増えている。

本番運用にとって、この経済学は厳しい。中規模のデプロイメントは月あたり 500 万〜1,000 万トークンで 月額 1,000〜5,000 ドル となる。Claude Code の利用は 開発者一人あたり 1 日 6 ドル が平均値である [15]。エンタープライズのプロトタイプはステージングから本番に移る段階で、月額 5,000 ドルから 月額 50,000 ドル へとコストが跳ねるケースが珍しくない [3]。プロンプトキャッシュ、階層的サマリゼーション、選択的アテンションを通じて 5〜20 倍の削減を達成するコンテキスト圧縮は、最も ROI が高い最適化であり、70〜94% の節約が報告されている。しかし、これらの緩和策は症状に対する処方に過ぎない。

可能な場面では、ステートレス設計 がしばしば最も効果の大きい対抗手段となる。スカウトおよびアナリストの呼び出しを、特化した単一目的のツールとして扱う。明確な指示を与え、結果を受け取り、終了する。状態を保持する必要がある場合は、それを外部化する。中間結果は会話履歴に積み上げるのではなく、データベースまたはコンテキストパックのストアに書き込む。呼び出しの間に何も覚えていないエージェントこそスケールするエージェントであり、ジャッジ層が実際に監査できるエージェントである。

信頼性を実際に改善するアーキテクチャパターン

最も勇気づけられる近年の結果は、Cognizant の AI Lab から出ている。Meyerson ら（「Solving a Million-Step LLM Task with Zero Errors」、2025）[16] は、MAKER フレームワークによって 100 万を超える逐次 LLM ステップをゼロエラーで 完遂することを実証した。MAKER はこれを三つの原理によって達成している。原子的サブタスクへの極端な分解をステートレスな「マイクロエージェント」が処理する構成、ギャンブラーの破産問題の一般化に基づくマルチエージェント投票、そして構文エラーを論理エラーのシグナルとして扱い修復ではなく破棄する「レッドフラギング」である。最も意外なのは、信頼性／ドル比で最良のパフォーマンスを示したのが より小さな、推論モデルではないモデル だった点である。

重要な留保がある。MAKER の 100 万ステップ達成は、高度に構造化され完全に検証可能なタスク（ハノイの塔）と決定的な検証手段の上で得られた結果である。アーキテクチャ原理（分解、投票、ステートレスなマイクロエージェント）は広く適用可能だが、ゼロエラーという具体的な数字をそのまま曖昧なエンタープライズワークフローへ外挿してはならない。

これは主要研究機関にまたがる近年のコンセンサスと整合する。Anthropic の Building Effective Agents（Schluntz と Zhang、2024）[17] は明確な階層を打ち出している。シンプルに始め、必要性が示されたときだけ複雑さを追加し、エージェント型システムがレイテンシとコストをタスク性能と引き換えにしている事実を直視する、というものである。Anthropic はその後、SWE-bench で SOTA を達成したが、その一因はモデルの変更ではなく、ツール記述の入念な改善 であった。これは、インフラ設計がモデル能力よりも重要となりうることの具体的な証左である。

OpenAI の Practical Guide to Building Agents（2025）[18] も独立に同様の結論に到達しており、マルチエージェントの複雑性を導入する前に まず単一エージェントの能力を最大化 することをチームに推奨している。競合する研究機関からのガイダンスが同じ原理（簡素さ、狭いスコープ、ツール設計の入念さ）へ収束していること自体が、強い証拠である。

DSPy（Khattab ら、NeurIPS 2023）[19] が切り開いたプログラム的アプローチは、もう一つの応答を与える。プロンプトを手で組み上げるのではなく、DSPy は LLM パイプラインを最適化可能なプログラムとして扱う。特定のタスク構成において、本フレームワークは GPT-3.5 でパイプライン品質を 33% から 82% へ改善した。ただし、この数字は特定のベンチマークスライス由来である。より広い論点は揺るがない。DSPy は、根底のモデルを変更するのではなく、パイプライン構造の系統的最適化を通じて実質的な向上を達成している。

重要な洞察。 基盤となるアーキテクチャ（接地のための ReAct [20]、失敗から学ぶための Reflexion [21]、階層的構成のための Voyager [22]）はそれぞれ、複合的システムの異なる故障モードに対処する。勝ち筋は一つを選ぶことではなく、タスクの信頼性要件に応じて適切な組み合わせを構成することにある。

Contextual Agentic Vision Platform がこの問題にどう応えるか

筆者らが他所で論じてきたアーキテクチャ上の選択（VLM が主導し専門 CV スカウト群をオーケストレーションする構成、決定を出荷する前にエビデンスチップを再検証するジャッジ層、エージェントの作業メモリから状態を外部化するコンテキストパック）は、上記の知見への直接的応答である。

分解。 Platform は、単一のモデルに「知覚し、解釈し、決定する」を一回のパスで求めない。専門スカウト群（検出、セグメンテーション、OCR、深度、トラッキング）は、対象範囲が狭く、ステートレスで、十分にキャリブレーションされている。その上位にある VLM アナリストは、生フレームではなく、構造化されたスカウト出力に対して動作する。アナリストの上位にあるジャッジ層は、自由形式の文章ではなく、引用可能な主張に対して動作する。各層のステップごとの信頼性が高いのは、各層のタスクが狭いから である。

第一級のリカバリ層。 ジャッジは Platform のリカバリアーキテクチャである。新しい証拠を収集するのではなく、整合性を検査し、チップで引用できない主張をフラグする。Pedder の「2.7 倍相当」のリカバリ基盤の利得 [4] こそ、ジャッジ層が捕獲するよう設計された利得である。スカウト出力から再構成できない判断は、構造上ブロックされる。文章で取り繕われることはない。ビジョン設定ではこれがテキスト以上に重要となる。所見が、次の ROV パスや次のクリーニングウィンドウまで新しい証拠を待たねばならない場合、裏付けのない主張を出荷拒否するジャッジ層こそが、実用に堪える検査レポートと、不確実性を静かに隠蔽するレポートとの分岐点となる。

外部化された状態。 コンテキストパック（顧客からの内部コンテキスト、公的なリファレンス、Yodo Labs の故障モードアトラスに由来するコンテキスト）は、任意のエージェントの会話ウィンドウの外部に存在する。エージェントはこのストアに対してステートレスに動作する。二次関数的トークン増大の問題 [13] は適用されない。各スカウトおよび各アナリスト呼び出しは、自らの狭いタスクに関係するコンテキストのスライスだけを見るからである。ビジョンワークロードにおいては、これが GPU メモリの制御方法そのものでもある。KV キャッシュのフットプリントはプロンプトに載せたものの大きさに比例する。プロンプトを関係するコンテキストスライスに絞り込むことが、7B クラスの VLM を本番解像度において単一 GPU の予算内に収める方法である。

結果に応じた境界づけられた自律性。 Feng、Morris、Mitchell（Levels of Autonomy for AI Agents、2025）[23] は、自律性を能力とは切り離した意図的な設計判断として形式化する。筆者らのデプロイメントでは、Platform の自律性は知覚層で高く（スカウトは見たままを見る）、アクション層では強く境界づけられる。アナリストが提案し、ジャッジがゲートし、オペレータがアクションの前に確認する。理由は、他所で記述した風力タービンブラケットの事例と同じである。誤った自律的アクションのコスト（誤って派遣された保守クルー、繰り延べられた荷重サーベイ）は、ユーザが修正可能な段落ではなく、運用上の結果として支払われるからである。

図 4。 左。2025 年のエンタープライズ AI アプリケーション支出の構成。コパイロット対自律エージェント [2]。右。完全な自律エージェントに対する信頼度の前年比低下 [1]。

市場データは、信頼性インフラの現在地を読むためのものであり、筆者らのアーキテクチャはその読みに合わせて較正されている。

長期的な答えとしての訓練可能なツール使用。 上記のアーキテクチャは土台であり、その下に走る研究の縦糸は、VLM のツール選択ポリシーを専門スカウトと共同で訓練し、システムを 最終アウトカムの品質 に対して最適化する（ステップの妥当性に対してではなく）ことである。これが、筆者らが現在まとめつつある訓練可能なツール使用のビジョンの方向性である。これは、Princeton の知見、すなわち 18 ヶ月の能力向上が信頼性を動かさなかった [6] という事実への、より長い時間軸での応答である。信頼性はモデル単体の性質ではなく、より良いモデルを待つことで得られるものではない。

ここから見えるもの

本番信頼性に関しては、エンジニアリング規律が、追加的なモデル能力向上と少なくとも同程度に重要であり、現状の多くのデプロイメントではそれ以上に重要である。証拠は収束している。Princeton による「18 ヶ月の能力向上が信頼性を動かさなかった」という知見。Cognizant による「高度に構造化された領域では、適切なアーキテクチャを伴った小型モデルが信頼性／ドル比で大型モデルに匹敵またはそれを上回りうる」という実証。Anthropic による「ツール記述の改善を通じて SWE-bench で SOTA を達成した」という事実。

これが筆者らの設定で実際に取る形は、スカウト／アナリスト／ジャッジ に外部化されたコンテキストと実体のあるリカバリ層を組み合わせ、加えてオーケストレーション自体を訓練可能にしていく研究プログラムを併走させる、というものである。複合的信頼性の問題は、次世代モデルで克服される一時的制約ではない。逐次システムの構造的性質であり、構造的解決（分解、検証、リカバリ、適切な自律性）を要求する。これを内面化した組織、すなわち適切にスコープされ、信頼性が高く、計装が行き届いたシステムを構築し、信頼性インフラが支えうる範囲でのみ自律性を拡張する組織こそ、エージェント時代に実質的な価値を獲得することになる。

References

1. Capgemini, "Trust and Human-AI Collaboration Set to Define the Next Era of Agentic AI." 2025. capgemini.com
2. Menlo Ventures, "2025: The State of Generative AI in the Enterprise." menlovc.com
3. Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027." June 2025. gartner.com
4. C. Pedder, "When agents fail: compounding errors in organisational systems." Substack, 2025
5. M. Cemri, X. Pan, et al., "Why Do Multi-Agent LLM Systems Fail?" NeurIPS 2025. arXiv:2503.13657
6. S. Rabanser, S. Kapoor, A. Narayanan, "Towards a Science of AI Agent Reliability." 2026. arXiv:2602.16666
7. T. Kwa et al., "Measuring AI Ability to Complete Long Tasks." METR, 2025. arXiv:2503.14499
8. T. Ord, "Is there a Half-Life for the Success Rates of AI Agents?" tobyord.com, 2025
9. J. Yang et al., "SWE-bench Goes Live!" arXiv:2505.23419
10. SWE-bench Pro Leaderboard. swebench.com
11. S. Zhou et al., "WebArena: A Realistic Web Environment for Building Autonomous Agents." arXiv:2307.13854
12. Epoch AI, "What does OSWorld tell us about AI's ability to use computers?" epoch.ai, 2025; T. Xie et al., "OSWorld: Benchmarking Multimodal Agents." arXiv:2404.07972
13. "How Do Coding Agents Spend Your Money?" ICLR 2026 submission. OpenReview
14. IKANGAI, "The LLM Cost Paradox: How 'Cheaper' AI Models Are Breaking Budgets." ikangai.com
15. Anthropic, "Manage costs effectively, Claude Code Docs." code.claude.com
16. E. Meyerson et al., "Solving a Million-Step LLM Task with Zero Errors." Cognizant AI Lab, 2025. arXiv:2511.09030
17. E. Schluntz, B. Zhang, "Building effective agents." Anthropic, Dec 2024. anthropic.com
18. OpenAI, "A Practical Guide to Building Agents." 2025. openai.com
19. O. Khattab et al., "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines." NeurIPS 2023. arXiv:2310.03714
20. S. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models." ICLR 2023. arXiv:2210.03629
21. N. Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning." NeurIPS 2023. arXiv:2303.11366
22. G. Wang et al., "Voyager: An Open-Ended Embodied Agent with Large Language Models." TMLR 2024. voyager.minedojo.org
23. G. Feng, M. Morris, K. Mitchell, "Levels of Autonomy for AI Agents." 2025. arXiv:2506.12469