深夜2時、スマートフォンがけたたましく鳴り響き、チャットツールには大量のアラート通知。
システムの信頼性を守るSRE（Site Reliability Engineering）やインフラ担当の皆さんなら、一度は経験したことがある状況ではないでしょうか。
「何が起きているのか？」
「影響範囲は？」
「誰に連絡すべきか？」
情報の洪水の中で瞬時に判断を下さなければならないプレッシャーは計り知れません。
実務の現場における一般的な傾向として確信できるのは、「生成AIは、インシデント対応における最強の副操縦士（コパイロット）になり得る」ということです。
しかし、多くの現場では「AIに何を聞けばいいか分からない」「もっともらしい嘘（ハルシネーション）をつかれたら怖い」という理由で、導入が足踏みしているケースが見受けられます。
そこで今回は、複雑なプログラムやシステム構築の話ではなく、「明日から現場で使える具体的な指示出し（プロンプト）」に特化して解説します。インシデント対応のフェーズごとに、そのままコピー＆ペーストして使えるテンプレートを用意しました。
これらを適切に活用することで、障害時の初動を標準化し、MTTR（平均復旧時間）を劇的に短縮することが実証されています。AIという強力なツールと共に、混乱しがちな障害対応を、論理的でコントロール可能なプロセスへと変えていきましょう。
本テンプレート集の活用方針と前提
プロンプトの紹介に入る前に、AIをインシデント対応に導入する際の「安全装置」について整理しておきます。生成AIは強力ですが、使い方を誤るとかえって混乱を招くリスクもあります。技術の進化に伴いAIのできることが増えているからこそ、基本的な原則を理解しておくことが重要です。
インシデント対応におけるAIの役割定義
まず、AIの立ち位置を明確にしましょう。最新のAIモデルは自律的なパートナーとして振る舞えるほど進化していますが、インシデント対応という極めて重要な場面において、AIは「最終的な意思決定者」ではありません。あくまで「情報の整理・推論・提案を行う高度なアシスタント」として位置づけるのが論理的です。
- AIが得意なこと: 大量のログの要約、パターンの抽出、一般的な解決策の提示、ドキュメントの下書き。
- 最新トレンド: 推論能力が強化されたモデル（OpenAIのoシリーズなど）を活用することで、複雑なエラーログからの因果関係分析や、段階的なトラブルシューティングの精度が向上しています。また、人間とAIが共同で編集できるインターフェースを用いることで、ドキュメント作成の効率も飛躍的に上がっています。
- AIが苦手なこと: 未知の事象に対する正確な断定、最終的な実行判断（コマンド実行など）、最新のコンテキスト（今の瞬間の社内事情や物理的な障害状況）の完全な理解。
AIが出力した情報を必ず人間が検証し、最終的な判断を下すという「人間が介入するフロー（Human-in-the-loop）」を崩さないことが、安全な運用の鉄則です。
MTTR（平均復旧時間）短縮へのロードマップ
本記事のプロンプトは、以下のフェーズに沿って設計されています。現在は、単一のAIモデルですべてを行うのではなく、タスクに応じて最適なモデルを選択する「マルチモデル活用」が効率的であると実証されています。
- 検知・トリアージ: ログ解読時間を短縮（目安：-10分）
- 推奨: 応答速度を重視した軽量なモデル（ChatGPTのmini版相当など）で即座に概要を把握。
- 状況共有: 報告文作成の手間を削減（目安：-15分）
- 推奨: 標準的な高性能モデルで迅速に下書きを作成。
- 調査・復旧: 仮説立案の高速化（目安：-20分）
- 推奨: 推論能力に特化したモデル（Thinking系）を用いて、多角的な視点から原因を深掘り。
- 事後分析: ドキュメント作成の自動化（目安：-60分以上）
- 推奨: 長い文章を読み込めるモデルで、チャット履歴やログ全体を処理させて生成。
セキュリティとデータプライバシーの基本ルール
これが最も重要なポイントです。一般向けに公開されているAIモデル（Web版のChatGPTなど）を使用する場合、機密情報を絶対に入力してはいけません。高度な推論機能やWeb検索機能を利用する場合でも、この原則は変わりません。
- IPアドレス:
192.168.x.xのように一部を隠すか、[Server_A_IP]のように置き換える。 - 個人情報: ユーザーID、メールアドレス、電話番号はすべてダミーのデータに変更する。
- 認証情報: APIキー、パスワード、トークンは絶対に入力しない。
企業向けのセキュアな環境（Azure AI Foundry経由で利用するAzure OpenAIなど）では、入力データがAIの学習に使われない設定が基本ですが、以下の対策を組み合わせることを推奨します。
- 個人情報検出機能の活用: 出力に含まれる個人情報を自動的にブロックまたは隠す設定（PII検出コンテンツフィルターなど）を有効化する。
- 習慣としてのマスキング: システム的な保護があっても、プロンプト入力時に機密情報を除外する習慣をつけることが、意図しないデータ流出を防ぐ「最後の砦」となります。
フェーズ1：検知・分類・トリアージ用テンプレート
障害発生直後は、大量のアラートメールやプログラムが吐き出すログが飛び交い、状況把握に時間がかかります。まずはAIに「何が起きているか」を論理的に整理させましょう。
雑多なアラートログの要約と重要度判定
生のログデータを人間が読み解くには時間がかかります。AIに情報を構造化させ、緊急度の一次判定を行わせるプロンプトです。
【プロンプトの目的】
複雑なログから主要なエラー内容を抽出し、対応の優先度を提案させる。
【入力データ例】
監視ツールからのアラート通知本文、またはエラーログの断片。
【プロンプト本文（コピー用）】
あなたは熟練したSRE（Site Reliability Engineer）です。
以下のインシデントログを分析し、状況を要約してください。
### 制約条件
- 技術的な詳細を維持しつつ、何が起きているかを簡潔に説明すること。
- 緊急度（Severity）を「高・中・低」で判定し、その根拠を述べること。
- 推測が含まれる場合は、その旨を明記すること。
### 入力ログ
{{incident_log}}
### 出力フォーマット
1. 概要（3行要約）:
2. 推定される影響範囲:
3. 緊急度判定: [高/中/低] - [理由]
4. 注目すべきエラーコード/メッセージ:
【期待される出力例】
- 概要: 決済サービスのAPI（/checkout）において、503エラーが急増しています。データベースの接続枠が枯渇している可能性が高いエラーメッセージが確認されます。
- 推定される影響範囲: ユーザーの決済処理が失敗しており、売上に直結する影響が出ています。
- 緊急度判定: 高 - コアビジネス機能である決済が停止しており、即時の対応が必要です。
- 注目すべきエラーコード:
FATAL: remaining connection slots are reserved for non-replication superuser roles
【カスタマイズのポイント】
「緊急度判定」の基準を自社のサービスレベル合意（SLA）に合わせてプロンプト内に定義すると、より実用的な精度が得られます（例：「ユーザー影響がある場合は『高』とせよ」など）。
類似インシデントの検索用キーワード抽出
「これ、前にも起きたな...」と思っても、過去の記録を探すキーワードが思いつかないことがあります。AIに適切な検索キーワードを作らせましょう。
【プロンプト本文（コピー用）】
以下のエラーログに基づいて、過去のナレッジベース（社内Wikiやチケット管理ツール）を検索するための最適な検索キーワードを5つ提案してください。
汎用的な単語だけでなく、特定のエラーコードや機能名を含めてください。
### エラーログ
{{error_log}}
### 出力形式
- キーワード1: [説明]
... (5つまで)
担当チームの自動振り分け推奨
複数の機能が連携するシステムの場合、どのチームが担当すべきか迷うことがあります。エラーの発生源から関連するサービスを特定させます。
【プロンプト本文（コピー用）】
以下のエラー履歴（スタックトレース）を分析し、このエラーがどの部分（データベース、フロントエンド、決済基盤、認証基盤など）に起因する可能性が高いか推測してください。
また、最初に連絡を取るべきチームの候補を挙げてください。
### スタックトレース
{{stack_trace}}
フェーズ2：状況共有・ステークホルダー報告用テンプレート
エンジニアにとって心理的負担が大きいのが「報告」業務です。対応の手を止めて文章を書くのは非効率ですが、AIを活用すれば一瞬で下書きが完成します。
非技術者（経営層・顧客）向け第一報作成
専門用語を並べ立てると、技術に詳しくない経営層や顧客は不安になります。技術的な内容を「ビジネスへの影響」という分かりやすい言葉に翻訳させます。
【プロンプトの目的】
技術的な詳細を知らない相手に対し、安心感を与えつつ状況を正確に伝える第一報を作成する。
【入力データ例】
フェーズ1で作成した要約、またはエンジニア間のチャットメモ。
【プロンプト本文（コピー用）】
あなたは企業の広報担当、もしくはITマネージャーです。
現在発生しているシステム障害について、非技術者（経営層または顧客）向けの第一報メールを作成してください。
### ターゲット読者
{{target_audience}} （例：サービスを利用中の顧客、社内経営層）
### 障害の状況（技術メモ）
{{incident_details}}
### 制約条件
- 専門用語（サーバー名、データベース用語など）は使わず、平易な言葉に言い換えるか、ビジネスへの影響（ログインできない、表示が遅い等）として表現すること。
- 謝罪の意を示しつつ、現在復旧作業中であることを明確に伝えること。
- 原因が未確定の場合は「調査中」とし、適当な推測を書かないこと。
- 丁寧かつ冷静なトーンで記述すること。
【期待される出力例（顧客向け）】
件名：【重要】決済機能のご利用に不具合が発生しております
お客様各位
平素より弊社サービスをご利用いただき、誠にありがとうございます。
現在、一部のお客様において、商品購入時の決済処理が正常に完了しない事象が発生しております。
状況: 決済画面にてエラーが表示される、または処理が進まない
原因: 現在、専門チームが詳細な調査を行っております
対応: 復旧に向けた作業を最優先で進めております
お客様には多大なるご迷惑をおかけしておりますことを、深くお詫び申し上げます。
復旧の目処が立ち次第、改めてご報告させていただきます。
技術チーム向け詳細状況レポート作成
逆に、他の技術チームへの応援要請や状況共有には、詳細な情報が必要です。箇条書きなどを用いて見やすく整理させます。
【プロンプト本文（コピー用）】
以下の情報を元に、技術チーム向けのインシデント状況共有レポートをMarkdown形式で作成してください。
### 構成案
- ステータス: [調査中/対応中/監視中]
- 発生時刻:
- 影響範囲:
- 根本原因（推測）:
- 現在のアクション:
- ヘルプが必要な事項:
### 情報ソース
{{chat_history_or_notes}}
定期的な状況アップデート文面の自動生成
「30分おきに報告してほしい」と求められることもあります。前回の報告からの差分を入力するだけで、論理的な続報を作成させましょう。
フェーズ3：原因調査・仮説立案支援用テンプレート
ここがAIの真骨頂と言えます。人間が焦って視野が狭くなっている時でも、AIは冷静に複数の可能性を提示してくれます。
エラーログからの原因仮説生成（Top3）
一つの原因に固執せず、可能性の幅を広げるための「壁打ち」として機能するプロンプトです。
【プロンプトの目的】
エラー情報から論理的に考えられる原因を複数挙げさせ、調査の抜け漏れを防ぐ。
【入力データ例】
エラーログ、直近のシステム更新情報、システム構成の概要。
【プロンプト本文（コピー用）】
あなたは熟練のバックエンドエンジニアです。
以下のエラーログとシステム環境情報から、考えられる根本原因の仮説を3つ挙げてください。
それぞれの仮説について、「可能性の高さ（高・中・低）」と「検証するための確認方法」を提示してください。
### システム環境
- 言語: Python
- DB: PostgreSQL
- インフラ: クラウド環境
### エラーログ
{{error_log}}
### 出力フォーマット
1. 仮説1: [原因の要約]
- 可能性: [高/中/低]
- 理由:
- 検証コマンド/アクション:
2. 仮説2...
【カスタマイズのポイント】
「直近でシステムの更新は行っていない」「データベースの性能を変更した」など、背景情報を追加で与えると、推論の精度が格段に上がります。
解決策の提案とコマンドライン生成
調査に必要な操作コマンドを思い出せない時に役立ちます。ただし、実行前に必ず人間が内容を確認し、安全性を担保してください。
【プロンプト本文（コピー用）】
上記の仮説1（データベース接続数の枯渇）を検証するために、PostgreSQLで現在のアクティブな接続数を確認し、接続元のIPアドレス別に集計するSQLクエリを作成してください。
また、クラウドの管理ツールを使ってデータベースのCPU使用率と接続数を取得するコマンドも提示してください。
コード修正案の提示と影響範囲の予測
原因が特定のプログラムコードにあると判明した場合、修正案を作成させます。
【プロンプト本文（コピー用）】
以下のコードブロックに不具合の原因があると思われます。
データベースの接続が適切に解除されていない可能性があります。
1. 修正案のコード（変更前後の差分が分かる形式）
2. なぜその修正で解決するかの論理的な解説
3. この修正による副作用のリスク
を提示してください。
### 対象コード
{{source_code}}
フェーズ4：事後分析（ポストモーテム）作成用テンプレート
障害対応が終わった後、疲弊した状態で振り返り文書（ポストモーテム）を書くのは大変です。しかし、これを怠ると再発のリスクが高まります。AIに下書きの大部分を作らせることで、効率的に知見を残しましょう。
チャット履歴からのタイムライン自動生成
対応時のチャットログを読み込ませ、時系列の表を作成させます。これだけで手作業による整理の時間を大幅に削減できます。
【プロンプトの目的】
整理されていないチャットログから、時系列の事実関係（タイムライン）を抽出する。
【入力データ例】
インシデント対応時のチャット履歴（テキスト形式）。
【プロンプト本文（コピー用）】
以下のテキストは、システム障害対応時のチャットログです。
このログから、重要なイベント（検知、報告、対応開始、復旧など）を抽出し、時系列のタイムラインテーブルを作成してください。
### 制約条件
- 時刻はログ内の記載に従うこと。
- 「誰が」「何をしたか」を明確にすること。
- 感情的な発言や無関係な雑談は除外すること。
### チャットログ
{{chat_log}}
### 出力フォーマット
| 時刻 | 担当者 | アクション/イベント |
|---|---|---|
| 14:00 | System | アラート検知（エラー率5%超過） |
| 14:05 | Tanaka | 調査開始を宣言 |
...
「なぜなぜ分析」のファシリテーション
根本原因を特定するための分析において、AIに客観的な視点から「なぜ？」を問い続けさせます。
【プロンプト本文（コピー用）】
今回の障害の直接原因は「データベースの接続数枯渇」でした。
これに対して「なぜなぜ分析（5 Whys）」を行いたいです。
私が回答を入力するので、あなたは鋭い「なぜ？」という質問を投げかけてください。
論理の飛躍がある場合は指摘してください。
まずは最初の質問をお願いします。
再発防止策のブレインストーミング
【プロンプト本文（コピー用）】
今回の根本原因は「定期的なデータ処理による大量の読み取りアクセスが、Webサイト側の接続枠を圧迫したこと」でした。
この再発を防ぐための対策案を、「短期的（即時実施）」「中期的（仕組み化）」「長期的（システム構造の変更）」の3つの視点で論理的に提案してください。
精度を高めるためのカスタマイズと運用Tips
最後に、これらのプロンプトをより自社の環境に適したものにするための実践的なテクニックを紹介します。
Few-Shotプロンプティングによる自社ルールの学習
AIは具体的な例を見せることで出力の精度が向上します。プロンプトの中に「過去の良い出力例」を含める手法（Few-Shotプロンプティング）を用いることで、自社のフォーマットに合わせた回答が得やすくなります。
- 例: 「以下は社内で使用している障害報告書のフォーマット例です。これに倣って出力してください。」として、過去の優れた報告書をプロンプトに含める。
ハルシネーション（嘘）を見抜くための検証プロンプト
AIの回答に疑義がある場合は、別のAIセッション（または別のモデル）で検証させる「ダブルチェック」が有効なアプローチです。
- 検証用プロンプト: 「以下の解決策は、技術的に正しいですか？また、実行した場合のリスクはありますか？客観的かつ批判的にレビューしてください。」
プロンプトのバージョン管理とチーム共有
プロンプトはプログラムのソースコードと同様に扱うべきです。社内の情報共有ツールなどで管理し、チーム全体で共有しましょう。「このプロンプトを使ったらうまくいった」「ここは修正したほうがいい」といった実証データを蓄積することで、組織全体の対応力が継続的に向上します。
まとめ
インシデント対応におけるAI活用は、単なる「作業を楽にするツール」ではありません。緊急時に高まりがちな人間の認知負荷を下げ、論理的で冷静な判断を支援するための「安全装置」として機能します。
今回ご紹介したプロンプトテンプレートは、あくまで実践のための出発点です。ぜひ、実際の現場のデータや運用ルールに合わせてカスタマイズし、継続的に改善を図っていってください。
コメント