セキュリティチームのうち、従業員がAIツールに送信する機密データを定期的に報告できるのはわずか29％

この記事は、Jazzの委託を受けてCloud Security Alliance（CSA）が実施した2026年の調査レポート、「AI時代のDLP」の調査結果に基づいています。

6月と7月に、CSAはITおよびセキュリティの専門家433人を対象に、過去30日間に機密データが生成AIツールへ送信された回数を示すレポートをチームで作成できるかどうかを尋ねました。定期的に作成できると回答したのは29％でした。

回答者が生成AIを小規模なリスク経路と見なしていたなら、この数字の重要性はそれほど高くなかったでしょう。しかし、回答者は生成AIをデータ流出リスクの筆頭に挙げ、48％がリスク上位3位以内に位置づけました。

私はデータ損失防止製品を開発する会社でエンジニアリングを統括しており、仕事の大半は、システム内のどこにデータの移動を示す証拠が残るのか、そしてそのリスクがなぜ生じるのかを見極めることです。その観点から見ると、チームが把握できていると考える範囲と、実際に証拠を示せる範囲との隔たりは、生成AI向けの制御がどのように設計されたかから直接生じています。

生成AIの可視性に対する自信は、チームが証拠として示せる範囲を大きく上回る

回答者の半数をわずかに超える人が、生成AIに対する可視性を5段階評価で4または5としました。しかし、機密データがAIツールに送られた回数を数えるだけのレポートによって、その評価を定期的に裏づけられる人はわずか29％でした。

出典：Cloud Security Alliance『AI時代のDLP』（2026年）、n=433。レポートの22、23ページのグラフを再現。

制御の適用状況にも同じ傾向が見られます。生成AI経由で送信される機密データを厳格にブロックしている回答者はわずか22％でした。回答者がデータ流出リスクとして最も低く評価したリムーバブルメディアは、厳格なブロック率が31％と最も高くなっています。厳格なブロックは、最も古いツールが使われている経路に集中しています。

出典：Cloud Security Alliance『AI時代のDLP』（2026年）、n=433。レポートの23、26ページのグラフを再現。丸め処理により行の値が99％または101％になった場合、棒グラフは100％に調整。

Jazzは調査とあわせて、顧客環境から得られたテレメトリーデータも公開しました。そのデータにおける組織あたりの平均利用AIツール数は、重複を除いて169.5種類でした。このうち承認済みは9.8種類で、94.2％が承認リストに含まれていませんでした。

隔たりが生じる理由：ツールのリストからイベントは記録できない

生成AIのリスクに対する一般的な対応は、企業向け契約のもとで一部のAIサービスを承認し、それ以外の利用を控えるよう促すか、ブロックすることです。94.2％という数字は、実際の利用状況に対してそのリストがどれほど遅れているかを示しています。納期に追われるエンジニアは、目の前の問題を解決できるツールを使います。承認済みツールの調達には何週間もかかるからです。

リストを完全なものにしても、CSAが求めたレポートは作成できません。インシデント対応チームや監査担当者が確認するのは、データが外部に流出した特定の事案です。ツールの一覧には、個々の事案の記録はありません。

その事案で何が起きたのかを示すには、機密データの内容、データを受け取ったツール、利用されたアカウント、そしてその人がデータを送信した理由という4つの事実が必要です。

ツール単位のガバナンスが最初に破綻するのは、アカウントの段階です。同じウェブサイトでも、データ保持の設定や契約条件が適用される会社の法人アカウントと、そのどちらも適用されない従業員個人の無料アカウントの両方から利用できます。承認済みツールを個人アカウントで使った場合、得られる証拠は未承認ツールを使った場合とほぼ変わりません。

目的を特定するのはさらに難しく、何か問題があったかどうかを左右します。壊れた数式を修正するために、財務アナリストがチャットボットに収益モデルを貼り付けるのは業務の一環です。一方、金曜日に退職届を提出した人が同じものを貼り付けた場合は、まったく異なる対応が必要です。この違いを見極める手がかりは、その人を取り巻く状況にありますが、そうした情報がデータの中身に現れることはありません。

現在使われている制御は、それぞれ一か所しか見ていない

この調査では、AIツールに送信される機密データを制御する方法として、特定のアプローチが主流になっているわけではないことが分かりました。AIドメインのネットワークレベルでのブロック、ブラウザー上でのコンテンツ検査、利用規定のみの適用は、それぞれ21～23％でした。一方、DLPを組み込んだ企業向けAIプラットフォームは10％でした。

これらの制御はどれも、単一の検査ポイントを中心に設計されています。ドメインのブロック機能は、接続を許可または遮断し、接続先のサイトを記録します。ブラウザー拡張機能は、そのブラウザーに入力された内容を確認できますが、デスクトップアプリ、コードエディター内のコーディングアシスタント、コマンドラインツールから送信された内容は見逃します。企業向けAIプラットフォームに組み込まれたDLPが確認できるのは、そのプラットフォームに入力された内容です。どの制御も確認する場所は一つだけで、データがそこを通ることを期待しています。

検査ポイントが一つしかないことは、制御の適用状況に関する数字も説明します。企業アカウントと個人アカウントを区別できない、あるいは日常的な貼り付けとリスクの高い貼り付けを見分けられない制御は、両方をブロックするか、どちらもブロックしないかのいずれかしかできません。その結果、厳格なブロックはリスクの高い行為だけでなく、正当な業務まで妨げてしまいます。積極的なブロックをさらに進めていない主な理由を尋ねたところ、回答者の46％が業務ワークフローを妨げる懸念を、39％がDLPの精度に対する信頼不足を挙げました。

留意しておきたい調査上の制約

この調査の数値は回答者の自己申告に基づくもので、可視性の評価を実際の把握範囲と照らし合わせて検証したわけではありません。回答者は南北アメリカ地域（80%）と、従業員数5,000人未満の組織（67%）に偏っているため、大規模なグローバル企業にも同じように当てはまるとは限りません。また、テレメトリーの対象は、こうした可視化の仕組みを導入することを選んだ組織です。そのため、AIの無秩序な利用をすでに懸念している組織に偏っている可能性があります。

承認済みツールやエージェントが加われば、リストはさらに不完全になる

承認済みのSaaS製品にAIアシスタントが追加されると、データを受け取ったツールは何かという問いには、多くの場合、2つの答えがあります。従業員が開いたアプリケーションと、その背後にあるAIモデルのプロバイダーです。AIエージェントが加わると、状況はさらに複雑になります。エージェントがファイルを取得し、従業員に代わってどこかへ送信する場合、誰が何のために行ったのかは、ソフトウェアにも部分的に委ねられることになります。Unite.AIの最近の記事が指摘するように、本番環境のエージェントに対するプロンプトインジェクションによって、エージェントは読んだコンテンツに誘導される可能性があります。そのため、エージェント自身による行動の説明を、目的を裏付ける証拠の代わりにすることはできません。

今月実施できるテスト

直近30日間を振り返り、AIツールに渡ったと思われる最も機密性の高いデータを1つ選んでください。次に、手作業で情報をまとめることなく、チームが以下の内容を提示できるか確認しましょう。

• データの内容と入手元
• 承認リストにないツールも含め、データを受け取ったツール
• 企業アカウントと個人アカウントのどちらを経由したか
• データを送信したとき、その人がどのような作業をしていたか

最初の2項目にはすぐ答えられても、後の2項目を確認するには従業員への聞き取りが必要だとしたら、ガバナンスが把握できているのはツールの一覧だけで、データについてはほとんど把握できていません。