近年、クラウドサービスの拡張とAI技術の進化に伴い、企業インフラにおける自動化が加速しています。しかし、AIエージェントが実際に動作している現場では、見えない「Chaos」が潜んでおり、数多くのインシデントが未分類のまま蓄積されています。実際、Gartnerの調査では 2026 年までに全企業の 79% が AI エージェントを本番環境で運用し、さらに 96% が拡張計画を持っていると報告されています。そこで本稿では、AI エージェントが引き起こす見えない Chaos とそれに対処するための実務的手法を解説します。
AIエージェントとChaos Engineeringのギャップ
従来の Chaos Engineering は、エンジニアが手動で実験を設計し、SLO バーンレートやダッシュボードを確認した上で実行します。その判断は「人間の直感」に基づくもので、実験のタイミングと範囲が人間の目で調整されます。対照的に、AI エージェントは「観測した異常を即座に処理」するように設計されており、SLO バーンレートやダッシュボードを参照せずにアクションを実行します。結果として、エージェントが行う再起動やトラフィックリダイレクトなどの Chaos イベントは、予測できない影響を生むことがあるのです。
典型的な失敗シナリオ
- マイクロサービスのレイテンシ上昇を検知したエージェントが、サービスクラスタを再起動
- 同時にピーク時のトラフィックを処理中の他サービスや共有接続プールの 87% 使用率、データベースのインデックス再構築が進行中
- 再起動により「thundering herd」現象が発生し、システム全体の障害が拡大
このように、AI エージェントは自らが「Chaos インジェクター」として機能することを前提に設計されていないため、インフラ全体のバランスを考慮した判断が欠けてしまいます。
見えないインフラリスクの実態
AI 関連インシデントは 2025 年に 21% 増加しましたが、実際にはエージェントのアクションが原因であるケースが大多数です。多くの組織ではインシデント分類に「AI エージェント起因」というカテゴリが存在せず、再起動や接続プールの飽和といった表面的な症状で閉じてしまいます。このため、インフラに潜むリスクは「見えないまま」蓄積され、次の大規模障害へとつながります。
また、従来の Chaos Engineering は「静的閾値」に依存しているため、インシデントが発生した時点でのリソース余剰量をリアルタイムで把握できません。結果として、エージェントが処理できる「吸収容量」が明確に定義されていない状態でアクションが実行されると、予期せぬ cascading failure が発生します。
吸収容量（Resilience Budget）の導入とAIアクションの統合
吸収容量を「継続的に再計算される消費可能なリソース」と捉えることで、Chaos Engineering と AI エージェントを同じフレームワークに統合します。Resilience Budget は以下の4つのライブシグナルを基に算出されます。
- SLO バーンレート：月間エラー予算消費率を直接反映
- P99 レイテンシトレンド：直近 40 分間の傾向を重視
- 依存関係の飽和状態：接続プールやデータベースの利用率
- アプリケーション挙動信号：セッション完了率や API 呼び出しパターンの変化
このバジェットは「消費可能なリソース」として扱われ、Chaos 実験やエージェントアクションが行われるたびに消費されます。複数チームが同時に実験を行う環境でも、バジェットが共有されることで予期せぬ blast radius の重複を防ぎます。
LLMを使ったハイパー化と限界
最近では LLM を活用し、依存関係グラフやインシデントポストモーテムから Chaos 仮説を自動生成する試みが進んでいます。LLM は「よくある失敗パターン」を高速に抽出できますが、以下の限界があります。
- 依存関係グラフの古さ：最新のサービス追加やライブラリ変更を反映していない
- モデルレベルのガードレールの不十分さ：Fine-tuning 攻撃に耐えないケースが多い
- 実行意思決定の欠如：オンコール体制や顧客 SLA など、モニタリング外の情報を考慮できない
したがって、LLM は「仮説生成ツール」としては有用ですが、実際のアクションを決定する段階では人間の判断が不可欠です。
ガバナンス実装の実務ステップ
AI エージェントを安全に運用するための 5 段階ガイドラインを提示します。
ステップ1：既存エージェントの棚卸
全てのインフラに触れるエージェントをリストアップし、アクション内容とトリガー条件を明文化します。
ステップ2：Resilience Budget との統合
各エージェントに対し、SLO バーンレートやレイテンシトレンドを参照する「バジェット門」を設置します。バジェットが閾値を下回った場合、エージェントは待機またはエスカレーションを行います。
ステップ3：アクションを実験として記録
エージェントがサービスを再起動した場合、その影響範囲を Chaos データとしてバジェットにフィードバックします。これにより、次回の判断に活用できます。
ステップ4：人間に委譲する曖昧ケース
バジェットスコアが不明瞭な場合、最近のデプロイやオンコール体制の変化などを考慮し、実行決定を人間に委ねます。
ステップ5：継続的な検証と更新
依存関係グラフや SLO 目標の変更があれば、バジェット算出ロジックを再構築し、エージェントの行動ルールを更新します。
このプロセスを継続的に実行することで、AI エージェントは「Chaos インジェクター」としてではなく、インフラの「耐久力」を補完するツールとして活用できます。
まとめ：安全に運用するためのポイント
AI エージェントが引き起こす見えない Chaos は、現在のインフラ運用における最大のリスクの一つです。安全に運用するためには、以下のポイントを押さえることが重要です。
- AI エージェントは「Chaos インジェクター」として扱い、Resilience Budget に組み込む。
- エージェントのアクションは常に人間が監視できる状態にし、必要に応じてオーバーライドできる仕組みを設ける。
- LLM を仮説生成に利用する際は、最新の依存関係データと組み合わせ、実行意思決定は人間に委譲する。
- 継続的にバジェットとガバナンスルールをレビューし、インフラの変化に即応できる体制を構築する。
こうした取り組みを踏まえることで、AI エージェントを活用しつつ、インフラの堅牢性を維持し、予期せぬ障害を未然に防ぐことが可能になります。今後の DX 推進において、AI と Chaos Engineering を統合したガバナンスは必須の要素となるでしょう。
