ストーリー

AIシステム固有のインシデント類型

インシデント分類

インシデント別の危険度マトリクス

          影響度
    低    中    高    極大
  ┌─────┬─────┬─────┬─────┐
高│     │品質 │ハルシ│     │   発
  │     │急劣化│ネーション│     │   生
  ├─────┼─────┼─────┼─────┤   頻
中│     │     │バイ │     │   度
  │     │     │アス │     │
  ├─────┼─────┼─────┼─────┤
低│モデル│     │プロンプト│データ│
  │障害 │     │インジェ│漏洩 │
  │     │     │クション│     │
  └─────┴─────┴─────┴─────┘

AI障害の影響範囲評価

影響範囲の特定手順

AIインシデントでは「誰が、いつ、何を受け取ったか」を特定することが重要です。

影響度スコアリング

# 影響度スコアの計算例
def calculate_impact_score(incident):
    severity_weight = {
        "data_leak": 10,
        "hallucination_critical": 8,  # 法務・医療等の重要領域
        "bias_exposure": 7,
        "prompt_injection": 6,
        "hallucination_general": 4,
        "quality_degradation": 3,
        "model_outage": 2,
    }

    score = (
        severity_weight[incident.type]
        * incident.affected_users
        * incident.duration_hours
    )

    # 高リスクドメインの場合は係数を上げる
    if incident.domain in ["legal", "medical", "financial"]:
        score *= 2.0

    return score

AIインシデント対応プレイブック

フェーズ1: 検知

フェーズ2: トリアージ

インシデントの深刻度を判定し、対応レベルを決定します。

フェーズ3: 緩和

緩和アクションの判断フロー:

インシデント検知
  │
  ├── データ漏洩？ ──Yes──→ 即座にサービス停止
  │                         ├── 漏洩データの範囲特定
  │                         └── 法務・コンプライアンス通知
  │
  ├── 安全性違反？ ──Yes──→ フォールバックモードへ切替
  │                         ├── ガードレールの強化
  │                         └── 問題パターンのブロックルール追加
  │
  ├── ハルシネーション？─Yes→ 問題カテゴリの回答を制限
  │                         ├── RAGソースの検証
  │                         └── 「確認中」メッセージへの切替
  │
  └── 品質劣化？ ──Yes──→ 前バージョンへのロールバック検討
                           ├── モデルバージョンの確認
                           └── プロンプト変更の巻き戻し

フェーズ4: 根本原因分析

フェーズ5: 再発防止

モデルのロールバック手順

ロールバック戦略

AIシステムのロールバックは、従来のソフトウェアより複雑です。複数のコンポーネントが関連するためです。

# ロールバック手順書の例
rollback_procedure:
  pre_checks:
    - name: "ロールバック先バージョンの確認"
      command: "git log --oneline -5 -- prompts/"
    - name: "現在のトラフィック量確認"
      command: "kubectl get hpa ai-service"

  steps:
    - name: "フィーチャーフラグで新プロンプトを無効化"
      action: "feature_flag.disable('prompt-v3')"
      rollback_time: "即座"

    - name: "モデルバージョンの切り替え"
      action: "kubectl set env deploy/ai-service MODEL_VERSION=v2"
      rollback_time: "2-3分"

    - name: "RAGインデックスの復元"
      action: "restore_index_snapshot('2025-01-15')"
      rollback_time: "10-30分"

  post_checks:
    - name: "品質スコアの確認"
      command: "python scripts/quick_eval.py --suite=smoke"
    - name: "エラー率の確認"
      command: "kubectl logs -l app=ai-service --since=5m | grep ERROR"

コミュニケーションプラン

ステークホルダー別の通知

インシデント報告テンプレート

# AIインシデント報告

## 基本情報
- インシデントID: AI-INC-2025-042
- 発生日時: 2025-01-20 14:30 JST
- 検知日時: 2025-01-20 14:35 JST
- 深刻度: SEV2
- 類型: ハルシネーション（重要領域）

## 影響範囲
- 影響ユーザー数: 約150名
- 影響リクエスト数: 約320件
- 影響時間: 約2時間（14:30-16:30）

## 経緯
- 14:30 モデルプロバイダーのマイナーバージョン更新が適用
- 14:35 品質モニタリングがスコア低下を検知、P2アラート発報
- 14:45 オンコール担当が調査開始
- 15:00 原因をモデル更新と特定、ロールバック開始
- 16:30 ロールバック完了、品質スコア回復を確認

## 根本原因
- モデルプロバイダーのマイナーバージョン更新により、
  特定ドメインの回答精度が低下

## 対策
- [ ] モデルバージョンの固定（ピンニング）
- [ ] モデル更新の自動検知アラートの追加
- [ ] 新バージョンの自動回帰テスト導入

まとめ

チェックリスト

• AIシステム固有のインシデント類型を理解した
• AI障害の影響範囲評価の手順を理解した
• 5フェーズのインシデント対応プレイブックを理解した
• モデルのロールバック手順を理解した
• ステークホルダー別のコミュニケーションプランを理解した

次のステップへ

次は演習です。ここまで学んだLLMOps、モニタリング、インシデント対応の知識を統合して、AI運用設計書を作成しましょう。

推定読了時間: 15分