連載ではこれまで、リトライ規律、提供元をまたぐフェイルオーバー、キルスイッチ、自動復旧（AI-SOAR）といった「壊れたときに効くはずの仕組み」を一通り作ってきた。だが、ここに一つ大きな穴がある。それらの仕組みが本番で本当に効くかを、誰も確かめていないことだ。
ネットワーク運用の現場では、冗長構成を組んだら切替試験をするのが当たり前だ。回線を抜き、ルーターを落とし、「設計どおりに副系へ切り替わり、想定時間内に戻るか」を保守時間帯に実際に確認する。確認していない冗長は、冗長ではなく”冗長のつもり”にすぎない。
ところがエージェントの現場では、この習慣がほとんど根付いていない。フェイルオーバーの設定は書いたが一度も発動させたことがない。キルスイッチは用意したが、押したら何秒で止まるのか誰も知らない。リトライ設定はSDKの既定値のまま。こうした状態で最初の”本番の障害”を迎えると、仕組みが効かないことを障害の最中に知ることになる。
本稿は、ツールのタイムアウト・429・壊れたツール応答・モデルの劣化・RAGの空振り・提供元のダウンといった障害を意図的に起こし、リトライ規律・フェイルオーバー・デグレード・キルスイッチが”本番で本当に効くか”を定期的に確かめる、エージェントの回復力テスト（カオスエンジニアリングとゲームデー）の設計をまとめる。想定読者は、エージェントを本番運用しているSRE・プラットフォームチーム・情シス、そしてAgentOpsの体制づくりを任された責任者だ。
本稿の位置づけ——”作る”の次は”壊して確かめる”
本稿は「障害」を扱うが、これまでの記事とは狙いが違う。混同しやすいので、先に線を引いておく。
| 記事 | 扱ったもの | 本稿との違い |
|---|---|---|
| AIレッドチーミング運用（8/22） | 悪意ある入力への耐性（セキュリティ） | 本稿は故障への耐性（信頼性）。攻撃者がいなくても起きる壊れ方を扱う |
| AgentOps②・評価（8/14） | 正常な動作の品質をどう測るか | 本稿は異常時にどう壊れるかを測る。平常時の正答率が高くても、壊れ方が悪ければ本番では事故になる |
| AgentOps⑧・インシデント運用（9/5） | 障害が起きた後の対応規律 | 本稿は障害が起きる前に、わざと起こして練習する。インシデント手順の”予行演習”にあたる |
| キャパシティ運用編（9/27）・緊急停止設計（8/9）・AI-SOAR（9/22） | リトライ規律・フェイルオーバー・キルスイッチ・自動復旧という仕組みを作る話 | 本稿はそれらを検証する話。作った仕組みの”効き目”を定期的に証明する |
一言でいえば、これまでの記事が「設計書」だとすれば、本稿は「試験成績書」をつくる回だ。
なぜエージェントには”障害試験”が必要なのか
“設計したはず”は、検証されるまで仮説にすぎない
フェイルオーバーやキルスイッチは、普段はまったく使われない経路だ。普段使われない経路ほど、設定の誤り・権限の不足・依存先の変更・手順の陳腐化が静かに積み上がる。副系のAPIキーが失効している、切替先モデルのプロンプトが旧版のまま、キルスイッチのフラグを読むコードがリファクタリングで消えている——こうした不具合は、障害が起きて初めて表に出る。
定期的に”使ってみる”以外に、普段使わない経路の健全性を確かめる方法はない。
エージェントは”エラーを返さずに”壊れる
従来のシステムと比べて、エージェントの障害には厄介な特徴がある。
- 失敗を取り繕う：ツールがタイムアウトしても、LLMは「取得できませんでした」と正直に言うとは限らない。それらしい値を推測で埋めて、タスクを”成功”として完了させることがある
- 劣化が連続的：ネットワーク機器のように「動く／止まる」の二値ではなく、品質がじわじわ下がる。モデルの挙動変化やRAGの検索精度低下は、HTTPステータスには現れない
- 非決定的：同じ障害を注入しても、毎回同じ反応をするとは限らない。1回の試験で「大丈夫だった」は証明にならない
- 多段で増幅する：1タスクで何十回もLLMやツールを呼ぶため、1か所の小さな障害がリトライ・再計画・再検索を通じて全体に波及する
つまりエージェントでは、「落ちたことに気づけるか」「落ちたときに正直に劣化するか」自体が試験対象になる。これは従来の障害試験にはなかった観点だ。
ネットワーク運用の「切替試験」から学ぶ
ネットワーク運用には、障害試験の長い蓄積がある。
- 冗長切替試験：主系回線を物理的に抜き、ルーティングが副系に収束するまでの時間と、パケットロスの量を測る
- 切り戻し試験：主系を戻したとき、フラップ（切替の往復）せずに安定して戻るかを確かめる
- 作業手順書（MOP）と中止基準：試験の前に「どの順で何をするか」「何が起きたら即中止して元に戻すか」を文書で決め、承認を取ってから実施する
- 保守時間帯と事前告知：影響範囲を限定し、関係者に知らせたうえで実施する
エージェントのカオスエンジニアリングは、これらをほぼそのまま持ち込める。違うのは、注入する障害の種類と、”正常”の定義の難しさだけだ。
カオスエンジニアリングの5原則をエージェントに当てはめる
カオスエンジニアリングは、Netflixなどで体系化された「本番環境で乱れた状況に耐えられるという確信を、実験によって築く規律」だ。その基本原則（Principles of Chaos Engineering）をエージェントに読み替えると、次のようになる。
| 原則 | 一般的な意味 | エージェントでの読み替え |
|---|---|---|
| 定常状態の仮説を立てる | システムの”正常”を、出力の指標で定義する | タスク成功率・p95所要時間・ツールエラー率に加え、「誤った成功」率（失敗を成功として報告した割合）を定常状態に含める |
| 現実の事象を変化させる | 実際に起こりうる障害を注入する | サーバー停止だけでなく、壊れたツール応答・モデルの劣化・RAGの空振りという”意味の障害”も注入する |
| 本番環境で実験する | 本番のトラフィックでしか見えない挙動がある | ステージングで十分に回してから、本番はカナリア（ごく一部のトラフィック）に限定して行う |
| 自動化して継続実行する | 一度きりではなく継続的に実験する | モデル更新・プロンプト変更・ツール追加のたびに壊れ方が変わるため、CIと定期ジョブに組み込む |
| 爆発半径を最小化する | 実験による影響を限定する | 対象テナント・エージェント・時間を絞り、中止条件と即時停止スイッチを実験側にも用意する |
特に1行目が重要だ。エージェントの定常状態を「エラー率」だけで定義すると、障害を取り繕って”成功”したタスクを見逃す。定常状態には必ず、正直さの指標を入れる。
障害カタログ——何を注入するか
最初に、注入する障害の一覧（障害カタログ）をつくる。ここでは、エージェント特有の障害を「インフラ系」と「意味系」の2つに分けて整理する。
インフラ系——”止まる・遅い・断られる”
| 障害 | 注入の方法（例） | 確かめたい仕組み | 期待する振る舞い |
|---|---|---|---|
| ツールのタイムアウト | ツール／MCPサーバーへのプロキシで応答を遅延させる | タイムアウト設定・リトライ規律 | 設定時間で打ち切り、リトライは1層だけ、上限回数で諦めて”取得できなかった”と報告する |
| 429（レート制限） | LLMゲートウェイで一定割合のリクエストに429とRetry-Afterを返す | バックオフ＋ジッター・リトライ予算・優先度キュー | Retry-Afterを尊重し、リトライが同期せず、優先度の高いタスクが先に通る |
| 応答の遅延（スローダウン） | LLM応答に数秒〜数十秒の遅延を加える | タスク全体のタイムアウト・デグレード | 全体の締め切りを守り、間に合わない場合は縮退モードに切り替える |
| 提供元のダウン | 主系プロバイダ宛てのリクエストをすべて5xxまたは接続失敗にする | フェイルオーバー・切り戻し | 決めた条件で副系に切り替わり、復旧後はフラップせずに段階的に戻る |
| 依存サービスの部分障害 | 特定のツールだけ、または特定リージョンだけを失敗させる | サーキットブレーカー・影響範囲の分離 | 壊れたツールだけが遮断され、他のツールを使うタスクは影響を受けない |
意味系——”動いているが、中身が壊れている”
| 障害 | 注入の方法（例） | 確かめたい仕組み | 期待する振る舞い |
|---|---|---|---|
| 壊れたツール応答 | JSONの欠損・型違い・空配列・想定外のエラーメッセージを返す | スキーマ検証・出力ガード | 検証で弾き、推測で値を埋めずに失敗として扱う |
| モデルの劣化 | 一部のリクエストを小型・旧版のモデルに差し替える、温度を上げる | オンライン評価・品質アラート | 品質指標の低下を検知し、アラートまたは自動切替が働く |
| RAGの空振り | リトリーバが0件または無関係な文書を返す | 根拠なし時の応答方針 | 「根拠が見つからない」と明示し、捏造した回答を返さない |
| 古いデータの混入 | インデックスに期限切れの文書を混ぜる | 鮮度チェック・出典表示 | 日付の古い根拠を識別し、注記または除外する |
| ツールの”成功したふり” | 200 OKを返すが、実際には処理していない | 事後検証（読み戻し確認） | 書き込み系ツールの結果を読み戻して確認し、不一致を失敗として扱う |
意味系の障害は、従来のカオスエンジニアリングツールがあまり想定していない領域だ。しかしエージェントの本番事故の多くは、こちらで起きる。インフラ系で「止まり方」を、意味系で「正直さ」を試すと覚えておくとよい。
注入の仕組み——どこに”蛇口”をつけるか
注入ポイントは4か所
障害を注入する場所は、エージェントと外部の境界に置くのが基本だ。エージェント本体のコードに障害注入のロジックを書き込むと、本番コードが汚れ、切り忘れの事故も起きやすい。
- LLMゲートウェイ：全エージェントのLLM呼び出しが通る共通ゲートウェイで、429・5xx・遅延・モデル差し替えを注入する。キャパシティ編で導入したゲートウェイがあれば、そのまま注入点になる
- ツール／MCPプロキシ：ツール呼び出しの手前にプロキシを置き、タイムアウト・壊れた応答・成功したふりを注入する。TCPレベルの遅延や切断であれば、Toxiproxyのような汎用ツールも使える
- リトリーバ（RAG）：検索結果を0件にする、無関係な文書に差し替える、古い文書を混ぜる
- クラウド基盤：AWS Fault Injection Service（FIS）やAzure Chaos Studioなどのマネージドサービスで、インスタンス停止・ネットワーク遅延・リージョン障害を起こす
注入は”対象を絞って、印をつけて”行う
注入の設定には、必ず次の3つを持たせる。
- 対象の絞り込み：テナント・エージェント・リクエストヘッダー・トラフィックの割合で対象を限定する
- 実験IDの付与：注入したリクエストのトレースに実験ID（例：
chaos.experiment_id）を属性として付ける。これがないと、観測ダッシュボード上で「実験による失敗」と「本物の障害」を区別できない - 有効期限：注入設定には必ず終了時刻を持たせ、消し忘れても自動で無効になるようにする
ネットワーク運用でいえば、試験用のACLやルートマップに「試験後に必ず削除」と書いておくのと同じだ。消し忘れた試験設定が本番障害の原因になる、という事故は昔から繰り返されてきた。
実験の設計——仮説・定常状態・爆発半径・中止条件
実験カードをつくる
一つひとつの実験は、実施前に「実験カード」として文書化する。ネットワーク運用の作業手順書（MOP）にあたるものだ。
| 項目 | 記入例 |
|---|---|
| 実験名 | 主系LLM提供元の全面ダウン時のフェイルオーバー |
| 仮説 | 主系が5xxを返し続けた場合、切替条件を満たしてから所定時間内に副系へ切り替わり、P0タスクの成功率は定常状態から大きく下がらない |
| 定常状態の指標 | タスク成功率、p95所要時間、誤った成功率、切替までの時間 |
| 注入する障害 | LLMゲートウェイで、主系宛てリクエストの100％に503を返す |
| 対象（爆発半径） | ステージング環境の全エージェント／本番では社内向けエージェントのトラフィック5％ |
| 実施時間 | 30分（注入15分＋切り戻し観察15分） |
| 中止条件 | 対象外のトラフィックでエラー率が上がった、P0タスクの成功率が許容値を下回った、副系のコストが想定を超えた |
| 中止手順 | 注入フラグを無効化 → 切替状態を手動で主系に戻す → 関係者に通知 |
| 担当・承認 | 実施者、安全責任者、承認者 |
| 結果と対応 | 仮説どおりか、ずれた点、修正チケット |
定常状態は”正直さ”まで含める
実験中に見る指標は、次の5つを基本にする。
- タスク成功率：実際に目的を達成したタスクの割合（評価編②のゴールデンセットや自動判定で測る）
- p95所要時間：遅くなっても締め切り内に収まっているか
- リトライ率・429率：リトライが増幅していないか
- 誤った成功率：失敗したのに成功として報告したタスクの割合。本稿で最も重要な指標
- 正直な失敗率：「できなかった」と正しく報告したタスクの割合。障害時にはこちらが増えるのが正しい
障害を注入したとき、成功率が下がること自体は問題ではない。問題なのは、成功率が下がらないのに中身が壊れていること、つまり誤った成功率が上がることだ。
段階を踏んで本番に近づける
- ローカル・CI：モックの提供元・ツールに障害を仕込み、単体の振る舞い（タイムアウト処理、スキーマ検証）を確かめる
- ステージング：本番に近い構成で、障害カタログを一通り流す。ここで大半の問題が見つかる
- 本番シャドー：本番トラフィックを複製し、結果をユーザーに返さない環境で実験する
- 本番カナリア：社内向けや影響の小さいタスクに限定し、ごく一部のトラフィックで実施する
いきなり本番で試す必要はない。ただし、ステージングだけで終わらせると「本番の設定だけ違っていた」という事故を見逃す。最終的には本番で、小さく確かめる。
確かめるべき6つの問い——仕組みごとの合格基準
これまでの連載で作ってきた仕組みごとに、「何を注入し、何が起きれば合格か」を決めておく。
| 仕組み | 問い | 注入する障害 | 合格基準の例 |
|---|---|---|---|
| リトライ規律 | リトライは輻輳を増幅していないか | 429を一定割合で返す、応答を遅延させる | リトライする層が1つだけ、リトライ予算内に収まる、リトライ要求が同期して波にならない |
| フェイルオーバー | 決めた条件で切り替わり、きちんと戻るか | 主系提供元のダウン、部分的な5xx | 切替条件どおりに発動、切替後のP0タスクが通る、復旧後にフラップせず段階的に戻る |
| デグレード（縮退） | “正直に”劣化するか | ツール停止、RAGの空振り、遅延 | 縮退モードであることを利用者に明示し、推測で埋めた回答を返さない |
| キルスイッチ | 押したら、時間内に、全部止まるか | 実験中にキルスイッチを実際に発動する | 目標時間内に新規タスクの受付と実行中タスクの外部書き込みが止まる、停止を監査ログで確認できる |
| 自動復旧（AI-SOAR） | 正しく直し、誤作動しないか | 自動復旧の対象障害と、対象外の紛らわしい障害の両方 | 対象障害では手順どおりに復旧し、対象外では手を出さずに人へエスカレーションする |
| 観測とアラート | 気づけるか、正しい人に届くか | 上記すべて | アラートが所定時間内に鳴り、オンコール担当に届き、ダッシュボードで原因の層が特定できる |
見落とされがちなのがキルスイッチだ。緊急停止の仕組みは「押さないこと」が前提のため、最も試されていない仕組みになりやすい。しかし、押すべき場面で効かなければ、あらゆる対策のなかで最も被害が大きくなる。キルスイッチは、定期的に実際に押す。これを運用規律として決めておく。
もう一つは自動復旧の誤作動だ。AI-SOARのような自動復旧は、対象の障害を直せるかと同じくらい、対象外の障害に手を出さないかが重要になる。紛らわしい障害を混ぜて注入し、自動復旧が”余計なこと”をしないかを確かめる。
ゲームデー——仕組みではなく”人と手順”を試す
自動化された障害注入が仕組みを試すものだとすれば、ゲームデーは人と手順を試すものだ。障害を起こし、オンコール担当が実際に検知・判断・対応する流れを、時間を区切って練習する。インシデント運用⑧で定めたSEV定義・エスカレーション・封じ込め手順は、ゲームデーで一度通して初めて”使える手順”になる。
役割を決める
| 役割 | やること |
|---|---|
| ゲームマスター | シナリオを設計し、障害を注入し、進行を管理する。対応チームには詳細を事前に明かさない |
| 対応チーム | 普段のオンコール手順どおりに検知・判断・対応する |
| 観察者（記録係） | 時刻・判断・迷った点・手順書と実際のずれを記録する |
| 安全責任者 | 本番への想定外の影響を監視し、中止条件を満たしたら即座に止める権限を持つ |
進行の例（半日）
| 時間 | 内容 |
|---|---|
| 0:00〜0:15 | 開始宣言、目的と中止条件の共有、関係部署への告知確認 |
| 0:15〜1:15 | シナリオ1：主系提供元のダウン。検知から切替・切り戻しまで |
| 1:15〜2:15 | シナリオ2：ツールが”成功したふり”をする。誤った成功に気づけるか |
| 2:15〜2:45 | シナリオ3：キルスイッチの発動。判断から停止確認まで |
| 2:45〜3:30 | 振り返り。記録をもとに、手順・仕組み・観測の不足を洗い出す |
シナリオは”複合障害”まで育てる
最初は単一の障害から始める。慣れてきたら、現実の障害に近い複合シナリオに進む。
- 主系提供元が遅延しているところに、ピーク時間帯の429が重なる
- フェイルオーバー先の副系で、RAGのインデックスが古い
- 障害対応の最中に、オンコール担当の主担当に連絡がつかない
本物の障害は、たいてい「想定した障害が、想定していない組み合わせで」起きる。ゲームデーの価値は、その組み合わせを安全な場で先に経験できることにある。
振り返りを”還流”させる
ゲームデーの振り返りは、インシデントのポストモーテムと同じ形式で書き、同じ場所に保管する。そのうえで、見つかった問題を次の3か所に戻す。
- 仕組み：リトライ設定・切替条件・スキーマ検証などの修正チケット
- 手順書（ランブック）：実際の対応と手順書のずれを修正する
- 評価セットと障害カタログ：ゲームデーで見つかった壊れ方を、評価ケースと自動実験に追加する
インシデント運用⑧で述べた「ポストモーテムを評価フライホイールへ還流する」流れに、ゲームデーを入口として加えるイメージだ。本物の障害を待たずに、フライホイールを回せる。
定期化——”一度やった”で終わらせない
エージェントは、モデル更新・プロンプト変更・ツール追加・提供元の仕様変更のたびに壊れ方が変わる。一度の試験で得た確信は、次の変更で失効する。そのため、回復力テストは頻度の違う複数の層で定期化する。
| 頻度 | 内容 | 主な目的 |
|---|---|---|
| デプロイごと | CIでモックに障害を注入する軽量テスト（タイムアウト・壊れた応答・429） | 基本的な壊れ方の退行を防ぐ |
| 週次 | ステージングで障害カタログを自動で一巡 | 仕組み全体の健全性を確認する |
| 月次 | 本番カナリアでの実験（フェイルオーバー・キルスイッチを含む） | 本番の設定と権限で効くことを確認する |
| 四半期 | ゲームデー（複合シナリオ） | 人と手順を試し、組織としての対応力を上げる |
| 変更時（随時） | モデル移行・提供元追加・大きなツール追加の前後に対象を絞った実験 | 変更による壊れ方の変化を確認する |
頻度はあくまで目安だ。規模の小さいチームであれば、CIの軽量テストと四半期のゲームデーから始めれば十分に効果がある。
回復力スコアカードで”効き目”を記録する
実験の結果は、仕組みごとに「最後に検証した日」と「結果」を一覧にしておく。
- フェイルオーバー：最終検証日、切替時間の実績、合否
- キルスイッチ：最終検証日、停止までの時間の実績、合否
- リトライ規律・デグレード・自動復旧・アラート：同様
「最終検証日が古い仕組み」は、それだけでリスクだ。スコアカードを経営層やリスク管理部門への報告に含めておくと、「対策はある」ではなく「対策が効くことを、いつ確認したか」を説明できるようになる。
よくある落とし穴
- ステージングだけで満足する：本番とステージングでは、APIキー・クォータ・権限・切替条件の設定が違うことが多い。最後は本番で小さく確かめる
- 成功率しか見ない：障害を取り繕った”成功”を見逃す。誤った成功率を必ず定常状態に入れる
- 1回で判断する：エージェントは非決定的だ。同じ実験を複数回流し、結果のばらつきも含めて評価する
- 実験に印をつけない：実験IDがないと、アラートが鳴ったときに実験か本物か区別できず、現場が混乱する
- 注入設定の消し忘れ：有効期限を必ず設定する。手動の削除に頼らない
- 見つけた問題を直さない：実験の目的は”弱点の発見”ではなく”弱点の解消”だ。修正チケットの消化までを実験の完了条件にする
- 告知なしで始める：関係部署に知らせずに障害を起こすと、信頼を失い、以後の実験が続けられなくなる。まずは告知ありで始め、慣れてから抜き打ち形式を検討する
回復力テスト・チェックリスト
| 分類 | チェック項目 |
|---|---|
| 準備 | 障害カタログ（インフラ系・意味系）を作成している |
| 準備 | 定常状態の指標に「誤った成功率」を含めている |
| 注入 | 注入点がエージェント本体の外（ゲートウェイ・プロキシ・リトリーバ・基盤）にある |
| 注入 | 注入リクエストに実験IDを付け、観測上で区別できる |
| 注入 | 注入設定に有効期限がある |
| 安全 | 実験ごとに実験カード（仮説・対象・中止条件・中止手順）がある |
| 安全 | 中止権限を持つ安全責任者を決めている |
| 検証 | リトライ規律・フェイルオーバー・デグレード・キルスイッチ・自動復旧・アラートのそれぞれに合格基準がある |
| 検証 | キルスイッチを定期的に実際に発動している |
| 検証 | 自動復旧が”対象外の障害”に手を出さないことを確かめている |
| 人と手順 | 四半期程度でゲームデーを実施している |
| 人と手順 | 振り返りを仕組み・手順書・評価セットに還流している |
| 定期化 | CI・週次・月次・変更時の実験が組み込まれている |
| 定期化 | 回復力スコアカードで仕組みごとの最終検証日を管理している |
よくある質問（Q&A）
Q1. 本番でわざと障害を起こすのは、危険ではないですか？
危険を管理したうえで行うのがカオスエンジニアリングだ。ステージングで十分に回し、本番では対象を小さく絞り、中止条件と即時停止の手段を用意してから実施する。「本番で試さないリスク」、つまり本物の障害のときに初めて仕組みが効かないと知るリスクと比べて判断してほしい。
Q2. AIレッドチーミングをすでにやっています。それとは何が違うのですか？
レッドチーミングは「悪意ある入力に対して、エージェントが誤った行動をしないか」を試すセキュリティの検証だ。本稿の回復力テストは「依存先が壊れたとき、エージェントが正しく壊れるか」を試す信頼性の検証だ。攻撃者がいなくても障害は起きるため、両方が必要になる。
Q3. 小規模なチームです。どこから始めればよいですか？
まずは3つで十分だ。①ツールのタイムアウトと壊れた応答をCIでモック注入する、②ステージングで提供元ダウンを起こしてフェイルオーバーを一度発動させる、③キルスイッチを一度実際に押して停止までの時間を測る。この3つだけでも、多くのチームで”効かない仕組み”が見つかるはずだ。
Q4. 専用のカオスエンジニアリングツールは必要ですか？
必須ではない。エージェント特有の障害（429・壊れたツール応答・RAGの空振り・モデル差し替え）は、LLMゲートウェイやツールプロキシに数十行の注入ロジックを足すだけで再現できることが多い。インスタンス停止やネットワーク障害など基盤レベルの実験には、AWS FISやAzure Chaos Studioなどのマネージドサービスが便利だ。
Q5. エージェントは非決定的なので、同じ実験でも結果が毎回違います。どう判定すればよいですか？
1回の成否ではなく、複数回実行したときの分布で判定する。たとえば「同じ実験を一定回数流し、誤った成功が一度も出ないこと」「P0タスクの成功率が許容値を下回らないこと」のように、統計的な合格基準を置く。評価編②で扱った評価の考え方を、そのまま異常時に適用するイメージだ。
まとめ——”効くはず”を”効いた”に変える
リトライ規律・フェイルオーバー・キルスイッチ・自動復旧は、普段は使われない経路だ。使われない経路ほど、静かに壊れていく。そしてエージェントは、壊れたことを取り繕って”成功”を報告することがある。だからこそ、壊れる前にわざと壊し、効き目を確かめ続ける規律が要る。
- 障害カタログで”何を壊すか”を決める：タイムアウト・429・提供元ダウンといったインフラ系に加え、壊れたツール応答・モデルの劣化・RAGの空振りといった意味系の障害を注入し、「止まり方」と「正直さ」の両方を試す
- 実験カードで”安全に壊す”：仮説・定常状態（誤った成功率を含む）・爆発半径・中止条件を事前に決め、注入はエージェントの外側で、実験IDと有効期限つきで行う
- 定期化と還流で”効き目を保つ”：CI・週次・月次・ゲームデーの層で回し、キルスイッチは実際に押し、見つかった弱点を仕組み・手順書・評価セットに戻す
ネットワーク運用の世界では、「切替試験をしていない冗長は冗長ではない」というのが常識だ。エージェントの運用も同じだ。”設計したはず”の仕組みを、”本番で効いた”と言える仕組みへ。回復力は作るものではなく、確かめ続けることで維持するものだ。
関連記事
- 【AgentOps・キャパシティ運用編】”動くのに、混むと止まる”を越える
- 【2026年版】AI-SOAR／自己回復（Self-Healing）実践ガイド
- 【AgentOps⑧・連載完結】”落ちない前提”を捨てる——非決定的エージェントのインシデント運用規律
- 【2026年版】AIレッドチーミング運用ガイド——”守った気になる”を検証する
- 【AgentOps②・評価】”測れる”の前に”何で測るか”
- 【2026年版】AIエージェントの「緊急停止・被害範囲最小化」設計ガイド
- 【AgentOps・モデル運用（ModelOps）編】”選んで終わり”にしない
- 【AgentOps・ツール運用編】”つないで終わり”にしない
- 【連載⑫】企業AI導入「つまずき」解決シリーズ——「AIが止まると業務が止まる」問題
参考リンク
- Principles of Chaos Engineering
- Google SRE Book｜Testing for Reliability
- Google SRE Book｜Addressing Cascading Failures
- AWS｜What is AWS Fault Injection Service?
- Microsoft Learn｜Azure Chaos Studio とは
- Shopify｜Toxiproxy（GitHub）
- AWS Builders’ Library｜Timeouts, retries, and backoff with jitter
※本記事は2026年9月時点の公開情報および一般的な運用手法に基づく情報提供であり、特定の製品・サービスの動作や、記載した手法による障害の防止を保証するものではありません。本番環境での障害注入は、自社の変更管理・承認プロセスに従い、影響範囲と中止手順を確認したうえで実施してください。記載した頻度・時間・指標は目安であり、システムの規模や業務要件に応じて調整してください。
コメント