自動で書かれるインシデント対応ランブック

インシデントのたびに、エンジニアリングチームはランブックの更新を約束します。しかし実際にはほとんど行われません。AIワークフローがインシデントレポートを生成し、ランブックを更新し、ポストモーテムを自動的に作成する方法をご紹介します。

JieGou Team · 2026年2月7日 · 1 分で読めます

すべてのエンジニアリングチームに同じインシデント後の儀式があります。インシデントが発生します。誰かがSlackに簡単なサマリーを書きます。別の誰かがランブックの更新を約束します。ポストモーテムがスケジュールされます。2週間後、ランブックはまだ更新されず、ポストモーテムドキュメントは半分完成で、次に同じインシデントが発生したとき、オンコールエンジニアはゼロから対応方法を考え直すことになります。

問題は怠惰ではありません。ストレスフルなインシデントの後にドキュメントを書くことは誰もやりたくないことであり、次のスプリントの機能開発と競合するのです。ドキュメント負債はランブックが陳腐化して誰も信頼しなくなるまで蓄積されます。

インシデント対応workflow

EngineeringスターターパックにはIncident Responseというworkflowが含まれています。生のインシデントデータ——タイムライン、症状、実施したアクション、根本原因——を取り、1回のパスで3つの出力を生成します。

インシデントレポート — インシデントサマリー、イベントのタイムライン、インパクト評価（影響を受けたユーザー、期間、重大度）、根本原因分析、寄与要因、即時のアクションを含む構造化されたポストインシデントレポート。フォーマットはインシデント間で一貫しているため、数ヶ月のレポートにわたるパターン認識が可能になります。
ランブック更新 — AIがインシデントの詳細を取り、関連するランブックへの追加または更新を生成します。インシデントが新しい障害モードを明らかにした場合、検出手順、診断コマンド、是正手順を書きます。既知の障害モードに新しい側面がある場合、既存のセクションを更新します。出力はナラティブサマリーではなく、ランブック対応のコンテンツとして構造化されています。
エンジニアリングリードレビュー（承認ゲート） — 何かを公開する前にworkflowはレビューのために一時停止します。エンジニアリングリーダーがタイムラインの正確性を検証し、根本原因分析を検証し、ランブックの追加を承認します。このゲートは重要です——AI生成のランブックには、手順が正しいことを確認するためにその場にいた人間が必要です。
ポストモーテム生成 — 承認後、AIが完全なポストモーテムドキュメントを生成します：何が起こったか、なぜ起こったか、何がより迅速な解決を妨げたか、再発防止のためのアクションアイテム。各アクションアイテムには推奨されるオーナーと優先度があります。

インシデントドキュメントに一貫性が重要な理由

インシデントレポートが異なるフォーマットに従っていると、比較できません。すべてのレポートが同じ重大度スケールと分類を使用しない限り、「今四半期のP1インシデントのうちデータベースの問題によるものは何件か？」と尋ねることはできません。すべてのレポートが同じタイミングフィールドを含まない限り、是正時間が改善しているかを追跡できません。

インシデントレポートrecipeは一貫したスキーマを強制します。すべてのレポートが同じセクション、同じ重大度カテゴリ、同じタイミングフィールドを持ちます。時間の経過とともに、これは単なるドキュメントのフォルダーではなく、クエリ可能な構造化データセットになります。

エンジニアがすべきこと

workflowには正確な入力が必要です。エンジニアは以下を提供します：

何が起こったか — イベントのタイムライン、観察された症状、発火したアラート
何をしたか — 実施した診断手順、実行したコマンド、適用した修正
何が原因か — 根本原因と寄与要因

AIはインシデントを調査しません——文書化します。調査、デバッグ、修正——それはエンジニアの専門知識です。AIの仕事は、その専門知識を次のオンコールエンジニアが実際に使える構造化されたドキュメントに変えることです。

ランブックの更新はここで特に価値があります。本番の問題のデバッグに2時間費やしたエンジニアは、次回従うべきステップを正確に知っています。通常その知識は頭の中やSlackスレッドに留まります。workflowはそれを具体的なコマンドと判断ポイントを含むランブックセクションにキャプチャします。

Feature Launchワークフロー

Engineeringパックには、もう1つのドキュメントギャップ——リリースコミュニケーション——を処理するFeature Launch workflowも含まれています。

コミット履歴とPRの説明からチェンジログエントリーを作成
適切なレベルの詳細さでユーザー向けリリースノートを生成
エンドポイントが変更された場合にAPIドキュメントを更新
すべてをレビュー用にパッケージ

そしてSprint Cycle workflowはプランニングとレトロスペクティブのドキュメントを自動化します：バックログアイテムからスプリントゴールを生成し、新機能のドキュメント計画を作成し、レトロスペクティブのメモを実用的な改善に構造化します。

Engineeringパック全体

Engineeringスターターパックにはインシデント対応に加えて2つの追加workflowが含まれています：

Feature Launch — リリースノート、チェンジログ、ドキュメント更新を1回のパスで
Sprint Cycle — プランニング、ドキュメント、レトロスペクティブの自動化

スタンドアロンのrecipe——テック仕様ライター、APIドキュメントジェネレーター、コードレビューフィードバック、アーキテクチャ決定レコード——は個別にまたはカスタムエンジニアリングworkflowのビルディングブロックとして機能します。