第12章：評価指標・KPI | AI品質安定化調査

AI導入の評価では、生産性だけを見ると危険である。品質が悪化しているのに作業速度だけ上がるケースがあるため、生産性・品質・組織・インフラ運用の4軸で見る。

Knowledge 索引（PoC KPI）

週次実測は metrics.yaml に反映。PoC 想定数値は confidence: low のまま、実測後に差し替える。

AI品質の良否を感想で終わらせず、Human Gateで止めた理由を週次KPIの補助ログとして記録する。着想元は Qiita: AI運用ログを週次レビューし、FAQ・CRM・承認ルールへ戻すGAS実装。GASは必須ではなく、PoC初期は手動記録でよい。

Human Gate / AI利用
  → 理由を4項目で記録
  → 週次で分類・件数確認
  → 改善候補を人間が選択
  → Git正本 / ADR / rules / FAQ / 承認ルールへ反映
  → 次週のログで効果確認

PoCで残す最小ログ
項目	用途	例
`gate`	どの確認点で止まったか	requirements / PR / release
`human_review_reason`	人間へ戻した理由の分類	missing_context / low_confidence / approval_rule
`blocked_reason`	止まった事実を短く記録	対象外範囲が未確定
`improvement_target`	改善候補	REQ / FAQ / CRM / ADR / rule / template

正本境界: ログと確定した改善はGit上のMarkdown/YAMLへ置く。スプレッドシートは一時集計に限り、顧客名・問い合わせ本文・機密情報を保存しない。

自動化条件: 最初の1〜2週間は手動。分類が安定してから集計だけを自動化する。改善チケットの自動起票や未入力による強制ブロックはPoC段階では行わない。

OpenAI 等の評価設計では、目的 → データ → メトリクス → 比較 → 継続評価の順で設計する。PoC では「雰囲気でよくなった」を禁止し、第19章の中止条件と接続する。

PoC テーマ別 eval シート（コピーして埋める）
項目	PR前レビュー（P-1）	要件ゲート（S-1）	QA観点生成（Q-1）
評価目的	重大指摘の取りこぼしを減らす	曖昧語・未決の検出	観点漏れの削減
評価データ	過去PR 10件の diff（匿名化）	確定済み REQ/設計 5章	リリース済み機能の観点表
合格基準	人間が「有用」とした指摘 ≥ 60%	曖昧語検出再現率 ≥ 80%	採用観点 ≥ 50%（QA採否）
人間採点者	TL / レビュー担当	SE + PM	QA 担当
採点頻度	週次（代表 3 PR）	ゲート実施ごと	スプリント末
ログ保存先	`output/poc-kpi/` · PRテンプレ	`output/gate/`	テスト管理ツール
自動採点	ルーブリック一致（任意）	曖昧語スキャン件数	—
継続評価	スキル変更時にゴールデン再実行	版間 drift 監査と併用	モデル版変更時に再評価

演習3接続: 週次 KPI に「eval 合格率」を1行追加し、2週連続で基準未達なら 限定継続または中止候補（第19章 19.5b）。

参照: OpenAI — Evaluation guide · 第17章 17.0b ゴールデン eval

カテゴリ	表示項目
AI利用	AI利用PR数、AIセルフレビュー実施率、プロンプト利用回数
レビュー	レビュー待ち時間、指摘件数、重要指摘率、再レビュー回数
テスト	テストケース数、カバレッジ、失敗率、回帰テスト実施率
品質	バグ件数、工程別流出、再発件数、手戻り件数
セキュリティ	アラート数、修正時間、再スキャン合格率
インフラ	設定ミス、作業手戻り、障害切り分け時間、MTTR
事務・人事	勤怠差戻し、照合工数、施策文案時間、パルス改善度

AI活用後にPR件数が増えても、レビュー指摘、手戻り、流出バグが増えているなら成功ではない。逆に、短期的にレビュー指摘が増えるのは、今まで見逃していた問題が可視化されている可能性もある。