障害対応でAIを使うなら「原因を聞くな、切り分けを聞け」

障害対応で生成AI（ChatGPTなど）を使うとき、いちばん危ないのはこれです。

• ログや状況を貼って「原因は何？」と聞く
• AIの「もっともらしい答え」を信じて調査が偏る
• 結果、遠回りする（最悪、復旧が遅れる）

この記事は、AIを"正解マシン"にせず、障害対応で安全に使うコツを、「原因ではなく、切り分け（調査計画）を引き出す」という型でまとめます。

なぜ「原因を聞く」のが危ないのか

障害対応の初期は、情報が不完全です。

• ログは一部しかない
• 影響範囲が未確定
• 直前変更が複数ある
• 二次障害（監視・リトライ・タイムアウト）が混ざる

この状態で「原因は？」と聞くと、AIは最も筋が良さそうな仮説を提示します。
でもそれは「正解」ではなく、仮説の一つです。

仮説を"結論"として扱うと、調査が偏って復旧が遅くなります。

目的を変える：AIは「切り分け担当」にする

障害対応でAIに求めるべきはこれです。

原因の断定ではなく、切り分けの観点と調査順を作ること

つまりAIは

• 「何が原因か」ではなく
• 「何から確認すべきか」
• 「どんな観点で切り分けるべきか」

を出す役割にします。

実務で使える手順（テンプレ付き）

STEP 0：まず人間が"事実"だけを書く（推測禁止）

AIに渡す前に、人間が事実を短く整理します。
ここが雑だと、AIの提案も全部ズレます。

【発生】
- 発生日時：
- 影響範囲（ユーザ/機能/件数）：
- 重大度（S1/S2…）：
- 収束状況（継続/断続/終息）：

【再現】
- 再現性：あり/なし/不明
- 再現条件（分かっている範囲）：

【直前変更】
- リリース/設定変更/DB変更/依存サービス変更：
- 変更の有無が不明なもの：

【観測された事実（推測を書かない）】
- ログ抜粋：
- メトリクス（CPU/メモリ/DB接続数/キュー滞留/レイテンシ等）：
- エラーコード/例外名：

コツ： 原因っぽい言葉（「たぶんDB」「おそらくネットワーク」）を書かない
→ AIがその方向に引っ張られます。

STEP 1：AIへの質問は「切り分け」と「優先順位」に固定する

このプロンプトをコピペで使えます。

あなたは障害対応の支援役です。
以下は事実情報です（推測は含まれていません）。

やってほしいこと：
1) 考えられる原因"カテゴリ"を列挙（断定しない）
2) それぞれについて「最短で否定/肯定する切り分け手順」を提案
3) 調査の優先順位を、根拠（影響×確度×確認コスト）付きで並べる
4) 追加で取るべきログ/メトリクス/確認事項を提案
5) まずやってはいけない行動（副作用が大きい、調査を壊す等）があれば指摘

【事実情報】
（ここにSTEP0の内容を貼る）

STEP 2：可能なら「役割を分けて」同じ情報を複数AIへ

1つのAIに聞いて終わるより、2〜3の視点を集めると安全です。

• AI①：SRE/インフラ寄り（ネットワーク、DB、リソース）
• AI②：アプリ寄り（例外、非同期、リトライ、整合性）
• AI③：運用寄り（変更管理、監視、切り戻し、影響分析）

※同じAIでも、役割を明示するだけで観点が変わります。

STEP 3（キモ）：AIの「答え」ではなく「共通の切り分け観点」を採用する

AIから出てきた内容を、次の形でまとめます。

【複数AIで共通して出た切り分け観点】（優先）
- 観点A：
- 観点B：

【AIによって割れた観点】（要判断）
- 観点C：Aはこう、Bはこう

【今回の調査順】（人間が決める）
1.
2.
3.

理由：
- 影響が大きい
- 確認コストが低い
- 早期に否定できる

複数AIが同じ観点を挙げたものは、見落としの可能性が低い＝優先しやすい
割れた部分は、前提不足 or 価値判断領域＝人間が裁く

よく使う「切り分けカテゴリ」例（チェックリスト）

AIに聞くときも、手元の観点としても使えます。

• 直前変更（コード/設定/DB/依存先）
• 依存サービス（API, MQ, 認証, 外部SaaS）
• DB（接続枯渇、ロック、スロークエリ、プール）
• 非同期/キュー（滞留、リトライ嵐、DLQ、タイムアウト）
• タイムアウト（上流/下流、LB、HTTPクライアント、スレッド枯渇）
• リソース（CPU/メモリ/FD/ディスク/GC）
• デプロイ/環境差（特定AZ/Podだけ、設定差、シークレット）
• データ起因（特定顧客/特定レコード/境界値）
• 監視・運用起因（アラート遅延、ログ欠落、ローテーション）

AIに「原因を言わせない」ためのコツ

1) 断定禁止を明示する

「断定しない」「カテゴリで」「切り分けで」をプロンプトに入れる。

2) "推測ワード"を入力側から排除する

「たぶん」「おそらく」「怪しい」などの先入観はAIに渡さない。

3) 重要な前提は固定して渡す

例：

• 「直前のDB変更はない」
• 「リリースはxx時に実施済み」
• 「影響はxx機能に限定」

逆に、AIに聞かない方がいいこと

• 本番での操作手順を"そのまま"採用（副作用が怖い）
• 法務/契約/対外報告の最終文面（レビュー前提ならOK）
• セキュリティや個人情報を含むログの丸投げ（マスキング推奨）

まとめ

障害対応でAIを使うなら、これだけ覚えておけばOKです。

• 原因を聞くな
• 切り分けを聞け
• 調査順は人間が決めろ
• 複数AIの共通点を優先しろ

AIは「当てる」より、調査の抜け漏れを減らす／無駄打ちを減らすのに効きます。

おまけ：そのまま使える「障害対応AIプロンプト（短縮版）」

以下は障害の事実情報です。
原因の断定は不要です。

1) 原因カテゴリを列挙
2) それぞれの最短切り分け手順
3) 優先順位（影響×確度×確認コスト）と根拠
4) 追加で取るべきログ/メトリクス
5) やってはいけない行動

【事実情報】
（貼る）