お問い合わせ
AIセキュリティ

シャドーAIによる情報漏えい、なぜブラウザで統制すべきか

·

禁止から条件付き許可へ

2023年4月、サムスン電子の半導体部門に所属する複数のエンジニアがソースコードと会議内容をChatGPTに入力していたことが社内で確認されました。同社は5月初めに社内端末と社内ネットワークでの生成AIの利用を制限し、当時、複数のグローバル金融機関や企業が同様の措置を取りました。

禁止は長続きしませんでした。韓国の金融委員会（FSC）と金融監督院（FSS）は2024年8月13日に「金融分野ネットワーク分離改善ロードマップ」を発表し、金融機関が生成AI・SaaSを活用する道を開きました。同年11月27日には、生成AIを活用した9社の金融機関による10件の革新金融サービス（韓国の金融規制サンドボックス制度による指定）を初めて指定し、申請期間だけで74社から141件の申請がありました。指定はセキュリティ対策の遵守を付帯条件としています。

問われているのは、もはや「生成AIを禁止するか」ではなく、「どのデータが、どのアカウントで、どこへ送られるかを統制しながら許可するか」です。

数字で見るシャドーAI

シャドーAI(Shadow AI)とは、組織の承認やセキュリティレビューを経ずに従業員が業務で使用するAIツールを指します。

指標数値出典
シャドーAIが関与したセキュリティインシデントの割合20%(2025) → 43%(2026)IBM Cost of a Data Breach 2026
シャドーAIが関与したデータ侵害の平均コスト539万ドル(前年463万ドル)IBM Cost of a Data Breach 2026
データ侵害を受けた組織のうちAIガバナンスポリシーがない割合68%IBM Cost of a Data Breach 2026
生成AIへの貼り付けのうち非管理(個人)アカウントの割合82%LayerX Enterprise AI & SaaS Data Security Report 2025

IBMのレポートは、Ponemon Instituteが2025年3月から2026年2月の間にデータ侵害を経験した16か国・17業種の602組織を調査した結果です。LayerXの数値は同社の顧客企業のブラウザテレメトリに基づくため、標本の特性を考慮して解釈する必要があります。

二つの資料が示す方向は同じです。データはファイルではなく、テキストの断片という形で、ブラウザの入力欄を通じて外に出ています。

既存の統制レイヤーが見落とす三つのポイント

1. 復号除外トラフィック

ネットワークDLPとSWG(Secure Web Gateway)が送信内容を検査するには、TLS復号が前提となります。個人向けの金融・医療サイトや証明書ピンニング(certificate pinning)を使うアプリのように、運用上復号の対象外とするトラフィックは内容検査の対象から外れます。除外リストが増えるほど、死角も広がります。

2. QUIC(HTTP/3)トラフィック

HTTP/3はQUIC上で動作し、QUICはTCPではなくUDPを使用します(RFC 9000、RFC 9114)。TCPベースのプロキシのみを運用している環境では、UDP 443のトラフィックが検査経路から外れることがあります。Chromiumのイシュートラッカーには、2015年にこの問題を理由としてポリシーの追加を求めた記録があり、その後QuicAllowedポリシーが導入されました。

プロキシがQUICの検査に対応していない場合は、管理対象ブラウザでQUICを無効にするのが最も簡単な措置です。Windowsのグループポリシーを使わない環境であれば、次のレジストリ値で同じ設定を適用できます。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"QuicAllowed"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"QuicAllowed"=dword:00000000

適用されているかどうかはchrome://policyまたはedge://policyで確認できます。境界ファイアウォールでUDP 443もあわせて統制すると、ブラウザはTCPベースのHTTP/2またはHTTP/1.1にフォールバックします。ただし、一部のサービスで体感速度が低下する可能性があるため、変更管理の手順を経て適用してください。

3. 同じドメイン、異なるアカウント

多くのSaaSや生成AIサービスでは、個人アカウントと企業アカウントが同じドメインを使用します。宛先ドメインを基準としたポリシーだけでは、「承認された企業テナントへの入力」と「個人アカウントへの入力」を区別することは困難です。前掲の表で貼り付けの82%が非管理アカウントで発生していたという数値が、この死角の大きさを示しています。

統制レイヤー別の可視性比較

統制レイヤー確保できる可視性死角が生じやすい領域
ネットワーク(SWG・CASB・ネットワークDLP)宛先ドメイン、復号されたHTTPリクエスト復号除外トラフィック、検査されないQUICトラフィック、同一ドメイン内のアカウント区別
エンドポイントDLPファイル移動、OSクリップボード、記憶媒体どのウェブアプリのどのアカウントの入力欄かというコンテキスト
ブラウザレイヤー入力・貼り付け・アップロードイベントの平文、タブのURLとログインアカウントのコンテキスト非管理ブラウザ、デスクトップ専用アプリ、API・CLI呼び出し

どのレイヤーも単独では完結しません。ブラウザレイヤーの強みは、暗号化される前の平文を、どのサービスのどのアカウントに入力されるかとあわせて把握できる点にあります。

ブラウザレイヤーでの統制の設計原則

1. 送信前にイベント単位で判定

貼り付け、キーボード入力、ファイルアップロード、ドラッグ&ドロップはそれぞれ異なるイベントです。リクエストがサーバーに送信される前にイベント単位で判定してはじめて、「送信された後に検知する」事後対応を避けられます。

2. アカウント・テナントのコンテキストを加味

同じ文章でも、承認された企業テナントに入力されれば許可し、個人アカウントに入力されれば警告または遮断するといった判定が必要です。ポリシーの基本単位は「ドメイン」ではなく、「サービス + アカウント + データ種別」の組み合わせです。

3. 遮断一辺倒ではない段階的な対応

対応適用例期待される効果
許可 + 記録承認された企業テナント、機微情報の未検知業務フローの維持、利用状況の可視化
警告 + 理由入力未承認サービス、または社内文書と推定されるテキストユーザー自身の判断を促し、迂回の動機を減らす
マスキング住民登録番号（韓国の個人識別番号）・口座番号などの識別パターンを検知業務目的を維持しつつ識別情報のみを除去
遮断ソースコード・顧客データの大量貼り付け、個人アカウントへのファイルアップロード高リスクの漏えい経路を封鎖

一律に遮断すればユーザーは個人端末へ移り、組織は可視性を失います。

4. 原文ではなくメタデータをログに記録

プロンプトの原文をそのまま保存すると、ログサーバーが新たな機微情報の保管場所になります。検知種別、措置結果、対象サービス、ユーザー、時刻を基本として記録し、原文の保管は例外的な場合に限り、保管期間とアクセス権限を統制したうえで行うほうが安全です。

5. 迂回経路もあわせて封鎖

ブラウザレイヤーの統制は、管理対象ブラウザの中でのみ有効です。生成AIのドメインには管理対象ブラウザからのみアクセスできるようネットワークポリシーをあわせて適用し、デスクトップ専用アプリやAPI呼び出しの経路はエンドポイント・ネットワークのポリシーで補完する必要があります。

導入順序 - 可視化、コーチング、強制適用

最初から遮断ポリシーを有効にすると、誤検知と業務部門からの苦情が一度に押し寄せます。以下の順序は、運用負担を分散させながら定着させるための推奨フローです。

段階運用モード目標成果物
1. 可視化記録のみどのAIサービスに、どのアカウントで、どの種別のデータを入力しているかを把握サービス・アカウント・データ種別ごとの利用状況
2. コーチング警告 + 理由入力承認サービスへ誘導し、ポリシーをユーザーに認知させる承認サービス一覧、例外申請フロー
3. 強制適用マスキング・遮断高リスクのデータ種別と個人アカウント経路を優先的に統制データ種別ごとの強制適用ポリシー
4. 運用定期チューニング誤検知の調整、新規AIサービスの反映四半期ごとのポリシーレビュー記録

第1段階の結果があってこそ、第2段階以降のポリシーを根拠をもって設計できます。利用状況を把握せずに作った遮断ポリシーは、ほとんどが過剰か漏れのどちらかです。

まとめ

生成AIは禁止の対象から管理の対象へと変わりました。管理の要は、データが暗号化されてネットワークへ出ていく前、ユーザーが貼り付け操作を行うまさにその瞬間にあります。その瞬間を最も近くで捉えられるのがブラウザです。

ZensLabは、ブラウザをポリシー実施ポイント(PEP、Policy Enforcement Point)とするクライアントベースのセキュアブラウザBrowZenを提供しています。セキュアブラウザの基本概念や、VDI・RBIなど他の方式との違いはセキュアブラウザ(SEB)とは何かでご確認いただけます。

参考資料

よくある質問

生成AIサイトをドメイン単位で遮断すれば十分ではありませんか。

新しいAIサービスが増え続け、既存の業務SaaSにもAI機能が組み込まれているため、ドメインリストだけでは漏れが生じます。全面遮断は個人端末や個人アカウントの利用による迂回を招き、かえって可視性が失われます。承認済みのサービスは許可し、機微情報の入力のみを統制する方式が現実的です。

ブラウザの拡張機能でも同じ統制は可能ですか。

拡張機能もページ上のイベントを観測でき、既存のブラウザに素早く配布できるという利点があります。ただし、ブラウザポリシーで強制インストールと無効化防止をあわせて設定する必要があり、ユーザーが拡張機能の入っていない別のブラウザを使えば統制の外に出てしまいます。いずれの方式でも、非管理ブラウザの経路をネットワークポリシーであわせて塞いではじめて実効性が確保されます。

プロンプトの原文は全件ログに残すべきですか。

推奨しません。プロンプト原文のログはそれ自体が機微情報の保管場所となり、新たな漏えいの標的になります。検知種別、措置結果、対象サービス、ユーザー、時刻などのメタデータを中心に記録し、原文の保管がどうしても必要な場合は保管期間とアクセス権限を別途統制する方式が、個人情報の収集を必要最小限にとどめるという原則の趣旨に沿います。

あわせて読みたい