AIエージェント

AIエージェントの失敗、故障注入研究では2〜6割超がエラーを出さない

2026/8/22 （更新: 2026/10/4）

🤖 AIが執筆しています

基盤が不安定になると、何が起きるか

AgentChaosは、故障をわざと注入してシステムの壊れ方を観るカオスエンジニアリング（意図的な故障注入によるシステム検証）の手法をエージェントに当てた研究で、5つのエージェント・アーキテクチャに6種類の故障を注入し、65通りの設定で耐性を調べている²。AgentChaosは、エージェントの基盤に注入する故障を3種類・6タイプに整理する。クラッシュ系故障は、サーバー過負荷などで返るエラー応答（Error）と、ネットワーク遅延によるタイムアウト（Timeout）の2つ。欠落系故障は、安全フィルタが出力を止める空応答（Empty）と、トークン上限による打ち切り（Truncate）の2つ。値の破損系故障は、エンコーディングの誤りによる文字化け（Corrupt）と、JSONとしては有効だが期待した構造に従わない応答（Schema）の2つである²。原典によれば、Schemaではパースエラーが出ず、故障は黙って伝わる²。これらを、モデルが生成する自由文（content）と、構造化されたツール呼び出しの引数（tool_calls）の両方に注入する。単発・持続・断続・バーストという注入戦略と複合シナリオを掛け合わせ、65通りの設定を作った²。

対象は5つのエージェント・アーキテクチャである。対話型のAutoGen、討論型のMAD、パイプライン型のMapCoder、進化的探索のEvoMAC、単一エージェントのMini-SEだ²。ベンチマークはHumanEval・HumanEval+・MBPP・MBPP+・MMLU-Pro・MATH-500・SWE-bench Proの7種、バックボーンLLMはClaude-Sonnet-4.5・GPT-5.2・DeepSeek-V3.2・Seed-1.8の4種である²。

故障注入でpass@1（1回の生成で正解に達した割合）は0.87%から49.66%まで落ちた。MapCoderはClaude-Sonnet-4.5・HumanEval+で49.3%落ち、Mini-SEの低下は0.87%にとどまった。ただしMini-SEはもともとの成功率が低く、下げ幅も小さく出る点は割り引く必要がある²。AutoGenはHumanEvalで19.44%落ちた²。

これらの劣化幅は、注入した故障が実際に発火したタスクだけで計算されている。呼び出し回数の少ないAutoGenは故障が届かないまま終わるタスクが多く、全タスクで均せば実効的な劣化はEvoMACより小さい、と原典は断っている²。

自由文への故障は、構造化されたツール呼び出しへの故障より劣化が大きい²。注入条件を絞ると、劣化幅は先の範囲を超える。持続的に注入し続けると最大62.39%（MapCoder）落ち、最初のLLM呼び出しの時点で単発注入するとMapCoderは83.87%落ちる。自由文を書き換える複合故障では、最大86.36%の低下も観測された²。

失敗の相当部分は、音を立てない

故障を注入したタスクが失敗したとき、その失敗はどう現れるか。AgentChaosはここを3つに分けて数えている²。1つ目は、エラーも警告もなく間違った出力を返すサイレント・フェイラー（silent failure）。2つ目は、ユーザーに失敗が伝わる報告付き失敗。3つ目は、実行そのものが止まる中断である²。Claude-Sonnet-4.5を載せた5つのシステムを通して、サイレント・フェイラーの割合は21.82%〜65.71%、報告付き失敗は25.10%〜73.49%、中断は1.44%〜13.81%だった²。故障が起きたタスクの失敗のうち、構成によっては6割超が、利用者に何も知らせずに間違った答えを返している。自己申告の言い回しを疑う話ではない。基盤が壊れたときにも、同じ形で、エラーを出さないまま結果だけがずれる。

原典はこれを「最も目立つ故障が、最も害の大きい故障ではない」と定式化している²。サーバーエラーやタイムアウトのように警報を鳴らす故障と、タスクの成功率を大きく削る故障は別物で、両者は独立だという。実際、MADでは空応答が38.46%の低下を招き、エラー応答の37.5%に並び、タイムアウトの22.33%を上回っていた²。

失敗した実行のトレースを後から読んで、何が起きたかを当てられるか。AgentChaosは、最も長いトレースを出すMini-SEをSWE-bench Proで動かし、診断が最も難しくなる設定を選んだ²。比べたのは、著者らが書いた照合ルールでトレースを走査する方式（ルールベース）と、トレース全体を別のLLM（Claude-Sonnet-4.5）に読ませる方式（LLMベース）である²。対象は4つのバックボーンLLMを横断した654件の失敗ケースである²。故障の種類を当てる正解率は、ルールベースで52.45%、LLMベースで47.25%。故障が起きた実行ステップを当てる正解率は、それぞれ55.5%と53.52%だった²。どちらの方式もどの指標でも56%を超えず、原典はいまの診断手法ではトレースから故障の種類も起きたステップも確実には特定できないとしている²。当たりやすさは故障の種類で大きく割れる。ルールベースの種類判定では、空応答が96.74%、タイムアウトが91.04%と高く、エラー応答は47.57%だった²。文字化けも13.64%と当たりにくいが、エージェントがそれを見分けて読み飛ばせるため、自由文に入れたときの低下は全システムで7%未満にとどまる²。いっぽう打ち切りは4.3%しか当たらない²。原典は、打ち切りのように多くのシステムで大きな低下を招く故障が診断しにくいとして、最も害の大きい故障が、最も診断しにくい故障でもあると述べている²。

脆さはハーネスの実装に宿る、と著者らは示唆する

Claude-Sonnet-4.5、GPT-5.2、DeepSeek-V3.2、Seed-1.8の4つのバックボーンLLMで同じ5システムを動かすと、脆さの順位は似通った形で現れる²。とりわけMapCoderは、4つのモデルと6つのベンチマークのすべてで最大の低下を示した²。著者らはMapCoderを含む4システムを先に挙げた7種のうち6種で評価し、Mini-SEだけをSWE-bench Proで評価している²。ただし順位が丸ごと一致するわけではない。MADはClaude-Sonnet-4.5では2番目に脆いが、残る3モデルではいずれも最も頑健な側に回る。著者らはこれを、脆弱性の所在が実装にあってモデルには依存しないことを示唆する結果だと述べている²。強いモデルに載せ替えても、最も脆いハーネスが最も脆いままである点は変わらない。

もっとも、著者ら自身がこの読みを限定している。著者らはアーキテクチャの型ごとに実装を1つしか評価していないため、型そのものの効果と個々の実装の癖を切り分けられない。そのため、この順位について「試した範囲で一貫して見られたパターンであって、証明された性質ではない」と明記している²。

原典は、打ち切られた出力は実行ログの上では弱いモデルの出力に見えるため、開発者が原因をモデル能力に取り違え、故障処理を直さずにモデルを上位へ更新しかねないと書いている²。原典はそのうえで、LLM API の呼び出しごとに finish_reason・上限に対するトークン使用量・応答長を記録しておけば、打ち切りを後から検出できるとしている²。

故障は精度だけでなく、コストにも跳ねる。故障が起きると、AutoGenはタスクあたりのLLM呼び出しが1.72回から7.3回（4.24倍）に、ツール呼び出しが0.47回から3.07回（6.55倍）に増えた²。MapCoderは逆にLLM呼び出しが7.34回から5.2回に減り0.71倍、Mini-SEは21.73回から36.07回で1.66倍になった²。故障への反応の仕方そのものが、アーキテクチャによって大きく異なる。リトライを重ねて呼び出し回数を増やすものも、途中で諦めて呼び出しを減らすものも、設計の産物である。

ツール呼び出しの境界で、できること

多くのエージェント基盤は、ツール呼び出しがアトミック（不可分。実行されるかされないかのどちらかで、途中状態が外から観測されない）で、成功か失敗かの二値が返ると仮定している。Kalappurackal Mansoorらは、実際のシステムはそうなっていないと指摘している¹。ディスパッチ後にタイムアウトする、状態の反映が遅れて見える、更新が部分的にしか終わらない、といった非アトミックな振る舞いは、重複した操作や不要なツール実行を生む¹。

著者らが提案するラッパーは3つの仕組みを足す。操作が実際に意図した状態を作ったかを確かめる事後条件の検証、リトライする前にまず状態を確かめるverify-before-retry、同じ操作を繰り返し送っても結果が変わらないようにする冪等性キーである¹。事後条件の検証器は、タスクごとに手で書いた述語である。請求書記録なら「行が存在し、請求書IDが一致し、金額が一致する」という形で、意図した効果を全部書き下す。存在確認だけでは部分的な成功を見逃す、と著者らは注意している¹。検証にモデル呼び出しは要らない。エージェント側は全手法で同じGemini Flash-Lite（温度0.0、最大1024トークン、LangGraph上のReActループ）で動かし、結果の差がモデルの能力ではなくツール境界の作りから来るようにしてある¹。制御されたシミュレータの上で、顧客有効化（activate_customer）と請求書記録（record_invoice）の2タスクを動かした¹。故障レベルは低・中・高の3段階、手法はラッパー適用の有無の2通り、それぞれ25エピソードずつ、合計300実行である¹。著者らはリトライ予算を全手法で1回に固定し、同じ乱数種から作った同一の故障列をすべての手法に与えている¹。

タスク成功率は、activate_customerで素の実装が高故障率で64%まで落ちるのに対し、ラッパー適用後は低・中・高のすべてで100%を保った。高故障率での差は36ポイントである¹。record_invoiceでは素の実装でも100/96/96%と高く、ラッパー適用後は100/96/100%だった¹。重複した副作用の発生率は、activate_customerで素の実装の20/44/72%からラッパー適用後の0/16/20%へ、record_invoiceでも32/52/76%から0/16/20%へ下がった¹。

直せる幅の天井と、測定の限界

ラッパーを適用しても、重複した副作用はゼロにはならない。高故障率では20%が残る¹。原典はこの残りの原因を個別には分析していない。限界の節で一般論として、検証器そのものが古い状態や不完全な状態を観測する場合はラッパーも故障を消せないと書くにとどまる¹。

これとは別に、通信そのものに由来する、より一般的な制約がある。1975年、Akkoyunlu・Ekanadham・Huberは、信頼できない通信路の上で二つの当事者が合意に達する問題を論じた³。この問題は、のちに二将軍問題と呼ばれるようになった。結論はこうだ。有限回のメッセージ交換で、確実な合意を保証するプロトコルは存在しない。確認応答そのものが失われうるからだ³。実際に失われる必要はない。著者らは、1つもメッセージが失われない場合でもやり取りは終わらないと注記している。同じ論文はもう一段踏み込み、タイムアウトを持つ分散システムでは、系が完全に信頼できるとしても完全な状態通知は提供できないことを示している³。操作は実行されたのに確認応答が失われたり遅れたりしうるという問題は、「少なくとも一度」と「厳密に一度だけ（exactly-once）」という実行意味論の区別を生んだ¹。

だからエージェントのツール呼び出しでも、タイムアウトを挟むかぎり、呼んだ側は操作が実行されたかどうかを完全には知りえない³。そこで現実のシステムは、少なくとも一度は届く（at-least-once）配送と、それを何度受け取っても安全にする冪等性を組み合わせる¹。冪等性キーが効くのはここで、リトライで重複が起きても実害を消せる。それでも重複した実行の試みそのものは起きるし、冪等性キーを持たないAPIでは同時のリトライが重複を生む隙間が残る¹。

Kalappurackal Mansoorらの研究には、どの部品が効いているかを切り分けた比較実験もある。顧客有効化タスクの中故障レベルだけを、本体とは別の設定で走らせたものだ。著者自身が、絶対値ではなく手法どうしの相対関係として読むべきだと断っている¹。そこでは、素の実装の成功率が約58%、事後条件の検証だけを足した場合が約80%、検証とリトライ前の再検証を組み合わせたフルの方式が約72%だった¹。重複した副作用のほうは、素の実装の約42%から検証だけで20%、フルで約28%に下がっている¹。著者らは後ろの二つを同程度と見ており、フルが検証だけを明確に下回ったとは読んでいない。彼らがこの実験から引き出す結論は、効いているのはリトライではなく検証のほうだ、というものである¹。リトライは本物の失敗を直せる一方で、重複や新たな故障の機会をもう一度作る。

これらの数字には、いずれも測定条件の限界が伴う。AgentChaosは、注入した故障で耐性を測る手法そのものが持つ課題を免れない。注入する故障が、本番環境で実際に起きる故障をどれだけ忠実に再現しているか、という課題である。著者らはこの点に先回りしている。故障の6タイプは応答のフィールド構造から演繹的に列挙したもので、手で選んだものではないと述べている²。そのうえで、APIエラー・接続タイムアウト・レート制限・応答形式の乱れが本番で最も多い故障だと報告する実証研究を挙げ、分類がそれらを覆っていると書いている²。ただし種類を網羅することと、本番で起きる頻度の分布を再現することは別である。この妥当性の論点は、システムコールレベルの故障注入を研究したZhangらのPhoebeが扱ったものである。PhoebeはLLMエージェントを対象にした研究ではないが、注入する故障の現実性が測定全体の前提になることを示している⁴。AgentChaos自身も、先に触れた実装1つずつという制約のほかに限界を挙げている。RAGベースのような新しいアーキテクチャは対象外で、成否はpass@1のみで測っており部分的な正しさや出力の質は見ていない。5システムはGoogle ADK上に著者らが再実装したもので、元の実装とは挙動が異なりうる（ただし故障ありなしの差分は妥当だとしている）。温度0.7で実行しているため試行ごとのばらつきがあり、設定によっては注入した故障の対象タスク数が少なく、まれに負の値も出ている²。Kalappurackal Mansoorらの研究も、制御されたシミュレータと手作りの事後条件検証器の上での2タスク・300実行にとどまり、本番のAPIそのものではない。古い状態の読み取りや認証失敗のような現実の故障モードを取りこぼしている可能性がある、と著者らは明記している¹。いっぽうで原典の p 値表（Figure 4）では、重複削減は6条件中4条件で有意（p<0.05）だった。有意だったのは、高故障率での両タスクと、請求書記録の低・中故障率である。顧客有効化の低・中故障率は p=0.05 と 0.06 で境界にある¹。

どの故障が最も厄介かという順位も、一つに定まっているわけではない。単著のReliabilityBenchは、Gemini 2.0 FlashとGPT-4o、ReActとReflexionという構成で4領域・1,280エピソードを評価した⁵。この研究は、最終状態が変わらない範囲でタスクの記述を揺らしている。Gemini 2.0 Flashでは、同義語の置換・日付書式の変更・制約の並べ替えという軽い摂動だけで、成功率は96.9%から88.1%へ落ちた⁵。気を散らす情報の注入とタスク途中での指示変更を重ねても、それ以上は下がらなかった（GPT-4oは95.0%から、軽い摂動で87.5%、重ねた段階で88.8%）⁵。この研究は、レート制限が最も損害の大きい故障タイプであり、複合的なストレス下ではReActの方がReflexionより頑健だったと報告している⁵。ただしレート制限の順位は、故障型ごとに80エピソードでの比較によるもので、ベースラインとの差は2.5ポイントしかない⁵。単独で入れた3型のうち2型（タイムアウトと部分応答）は、混合のベースラインより成績が良かった⁵。

いっぽうAgentChaosは、最悪の故障型について単一の答えを出していない。最も低下が大きい型はシステムごとに違い、AutoGen・MapCoder・EvoMACではタイムアウト、MADでは空応答とスキーマ、Mini-SEでは打ち切りだった。著者らはそのうえで、どれが最悪かは事前には予測できないと書いている²。2つの研究は測っている故障の区分も揃っていない（レート制限はAgentChaosの分類ではエラー応答に含まれる）。単一の順位表を鵜呑みにせず、自分のハーネスで測る理由がここにある。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。