Skip to Content
Docs05. 運用AI システムのカオスエンジニアリング
上級reliabilitychaos-engineeringtesting更新: 2026-07-08この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

AI システムのカオスエンジニアリング

この記事の目的

「フォールバックが本当に動くか」を、事故が起きてからではなく意図的な障害注入で事前に検証する演習を設計・運用できるようになります。プロバイダー障害・モデルの劣化応答・ツール障害を計画的に起こし、「壊れても守られる」ことを確かめられる状態がゴールです。

対象読者

  • フォールバック・リトライを実装したが、それが本番で本当に発動するか確かめていないエンジニア・SRE
  • 外部プロバイダー依存の Agent で、障害時の挙動を事前に把握しておきたいテックリード

前提知識

本文

概要: 分担と「検証演習」という位置づけ

対象正本本記事
個別のリトライ・フォールバックの設計エラー処理・リトライ・フォールバック設計—
攻撃者視点のセキュリティ演習エージェントのレッドチーミング—
演習を実行する環境エージェント評価環境の構築—
発火後の対応手順インシデント対応—
障害注入による回復力の検証演習本記事注入対象・仮説設計・環境・定常化・還流

カオスエンジニアリング(chaos engineering)は、システムに意図的に障害を注入し、回復力を検証する実践です。備え自体の設計は エラー処理・リトライ・フォールバック設計 が、攻撃者視点のセキュリティ演習は エージェントのレッドチーミング が正本です。本記事は「信頼性(壊れても動くか)」を意図的な障害で検証する演習を扱います。SRE のカオス工学一般論は確立領域として、AI 固有の面に絞ります。

AI 固有の注入対象

一般的なインフラ障害(ノード停止・ネットワーク遅延)に加え、AI システムには固有の注入対象があります。

カテゴリ注入する障害
プロバイダーAPI 障害・レート制限(429)・レイテンシ急増・タイムアウト
モデル出力劣化した応答・不当な拒否・形式崩れ(壊れた JSON)・空応答
ツールツール障害・タイムアウト・想定外のエラー返却
知識源検索の空振り・知識源の欠落・古い情報の返却

これらは AI システムで実際に起きるのに、正常系のテストでは再現されません。「モデルが形式崩れを返したらパースが落ちる」「プロバイダーが 429 を返したらフォールバックが発動するはずが実は落ちる」を、注入して確かめます。

仮説駆動の演習設計

カオス演習は「とりあえず壊す」ではなく、仮説を立てて検証します(セキュリティのレッドチーミング脅威モデルを机上で終わらせず、実際に攻撃を試して防御の穴を見つける演習。エージェントでは有害な出力よりも、騙されたモデルが権限で有害な行動を取れるかに重心を置く。と同型の演習運営。エージェントのレッドチーミング)。

  • 仮説の形: 「X が落ちても Y が守られる」。例: 「主モデルが 429 を返しても、フォールバックモデルで応答が返り、成功率は 5% 以上落ちない」
  • 定常状態を定義する: 障害注入の前に「正常なら SLI がこの水準」を決めます(AI 品質の SLO 設計)。注入で SLI がどう動くかを見ます
  • 影響範囲を絞る: 最初は 1 つの障害を、小さな範囲で注入します。複数を同時に注入すると、何が原因か切り分けられません
  • 成功と失敗の基準を先に決める: 「フォールバックが発動し SLI が閾値内に収まれば合格、そうでなければ弱点発見」を演習前に定義します

実施環境の選択

障害注入は、いきなり本番でやりません。段階的に忠実度を上げます。

定常化: ゲームデーと自動注入

一度きりの演習は忘れられます。定常的に回すことで、劣化した回復力を検知し続けます。

発見の還流

演習の価値は、見つけた弱点を手順・設計の改善につなげることにあります。

実務での注意点

アンチパターン

  • フォールバックを実装したまま検証しない → 本番で初めて「実は発動しない」と分かり、障害が素通りする → 障害を注入して発動を事前に確かめる
  • AI 固有の障害(形式崩れ・拒否・空応答)を注入しない → 正常系テストをすり抜ける弱点が残る → プロバイダー・モデル・ツール・知識源の固有障害を注入対象にする
  • いきなり本番で障害注入する → ユーザーに実害が出る → 評価環境 → ステージング → 本番限定と段階的に上げる
  • 仮説なしで手当たり次第に壊す → 何を確かめたのか分からず、改善につながらない → 「X が落ちても Y が守られる」を仮説にして検証する
  • 一度演習して終わりにする → 回復力が劣化しても気づけない → ゲームデー・自動注入で定常化し、変更のたびに回す

チェックリスト

  • AI 固有の障害(プロバイダー・モデル出力・ツール・知識源)を注入対象にしている
  • 「X が落ちても Y が守られる」という仮説と成否基準を演習前に定義している
  • 定常状態(正常時の SLI 水準)を基準に、注入の影響を測っている
  • 評価環境から始め、段階的に忠実度を上げている(いきなり本番にしない)
  • 本番注入で副作用のあるツールを実行しない設計になっている
  • ゲームデー・自動注入で演習を定常化している
  • フォールバック・リトライの変更後に、発動をカオス演習で確認している
  • 見つけた弱点を手順改善と回帰スイートに還流している

関連トピック

参考資料

  • Principles of Chaos Engineering  — 仮説駆動・定常状態・影響範囲の限定というカオス工学の原則(本記事はこれを AI 固有の障害に適用)(アクセス日: 2026-07-08)

TODO・未確認事項

なし

AI 品質の SLO 設計常駐エージェントのライフサイクル管理