インシデント影響分析のためのWebアプリをステップバイステップで作る

インシデント影響を定義し、それが導く意思決定を明確にする

計算やダッシュボードを作る前に、組織で「影響」が何を意味するかを決めてください。このステップを飛ばすと、見た目は科学的でも誰の行動にも結びつかないスコアが出来上がります。

何が「影響」か（何が含まれないか）

影響は、インシデントがビジネスの重要事項に与える測定可能な結果です。一般的な次元には：

• ユーザー： ログイン不能なユーザー数、主要フローでのエラーレート上昇、特定リージョンでのレイテンシ悪化。
• 収益： チェックアウトの失敗、サブスクリプション更新のブロック、広告インプレッションの減少。
• SLA／SLOリスク： 可用性目標に対するダウンタイム分数、エラーバジェットの消費率。
• 内部チーム： サポートチケット量、オンコール負荷、デプロイの停止。

主要な次元を2〜4個選び、明確に定義してください。例えば：「Impact = 影響を受けた有料顧客数 + リスクにさらされたSLA分数」だと具体的です。「グラフが悪く見えるもの＝影響」としないでください。

アプリ利用者と、最初の10分で彼らが必要とするもの

役割によって意思決定が異なります：

• インシデントコマンダー は迅速で根拠ある要約が必要：何が壊れているか、誰が影響を受けているか、トレンド。
• サポート は顧客向けの範囲（どのアカウント／リージョン／プランが影響か）を必要とする。
• エンジニアリング は調査・軽減のためのブラスト半径仮説が必要。
• 経営陣 は簡潔なビジネス表現：深刻度、顧客影響、ETAの信頼度。

各観客が指標を翻訳せずに自分の重要な質問に答えられるように「影響」の出力を設計してください。

リアルタイム vs 近リアルタイム：期待値を早めに設定する

許容される遅延を決めてください。「リアルタイム」は高コストで不要な場合が多く、**近リアルタイム（例：1〜5分）**で意思決定に十分なことが多いです。

これをプロダクト要件として書き残してください。取り込み方法、キャッシュ、UIに影響します。

インシデント中にアプリが有効にする意思決定

MVPは次のようなアクションを直接支援すべきです：

• 深刻度とエスカレーションレベルの宣言
• 顧客コミュニケーションのトリガー（ステータスページ、サポートマクロ）
• 軽減作業の優先順位付け（どのサービス／チームを先に）
• ロールバック、機能フラグ、トラフィック切替の判断
• 積極的に連絡すべき顧客の特定

ある指標が意思決定に影響しないなら、それは「影響」ではなく単なるテレメトリです。

要件チェックリスト：入力、出力、制約

画面設計やDB選定の前に、インシデント発生時に「影響分析」が答えるべきことを書き出してください。目標は初日からの完璧な精度ではなく、レスポンダーが信頼できる一貫性と説明可能な結果です。

必要な入力（最小限）

影響を算出するために取り込む／参照すべきデータをまず決めます：

• インシデント： ID、開始／終了時刻、ステータス、担当チーム、要約、インシデントチャネル／チケットへのリンク。
• サービス： 正準サービスリスト（名前、所有者、ティア／重要度、ランブックリンク）。
• 依存関係： どのサービスがどれに依存するか（最初は粗くても可）。
• テレメトリ信号： アラート、SLO消費、エラー率／レイテンシ、デプロイイベントなど。
• 顧客アカウント： アカウントID、プラン／SLA、リージョン、主要連絡先、サービスへのマッピング（直接またはワークロード経由）。

ローンチ時の任意項目（計画はするが必須にしない）

多くのチームは初日で完璧な依存関係や顧客マッピングを持っていません。データが欠けている場合に手動入力を許すか決めてください：

• データがない場合に影響サービス／顧客を手動選択できる
• テレメトリが遅延する場合の推定開始時刻や範囲
• 理由付きのオーバーライド（例：「誤検知」「社内限定の影響」）

これらはアドホックなメモではなく、検索可能な明示的フィールドとして設計してください。

主要出力（アプリが生成すべきもの）

最初のリリースは次を確実に出せるべきです：

• 影響を受けたサービス と「なぜ」（信号＋依存関係）
• 顧客リスト（プラン／地域別の件数とトップアカウントビュー）
• 深刻度／影響スコア（平易な言葉で説明可能）
• タイムライン（影響がいつ始まり、いつピークし、いつ回復したか）
• 付加価値として：コスト推定（SLAクレジット、サポート負荷、収益リスク）とその信頼区間

非機能制約（信頼できるために必要なこと）

影響分析は意思決定ツールなので制約が重要です：

• 遅延： インシデント中でもダッシュボードは数秒で表示されること
• 可用性： 内部の重要ツールとして扱い、可用性目標を定義すること
• 監査可能性： オーバーライドを誰がいつしたかと以前の値を記録すること
• アクセス制御： 機密顧客データを制限し、読み取りと書き込みを分けること

これらをテスト可能な文として書き出してください。検証できなければ、障害時に頼れません。

データモデル：インシデント、サービス、依存関係、顧客

データモデルは取り込み、計算、UIの契約です。正しく作ればツールを入れ替えても同じ質問に答えられます：「何が壊れた？」「誰が影響を受けた？」「どれくらいの期間？」

コアエンティティ（小さくリンク可能に保つ）

最低限、次をファーストクラスのレコードとしてモデル化してください：

• Incident（インシデント）： ナラティブコンテナ（タイトル、深刻度、ステータス、所有者）と証拠へのポインタ
• Service（サービス）： 依存関係をマップする単位（API、DB、キュー、サードパーティ）
• Dependency（依存関係）： 有向エッジ service A → service B とメタデータ（タイプ、重要度）
• Signal（信号）： タイムスタンプ付き観測（アラート、SLO消費、エラースパイク、合成チェック失敗）
• Customer（顧客）： サービスを消費するアカウントや組織
• Subscription/SLA（契約／SLA）： 顧客に付与される内容（プラン、SLA/SLO目標、レポートルール）

IDは安定して一貫性を保ってください。既にサービスカタログがあるならそれを真実の源（source of truth）として扱い、外部ツールの識別子をマッピングしてください。

時間モデル化（影響は時間窓の問題）

インシデントに複数のタイムスタンプを保存してレポートや分析を支援します：

• start_time / end_time： 実際の影響ウィンドウ（後で精緻化可能）
• detection_time： 最初に気づいた時刻
• mitigation_time： 軽減が効果を上げ始めた時刻

また影響スコアリング用の計算済み時間窓（例：5分バケット）も保存してください。これによりリプレイや比較が簡単になります。

「誰が影響を受けたか」を支える関係

二つのグラフをモデル化します：

1. サービス間の依存関係（ブラスト半径）
2. 顧客とサービスの利用関係（影響範囲）

単純なパターンとして customer_service_usage(customer_id, service_id, weight, last_seen_at) のようなテーブルを作り、顧客がどれだけそのサービスに依存しているかでランク付けできるようにします。

バージョニングと履歴（依存関係は変わる）

依存関係は進化します。計算は当時の状況を反映すべきです。エッジに有効期間を持たせてください：

• dependency(valid_from, valid_to)

顧客契約や利用スナップショットも同様にバージョン管理してください。履歴を持てば過去のインシデントを正確に再実行し、SLA報告を一貫して出せます。

既存ツールからのデータ収集と正規化

影響分析は入力次第です。ここでの目標は、既に使っているツールから信号を引き出し、それらをアプリが扱える一貫したイベントストリームに変換することです。

取り込むべきもの（とその理由）

インシデント時に「何かが変わった」ことを確実に示すソースから始めてください：

• 監視アラート（PagerDuty、Opsgenie、CloudWatchアラーム）：症状と深刻度の迅速な指標
• ログとトレース（ELK、Datadog、OpenTelemetryバックエンド）：どのエンドポイント／どの顧客に影響があるかの証拠
• ステータスページの更新（Statuspage、Cachet）：公式の説明と顧客向けタイムスタンプ
• チケッティング／インシデントツール（Jira、ServiceNow）：所有権、タイムスタンプ、事後データ

一度にすべてを取り込もうとしないでください。検知・エスカレーション・確認をカバーするソースを選びます。

取り込み方法の選択肢

ツールによって統合パターンが異なります：

• Webhook： 近リアルタイムの更新に最適（アラート、ステータスページ）
• ポーリング： WebhookがないAPI向け（バックオフとレート制限に配慮）
• バッチインポート： 過去のバックフィルに有用（初期検証用）
• 手動入力： 最後の修正（アナリストが欠けを補う）

実践的には、重要信号はWebhook、ギャップ埋めはバッチインポートという組み合わせが良いです。

共通スキーマへ正規化する

ソースがalert、incident、annotationと呼んでいても、すべてを単一の「event」形状に正規化してください。最低限標準化する項目：

• タイムスタンプ： occurred_at、detected_at、resolved_at（利用可能な場合）
• サービス識別子： ソースタグ／名前を正準なservice IDにマップ
• 深刻度／優先度： ツール固有のレベルを自分たちのスケールに変換
• ソースと生ペイロード： 監査とデバッグ用に元のJSONを残す

データハイジーン：重複、順序、欠落

データは汚れている前提で設計してください。冪等性キー（source + external_id）で重複を除き、到着順ではなく occurred_at によるソートで順序の乱れを許容し、欠落するフィールドには安全なデフォルトを適用しつつレビューを促すフラグを立てます。

UIに小さな「未マッチサービス」キューを置くと、黙ったままのエラーを防ぎ影響結果の信頼性が上がります。

正確なブラスト半径のためのサービス依存関係マッピング

依存関係マップが間違っていれば、信号とスコアリングが完璧でもブラスト半径は誤ります。目標は、インシデント中にも後続分析でも信頼できる依存グラフを作ることです。

サービスカタログを先に（これが真実の源）

エッジをマップする前にノードを定義してください。インシデントで参照する可能性のあるすべてのシステムについてサービスカタログのエントリを作成します：API、バッチワーカー、データストア、サードパーティベンダー、共有の重要コンポーネントなど。

各サービスには最低限、所有者／チーム、ティア／重要度（顧客向けか内部か）、SLA／SLO目標、ランブックやオンコールドキュメントへのリンク（例：/runbooks/payments-timeouts）を含めます。

依存関係の取得：静的宣言 vs 観測

二つの補完的ソースを使います：

• 静的（宣言）依存： チームが依存を宣言したもの（IaC、設定、サービスマニフェスト、ADR）。安定して監査しやすい。
• 観測（学習）依存： 実際にシステムが呼んでいるもの（トレース、サービスメッシュ、APIゲートウェイログ、イグレスプロキシ、DB監査ログ）。忘れられた下流呼び出しなど「未知の未知」を捉える。

これらを別々のエッジタイプとして扱い、信頼度が理解できるようにします（例：「チームが宣言」／「過去7日間に観測」）。

方向性と重要度が重要

依存は有向でなければなりません：Checkout → Payments と Payments → Checkout は異なります。方向性により「Paymentsが劣化したらどの上流が失敗するか？」といった推論が可能になります。

また ハード依存 vs ソフト依存 をモデル化してください：

• ハード： コア機能がブロックされる（例：認証サービス）
• ソフト： デグレードだがフォールバックがある（例：レコメンド）

この区別は影響を過大評価するのを防ぎ、優先順位付けを助けます。

リプレイと事後分析のためにグラフをスナップショット化

アーキテクチャは週単位で変わります。スナップショットを保存していなければ2ヶ月前のインシデントを正確に分析できません。

依存グラフのバージョンを時系列で保存（毎日、デプロイごと、変更時）し、ブラスト半径計算時にはインシデント時刻に最も近いグラフスナップショットを参照してください。そうすれば「誰が影響を受けたか」は当時の現実を反映します。

影響計算：信号からスコアと影響範囲へ

信号（アラート、SLO消費、合成チェック、顧客チケット）を取り込んだら、アプリは雑多な入力を一貫した表現に変換する必要があります：何が壊れたか、どれほど悪いか、誰が影響を受けているか？

スコアリングアプローチの選択（まずはシンプルに）

MVPは次のいずれかで十分です：

• ルールベース： 「チェックアウトのエラー率 > 5% が10分続いたら影響＝高」など。説明しやすくデバッグが容易。
• 重み付け式： 正規化した指標を組み合わせ0–100のスコアにする。多数の信号がある場合に滑らかな曲線を得られる。
• ティアベース： システムをビジネスティアにマップし、深刻度にキャップやブーストを適用する。ビジネス優先度と整合する。

どの方法でも中間値（閾値到達、重み、ティア）を保存して、なぜスコアが出たか説明できるようにしてください。

影響の次元を定義する

早い段階で全てを1つの数値に潰しすぎないでください。いくつかの次元を別々に追跡し、そこから総合深刻度を導出します：

• 可用性： ダウンタイム、失敗リクエスト、到達不能なエンドポイント
• レイテンシ： p95／p99のベースライン比での悪化
• エラー： エラーレートのスパイク、失敗ジョブ、タイムアウト
• データの正確性： レコード欠損、誤った結果、遅延処理
• セキュリティリスク： 不審なアクセス、データ露出の指標

これにより「利用可能だが遅い」対「誤った結果を返す」といった正確なコミュニケーションが可能になります。

影響範囲（顧客／ユーザー）の算出

影響はサービスの健康だけでなく、それを受けた人です。

利用マッピング（テナント→サービス、顧客プラン→機能、ユーザートラフィック→エンドポイント）を用いて、インシデントに合わせた時間窓内で影響顧客を算出してください（開始時刻、軽減時刻、バックフィル期間など）。

サンプリングログや推定トラフィック、部分的なテレメトリなどの前提を明示してください。

手動調整—説明責任を付けて

オペレーターは誤検知、段階的ロールアウト、一部テナントのみの影響などを手動で修正する必要があります。

手動での深刻度、次元、影響顧客の編集を許可する場合は次を必須にしてください：

• 誰が／いつ／何を変更したか
• 理由（短い説明 + 任意でチケットやランブックへのリンク）

この監査トレイルによりダッシュボードの信頼性が守られ、事後レビューが速くなります。

UXとダッシュボード：数分で影響を理解できるようにする

良い影響ダッシュボードは素早く3つの質問に答えます：何が影響を受けているか？ 誰が影響を受けているか？ どれくらい確信があるか？ これらを得るのに5つのタブを開かなければならないようでは、ユーザーは出力を信用しません。

MVPで出すべき主要ビュー

少数の「常にある」ビューから始めて、実際のインシデントワークフローに対応させます：

• インシデント概要： ステータス、開始時刻、現在の影響スコア、影響が大きいサービス／顧客、最新の証拠
• 影響サービス： 重症度、リージョン、依存経路付きのランクリスト（エンジニアが介入箇所を特定しやすい）
• 影響顧客： プラン／リージョン別の件数と名前付きアカウント（トップアカウント）
• タイムライン： 検知、デプロイ、アラート、軽減、影響変化を時系列でひとまとめにしたストリーム
• アクション： 推奨次ステップ、担当者、プレイブックやチケットへのリンク

「なぜ」を見せる

説明のないスコアは恣意的に感じられます。すべてのスコアは入力とルールに遡れるべきです：

• どの信号が寄与したか（エラー、レイテンシ、合成チェック、サポート量）とその現在値を表示
• 使用したルールと閾値を表示（例：「p95 latency > 2s for 10 min = degraded」）
• 軽量な信頼度インジケータを追加（例：「高信頼度：3ソースで確認」）

「Explain impact」パネルやドロワーを用意すれば、メインビューを散らかさずに説明が可能です。

実際の質問に合うフィルタとドリルダウン

サービス、リージョン、顧客ティア、時間範囲で簡単にスライスできるようにしてください。チャートの任意の点や行をクリックして、変更を引き起こした生データ（モニタ、ログ、イベント）にドリルダウンできるようにします。

共有とエクスポート

アクティブなインシデント中はポータブルな更新が必要です。次を含めてください：

• 共有リンク（権限を尊重）
• CSVエクスポート（サービス／顧客リスト向け）
• PDFエクスポート（ステータス更新や事後サマリ用）

既にステータスページがあるなら /status のような相対ルートでリンクすると広報チームがすばやく参照できます。

セキュリティ、権限、監査ログ

人々がアプリを信頼するには、誰が何を見られるか／変更できるかを管理し、変更の記録を残す必要があります。

役割と権限（シンプルに始める）

実際のインシデント運用に合わせた小さな役割セットを定義します：

• Viewer（閲覧者）： インシデント要約と高レベル影響の読み取りのみ
• Responder（対応者）： ノート追加、影響確認、運用フィールド更新が可能
• Incident commander（インシデントコマンダー）： オーバーライド承認、対外ステータス設定、インシデントを閉じる権限
• Admin（管理者）： 統合管理、役割割当、データ保持ポリシー管理

権限は職位ではなくアクションに合わせて割り当ててください。例えば「顧客影響レポートをエクスポートできる」はコマンダーと一部の管理者に付与する権限です。

機密顧客データの保護

インシデント影響分析は顧客識別子、契約ティア、連絡先を扱うことがあるため、デフォルトで最小権限を適用してください：

• 機密フィールドはマスク表示（例：アカウントIDの下4桁のみ）し、明示的アクセス権があるユーザーのみフル表示
• 「誰が影響を受けたか」と「何が壊れたか」を分離表示。多くのユーザーはサービスレベルだけを見ればよい
• エクスポートに制限を設ける：PDF／CSVに透かしを入れ、依頼者を含め、承認されたロールのみに許可。短期有効で署名付きダウンロードリンクを推奨

「誰が何を変えたか」を答えられる監査ログ

次の操作を十分な文脈で記録してください：

• 影響入力（影響サービス／顧客）の手動編集
• 影響スコアのオーバーライド（旧値、新値、理由）
• 承認やステータス遷移
• レポート生成とエクスポート

監査ログは追記専用で、タイムスタンプと実行者識別を付け、インシデントごとに検索可能にしてください。

コンプライアンス要件への計画

今サポートできること（保持期間、アクセス制御、暗号化、監査範囲）とロードマップ上の事項を文書化してください。

アプリ内に短い「Security & Audit」ページ（例：/security）を用意すると、インシデント中に訊かれる雑多な質問が減ります。

アクティブインシデント中のワークフローと通知

影響分析はインシデント中に次のアクションを促す必要があります。アプリはインシデントチャネルの“コパイロット”のように振る舞い、着信信号を明確な更新に変え、重要な変化があれば人を促します。

チャット／インシデントチャネルとの接続

レスポンダーが既に作業しているチャネル（Slack、Microsoft Teams、専用ツール）と統合を始めてください。目的はチャネルを置き換えることではなく、文脈に応じた更新を投稿し共有記録を保つことです。

実用的なパターンはチャネルを入力と出力の両方として扱うことです：

• 入力： レスポンダーがアプリをタグ付けして（例：「/impact summarize」「/impact add affected customer Acme」）範囲を修正・補強できる
• 出力： アプリが簡潔で一貫した更新を投稿（現在の影響スコア、影響サービス／顧客、前回からのトレンド）

プロトタイプを早く回すなら、まずは一連のワークフロー（インシデントビュー → 要約 → 通知）を端から端まで組んでみてからスコアを洗練するのが良いです。Koder.ai のようなプラットフォームは、ReactダッシュボードとGo/PostgreSQLバックエンドをチャット駆動で素早く試作し、チームがUXを確認したらソースコードをエクスポートできます。

閾値ベースの通知（ノイズではなく意味のあるもの）

影響が明確な閾値を越えたときだけ通知を出し、アラートスパムを避けてください。一般的なトリガー：

• スコープ： 影響顧客数が急増（例：10 → 100）
• ティア： Tier 1 のサービスが影響を受ける
• 収益／SLAリスク： 予測されるSLA違反や重要契約が巻き込まれる
• ブラスト半径の拡大： 新たな依存サービスが影響集合に追加される

閾値を越えたら「何が変わったか」「誰が行動すべきか」「次に何をすべきか」を説明するメッセージを送ってください。

ランブックやワークフローへのリンク

すべての通知に「次のステップ」リンクを含めて、レスポンダーが素早く動けるように：

• ランブック：/blog/incident-runbook-template
• エスカレーションポリシー：/pricing
• サービスオーナーページ：/services/payments

これらは相対リンクにして安定させ、環境間で動くようにしてください。

ステークホルダー向け更新：内部向けと顧客向け

同じデータから二つのサマリ形式を作ってください：

• 内部更新： 技術的詳細、推定原因、軽減進捗、ETA信頼度
• 顧客向け更新： 平易な表現、現在のユーザー影響、回避策、次の更新時刻

定期サマリ（例：15〜30分ごと）と、外部発信前に承認ステップを挟む「生成」アクションの両方をサポートしてください。

検証：テスト、リプレイ、精度チェック

影響分析はインシデント時と事後の両方で信頼される必要があります。検証は二つを証明するべきです：(1) システムは安定で説明可能な結果を出す、(2) その結果は後の合意（事後レビュー）と合致する。

テスト戦略：ルールとパイプライン

最初はスコアリングロジックとデータ取り込みの二点に対する自動テストを用意してください：

• スコアルールのユニットテスト： 各ルールを契約として扱います。特定の信号（エラー率、レイテンシ、合成チェック、チケット量）を与えたときに期待される影響スコアと影響範囲をアサートします。境界値テスト（閾値直下／直上）を含め、メトリクスのジッターで結果が不安定にならないようにします。
• 取り込みの統合テスト： Webhook／イベント入力から正規化レコード、計算された影響までのフルパスを検証します。実際の監視／インシデントツールからの記録済みペイロードを使ってスキーマドリフトを早期に検出します。

テストフィクスチャは読みやすく保ち、誰かがルールを変更した時にスコア変化の理由がわかるようにしてください。

過去インシデントのリプレイで出力を検証

リプレイモードは信頼獲得への近道です。過去のインシデントをアプリで再生し、「当時の段階でシステムがどう表示したか」を実際の結論と比較してください。

実用的なヒント：

• 到着時刻ではなくイベントのタイムスタンプでタイムラインを再構築する
• サービスカタログが変わっている場合はインシデント日付時点のグラフスナップショットで凍結する
• リプレイ結果を保存し、ルール調整後に比較できるようにする

ナイーブなスコアリングが破綻するエッジケースの扱い

実際のインシデントはきれいな障害ばかりではありません。検証スイートに次のシナリオを含めてください：

• 部分的障害（一部エンドポイントや顧客セグメントのみが失敗）
• 性能劣化（失敗ではないが遅く、ビジネス影響は高い）
• マルチリージョン障害（同一サービスのリージョン毎に状態が異なる）

各ケースでスコアだけでなく、どの信号と依存関係／顧客が結果を引き起こしたかという説明をアサートしてください。

事後レビューとの比較で精度を測る

精度を運用的に定義し、追跡してください。計算された影響を事後レビューの結果（影響サービス、期間、顧客数、SLA違反、深刻度）と比較し、差分を検証課題（カテゴリ：データ欠落、依存関係誤り、閾値不適切、信号遅延）として記録します。

時間が経つにつれ目標は「完璧」ではなく、「驚きが減り、インシデント時の合意が速くなる」ことです。

デプロイ、スケーリング、MVP以降の反復

インシデント影響分析のMVPを出すには信頼性とフィードバックループが重要です。最初のデプロイ選択は将来の理論的スケールよりも変化の速さを優先してください。

進化できるデプロイ様式を選ぶ

明確なプラットフォームチームやサービス境界が無いなら**モジュラー単一体（modular monolith）**で始めるのが現実的です。一つのデプロイ単位は移行、デバッグ、エンドツーエンドテストを簡素化します。

サービス分割は次のような実際の痛みが出てから：

• 取り込みパイプラインが独立スケールを必要とする
• 複数チームが独立にデプロイする必要が出てきた
• 単一アプリだと障害ドメインが理解しにくい

実用的な折衷案は 一つのアプリ + バックグラウンドワーカー（キュー） + 必要なら別の取り込みエッジ です。

素早く進めたいなら Koder.ai のようなツールでプロトタイプを加速するのも選択肢です。チャット駆動のワークフローでReact UI、Go API、PostgreSQLデータモデルを素早く作り、スコアリングやワークフローを反復できます。

アクセスパターンに基づくストレージ選定

コアエンティティ（インシデント、サービス、顧客、所有権、計算スナップショット）には**リレーショナルストレージ（Postgres／MySQL）**を使ってください。クエリしやすく、監査や拡張が容易です。

高頻度の信号（メトリクス、ログ起点イベント）は生データ保持やロールアップがSQLで高コストになったら時系列ストア／カラムナストアを追加します。

依存クエリがボトルネックになったり依存モデルが非常に動的にならない限り、グラフDBは後回しで問題ありません。多くのチームは隣接リストテーブルとキャッシュで十分です。

アプリ自身のオブザーバビリティを追加

影響分析アプリもツールチェーンの一部です。次を計測・公開してください：

• エラー率と遅いエンドポイント（特に「影響再計算」）
• ワーカのキュー深度／遅延とリトライ率
• 取り込みスループットとソースごとの失敗数
• データ鮮度（最後の成功pull/pushからの経過時間）
• 計算時間とキャッシュヒット率

UIに「ヘルス + 鮮度」ビューを用意すると、レスポンダーが数字を信頼するか疑うかの判断に役立ちます。

反復とリファクタは計画的に

MVP範囲は狭く定めてください：少数の取り込みツール、明確な影響スコア、誰がどれだけ影響を受けたかを答えるダッシュボード。その後で反復します：

• 次の機能：依存精度向上、顧客固有の重み付け、SLAレポートエクスポート、過去インシデントのリプレイ
• リファクタのトリガ：特例を毎週追加している、再計算が遅すぎる、データモデルが現実を表現できない

モデルをプロダクトとして扱い、バージョン管理し、安全にマイグレーションし、事後レビューのために変更を文書化してください。