AIインシデント対応Playbook：AIが失敗したときの対応方法

AIチャットボットが、顧客に受け取る権利のない返金があると告げます。AIサマリーツールがデューデリジェンスレビュー中に重要な契約条項を見落とし、その見落としが署名後まで発覚しません。AIリードスコアリングモデルが最も価値の高い見込み客を誤った担当者にルーティングし始め、3週間誰も気づきません。

これらはAIインシデントです。そして、チームがすでに対処方法を知っているITインシデントとは異なります。

インシデント対応プロセスはその違いを理解していますか？していなければ、誤ったシグナルへの対応が遅くなり、間違ったことをエスカレーションし、誰も気づかないまま何百件もの判断に静かに影響している問題を見逃します。

このPlaybookは、最初のAI固有のインシデント対応能力を構築している、または既存のプロセスが十分かどうか監査している最高情報責任者（CIO）、セキュリティリード、トランスフォーメーションチームのためのものです。承認されたAIの範囲を定義する AIユーセージポリシーの構築 および調査の証拠基盤を提供する AI Executeアクションの監査証跡 と連携しています。

AIインシデントがITインシデントと異なる理由

Key Facts: AIインシデントのリスク

• GDPR Article 33は、個人データ侵害を認識してから72時間以内に関連する監督機関への通知を要求します。72時間のタイマーは組織が認識した時点から始まり、調査が完了した時点からではありません（GDPR Article 33）
• AIインシデントのカテゴリにはハルシネーション、Executeエラー、バイアス、データ露出、モデルドリフトが含まれます。従来のITインシデント対応（二元的な稼働/停止の障害を前提に構築された）は、検出されるまで何百件もの判断に影響し続けるAI障害の潜在的・確率的な性質を見落とします（NIST Cybersecurity Frameworkの研究）
• Gartnerは2027年までにエージェント型AIプロジェクトの40%以上がキャンセルされると予測しており、ガバナンスフレームワークが主因として追いついていないとしています。インシデント対応インフラは最も欠けているガバナンスコンポーネント3つの一つです（Gartner、2025年）

従来のITインシデント対応はシンプルなモデルを前提に構築されています：システムは稼働しているかダウンしているかです。サーバーがオフラインになる、サービスが500エラーを返す、ネットワークリンクが失敗する。インシデントは二元的で即時的です。検出は速く、通常は自動化されています。修正は技術的です：サービスを復元する。

AIインシデントはそのように機能しません。NIST Cybersecurity FrameworkのRespond機能は、インシデント対応を検出されたイベントの影響を封じ込めて管理することと説明していますが、CSFは二元的で検出可能な技術的障害を前提に設計されています。AIインシデントには大幅に異なる検出と対応のモデルが必要です。

確率的です。 「ほとんどの場合」は正常に機能しているAIシステムが、特定のサブポピュレーションの入力に対して誤った判断をしている可能性があります：特定の顧客セグメント、特定のドキュメントタイプ、特定の言語。全体的な精度指標は許容範囲に見えます。しかし端の部分では深刻な失敗が起きています。

潜在的です。 バイアスのかかったスコアリングモデル、ハルシネーションするナレッジベース、プロンプトインジェクションの脆弱性は、誰かが気づく前に何週間または何ヶ月もその状態で動いている可能性があります。ITインシデントの類似は、完全にクラッシュするのではなく、3%の確率でデータを静かに破損しているサーバーです。

重大な影響が出るまでしばしば見えません。 顧客に誤った情報を送るAI、採用での差別的な判断をするAI、プロンプトコンテキストにデータを漏洩させるAIは500エラーを生成しません。顧客の苦情、規制当局からの問い合わせ、または記者からの電話を生成するかもしれません。これがガバナンスの失敗モードの一つで、それ以外は十分な資金が投じられたAIトランスフォーメーションを脱線させます。

根本原因の特定が難しくなります。 ITインシデントは技術的な根本原因を持ちます：設定ミス、コードのバグ、ハードウェア障害。AIインシデントはモデルの挙動（このタイプの入力に対してモデルは常に失敗するはず）、プロンプト設計（特定のエッジケースでプロンプトが一致しない）、データ品質（学習または取得データが誤っていた）、統合の失敗（正しいアウトプットが生成されたが外部のExecuteシステムとの統合が失敗した）、またはユーザーの挙動（人間が設計されていない方法でツールを使い始めた）から生じる可能性があります。

それぞれの根本原因タイプは異なる対応を必要とします。

「AIインシデントは500エラーで自己申告しません。バイアスのかかったスコアリングモデルは誰かが気づく前に何ヶ月も動き続けることがあります。顧客に誤った情報を送るAIはクラッシュしません。顧客の苦情を生みます。ITの障害に対して機能するインシデント対応プロセスは、AI障害の大多数が危機になるまで見落とします。」（Rework）

4タイプAIインシデント分類体系

AIインシデントを根本原因タイプ別に分類し、より速い診断とより的確な対応を可能にするフレームワーク。Type 1（ハルシネーション）：AIが実際に対処された事実に基づかないコンテンツを生成した。Type 2（Executeエラー）：AIが現実世界に結果をもたらすアクションを誤って実行した。Type 3（バイアス）：AIがサブポピュレーションに影響する体系的に差別的な判断を下した。規制上の露出が最も深刻。Type 4（データ露出）：プロンプトの入力またはAIアウトプットが保護されるべき情報を明らかにした。GDPR Article 33の72時間通知義務を発動する可能性がある。Type 5（モデルドリフト）：単一の検出可能な障害の瞬間なしにAIのパフォーマンスが時間とともに低下している。最も見落とされやすいインシデントタイプ。各タイプは異なる検出シグナル、対応タイムライン、根本原因調査のアプローチを持ちます。間違ったインシデントタイプに対して誤った対応プロトコルを使用すると、解決が遅くなり体系的な問題を見落とす可能性があります。

AIインシデント分類体系

AIインシデントに対応する前に、どのタイプのインシデントかを知る必要があります。

Type 1：ハルシネーションインシデント

AIが実際に対処された事実に基づかないコンテンツを生成し、それに基づいてアクションが取られました。顧客が保険のカバレッジについて誤った情報を受け取りました。サポートエージェントがAI生成の回答を使ってチケットを誤って解決しました。AIが書いた文書に捏造された引用が含まれていました。

検出シグナル：顧客の苦情、内部品質レビュー、社員の報告、誤った情報に基づいてアクションした結果起きたダウンストリームシステムのエラー。

対応における主な問い：アウトプットは使用前にレビューされたか？これは単発か、それともモデルはこのタイプの質問で一貫してハルシネーションするか？修正するプロンプト変更はあるか？

Type 2：Executeエラー

AIが重大なアクションを誤って実行しました。これは最も時間的に緊急なインシデントタイプです。Executeアクションは世界の状態を変えるからです。誤った返金が発行された。メールが誤った受信者リストに送信された。CRMレコードが誤ったデータで更新された。起動すべきでなかったワークフローがトリガーされた。

検出シグナル：顧客の苦情、財務調整の不一致、ダウンストリームプロセスのエラー、社員の報告。

対応における主な問い：アクションを取り消せるか？取り消せる場合、誰がどのように権限を持つか？誰が影響を受けたか？根本原因はAIモデルにあるか、トリガーロジックにあるか、AIアウトプットと外部システムの統合にあるか？

Type 3：バイアスインシデント

AIが体系的に差別的な判断を下しました。スコアリングモデルが特定の人口統計グループの候補者を不釣り合いに却下にルーティングしました。信用に隣接するAIが保護されたクラスに対して異なる割合で申請を却下しました。採用AIが保護された特性と相関する要因に基づいて候補者をフィルタリングしました。

検出シグナル：成果の人口統計監査、社員の報告、規制当局からの問い合わせ、影響を受けた個人からの法的異議申し立て。

対応における主な問い：このバイアスでシステムはどのくらいの期間動いていたか？何人の個人が影響を受けたか？影響を受けた当事者にはどのような救済が必要か？このモデルはまだ本番環境にあるか？

このインシデントタイプは最も深刻な規制上の露出を持ちます。法務顧問には直ちに関与させなければなりません。

Type 4：データ露出インシデント

プロンプトの入力またはAIアウトプットが保護されるべき情報を明らかにしました。顧客AのデータがBの顧客のAIレスポンスに現れました。社員の個人データが権限のないユーザーがアクセスできるプロンプトコンテキストに含まれていました。機密の社内データが受け取る権限のないベンダーのAIシステムに送信されました。

検出シグナル：別のユーザーのデータを見たという顧客の苦情、内部監査、社員の報告、データ分類違反の監視アラート。

対応における主な問い：どのデータが露出したか？誰に対して？個人識別情報（PII）、保護された健康情報（PHI）、財務データ、または機密ビジネスデータか？これは単発のイベントか体系的な欠陥か？

GDPR Article 33の注意：露出がEU在住者の個人データを含む場合、関連する監督機関への72時間の通知義務が生じる可能性があります。これは任意ではありません。タイマーはインシデントを認識した時点から始まり、調査が完了した時点からではありません。

Type 5：モデルドリフト

AIのパフォーマンスが誰も気づかないまま時間とともに低下しています。Q1で78%の精度だったスコアリングモデルがQ3では61%の精度になっています。正しいドキュメントを返していた取得システムが今は古いものを返しています。許容範囲だった生成品質がモデルまたは取得コンテキストの変化とともに低下しています。

検出シグナル：モニタリング指標（構築していれば）、ビジネス成果指標（リードのコンバージョン率の低下、顧客満足度の低下、サポートチケットの解決品質の低下）、AIが「以前ほど良くない」という社員の報告。

これは最も見落とされやすいインシデントタイプです。単一の障害の瞬間がないからです。積み重なっていきます。

4階層対応フレームワーク

インシデントタイプを特定したら、階層が誰が対応するか、どのくらいの速さで、最初に何をするかを決めます。

Tier 4：調査

基準： 外部露出なし、まだ顧客への影響なしの内部AIアウトプットエラー。内部品質レビュー中に発見されたハルシネーション。誤っていたが対処されなかったGenerateアウトプット。成果に影響を与える前に内部モニタリングで検出されたモデルドリフト。

対応期間： 初期評価まで24時間。

対応者： AIシステムを担当するチーム。評価で外部露出が明らかにならない限りエスカレーション不要。

アクション： AIリスクレジスターにインシデントを文書化する。根本原因を特定する。問題が体系的か単発かを評価する。修正または回避策を実施する。インシデント後レビューをスケジュールする。

Tier 3：封じ込め

基準： 顧客向けの誤ったアウトプットで、顧客が対処しなかった。チャットボットのレスポンスが誤っていたが顧客が対処しなかった。誤った情報を含む下書きメールが送信前にキャッチされた。

対応期間： 封じ込め決定まで4時間。

対応者： チームリードとITセキュリティ担当者。管理職への通知（Tier 2以上にならない限りCIOへのエスカレーション不要）。

アクション： 問題を封じ込める（影響を受けたAI機能が誤ったアウトプットを出し続けている場合は無効化する）。範囲を評価する：この顧客が影響を受けたか、または他にも可能性があるか？文書化する。顧客への積極的なコミュニケーションが必要かどうかを判断する（通常Tier 3では不要。ただし誤ったアウトプットが後で顧客が対処した場合に害を与える可能性がある場合を除く）。

Tier 2：インシデント対応

基準： 顧客向けのExecuteエラー、封じ込められたデータ露出インシデント、顧客が対処したハルシネーション。

対応期間： 初期対応まで1時間、解決まで継続的な管理。

対応者： CIOとセキュリティリードに1時間以内に通知。法務顧問は待機状態。コミュニケーションチームは顧客通知の下書きに関与。

アクション： 影響を評価する（顧客何人、どのデータ、どのアクションが取られた）。封じ込める（影響を受けたワークフローを無効化し、可能であればExecuteアクションを取り消す）。顧客コミュニケーション計画：影響を受けた顧客に通知する必要があるか？何を知らせる必要があるか？規制上の通知評価：これはGDPR Article 33の通知が必要な侵害に該当するか？すべてをリアルタイムで文書化する。

Tier 1：危機

基準： 規制上の露出が確認または確実、大規模な顧客への影響、影響を受けた個人を持つバイアスインシデント、大規模な機密個人データの露出。

対応期間： 即時。最高経営責任者（CEO）と法務顧問は最初の1時間以内に状況を把握しなければなりません。

対応者： 経営幹部、法務顧問、外部コミュニケーション、該当する場合は規制担当者。

アクション： 調査完了まで全面的にAIシステムを停止するかどうかの経営判断。外部法律事務所の起用。顧客と規制当局向けコミュニケーションの下書きとレビュー。危機後のレビューをスケジュールする。EUの個人データが関与し、侵害が通知対象の場合、GDPR Article 33のもとでの72時間のタイマーが動いています。

GDPR Article 33と通知要件

GDPR Article 33は、侵害が「自然人の権利と自由に対するリスクを生む可能性が低い」場合を除き、個人データ侵害を認識してから72時間以内に関連する監督機関への通知を求めています。

AIインシデントが個人データ侵害になりうるのは：

• AIシステムが個人データを処理した結果、不正な開示が生じた場合
• 個人データを含むAIアウトプットが権限のない受取人に送信された場合
• AIシステムがデータ主体に開示されていない方法で個人データを使って自動意思決定を行った場合
• プロンプトインジェクションまたは他の悪用によりデータ流出が発生した場合

72時間のタイマーは、侵害を認識した時点から始まり、調査が完了した時点からではありません。「インシデントを認識しており、調査中です」という初期通知を提出し、後で補足することができます。調査が完了するまで通知を待つことはコンプライアンス違反です。

規制対象産業で米国拠点の組織については、類似の要件が存在します：PHI侵害に対するHIPAA侵害通知規則、重要なサイバーセキュリティインシデントに対するSECサイバーセキュリティ開示規則、および州レベルの侵害通知法。

インシデント後のレビュー：AI根本原因分析

AIインシデントのインシデント後レビューは、標準的なIT事後レビューとは異なる構造に従います。

ITの事後レビューが問うのは：どの技術的障害が障害を引き起こしたか？技術的障害を修正し、サービスを復元する。

AIのインシデント後レビューが問う4つの問い：

これはモデルの障害だったか？ AIが誤ったアウトプットを生成したのは、基盤モデルが誤っていたか、ハルシネーションしていたか、またはこのタイプの入力でパフォーマンスが低かったためか？Yesの場合：再発を防ぐプロンプトの変更、取得の改善、またはモデルの更新はあるか？このモデルはこのユースケースに引き続き使用すべきか？

これはプロンプトまたは設計の障害だったか？ AIが誤ったアウトプットを生成したのは、プロンプトが曖昧だったか、コンテキストウィンドウが不十分だったか、またはワークフローがこの入力を処理するように設計されていなかったためか？Yesの場合：これは最も修正しやすい根本原因であることが多いです。プロンプトテンプレートを再設計し、入力検証を追加するか、ガードレールを追加してください。

これはデータの障害だったか？ AIが誤ったアウトプットを生成したのは、取得データが古かったか、学習データにバイアスがあったか、または入力データが正しくない形式だったためか？Yesの場合：モデルではなくデータガバナンスが修正策です。

これは統合の障害だったか？ AIは正しいアウトプットを生成したが、AIシステムとダウンストリームのExecuteシステムとの統合が失敗したか？Yesの場合：AIガバナンスの根本原因はエンジニアリングの統合修正ほど重要ではありません。しかしまた：Executeの前にこれをキャッチすべき人間のレビューステップがあったか？

根本原因をAIリスクレジスターに文書化してください。関連するAIガバナンス文書を更新してください。インシデントで人間介在設計のギャップが明らかになった場合、そのギャップを修正してください。

報告文化の構築

AIインシデント対応プログラムで最も危険なギャップはPlaybookではありません。問題を見て報告しない社員です。

先週、AIチャットボットが誤った返金情報を提供していることに気づいた社員。AIアウトプットログで異常なパターンを見たが重要かどうかわからなかったエンジニア。AI生成の推薦に関する苦情を聞いたが単発のことだと思ったカスタマーサクセスマネージャー。

これらはすべて早期のシグナルです。危機になるほとんどのAIインシデントは、見られていたが対処されなかったシグナルとして始まりました。

報告文化の構築は3つのことを意味します：

報告を簡単にする。 社内チャンネル一つ、フォーム一つ、メールアドレス一つ。社員が潜在的なAIの問題を報告するために組織図を辿る必要はないはずです。

報告を安全にする。 問題を報告した社員はインシデントや誤検知に対して責任を問われてはなりません。報告に対する対応は、たとえ非インシデントと判明しても「フラグを立ててくれてありがとう」であるべきです。報告者が責任を感じると、報告しなくなります。

報告を可視化する。 報告が本当のインシデントを早期に発見することにつながったとき、チームに伝えてください。「重大なインシデントがありました」ではなく「先週誰かが異常をフラグしたおかげで、顧客に影響が出る前に問題をキャッチできました」と。報告が重要だという社会的証拠は、どんなトレーニングプログラムよりも早く習慣を構築します。

ガバナンス文書、監査証跡、対応階層はすべて、インシデントが発生した後に管理するために存在します。報告文化は、問題を早期に発見するか遅くなってから発見するかを決めるものです。

このPlaybookが置き換えるものと置き換えないもの

このPlaybookはAI固有のインシデント対応を管理します。既存のITインシデント対応プロセス、GDPR（一般データ保護規則）またはCCPA（カリフォルニア州消費者プライバシー法）のもとでのデータ侵害対応プロセス、または差別関連の苦情に対するHRインシデントプロセスの代わりにはなりません。それらのプロセスは引き続き適用されます。AIの障害とデータ侵害の両方を含むインシデントでは、両方のPlaybookが並行して動きます。

このPlaybookを監査証跡フレームワークに接続してください（インシデント調査中に必要な証拠を提供します）。AIユーセージポリシーに接続してください（AIアクションの承認範囲を定義します）。そしてAIリスクレジスターに接続してください（過去のインシデントからの既知のリスクパターンが文書化され、将来のインシデントをより速く検出できるようにします）。

Rework分析： エンタープライズAIのインシデントパターンに基づくと、軽微なAIインシデントが危機にエスカレーションする最も一般的な理由はインシデント自体ではなく、検出の遅れです。スコアリングモデルのアウトプットの15%に影響するバイアスインシデントは、ビジネス指標に現れるまで8〜12週間動き続けることがあります。共有AIコンテキストでのデータ露出は、顧客が別のユーザーのデータを見たと報告するまで表面化しないかもしれません。このPlaybookの報告文化セクションが存在するのは、最も速い検出メカニズムが何かを気づいて報告した人間だからです。検出の遅れの1週間ごとに、規制上の露出、影響を受けた顧客の数、そして救済の複雑さが積み重なります。

目標は、一度も使う必要のないPlaybookを持つことではありません。必要なときに準備できていることです。

そして最もクリーンなインシデント対応を行う企業は、最初のインシデントの前から報告文化を構築したものです。だから本当の問いは：チームは何か問題を見たとき、どこに行けばいいかわかっていますか？

関連記事：

• AI承認ゲートとベンダーレビュー：このPlaybookが必要になる頻度を減らす事前展開ゲート
• AIアクセスのためのデータ分類ルール：Type 4インシデントが侵害通知を必要とするかどうかを判断するデータ階層フレームワーク
• Stage 3から4：ScaledからIntegratedへ：Stage 4でフォーマルなインシデント対応が必須となる理由
• 18ヶ月CEO AIアジェンダ：トランスフォーメーションロードマップのPhase 1にインシデント対応インフラがどこに位置づけられるか