AI時代のインシデント対応 〜時代を切り抜ける、組織アーキテクチャ〜

アーキテクチャConference 2025で登壇した資料です。AI時代、増え続けるインシデントに対して、AIを活用すれば良い感じになるのでは？って安直に考えたりしていませんか？でもそれは「甘え」です。それよりも先にやるべきこと。それは「組織アーキテクチャ」の見直しです。

Transcript

1. 時代を切り抜ける、 組織アーキテクチャ AI 時代の インシデント 対応
2. Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association アーキテクチャConference登壇時に口頭で補足した内 容を、ここの枠に書いていきます
3. 2025年 AIエージェント元年 xx元年っていうの、だいたい眉唾なんですがコレに関し ては間違いなくその通りと言えますね。この 1年でめ ちゃくちゃ変わりました。自分もあらゆる用途に活用し ています
4. 「AIでなんとかしよう」 その発想が、組織を壊すかもしれない 今日のテーマ でも、本セッションではあえてこういうテーマでお話をし ます。
5. アプリケーション開発の高速化 AIエージェントがコーディング作業の大半を 代行してくれることにより、アプリケーション開 発が格段に高速化。 ⇨ 生み出されるアプリケーションの数が増 大する AIコーディングエージェントにより開発は大きく変わりま したね。ほんの1年前までは人間が主でAIが補佐でし たが、今ではAIが主で人間が指示役 開発はスピードアップし、生まれるアプリが増えます
6. 少数精鋭のチーム構成に アプリケーション開発に必要な人数が減少、 少数精鋭によるチーム構成に これまでは7〜8人程度のチームで開発に当 たるのが最も効率が良いとされてきた (Two-pizza rule) AIエージェントがコーディングを担うことで、AI に適切な指示を下せる2, 3人のチームになっ ていく可能性 ⇨ 多数のチームに分割され、多くのアプリ ケーションが開発されるようになる こういう組織も出ているようです。人材育成などの課題 はあれど、アウトプットを最大化するなら熟練エンジニ アがAIしばきまくったほうが速い
7. アプリケーション開発の民主化 知識を持つ人に限られていたアプリケーショ ン開発 ノーコード・ローコードツールも多数存在した が、ツールの枠は超えられず、自由度は低 かった。 AIエージェントによって、作りたいものの概要 を伝えるだけで、自律的に開発が進むよう に。 ⇨ アプリケーションの作り手が 非エンジニアまで拡大する たとえばプロダクトマネージャーのような役割の人も、 AIを活用して開発に参加したり、プロトタイプを自身で 開発したりというケースが増えてきていますね。
8. 全体的には、すごく良いこと しかし・・・
9. 障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。した がって、デプロイが増えると障害も増え、結果としてインシデ ント管理、軽減策、ポストモーテムが必要となる” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのか より引用 https://www.amazon.co.jp/dp/4296070916 ⇨ 開発が高速化するとデプロイも増え、インシデントが増 える 障害のうち、インフラやクラウドによるものって実は少 ないんですよね。多くは「何か変更を加えたとき」に起 きます。なので、アプリのデプロイ回数増えたら比例し てインシデントは増えます。
10. 複雑性の増加 少数精鋭のチームによって生み出されたサービ スは、それぞれがAPI等で連携する。いわゆるマ イクロサービスアーキテクチャ スケーラブルなアプリケーションにするためには 重要なことだが、複雑性が増し インシデントが増 える 関係ないですがマイクロサービスを実践できてる組 織、日本全体の何割なんだろう？ 正直ちゃんと運用出来る組織、ごく僅かでは
11. 人の目を通さないコードの増加 エンジニア、非エンジニアどちらにおいても、人 の目を通さないコードが増加する。 専門的知識が無くても開発出来る時代だが、必 ずしもセキュアで、スケーラビリティが担保され、 バグのないコードとは限らない 専門知識を持った人の目を通さないコードがデ プロイされることで、予期せぬ障害やセキュリ ティ侵害が起きてインシデントになる ほんとはちゃんとレビューしないといけないんですが、 ついついラクをしてちゃんと見ずにマージ、してません か？僕はたまにしてます。でも、それが事故に繋がる。
12. つまり、AIエージェント時代になる とインシデントが増える！
13. システム障害事例 2025年7月に発生。 AIコーディングツール Replitで起きたインシデント。 AIが開発者の命令を無視して本番環境のデータベー スを削除。 さらに4,000人分の架空ユーザーと虚偽のデータを生 成して隠蔽を図った。 https://rocket-boys.co.jp/security-measu res-lab/chatgpt-replit-ai-coding-tool-del etes-production-database-serious-incid ent-behind-vibe-coding/
14. セキュリティインシデント事例 女性向けデートセーフティアプリ「Tea」で発生した大規 模なデータ漏洩。 2025年7月25日に、データストレージシステムが侵害 され、約72,000枚の画像（13,000枚のセルフィーと身 分証明書、59,000枚のユーザー投稿画像）が流出。 • Firebaseデータストアが認証無しで公開状態 • Vibe codingが原因とされる。非エンジニアの開 発者がAIツールに依存して生成したコードを利 用 • 2024年2月以前のバケットが不適切な状態
15. ではどうするか Proprietary & Confidential アプリケーションの 数を制限 高速開発を諦めて 従来の方法に戻す 非エンジニアによる 開発を辞めさせる じゃあAIやめますか。
16. ではどうするか Proprietary & Confidential アプリケーションの 数を制限 高速開発を諦めて 従来の方法に戻す 非エンジニアによる 開発を辞めさせる それは違う
17. AIエージェントによる恩恵は 最大限受けるべき ではどうするか
18. インシデント起きたとしても AIで対処すればいいのでは？ こういう考えに至る人もいるんじゃないでしょうか。
19. インシデントも AIで対処すればいい なんて考えは 甘え
20. インシデントも AIで対処すればいい なんて考えは 甘え PagerDutyも「AIエージェントで運用が良くなる！」とい う機能を前面に押し出してるので、これ言うと営業から やめてくれと言われそう。 でも、やっぱ甘えだと思うんです。
21. インシデント対応も アーキテクチャ が全て AIより先に「構造設計」
22. 「システム障害で 混乱がおきる ので、AIで何とかしよう 」 (インシデントの元となる) システム障害が起きると社内に混乱が起きるから、それを防ぐ為に AIを活用したい。 ＝技術的な問題だから、技術で対応しようとしている CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー システム障害で社内に混乱が起きている様子
23. 混乱が続くとどうなるか
24. 「システム障害で 混乱がおきる ので、AIで何とかしよう 」 (インシデントの元となる) システム障害が起きると社内に混乱が起きるから、それを防ぐ為に AIを活用したい ＝技術的な問題だから、技術で対応しようとしている CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー システム障害で社内に混乱が起きている様子 混乱を起こしているのは誰？ 確かにシステム障害がキッカケになっています が、混乱を引き起こしているのは誰なんでしょう。 そう、混乱を起こしているのは人間なんですよね
25. 障害は技術的に、混乱は 構造的に生まれる • 技術的な障害（Failure）はシステムの 設計不備や未知の条件から発生 する。 • しかし“混乱”（Chaos）は、情報の流れ・ 意思決定の経路・責任の所在が曖昧な 組織アーキテクチャから生じる 。 • つまり障害そのものよりも対応中の構造 が 組織全体を危機に陥れる。 CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー 障害 = 技術の問題 混乱 = 組織アーキテクチャの問題
26. 障害は技術的に、混乱は 構造的に生まれる • 技術的な障害（Failure）はシステムの 設計不備や未知の条件から発生 する。 • しかし“混乱”（Chaos）は、情報の流れ ・ 意思決定の経路 ・責任の所在 が曖昧な 組織アーキテクチャから生じる。 • つまり障害そのものよりも対応中の構造 が 組織全体を危機に陥れる。 CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー 障害 = 技術の問題 混乱 = 組織アーキテクチャの問題
27. 先人から学ぶ 災害対応の現場において • 人命や財産に重大な危機 • パニックになる住民 • 多くの関係者(行政、消防、救急、警察) • 多くの情報発信手段(防災無線、マスコミ、自治 体の掲示板etc) これらを適切に制御し、市民の安全を守らなければ いけない https://commons.wikimedia.org/wiki/File:%E5%AE%B6%E5%B1%8B%E7%81%AB%E7%81%BDP6014960.jpg この混乱への対処方法は、先人に学ぶのが良いでしょ う。インシデント対応については、災害対応が先行して きました。
28. Incident Command System (ICS) • 1970年代に米国の消防によって確立された、災害対応時に統制を取るための 方法論 • 米国は山火事が多く発生する地域。ひとたび発生すると大きな影響が及ぶた め、行政や報道機関と連携して対応していく必要性がうまれた • 標準化された組織構造、統一された指揮 • スパンオブコントロール • 柔軟性と拡張性 • 機能別の部門編成 • インシデントアクションプラン（IAP） • リソース管理 • 安全管理 • 文書化と記録 災害対応から生まれたICSは、ITシステムの運用にお いても取り入れられつつあります。
29. ICSを取り込む考え方 — 組織を “分散システム ” と捉え、設計する 分散システムの文脈だと･･･ CAP定理 • 一貫性（Consistency） • 可用性（Availability） • 分断耐性（Partition Tolerance） 実装・設計の観点 • 障害検知とリカバリ機構 • 同期戦略 • 分散トランザクション • リーダー選出 組織アーキテクチャにこの考えを 直接適用することはできないが、 思考のフレームワークとしては有用 アーキテクチャConferenceの参加者向けに表現したも のがこれです。 組織はナマモノなので、分散システムの考え方がその まま使えるわけではないですが、思考のフレームワー クとして取り入れるのはどうでしょう
30. ICSを取り込む考え方 — 組織を “分散システム ” と捉え、設計する 責任の所在 と 意思決定の経路 を明確にし 情報の流れ をコントロールする =一貫性の担保 インシデントコマンダー (IC)を 中心とした命令指揮系統を構築 ICはインシデント対応の指揮者。 重大インシデントを解決に導く ことを目的と し、意思決定を行う。 インシデントコマンダー 作業担当 CIO ユーザー担 当 別チーム ユーザー
31. 平時(peacetime)と戦時(wartime)を分離 インシデントコマンダー 作業担当 CIO ユーザー担 当 別チーム ユーザー 平時は「ビジネスを回すこと」が最重要。戦時は「インシデントの解決」が最重要。 目的が異なるので、区別して組織構造を作る必要がある 平時: 社長が一番偉い 戦時: ICが最も位が高い (インシデント解決の文脈において)
32. リーダー選出 最初に到着した人が インシデントコマンダー 分散システムにおいてリーダー選出は重要 人命に影響する災害対応においては、最初に現場に到着し た者がインシデントコマンダーとなるのがセオリー。その後よ り適した者がきたら、インシデントコマンダーを明示的に移譲 する。 ITシステムの場合はその限りではない。同様に先着で決めて も良いし、ローテーションでも良い。大事なのは、組織内でき ちんとルールを決めておく こと。 また、なるべく役割を固定化しないこと。 より適した人が来たら委譲 しても良い。 その場合、移譲する旨を全 体に宣言することが大事 これよりICをXXさんに移 譲します
33. コントロールプレーンとデータプレーンを分離 インシデントコマンダー コントロールプレーン: ICを中心とした、意思決定と指揮を 行う密な連携 レスポンダー 書記 リエゾン データプレーン: ステークホルダーとのコミュニケーションパス CIO Dev Support Sales コミュニケーション超大事。でも、 あるべきコミュニケーションの形 は、相手によって変わります。イ ンシデントに直接対応する人た ちと、ステークホルダーは分けて 考えなくてはいけません。
34. コントロールプレーン内のコミュニケーション インシデントコマンダー レスポンダー 書記 リエゾン War Room 重大インシデント発生時に、集中的に問題解 決にあたる専用の対応拠点 物理的な会議室 もしくは バーチャル (Zoom, Teams等) リアルタイムで一元的なコミュニケーションに より、迅速な意思決定と集中的な問題解決を 可能にする
35. データプレーンのコミュニケーション 経営的な意思決定、対外的な情報発信のため に重要。3つの「適切」を意識 • 適切な粒度 • 技術的な詳細までは不要 • 何が起きているか 、今何をしているか 、 今後の見通し 　を伝える • 適切な方法 • ブロードキャスト型 を徹底 • 戦時における1:1のコミュニケーション は、取り返しの付かない遅延を招く • 適切なタイミング • 定期的 (1時間おき、など) • ステータスに変化があったとき CIO Dev Support Sales
36. 改善のためのフィードバック 起きてしまったインシデントは、きちんと振り 返って改善に繋げる AIエージェントによる問題？人為的なミス？ イ ンフラの障害？ 障害によって対処すべき方法が異なる。きちん と振り返り「インシデントが繰り返し起きないよう 対処」することが重要 いわゆる「ポストモーテム」「ポストインシデントレ ビュー」と呼ばれる取り組みですね。これが本当に大事
37. もっと人間的な要素に注目する 現代のシステムは、人間が人間の目的のために構築したもの。 なので、人間的な要素を理解しなければ、技術的な要素を理解することは できない 有意義なポストインシデントレビューを行うには、 直面した技術的な課題 とそれを処理した組織アーキテクチャ の両方を考 慮する 技術面におけるポストインシデントレビューをやってい る人は多いと思うんですが、混乱を起こすのが「人」で あると考えると、人間的な要素まで踏み込んで振り 返ってみましょう
38. 例 クレームがき てます 確かに何か おかしい DBへのクエリ が通らない Xさんを 呼ぼう メタデータロッ クだね リリースプロセ ス見直す 調査開始 復旧対応 シナリオ: 障害によりユーザーからクレーム。最初に対応したエンジニアは、ログやメトリクス を見て「何かがおかしい」と感じました。調査を進めると、どうやら DBがおかしいようです。そ こで、DBAであるXさんを呼ぶことにしました。 Xさんはメタデータロックによるロック解放待ち が原因になっていることを突き止め、対処を行い問題は解消しました。リリース時の ALTER TABLEが原因となったため、ポストインシデントレビューを通じてリリースプロセスを見直すこ とにしました。
39. インタビュー『なぜあのとき Xさんを呼びましたか？』 組織を跨いだ連携があった場合も、インタビューの余地がある “DBに関する問題だと報告を受けた時点で、真っ先に思い浮かんだのが Xさんだった。Xさ んはDBエンジニアとして豊富な経験を積んでいる し、過去にも似たようなトラブルで対応 してもらったことがあった。Yさんも同様に経験豊富だが、 Xさんに比べるとレスポンスが 遅いことがあり、今回のような緊急事態であればまずXさんに聞くのが良いと思った” ここで、「人間的な要素」に踏み込んだポストインシデン トレビューのために、インタビューを行ってみましょう。 なぜあのとき、無意識にXさんを呼ぼうとなったので しょう。
40. インタビュー『なぜあのとき Xさんを呼びましたか？』 • 組織を跨いでいるにも関わらず、Xさんを呼べばいいとすぐに思いついた & すぐに連絡が付いた　ということは良いこと • 上手くいっていない組織だとこれすら難しい • これをより広く共有できれば、さらなる学びに繋がる • 一方で、今後もXさんに依存してしまうのはリスク • DBエンジニアへのエスカレーションプロセスを確立する必要があるかも • 経験がまだ浅いエンジニアをどのように巻き込んでいくか このXさんを呼んだ流れ、良いことと言えるんですよね。 DBの問題はこ の人に聞けば良いという知識が組織にあるからこそ、これができた。上 手くいっていない組織はこれすらできない。良いところもしっかり理解し、 維持していきましょう。 改善点があるとすると、Xさんが単一障害点になり得るという点でしょう か。ここは、DBA側で組織的に対応できるようにフォーメーションを組む のが改善策になりそうです。
41. 開発・運用に分ける考え方の限界 AIエージェント時代では、開発と運用に役割を 分けること自体が困難になる。 アプリが障害を起こしたとき、運用の人に対して 「AIが書いたコードだから仕方ないね」と言っ たらどう思うか そもそもたくさんのアプリを運用チームが面倒 見るのは困難だし、対応が難しい あと、DevとOpsに分ける考え方。これそろそろ限界だ と思うんですよね。DevOpsという考え方もありますが、 そもそも役割分かれてると辛くない？
42. フルサービスオーナーシップの適用 「コードを書いた者が、その責任を負う」 設計と実装の点から見て、テクノロジーに最も 精通した人が製品開発ライフサイクル全体の 責任を引き受ける運用モデル 本番環境において自分が書いたコードの責任 を負うよう、最もシンプルな形でエンジニアに権 限を与える Build Test Ship Run You build it, you run it. PagerDutyでは、これをフルサービスオーナーシップと 呼んでいます。他にもフルサイクルデベロッパーとか、 各社いろんな呼び方があります
43. 「開発者に運用もやらせる」ではなく 「ライフサイクルに責任を持たせる」 Build Test Ship Run スケールアウトがしやすい実装 (コンテナオーケストレーターの自 律復旧に委ねる) ビルドやパッケージングの自 動化 素早いビルドの工夫 実行パラメータの外部 注入(環境依存の排除) トラブルシュートしやす いログの工夫 インフラのコード化 フィードバックループで改善を続け、呼び出しの頻度を減らす
44. AIが得意なこと アラートの分類・関連付け・初動判断 Runbook自動実行、メッセージ生成 Postmortem分析支援 AIが不得意なこと どのチームが対応するべきか、 誰が指揮を取るかの判断 状況判断、優先順位の決定、責任分離 組織の学習構造の設計
45. 構造設計をせず、安易な AI活用によって起こる弊害 AIが「これは重大です」といっても、誰が判断するのか不明確 。 また、情報洪水が発生 。AIアラート関連付けや要約がない場合の改善を期待して導入した はずが、構造がないと逆にAIが大量の“半自動メッセージ ”を発生させる 。 CIO 一体 どうなってるんだ! 現状を 教えてください！ 今何が起きてるの！ スココン スココン アラート 動かない！ ユーザー担当 別チーム ユーザー ヤバい！重大！ 情報情報情報
46. 構造設計をせず、安易な AI活用によって起こる弊害 平時の組織体制のままで運用にAIを取り込んでも、緊急時の素早い対応は難しい 。 ヤバい！重大！ 情報情報情報 本来情報を 届けるべき人 目的が「ビジネスを回すこと」となっている平時の体制 でAIを入れたところで、命令指揮系統が対応しておら ず機能しない
47. 構造設計をせず、安易な AI活用によって起こる弊害 システム運用には、必ず「責任」が伴う。 AIに大いなる力を持たせることは可能だが、大いなる責任は引き受けてくれない あなたはシステム管理者から通常の講習を受けたは ずです。 これは通常、以下の3点に要約されます: #1) 他人のプライバシーを尊重すること。 #2) タイプする前に考えること。 #3) 大いなる力には大いなる責任が伴うこと。 今現在のAIは、考えるより先にタイプする (実行する) 感がある AIにシステム運用させるには大いなる力 も必要 しかし責任は取ってくれない
48. は インシデントに強い組織アーキテクチャ を実現するためにキーとなる能力 をもたらすサービ スです。 情報の流れ ・意思決定の経路 ・責任の所在 をクリアにし、インシデントによる混乱を最低限 に抑えます。 発生する大量の情報を整理し 最適な人に通知 War Room自動作成 意思決定に役立つ インサイトの提供
49. は インシデントに強い組織アーキテクチャ を実現するためにキーとなる能力 をもたらすサービ スです。 情報の流れ ・意思決定の経路 ・責任の所在 をクリアにし、インシデントによる混乱を最低限 に抑えます。 ブロードキャスト型の ステータス共有 組織アーキテクチャに 踏み込む ポストインシデントレビュー フルサービス オーナーシップを実現
50. は 情報の流れ ・意思決定の経路 ・責任の所在 をクリアにする ↑はオブザーバビリティツールだけでは実現が困難。 ITSMツールだけでも難しい。 PagerDutyはそれに特化した、希有なサービス 障害が起きたときに担当者を電話で叩き起こすサービス ･･･と思われがちですが、それは情報の流れ をコントロールする機 能の一部に過ぎないのです
51. インシデント対応も アーキテクチャ が全て AIより先に「構造設計」 まとめ
52. 補足 PagerDutyは決してAIを否定しているわけでなく、むしろ「AIファースト 」を謳うなどインシデン ト管理のAI活用に極めて積極的 なサービスです。 他社に数年先行して、AIOpsをサービス化しています。 インシデント管理のパイオニア、かつAIに長く取り組んでいるからこそ「組織アーキテクチャが 大事」と自信を持って言えると考えています。
53. PagerDuty AI エージェント - インサイトからアクションまで - エージェントがより良く、早く、スマートに業務を⽀援 SRE エージェント 運⽤上の問題を特定して 分類し、関連する過去の インシデントなどの重要 なコンテキストを浮き彫 りにし、対応者に解決を 早めるための推奨事項を 提⽰することにより、業 務の中断によって引き起 こされるビジネスリスク を軽減し、顧客体験を向 上 Insight エージェント 組織内で使われているツー ル全体のデータを分析し、 戦略的な運⽤判断に必要な 情報を特定し、運⽤⼿順と ビジネスの効率を継続的に 改善 Shift エージェント オンコールシフトを動的 に調整して、スケジュー ルや空き時間の競合を未 然に防ぎ、インシデント 担当者のカバレッジを確 保することで、迅速なイ ンシデント解決を促進 し、運⽤コストの削減と 顧客影響の最⼩化を図る Scribe エージェント Web 会議での会話内容を リアルタイムに整理、分析 し、必要なアクションを特 定し、内容をサマリーし て提供することにより、イ ンシデント解決の迅速化 と関係者への情報共有を 促進 インシデント 対応プロセスの改善 On-call 対応 スケジュールの調整 インシデント 対応中の右腕役 インシデント対応の 筆記担当者
54. こちらに興味がある方は是非 PagerDutyウェブサイト、 もしくはお問い合わせください