シャドーAIが見えるのは、ブラウザの中だけ

うちの会社で、誰がChatGPTに何を入力しているか。この問いに即答できる情シスは、まだ多くありません。

帝国データバンクが2026年3月に全国23,349社を対象に実施した調査（有効回答10,312社）では、生成AIを業務で活用している企業は34.5%、大企業に限れば46.5%でした¹。使われていること自体は分かっている。しかし、誰が、どのサービスに、何を入力しているのかは掴めていない。

対策を検討し始めると、たいていはこう言われます。ブラウザ拡張を全端末に配るんですか、それはさすがに大げさでは、と。

この記事は、その疑問に正面から答えます。

先に結論を書きます。ブラウザに観測点を置くのは、安易な回避策ではなく、この問題の構造から導かれる答えです。他に場所がない、という話になります。

これは製品の優劣の話ではありません。どこに見張りを置けば見えるのか、という技術の話です。

見えるAIと、見えないAI

まず、前提を一つ更新します。

生成AIに何を入力したかはベンダー側では追えない。これは2026年時点では正しくありません。会社が契約しているAIについては、主要ベンダーがいずれもプロンプト本文に到達する手段を管理者向けに提供しています。

つまり承認済みAIについては、第三者の製品を入れなくても相当なところまで見えます。これが現在地です。

問題はここからです。この仕組みはいずれも、自社サービスの中しか見ていません。あるベンダーの管理画面で他社AIの利用は見えないし、そもそも会社が契約していなければ、どのログにも一行も残りません。

従業員が個人のGmailアカウントで無料版のChatGPTに顧客リストを貼っても、管理者は永久にそれを知りません。ライセンスを付与していないユーザーの、契約していないサービス上の行動だからです。

この非対称が、いま情報システム部門が見ている風景の正体です。見えているものはよく見え、見えないものは全く見えない。そしてリスクが高いのは、当然ながら後者です。

なぜ、ブラウザの外では捕まえられないのか

ここがこの記事の本題です。

ネットワークでも、エンドポイントでも、クラウドのAPIでもなく、なぜブラウザなのか。理由は3つあります。

1. 他社AIには、そもそもサーバ側ログが存在しない

会社が契約しているAIなら、提供元が管理者向けにログを出してくれます。自分たちの契約の中の出来事だからです。

しかしChatGPTはOpenAIのサーバーで動いています。従業員が個人アカウントでログインしていれば、その会話は自社の契約とは何の関係もありません。取りに行けるログが、どこにも存在しない。

2. ネットワーク層では、画面上の文脈が取れない

ここでよくある誤解を一つ正しておきます。SWGやCASBではプロンプトの中身は見えない、という説明を目にしますが、これは技術的に誤りです。TLSインスペクションを有効にすればHTTPSリクエストボディは復号でき、プロンプト本文の取得は原理的に可能です。実際、主要なSASE製品は生成AI向けのDLPを提供しています。

問題は、取れるのが通信の中身だけだということです。

ブラウザの中では、同じ chatgpt.com へのリクエストでも、それが法人契約のEnterpriseアカウントなのか、個人の無料アカウントなのかで、リスクの意味が正反対になります。どの入力欄に打ったのか、貼り付けたのかタイプしたのか、ファイルを添付したのか。こうした画面上の文脈は、パケットを見ても復元できません。

3. 復号しそこねる経路が増えている

仮にTLS復号を全面適用しても、逃げ道は残ります。非管理端末やBYOD、証明書ピンニングを行うデスクトップアプリ、ストリーミング応答の再構成の難しさ。そしてTLS復号自体が、運用上は適用範囲を狭くせざるを得ないことも多い。

この3つを同時に満たす観測点は、結局ブラウザの中しかありません。レンダリングされた画面を見ており、ログイン中のアカウントを知っており、暗号化される前の入力を捉えられる場所です。

観測点を置いたあと、日本で効いてくること

技術的に見えるようになることと、社内で運用できることは別です。そして日本企業では、後者のほうが導入の律速になります。

プロンプト本文は、入力者の識別子と紐づく限り従業員本人の個人データを構成します。そして本文には、従業員が業務で扱う顧客名や取引先担当者名、場合によっては健康や信条に関わる要配慮情報が混入しうる。つまり二重の意味で機微なデータを蓄積することになります。

加えて、従業員モニタリングには日本では直接規律する単独法がなく、実務上の相当性要件が定着しています。目的をあらかじめ特定して社内規程に定めること、実施を従業者にあらかじめ周知すること、責任者と権限を明確にすること、実施状況を監査すること。就業規則または情報セキュリティ規程の改定を伴う場合、周知と手続きで数週間から数か月のリードタイムが生じます。

機能比較で勝っても、ここで止まれば導入は進みません。逆に言えば、この関門を先回りして潰す設計は、機能というより受注条件です。検討するときは、少なくとも次の点を確認しておくことをおすすめします。

• 本文を保存せず集計だけを取るモードがあるか
• 個人単位ではなく部署単位に集約して見られるか
• 保持期間を決めて自動削除できるか
• 管理者が誰の本文をいつ閲覧したかのログが残るか
• 本人からの開示請求に、本人単位のエクスポートで応えられるか
• 人事評価への転用を、規程と権限設計の両方で断てるか

法務、労務の記述について本節は一般的な制度理解の整理です。個別の案件については自社の法務部門または専門家にご確認ください。

ブラウザの中で、どこまでやるか

観測点をブラウザの中に置く。ここまでは前節までの話と同じです。

ブラウザに観測点があることの本当の意味は、そこで判定まで完結できるという点にあります。Folta では次のように作っています。

ファイルは、端末の中で開いて読む

PDF、Word、Excel、PowerPoint、画像、テキスト。アップロードされようとしているファイルを拡張機能がその場で解析し、本文を取り出して判定します。文書に埋め込まれた画像やスライドも取り出します。

スキャンPDFや画像は、OCR にかける

端末上でOCRを動かしています。日本語辞書を持つモデルを選んでいるのは、軽量なモデルには日本語辞書がないためです。機密を画像化して検知をすり抜ける経路を塞ぐためのもので、この処理もクラウドに送らず端末内で完結します。

どこから来たファイルかを追う

ダウンロードしたファイルのSHA-256を端末に記録しておき、アップロード時に照合します。社内システムから落としたファイルが外部AIに上がろうとしている、という状況を、ファイル名ではなく中身の同一性で判定できます。リネームしても追えます。

アクションは4段階

ブロック、確認付きブロック、警告、監視。全部止めるのでも、全部見るだけでもない中間を用意しています。特に確認付きブロックは、理由を入力すれば続行できるアクションです。業務を止めずに、なぜ必要だったかを記録に残せます。

取るデータは、項目ごとに会社が決める

前節で、本文を保存せず集計だけを取るモードがあるかを確認項目に挙げました。Folta ではここを設定で選べるようにしています。

収集する項目ごとに、そのまま保存する、暗号化して保存する、収集しない、の3つから選べます。対象は、ファイル名、フォルダパス、ペーストしたテキスト、入力したテキスト、コピーしたテキスト、正規表現に一致した箇所、Webサイトのタイトル、ファイル要約。しかもアラート用とアクティビティログ用で別々に設定できます。暗号化は会社ごとの鍵で行い、ファイル要約は既定で収集しません。

可視化はしたいが、従業員の打った文章そのものを自社のデータベースに残したくはない。この要望は日本の法務レビューで必ず出ます。先に作ってあるのは、それが分かっていたからです。

見るのは9種類の操作

アクセス、アップロード、ダウンロード、ペースト、コピー、ログイン、拡張機能の導入、印刷、テキスト入力。ポリシー条件のオペレータはテキスト系13種、ファイル名14種ほか、正規表現も使えます。管理画面では条件を自然文に要約せず、設定値のまま表示します。

MDM がない会社を切り捨てない

配布は Jamf、Intune、GPO によるMDM配布と、管理画面からセットアップキットをダウンロードして実行する経路の両方。対応は Chrome 120以降、Edge 120以降、macOS 12以降、Windows 10および11。

情報システム部門が専任1人以下という会社は珍しくありません。MDMが全社に行き渡っている前提を置けるかどうかで、可視化から始められるかが決まります。

見えないものは、対策しようがない

冒頭の疑問に戻ります。ブラウザ拡張を全端末に配るのは、たしかに大げさに見えます。

でも、これは好みの問題ではありません。他社AIには取りに行けるサーバ側ログがなく、ネットワーク層では画面上の文脈が取れず、復号しそこねる経路も残る。消去法でブラウザが残る、という話です。

ブラウザの中を見ないことには、始まりません。