規制環境におけるプロンプトインジェクションとAI安全フィルターの限界

プロンプトインジェクション攻撃によってAIエージェントが本来許可されていないデータへアクセスした場合、コンプライアンス上の問題は「モデルが有害な出力を生成したかどうか」ではなく、「規制対象データへの不正アクセスが発生したかどうか」です。これらは異なる論点であり、AIの安全性フィルターは前者しか判断できません。

医療、金融サービス、防衛契約などの分野でAIエージェントの導入を管理するコンプライアンスチームにとって、この違いは非常に重要です。HIPAA、CMMC、SEC、NYDFSはいずれも「どのデータにアクセスしたか」「そのアクセスが許可されていたか」を規定しています。安全性フィルターはモデルの出力内容を管理しますが、出力が許容されたとしても、その背後で行われたデータアクセスがコンプライアンスに適合しているかどうかは判断できません。

本記事では、プロンプトインジェクションが規制対象データ環境において生じさせるコンプライアンスリスク、そのリスクがモデル層の防御だけでは解決できない理由、そして実際にリスクを封じ込めるアーキテクチャについて解説します。

要約

主なポイント：プロンプトインジェクション攻撃は、人間が委任したワークフローの範囲を超えてエージェントに行動させることで成立します。規制環境下では、インジェクションによる不正なデータアクセスは、人間による不正アクセスと同じ枠組みでコンプライアンス違反となります。モデルとは独立したデータ層でのアクセス制御のみが、インジェクションによる指示がコンプライアンスインシデントにつながるのを防げます。

重要性：2026年2月にハーバード、MIT、スタンフォード、カーネギーメロンのレッドチーム調査で、AIエージェントが実際のエンタープライズ環境でデータを流出させ、不正な操作を実行した事例が報告されました。モデル層の安全対策では信頼できる防御は得られませんでした。規制対象データでエージェントを運用する組織にとって、これは研究上の話ではなく、現実の運用リスクです。

主なポイント

1. プロンプトインジェクションはセキュリティだけでなくコンプライアンスのリスク要因。重要なのは「規制対象データへの不正アクセスが発生したかどうか」であり、モデル出力が有害と判定されたかどうかではありません。

2. 安全性フィルターは出力のみを評価し、コンプライアンスにはデータアクセスの管理が必要。有害な出力をブロックするフィルターは、その出力の前段階で発生した不正アクセスには対処できません。

3. ドキュメント経由の間接的なインジェクションが最もリスクが高い。エージェントがドキュメント、メール、データベース記録などを処理するたびに、インジェクションの可能性が生じます。モデルは正当な内容とインジェクションされた指示を区別できません。

4. モデルのアップデートでエージェントのインジェクション耐性が変化する可能性がある。あるモデルバージョンでインジェクションを拒否できていたエージェントも、アップデート後はそうでなくなることがあります。モデルの一貫した挙動に依存したガバナンスは、持続性がありません。

5. データ層でのガバナンスが、モデルの挙動に関係なくコンプライアンスリスクを封じ込める。インジェクションされた指示でモデルが不正アクセスを試みても、データ層でブロックされればコンプライアンスリスクは現実化しません。インジェクションはモデル層では成功しても、ガバナンス層で失敗します。コンプライアンス上重要なのはこのガバナンス層です。

なぜ安全性フィルターだけではコンプライアンス問題を解決できないのか

安全性フィルターは、モデルが有害な出力を生成するのを防ぐためのものです。データアクセス権限の管理を目的としておらず、それを実現することもできません。HIPAAはPHIへのアクセスを認可された人物やソフトウェアに限定することを求め、CMMCはCUIへのアクセスを認可されたユーザーやプロセスに限定することを求めています。これらはデータアクセスの要件であり、エージェントが「何を言うか」ではなく「何にアクセスできるか」が問われています。モデル出力に対する安全性フィルターは、評価する層がそもそも異なります。

さらに、安全性フィルターは回避可能です。ロールプレイや複数ステップの指示分解、符号化のバリエーションなどによる「ジェイルブレイク」が繰り返し報告されています。また、モデルのアップデートによりフィルターの挙動が予告なく変わることもあります。2026年2月のMicrosoft Copilotの設定ドリフト事例では、通常のモデルアップデートでアクセス制御の結果がサイレントに変化しました。モデル層の制御に一貫性を期待したガバナンスは、予告なく破綻するリスクがあります。

規制環境で重要な4つのインジェクション経路

防衛請負業者にとっては、ドキュメント経由の間接インジェクションへの注意が特に重要です。技術データパッケージや下請け業者からの納品物は、セキュリティ状況が不明な第三者から届きます。CUIリポジトリにインジェクションされたドキュメントが置かれると、認可されたエージェントが制御データを流出させる経路が生じます。しかも、その監査記録は正規のワークフローと見分けがつきません。

現在、規制企業が最もリスクにさらされているポイント

多くの企業は直接インジェクションへの対策（入力フィルタリングやシステムプロンプトの強化）を標準化していますが、残るギャップは構造的なものであり、設定上の問題ではありません。

医療機関で臨床文書エージェントを運用する場合、患者の申込書、事前認証申請、保険会社とのやり取りなど、外部から届く多数のドキュメントを処理します。これら一つ一つがインジェクションの足掛かりとなり得ます。エージェントには、改ざんされた申込書と正規の申込書を区別する仕組みがありません。エージェントのアクセス制御がシステムプロンプトだけに依存している場合、間接インジェクションが成功すれば、エージェントが本来許可されていないPHIにアクセスする道が開かれます。

防衛請負業者もCUIワークフローで同様のリスクに直面します。下位サプライヤーからの技術データパッケージは、レビュー前にCUIリポジトリへ格納されることが一般的です。エージェントがそれらを処理する際、サプライヤードキュメント内のインジェクション指示は、そのまま認可範囲を継承します。流出が発生しても監査記録は通常のワークフローと区別がつきません。何が、なぜアクセスされたかを示すオペレーションレベルのログがなければ、インシデントは無期限に発見されない可能性があります。

金融サービス企業にとっては、メール受信箱が最も見落とされがちなリスク面です。クライアントとのやり取りを監視・分類・要約するエージェントは、外部からの内容を事前審査なしで処理します。脅威アクターが監視対象の受信箱へメッセージを送信できれば、エージェントにインジェクション指示を届けることができ、SEC Rule 204-2やRegulation S-Pで規定されるクライアントデータへの経路が生じます。

共通するのは、いずれもエージェントの認可されたワークフローがアクセスを提供し、インジェクションがその流れを変える点です。そして、エージェントの処理速度が上がるほど、インジェクションが成功した場合の影響範囲も拡大します。

実際のリスク封じ込めとは

プロンプトインジェクションによるコンプライアンスリスクを封じ込めるアーキテクチャの本質はシンプルです。モデルが何を指示されたかに関係なく、データ層でアクセス権限を強制することです。エージェントのデータアクセスが、リクエストが規制対象データに到達する前にABACポリシーで管理されていれば、インジェクション指示による不正アクセス試行はガバナンス層でブロックされます。インジェクションはモデル層では成功しても、コンプライアンスイベントは発生しません。

これは設計上、モデル非依存です。モデルのアップデートでインジェクション耐性が変わっても、データポリシーエンジンによるアクセス評価には影響しません。ガバナンス層は、モデルの挙動やインジェクション内容に関係なく、ポリシーに基づいてデータアクセスリクエストを評価します。

インジェクションによる拒否されたアクセス試行も、監査証跡に記録されるべきです。ドキュメント処理中に特定のデータカテゴリへのブロックリクエストが繰り返されるパターンは、アクセス制御境界を探るインジェクション攻撃の兆候となります。オペレーションレベルのログがSIEMに連携されていなければ、このシグナルは見えません。

プロンプトインジェクションによるコンプライアンスリスクを減らす5つの実践

モデル層の防御とデータ層のガバナンスは異なる役割を果たします。どちらも重要ですが、コンプライアンスギャップを埋めるのは後者だけです。

1. データ層でアクセス権限を強制する。全てのエージェントデータリクエストについて、認証済みエージェントID、データ分類、ワークフローコンテキスト、操作種別をABACで評価し、規制対象データに到達する前に制御します。これが、インジェクションの成功がコンプライアンスイベントに発展するのを防ぎます。

2. 成功したリクエストだけでなく拒否されたリクエストも記録する。オペレーションレベルの監査証跡に、ブロックされたアクセス試行（エージェントID、リクエストデータ、拒否理由、タイムスタンプ）を記録し、SIEMに連携することで、インジェクション攻撃の兆候を検知できます。これがなければ、攻撃は成功するまで見えません。

3. モデル層の防御はリスク低減策と位置付け、コンプライアンス制御とは区別する。入力サニタイズ、プロンプト強化、出力フィルタリングはインジェクション成功率を下げますが、規制上求められるアクセス権限管理を満たすものではありません。インジェクションが時折成功する前提でコンプライアンスアーキテクチャを設計しましょう。

4. RAGデータソースは信頼できない入力として扱う。インデックス化前に内容をサニタイズし、コーパスへの寄与を制限し、ベクトルデータベースにもアクセス制御を適用します。リトリーバルはデータアクセスイベントであり、他の規制データアクセスと同様のガバナンスが必要です。

5. モデルアップデートごとにガバナンスポスチャを再検証する。標準・攻撃的ワークフローの両方で、アクセス制御の結果が認可範囲内に収まっているかテストし、変更点を記録します。モデルに依存しないデータ層の制御は再検証不要ですが、モデル層の制御はモデル変更のたびにテストが必要です。

Kiteworksによるプロンプトインジェクション・コンプライアンスリスクの封じ込め

Kiteworksプライベートデータネットワークは、AIエージェントとそのアクセス先の規制データの間に位置します。すべてのデータリクエストは、認証済みIDの検証、データポリシーエンジンによる評価、FIPS 140-3認証済み暗号化、改ざん検知可能なログ記録を経て初めてデータが移動します。これはモデルやプロンプト、エージェントフレームワークに依存しません。

インジェクション指示によってエージェントが範囲外のデータアクセスを試みても、そのリクエストはポリシーレイヤーで拒否され、完全な証跡付きで記録されます。コンプライアンスイベントは発生しません。インジェクション試行は監査記録で可視化されます。AIベンダーがモデルをアップデートしても、ガバナンスポスチャは変わりません。なぜなら、制御はモデル内部ではなくデータ層に存在するからです。

Kiteworks Compliant AIの「ガバナンス付きファイル管理」「ガバナンス付きフォルダー操作」機能は、さらにアクションの範囲を制限します。たとえば、外部送信がエージェントの認可ポリシー範囲外であれば、インジェクション指示によるファイル転送は実行できません。RBACやABACによる制御が、インジェクション成功時に実際に実行可能な内容を限定します。

モデルの挙動に関係なくコンプライアンスリスクの封じ込めが必要な組織には、Kiteworksがそのためのアーキテクチャを提供します。Kiteworks Compliant AIの詳細やデモのご予約はこちら。

追加リソース

• ブログ記事
  手頃なAIプライバシー保護のためのゼロトラスト戦略
• ブログ記事
  77%の組織がAIデータセキュリティに失敗している理由
• 電子書籍
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレットをしている理由
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーの有無」を問う段階を終えた。今求められるのは「実効性の証明」