KPI：導入効果の測り方

この章で分かること

AI導入の成功を「回答が当たったか」だけで測らない理由
インシデントの時間軸（検知→着手→復旧）と各KPIの関係
速度・品質・運用ノイズ・コストの4グループで見る方法
導入前後で取るベースラインと、月次レビューの進め方
リスク表を、効果測定とセットで読むこと

たとえ話

救急外来で「研修医の診断正答率」だけを見ても、病院の質は分かりません。
重要なのは、トリアージが速いか・必要検査がすぐ揃うか・正しい診療科に渡るか・患者が回復するまでどれだけ待たされたかです。
AI支援運用のKPIも同じで、「モデルが正解したか」より迷いと待ち時間が減ったかを見ます。

この資料の核心（KPI版）:
AIは障害そのものを消しません。
AIの価値は、迷い・探索・情報不足・判断のばらつき・連携遅延を減らし、復旧と改善を速くすることです。
したがってKPIも「障害ゼロ」ではなく、対応プロセスの速度と質を中心に設計します。

1. まず時間軸を共有する（図で覚える）

インシデント1件を時計の針で切ると次のようになります。用語の定義は組織ごとに食い違いやすいので、測定ルールを一文で固定してください。

インシデント時間軸（MTTD / MTTA / MTTR） · ソース: ../diagrams/kpi_incident_timeline.mmd

%% KPI: インシデント時間軸
flowchart LR
  A["障害発生"] --> B["検知\nアラート"]
  B --> C["着手\nアサイン/起票"]
  C --> D["調査・判断・実行"]
  D --> E["復旧確認\n復旧ゴール"]

  A -.->|MTTD| B
  B -.->|MTTA| C
  A -.->|MTTR※定義を固定| E

  note["※MTTRの終点は組織で一文にそろえる\nRestore=サービス復帰 / Repair=修理完了"]
  E --- note

  style A fill:#7f1d1d,stroke:#fca5a5,color:#fff
  style B fill:#1e3a5f,stroke:#7dd3fc,color:#fff
  style C fill:#a16207,stroke:#fde68a,color:#fff
  style E fill:#14532d,stroke:#86efac,color:#fff
  style note fill:#182338,stroke:#2a3a55,color:#e8eef9

図が見えないときのテキスト版

発生 --MTTD--> 検知 --MTTA--> 着手 --> 調査・実行 --> 復旧
※MTTRの終点は組織で固定

指標	読み	何を測るか	定義で食い違いやすい点	AIとの関係
MTTD	Mean Time To Detect	発生から検知まで	「発生」をユーザー申告にするか、症状メトリクスにするか	主に監視ルールと観測品質の指標。AI導入だけでは縮みにくい
MTTA	Mean Time To Acknowledge	検知から着手まで	「着手」＝既読か、起票か、アサインか	初動パック提示で短縮しやすい（通知設計も効く）
MTTR	Mean Time To Repair / Restore	復旧までの平均時間	Repair（修理）とRestore（サービス復帰）で終点が違う。他章の「復旧」もこの定義に揃える	調査・連携・手順選択が速くなると短縮を狙いやすい。月次の「良い／悪い」はエラーバジェット政策 [S18] とセットで語る

一文で固定する定義テンプレ（コピー用）

当社のMTTR = 「インシデント開始時刻」から
               「復旧ゴール達成（例: SLO内＋15分再発なし）」までの時間
着手(MTTA終点) = インシデントの担当アサイン時刻

測定のコツ: まず直近3ヶ月分を10〜20件、手作業でもよいので上図にプロットする。
AI導入前の点が無いと、「速くなったのか」が説明できません。

2. KPIを4グループで見る（地図）

一覧を並べると迷子になるので、次の4つに整理します。速度（A）と品質・安全（B）はペアで報告します。

KPIの4グループ地図 · ソース: ../diagrams/kpi_four_groups.mmd

%% KPI: 4グループで見る
flowchart TB
  CENTER["AI支援運用のKPI\n障害ゼロではなく\nプロセスの速度と質"]

  CENTER --> A["A 対応速度\nMTTD MTTA MTTR\n初動・収集・候補提示"]
  CENTER --> B["B AI出力の質\n採用率 誤り率\n修正率 承認拒否率"]
  CENTER --> C["C ノイズと再発\n誤アラート ノイズ率\n再発率 ランブック利用率"]
  CENTER --> D["D コストと効率\n件あたりAI費用\nレポート/PM作成時間"]

  A --- PAIR["速度と安全は\n必ずペアで報告"]
  B --- PAIR

  style CENTER fill:#134e4a,stroke:#5eead4,color:#fff
  style A fill:#1e3a5f,stroke:#7dd3fc,color:#fff
  style B fill:#134e4a,stroke:#5eead4,color:#fff
  style C fill:#7c2d12,stroke:#fdba74,color:#fff
  style D fill:#3b0764,stroke:#d8b4fe,color:#fff
  style PAIR fill:#7f1d1d,stroke:#fca5a5,color:#fff

図が見えないときのテキスト版

中央: プロセスの速度と質
A速度 / B品質 / Cノイズ再発 / Dコスト
AとBはペアで報告

ダッシュボードの置き方（イメージ）

+------------------+------------------+
| A 対応速度       | B AI出力の質     |
| MTTR  MTTA       | 採用率  誤り率   |
| 収集・候補提示   | 承認拒否率       |
+------------------+------------------+
| C ノイズと再発   | D コストと効率   |
| 誤アラート 再発  | 件あたりAI費用   |
| ランブック利用率 | レポート作成時間 |
+------------------+------------------+
        ↑ 月次はこの4マスを同じ1枚で見る

3. Phaseが進むと測るものを増やす

ベースラインの階段 · ソース: ../diagrams/kpi_phase_metrics.mmd

%% KPI: Phase別で測るものを増やす
flowchart LR
  P0["Phase 0\nベースライン\nMTTA MTTR\n誤アラート 再発"] --> P3["Phase 3\n読取AI追加\n収集時間\nツール切替\n採用率"]
  P3 --> P4["Phase 4\n分析支援追加\n候補提示時間\n誤り率 修正率"]
  P4 --> P6["Phase 6~\n操作権限あり\n承認拒否率\n件あたりAI費用\n必須"]

  style P0 fill:#1e3a5f,stroke:#7dd3fc,color:#fff
  style P3 fill:#134e4a,stroke:#5eead4,color:#fff
  style P4 fill:#a16207,stroke:#fde68a,color:#fff
  style P6 fill:#7f1d1d,stroke:#fca5a5,color:#fff

図が見えないときのテキスト版

P0: MTTA MTTR 誤アラート 再発
-> P3: 収集・切替・採用率
-> P4: 候補提示・誤り・修正
-> P6~: 承認拒否・AI費用 必須

4. 指標カタログ（詳細）

全部を最初から測る必要はありません。上の階段に合わせて増やします。

A. 対応速度

KPI	意味	測り方の例	改善の打ち手の例	いつから
MTTD	検知までの時間	障害開始〜初回アラート	監視ルール、SLO、ログ欠落の解消	Phase 0〜
MTTA	着手までの時間	アラート〜担当アサイン／起票	通知先整理、オンコール、初動テンプレ	Phase 2〜
MTTR	復旧までの時間	開始〜復旧ゴール達成（定義固定）	証拠の揃え、ランブック、承認の事前化	Phase 0〜（メイン）
初動開始時間	実質調査が始まるまで	アサイン〜最初の証拠閲覧	AIの初動パック、読取権限	Phase 3〜
情報収集時間	画面・ツールを渡り歩く時間	ストップウォッチ／活動ログ概算	相関キー、横断検索	Phase 3〜
原因候補提示時間	仮説が揃うまで	着手〜仮説リスト更新	構造化出力、過去事例	Phase 4〜
エスカレーション時間	正しい次の窓口へ渡るまで	条件成立〜相手アサイン	条件の文書化（例は [S19]）、候補提示	Phase 2〜
正しい担当者到達時間	たらい回しの少なさ	初動〜最終担当への到達	資産マップ、サービスオーナー表	Phase 2〜
復旧手順選択時間	やる手順が決まるまで	判断開始〜実行承認依頼	ランブック検索、リスク付き選択肢	Phase 4〜

B. AI出力の質

KPI	意味	測り方の例	読み方の注意
AI提案採用率	提案のうち人が採用した割合	採用／一部採用／不採用	高い＝良いとは限らない
AI提案誤り率	事後に外れ／有害と判定	ポストモーテムレビュー	事実と推測の分離も見る
人間による修正率	草案を大幅修正した割合	報告書／PRの差分	初期は高くてよい
AI操作の承認拒否率	L3以上の実行要求が拒否された割合	承認WF集計	急落は「何でも通る」危険信号
手動検索・ツール切替回数	探索コストの代理	サンプル観察	完全自動計測でなくてよい

やってはいけない評価: 「デモで正解を当てた」「感想が良い」だけを正式KPIにしない。
デモデータは綺麗で、本番は欠損・時刻ずれ・権限不足があります。

C / D. ノイズ・再発・コスト

C ノイズと再発

誤アラート率 … 対応不要だった割合
アラートノイズ率 … 抑制前の密度など [S14]
再発率 … 同系統の再発（学習層の代理）
ランブック利用率 … 属人化の減り方

D コストと効率

インシデント1件あたりAIコスト（推定と請求を分ける）
定期レポート作成時間
ポストモーテム作成時間（草案はAI、事実確認は人）

5. ビフォー／アフターの見え方

棒グラフ風イメージ（自データで置き換え）

導入前（中央値）          Phase 4 後（中央値）
MTTR   ████████████ 180分    MTTR   ██████ 90分
MTTA   ████ 40分             MTTA   ██ 15分
収集   ████████ 80分         収集   ███ 25分
誤り率 （未計測）            誤り率 ██ 18%（監視開始）
承認拒否 （なし）            承認拒否 ███ 25%（健全なブレーキ）

※速度が改善しても、誤り率・承認拒否を並記する。

導入前（Phase 0）に MTTA・MTTR・誤アラート率・再発の定義と直近値を取る。
Phase 3で情報収集時間・ツール切替・提案採用率を追加。
Phase 4で原因候補提示時間・誤り率・修正率を追加。
Phase 6〜で承認拒否率と件あたりAIコストを必須化。
比較は平均だけでなく中央値と最悪ケースも見る。

6. 月次レビューの流れ

60分アジェンダ

[定義確認 10分] → [速度KPI 15分] → [AI品質 15分]
        → [ノイズ・再発 10分] → [次の1アクション決定 10分]

会議のゴールは数値を眺めることではなく、次の1アクションを決めることです（監視／ログ／権限／ランブックのいずれか）。

7. リスク表とセットで読む

報告の型（1枚に両方書く）

効果が伸びた指標          同時に見る安全指標
・MTTR ↓                 ・提案誤り率
・収集時間 ↓             ・承認拒否率
・正しい担当到達 ↓       ・PII関連事象 / 権限監査

区分	導入前からあるリスク	AIで増えるリスク	AIで改善しやすい点	見るKPIの例
アプリ	バグ、例外、データ不整合	誤った原因推定	調査時間の短縮	情報収集時間、誤り率
インフラ	故障、容量不足、通信断	過剰権限	影響範囲の整理	正しい担当到達、承認拒否率
CI/CD	テスト不足、誤デプロイ	誤った自動マージ	失敗原因の分析	CI調査時間、PR修正率
セキュリティ	不正アクセス、情報漏洩	プロンプトインジェクション	証跡の横断分析	PII事象件数、権限監査
運用	属人化、連携遅延	AI依存（停止時に読めない）	手順と判断の標準化	ランブック利用率、MTTR

「MTTRが下がった」一方で「承認拒否率が急落（＝何でも通る）」なら、速度の裏で安全が削れている可能性があります。
速度KPIと安全KPIは必ずペアで報告してください。

8. 読者別：何を持ち帰るか

運用担当者MTTA/MTTRの定義文を書き、週次で外れ値1件を見る

PG探索時間・手動検索回数の減少でログ改修の効果を見る

SEログ設計・検索導線・権限設計の効果をKPIで説明する

PM効果報告は回答精度%ではなく、プロセス時間と再発・ノイズで書く

経営層投資対効果は「障害がなくなる」約束ではなく、復旧リードタイムと属人化低減で見る

9. よくある失敗パターン

指標が多すぎる

最初は MTTA / MTTR / 誤アラート / 提案誤り率 / AIコストの5つで足りることが多い。

定義が会議ごとに変わる

MTTRの終点を資料ヘッダに固定する。

デモ精度を本番KPIにする

本番の欠損込みで再測定する。

速度だけ追う

承認拒否率・誤り率・漏洩系の事故件数を並記する。

ふりかえり

自組織の MTTR の終点を一文で書けたか
導入前ベースライン（少なくとも MTTA/MTTR）があるか、無いなら取得計画があるか
速度KPIと安全KPIをペアで報告する欄があるか
月次で「次の1アクション」まで決めるアジェンダがあるか