プロンプトインジェクションは、不正な文章がモデル回答を変えるだけでなく、AIエージェントのtool実行、外部送信、記憶保存へ進むと業務事故になります。検知後にpromptを修正するだけでは不十分です。権限を止め、入力・判断・tool call・外部影響を一続きで保全し、安全な版へ段階復旧する必要があります。
最初に出力ではなく権限を止める
OWASP LLM01:2025は、直接・間接prompt injectionが、不正な意思決定、情報露出、無許可機能実行につながると整理しています[1]。異常を見つけたら、会話画面だけを閉じず、該当agentのtool token、write scope、外向き通信、長期記憶への書込みを停止します。
read-only調査と外部副作用を分け、送信・削除・権限変更など高影響toolを優先して遮断します。全AI機能を無条件に止めるのではなく、影響が疑われるtenant、agent、connector、時間帯を特定し、被害拡大を防ぎます。
証跡を上書きせず保全する
入力本文、取得文書、system/developer instructionの版、model、tool call、引数、承認、response、外部API結果、記憶更新をincident IDで結びます。ログに機密promptが含まれる場合は閲覧権限と保持期間を限定し、調査のために別系統へ無制限複製しません。
NIST AI 600-1は、生成AIのincidentを既存のrisk managementへ統合し、eventの記録、責任、post-deployment monitoringを扱います[2]。MITRE ATLASのincident sharingも、サニタイズした技術情報を共有し、実例に基づく防御へつなげる考え方を示します[3]。
影響範囲をtool単位で確認する
「危険な回答が出たか」だけでなく、どのtoolが実行され、対象resource、権限、結果、下流処理が何だったかを確認します。成功responseでも、宛先や対象が誤っていればincidentです。失敗responseでもpartial writeがないとは限りません。
Google CloudのAI/ML security guidanceは、AI固有のincident responseとしてpreparation、eradication、recovery、post-incident activityを示し、prompt injectionやunsafe outputに合わせたplaybookを求めています[4]。中央SOC、法務、業務責任者へのescalation条件を事前に決めます。
安全な版へ戻して再検証する
原因が取得文書なら隔離・再取得、prompt templateなら版を戻し、tool policyならallowlistと引数validationを修正します。悪意ある内容が長期記憶へ入った場合は、対象memoryを隔離し、別tenantへ伝播していないか確認します。
修正後は、実際の攻撃入力と変種をreplayし、toolが呼ばれないこと、警告が出ること、正常業務が壊れていないことを確認します。GoogleのSAIFは、AI向けincident typeに合わせてabuse policyとresponse processを調整するよう勧めています[5]。一度のfilter成功だけで復旧しません。
AIエージェントの事故対応設計を相談する
平時にplaybookを演習する
検知条件、即時停止権限、証跡場所、連絡先、影響確認query、復旧承認、顧客通知判断をplaybookへ固定します。四半期ごとに間接prompt injectionを含むtabletop exerciseを行い、当直者がtool権限を実際に止められるか確認します。
適用限界
入力filterやモデルguardrailだけでprompt injectionを完全に防げません。検知不能を前提に、最小権限、承認、sandbox、出力後validation、監査を重ねます。海外frameworkは自社の法的通知義務を代替しないため、日本の契約・個人情報・業界規制を別途確認します。
一次情報と確認範囲
確認日：2026年9月19日。製品仕様・制度・研究結果は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。