一言で言うと
エージェントは、与えられた情報の範囲では技術的に正しい行動を取ります。ただし、システム全体の状態を十分に知らないまま動くことがあります。この「正しい行動が、文脈の欠如によって連鎖的な障害を引き起こす」問題は、既存のポストモーテムのテンプレートに収まりにくく、記録されにくい。記録されない障害は、改善もされません。
何が起きているのか
現在、79%の組織が何らかのAIエージェントを本番環境に導入しています。Gartner（アメリカの調査会社）は、2028年までに企業向けソフトウェアの33%にエージェントAIが含まれると予測する一方、そのうち40%はリスク管理の不備で導入が見送られる、と警告しています。
この記事が注目するのは、その間にある問題です。動いていて、導入も取りやめられていないのに、静かに障害を生み出しているエージェントの話です。
典型的な障害パターンは次のとおりです。修復エージェントが、マイクロサービス（小さな機能単位に分かれたシステム）のレイテンシ（応答の遅れ）を検知し、サービスクラスタ（同じ機能を担うサーバー群）を再起動します。エージェントの判断自体は、技術的には正しいものです。
しかし、エージェントが知らなかったことがあります。ほかのサービスがピーク時間の処理中だったこと。共有のコネクションプール（複数のサービスが使い回す通信資源）が87%まで埋まっていたこと。データベースがバックグラウンドでインデックスの再構築（検索を速くするための整理作業）を走らせていたこと。
この状態で再起動が入ると、回復中のサービスへリクエスト（処理要求）が一斉に殺到します。レイテンシのスパイクを直そうとした結果、カスケード障害（一つの問題が次々と別の問題を引き起こす連鎖的な系統障害）になってしまう、という流れです。
AIインシデント（AI起因の事故）を記録するデータベースによると、報告件数は2024年から2025年にかけて21%増加しました。ただし、この数字は実態を下回っている可能性が高いです。障害はポストモーテムに「サービス再起動」「コネクション飽和」「レイテンシイベント」と記録され、起点がエージェントの行動だったことは残りにくいからです。
AI業界の文脈では
「エージェントのリスクはバグだ。テストして品質を上げてから本番に入れれば大丈夫」という見方は自然です。しかし、その見方は「エージェントのリスクは誤動作から来る」という前提に立っています。
その前提は、今崩れ始めています。
障害を起こしたエージェントは、必ずしも誤動作していたわけではありません。与えられた文脈の中では正しい判断をしたのです。問題は、その文脈が不完全だったことです。これはテストだけでは防ぎにくい。本番環境の状態は常に変わり、エージェントが見える範囲には限界があるからです。
ここで、カオスエンジニアリング（本番環境で意図的に障害を起こし、システムがどれだけ耐えられるかを確認する手法）との関係が見えてきます。人間のエンジニアがカオス実験を行うときは、必ず「今やって大丈夫か」という判断が入ります。エラー予算の消費速度（サービスの品質目標を、どれくらいの速さで使い切っているか）を確認し、依存するサービスが安定しているかを見る。完璧ではなくても、人間は「今このタイミングでやるか」を判断しています。
一方、自律修復エージェントには、この判断がありません。エージェントは異常を検知し、すぐ行動します。その行動は、事実上、カオスの注入（意図的な負荷や障害の投入）に近いものです。ただし、意図はなく、SLO（Service Level Objective: サービス品質目標）を確認せず、ほかのチームが同時に何をしているかも知らないまま実行されます。
私の見立て
この問題が静かに積み上がっている最大の理由は、「誰も悪くない」からだと見ています。
エージェントは正しく動いた。インフラは設計通りに動いた。それでもシステムが壊れたのは、全体の状態を誰も一元的に把握していなかったからです。「バグがあった → 修正する」という枠組みだけでは、対処しきれません。
情報の欠如という観点で見ると、エージェントが見ている状態と、システム全体の状態の間には、常にギャップがあります。このギャップは設計上の問題であり、エージェントをいくらテストしても埋まりません。システム全体のリアルタイムな状態を、エージェントの行動判断に組み込む仕組みが、別途必要になります。
もう一つ見落とされがちなのは、記録の構造です。ポストモーテムのテンプレートに「エージェントの行動」を記録する項目がない組織では、エージェント起因の障害は集計されません。データがなければ、リスクの大きさも見えません。エージェント導入を判断している経営層には、実際の障害コストが届いていない可能性が高いです。
著者が提案する「レジリエンス予算（システムが追加のストレスをどれだけ受け入れられるかを、共有の台帳で管理する考え方）」は、方向として正しいと思います。ただし、複数のチームが異なるエージェントを動かす大規模な組織で、この台帳をリアルタイムに維持するのは容易ではありません。まずは「エージェントがいつ・何を・どんな状態で実行したかを可視化すること」から始める方が、現実的です。
→ 何が変わるか: エージェントとカオスエンジニアリングのガバナンス（統制の仕組み）を別々に管理している組織では、「記録されない障害」が積み上がり続けます。エージェントの行動を監視するインフラが、従来のインフラ監視と同じ優先度で必要になっていきます。
→ 何をすべきか: 今週できる一歩は、直近の障害ポストモーテムを数件見直し、「エージェントの自律行動が関与していた可能性」を確認することです。テンプレートに記録されていなくても、タイムラインを見ると見えてくることがあります。エージェントの行動ログに「いつ・何を・どんなシステム状態で実行したか」を残す設計が、次の必須要件になります。 ---