ストーリー
田
田中VPoE
ガイドラインと教育を整備しても、AIインシデントはゼロにはならない。重要なのは、発生した時にいかに迅速かつ適切に対応できるかだ
あなた
従来のITインシデント対応と何が違うんですか?
あ
田
田中VPoE
AIインシデントは原因の特定が難しい。「なぜその回答が生成されたのか」の再現が困難な場合がある。また、バイアスやハルシネーションなどAI特有の問題カテゴリがある
あなた
AI専用のインシデント対応フローが必要なんですね
あ
AIインシデントの分類
インシデントカテゴリ
| カテゴリ | 説明 | 例 | 深刻度 |
|---|
| データ漏洩 | 機密・個人情報の意図しない出力 | 他顧客の情報を含む回答 | CRITICAL |
| 有害出力 | 差別的・攻撃的・不適切な生成 | 差別的なレコメンド | HIGH |
| ハルシネーション | 事実と異なる情報の生成 | 存在しない商品の案内 | MEDIUM-HIGH |
| バイアス | 特定グループへの不公平な処理 | 性別による価格差異 | HIGH |
| サービス障害 | AI機能の停止・劣化 | レスポンス遅延、エラー率増 | MEDIUM |
| セキュリティ | プロンプトインジェクション等 | システムプロンプトの漏洩 | HIGH |
インシデント対応フロー
5フェーズの対応プロセス
Phase 1: 検知・報告(0-1時間)
├── 自動検知(アラートシステム)
├── ユーザー報告(インシデント報告フォーム)
└── 初期トリアージ(深刻度判定)
│
Phase 2: 初動対応(1-4時間)
├── インシデント対応チーム招集
├── 影響範囲の特定
├── 必要に応じてサービス停止/制限
└── ステークホルダーへの第一報
│
Phase 3: 調査・分析(4-48時間)
├── 監査ログの確認
├── 入出力データの分析
├── 根本原因の特定
└── 再現テスト
│
Phase 4: 是正・復旧(1-7日)
├── 修正の実装(プロンプト/フィルター/モデル)
├── テストと検証
├── サービス復旧
└── 影響を受けたユーザーへの対応
│
Phase 5: 事後対応(1-2週間)
├── インシデントレポート作成
├── 再発防止策の策定
├── プロセス・ガイドラインの更新
└── 関係者への共有・教育
深刻度別の対応SLA
| 深刻度 | 初動 | 影響評価 | 是正完了 | エスカレーション |
|---|
| CRITICAL | 30分以内 | 2時間以内 | 24時間以内 | CTO + 法務即時 |
| HIGH | 1時間以内 | 4時間以内 | 48時間以内 | AI倫理委員会 |
| MEDIUM | 4時間以内 | 24時間以内 | 1週間以内 | AI推進チーム |
| LOW | 翌営業日 | 3営業日以内 | 2週間以内 | 担当チーム |
インシデント対応チームの構成
RACI マトリクス
| 活動 | インシデント対応リーダー | エンジニア | AI倫理担当 | 法務 | 広報 |
|---|
| 検知・トリアージ | A | R | I | I | I |
| 初動対応 | A | R | C | C | I |
| 技術調査 | C | A,R | C | I | I |
| 影響評価 | A | C | R | C | I |
| 是正実装 | C | A,R | C | I | I |
| 外部対応判断 | C | I | C | A | R |
| レポート作成 | A | R | R | C | I |
AIインシデントの調査手法
監査ログベースの調査
class IncidentInvestigator:
"""AIインシデントの調査支援"""
def __init__(self, audit_service, log_service):
self.audit = audit_service
self.logs = log_service
def investigate(self, incident_id: str, time_range: tuple) -> dict:
"""インシデントを調査"""
# 1. 該当時間帯のログを取得
related_logs = self.audit.find_by_timerange(*time_range)
# 2. エラーパターンの分析
error_patterns = self._analyze_error_patterns(related_logs)
# 3. 影響を受けたユーザーの特定
affected_users = self._identify_affected_users(related_logs)
# 4. 根本原因の候補特定
root_causes = self._identify_root_causes(related_logs)
return {
"incident_id": incident_id,
"total_affected_requests": len(related_logs),
"affected_users": len(affected_users),
"error_patterns": error_patterns,
"root_cause_candidates": root_causes,
"timeline": self._build_timeline(related_logs)
}
def _analyze_error_patterns(self, logs: list) -> list:
"""エラーパターンを分析"""
patterns = {}
for log in logs:
if log.error_occurred:
key = f"{log.error_type}:{log.model_name}"
patterns[key] = patterns.get(key, 0) + 1
return sorted(
[{"pattern": k, "count": v} for k, v in patterns.items()],
key=lambda x: x["count"], reverse=True
)
def _identify_affected_users(self, logs: list) -> set:
"""影響を受けたユーザーを特定"""
return {log.user_id for log in logs if log.error_occurred or log.confidence_score < 0.5}
def _identify_root_causes(self, logs: list) -> list:
"""根本原因の候補を特定"""
causes = []
# モデル変更の確認
model_versions = {log.model_version for log in logs}
if len(model_versions) > 1:
causes.append("モデルバージョンの変更")
# プロンプト変更の確認
prompt_ids = {log.prompt_template_id for log in logs}
if len(prompt_ids) > 1:
causes.append("プロンプトテンプレートの変更")
# 入力データの変化
# (信頼度スコアの急落を検知)
scores = [log.confidence_score for log in logs]
if scores:
avg = sum(scores) / len(scores)
if avg < 0.7:
causes.append("入力データの品質変化またはモデル劣化")
return causes
def _build_timeline(self, logs: list) -> list:
"""イベントタイムラインを構築"""
events = []
for log in sorted(logs, key=lambda x: x.timestamp):
if log.error_occurred:
events.append({
"time": log.timestamp.isoformat(),
"event": f"エラー: {log.error_type}",
"user": log.user_id
})
return events
インシデントレポートのテンプレート
| セクション | 内容 |
|---|
| 概要 | インシデントの要約、深刻度、影響範囲 |
| タイムライン | 発生→検知→初動→調査→是正の時系列 |
| 影響分析 | 影響を受けたユーザー数、データ、サービス |
| 根本原因 | 技術的原因と組織的原因の分析 |
| 是正措置 | 実施した対策と効果の確認 |
| 再発防止策 | 短期・中期・長期の再発防止策 |
| 教訓 | 今後に活かすべき教訓 |
まとめ
| 要素 | ポイント |
|---|
| 分類 | AI特有のインシデントカテゴリを定義 |
| 対応フロー | 5フェーズ(検知→初動→調査→是正→事後) |
| SLA | 深刻度に応じた対応時間の基準 |
| 調査手法 | 監査ログベースの体系的調査 |
| レポート | 根本原因分析と再発防止策を含む |
チェックリスト
次のステップへ
次は継続的改善の仕組みを学び、ガバナンス全体のPDCAサイクルを確立します。
推定読了時間: 30分