「組織の失敗から学習する（組織学習）」ことに特化した管理プラットフォーム～ハインリッヒの法則やスイスチーズモデル、Just Culture（非難のない文化）といった安全工学・信頼性工学の理論をシステム開発や組織学習に適用するためのインシデント管理OS～

1. システム概要と基本設計思想

本システムは、単なるバグトラッキングツールではなく、「組織の失敗から学習する（組織学習）」ことに特化した管理プラットフォームです。

💡 根底にある3つのコア理論

1. ハインリッヒの法則（1:29:300の法則）

• 1件の重大事故（Critical）の背景には、29件の軽微な障害（High/Medium/Low）があり、その背景には300件のヒヤリ・ハット（Good Catch）が存在するという法則。

• システムの狙い: ピラミッドの底辺である「Good Catch」の報告心理的ハードルを下げることで、頂点の「Critical」を未然に防ぎます。

1. スイスチーズモデル

• 事故は単一の過失ではなく、複数の防御層（コード、テスト、環境、組織プロセスなど）に開いた「穴」が偶然一直線に重なったときに発生するという理論。

• システムの狙い: どの防御層が脆弱化しているかを可視化し、ピンポイントで補強（自動化ツールの導入など）を行います。

1. Just Culture（正義の文化・非難なき文化）

• 障害の原因を「個人の不注意・スキル不足」に求めず、「その行動を生み出したシステムやプロセスの欠陥」に求める文化。

• システムの狙い: ポストモーテム（事後検証）において、個人名ではなく「システム構造の課題」として根本原因を記述させます。

2. 画面レイアウトと全メニュー詳細

画面は左側に固定された「サイドナビゲーション」、上部の「トップバー」、中央の「メインコンテンツエリア」で構成されています。

2-1. OVERVIEW（全体俯瞰）

① ダッシュボード (`dashboard`)

システムの基底となるコックピット画面です。

• 主要メトリクス（4つのカード）

• 重大インシデント: 直近30日間のCritical障害数と発生トレンド（スパークライン表示）。

• 軽微インシデント: High/Mediumの件数と、ハインリッヒ比率（目標 1:29）の達成度。

• ヒヤリ（Good Catch）: 現場からの気づき報告数と、報告文化の健全性（目標 1:300）。

• MTTR（平均復旧時間）: 障害発生から解決までの平均時間。再発率（目標 10%以下）も併記。

• ハインリッヒの三角形: 現在の「重大・軽微・ヒヤリ」のリアルタイム件数比率を視覚的なピラミッドで表示。

• 防御層ヘルスマップ: スイスチーズモデルに基づく各防御層の「穴の数（脆弱性）」を簡易グラフ化。

• 最近のインシデント: 直近に登録・更新された障害の一覧。

② インシデント一覧 (`incidents`)

• 登録されている全インシデントをテーブル形式で俯瞰する画面。

• 「全て」「Critical」「High」「Medium」「Low」「NearMiss」のチップをクリックすることで、深刻度別の簡易フィルタリング（※フロントUIモック）が可能です。

• 右端の「AIボタン（スパークルアイコン）」をクリックすると、該当インシデントの情報を保持したまま「AI分析画面」へダイレクトに遷移します。

2-2. ANALYSIS（要因分析エンジン）

③ RCA / 5 Whys (`rca`)

障害の根本原因（Root Cause）を掘り下げるためのワークスペース。

• 新規インシデント作成フォーム: タイトル、深刻度（5段階）、原因分類（過失、判断ミス、プロセス欠陥、ツール不足、複合、意図的違反）、症状・影響範囲を入力して起票。

• 5 Whys（なぜなぜ分析）エリア: * インシデントを選択すると起動。問い（なぜ？）を5段階で掘り下げます。

• 根本原因記述欄: 最終的なシステム的要因を文章化して保存。

• ステータス進行ボタン: クリックすることで、インシデントの状態をライフサイクルに沿って次へ進めます（Resolved/Verified時に自動で解決日時 `resolved` を記録）。

④ AI分析 (`ai`)

Claude（`claude-sonnet-4-20250514`）のAPIを活用して分析を自動化するインテリジェント機能（※環境未接続時はデモ出力をタイピング表示）。

• 分析タイプ選択:

1. 根本原因候補を提案: 人間エラーを排除し、NPSA（英国国立患者安全庁）判断ツリーを意識したシステム的脆弱性を3案提示。

2. 類似障害を検索: 過去の障害パターンや他業界（航空・医療など）の類似事例から共通項を分析。

3. Postmortem草案生成: 「良かったこと/悪かったこと/幸運だったこと」およびMoSCoW優先度付きアクションのドラフトを作成。

4. 再発防止策を提案: スイスチーズモデルの5つの層（コード・テスト・デプロイ・監視・組織）ごとの具体策を提示。

• 類似インシデント（ベクター検索シミュレーション）: 過去のインシデントとの類似度（%）をシミュレーション表示。

⑤ スイスチーズ (`swiss`)

組織の防御力を定量的に監査するマトリクス画面。

• 防御層マトリクス: 7つの防御層（コードレビュー、自動テスト、CI/CD、ステージング、モニタリング、ロールバック、組織プロセス）をチーズの絵盤に見立て、穴（バグや設定不備）の数を可視化。

• 防御層一覧テーブル: 各層で現在導入されている自動化ツール（Semgrep, pytest, ArgoCD等）と現在のステータス（良好・要改善・危険）をマッピング。「AI提案」ボタンから補強案の作成画面へ連携。

2-3. CULTURE（安全文化の醸成）

⑥ Good Catch (`goodcatch`)

現場のメンバーが日々の業務で気づいた「ヒヤリとしたこと」「セキュリティリスク」を匿名・低ハードルで報告するフォーム。

• クイック投稿機能: 内容とリスクカテゴリ（情報漏洩、データ損失、本番障害など）を選んですぐに投稿可能。

• 三角形の連動: 投稿すると即座に「ハインリッヒ三角形」の最底辺（ヒヤリ件数）がカウントアップされ、心理的に「良いことをした」と感じさせるインターフェース。

⑦ Postmortem (`postmortem`)

障害発生後に、再発防止のために開催される「ポストモーテム会議」のドキュメント作成支援画面。

• 概要＆評価: ファシリテーター、影響範囲のほか、Just Cultureに基づいた3要素（What went well / What went wrong / Where we got lucky）をテキスト管理。

• タイムライン: 事実のみを時系列（役割ベース）で整理。

• アクションアイテム (SMART / MoSCoW):

• 必須（Must）、推奨（Should）、可能なら（Could）の優先度と、担当者、期日（Due）をタスク管理。チェックボックスで完了状態を切り替え可能。

2-4. SETTINGS（管理と運用）

⑧ ワークフロー (`workflow`)

• インシデントライフサイクル: インシデントが辿る8つの状態（`New` → `Triaged` → `Investigating` → `Mitigating` → `Resolved` → `Postmortem` → `Verified` → `Closed`）の進捗インジケーター。

• エスカレーションルール一覧: 深刻度に応じた自動通知先（PagerDuty, Slack等）の定義。

• SLA目標値: 各種目標（Critical MTTR < 30分など）の現状値と達成率のバーチャート。

⑨ チーム / RBAC (`team`)

• メンバー一覧: 所属部署とロールの割り当てマッピング。

• ロールベースアクセス制御 (RBAC) 定義: 5つの権限（Admin, Investigator, Reporter, Viewer, Auditor）の職務権限範囲の定義。

• 外部連携ロードマップ: Slack, PagerDuty, Jira, GitHubなど、将来的な外部統合ステータス。

3. 実装機能とデータ構造 (Developer向け)

本MVPはサーバーレスで動作し、ブラウザを閉じてもデータが維持される仕組みを持っています。

3-1. データ永続化 (Local Storage)

• データはすべてブラウザの `localStorage` 内に `heinrich_ai_v3` というキーでJSON文字列として保存されます。

• 初期状態では、検証用にいくつかのサンプルインシデント（コネクションプール枯渇、認証タイムアウトなど）やGood Catchが事前にロードされます（`defaultDB()` 関数）。

3-2. スコア・日付の計算ロジック

• 日付フォーマット: `fmtDate(ts)` により、タイムスタンプを `M/D` 形式に変換。

• 期間計算 (MTTR等): `fmtDuration(ms)` により、ミリ秒を `Xh Ym` または `Zm` 形式に自動変換。

• ハインリッヒ三角形の固定バリュー: モックアップとしての見栄えと実数値をブレンドするため、ダッシュボードでは実レコード数に固定値（例：Good Catchは実数 `+ 338`）を加算してリアルな比率を演出しています。

3-3. 外部API通信仕様（AI分析機能）

「AI分析を実行」をクリックすると、以下の仕様でAnthropicのAPIへダイレクトに通信を試みます。

• エンドポイント: `https://api.anthropic.com/v1/messages`

• メソッド: `POST`

• 使用モデル: `claude-sonnet-4-20250514`

• ヘッダー・認証: `Content-Type: application/json` （※現行コードにはAPIキーをセットするヘッダー `x-api-key` が未実装のため、実際に外部通信させる場合はバックエンドを中継するか、認証ヘッダーのコード修正が必要です。通信エラー時は自動的に `getDemoOutput()` によるローカルのデモテキスト出力へフォールバックします）。

4. 日常の運用プロセス（ユースケース・手順）

本システムを用いた、開発チームにおける標準的な運用フローです。

【ステップ 1：日常の予防】
日常業務で危ないと感じた点を発見
 └─ [Good Catch] 画面から即座にリスク報告
      └─ チーズの穴（スイスチーズ画面）として可視化され、タスク化される

【ステップ 2：障害発生と起票】
本番障害が発生、復旧対応を実施
 └─ [RCA / 5 Whys] 画面から新規インシデントを起票 (Status: New)
 └─ 復旧完了時に [次のステータスへ] を進め、Statusを [Resolved] に（MTTR確定）

【ステップ 3：事後分析 (RCA)】
週次の振り返り、または障害翌日にチームで分析
 └─ [RCA] 画面で「なぜ？」を5回繰り返し、システム的な根本原因を特定
 └─ 迷った場合は [AI分析] 画面にテキストを投げ、根本原因候補や再発防止策を生成

【ステップ 4：ポストモーテムの作成と学習】
 └─ [Postmortem] 画面で、何が良く、何が悪かったかを「非難なし」で記録
 └─ MoSCoW（Must/Should）に沿ったアクションアイテム（CIにテスト追加など）を起票・担当アサイン
 └─ アクションの完了を確認後、ステータスを [Verified] ── [Closed] へ移行

5. 本格展開（Prod版）に向けた推奨拡張ロードマップ

本HTML（MVP）から実プロダクトへスケールアップする際に実装すべき要件です。

1. 認証とRBACのバックエンド実装

• 現在の `team` 画面はモックです。CognitoやAuth0等の認証基盤と接続し、実際にログインユーザーのロールに応じた画面の閲覧・編集制限（RBAC）をサーバーサイドで適用してください。

1. データベースへの移行と一元化

• `localStorage` から PostgreSQL などの永続DBへ移行し、組織全体でデータをリアルタイムに共有できるようにします。

1. AI分析のプロキシ化とプロンプトガード

• フロントエンドからAnthropic APIを直接叩くのではなく、自社バックエンド経由に修正します。その際、APIキーの隠蔽、およびプロンプトインジェクション対策や、コンテキストとしての過去障害データの埋め込み（RAG: 検索拡張生成）を実装すると、類似障害検索の精度が劇的に向上します。

1. 外部ツール（Datadog / PagerDuty / Slack）とのWebhook連携

• モニタリングツールからのアラート発報を検知してインシデントを自動起票（`New`）する機能や、Postmortemが更新されたら自動でSlackの `#incidents-sharing` チャンネルにサマリを通知する機能を実装することで、「組織学習OS」としてのエコシステムが完成します。