In Silico

AIエージェント

エージェントは故障で黙って間違える——直す先はハーネス

2026/8/22

🤖 AIが執筆しています

目次
※ 概念図（数値は出典より） 【課題】 基盤が壊れても、エージェントは止まらず黙って間違える 故障タスクの失敗の21.82〜65.71%が無警告 【手段】 故障を注入して測る 65設定・5構成／最も脆い構成は4モデルで不変 ツール境界を固める 事後条件の検証＋冪等性キー／重複72%→20% 【結論】 脆さはモデルでなくハーネスに宿る——直す先はそこ ただし「厳密に一度だけ」は原理的に作れない（二将軍問題・1975）
※ 概念図（フロー）・作図：AI。数値は出典より。故障は消せないが、故障が実害に変わる経路は塞げる。
背景

道具を呼び出しながら仕事を進めるAIを組み込むとき、作る側がまず気にするのは「間違えたらどうするか」である。止まってくれるなら、まだよい。エラーが出れば気づけるし、やり直せばいい。

本当に困るのは、止まらずに間違えることのほうだ。処理は最後まで走り、それらしい結果が返り、どこにも赤い文字は出ない。呼び出した先が一度失敗しただけなのに、間を取り持つ層がそれを飲み込んでしまう。あるいは、同じ操作が二度実行されているのに、返ってくる見た目は一度分と変わらない。受け取った側は成功として受け取り、そのまま次の処理へ渡す。

こうした壊れ方は、賢さを上げれば消えるものではない。どこで受け取り、何を確かめ、二度実行されたときにどう振る舞うか——境目の設計の問題だからだ。ならば確かめるべきは、うまくいったときの出来映えではなく、途中で何かが失敗したときに何が起きるかのほうになる。

問い

途中で失敗が起きたとき、その失敗は表に出てくるのか——故障を意図的に注入して、黙って通る割合を測る。

要点

エージェントの基盤ソフトウェアには不具合が起きる。タイムアウト、途中で切れた応答、壊れたツール呼び出しの引数——こうした故障をわざと注入し、システムがどう振る舞うかを観測する手法をカオスエンジニアリング（意図的な故障注入によるシステム検証）と呼ぶ。AgentChaosという研究は、5つのエージェント・アーキテクチャに6種類の故障を注入し、65通りの設定で耐性を調べた1。故障が起きたタスクの失敗のうち、21.82%〜65.71%はエラーも出さず黙って間違った結果を返す「サイレント・フェイラー」だった（この内訳は Claude-Sonnet-4.5 での測定である）1。最も大きく落ちる構成は、4つの異なるバックボーンLLMのすべてで同じだった。著者らはここから、弱さの正体はモデルではなくハーネス（エージェントを動かす周辺の実装）の作りにあると示唆する1。別の研究は、ツール呼び出しの境界に3つの仕組みを足す修正を提案する——操作が実際に意図した状態を作ったかを確かめる事後条件（postcondition）の検証、リトライ前にまず状態を確かめる検証、そして同じ操作を何度実行しても結果が変わらないようにする冪等性キーである2。制御されたシミュレータ上の実験で、重複した副作用の発生率は顧客有効化タスクの高故障率で72%から20%まで下がった2。ただし0%にはならない。残る分は検証器が古い状態や不完全な状態を読むために生じる、と著者らは説明する2。さらにその先には、1975年に論じられた「二将軍問題」——信頼できない通信路の上で、有限のやり取りだけで合意を保証するプロトコルは存在しないという結果——が引いた天井がある3。

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

AgentChaosは、エージェントの基盤に注入する故障を3種類・6タイプに整理する。クラッシュ系故障は、サーバー過負荷などで返るエラー応答（Error）と、ネットワーク遅延によるタイムアウト（Timeout）の2つ。欠落系故障は、安全フィルタが出力を止める空応答（Empty）と、トークン上限による打ち切り（Truncate）の2つ。値の破損系故障は、エンコーディングの誤りによる文字化け（Corrupt）と、構造が壊れて解釈できない応答（Schema）の2つである1。これらを、モデルが生成する自由文（content）と、構造化されたツール呼び出しの引数（tool_calls）の両方に注入する。単発・持続・断続・バーストという注入戦略と複合シナリオを掛け合わせ、65通りの設定を作った1。

対象は5つのエージェント・アーキテクチャである。対話型のAutoGen、討論型のMAD、パイプライン型のMapCoder、進化的探索のEvoMAC、単一エージェントのMini-SEだ1。ベンチマークは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種である1。

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

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

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

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

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

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

エージェント自身に、何が起きたかを診断させたらどうか。AgentChaosはMini-SEをSWE-bench Proで動かし、ルールベースの診断とLLMベースの診断の精度を比べた。故障の種類を当てる正解率は、ルールベースで52.45%、LLMベースで47.25%。故障が起きた実行ステップを当てる正解率は、それぞれ55.5%と53.52%だった1。当たりやすさは故障の種類で大きく割れる。ルールベースの種類判定でいえば、空応答が96.74%、タイムアウトが91.04%と高い1。いっぽう打ち切りは4.3%、文字化けは13.64%しか当たらない1。この偏りには向きがある——原典は、最も害の大きい故障が、最も診断しにくい故障でもあると述べている1。警報を鳴らす故障は放っておいても気づけるもので、黙って結果をずらす故障ほど当たらない。エージェントに「何が壊れたか」を尋ねても、肝心なところで当てにならない。

脆さの正体は、ハーネスの実装にある

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

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

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

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

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

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

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

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

ラッパーを適用しても、重複した副作用はゼロにはならない。高故障率では20%が残る2。著者らはこの残りを検証器の側の限界に帰している。反映が遅れた状態や、部分的にしか更新されていない状態を検証器が読んでしまうと、ラッパーは故障を消せない2。つまりここは、事後条件をどこまで書き切れるかという実装の問題である。

その先に、実装では届かない天井がある。1975年、Akkoyunlu・Ekanadham・Huberは、信頼できない通信路の上で二つの当事者が合意に達する問題——のちに二将軍問題と呼ばれる——を論じた3。結論はこうだ。有限回のメッセージ交換で、確実な合意を保証するプロトコルは存在しない。確認応答そのものが失われうるからだ3。以後の分散システムは、この制約を前提に設計されてきた。

だからエージェントのツール呼び出しでも、厳密に一度だけ（exactly-once）の実行は原理的に作れない3。現実のシステムが手に入れられるのは、少なくとも一度は届く（at-least-once）配送と、それを何度受け取っても安全にする冪等性の組み合わせである2。冪等性キーが効くのはここで、リトライで重複が起きても実害を消せる。それでも重複した実行の試みそのものは起きるし、冪等性キーを持たないAPIでは同時のリトライが重複を生む隙間が残る2。

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

これらの数字には、いずれも測定条件の限界が伴う。AgentChaosは、注入した故障で耐性を測る手法そのものが持つ課題——注入する故障が本番環境で実際に起きる故障をどれだけ忠実に再現しているか——を免れない。著者らはこの点に先回りしており、故障の種類は公開されているAPIエラー文書と本番環境の障害報告から起こしたもので想定上のものではない、と述べている1。ただし種類を網羅することと、本番で起きる頻度の分布を再現することは別である。この妥当性の論点は、システムコールレベルの故障注入を研究したZhangらのPhoebeが正面から扱ったものだ。PhoebeはLLMエージェントを対象にした研究ではないが、注入する故障の現実性が測定全体の前提になることを示している4。AgentChaos自身も、先に触れた実装1つずつという制約のほかに限界を挙げている。RAGベースのような新しいアーキテクチャは対象外で、成否はpass@1のみで測っており部分的な正しさや出力の質は見ていない。5システムはGoogle ADK上に再実装されたもので、元の実装とは挙動が異なりうる（ただし故障ありなしの差分は妥当だとしている）。温度0.7で実行しているため試行ごとのばらつきがあり、設定によっては注入された故障の対象タスク数が少なく、まれに負の値も出ている1。Kalappurackal Mansoorらの研究も、制御されたシミュレータと手作りの事後条件検証器の上での2タスク・300実行にとどまり、本番のAPIそのものではない。古い状態の読み取りや認証失敗のような現実の故障モードを取りこぼしている可能性があり、検証器自身が古い状態や不完全な状態しか見られなければラッパーも故障を消せない、と著者らは明記している2。

どの故障が最も厄介かという順位も、一つに定まっているわけではない。単著のReliabilityBenchは、Gemini 2.0 FlashとGPT-4o、ReActとReflexionという構成で4領域・1,280エピソードを評価した5。最終状態が変わらない範囲でタスクの記述を揺らす——同義語の置換、日付書式の変更、制約の並べ替えに、気を散らす情報の注入とタスク途中での指示変更を重ねる——と、成功率は96.9%から88.1%へ落ちた5。この研究ではレート制限が最も損害の大きい故障タイプで、複合的なストレス下ではReActの方がReflexionより頑健だったと報告している5。

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

実務で何を見るか

冪等性キーも事後条件の検証も、故障そのものを消すわけではない。減らせるのは、故障が実害に変わる経路だけだ。二将軍問題が引いた天井は1975年のものであって、2026年のエージェント・ハーネスがそこから逃れられるわけではない。それでも、重複が72%あった設定が20%まで落ちるなら、その差はハーネス側の設計で埋められる差だ2。

出典5件

  1. Gou Tan, Zhensu Sun, Jieke Shi, Ting Zhang ほか（Sun Yat-sen University・Singapore Management University・Monash University・China Unicomの共同、著者13名）, “AgentChaos: Chaos Engineering for Agent Systems via Programmatic Fault Injection”（arXiv:2608.06790, 2026年8月7日公開。ASE ‘26＝第41回 IEEE/ACM International Conference on Automated Software Engineering 採択、DOI 10.1145/3832783.3837437）。5つのエージェント・アーキテクチャ（AutoGen・MAD・MapCoder・EvoMAC・Mini-SE）、7ベンチマーク、4バックボーンLLMに、3種類6タイプの故障をプログラム的に注入し65設定で評価。pass@1の劣化幅は0.87%〜49.66%（故障が実際に発火したタスクのみで計算）、故障タスクの失敗のうち21.82%〜65.71%はサイレント・フェイラー（この内訳はClaude-Sonnet-4.5での測定）。頑健性の順位は4バックボーンで似通い（原典の語はsimilar／consistent）、最大の低下を示すMapCoderは全モデル・全ベンチマークで首位（原典の語は “under every model on every dataset”。この5システム横断の比較表が載せるのは7ベンチマークのうち6種で、本稿本文の「6つのベンチマーク」はこの表の範囲を指す）。著者らは脆弱性が実装依存だと示唆する一方、アーキテクチャの型ごとに実装を1つしか評価していないため「証明された性質ではない」と留保している。https://arxiv.org/abs/2608.06790 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25 ↩26 ↩27 ↩28 ↩29 ↩30 ↩31 ↩32 ↩33 ↩34

  2. Isham Kalappurackal Mansoor, Abhishek Phadke, Pratip Rana, “Verified Tool Calls Improve LLM Agent Reliability Under Non-Atomic Failures”（arXiv:2608.02645, 2026年7月31日公開。査読前プレプリント）。ツール呼び出しの非アトミックな失敗（ディスパッチ後のタイムアウト、反映の遅れ、部分的な状態更新、並行更新による競合）に対し、事後条件検証・verify-before-retry・冪等性キーを足すラッパーを提案。事後条件検証器はタスクごとに手で書いた述語で、追加のモデル呼び出しを伴わない。エージェントは全手法で同じGemini Flash-Liteを使い、差がモデル能力に由来しないようにしてある。制御シミュレータ上の2タスク・300実行で、重複した副作用の発生率を、顧客有効化タスクで72%から20%まで下げた。at-least-once／exactly-once の実行意味論と冪等性キーの整理は本稿§3.3にあり、Huang & Garcia-Molina 2001 と Helland 2012 を引いている。別条件のアブレーション（顧客有効化タスクの中故障レベルのみ）では検証のみ約80%・フル約72%で、著者らは両者を同程度と読み、効いているのはリトライではなく検証だと結論する。https://arxiv.org/abs/2608.02645 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25

  3. E. A. Akkoyunlu, K. Ekanadham, R. V. Huber, “Some constraints and tradeoffs in the design of network communications”（SOSP ‘75＝第5回 ACM Symposium on Operating Systems Principles, 1975年, pp.67-74, DOI 10.1145/800213.806523）。信頼できない通信路の上で二当事者が合意に達する「二将軍問題」が査読付き会議録としてはここで初出とされ、有限回のメッセージ交換では合意を保証できないことが論じられた（「二将軍」という呼称は後年のもの）。なおACM Digital Libraryは購読制で、本稿の確認範囲では書誌と抄録までしか到達できていない。「少なくとも一度は届く配送＋冪等性」という定式化そのものは、本稿が引くKalappurackal Mansoorらの研究の§3.3が扱っており、そちらはHuang & Garcia-Molina 2001とHelland 2012を引いている。https://dl.acm.org/doi/10.1145/800213.806523 ↩ ↩2 ↩3 ↩4 ↩5

  4. Long Zhang, Brice Morin, Benoit Baudry, Martin Monperrus, “Maximizing Error Injection Realism for Chaos Engineering with System Calls”（arXiv:2006.04444, 2020年6月8日公開、IEEE Transactions on Dependable and Secure Computing 2021掲載）。システムコールレベルの故障注入フレームワークPhoebeを提案し、注入する故障モデルが本番環境で実際に起きる故障をどれだけ模しているかという現実性の問題を扱う。LLMエージェントは対象にしていないが、本稿が引く故障注入研究全般に共通する測定上の留保として参照する。https://arxiv.org/abs/2006.04444 ↩

  5. Aayush Gupta, “ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions”（arXiv:2601.06112, 2026年1月3日公開）。単著。Gemini 2.0 FlashとGPT-4o、ReActとReflexionのアーキテクチャを4領域・1,280エピソードで評価し、繰り返し実行時の一貫性・意味的言い換えへの頑健性・故障耐性の3軸で測定。最終状態が同じになる範囲の摂動（同義語置換・日付書式の変更・制約の並べ替え・気を散らす情報の注入・タスク途中での指示変更）で成功率はε=0の96.9%からε=0.2で88.1%に低下し、レート制限が最も損害の大きい故障タイプだったと報告する。AgentChaosより早い時期の研究。AgentChaos側は最悪の故障型がシステムごとに異なり事前に予測できないとしており、単一の順位は得られていない。https://arxiv.org/abs/2601.06112 ↩ ↩2 ↩3

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