第8章：AIによる初動支援

この章で分かること

初動でAIに頼む順番（何を先に、何を後に）
自由文ではなく「型」で出力させる理由と必須項目
事実／推測／反証／不足情報の分け方
復旧ゴールとエスカレーションを初動から書く意味
人が最終判断するときのチェックポイント

たとえ話

救急外来のトリアージシートです。
「バイタル・疑っている病名・まだ測っていない検査・次の診療科」を同じ紙に書くと、引き継ぎが速くなります。
AI初動支援の価値は診断の断定ではなく、シートをその場で埋めることです。

AI は材料を揃え、人間はやる／やらない／誰に渡すを決める。
AIの文章をそのまま「原因確定」にしないことが、この章の最低ルールです。

1. 初動の流れ（9ステップ）

初動パイプライン

[既存監視が検知] → 起票
        ↓
1 情報収集 → 2 時系列 → 3 影響範囲
        ↓
4 仮説 → 5 反証 → 6 不足情報
        ↓
7 次の確認 → 8 復旧ゴール → 9 エスカレ候補
        ↓
   人間が判断・承認・実行

情報収集 … ログ／メトリクス／トレース／直前の変更・デプロイを、権限の範囲で集める
時系列 … 「いつから変か」を一分単位で並べる（デプロイ直後かが鍵）
影響範囲 … ユーザー影響・対象サービス・地域・テナント
仮説 … 複数本。1本だけ出させない
反証 … 各仮説に「これを満たせば否定できる」材料
不足情報 … まだ見ていないが必要そうな指標・ログ
次の確認 … 誰が何を何分で見るか
復旧ゴール … いつ「終わった」と言えるか
エスカレーション候補 … 条件付きで次の窓口（条件の型は公式の実践例も参考になる [S19]）

2. 出力の型（必須項目つき）

incident_summary:
  current_status / user_impact / started_at / severity
facts:                 # 観測できたことだけ
hypotheses:            # cause / confidence / support / contradict / verification
missing_information:
next_actions:          # action / owner / risk / requires_approval
escalation:            # level / next / condition
recovery_goal:         # 測れる条件で書く

区分	書いてよいもの	書いてはいけないもの
事実	ログ件数、デプロイ時刻、メトリクス値	「きっとDBが原因」
推測	仮説とその信頼度	根拠なしの断定
次アクション	確認作業、承認付きロールバック案	無承認の本番破壊操作

3. 人が見るチェックリスト（初動2分）

見る

事実と推測が分かれているか
反証が空欄になっていないか
復旧ゴールが測れる表現か

止める

「原因はこれ」だけの出力
承認なし本番操作の提案を即実行
不足情報を無視して深掘りだけ続ける

運用担当者初動テンプレをインシデントツールの必須項目にする

PGverificationを再現手順・確認コマンドへ落とす

SEverificationを担当分界とエスカレーション条件に接続する

PM復旧ゴールを先に共有すると会議が短い

経営層「AIが原因特定」ではなく「初動の迷いが減った」を成果にする

よくある失敗

仮説が1本だけ

常に2本以上と反証を要求する。

ゴール無しで調査地獄

先に復旧ゴールを書く。

4. 現場適用：初動15分の台本

分	人	AI	成果物
0-2	SEVと影響を仮置き	証拠収集開始	status仮
2-7	事実の読み合わせ	時系列と仮説2本+	facts/hypotheses
7-12	反証と不足情報の確認	次アクション草案	missing/next
12-15	復旧ゴールと承認要否	エスカレ条件照合	goal/escalation

エスカレーション条件は「なんとなく上に上げる」ではなく、時間・影響・手詰まりなど事前に書いた条件で渡します [S19]。

15分で原因が分からなくてよい。分かることと、次の確認だけ決まれば合格です。

ふりかえり

最後のインシデントで「事実」と「推測」が混ざっていなかったか
復旧ゴールを最初に書けたか
次アクションに担当と承認要否があったか