昨今の生成AI技術の進化は、システム開発の現場に大きな変化をもたらしている。これまでエンジニアが手作業で実施していたコーディングの大半をAIエージェントが担うようになり、アプリケーション開発のスピードは大きく向上した。

　この変化は、開発チームの構造にも影響を与え始めている。大人数で要件を定義してシステムを構築する従来の手法から、AIに適切な指示を与えられる2、3人の少数精鋭チームが中心になるのではないかとの見方もある。

　また、これまでプログラミングの専門知識を持つエンジニアが担っていた開発業務が、ビジネス部門などの非エンジニア層に広がる「開発の民主化」も進みつつある。今後、開発されるアプリケーションが増えれば、開発フェーズの比重は相対的に下がっていく可能性がある。

AIエージェントによる開発の高速化と、開発チームやアプリケーション数に生じる変化（講演動画から抜粋）

　「『人間が書くコードは2025年に死に、コードレビューは2026年に死ぬ』という予測があるように、開発はAIによって飛躍的に高速化しています。しかし、AIにレビューをさせれば障害が防げるかといえば、決してそうではありません。システム障害の大部分はデプロイによって引き起こされるため、開発サイクルの高速化は必然的にインシデントの増加を招きます」

　こう語るのは、PagerDutyの草間一人氏（Product Evangelist）だ。同氏によると、開発サイクルの高速化とアプリケーションの増加は、その後の運用フェーズに新たな課題をもたらすという。デプロイの頻度が増えれば、運用担当者が対処すべきインシデントの発生件数も増えていく。

　一部の開発現場では、コードレビューをAIに任せることでシステム障害を大幅に減らせるのではないかとの期待もある。これに対し、草間氏は次のように指摘する。

　「たとえAIでコードレビューを行っても、複雑に絡み合うシステム環境における障害を完全にゼロにすることは不可能です。どれほどAI技術が進化しても、インシデントは必ず起きるという前提に立って、運用基盤を設計し直す必要があります」

「障害対応」から「インシデント管理」へ視座を上げる

　インシデントが発生した場合、その影響は技術的なエラーやシステム停止だけにとどまらない。例えば、人気ECサイトで突発的な障害が発生したケースを考えてみよう。運用現場に監視ツールから次々とアラートが届く一方で、システム部門には社内のさまざまな関係者から問い合わせが殺到する。

　営業部門は、進行中の商談や顧客との信頼関係への影響を懸念し、「顧客が注文できないと怒っている。いつ復旧するのか」と催促する。カスタマーサポート部門にはユーザーからの問い合わせが相次ぎ、「顧客にどのように説明すればよいのか」と指示を求める連絡が入る。

　一方、経営層は「この障害によって、どの程度の経済的損失が生じるのか」「ブランドイメージへの影響やメディアへの対応は必要か」といったビジネスへの影響を懸念し、早期の復旧を求める。

ECサイトの障害をきっかけに、運用担当者へアラートや問い合わせが集中する状況（講演動画から抜粋）

　このような状況で、経営層や営業部門、カスタマーサポート部門に技術的な説明を繰り返しても、コミュニケーションのすれ違いが生じるだけだ。

　「システム障害時に生じる組織全体の混乱は、単なるサーバのエラーではなく、情報連携やコミュニケーションの不足に根本的な原因があります。壊れたものを直す技術的な『障害対応』だけでは、経営層や顧客の不安は拭えません」（草間氏）

　こうした状況を想定し、平時から情報連携の仕組みやコミュニケーションのルールを整備しておかなければ、いざというときに組織内に「情報の空白」が生じる。それぞれの部門が自部門の都合や判断で動き出し、経営陣からのプレッシャーも加わることで、組織全体の混乱が深まってしまう。

　システムの復旧だけに注力する技術的なアプローチでは、この混乱を収束させることは難しい。そのため、技術的な障害対応にとどまらず、ビジネスへの影響を最小限に抑えながら、顧客からの信頼をどう維持するかまでを含む「インシデント管理」へと視座を上げる必要がある。

技術的な復旧を目的とする「障害対応」と、組織やビジネスへの影響まで扱う「インシデント管理」の違い（講演動画から抜粋）

担当者を集めるだけでは足りない、インシデント対応に必要な3つの仕組み

　草間氏によると、包括的なインシデント管理には、「状況の把握」「対応プロセス」「情報共有と連絡手段」という3つの仕組みが必要になる。

　現代のエンタープライズシステムでは、オンプレミスやクラウドなど複数の環境を併用することが一般的だ。それぞれの環境に導入された監視ツールから大量のイベントが送られてくるため、まずは重複する通知や対応不要なアラートを取り除き、対処すべきインシデントを見極めなければならない。

　PagerDutyは、監視ツールから受け取ったシグナルを集約し、重複するイベントの統合やフィルタリングを実施するという。対応が必要なインシデントは、電話やSMS、プッシュ通知、チャットツールなど、担当者ごとに設定した手段で通知する。一次対応者が応答できない場合は二次対応者へ通知するなど、あらかじめ決めたルールに沿って担当者を招集する。

　ただし、担当者を集めるだけでは十分ではない。実際のインシデント対応では、「インシデントコマンダー」（IC）と呼ばれる指揮者を中心に、誰が意思決定し、誰が作業を担当するのかを明確にする必要がある。

　「インシデント対応においては、責任の所在と意思決定の経路を明確にしなければ、現場のエンジニアはばらばらに動いてしまいます。たとえ最新のAIを導入したとしても、誰が指揮を執り、どのように情報を発信するかというプロセスが欠けていれば、AIは次に何をすべきか提案すらできません」（草間氏）

　指揮を執るICに加え、対応経緯を記録する「書記」や、他部門や経営層との連絡・調整を担う「リエゾン」といった役割も決めておく。これにより、対応作業と情報発信が特定の担当者に集中するのを防げる。

インシデントコマンダーを中心に、責任、意思決定の経路、情報の流れを明確にした対応体制（講演動画から抜粋）

　経営層や営業部門、カスタマーサポート部門、広報部門などへの情報共有では、相手に応じて情報の粒度を変える必要がある。技術的な原因を詳しく伝えるのではなく、復旧の見通しや顧客への影響など、それぞれが判断に必要とする情報を、適切な手段とタイミングで届ける。

ステークホルダーとのコミュニケーションで求められる情報の粒度、手段、タイミング（講演動画から抜粋）

　PagerDutyは、こうした役割分担や通知、情報共有の流れをあらかじめ設定するための基盤として利用できる。ただし、ツールを導入すれば対応プロセスまで自動的に決まるわけではない。草間氏が重視するのは、AIを活用する前に、組織としての対応フローを確立しておくことだ。

AIは既存の対応フローをどう補完するのか

　PagerDutyには、インシデント対応を支援する複数のAIエージェントも用意されている。ただし、これらは人間に代わってインシデント対応の全てを引き受けるものではなく、既存の対応フローに組み込み、担当者の作業を補助する位置付けだ。

　「SREエージェント」は、ログや診断情報、ランブック、過去のインシデント記録などを参照し、関連する事象や過去の対応を探し出す。診断や修復の候補を提示することで、担当者の原因調査を支援する。

　「Shiftエージェント」は、オンコールスケジュールと休暇予定などの重複を検知し、交代可能なメンバーを探す。「Scribe Agent」は、インシデント対応中のWeb会議を文字に起こし、対応経緯の記録や事後レビューに利用できる情報を残す。

　「Insightsエージェント」は、蓄積された運用データを分析し、インシデント対応の傾向や改善点を提示する。これらの機能によって、担当者の招集や状況把握、記録、振り返りといった各工程を補助する。

　一方で、誰が意思決定するのか、どの情報を誰に伝えるのかといった対応方針は、組織側で定めなければならない。対応プロセスが曖昧なままでは、AIが情報を集めても、その情報を適切な行動につなげることは難しい。

　草間氏によると、一時的にシステムを復旧させるだけでなく、事後分析によって根本原因を究明し、再発防止につなげることも重要だという。

AIエージェントを活用する場合も、インシデントを振り返り、改善と再発防止につなげる必要がある（講演動画から抜粋）

　「起きてしまったインシデントをただ解決して終わりにするのではなく、きちんと事後分析を行い、改善につなげることがAI時代だからこそ重要です。AI時代のインシデント管理を実現するには、まずはAIに頼らない強固な対応フローを確立し、その上でAIエージェントによる最新の仕組みを取り入れて、改善サイクルを回していくことをお勧めします」