更新日: 2026年6月25日

「CASB・DLPでは防げない」生成AIの情報漏洩リスク

プロンプトセキュリティが必要になる2つの構造的な理由

生成AIは、いまや一部の先進的なチームだけのものではありません。マーケティング、人事、法務、開発、経理――組織のあらゆる部門が、毎日のように生成AIを業務に使っています。一方で、多くの企業がすでに導入しているCASBやDLPといった既存のセキュリティ製品は、この新しいAIの利用に「構造的に」追いつけません。本コラムでは、なぜ既存対策では生成AIの情報漏洩を防ぎきれないのか、そしてプロンプトセキュリティという新しいアプローチがなぜ必要なのかを整理します。

そもそもCASB・DLPとは何か

議論の前に、既存の代表的な対策を簡単に整理します。両者はいずれも優れた製品ですが、設計思想は「生成AI登場以前」のものです。

CASB（Cloud Access Security Broker）：クラウドサービス（SaaS）の利用状況を可視化し、シャドーITの発見やアクセス制御を行う仕組み。ネットワークやAPI連携を起点に、「どのクラウドサービスが使われているか」を統制します。
DLP（Data Loss Prevention）：機密情報や個人情報が社外へ流出することを防ぐ仕組み。メール、Web、エンドポイント、ストレージなど、決められたチャネルを監視し、パターンに合致したデータの送信をブロックします。

どちらも「決められたクラウド」「決められたチャネル」「決められたパターン」を前提に動きます。ところが生成AIの利用は、この前提を次々と外していきます。

CASB・DLPが生成AIリスクに追いつけない2つのギャップ

ネットワーク起点・チャネル起点の従来型ツールには、生成AI時代に克服しづらい構造的な弱点が2つあります。

① 暗号化された通信は「中身」が見えない

ChatGPTやGeminiなどとの通信はすべてHTTPSで暗号化されています。ネットワーク型のツールから見えるのは暗号化された“かたまり”だけで、実際に入力されたプロンプトや、その中に含まれる機密データ・ポリシー違反までは見えません。中身を検査するにはTLS復号化が必要ですが、TLS復号化は、復号化して通信の中身の検査を実施した後に再度暗号化を実施する仕組みのため、通信フローの複雑化や遅延などのリスクを伴います。

② 静的なアプリリストは、増え続けるAIに追いつけない

新しいAIツールは毎日のように登場します。手動で更新するURL／シグネチャに依存する従来型ツールでは、この増加スピードに原理的に追いつけません。「リストにないAI」はすべて統制の外で使われることになります。さらに、既存のSaaSやアプリに後から搭載される「組み込み型のAI」も、URLベースでは識別が難しく、対応が困難です。

これらは設定や運用でカバーできる「不足」ではなく、検知ポイントそのものが違うことから生まれる「構造的なギャップ」です。

プロンプトセキュリティのアプローチ ― 「利用の発生点」で見る

プロンプトセキュリティは、ネットワーク上（通信の途中＝In-Line。CASBもインライン制御の代表例です）ではなく、AIが実際に使われるその瞬間（Point of Interaction）で動作します。2種類のセンサーで、上記のギャップを正面から塞ぎます。

ブラウザ拡張（ブラウザ版のAIアプリを対象）：15,000以上のAIサイトを対象に、アプリケーション層を直接検査するため、TLS復号化は不要でプロンプトの中身を可視化します。
専用エンドポイントエージェント（デスクトップ版のAIアプリを対象）：デスクトップ版のAIアプリからAIへの通信に対して、ローカルプロキシ接続することにより、プロンプトの中身を可視化します。

結果として、ブラウザ版・デスクトップ版いずれのAIアプリ利用についても、利用の発生点でプロンプトの中身を可視化・統制できます。

比較表：プロンプトセキュリティ vs CASB vs DLP

生成AIの利用統制という観点で、3つのアプローチを並べると違いが明確になります。

観点	CASB	DLP	プロンプトセキュリティ
主な目的	クラウド（SaaS）利用の可視化・統制	機密データの社外流出防止	生成AIの利用そのものの可視化・統制・保護
検知ポイント	ネットワーク／APIゲートウェイ	チャネル（メール・Web・端末等）	利用の発生点（ブラウザ拡張＋端末エージェント）
暗号化(HTTPS)通信の中身	復号構成が必要（TLS破壊リスク）	同様に復号が前提	TLSを破壊せずアプリ層で可視化
新規AIサービスへの追従	手動URL/シグネチャ依存	同様に追従が困難	15,000+サイトを動的に検出
入力前のPIIマスキング	事後ブロック中心	チャネル次第	送信前にローカルでマスキング
利用者へのリアルタイム教育	なし	なし	ポップアップでその場でコーチング
生成AI特化の脅威への対応	想定外	想定外	プロンプトインジェクション/ジェイルブレイク等

※〇 = 対応／ △ = 条件付き・限定的／ × = 構造的に困難

※CASB/DLPの一般的な設計を前提とした整理です。

「Microsoft 365の既存機能で足りるのでは？」への回答

「すでに契約しているMicrosoft 365のセキュリティ機能で代替できるのでは？」という疑問がよく挙がります。結論から言えば、守備範囲が異なります。

Microsoft 365 のセキュリティ機能（情報保護・DLP等）は、主にMicrosoftのエコシステム内のデータとチャネルを守る設計です。
一方、従業員が日々使う生成AIは、ChatGPT、Gemini、Claudeをはじめ15,000以上に及び、その多くはMicrosoftの統制範囲の外で利用されます。

つまり「M365で足りるか」ではなく、「生成AIの利用全体を、発生点で可視化・統制できているか」が問うべき論点です。ここがプロンプトセキュリティの価値であり、コスト以上のリスク低減につながります。

こんな課題をお持ちの企業に

従業員の生成AI利用（シャドーAI）の実態が見えず、不正・過失による情報漏洩を防ぎたい
CASB／DLPを導入済みだが、生成AIまわりだけ「抜け道」になっている懸念がある
AIの利用は止めたくない。安全に使える状態にして、生産性と競争力を保ちたい
AI事業者ガイドラインなど、生成AIに関するガバナンス・規制対応を進めたい

まとめ

生成AIの情報漏洩リスクは、CASBやDLPの「設定不足」ではなく「検知ポイントの違い」から生まれます。AI特有のリスクには、AIの利用が発生するその瞬間を捉える、AI特化型のアプローチが必要です。プロンプトセキュリティは、暗号化通信や新規サービスへの追従といった既存ツールの死角を、利用の発生点でまとめてカバーします。