AIフィーチャーでインシデントが発生した場合、通常のバグのようにデバッグすることはできません。「モデルが誤った結果を返した」原因は、データ品質の変化、プロンプトインジェクション、分布のシフト、またはインフラの問題である可能性があります。BAは各タイプの分析方法を知っておく必要があります。
1. AI固有のリスクカテゴリ
1.1 AIフィーチャーのリスク分類
| カテゴリ | リスク | 可能性 | 影響 | 軽減策 |
|---|---|---|---|---|
| モデル | 精度劣化（ドリフト） | 中 | 高 | 月次評価、ドリフト検出器 |
| モデル | 高リスクコンテキストでのハルシネーション | 中 | 非常に高い | 人間レビュー閾値、引用要件 |
| データ | 学習データポイズニング | 低 | 非常に高い | データ出所監査、異常検出 |
| データ | モデル出力経由のPII漏洩 | 低 | 非常に高い | 出力スキャン、PIIマスキング |
| バイアス | 差別的な出力 | 中 | 高 | 定期的なバイアス監査、多様なテストセット |
| 運用 | モデルの利用不能（APIダウン） | 中 | 中 | ルールベースへのフォールバック、リトライロジック |
| セキュリティ | プロンプトインジェクション攻撃 | 中 | 高 | 入力サニタイズ、システムプロンプトのロック |
1.2 AIリスクスコアの計算式
リスクスコア = 確率 × 影響度 × 検出困難度
確率：1（まれ）→ 5（頻繁）
影響度：1（軽微）→ 5（重大/法的影響）
検出：1（簡単）→ 5（非常に検出困難）
スコア ≥ 30：クリティカル — 即時軽減計画が必要
スコア 15〜29：高 — ゴーライブ前に軽減が必要
スコア < 15：中/低 — 監視、四半期ごとにレビュー
2. AIリスク登録簿テンプレート
## AIリスク登録簿 — [プロダクト/フィーチャー]
**最終更新：** YYYY-MM-DD | **オーナー：** [BA名]
| ID | リスク | カテゴリ | 確率 | 影響度 | 検出 | スコア | ステータス | 軽減策 | オーナー |
|----|--------|----------|------|--------|------|--------|------------|--------|--------|
| R001 | 3ヶ月後のモデルドリフト | モデル | 3 | 4 | 3 | **36** | 🔴 クリティカル | 月次評価＋アラート | ML Eng |
| R002 | 医療コンテキストでのハルシネーション | モデル | 3 | 5 | 4 | **60** | 🔴 クリティカル | 必須人間レビュー＋引用 | BA＋QA |
| R003 | AI出力内のPII | データ | 2 | 5 | 3 | **30** | 🔴 クリティカル | 配信前出力スキャナー | セキュリティ |
| R004 | APIプロバイダーの障害 | 運用 | 3 | 3 | 1 | **9** | 🟡 中 | フォールバックフロー＋タイムアウト処理 | Dev |
3. AIのインシデント分類
すべての「AIの誤り」がインシデントとは限りません。BAは以下を定義する必要があります：
重大度レベル
| 重大度 | 定義 | 例 | 対応時間 |
|---|---|---|---|
| P0 — クリティカル | AIが直接的な被害を引き起こし、データ漏洩、または誤った法的判断を下す | AIが誤ったローン審査を承認、PII漏洩 | 15分以内 |
| P1 — 高 | AIが機能しない、または精度が20%以上低下 | チャットボットが無意味な回答、分類器の失敗 | 1時間以内 |
| P2 — 中 | 精度が10〜20%低下、一部ユーザーへの影響 | 再現率が90%から75%に低下 | 4時間以内 |
| P3 — 低 | 軽微な不一致、エッジケースの問題 | 一部のエッジケースの不完全な処理 | 次のスプリント |
4. AIのインシデント対応プロセス
[インシデント検出]
（モニターアラート / ユーザーからのクレーム / エージェントのエスカレーションによる）
↓
[BAが15分以内に重大度を確認]
├── P0/P1：インシデント対応チームを起動
│ ├── 通知：ステークホルダー＋法務（必要な場合）
│ ├── アクション：フィーチャーフラグをOFF、またはロールバック
│ └── ウォールーム：BA＋ML Eng＋PM
└── P2/P3：通常のスプリントプロセス＋トラッキング
↓
[根本原因分析 — 確認すべき4種類]
1. モデルの問題（ドリフト、再トレーニングが必要か？）
2. データの問題（入力の分布が変わったか？）
3. インフラの問題（APIエラー率が増加したか？）
4. 攻撃的行為（プロンプトインジェクション、悪用？）
↓
[軽減策＋修正]
↓
[48時間以内の事後分析（P0/P1）]
5. AIインシデント事後分析テンプレート
# AIインシデント事後分析
**インシデントID：** INC-YYYY-XXX
**重大度：** P[0-3]
**日付：** YYYY-MM-DD
**期間：** X時間Y分
**影響を受けたフィーチャー：** [AIフィーチャー名]
## タイムライン
| 時刻 | イベント |
|------|---------|
| HH:MM | インシデントが[誰/システム]によって最初に検出された |
| HH:MM | BAに通知 |
| HH:MM | フィーチャーを無効化/軽減策を適用 |
| HH:MM | 根本原因を特定 |
| HH:MM | インシデントが解決された |
## 根本原因
**主要：** [技術的な説明]
**寄与因子：** [リスト]
## 影響
- 影響を受けたユーザー：[N]名
- 誤った意思決定：[N]件（ある場合）
- ビジネスへの影響：[$X / SLA違反 / 評判]
## うまくいったこと
- [検出が迅速だった]
- [ロールバックがスムーズだった]
## 改善が必要なこと
- [検出のギャップ：Xが発生したがアラートが発火しなかった]
- [対応：Yに時間がかかりすぎた]
## アクションアイテム
| アクション | オーナー | 期限 | 優先度 |
|--------|-------|----------|----------|
| [条件]のアラートを追加 | ML Eng | [日付] | P1 |
| HITLの閾値をXからYに更新 | BA | [日付] | P2 |
| 修正済みラベルでモデルを再トレーニング | ML Eng | [日付] | P1 |
6. プロアクティブなリスクレビューの頻度
| 頻度 | 活動 | オーナー |
|---|---|---|
| 週次 | P0/P1リスクアイテムをレビュー | BA |
| 月次 | ベースラインに対するモデルパフォーマンス評価 | BA＋ML Eng |
| 四半期 | AIリスク登録簿の全面レビュー | BA＋PM＋セキュリティ |
| スプリントごと | 新しいAIフィーチャーのレッドチームセッション | BA＋QA |
まとめ
AIのリスクとインシデント分析は、通常のIT運用とは異なります。BAはAI固有の障害モードを理解し、最新のリスク登録簿を維持し、AIが誤った場合のエスカレーションパスを把握する必要があります。AIインシデントが「発生するかどうか」ではなく、「いつ発生するか」という問題であり、あなたが準備できているかどうかが重要です。