「社内の共有フォルダやメールを AI アシスタントにつないだら、資料探しが一気に楽になった！」——そんな声を聞く機会が増えました。その一方で、導入を任された担当者からはこんな不安も聞こえてきます。「人事評価のファイルについて新入社員が質問したら、AI は答えてしまわないだろうか」「社員が顧客の名簿を、無料の生成AIに貼り付けていないだろうか」。
どちらも、AI そのものが悪いわけではありません。問題は「AI に何を見せたか」「AI に入れた情報がどこへ行くか」を誰も決めていないことです。AI は検索も要約も速いので、これまで「誰も探さないから」表に出なかった情報まで、あっさり見つけて答えてしまいます。
この記事では、社内データが AI を通じて漏れる経路を 3 つに分け、関連する研究 4 本を紹介しながら、運営者・情シス担当者がやるべきことを整理します。プロンプトインジェクション（AI への指示の乗っ取り）そのものの仕組みはLLMエージェントのセキュリティの記事で扱っているので、ここでは「漏えい」と「アクセス権」に絞ります！
漏えいの 3 つの経路
社内データが AI を通じて外に出る道筋は、大きく次の 3 つに整理できます。
- 入力から漏れる
社員が業務の情報を外部の生成AIサービスに入力し、それが提供元で保存されたり、学習に使われたりする経路です。 - 権限を越えて答える
社内の AI アシスタントが、質問した人には本来見る権限のない文書を参照して答えてしまう経路です。 - 外へ送り出される
外から届いたメールや文書に紛れた指示で AI が社内データを外部へ送ってしまう、あるいはチャットボットのサービス自体が会話の内容を第三者へ送っている経路です。
実際には、これらの経路は重なることがあります。たとえば社員が入力した内容（1 の経路）が、サービス側の解析ツールを通じて第三者に届く（3 の経路）、といった具合です。
OWASP（ソフトウェアのセキュリティ向上に取り組む非営利団体）がまとめた LLM アプリのリスク一覧でも、機密情報の漏えいは 2 番目の項目「LLM02:2025 Sensitive Information Disclosure」として挙げられています。対策としては、最小権限の考え方で「その利用者やその処理に必要なデータだけ」にアクセスを絞ること、データの保存・利用・削除の方針を明確にし、学習に使われることを利用者が拒否できるようにすることなどが示されています。システムプロンプト（AI への事前の指示）で「これは答えないように」と制限をかける方法も紹介されていますが、その制限は必ずしも守られず、すり抜けられうるとも書かれています（OWASP「LLM02:2025 Sensitive Information Disclosure」）。
つまり「AI に言い聞かせる」だけでは足りず、仕組みで止める必要がある、ということです。ここから、研究が示していることを順に見ていきましょう。
研究から見えること
📄 論文: 「会話の参加者全員が見てよい情報だけ」を使う
Enterprise AI Must Enforce Participant-Aware Access Control（Shashank Shreedhar Bhatt ほか、2025年9月、arXiv:2509.14608）は、査読前の論文（プレプリント）で、企業向け AI の設計について立場を表明する論文です。
著者らは、社内データで追加学習したモデルや、社内文書を検索して答える RAG（検索拡張生成）の構成に対して、アクセス制御が欠けていることを突いて機密を引き出す攻撃を実演しました。そのうえで、入力の無害化、出力のフィルタ、システムの分離、学習時のプライバシー保護といった既存の防御は、役には立つものの、どれも「たいていは防げる」という確率的なものにとどまり、確実な保証にはならないと論じています。
提案はシンプルです。学習・検索・回答の生成に使う情報は、すべて「その会話に関わる利用者全員が閲覧を許されたもの」に限る、という原則を、確率ではなく確定的なルールとして強制すること。たとえば部長と新入社員が同じ会話にいるなら、AI が使ってよいのは 2 人とも見られる文書だけ、という考え方です。著者らは、この仕組みが実際の企業向け製品の追加学習機能に導入されたと述べています。
運営者にとっての意味は、「AI に見せる範囲＝その利用者が元から見られる範囲」になっているかを、導入前に確かめることです。出力のフィルタは補助にとどめ、元の文書のアクセス権で止めましょう。
📄 論文: メール 1 通で社内データが持ち出されうる——ゼロクリックの漏えい事例
EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System（Pavan Reddy ほか、2025年9月、arXiv:2509.10540）は、abs ページに「AAAI Fall Symposium Series 2025 で発表」と記載のある論文です。
対象は、Microsoft 365 Copilot で報告された脆弱性 CVE-2025-32711 の事例研究です。外部から細工されたメールが 1 通届くだけで、利用者が何も操作しなくても、AI アシスタントを経由して社内データが外部へ持ち出されうる状態でした。著者らは、AI 側の入力の判定や表示の制限など、いくつもの防御が組み合わせてすり抜けられたことを分析し、なぜ既存の防御が効かなかったのかを整理しています（具体的な手口はここでは扱いません）。
論文がまとめた教訓は、最小権限の原則、何重にも防御を重ねる設計、そして継続的な攻撃側の視点でのテストです。対策としては、外から来た内容と社内の指示を分けて扱うこと、入出力のフィルタの強化、情報の出どころに基づくアクセス制御などが挙げられています。なお、この脆弱性について Microsoft はサービス側で修正済みで、利用者が行う対策はないと案内しています（深刻度は Critical、CVSS 基本値 9.3）（Microsoft Security Response Center「CVE-2025-32711」）。
運営者にとっての意味は、外部から届くメールや文書を読む AI に、社内のあらゆる情報へのアクセスを持たせないことです。クラウドの AI は提供元が修正するので、修正情報を追いつつ、こちらはアクセスできる範囲を設定で絞っておきましょう。
📄 論文: 利用者の多くは「入力が学習に使われうる」ことを知らない
Prevalence of Security and Privacy Risk-Inducing Usage of AI-based Conversational Agents（Kathrin Grosse ほか、2025年10月、arXiv:2510.27275）は、IEEE Access 採録の論文です。
2024 年に英国の成人 3,270 人の代表サンプルを調査し、対話型 AI を週 1 回以上使う「常連」に使い方を尋ねました。回答は本人の自己申告で、実際の被害を測ったものではありません。常連のうち最大 3 分の 1 が、攻撃につながりうる使い方をしていると答えました。データを伏せてから入力していると答えた人は半数で、パスワードのようなとても機微な情報を入れる人は少数でした。一方で、回答者の半数余りは「入力したデータがモデルの学習に使われうること」を知らず、学習への利用を拒否できるかについては大半が「分からない」と答えていました。
運営者にとっての意味は、「学習に使われない設定になっているか」の確認を社員一人ひとりに任せきりにしないことです。会社として使ってよいサービスと設定を決め、周知しましょう。
📄 論文: AI チャットボット自体が、第三者へ情報を送っている
Tracking Conversations: Measuring Content and Identity Exposure on AI Chatbots（Muhammad Jazlan ほか、2026年4月、arXiv:2604.27438）は、査読前の論文（プレプリント）です。
人気の AI チャットボット 20 種について、機微な内容の質問を送ったときの通信を管理された条件で記録し、会話の内容や利用者の身元に関わる情報が誰に送られているかを調べました。その結果、20 種のうち 17 種が少なくとも 1 つの第三者に情報を送っていました。さらに 3 種では、画面操作を記録する解析ツール（セッションリプレイ）を通じて、質問と回答の一部を含む会話の文面が、伏せ字などの加工をされない文字のまま第三者に送られていました。あくまでこの 20 種とこの測定条件での結果ですが、「AI の提供元の外」へ情報が出る経路が現にあることを示しています。
運営者にとっての意味は 2 つあります。業務で使うサービスは「AI の提供元に渡る」だけでなく、その先の解析・広告事業者まで情報が流れうる前提で選ぶこと。そして自社サイトに AI チャットを置く場合も、自社の解析タグが会話の中身を拾っていないかを確かめることです。
運営者のやること
研究と公的資料を踏まえると、やることは次の 5 つに整理できます。
1. 入力のルールを決める
個人情報保護委員会は、2023 年 6 月の注意喚起で、事業者が個人情報を含むプロンプトを生成AIサービスに入力する場合、利用目的の達成に必要な範囲内かを十分に確認するよう求めています。さらに、本人の同意なく個人データを入力し、それが回答の出力以外の目的で扱われる場合は個人情報保護法に違反する可能性があるとして、提供元がそのデータを機械学習に使わないことなどを十分に確認するよう注意を促しています（個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」）。
2026 年 10 月時点で、同委員会の注意喚起の一覧に載っている生成AI全般についての資料はこれが最新ですが、2025 年 2 月には特定の生成AIサービスについて、取得したデータが国外のサーバに保存され、その国の法令が適用される点に留意するよう情報提供も行っています（個人情報保護委員会「DeepSeekに関する情報提供」）。
社内ルールでは、「入れてはいけないもの」（顧客の個人情報、パスワードや鍵、未公開の契約情報など）と「使ってよいサービス」をはっきり書きましょう。サーバのアクセスログを AI に要約させるような場面も同じで、IP アドレスや利用者の入力値を伏せてから渡すのが安全です。
2. 設定と契約を確かめる
使うサービスごとに、入力が学習に使われるか、拒否の設定があるか、会話がどれくらい保存されるか、データがどの国・地域に保存されるかを確認します。法人契約なら、データの取り扱い条件が契約書や付属の規定にどう書かれているかも見ておきましょう。個人向けの無料版と法人向けプランで扱いが違うことも多いので、規約と管理画面の両方を見ておきましょう。
確認した結果は、サービス名・プラン・学習の設定・確認日を 1 行ずつ表にしておくと便利です。規約や既定の設定は後から変わることがあるので、半年に 1 回など時期を決めて見直しましょう。社員が個人のアカウントで使っているサービスがないかも、あわせて聞き取っておくと安心です。
3. AI につなぐ前に、アクセス権を棚卸しする
社内文書を AI アシスタントにつなぐ前に、共有フォルダやチャットで「全員に公開」になっているものを洗い出します。AI が元の文書のアクセス権を引き継ぐかどうかは、製品や構成によって違います。引き継ぐ製品でも、元の権限が緩ければ AI はそのまま広く答えてしまいますし、引き継がない構成なら権限の違う人にも同じように答えかねません。導入前に、検索の対象が利用者ごとの権限で絞られるかを提供元や制作会社に確かめましょう。異動や退職で不要になった権限が残っていないかも、このタイミングで見直しましょう。OWASP も、検索用のデータベースに利用者ごとの権限を反映させ、利用者の区分ごとにデータを分けるよう勧めています（OWASP「LLM08:2025 Vector and Embedding Weaknesses」）。
4. 外から届く内容を読む AI は、権限を絞る
メールや Web ページを読んで要約する AI に、社内のすべてを見せる必要はありません。外部の内容を扱う機能と社内データを扱う機能を分けられるなら分け、外部への送信や共有は人の確認を挟むようにしましょう。AI に社内ツールを操作させる場合の権限設計は、このシリーズの別の記事で取り上げる予定です。検索用の文書に毒を混ぜられる問題はRAGの記事で扱っています。
5. ログを残し、ときどき見る
誰が何を質問し、AI がどの文書を参照したかを記録できるサービスなら、記録を有効にしておきます。「見えてはいけない文書が参照されていた」と気づける仕組みがあれば、権限の設定ミスを早く直せます。
社内データを AI から守る鍵は次の3点です
- AI に見せる範囲は「その人が元から見られる範囲」まで
言い聞かせやフィルタではなく、元の文書のアクセス権で止めます。つなぐ前に権限の棚卸しをしましょう。 - 入力のルールと設定は会社が決める
使ってよいサービス、入れてはいけない情報、学習に使われない設定を会社として決め、社員に周知します。 - 外から届く内容を読む AI に、社内の全部を渡さない
外部のメールや文書を扱う機能は権限を絞り、外への送信には人の確認を挟みます。提供元の修正情報も追いましょう。
まとめ：「AI が何を知っているか」を決めるのは運営者！
社内データの漏えいのリスクは、「AI に何を見せ、何を入れ、どこへ送らせるか」という導入と運用の設計で大きく変わります。研究が示したのは、言い聞かせやフィルタだけでは確実に止められないこと、そして調べられた範囲でも、利用者の使い方やサービスの作りによって情報が外へ流れうるという現実でした。
まずは自社で使っている AI サービスの一覧と、その設定を確かめるところから始めてみましょう。AI 全体のリスクの地図も、このシリーズで OWASP Top 10 for LLM を運営者目線で読む回にまとめる予定です！
参考文献
- Shashank Shreedhar Bhatt ほか「Enterprise AI Must Enforce Participant-Aware Access Control」arXiv:2509.14608（https://arxiv.org/abs/2509.14608）2026-10-01 確認
- Pavan Reddy ほか「EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System」arXiv:2509.10540（https://arxiv.org/abs/2509.10540）2026-10-01 確認
- Kathrin Grosse ほか「Prevalence of Security and Privacy Risk-Inducing Usage of AI-based Conversational Agents」arXiv:2510.27275（https://arxiv.org/abs/2510.27275）2026-10-01 確認
- Muhammad Jazlan ほか「Tracking Conversations: Measuring Content and Identity Exposure on AI Chatbots」arXiv:2604.27438（https://arxiv.org/abs/2604.27438）2026-10-01 確認
- OWASP Gen AI Security Project「LLM02:2025 Sensitive Information Disclosure」（https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/）2026-10-01 確認
- OWASP Gen AI Security Project「LLM08:2025 Vector and Embedding Weaknesses」（https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/）2026-10-01 確認
- Microsoft Security Response Center「CVE-2025-32711 M365 Copilot Information Disclosure Vulnerability」（https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32711）2026-10-01 確認
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/）2026-10-01 確認
- 個人情報保護委員会「DeepSeekに関する情報提供」（令和7年2月3日・3月5日更新）（https://www.ppc.go.jp/news/careful_information/250203_alert_deepseek/）2026-10-01 確認
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（別添1・令和5年6月2日）（https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf）2026-10-01 確認
