2026.10.27
AIインシデントを防ぎ対応力を高める実践手順
IT関連
AIインシデントは、AIが期待どおりに動かなかった出来事だけを指す言葉ではありません。機密情報の外部送信、誤った自動判断、権限を逸脱したAIエージェントの操作など、事業・利用者・社会に影響する事象を含みます。
生成AI、RAG、外部API連携の利用が広がるほど、従来の情報システム障害とは異なる原因と証跡が増えます。問題が起きてから担当者を探す運用では、封じ込めの遅れ、説明責任の不足、同じ事故の再発を招きかねません。
本記事では、AIインシデントの定義からAIリスク評価、AI受入テスト、AI品質保証、AI事故対応、AI監査対応までを一つの運用として解説します。現場で使える判断基準、保存すべきログ、復旧後の改善方法を順に確認しましょう。
AIインシデントとは何かを事業影響から定義する
AIインシデントは安全・権利・業務への悪影響です
AIインシデントとは、AIシステムの設計、データ、モデル、利用方法、外部連携などが原因となり、安全性、プライバシー、公平性、可用性、法令順守を損なう事象です。単なる回答ミスでも、意思決定や公開情報に使われれば重大な問題になります。
ISO/IEC 22989:2022の考え方を踏まえると、AIの問題はモデル単体ではなく、人、組織、データ、運用を含むシステムとして捉える必要があります。利用目的と実際の影響を結び付けて定義することが、適切な初動の出発点です。
公開された事例群では、インシデント 1783という蓄積が示される一方、被害規模や確度は一様ではありません。誤情報、差別的な判定、漏えい、なりすまし、物理的な誤作動を同じ窓口で受け、影響に応じて分類する仕組みが重要です。
- 情報漏えい・秘密情報の再現
- 誤情報・偏見を含む出力の公開
- AIエージェントによる権限外の実行
- データ汚染やモデル更新による性能劣化
生成AI・RAG・AIエージェントには固有の事故経路があります
生成AIでは、もっともらしい虚偽を回答するハルシネーション、機密プロンプトの混入、著作物に近い出力が代表的なリスクです。RAGではさらに、検索対象の誤り、古い文書、アクセス権を無視した検索結果が出力に連鎖します。
AIエージェントでは、自然言語の指示がツール実行へつながるため、プロンプトインジェクションが外部送信やデータ削除へ発展し得ます。ツールの許可範囲、承認の有無、実行結果をセッション単位で追跡できる設計が欠かせません。
AI関連の侵害を受けた組織の97%が適切なAIセキュリティ管理を欠いているという調査結果は、導入時の機能評価だけでは不十分であることを示します。モデル、データ、プラグイン、外部APIを依存関係として台帳化しましょう。
- 入力データと検索文書の汚染
- モデル版変更による回答品質の変動
- 外部ツールの過剰な権限設定
- 第三者サービス障害による連鎖停止
重大度は影響・確度・拡散性で判断します
重大度の判定は、技術的な不具合の大きさだけで決めません。個人情報、金銭、安全、法的義務、顧客への波及という影響度に、事実の確度と出力・行為の拡散性を掛け合わせて評価します。
AI Incident Response Systemを整備する際は、報告者が「AIの回答がおかしい」とだけ送っても受理できるようにします。その後、一次情報、対象者数、外部送信の有無、停止可能性を担当チームが補完して重大度を暫定決定します。
事故の総件数自体は1年間で約85.4%増えましたという動向を踏まえると、全件を経営会議へ上げる運用は機能しません。軽微な事象は現場で記録・改善し、高影響の事象だけを即時エスカレーションする基準が必要です。
- 高：人身、安全、重大漏えい、法的通知の可能性
- 中：顧客影響はあるが停止・訂正で限定可能
- 低：内部で完結し、再現性と影響が限定的
AIリスク評価で事故が起きる前の弱点を見つける
AIリスク評価は導入可否を決める継続作業です
AIリスク評価は、AIの導入前に一度だけ行う審査ではありません。企画、開発、運用、モデル更新、データ更新、委託先変更、廃止まで、リスクが変わる契機ごとに見直し、統制策と残余リスクを記録する活動です。
NIST AI RMFは、ガバナンス、マッピング、測定、管理という4つの機能を中心に構築されています。自社では、責任者の明確化、用途の特定、テストによる測定、利用制限や停止判断を、この流れに対応させると実務へ落とし込みやすくなります。
AIシステムを評価している組織の37%が、セキュリティとコンプライアンスへの懸念を最大の課題として挙げています。特にITリーダー層ではこの割合が44%に達しており、業務部門だけでユースケースを判断しない体制が求められます。
- 利用目的と意思決定への関与度
- 扱うデータの分類と保存先
- モデル・ベンダー・外部接続先
- 人による確認、停止、訂正の手段
評価票は資産とリスク経路を具体的に書き出します
評価票には、ユースケース、利用者、入力データ、モデル名と版、RAGの索引、ツール権限、出力先、承認者を記載します。抽象的な「安全対策済み」ではなく、どの情報がどの経路で外部へ出るかを可視化することが目的です。
スコアリングは、発生可能性、影響度、検出可能性、可逆性を各段階で採点し、合計ではなく高い項目を優先して扱います。たとえば削除や送信を伴い元に戻せない処理は、発生確率が低くても人的承認や隔離を要求すべきです。
現在企業内で使用されているAIツールの約91%は、セキュリティやIT部門による監視なしで運用されているとされます。利用申請だけを待たず、SSOログ、購買記録、ブラウザ利用状況を用いてシャドウAIを棚卸しする必要があります。
- 高リスク：対外送信、採否判断、金銭・安全に関わる処理
- 中リスク：社内文書検索、下書き生成、分析補助
- 低リスク：匿名化済みデータでの限定的な試作
リスク評価は残余リスクを経営判断へ渡します
評価の結論は、GoかNo-Goかの二択にしません。用途を限定する、閲覧のみとする、二者承認にする、出力を隔離する、監視頻度を上げるなど、残余リスクに応じた条件付きの利用許可が現実的です。
データ侵害による平均的な損失額は445万ドルとされ、AIの便利さだけで例外扱いをすると、事故時の事業損失が大きくなります。法務、情報セキュリティ、業務責任者が評価結果を共有し、受容するリスクを明文化しましょう。
組織の88%が過去1年間に、AIエージェントによるセキュリティインシデント（確認済みまたは疑わしいもの）を経験しているという調査もあります。エージェントには最小権限、操作対象の分離、金銭・公開操作前の人間承認を設定します。
- 許容するリスクと承認者を台帳に残す
- 高リスク変更時は再評価を必須化する
- 未解決の課題には期限と責任者を置く
検証環境と受入基準でAIの危険な挙動を止める
AIサンドボックスは本番から切り離した検証の場です
AIサンドボックスは、本番データ、本番権限、本番の送信先から隔離して、モデルやエージェントの挙動を確認する環境です。試行を止めるのではなく、試行の失敗が顧客、基幹データ、外部サービスへ届かないようにします。
隔離環境では、匿名化または合成データを用い、外部APIはモック化します。AIエージェントのメール送信、ファイル更新、支払い処理などは実行結果を模擬し、意図しない指示に従わないか、停止操作が効くかを確認します。
ALION株式会社のように国境を越えた専属チームで開発を進める場合も、開発・検証・本番の責任境界を共有することが重要です。委託先を含むチームが同じ評価基準と変更記録を参照できれば、引き継ぎ時の見落としを減らせます。
- 本番の認証情報・個人情報を持ち込まない
- 送信・削除・更新は模擬実行に置き換える
- テストごとにモデル版とプロンプト版を固定する
AI受入テストは業務上の失敗条件を確認します
AI受入テストでは、平均的に正しい回答を出せるかだけでなく、失敗してはいけない条件を合否基準にします。具体的には、機密情報を含む質問、根拠のない断定、禁止されたツール実行、権限のない文書検索を試験します。
業務部門は、実際の例外ケースをテストデータへ提供します。顧客への説明文、契約判断、採用候補者の評価などでは、もっともらしい誤りを人が見抜ける設計か、回答を保留・差し戻しできるかも受入条件になります。
最初の3〜6ヶ月は週次でモデルの精度指標を確認し、月次で詳細レビューを実施する体制が理想的です。本番稼働後の性能劣化、検索文書の更新、利用者の入力傾向の変化を、導入時の合格だけで見逃さないためです。
- 正常系・異常系・悪用想定を分けて試験する
- 高影響の判断には根拠表示と人の確認を要求する
- モデル、プロンプト、検索索引の変更ごとに再試験する
AI品質保証は正確さ以外の品質も測ります
AI品質保証は、正答率だけを追う活動ではありません。安全性、再現性、応答時間、可用性、公平性、説明可能性、セキュリティを利用目的に応じて確認し、許容できない失敗を減らすための継続的な仕組みです。
AI出力検証では、回答の根拠文書、参照時点、検索順位、確信度、禁止表現の検出結果を確認します。RAGの回答であれば、根拠にない主張をしていないか、権限外の文書を参照していないかを自動・手動の両方で点検します。
包括的な機械学習ツールを用いることで、不正検出の精度を40%向上させることができるという報告もあります。ただし指標の改善だけで安全を断定せず、誤検知、見逃し、利用者への影響を併記して判断する姿勢が必要です。
- 事実性：根拠との整合性を確認する
- 安全性：有害・秘密・差別的表現を検査する
- 運用品質：遅延、失敗率、再実行率を監視する
AI事故対応は最初の行動と証拠保全で決まる
AI事故対応はまず外部影響を止めることです
AI事故対応の目的は、原因をすぐ断定することではなく、被害拡大を止め、事実を保全し、利用者への影響を減らすことです。とくに外部送信、自動更新、公開、決済、削除の権限を持つAIは、停止権限を平時から明確にします。
初動5ステップとして、発生時刻の固定、外部作用の遮断、ログ保全、暫定重大度の設定、対応責任者の指名を順に行います。最初の10分で議論を始めるより、送信と更新を止めて証跡が失われない状態を作ることが先決です。
00-15分: 外部送信・更新・公開を遮断 / 発生時刻を固定 / ログ保全開始という行動を、運用手順書へ明記しましょう。15分以内に責任者を招集し、30分以内に対応責任者を決定できる連絡網を訓練します。
| 時間帯 | 実施内容 | 主な目的 |
|---|---|---|
| 00-15分 | 送信・更新・公開を遮断 | 被害拡大の防止 |
| 15-30分 | 重大度設定・責任者指名 | 指揮系統の確立 |
| 30-45分 | 対象件数・送信先を仮集計 | 影響範囲の把握 |
| 45-60分 | 前版・手動経路へ切替 | 業務継続の確保 |
- 利用停止と影響範囲の拡大防止
- ログ・画面・設定値の改変防止
- 業務、法務、広報、セキュリティへの連絡
- 手動運用または前版への切り替え
証跡はプロンプトから承認記録まで一体で保存します
AIの事故調査では、アプリケーションログだけでは原因を再現できません。入力プロンプト、システム指示、モデル名と版、温度などの設定、RAG検索結果、ツール呼び出し、出力、承認者、送信先を同じ事象IDで結び付けて保存します。
証拠保全では、ログを上書きせず、取得時刻、取得者、ハッシュ、保存場所を記録します。個人情報を含むログは閲覧権限を最小化し、調査目的以外の二次利用を防ぎます。完全性のある証跡が、説明と再発防止の土台です。
30-45分: 既知の送信先・対象件数を仮集計 / 専門部署へ連絡という段階では、確定していない数値を断定しないことも重要です。分かっている事実、確認中の事項、次の更新時刻を分けて、関係者へ共有します。
- 会話履歴・プロンプト・システム指示
- モデル・検索索引・ツールの版情報
- ツール実行履歴と外部送信先
- 出力内容、承認記録、アクセスログ
復旧は安全を確認して段階的に行います
復旧は、サービスを元に戻す作業ではなく、同じ経路で再発しないことを確認する工程です。原因仮説に対し、権限縮小、検索索引の再作成、危険なプロンプトの遮断、モデルのロールバックなどの対策を施してから限定再開します。
四件の封じ込め時間が12分、18分、35分、95分で、平均40分、中央値は26.5分という演習結果のように、対応時間にはばらつきが出ます。MTTD、封じ込め時間、MTTR、証拠完全率、再発率を測り、遅延箇所を具体的に改善します。
AI RMF 1.0やNIST SP 800-61r3を参照しつつ、技術対策と業務判断を接続します。復旧後には、何を止め、誰が判断し、利用者へ何を伝え、どの統制が欠けていたかをレビューし、次の演習へ反映させます。
- 限定ユーザー・限定機能で再開する
- 再開前に同じ攻撃・失敗を再現試験する
- 教訓をリスク台帳、テスト、教育へ反映する
AI監査対応で説明できる運用を日常化する
AI監査対応は監査直前ではなく運用記録から始まります
AI監査対応で問われるのは、問題がなかったという主張ではなく、リスクをどのように把握し、誰が判断し、どのように改善したかです。監査のためだけに資料を後追いで作るのではなく、日々の開発・変更・事故対応の記録を残します。
最低限必要なのは、AI資産台帳、用途と責任者、AIリスク評価、データの出所、モデル・プロンプト・索引の変更履歴、AI受入テスト結果、アクセス権、インシデント記録です。これらを相互に参照できる状態に整えると、説明作業が速くなります。
NIST Cybersecurity Framework (CSF) 2.0は、ガバナンスを含めた全体的な管理を考える助けになります。技術部門だけに証跡作成を任せず、業務部門、法務、購買、委託先管理を含む責任分担を文書化しましょう。
- 誰がAI利用を承認したか
- どのデータとモデルを使ったか
- どの検証を実施し、何を制限したか
- 事故後に何を改善したか
AI出力検証は監査可能な形で継続します
AI出力検証は、公開前の目視確認だけでは不十分です。高影響な出力については、根拠の参照、禁止事項の判定、信頼度、レビュー担当者、承認・差し戻しの理由を記録し、後から判断過程を説明できるようにします。
自動判定には限界があるため、重要な契約、医療・安全、採用・与信、顧客への公式回答では人間による最終確認を残します。レビュー担当者が根拠にアクセスできず、AIの結論だけを見る設計は、形式的な承認になりやすいため避けます。
自動化の効果は分野で異なります。自動車保険の保険金請求の約30%が、デジタル写真撮影を用いて開始されている一方、発売後数か月のうちに損害賠償請求の 50% を自動承認する運用には、例外検知と人の介入点が不可欠です。
- 根拠なしの断定を検知・保留する
- 重要出力は二者確認または専門家確認を行う
- 訂正履歴と利用者への通知を保存する
演習と改善でAI品質保証を事業継続へ結び付けます
監査可能な運用を維持する最短の方法は、定期的に事故対応を演習することです。情報漏えい、誤出力の対外公開、著作権懸念、AIエージェントの誤操作をシナリオ化し、停止権限、連絡先、証拠保全、対外説明までを実地で確認します。
年1回の社内AI研修に加え、変更頻度の高いサービスは短い机上訓練を重ねます。三十分の演習でも、担当者がログの場所を知らない、前版へ戻せない、顧客窓口が未確定といった実務上の欠陥を早期に発見できます。
AIインシデント関連の公開データには$1B、52K+、$10T+、約0.15%といった異なる規模・指標が並びます。単一の数字だけで自社リスクを判断せず、自社の利用者数、権限、データ種別、復旧能力に沿ったKPIを継続的に見直しましょう。
- 演習後は手順書ではなく実測時間を更新する
- 委託先も含めた連絡・停止権限を確認する
- 品質、セキュリティ、監査の改善を一つの台帳で管理する
まとめ
AIインシデントへの備えは、導入を遅らせるための制約ではありません。AIリスク評価、隔離した検証、AI受入テスト、証跡保全、迅速なAI事故対応をつなげることで、AIを安全に業務へ定着させる基盤になります。
要点
- AIの問題はモデル単体ではなく、データ、権限、運用、外部連携を含めて評価する。
- 初動では原因究明より先に、外部送信・更新・公開を止め、証跡を保全する。
- プロンプト、モデル版、RAG検索結果、ツール実行、承認記録を結び付けて保存する。
- AI監査対応は、日常の変更・検証・事故対応の記録を継続することで効率化できる。
- 演習で停止権限と連絡網を確かめ、実測した課題をAI品質保証へ反映する。
まずは自社で利用しているAI、接続しているデータ、外部操作権限、責任者を一覧化してください。その上で、最も影響が大きいユースケースからAIリスク評価と初動手順を整え、実践的なAIインシデント対応体制へ育てていきましょう。
よくある質問
Q1. AIインシデントと通常のシステム障害の違いは何ですか？
通常の障害に加え、AIの誤出力、偏見、説明不能な判断、学習・検索データの汚染、プロンプトインジェクション、AIエージェントの権限逸脱などを扱う点が特徴です。モデルだけでなく、データ、利用者、権限、外部連携を含めて調査します。
Q2. AI事故対応で最初に行うべきことは何ですか？
外部送信、公開、更新、削除などの影響を止め、発生時刻を固定し、ログ保全を開始します。その後に暫定重大度を決め、対応責任者と次の共有時刻を明確にします。原因を急いで断定して証跡を失わないことが重要です。
Q3. AI受入テストでは何を確認すべきですか？
通常の正答率だけでなく、機密情報の出力、根拠のない断定、権限外の文書参照、危険なツール実行、停止操作の有効性を確認します。業務上の例外ケースと悪用を想定した試験を含めることが実践的です。
Q4. AI監査対応に必要な記録は何ですか？
AI資産台帳、利用目的、責任者、リスク評価、データ出所、モデル・プロンプト・索引の変更履歴、テスト結果、アクセス権、出力レビュー、インシデント記録を残します。各記録を事象IDや変更IDで関連付けると説明しやすくなります。
Q5. AIサンドボックスはなぜ必要ですか？
本番環境で未知のプロンプトやツール連携を試すと、情報漏えい、誤送信、データ改変につながるためです。隔離環境で匿名化データと模擬APIを使い、危険な挙動や停止手段を確認してから本番へ進めます。
参考文献・出典
AI-IRS AI インシデントレスポンス・アプローチブック ~ A Foundation for Trustworthy AI ~ 令和８年１月9 日 AI セーフティ・インスティテュート 2 目次 0 エグゼクティブサマリ…
aisi.go.jp
  # AIインシデントデータベース にようこそ…
incidentdatabase.ai