はじめに
障害が発生した深夜2時。ページャーが鳴り、オンコール担当がSlackに飛び込む。最初の15〜30分は「ログを漁る」「ダッシュボードを確認する」「過去の類似障害を検索する」という単純作業に費やされる。
障害が収まった後には「ポストモーテムを書かなければ」と疲弊したチームが重い腰を上げる。多くの場合、この文書は「何が起きたか」の記録に終わり、根本原因の掘り下げが浅くなる。
Claude Codeを障害対応に使い始めて一番変わったのは、初動調査の時間とポストモーテムを書く疲弊感だった。
説得力ある実例：「Claudeで自社のClaudeを直した」
2026年3月、Anthropic自身のSREチームがClaude Codeを使った自社インシデント対応について公表した（The Register, 2026-03-19）。
New Year's EveにClaude Opus 4.5がHTTP 500エラーを返し始めたとき、エンジニアがClaude Codeに調査を依頼。AIはSQLクエリを自作し、数秒で画像処理クラス内のハンドルされていない例外を特定した。
Anthropicは「Claudeで自社インフラのトラブルシューティングを行うことが日常的になっている」と述べている。ツール開発者自身が自社障害に使っているという事実が、信頼性の証左になる。
インシデント対応4フェーズとClaude Codeの役割
フェーズ1：検知・トリアージ
SRE Incident Response Skill（mcpmarket.com）を使うと、PagerDutyアラートの集約と重要度評価・類似過去インシデントとの照合・影響範囲の初期推定を自動化できる。
「現在発生しているアラートの一覧を確認して、
最も影響が大きいものを3つ優先順位付けして」
フェーズ2：初動調査
Claude Codeにbash/psql/bqツールへのアクセスを与えることで、手動では15〜30分かかるログ調査が数秒〜数分で完了する（参考値）。
「直近30分のエラーログを分析して、エラーパターンと
発生頻度を時系列で整理して」
フェーズ3：対応・収束
この段階は人間の判断が必須だ。Claude Codeの役割はランブック（手順書）の該当箇所の自動参照・設定変更のPR作成支援・関係者へのステータス更新文書の下書きに限定する。incident-runbook-templates skill（claudeskills.club）では、インシデント種別に応じたランブックテンプレートを自動適用できる。
フェーズ4：ポストモーテム作成
「このインシデントのポストモーテムを書いて。
Slackの#incidentsチャンネルのログとCloudWatchのメトリクスを参照してください。
Google SRE形式（What went well / What went wrong / Where we got lucky）で」
Google SRE形式の構成要素は以下のとおりだ。
| セクション | 内容 |
|---|---|
| What went well | 監視が迅速に機能した等、うまくいったこと |
| What went wrong | カスケード障害への対応不足等 |
| Where we got lucky | 偶然に助けられた部分（ニアミス記録として重要） |
| Timeline | 詳細な時系列（UTC基準） |
| Action Items | 担当者・期限付きの改善タスク |
AIポストモーテムの限界：「80%の話」問題
Claude Codeでポストモーテムを運用するSRE実践者の間でよく語られる限界がある。「読みやすく説得力ある80%の内容は得られるが、根本原因の特定は苦手」という指摘だ。
表面的なログパターンは検出できても、「なぜそのコードがそのタイミングでデプロイされたのか」「なぜレビュープロセスがそれを見逃したのか」という組織・プロセス的な根本原因はClaude Codeには見えない。
推奨する協働スタイルはこうだ。
Claude Code → 草案生成（タイムライン・事実確認・データ収集）
↓
人間 → 根本原因分析・Action Itemsの優先順位付け・組織文化的観点の追加
↓
チームレビュー → ブレームレス文化の確認・公開前チェック
AI生成の80%を叩き台にして、残りの20%を人間の洞察で埋める——今のところこの分担が一番うまくいっている。
SRE Incident Response Agent：公式Cookbookの実装例
AnthropicのClaude Agent SDK Cookbookに「The SRE Incident Response Agent」が掲載されている（platform.claude.com/cookbook）。PagerDuty統合・Confluence統合・Google SRE形式の文書生成ツールを組み合わせた構成だ。
インシデント指揮体制との統合も設計されている。Incident Commander（指揮官）・Technical Lead（技術責任者）・Communications Lead（コミュニケーション担当）・Subject Matter Expert（専門家）の各ロールのチェックリストをCLAUDE.mdに定義しておくことで、深夜の障害対応でも「誰が何をすべきか」が明確になる。
権限設計：読み取り専用の原則
kosui.meで公開されたClaude Codeポストモーテムスキル設計の記事では、重要な設計原則が示されている。エージェントに与える権限は読み取りのみに絞ることだ。ログ・メトリクス・Slack履歴は読めるが、本番環境への書き込みは禁止する。また、利用するMCPサーバーの信頼性を事前に確認し、ポストモーテムの最終版は必ず人間がレビューして承認する。
「自動生成された内容をレビューなしで公開する」という事故を防ぐための設計だ。
注意点：ポストモーテム文化を守るために
AIが生成したポストモーテムに特定の個人名が否定的な文脈で含まれていないかを必ず確認する。ブレームレス文化の維持はツールの設計ではなく人間のレビューで担保する。顧客データを含むログをClaude Codeに渡す際は、マスキング処理を事前に行う。
また、すべての障害に対してAI支援ポストモーテムを強制すると形骸化する。重大度基準（P0/P1のみ等）を設けることを推奨する。
まとめ
どこから手をつけるかはチームの状況によるが、この順番が無理なく進められる。
ステップ1（1時間）：CLAUDE.mdにポストモーテムテンプレートを定義する。インシデントサマリー・タイムライン・What went well/wrong/lucky・暫定根本原因・Action Items（担当者・期限付き）の構造を書いておく。
ステップ2（2時間）：よく使うログ調査パターン（エラー率急上昇・レイテンシ増加・DB接続エラー）をスキルとして定義する。深夜の障害時に`/investigate-error-spike`一発で初動調査を開始できる状態を作る。
ステップ3（30分）：Claude Codeに与えるアクセス権限を棚卸しする。本番DBへの書き込みアクセスは付与せず、ログ・メトリクスの読み取りのみを許可することを確認する。
コメント