AIエージェントはめったにクラッシュしない。ひそかに失敗する理由を研究が明らかに

大規模言語モデルを使ったエージェントは今や、サポートへの問い合わせに回答し、データベースを検索し、旅行の計画を立てている。問題が起きても、たいていは自信ありげな回答と成功コードを返す。こうした失敗が見つけにくい理由と、エンジニアリングチームがその測定方法を学びつつある過程を、研究の蓄積が明らかにしている。

成功したように見える失敗

従来のソフトウェアは、問題が起きると目に見える形で失敗する傾向がある。関数は例外を投げ、サーバーはエラーコードを返し、監視ダッシュボードは赤くなる。AIエージェントの挙動は異なる。エージェントは、言語モデルがプロンプトを読み、検索APIやデータベースなどのツールを呼び出すかどうかを判断し、結果を読んで次の行動を決める、というループで動く。この一連の処理では、ネットワークリクエストがすべて成功していても、どの段階でも問題が起こりうる。

よくあるケースを考えてみよう。天気情報ツールが失敗し、ほかは通常どおりの応答の中に「サービスを利用できません」というテキストを返す。モデルはそのテキストを読み、丁寧に謝罪するか、さらに悪い場合には、学習データをもとにもっともらしい予報を作り上げる。ユーザーには流暢な回答が届く。サーバーログには、通常の遅延時間でリクエストが成功したと記録される。従来型の監視基盤には、何か問題が起きたことを示す記録が何も残らない。

モデル提供各社も、自社のドキュメントで同じ問題に言及している。GoogleのGemini APIガイドによると、モデルは「関数そのものを実行するわけではない」。モデルが提案するのは関数名と引数だけで、呼び出しを実行するのは開発者のアプリケーションだ。そのため、実際の結果を確認できるのはシステムの中でアプリケーションだけである。エージェント構築に関するAnthropicのエンジニアリングガイドも関連する点を指摘している。エージェントが自らの進捗を判断するには、ツールの結果など、各段階で環境から得られる「正解となる情報」が必要だという。ツールが失敗を通常のテキストとして報告すると、その情報自体が誤っているため、エージェントにはそれに気づく手段がない。

これは新しい問題ではなく、以前からある問題がより顕著になったものにすぎない。2015年、D. Sculley率いるGoogleのエンジニアたちは、機械学習システムにおける「隠れた技術的負債」について記述した。彼らは、本番環境の機械学習システムに潜むリスクの大半はモデルのコードの外側、つまりデータ依存関係、設定、システムをつなぐコードにあると論じた。エージェントは、このリストに新たな層を加える。プロンプトやツールの説明は設定の一部であり、コードを変更しなくてもシステムの挙動を変えうる。

小さな変更が大きな影響をもたらす

プロンプトを少し変えるだけで、どれほど影響があるのだろうか。ICLR 2024で発表された論文で、メラニー・スクラー氏とUniversity of Washingtonの同僚らは、少数例プロンプトの書式だけを変更した。変更したのは区切り記号、スペース、大文字・小文字の使い方で、意味は変えていない。それでも同じタスクにおけるLLaMA-2-13Bの性能は、正解率で最大76ポイント変動した。モデルを大型化しても、例を増やしても、指示チューニングを行っても、この感度はなくならなかった。

著者らは、単一の数値ではなく、妥当な範囲のプロンプト形式における性能の幅を報告するよう提案している。エンジニアリングチームにとって、実務上の教訓はもっとシンプルだ。プロンプトの編集はコードの変更である。バージョン履歴を残し、ユーザーに提供する前にテストする必要がある。

同じことは、プロンプトの一部としてモデルが読むツールの説明にも当てはまる。Anthropicのガイドは、ツールの定義にもメインのプロンプトと「同じくらいのプロンプトエンジニアリング上の注意」を払うべきだとしている。同ガイドでは、相対パスを使って何度も誤りを起こすコーディングエージェントの例が紹介されている。ツールの仕様を絶対パスの使用必須に変更すると、モデルはエラーなく使えるようになった。モデルは変わっていない。モデルが読む説明だけが変わったのだ。

一度の成功だけではほとんど分からない

研究のもう一つの流れでは、一貫性に注目している。シュンユ・ヤオ氏らがSierraで発表し、ICLR 2025で報告したτ-benchベンチマークは、エージェントがツールを使い、業務上のルールに従わなければならないカスタマーサービスの会話をシミュレーションする。著者らはpass^kという指標を導入した。これは、同じタスクをk回試行し、そのすべてでエージェントが正しく解決する確率を示す。

結果は厳しいものだった。GPT-4oエージェントは、小売業のタスクを1回の試行で約61%解決した。しかし、同じタスクを8回連続で成功させる必要がある場合、その割合は約25%に下がった。一度うまく動くデモを見ても、システムが1000回目の実行でどう振る舞うかはほとんど分からない。

マルチエージェントシステムはどこで破綻するのか

現在、多くのチームが複数のエージェントを連携させている。1つが計画を立て、別のエージェントが実行し、3つ目が作業を確認するという構成だ。UC Berkeleyによる2025年の研究「マルチエージェントLLMシステムはなぜ失敗するのか？」は、よく使われる7つのマルチエージェントフレームワークを対象に、注釈付きの実行トレースを1,600件以上分析した。メルト・ジェムリ氏を筆頭著者とする研究チームは、3つのグループに分類した14の失敗パターンからなる分類体系、MASTを構築した。3つのグループとは、システム設計上の問題、エージェント間の不整合、タスクの検証である。

研究の中心的な知見は、多くの失敗が基盤モデルの限界だけでなく、システムの設計に起因するということだ。エージェントは割り当てられた役割を無視し、会話の流れを見失い、結果を確認せずにタスクが完了したと宣言することがある。こうした失敗はエラーの記録を残さない。各エージェントが実際に何をしたかを読み取れる場合にのみ、問題が見えてくる。Unite.AIが取り上げたマルチエージェントのパラドックスも、アーキテクチャの観点から同様の点を指摘している。エージェントを増やすと、初期の誤りが打ち消されるどころか、増幅されることがある。

見えないものを見えるようにする

エンジニアリング上の対応策は、長らくトレーシングという手法で複数のサービスにまたがるリクエストを追跡してきた分散システムの考え方を取り入れている。エージェントに適用すると、ユーザーのリクエストはそれぞれトレースとなり、モデルの呼び出しやツールの呼び出しは、その中の「スパン」となる。スパンには、入力、出力、使用したトークン数、所要時間が記録される。この分野の業界標準化団体であるOpenTelemetryは、生成AIのスパンに関する共通規約を策定している。2026年現在、この規約はまだ開発中とされているため、属性名は今後変更される可能性がある。

Langfuse、Arize Phoenix、AcruxCoreなど、いくつかのオープンソースプロジェクトでは、すでにこの考え方が取り入れられている。ソースコードが公開されているため、チームはトレースの保存方法を確認し、自社のサーバーでソフトウェアを運用できる。これらのプロジェクトでは、モデルの呼び出しとツールの呼び出しを1つのトレース内のスパンとして記録し、それぞれに品質スコアを付けられる。どのツールを選ぶかよりも重要なのは、ツールのスパンに、ネットワークリクエストが成功したかどうかだけでなく、ツールが実際に返した内容を記録することだ。それがなければ、前述の天気ツールの失敗は見えないままになる。

業界調査によると、トレーシングはすでに一般的になっている一方、テストは遅れを取っている。LangChainのエージェントエンジニアリングの現状に関するレポートは、2025年後半に1,340人の実務者を対象に調査を行った。エージェントを本番環境に導入する際の障壁として最も多く挙げられたのは品質で、回答者の32%がこれを選んだ。89%の組織がエージェントに何らかの形でオブザーバビリティを導入しており、62%は個々のステップやツール呼び出しを詳細にトレーシングしていた。一方、テストセットを使ったオフライン評価を実施していたのは52.4%にとどまり、実際のトラフィックを評価していたのは37.3%だった。ほとんどのチームは、エージェントが何をしたかを確認できる。しかし、それが正しかったかどうかを確かめるチームは少ない。

大規模な回答評価

トレースから分かるのは、何が起きたかだ。回答が良かったかどうかは分からない。会話を一つずつ手作業で読む方法では規模に対応できないため、チームは次第に、別のモデルを採点者として使うようになっている。これは「LLM-as-a-judge（LLMによる評価）」と呼ばれる手法だ。Lianmin ZhengらによるNeurIPS 2023の論文では、GPT-4のような高性能モデルは、人間の選好と80%を超える割合で一致し、その一致率は人間同士の場合とほぼ同じだと報告された。

同じ論文では、この手法の弱点も明らかにされている。評価モデルは先に提示された回答を好み、長い回答を好み、自らが生成した文章を有利に評価することもある。そのため、評価モデルのスコアはあくまで推定値だ。大量の評価には役立つが、回答の順序をランダム化したうえで、人間がラベル付けした少数の例と照合する必要がある。

実践から政策へ

こうした測定の取り組みは、ガバナンス上も求められるようになっている。米国国立標準技術研究所（NIST）は、2023年1月にAIリスクマネジメント・フレームワークを公開した。中核となる4つの機能の1つである「測定」では、組織に対し、AIリスクを定量化し、継続的に追跡して記録するよう求めている。エージェントの場合、トレースと評価スコアが、この機能で求められる証拠となる。

チームが今できること

これは、このプラットフォームで論じられてきた、エージェント型AIの真価は信頼性にあるという主張にも通じる。ここで取り上げた研究は、その主張を支える測定の詳細を示している。信頼性は一度観察すれば分かる性質ではなく、継続して測定しなければならない幅のあるものだ。

研究からは、実践すべき習慣がいくつか見えてくる。主要なモデル提供各社も、その多くを推奨している。エージェント構築に関するOpenAIの実践ガイドは、最適化の前に「評価を設定して性能のベースラインを確立する」ようチームに勧めている。また、エージェントが失敗を一定回数繰り返した場合や、高リスクの操作に直面した場合には、人間に制御を引き継ぐよう促している。Anthropicは、エージェントを自律的に動かす前に「サンドボックス環境で徹底的にテストする」ことを推奨している。

実際には、次のような具体的な手順が考えられる。プロンプトとツールの説明をコードと同様にバージョン管理する。各プロンプトの変更を固定データセットでテストし、単一の数値ではなく、結果に幅があることを想定する。1回の実行では一貫性の欠如を見逃すため、各テストケースを複数回実行する。ツールの出力をトレース内に記録し、成功コードの陰にツールの失敗が隠れないようにする。自動評価モデルのスコアは推定値として扱い、人間による評価と照合する。

こうした習慣を実践するのに、モデルの能力を飛躍的に高める必要はない。必要なのは、AIエージェントをその実態に即して扱うことだ。つまり、失敗を自ら知らせることはめったにないため、測定が欠かせない確率的システムとして捉えることである。