AIエージェントを本番で運用し始めると、ツール呼び出しが静かに失敗し、エージェントが誤ったデータを事実として推論に使い続けるインシデントに直面する。LLM API の呼び出しは本番環境で 1〜5% の確率で失敗することが知られている。10ステップのツール呼び出しチェーンを持つエージェントでは、1 ステップあたり 2% の失敗率を仮定するだけで、1 タスクあたり少なくとも 1 回の障害に遭遇する確率は約 18%（1 − 0.98^10 ≈ 0.18）に達する。
従来のカオスエンジニアリングは CPU 注入・ネットワーク遮断・プロセスキルで有効性を証明してきたが、LLM ベースのエージェントは非決定論的な推論・セマンティック障害・権限逸脱という三つの軸で従来手法が通用しない。本記事では、エンタープライズのエージェント基盤チームが安全に障害を注入するための設計手順と実装パターンをまとめる。
なぜエージェントにカオスエンジニアリングが必要か
LLM API は本番で 1〜5% 失敗し、10 ステップのエージェントでは 18% のタスクが障害を経験する。従来の「クラッシュしなければ健全」という基準はエージェントに通用しない。
従来のサービスは「応答コード 200 ＝ 正常」と定義できる。ところがエージェントは HTTP 200 を返しながら意味的に誤った出力を生成する「サイレント障害」が存在する。ツール呼び出しがタイムアウトしたとき、エージェントが「存在しないデータを期待される形式で捏造する」事例が確認されており、ログにはエラーが残らない。
もう一つの問題は権限逸脱（Specification Drift）だ。障害からの回復中、エージェントは「合理的に見えるが意図された権限を超えた」行動を選択することがある。ポリシー決定ポイントが 5〜10 分間到達不能になると、エージェントは POLICY_CHECK_FAIL_MODE の設定に依存して安全側（fail-closed）または危険側（fail-open）へ振る舞いを変える。エンタープライズのエージェント基盤ではこの振る舞いを事前に注入テストで検証することが必須だ。
この課題は AIエージェントガバナンスの基盤設計とも直結する。サーキットブレーカーパターンとの組み合わせはエージェントのサーキットブレーカー設計を参照。
エージェント固有の6つの障害クラスとは
注入すべき障害は LLM API 障害・ツール失敗・コンテキスト劣化・カスケード伝播・権限逸脱・サイレント障害の 6 分類で整理できる。
研究と実運用のプレイブックを総合すると、エージェントに固有の障害は次の 6 クラスに分類できる。
1. LLM API 障害: HTTP 429（レート制限）・500/502/503（サーバーエラー）・タイムアウト・ストリーム中断。レート制限が最も影響が大きく、ベースラインから 2.5% の信頼性低下を引き起こすことが報告されている。
2. ツール呼び出し失敗: API エラー・マルフォームドレスポンス・タイムアウト。エージェントが結果を検証しない実装では、空の配列や不完全な JSON を正常データとして後続推論に渡す。
3. コンテキスト劣化: 長時間タスクではコンテキストウィンドウが埋まり、冒頭の制約指示が押し出される。エージェントは制約を「忘れた」まま推論を続ける。
4. カスケード伝播: マルチエージェントパイプラインでは、上流エージェントの誤出力を下流エージェントが信頼できる入力として処理する。1 ステップの障害が最終出力まで増幅される。
5. 権限逸脱: 障害回復の過程でエージェントが合理的に見えるが権限外の行動を選択する。ポリシーエンジンへの依存度が高い設計ほど fail-closed/fail-open の選択が重要になる。
6. サイレント障害: タスクは完了し HTTP 200 が返るが出力が誤り。オペレーショナルアラートが一切発火しない最も検知困難な障害モード。
障害注入の設計手順はどう組むか
仮説策定→ブラストラジウス制限→アボートガード設定→注入→観測→復旧測定の 6 ステップが基本手順だ。
ステップ 1: 仮説策定（Hypothesis First）
「このエージェントは LLM API が 30 秒タイムアウトしても、前回の有効な出力を返しながら graceful に再試行する」のような定量的な定常状態と許容劣化エンベロープ（例: タスク完了率 ≥ 95%）を注入の前に定義する。仮説なき注入は「何が崩れたかわからない」実験になる。
ステップ 2: ブラストラジウス制限
テストテナントのみに対象を絞り、本番トラフィックの最大 5% に注入を限定する。特定トピック × テストテナント × 5% トラフィックが推奨される初期値だ。
ステップ 3: アボートガード設定
注入前に中断条件を決める。例として「ディスパッチレイテンシが 5 分間 2 秒超」「失敗ジョブ率が 10% を超えた瞬間」などを Prometheus クエリで定義し、チームで rehearse しておく。
ステップ 4: 障害注入
LLM 障害には agent-chaos（OSS）のような専用ライブラリか、HTTP インターセプターで 429/503 を差し込む。ツール失敗はモック関数でマルフォームドレスポンスを返す。コンテキスト劣化は長い偽ドキュメントを注入してウィンドウを意図的に埋めることで再現できる。
ステップ 5: ガバナンス経路の観測
スループットだけでなく、ポリシー経路が正しく機能しているかを確認する。「孤立リプレイ数」「失効ジョブ数」「隔離レート」を定常状態メトリクスとして定義し、障害時の乖離幅を評価する。
ステップ 6: 復旧測定
障害が収束した後、孤立タスクが正しく再キューされ、監査証跡にすべての実験アクションが記録されているかを確認する。特に fail-closed 設定（ポリシー到達不能時にジョブをバイパスせず再キュー）が機能しているかを事後ログで検証する。
ガバナンス経路の検証——エンタープライズ特有の設計
ポリシー決定ポイントが 5〜10 分停止したとき fail-closed で安全側に倒れるかが、エンタープライズ実装で最も重要な検証項目だ。
大規模エージェント基盤では、実行権限がポリシーエンジン（OPA 等）に委譲されていることが多い。カオス実験でポリシーエンジンをアンリーチャブルにしたとき、次の二択を事前に確認する必要がある。
- fail-closed（安全側）: ジョブをバイパスせず再キューし、ポリシーエラーを監査ログに記録
- fail-open（危険側）: ポリシーチェックをスキップして処理を継続
製造・金融・医療などの規制業界では fail-closed がデフォルトになるべきだが、設定ミスで fail-open になっているケースが実装ギャップとして存在する。Kuu の RDE（Reinvention Deployed Engineering）サービスでは、ポリシー経路の検証をデプロイ前チェックリストに組み込み、本番投入前に fail-closed 挙動を保証するカオス実験を標準化している。
エンタープライズ実装のもう一つの要件は監査証跡の完全性だ。カオス実験で発生したすべてのアクション（注入・アボート・復旧）が改ざん防止済みの監査ログに記録されているかを確認する。詳細な設計は監査ログのスキーマ設計を参照。
参考
- Chaos Engineering for AI Agents: Injecting the Failures Your Agents Will Actually Face
- AI Agent Chaos Engineering Playbook: Safe Failure Injection in Production-Like Systems
- LLM-Powered Fully Automated Chaos Engineering — arxiv 2511.07865
まとめ
エージェントのカオスエンジニアリングは「本番で必ず起きる障害を、制御された環境で先に経験する」実践だ。LLM API の 1〜5% 障害率は、10 ステップ以上のエージェントでは無視できない複合リスクになる。
検証すべき 6 クラス（LLM API 障害・ツール失敗・コンテキスト劣化・カスケード伝播・権限逸脱・サイレント障害）をカバーし、fail-closed/fail-open の設定を事前に確認することで、ガバナンス経路の信頼性を本番前に証明できる。エンタープライズのエージェント基盤信頼性設計や、ポリシー経路の検証体制の標準化に課題がある場合は、Kuu の RDE サービスをご参照ください。