incident-learning

インシデントからの学び

運用上のインシデント、ニアミス、演習で得られた知見を、プロダクト、エンジニアリング、テスト、評価、ガバナンスの各領域における、検証済みで担当者が明確な改善につなげます。このスキルが担うのは学習パイプラインです。つまり、生のインシデント証拠を、完了を示す証拠を伴った持続的なフォローアップ作業へと変換する体系的な手法です。インシデント対応、ポストモーテムの進行、フォローアップ作業の実装は担いません。証拠から検証済みの変更への変換を担います。

使用する場面

トリガー	対象範囲
「このインシデントをフォローアップ作業に変換する」	証拠の切り分け、因果関係の台帳、フォローアップ作業マップ、担当者の割り当て
「このインシデントから何を学びましたか？」	事実、仮説、不確実性、すり抜け元のマッピングを含む学習記録
「この知見を完了まで追跡する」	検証記録、完了を示す証拠、フォローアップ作業のステータス
「このインシデントを欠落していた要件に結び付ける」	すり抜け元のギャップマッピング：要件、モニタリング、権限、移行、導入
「インシデントのフォローアップ完了率を確認する」	学習パイプラインの監査、未検証の完了、停滞しているフォローアップ作業
「このニアミスを処理する」	ニアミスの学習記録、寄与した条件、リスク低減のフォローアップ
「インシデント学習記録を作成する」	証拠・推論・不確実性を分け、すり抜け元の分析を含めた構造化記録

使用しない場面

• 責任を追及する、または責任追及を前提にレビューを行う場合。 このスキルは明確に非難を避けるものです。証拠を改善につなげるのであり、過失を処分につなげるものではありません。責任者を割り当てるプロセス、「誰を非難するか」という項目、「非難に値する」という分類はありません。責任者を特定するポストモーテムが必要な場合、このスキルは目的に適しません。
• 汎用的なポストモーテムテンプレートだけを成果物として作成する場合。 このスキルの成果物であるインシデント学習記録、因果関係・証拠の台帳、フォローアップ作業マップ、検証・完了記録が、主な納品物です。ポストモーテム、タイムライン、なぜなぜ分析は学習記録に役立てることはできますが、最終成果物にはなりません。
• 進行中のインシデント指揮またはインシデント対応。 インシデント指揮システム、オンコール運用、リアルタイムのインシデント管理については、site-reliability-engineering を利用してください。
• 非難を避けるポストモーテムセッションの進行。 ポストモーテムの文化、タイムラインの作成、進行方法については、site-reliability-engineering を利用してください。このスキルはポストモーテムの成果物を受け取りますが、作成はしません。
• チケットを作成したことを理由に学習を完了する場合。 チケットの作成は行動であり、成果ではありません。このスキルでは、意図した変更が実施され、意図した効果が得られたことの検証が必要です。チケットだけでは完了とはなりません。
• 特定の障害の根本原因をデバッグする場合。 障害の調査については、systematic-debugging を利用してください。このスキルは、デバッグで得られた知見を学習パイプラインの入力として受け取ります。

中核となる原則

推測ではなく、証拠が基盤です。 インシデントの学習記録では、3 つのカテゴリーをそれぞれ区別します。観測された事実（テレメトリー、ログ、または直接の観察によって裏付けられた、何が起きたか）、因果関係の仮説（何が原因で起きたのかについての推論。確信度と代替説明を明記）、未解決の不確実性（未解決の質問や競合する仮説など、依然として不明な点）です。これらのカテゴリーを混同すると、誤った確信につながります。学習記録テンプレートの「証拠／推論／不確実性」の分類を参照してください。

学習はチケットではなく、検証によって完了します。 チケット、タスク、またはストーリーの作成はプロセスの一環であり、改善の証拠ではありません。完了するには、（1）フォローアップ作業が実装されたこと、（2）意図した変更に照らして実装が検証されたこと、（3）意図した効果が確認されたこと（または改訂した仮説が記録されたこと）が必要です。検証・完了記録テンプレートはこの基準を徹底します。チケットだけでは明確に不十分です。完了記録には、変更が実装されたことを示す証拠を記載する必要があります。

フォローアップ作業の対象はコードだけでなく、複数の領域にわたります。 インシデントによって、6 つの領域のいずれかにおけるギャップが明らかになる場合があります。製品（要件、設計、ユーザーエクスペリエンス）、コード（実装、ロジック、依存関係）、テスト（回帰テストのカバレッジ、統合テスト、アサーション）、評価（評価ケース、評価者のカバレッジ、データセットのギャップ）、運用（監視、アラート、ランブック、キャパシティ）、ガバナンス（権限の境界、ポリシー、コンプライアンス、アクセス制御）です。フォローアップ作業マップでは、この 6 領域の分類を使用し、すべての所見を少なくとも 1 つの領域に対応付けます。

すべてのインシデントには、すり抜けた原因があります。 「どこからすり抜けたか」の分析では、発生元のギャップを次のいずれか 1 つ以上に対応付けます。要件のすり抜け（必要な要件が欠落していた、または不完全だった）、監視または可観測性の欠如（その状態を検知するシグナルが存在しなかった）、安全でない権限またはアクセス（行動できる主体に対するガードレールが不十分だった）、移行時のギャップ（状態を引き起こした移行）、または導入の影響（ユーザーやオペレーターの行動が一因となった）です。この対応付けがフォローアップ作業を導きます。監視のギャップに対して必要なのは、コードの修正ではなく、可観測性に関するフォローアップです。

不確実性は隠さず、記録します。 競合する因果関係の仮説、不完全なデータ、未解決の質問は、学習記録の明示的な項目であり、脚注ではありません。未解決の不確実性に基づいて、何を計測する必要があるのか、どのデータを収集する必要があるのか、どの仮説を検証する必要があるのかといった調査のフォローアップ作業を決定します。未解決の不確実性がないインシデント学習記録は、些細なものか、作成が時期尚早なもののどちらかです。

設計上、非難の項目はありません。 学習記録には、「誰が原因か」「責任者」「非難に値する行為」を記載する欄はありません。この手法では、インシデントを個人の失敗ではなく、相互に作用するコンポーネント、プロセス、前提、状況が生み出すシステム上の結果として扱います。これは文体上の好みではなく、テンプレートと記録形式に組み込まれた構造上の制約です。

インシデント学習記録

インシデント学習記録は主要な成果物です。以下の構造化されたフィールドを含みます。

フィールド	内容	要件
インシデント識別子	一意の ID、日付、期間、重大度、影響を受けたシステム	必須
観測された事実	何が起きたか — テレメトリ、ログ、直接観測、タイムラインのイベントによって裏付けられたもの	必須。ここでは推論しないこと
原因に関する仮説	発生原因についての推論。それぞれに確信度と代替説明のラベルを付けます	必須。事実とは分けること
寄与した条件	インシデントの発生や影響の増幅を可能にしたシステムの状態、プロセスの不備、環境要因	必須
未解決の不確実性	未解決の疑問、競合する仮説、不足しているデータ、不明点	必須。調査のフォローアップにつなげます
発生元のギャップのマッピング	発生元のギャップ：見落とされた要件、監視／可観測性の欠如、安全でない権限／アクセス、移行時のギャップ、導入の結果	必須。少なくとも 1 つのカテゴリが必要
フォローアップ作業のマップ	所見を各領域（プロダクト、コード、テスト、評価、運用、ガバナンス）に対応づけ、担当者と検証方法を記載します	必須。重要な所見ごとに少なくとも 1 つのフォローアップが必要
検証および完了記録	各フォローアップについて、実装の証拠、検証の証拠、効果の証拠、完了日、完了承認者を記載します	完了には必須。チケットだけでは不十分です

読み込みガイド

ファイル	読み込むタイミング
references/discovery-brief.md	隣接するスキルとの責任範囲やルーティングの判断を理解するとき
references/evidence-inference-taxonomy.md	インシデント記録で、観測された事実、原因に関する仮説、未解決の不確実性を区別するとき
references/escaped-from-analysis.md	インシデントを発生元のギャップ（要件、監視、権限、移行、導入）に対応づけるとき
references/follow-up-domains.md	所見を 6 つのフォローアップ領域（プロダクト、コード、テスト、評価、運用、ガバナンス）に対応づけ、担当パターンを確認するとき
references/verification-and-closure.md	検証済みの完了の条件を定義し、チケットだけでの完了を退け、完了の証拠を記録するとき

テンプレート

テンプレート	ファイル	目的
インシデント学習記録	templates/incident-learning-record.md	事実／仮説／不確実性を分け、発生元のギャップのマッピングを含む構造化された記録
原因／証拠台帳	templates/causal-evidence-ledger.md	各原因に関する主張を、裏付ける証拠、確信度、代替説明とともに追跡する台帳
フォローアップ作業のマップ	templates/follow-up-work-map.md	担当者、検証方法、ステータスの追跡を含む、6 領域のフォローアップ作業マップ
検証および完了記録	templates/verification-and-closure-record.md	実装の証拠、検証の証拠、効果の証拠を必須とする、フォローアップごとの完了記録

ルーティングと関連スキル

このスキルは、次の機能を組み合わせ、各スキルへルーティングします。

• site-reliability-engineering — インシデント指揮、オンコール運用、SLO/SLI フレームワーク、非難しないポストモーテム、監視とアラート。SRE は進行中のインシデント対応とポストモーテムの進行を担当し、incident-learning はポストモーテムの成果を受け取り、検証済みのフォローアップ作業に変換します。
• qa-methodology — テスト戦略、回帰テスト、品質ゲート。テストの不足（回帰テストのカバレッジ不足、アサーションの弱さ、未テストの経路など）を明らかにするインシデントの所見はフォローアップ作業につながり、テストの設計と実装のために QA methodology へルーティングされます。
• verification-methodology — 明示された基準に対する合否評価。incident-learning の完了基準では検証エビデンスが必要です。verification-methodology は、意図した変更に対するエビデンスを作成する手順を提供します。
• agent-evals-and-observability — エージェント評価の設計、データセット管理、採点、軌跡レビュー。エージェントの動作に関わるインシデントは、評価の不足（評価ケースの欠落、採点器のカバレッジ不足、観測されていない障害モードなど）に関するフォローアップ作業につながり、agent-evals-and-observability へルーティングされます。
• product-lifecycle-learning — リリース後の成果レビュー、前提の更新、機能の廃止。製品の前提の誤り（機能が意図とは異なる形で使われた、前提が成立しなかったなど）を明らかにするインシデントは、前提の更新や機能の健全性に関する判断のために product-lifecycle-learning へルーティングされる製品フォローアップ作業につながります。
• implementation-planning — デリバリー計画、作業の分解、依存関係のマッピング、ロールアウト戦略。複数のチームやリポジトリにまたがるドメイン横断のフォローアップ作業は、連携したデリバリー計画のために implementation-planning へルーティングされます。
• resilience-and-recovery — レジリエンス設計、演習エビデンス、ゲームデー、復元テスト。演習や DR テストの所見は、インシデントをまたいだパターン分析と検証済みフォローアップの完了のため、incident-learning に取り込まれます。incident-learning は演習の所見を入力として受け取り、resilience-and-recovery は演習の設計を担当します。
• production-readiness — リリースエビデンスパケット、Go/No-Go の判断。システム全体に及ぶ本番環境の課題を明らかにする incident-learning の所見は、将来のリリース判断に向けた production-readiness のエビデンスパケットに反映されます。

このスキルはコンポーネント機能として、production-excellence バンドル（未リリース）と agent-production-operations バンドル（未リリース）に情報を提供します。インシデント学習の記録、因果関係の台帳、フォローアップ作業マップ、完了記録は、インシデントをまたいだパターン分析のために production-excellence へ、エージェント固有の運用学習のために agent-production-operations へと流れます。

incident-learning が担当しないこと

• インシデント指揮とリアルタイム対応：site-reliability-engineering が担当します。incident-learning は進行中のインシデントを管理せず、インシデント対応も実施しません。
• ポストモーテムの進行：site-reliability-engineering が担当します。incident-learning はポストモーテムの成果物を利用しますが、ポストモーテムのセッションを進行しません。
• 根本原因のデバッグ：systematic-debugging が担当します。incident-learning はデバッグで得られた知見を入力として利用します。
• テストの設計と実装：qa-methodology が担当します。incident-learning はテストの不足箇所を特定し、QA methodology がテストを設計して実装します。
• 評価フレームワークの実装：agent-evals-and-observability が担当します。incident-learning は評価の不足箇所を特定し、agent-evals-and-observability が評価を設計します。
• フォローアップ作業の実装：各領域を担当する専門スキルが担当します。incident-learning が担当するのは学習記録、フォローアップの対応表、完了確認であり、実装そのものではありません。
• リリースの判断：production-readiness が担当します。incident-learning は証拠を production-readiness に提供しますが、リリース可否の判断は行いません。