AI 機能が不正な結果を生成する場合、最初の質問は常に「誰がレビューする？受け入れるか拒否するか誰が決定する？」です。
最初から明確な RACI がない場合、チームは混乱し、遅延が発生し、あるいはより悪いことに全員が「これは私の仕事ではない」と思います。
このガイドは BA が AI 機能用のガバナンス フレームワークを構築する方法を教えます。
1. RACI が AI にとって重要な理由
| シナリオ | ガバナンスなし | 明確な RACI |
|---|---|---|
| プロンプトが誤出力を生成 | チーム全体が混乱、誰も確信がない | BA がすぐに識別：AI チーム所有、製品承認 |
| セキュリティ インシデント | 誰がフォローアップ？誰がロールバックを決定？ | 明確なエスカレーション パス → SOP |
| リリース遅延 | 誰からの承認を待つ？ | 明確な所有者、SLA、go/no-go 基準 |
2. AI 機能用の RACI マトリックス
RACI = Responsible（責任者）、Accountable（説明責任者）、Consulted（相談先）、Informed（報告先）
| アクティビティ | 製品 | BA | データ/AI | エンジニアリング | QA | コンプライアンス |
|---|---|---|---|---|---|---|
| AI 要件の定義 | A | R | C | C | - | C |
| プロンプト設計とチューニング | - | R | R | - | - | - |
| AI 出力品質のテスト | - | C | R | - | R | - |
| セキュリティ/バイアス テスト | - | - | R | - | C | A |
| 本番リリース承認 | A | R | C | R | - | A |
| インシデント対応 | C | R | A | C | C | - |
| モデル ロールバック決定 | A | C | A | R | - | - |
凡例：
- R（責任者）= 実際の作業をする
- A（説明責任者）= 最終的に責任を負う（1 人である必要があります）
- C（相談先）= 決定前に意見を求める
- I（報告先）= 決定後に通知される
3. RACI が必要な重要な決定ポイント
1. プロンプト変更承認
シナリオ：AI チームが出力を改善するためにプロンプトを更新したい
アクティビティ：プロンプト変更承認
責任者：AI エンジニア（変更を提案＋テスト）
説明責任者：製品マネージャー（最終的な可否決定）
相談先：BA（影響分析）、QA（回帰テスト）
報告先：エンジニアリング リード（パフォーマンス影響）
プロセス：
1. AI エンジニアがプロンプト変更 + A/B テスト結果をドラフト
2. BA がレビュー：受け入れ基準への影響はあるか？
3. QA がゴールデン テスト セットで回帰テストを実行
4. 製品マネージャー：承認または拒否
5. 承認された場合：ステージングにデプロイ → 最終 QA テスト → 本番環境
2. セキュリティ閾値決定
アクティビティ：信頼度閾値調整（例：0.75 → 0.80）
責任者：データ サイエンティスト（精度とエスカレーション率のトレードオフを分析）
説明責任者：コンプライアンス / 法務（最終承認、法的リスクを負う）
相談先：BA（ビジネス ワークフローへの影響）、製品（UX への影響）
決定基準：
- accuracy_delta（例：+2%）
- escalation_rate_delta（例：+8%）
- business_impact（コスト、ユーザー体験）
→ 結果を総合、コンプライアンスが決定
3. Go/No-Go 本番リリース
アクティビティ：本番リリース決定
責任者：QA（UAT を実行）、BA（ビジネス基準を検証）
説明責任者：製品マネージャー（最終 go/no-go 決定）
相談先：データ/AI（品質メトリクス）、エンジニアリング（技術準備）
報告先：サポート/オペレーション（エスカレーションに対応する準備はできていますか？）
パスすべき基準：
☐ 精度 ≥ 閾値
☐ 重大な欠陥 0
☐ ビジネスからの UAT サイン オフ
☐ ロールバック手順がテスト済み
☐ モニタリング ダッシュボード実装済み
☐ エスカレーション プレイブック準備完了
4. インシデント対応とエスカレーション
いつ：AI 出力が害をもたらす（誤診断、不正確な財務決定）
重大度レベル → 対応者：
- P0（顧客への害、即座）：CEO/CRO がエスカレーション/一時停止を決定
- P1（重大なバグ）：1 時間以内に製品 + エンジニアリング + コンプライアンス
- P2（軽微なバグ）：4 時間以内に BA + AI チーム
- P3（改善）：定期スプリント バックログ
エスカレーション パス：
ユーザー報告 → QA がチケットをログ
↓
QA 重大度 P0/P1 → 即座に通知
↓
オンコール エンジニア + BA + コンプライアンス
↓
分析：ロールバック？ホットフィックス？監視？
↓
製品が決定：機能一時停止 / ユーザー % 制限 / フル ロールバック
4. BA が記入する RACI テンプレート
# RACI マトリックス：[AI 機能名]
## コア チーム
| 役割 | 名前 | メール | 可用性 |
|------|------|-------|------|
| 製品マネージャー | ... | ... | ... |
| BA | ... | ... | ... |
| データ サイエンティスト | ... | ... | ... |
| AI エンジニア | ... | ... | ... |
| QA リード | ... | ... | ... |
| エンジニアリング リード | ... | ... | ... |
| コンプライアンス オフィサー | ... | ... | ... |
## 決定マトリックス
| 決定 | 責任者 | 説明責任者 | 相談先 | 報告先 | タイムライン |
|------|--------|----------|--------|--------|----------|
| プロンプト設計承認 | AI Eng | 製品 | BA、QA | Eng リード | 開発前 |
| 精度閾値 | Data Sci | コンプライアンス | BA、製品 | AI Eng | UAT 前 |
| UAT サイン オフ | BA | 製品 | QA | 全員 | UAT 終了時 |
| 本番リリース | QA | 製品 | 全員 | オペレーション | リリース日 |
| インシデント > P1 | BA | 製品 | Data Sci、Eng | 全員 | 1 時間以内 |
| ロールバック決定 | Eng リード | 製品 | 全員 | - | 即座 |
5. エスカレーション プレイブック
AI 出力懸念検出
│
├─→ 顧客に影響がある？いいえ
│ └─→ チケットをログ、標準プロセス
│
└─→ はい
├─→ 重大度？
│
├─→ P0（即座の害）
│ ├─→ 即座に一時停止 / AI を 5% に制限
│ ├─→ 製品 + エンジニアリング + コンプライアンスに通知
│ ├─→ インシデント ポストモーテム開始
│ └─→ 決定：ロールバック対ホットフィックス
│
└─→ P1（重大な問題）
├─→ 2 時間以内に調査
├─→ 根本原因 = プロンプト → AI チーム修正 + テスト
├─→ 根本原因 = データ → データ チームがデータ品質を検証
├─→ 不明な場合 → シニアにエスカレーション（BA レビュー）
└─→ 修正を実装 → ステージング テスト → 本番環境
6. 一般的なアンチパターン
❌「全員が決定を所有」→ 遅延、責任転嫌 ✅ 決定ごとに明確な A（説明責任者）所有者
❌「コンプライアンスがすべてをチェック」→ 遅い速度 ✅ セキュリティ クリティカルは A、その他は C
❌「データ品質に R がない」→ バグが漏れる ✅ AI 処理前のデータ検証に明確な R
❌「エスカレーション不明確」→ インシデント管理不十分 ✅ 重大度ごとに明確な所有者を持つエスカレーション プレイブック
まとめ
AI ガバナンスは複雑ではありません：
- 各決定に対して RACI を明確に定義（プロンプト、閾値、リリース、インシデント）
- 明確な説明責任者を割り当て（1 人、委員会ではない）
- 重大度レベル付きエスカレーション パスをドキュメント化
- 四半期ごとにレビュー — チーム/プロセスが変わったら RACI を更新
明確なガバナンスを持つチームは、AI 機能をより速く、自信を持って、説明責任を持って提供します。