Claude Code を本番環境で運用していると、予期しないエラーや応答停止に直面することは避けられません。私自身、デジライズでの導入支援において、「インシデントが発生したこと自体は問題ではないが、同じ問題を繰り返すかどうかが組織の成熟度を分ける」という現場を何度も見てきました。本記事では、SRE や運用チームが Claude Code のインシデント後に実施すべき事後分析の手順と、組織学習に結びつける実践方法を、テンプレートと具体例を交えて解説します。
本記事の結論: 責任追及ではなく原因究明に集中する blame-free 文化を前提に、タイムライン・根本原因・是正措置を構造化文書にまとめ、72時間以内に初期レポートを作成。そのナレッジを 継続的改善サイクル に組み込むことで、再発防止と組織全体の運用成熟度を高められる。
インシデント事後分析（ポストモーテム）の位置づけ
Claude Code のインシデント対応は「検知→復旧→分析→改善」の4段階で構成されます。インシデント管理の全体像 で述べたように、復旧後の分析フェーズを省略すると、同じトリガーで繰り返し障害が起きる「消火型運用」から抜け出せません。
事後分析（ポストモーテム）の目的は次の3つです。
- 根本原因の特定 — 表面的な直接原因だけでなく、なぜそれが防げなかったのかを掘り下げる
- 再発防止策の立案 — 技術的対処とプロセス改善の両面でアクションアイテムを明確化する
- 組織学習の促進 — ナレッジベースに記録し、他チームや今後のメンバーが同じ轍を踏まないようにする
多くの組織では 72時間以内に初期レポート を作成し、関係者レビューを経て1週間以内に確定版を公開する運用が一般的です。時間が経つと記憶が薄れ、「なぜそう判断したのか」の文脈が失われるため、初動の速さが重要です。
ポストモーテム文書のテンプレートと記載項目
事後分析を属人的なメモで終わらせないために、構造化されたテンプレートを用意します。以下は Claude Code 運用で有効な項目例です。
| 項目 | 内容 | 記載のポイント |
|---|---|---|
| インシデント ID | チケット番号や日時ベースの一意識別子 | INC-2025-001 など追跡可能な形式 |
| 影響範囲 | 影響を受けたユーザー数・機能・時間帯 | 「全社員 500 名のうち営業部 80 名」など定量化 |
| 検知方法 | アラート・ユーザー報告・監視ツール | 検知の遅れがあれば改善ポイント |
| タイムライン | 発生→検知→対応開始→復旧の時系列 | 各ステップの時刻と担当者を明記 |
| 直接原因 | 何が起きたか（エラー内容・API 応答異常など） | 観測された現象を客観的に記述 |
| 根本原因 | なぜ起きたか（設定ミス・リソース不足・依存関係など） | 5 Whys や Fishbone 図で分析 |
| 是正措置（即時対応） | インシデント時に実施した応急処置 | 「API Key を再発行」「プロンプト長を制限」など |
| 再発防止策（恒久対応） | 同じ問題を起こさないための改善 | 技術的修正＋プロセス改善の両面 |
| アクションアイテム | 誰が・いつまでに・何をするか | 優先度付け（Critical / High / Medium） |
このテンプレートを Notion や Confluence に用意し、インシデント発生時に即座に複製して埋めていく運用が効率的です。
テンプレートの保管場所: 運用ドキュメントの「インシデント対応マニュアル」に添付し、チーム全員がアクセスできるようにする。初回作成時に項目の意味を説明する研修を実施すると、記載内容の質が向上する。
タイムラインの作成と「何が遅れたか」の可視化
タイムラインはポストモーテムの核心です。時系列で事実を並べることで、検知の遅れ・判断の迷い・情報伝達のボトルネックが浮き彫りになります。
1. 発生時刻の特定 — ログや 監査ログ から最初の異常が記録された時刻を確認する。ユーザー報告よりログのほうが正確な場合が多い。
2. 検知時刻の記録 — アラートが発火した時刻、または運用チームが気づいた時刻。発生から検知までのギャップが長い場合、監視設定の見直しが必要。
3. 対応開始時刻の記録 — 担当者がチケットをアサインされ、調査を開始した時刻。エスカレーションフローが機能していたかを検証する。
4. 復旧時刻の記録 — サービスが正常に戻った時刻。部分復旧と完全復旧を区別する（例: 一部ユーザーは 30 分後に復旧、全体は 1 時間後）。
5. 遅延要因の分析 — 各段階で時間がかかった理由を記述する。「担当者不在で 15 分遅れた」「ログの調査に 20 分かかった」など、改善の糸口を明確にする。
タイムラインは箇条書きではなく、表形式で時刻・担当者・実施内容・備考を整理すると読みやすくなります。
| 時刻 | 担当者 | 実施内容 | 備考 |
|---|---|---|---|
| 10:05 | - | API レスポンス遅延が発生（ログより） | ユーザー影響なし |
| 10:12 | 監視ツール | アラート発火（p95 レイテンシ 5 秒超） | Slack 通知 |
| 10:15 | SRE A | チケット作成・調査開始 | 初動対応 |
| 10:30 | SRE A | Claude Code API の rate limit 到達を確認 | プロンプト長超過が原因 |
| 10:35 | SRE A | 一時的にプロンプト長を制限（暫定対応） | 部分復旧 |
| 10:50 | SRE B | API Key の使用状況を再確認・新 Key 発行 | 恒久対応へ移行 |
| 11:00 | - | 全ユーザー復旧確認 | 影響時間 55 分 |
この表により、「検知から調査開始まで 3 分」「原因特定に 15 分」など、各フェーズのパフォーマンスが定量的に把握できます。
根本原因分析の手法（5 Whys・Fishbone 図）
直接原因（What）だけでなく、**なぜそれが起きたか（Why）**を掘り下げないと、対処療法に終わります。Claude Code のインシデントでよく使われる分析手法を2つ紹介します。
5 Whys（5回の「なぜ?」）
トヨタ生産方式で知られる手法で、「なぜ?」を5回繰り返して根本原因に到達します。Claude Code の例：
- なぜ API が応答しなくなったか? → rate limit に到達したから
- なぜ rate limit に到達したか? → プロンプト長が想定より長いリクエストが集中したから
- なぜプロンプト長が長いリクエストが集中したか? → ユーザーが大量のコードを貼り付ける操作を同時に行ったから
- なぜ同時に行われたか? → 新機能リリース直後で、利用者が一斉に試したから
- なぜリリース時の負荷を予測できなかったか? → 負荷テストでプロンプト長の上限ケースを想定していなかったから
この結果、「負荷テストシナリオにプロンプト長の上限ケースを追加する」という再発防止策が導かれます。5 回で必ず終わる必要はなく、納得できる根本原因に達したら終了します。
Fishbone 図（特性要因図）
原因を「人・プロセス・技術・環境」などのカテゴリに分類し、多角的に分析する手法です。Claude Code のインシデントでは以下のような軸が有効です。
- 技術（Technology） — API 設定・監視ツール・依存ライブラリのバージョン
- プロセス（Process） — 負荷テスト手順・デプロイフロー・インシデント対応マニュアル
- 人（People） — スキル不足・コミュニケーションミス・担当者不在
- 環境（Environment） — リリースタイミング・ユーザー行動の変化
この図をホワイトボードや Miro で作成すると、チーム全員で「どこが弱かったか」を議論しやすくなります。
blame-free 文化の重要性: 根本原因分析では「誰のせいか」を問わず、「どのプロセスが不足していたか」に焦点を当てる。個人を責めると、次回から報告が隠蔽される恐れがある。「担当者 A がミスした」ではなく「チェックリストに項目がなかった」と記述する。
是正措置と再発防止策の区別
ポストモーテムでは 是正措置（Corrective Action） と 再発防止策（Preventive Action） を明確に分けます。
- 是正措置: インシデント時に実施した応急処置。「API Key を再発行」「プロンプト長を一時制限」など、すでに完了している対応。
- 再発防止策: 同じ問題を起こさないための恒久対策。「プロンプト長の上限チェックをフロントエンドに実装」「rate limit に達する前に警告を出す監視を追加」など、今後実施するアクション。
再発防止策は 技術的対処 と プロセス改善 の両面で検討します。
| 分類 | 対処例（Claude Code） |
|---|---|
| 技術的対処 | プロンプト長のバリデーション強化、API Key の自動ローテーション、rate limit の監視アラート追加 |
| プロセス改善 | 負荷テストシナリオの更新、デプロイ前のチェックリスト追加、インシデント対応マニュアルの改訂 |
どちらか一方だけでは不十分です。技術で防ぎつつ、プロセスで早期検知・早期復旧できる体制を整えます。
アクションアイテムの優先順位付けと責任者アサイン
再発防止策を列挙しただけでは実行されません。誰が・いつまでに・何をするかを明確にし、優先順位を付けます。
1. Critical（最優先） — 同じインシデントが再発すると事業に重大な影響がある項目。例: プロンプト長の上限チェックを 1 週間以内に実装。
2. High（高） — 再発リスクは中程度だが、実装コストが低い項目。例: 監視アラートの閾値調整を 2 週間以内に実施。
3. Medium（中） — 再発頻度が低いか、影響範囲が限定的な項目。例: インシデント対応マニュアルの改訂を 1 ヶ月以内に完了。
4. 責任者とレビュワーのアサイン — 各アクションアイテムに実施者とレビュワーを割り当て、進捗を週次ミーティングで確認する。
Jira や GitHub Issues でチケット化し、ポストモーテム文書にチケット番号をリンクしておくと、進捗が追跡しやすくなります。
ナレッジベースへの統合と組織学習の促進
ポストモーテム文書は作成して終わりではなく、検索可能なナレッジベースに保管し、今後の運用に活かします。
統合方法の例
- Wiki やドキュメント管理ツールに専用ページを作成 — Confluence の「インシデント事後分析」スペースに年月別でアーカイブ。
- タグ付けで分類 —
#api-rate-limit#prompt-length#monitoringなど、原因や影響範囲でタグを付け、類似インシデントを横断検索できるようにする。 - FAQ やトラブルシューティングガイドに反映 — よくある問題はユーザー向けの FAQ に追加し、運用チーム向けにはトラブルシューティング手順書を更新する。
- 定期レビューでパターンを抽出 — 四半期ごとに全ポストモーテムを俯瞰し、「プロンプト関連のインシデントが多い」などの傾向を把握。継続的改善 のテーマに組み込む。
組織学習を促す文化づくり
- ポストモーテム読み合わせ会の開催 — 月次で過去 1 ヶ月のポストモーテムをチーム全員で読み、質問や議論の場を設ける。他チームの失敗から学ぶ機会にもなる。
- 成功事例の共有も同様に記録 — インシデントだけでなく、「早期検知により被害を最小化できた事例」も記録し、ポジティブな学習を促す。
- 新メンバーのオンボーディングに活用 — 過去のポストモーテムを読むことで、「どんなリスクがあるか」「どう対処したか」の文脈を短期間で理解できる。
ナレッジベースの更新頻度: インシデント発生時は即座に追加し、四半期ごとに全体を見直して古い情報を整理する。放置するとノイズが増えて検索性が低下するため、「生きたドキュメント」として維持する意識が必要。
まとめ
Claude Code のインシデント事後分析は、責任追及ではなく 原因究明と組織学習 を目的とした構造化プロセスです。blame-free 文化を前提に、タイムライン・根本原因・是正措置を明確に記録し、72時間以内に初期レポートを作成することで、記憶が鮮明なうちに事実を定着させられます。5 Whys や Fishbone 図を用いて根本原因を掘り下げ、技術的対処とプロセス改善の両面で再発防止策を立案。アクションアイテムには優先順位と責任者をアサインし、進捗を追跡します。完成した文書はナレッジベースに統合し、定期レビューや新メンバーのオンボーディングに活用することで、組織全体の運用成熟度が向上します。
Claude Code の法人導入でインシデント対応体制を整備したい方へ
デジライズ では、Claude Code の導入支援を 研修とコンサルティングの2本柱 で提供しています。ポストモーテムテンプレートの整備、blame-free 文化の構築、監査ログとナレッジベースの統合方法など、実運用に即した体制づくりをサポートします。
- 研修プログラム: SRE・運用チーム向けに、インシデント対応と事後分析の実践ワークショップを実施
- コンサルティング: 既存のインシデント管理プロセスと Claude Code 運用の統合設計、再発防止策の優先順位付け支援
初回相談は無料です。お気軽に お問い合わせ ください。
関連記事
デジライズの実績は社内集計値です。特に明記のない数値付き事例は、匿名加工された実例をもとにしたモデルケースです。導入効果は企業や業務によって異なります。各サービスの料金・機能・提供条件は記事の公開・更新時点の情報であり、変更されるため、最新情報はAnthropic公式サイトなどの一次情報をご確認ください。
Claude Codeの法人導入・研修・業務活用を支援しています。
法人導入支援サービスを見る
