Chiehmin Weiは、AIを活用したインシデント管理プラットフォームIncidentFoxの共同創業者である。
午前3時。決済サービスがダウンする。エンジニアに呼び出しがかかり、ターミナルを開くと数秒で10のAIエージェントが並列で動き始める。1つはログを照会し、別の1つはデプロイ履歴を追跡し、さらに別の1つは依存サービス間のメトリクスを相関分析している。これは、AIコーディングエージェントを運用業務に導入している多くの企業で、すでに現実となっているオンコール対応の姿だ。
AIを活用したインシデント管理プラットフォームの共同創業者として、私はこの1年間、5人規模のスタートアップからFortune 500の大企業まで、さまざまなエンジニアリングチームと対話を重ねてきた。そこで見えてきたのは、あまり公に語られていないパターンである。すなわち、エンジニアリング組織における分散型の「スウォーム・インテリジェンス（群知能）」の台頭と、それが引き起こし得る調整の危機だ。
ボトムアップの革命
IT運用におけるAI（AIOps）の従来の通説はトップダウンだった。中央集権的なAIシステムを構築し、監視スタック（監視基盤）と統合し、アラートのトリアージを任せるという考え方である。AIOpsプラットフォーム市場は2028年までに320億ドルに達すると予測されており、既存プレイヤーの多くは中央集権的な知能に賭けている可能性が高い。
しかし私が見ているのは、多くのエンジニアがこうしたツールを迂回し、汎用のAIコーディングエージェントを選んでいる姿だ。Stack Overflowのソフトウェア開発者調査では、回答者の47%がAIツールを毎日使っていることがわかった。Sonarの調査でも、回答者は自分たちのコードの42%がAI生成、またはAI支援によるものだと述べている。
社内でAIによるサイト信頼性エンジニアリング（SRE）システムを構築するために数百万ドルを投じたにもかかわらず、社内のエンジニアによるボトムアップのエージェント採用に太刀打ちできなかったチームにも話を聞いた。理由は何か。権限モデルである。エンジニアがコマンドラインインターフェース（CLI）エージェントを実行すると、そのエンジニアがすでに持っているものすべてにアクセスできる。SSHキー、クラウドの認証情報、ダッシュボード、コードベース。別個の権限システムもアクセス申請もいらない。ただ動くのだ。
これは、典型的な企業導入の構図を反転させる。トップダウンの展開ではなく、エンジニアがボトムアップでエージェントを採用し、共有スキルリポジトリを通じて機能を共有する。あるエンジニアがマイクロサービスのデバッグ用スキルを書き、共有リポジトリにコミットすれば、全エンジニアのエージェントがそれを使えるようになる。
調整の危機
重大インシデントで5人のエンジニアが呼び出され、各人が5〜20のAIエージェントを起動したとしよう。本番環境で同時に最大100のエージェントが稼働する可能性がある。それぞれが異なるコードパスを探索し、異なる根本原因の仮説を生成する。
ここで、エージェントが変更まで行い始めたらどうなるか。あるエージェントはデプロイをロールバックし、別のエージェントは同じサービスでコミットの二分探索（bisect）を実行する。調整がなければ、群れは自らに逆らう形で動きかねない。
リスクは大きい。1,000人のITおよびビジネスリーダー、そして開発者を調査したPagerDutyの2026年レポートによると、組織の3分の2は重大インシデント時に1時間あたり30万ドル超を失っている。平均解決時間は15時間にまで増加した。調整の取れていないエージェントの群れがインシデントを増幅させれば、損失は甚大になり得る。
リーンチームのパラドックス
構造的なチームのリーン化へのシフトが、この課題をさらに深刻にしている。リーンチームは、AIで増強された開発によってより多くのコードと複雑性を出荷できる一方で、インシデント時に動けるエンジニアは少なくなることを意味する。
理論上は、各自がエージェントの群れを指揮する3人のエンジニアが、従来の30人チームに匹敵するかもしれない。しかし調整に伴うオーバーヘッドが消えるわけではない。形を変え、3人の人間がそれぞれ10のエージェントを管理する構図になるだけである。
レガシーシステムの課題
最後に、群れは組織のレガシーシステムに直面したとき壁にぶつかる。McKinseyによれば、Fortune 500のソフトウェアの70%は、20年以上前に開発されたとされる。
現代のクラウドネイティブなアーキテクチャで学習したAIエージェントは、メインフレームのバッチ失敗や、数十年前のデータベースにあるストアドプロシージャのデバッグで大きな摩擦に直面し得る。ドキュメントが、3年前に退職したエンジニアの記憶の中にしか存在しない場合、コンテキストウィンドウ（文脈の保持範囲）も助けにはならない。
企業ができること
これらの課題に対処するため、次の3つの能力が求められるはずだ。
1. 人間とエージェントの群れのためのリアルタイム共有コンテキスト：企業は、インシデントの進行中の状態を、すべてのエージェントが読み取れる機械可読で構造化された表現として構築することに取り組める。これはSlackチャンネルではなく、人間とエージェントが同時に参照し、同時に書き込めるものであるべきだ。社内で軽量に実現する方法の1つが、追記専用のイベントログである。共有のJSONLファイル、データベーステーブル、あるいはチームがすでに使っている任意のシステム上の構造化ドキュメントでよい。仮説の提示、実行したアクション、否定した原因に関する定義済みスキーマを備える。人間とエージェントは行動前にそれを読み、行動後に書き込むべきだ。そうすれば、参加者全員が同じ状態から開始し、すでに何が調査されたかを把握できる。
2. 調整プロトコル：企業が人間向けにインシデント指揮系統を整備するのと同様に、リーダーは、エージェントがどのように調査スレッドを引き受け、所見を報告し、相反するアクションを避けるかについてのプロトコルも確立すべきである。これはモデル能力の問題ではなく、システム設計の問題だ。
3. レガシーシステムのための深い文脈学習：次世代のAIインシデント対応の構築に取り組む企業が注力すべきはここである。すなわち、レガシーシステムを動かしている文書化されていない知識を学習し、インフラ向けの統合を生成するシステムを構築することだ。エージェントは、組織のインフラにおける文書化されていない側面を自律的に学習し、まだ存在しない統合を構築すべきである。これは私の会社が行っていることでもあり、エージェントがより大きな価値を提供する方法だと私は考えている。
これらの能力の実現を目指すリーダーにとって、第一歩はモデルそのものよりも、それを取り巻く運用基盤に注力することだ。インシデントデータ、サービスオーナーシップ、ランブック（運用手順書）、意思決定ログを標準化すれば、人間とエージェントが信頼できるコンテキストの供給源を持てる。次に、ログのトリアージや仮説トラッキングのような、狭く摩擦の大きいワークフローにエージェント支援を導入し、その後より自律的なアクションへと拡張していける。
最大の障害は、モデル能力そのものではなく、ツール群の断片化、権限の不整合、弱いドキュメンテーション、そしてレガシーシステムに閉じ込められた属人的知識である場合がほとんどだ。私の助言は、インシデントの1類型から始め、そこに関する知識を構造化し、エージェントのワークフローを本番システムのように扱うことである。バージョン管理し、監査し、重要局面で依存する前にテストする。これをうまく乗り越える組織は、まず調整とコンテキストを構築し、その上に自律性を積み上げていく。
インシデント対応の未来は、単一のAIが人間を置き換えることではない。人間とAIを、どちら単体でも到達できないスピードで連携させることにある。その調整レイヤーを構築できる企業は、優位性を得られるだろう。
