AIインシデントには新たな対応手順が必要 ― その構築方法とは

組織の71%が「AIが基幹業務システムにアクセスできる状態にある」と回答している一方、そのアクセスを効果的に統制できているのはわずか16%にとどまります。これは2026年版CISO AIリスクレポートによる調査結果です。自社のIR(インシデント対応)チームに次の3つを問いかけてみてください。AIシステムの一覧は把握できているか。本番稼働中のモデルが有害な出力を生成し始めたらどうなるか。そのシステムを停止させる権限は誰が持っているか。

筆者はエネルギー、銀行、通信、製造業と、14年にわたりセキュリティ分野に携わってきました。レッドチーム業務や検知プログラムの構築に従事し、ここ数年はAIリスクとシャドーAIに焦点を当てています。その中で一貫して目にしてきたのは、AIを本番環境で運用し、IR対応手順も整備しているにもかかわらず、両者が実際には連動していないと思い込んでいる組織の姿です。実際には連動していません。

自社のIR対応手順がAIインシデントをカバーしていると考えているCISOは、おそらくまだそれをテストしていません。テストを行ったCISOは、カバーできていないという事実を知っています。

AIインシデントの2つの種類 ― リストよりも重要な分類の違い

AIインシデントは2023年から2024年にかけて56.4%増加し、記録された事例は233件に達しました。NIST SP 800-61、MITRE ATLAS、GLACIS AI Incident Response Playbookをはじめとする多くのIRフレームワークは、6種類のインシデント分類を提示するにとどまっています。これらは有用ではあるものの、より重要な区別を見落としています。それは、モデル自身が引き起こす障害と、人間が引き起こす障害の違いです。この2つのグループでは、検知アプローチも封じ込めのロジックも、法的リスクの性質もまったく異なります。

モデル自身に起因する障害 ― 性能劣化、バイアス、ハルシネーション ― は、システムが設計どおりに機能しているにもかかわらず、その結果が芳しくない場合に発生します。米国の数百の病院で導入されていたEpic Sepsis Model(敗血症予測モデル)は、外部検証において感度がわずか33%しかありませんでした。実際の敗血症症例の3分の2を見逃す一方、医師には誤警報が殺到していたことが、2021年のJAMA Internal Medicine誌の研究で明らかになっています。誰かが攻撃したわけではありません。ダッシュボード上ではすべて正常を示したまま、システムはひそかに機能しなくなっていたのです。

外部要因による障害 ― 敵対的攻撃、データポイズニング、プライバシー侵害 ― は、何者かが入力データや学習環境を汚染することで発生します。NHTSA(米国運輸省道路交通安全局)が数十万台の車両を対象に調査したTeslaのオートパイロットにおける「幻の急ブレーキ」事例は、安全性が最重要視されるシステムにおいて敵対的入力による障害がどのような形を取るかを示しています。この2つのグループには、それぞれ異なる主要な防御策と、独自の対応手順が必要です。

さらに、現時点で最も法的リスクが大きいのがハイブリッド型のケースです。ハルシネーションはモデル起因の問題でありながら、法廷では人為的ミスと同様に扱われます。Air Canadaのチャットボットが存在しない忌引き運賃制度を作り出した際には、同社に責任があるとの判断が下されました。また、米連邦裁判所がMobley対Workday訴訟の審理継続を認めた際には、AI採用プラットフォームがそれを利用する雇用主の「代理人」として直接責任を負い得るとの見解が示されました。いずれのケースも、当初はセキュリティインシデントには見えませんでした。しかし最終的には、どちらも法的な問題へと発展しています。もし法務部門が自社のIRコールツリーに含まれていないなら、その対応手順はすでに不完全だと言えます。

CIAトライアッドではハルシネーションをカバーできない

機密性・完全性・可用性からなるCIAトライアッドは、AIインシデントの大半には当てはまりません。Air Canadaのチャットボットが架空の制度を作り出した際、何かが利用不能になったわけでも、無許可で何かが変更されたわけでも、何かが漏えいしたわけでもありませんでした。このフレームワークは、そもそもこの種の問題に対応できないのです。Epic Sepsis Modelが症例の3分の2を見逃した際にも、侵害も侵入も痕跡(IoC)も存在しませんでした。従来型のIRの評価指標に照らせば、システムはどれも「正常」に見えてしまうのです。

これは例外的なケースではありません。従来型のIRフレームワークは、決定論的な障害と静的な侵害指標(IoC)の存在を前提としていますが、この前提は確率的なシステムを相手にすると崩れてしまいます。Microsoft Security Blogは2026年4月、この点を端的に言い表しました。あるモデルが今日は有害な出力を生成しても、翌日には同じプロンプトに対してまったく異なる応答を返すことがある、と。根本原因は特定のコード行にあるのではなく、確率分布そのものにあります。そしてMicrosoft Security Blogが指摘するように、確率分布にパッチを当てることはできません。

数字を見ても、このギャップは明らかです。AIインシデントの検知には平均で4.5日を要しています。AIインシデントの67%はモデルの誤作動によるものであり、敵対的攻撃によるものではありません。それにもかかわらず、セキュリティ予算は依然として後者を想定した境界防御ツールに投じられ続けています。私たちは、間違った失敗モードに対して、間違ったツールで、間違った兆候を探し続けているのです。

成熟したAI IR体制とはどのようなものか

これは講演を行うたびに必ず聞かれる質問です。端的に言えば、成熟したチームはインシデント発生前に、次の3つを備えています。

1つ目は、本番稼働中のすべてのシステムを対象としたAI部品表(AIBOM)です。これはソフトウェアのSBOMのAI版と考えてください。ベースモデル、学習データセット、サードパーティの依存関係、そしてコンポーネント全体の構成を文書化するものです。これがなければ、自社のAIが何で構成されているかを把握できず、データポイズニングインシデントやサプライチェーン侵害を、この基礎情報なしに調査することはできません。OWASP GenAI Security Projectは2025年12月、オープンソースのAIBOM生成ツールを公開しました。このツールはSPDX標準に準拠したCycloneDX形式で出力を生成でき、今すぐ実用的に導入できます。

2つ目は、本番稼働中のすべてのAIシステムを対象としたモデルカードです。これは共有ドライブに眠ったまま誰も開かない文書ではなく、IRチームが対応開始から10分以内に参照できるものでなければなりません。学習データの出所、モデルのバージョン、既知の性能上の限界(テストにおいてどのサブグループで精度が低かったかを含む)、アクセス制御、そして障害発生時の影響範囲。筆者が関わってきた組織の多くでは、モデル関連の文書はデータサイエンティスト向けに書かれており、セキュリティチームが深夜2時に参照しても使い物になりません。それは文書ではなく、単なる負債です。

3つ目は、IRコールツリーに専任のデータサイエンティストを明記しておくことです。インシデント発生後に事後報告を受ける担当者ではなく、モデルの挙動をリアルタイムで検証する権限を持つ担当者である必要があります。従来のIR体制にはオンコールのネットワークエンジニアが存在しますが、AI IRでも同じ発想を、障害を起こしているシステムの仕組みを理解している人材に適用する必要があります。

そしてごく一部のチームしか備えていない4つ目の要素が、稼働中の各モデルについて明文化されたロールバック基準です。異常率、ドリフト指標、公平性の逸脱がどの水準に達したら封じ込めやフォールバックへの切り替えを発動するのかを、事前に合意しておくものです。この基準がないチームは、AIインシデント発生後の最初の数時間を、目の前の事象が本当に問題なのかどうかの議論に費やしてしまいます。基準を備えたチームは、その時間を実際の対応に充てることができます。

次のインシデントが起きる前にやるべき4つのこと

検知トリガーを見直してください。出力の異常スコアリング、ドリフトを捉えるためのデータ分布モニタリング、モデルAPI利用の挙動追跡は、検知レイヤーに組み込んでおく必要があります。これらはSIEMからは得られません。AIシステムのレベルで計測基盤を整備する作業が求められます。

封じ込めの定義を見直してください。ほとんどのAIインシデントにおいて、「システムを切り離す」ことは最初の一手としては誤りです。サービスを稼働させたままルールベースのフォールバックに切り替えるほうが、システムを停止させて業務エスカレーションを引き起こすよりも被害を抑えられる場合があります。稼働中の各モデルには、あらかじめ定義されたロールバック基準と、指定されたフォールバック先が必要です。今のうちにこれらを文書化しておいてください。

インシデント発生前に法務部門を巻き込んでおいてください。Mobley対Workday訴訟が示すのは、バイアスによるインシデントについて、AIベンダーとそれを導入した組織の双方が責任を問われ得るということです。Air Canadaの事例が示すのは、自社のAIが顧客に対して発言した内容について、その責任を否定することはできないということです。もし法務部門がAIインシデントの発生を報道機関からの問い合わせで初めて知るような状況なら、その時点ですでに何かが手遅れになっています。