「機能ローンチ。次は？」— この質問は通常数週間後に答えがないまま出ます。理由：評価フレームワークが事前に設計されていませんでした。
良い BA は、ローンチ後ではなくビルド前に成功を定義します。
1. AI 機能に特別な評価が必要な理由
従来の機能：処理されたトランザクション、費やした時間、エラー率。明確なメトリクス。
AI 機能が追加：
- 出力品質ドリフト：データ分布が変わるとモデルが劣化する可能性
- ユーザー信頼減衰：AI が数回失敗するとユーザーは使用を停止
- 幻覚インシデント：エラー率以上を監視する必要
- コストスケーリング：より多くのユーザー = 非線形コスト増
2. AI 機能の 3 KPI レイヤー
レイヤー 1：ビジネス KPI
機能がなぜビルドされたか。ビジネス価値を測定する必要があります：
| KPI | 例（AI チャットボット CSKH） | ターゲット |
|---|---|---|
| デフレクションレート | AI が処理した質問の % | 30 日後 ≥ 60% |
| 解決率 | AI レスポンス後に満足した % | ≥ 70% |
| 解決あたりのコスト | 1 リクエスト処理のコスト vs エージェント | < $0.5 |
| 解決時間 | 質問から回答までの平均時間 | < 30 秒 |
| NPS | 機能の Net Promoter Score | ベースライン対比 ≥ +10 |
レイヤー 2：技術・AI 品質 KPI
AI 出力品質を測定（アップタイムだけではなく）：
| KPI | 測定方法 | 閾値 |
|---|---|---|
| 精度 | サンプリング + 人間レビュー（トラフィック 5%） | ≥ 85% |
| 幻覚率 | ファクトチェックサンプリング | ≤ 2% |
| 信頼度分布 | スコア < 閾値の % レスポンス | 週間監視 |
| エスカレーション率 | 人間にエスカレートした % リクエスト | 10～30%（ドメイン依存） |
| レイテンシ p95 | 95 パーセンタイルレスポンス時間 | < 3 秒 |
| エラー率 | API エラー、タイムアウト | < 0.5% |
レイヤー 3：ユーザー経験 KPI
実際の経験を測定（技術メトリクスだけではなく）：
| KPI | 収集方法 | ターゲット |
|---|---|---|
| タスク完了率 | アナリティクス追跡 | ≥ 75% |
| 再質問率 | 回答後 5 分以内にもう一度質問 | ≤ 15% |
| 放棄率 | ユーザーが途中で終了 | ≤ 20% |
| 親指評価 | アプリ内フィードバック | ≥ 60% ポジティブ |
| 機能採用 | AI 機能を使用する MAU / 全 MAU | 60 日後 ≥ 40% |
3. 評価タイムライン：30/60/90/180 日
ローンチ
│
├── 7 日（ヘルスチェック）
│ - エラー率正常？
│ - 対応すべきインシデント？
│ - 初期ユーザーフィードバック
│
├── 30 日（初期評価）
│ - ローンチ前ベースラインと KPI 比較
│ - 精度サンプリング（100 ケース）
│ - トップ失敗モード特定
│
├── 60 日（最適化）
│ - 完全 KPI レビュー
│ - A/B テスト結果（あれば）
│ - 精度未達なら prompt 調整
│ - 決定：スケール上げ・保持・ピボット
│
├── 90 日（マイルストーンレビュー）
│ - ステークホルダー向けビジネスインパクトレポート
│ - ROI 計算
│ - Q2 ロードマップ学習成果ベース
│
└── 180 日（利益実現レビュー）
- 元のビジネスケースとの比較
- 決定：継続・スケール・廃止
4. 利益実現トラッキング
ビジネスケースが実際に実現されているか確認：
## 利益実現レポート：[機能] — 90 日
### ビジネスケース概要（ローンチ前）
- 期待される利益：エージェント ワークロード 40% 削減
- 期待されるコスト：$X/月 API コスト
- 期待される ROI：[N] ヶ月ペイバック
### 実績
| 利益 | 期待 | 実績（D90） | ステータス |
|------|------|-----------|---------|
| デフレクションレート | 60% | 52% | ⚠️ 未達 |
| エージェント時間削減 | 200h/月 | 160h/月 | ⚠️ 未達 |
| ユーザー満足 | 70% | 74% | ✅ 超過 |
| 月間 API コスト | $500 | $620 | ⚠️ 超過 |
### 根本原因分析
- デフレクション低い：ロングテール質問（トラフィック 30%）AI 未対応
- コスト超過：ユーザー量 +25% 推定対比
### 推奨アクション
1. トップ 20 未回答質問タイプ用にナレッジベース拡張
2. コストキャップと使用量ティアリング実装
3. D180 目標再修正：デフレクション ≥ 58%
5. BA がデータチームにリクエストすべきダッシュボード
ローンチ後ではなく、ローンチ前にリクエストします。事後構築しない。
リアルタイム監視（オペレーション）
☐ エラー率、アップタイム、レイテンシ（エンジニアリング）
☐ エスカレーションレート（日次）
☐ 1 日あたり/リクエストあたりコスト（FinOps）
週間レビュー
☐ 精度トレンド（サンプリング）
☐ 失敗クエリトップタイプ
☐ ユーザー満足スコア
月間レポート
☐ 完全 KPI ダッシュボード対ターゲット
☐ A/B テスト結果
☐ 機能採用ファネル
☐ コスト対利益サマリー
6. KPI が未達の場合：決定フレームワーク
| 状況 | アクション |
|---|---|
| 精度 < 閾値 | Prompt 調整 → 改善なければ再トレーニング |
| 低ユーザー採用 | ユーザーリサーチ → 通常は UX 問題 |
| コスト超過 | モデルティアリング（単純ケース用安価モデル） |
| 高エスカレーション | AI カバレッジ拡張 OR エージェントワークフロー最適化 |
| 幻覚インシデント | RAG または fact-check レイヤー追加 |
| ビジネス KPI 未達 | 元のビジネスケース仮定を再検討 |
まとめ
ソリューション評価は Data Analyst または PM の仕事ではありません。BA が KPI 定義と測定データ存在を所有します。仕様に組み込まれなければ、誰も構築しません。
重要な実践：スプリント 1 前に「成功メトリクス」セクションを SRS に追加。具体的な KPI、閾値、測定方法、所有者を含みます。これはビジネスへのコミットメント。事後の思い付きではありません。