Accenture Japan (有志)
🥷

「生成AIだから機密情報を送るな」は本当に正しい議論なのか

kaito.abe
に公開
情報セキュリティ
生成 AI
AIエージェント
Claude Code
生成aiガイドライン
idea

はじめに

先日、あるSNSのタイムラインであるやり取りが目に入りました。要約すると、「社用PCでAIコーディングツールを使って業務情報を扱った場合、顧客に関するデータを外部のAIサービスに渡していることになるのでは？」という疑問に対し、「それはポリシー違反でしょう」という回答がなされていた、というものです。

このやり取り自体は至極まっとうな問題提起だと思います。ただ、私はこのやり取りを見て少し引っかかるものがありました。この議論の前提はそもそもずれていないだろうか、と。

そんな折に、広木大地氏のNewsPicks記事「『生成AIガイドライン』がナンセンスになる理由」[1]を読み、自分の中のモヤモヤがかなり整理されました。本記事では、広木氏の記事で提示された論点をベースに、私自身の実体験や現場での所感を交えながら、「生成AIを通じて機密情報が外部に送信されること」に対する懸念について整理してみたいと思います。

「外部にデータを送るな」は生成AI以前からの話ではないか

生成AIが業務に入り込み始めてから、「機密情報を外部サービスに送信してはならない」という議論を目にする機会が増えたように感じます。もちろんその懸念自体は理解できます。ただ、ここで一度立ち止まって考えてみたいのは、この問題は生成AI固有のものなのだろうか、ということです。

たとえば、多くの企業がBoxやOneDrive、Google DriveといったクラウドストレージにNDA付きの資料を保存しています。Notionに議事録を書き、CRMに顧客情報を入力し、GitHub上でソースコードを管理している。これらはすべて「外部サービスにデータを送信している」行為にほかなりません。

広木大地氏がNewsPicksの記事で指摘されているように、「外部サービスに機密情報を送ってはいけない」というルールを字義通りに適用すれば、Notionも、CRMも、GitHub Secretsも使えなくなってしまいます[1:1]。つまり、「外部サービスに機密情報を送ること」自体が問題なのではなく、「そのサービスが情報をどう扱うか」が本質的な論点なのではないかと思います。

もちろん、生成AIには「入力データがモデルの学習に使われる可能性がある」という、従来のSaaSにはなかった固有のリスクがあります。BoxやNotionとまったく同じだと言いたいわけではありません。ただ、そのリスクも後述するオプトアウトや法人契約で技術的に対処できる領域であり、「データが外部に出る」という構造自体は既存サービスと共通しています。にもかかわらず、生成AIが絡んだ途端に「データが外に出る」ということだけが過度にクローズアップされている印象があります。

友人からの質問「チャッピーって情報漏洩しないの？」

先日、営業をやっている大学の友人から「チャッピーって情報漏洩しないの？」と聞かれたことがありました。もちろんチャッピーはChatGPTのことを指すのですが、正直答えに窮しました。ChatGPTひとつとっても、答えはプランによってまったく違うからです。個人プラン（Free・Plus）であれば、設定画面の「モデルを改善する」をオフにすることで学習利用は止められますが、不正利用防止の目的で最大30日間はデータが保持されます。一方、Team・Enterpriseプランであればそもそもデフォルトで学習に使われません。つまり「漏洩するの？」という問いに対する答え自体は、仮に個人プランだとしても「限りなく0%だと思うよ」だとは思います。ただ友達が求めている答えは恐らくそうではなく、「入力した情報が学習利用されているのではないか」が本当の問いだとするならば、その答えにたどり着くには「どのプランで、どの設定で使っているか次第」なのですが、友人はそもそもプランの違いという前提を持っていませんでした。この漠然とした問いの立て方自体が、生成AIに対する不安の根っこにあるのではないかと感じています。

「機密情報を送るな」の先にあるジレンマ

私自身も生成AIを業務で使う中で、この矛盾に直面することがあります。たとえば、障害対応中にアプリケーションのログをAIに解析させて原因を特定したい場面があったとします。しかしログにはユーザーIDやIPアドレスなどの個人情報が含まれている。「機密情報を送るな」というルールを守ろうとすると、ログ解析にAIを使うこと自体ができなくなるというジレンマです。

また、個人が特定されないダミーデータをもとに生成AIに顧客向けの提案をブレストしてもらおうとしたこともあります。しかし、具体的な文脈が欠落したダミーデータでは、返ってくるのは教科書通りの体温のない回答ばかりで、実務に使えるレベルのアウトプットにはなりませんでした。「機密情報を入れなければ安全」というのは確かにそうなのですが、それでは生成AIを業務に活用する意味そのものが薄れてしまうのではないかと思います。

オプトアウトの現状を整理する

「学習に使われるかもしれないから業務データを入力してはいけない」という懸念もよく耳にします。この点については、現在の主要なAIサービスのオプトアウト状況を整理しておくと見通しが良くなるかもしれません。

主要なAIサービスの法人プランにおけるデータ学習利用の状況を表にまとめると、以下のようになります。

サービス 法人プラン デフォルト学習利用 備考
ChatGPT Enterprise / API OFF DPA契約で保証。APIはデフォルトでオプトアウト[2]
Claude Team / Enterprise / API OFF 入力データを学習に使用しないことを明示[3]
GitHub Copilot Business / Enterprise OFF コードデータを学習に使用しない[4]
Gemini Workspace Enterprise OFF ドメイン外でのモデル学習・人間レビューなし[5]

一方で、消費者向けプラン（無料版や個人向け有料版）では、デフォルトで学習利用がオンになっているケースが多く、手動でオプトアウトする必要があります。また、オプトアウト後も安全目的で7日から30日程度データが保持される場合があり、Enterprise契約ではZero Data Retention（即時削除）の設定が可能なサービスも存在します。詳細は各サービスの公式ドキュメントを確認していただければと思います。

つまり、法人契約で適切なプランを利用し、オプトアウト設定を確認している限り、「学習に使われるリスク」は技術的にはかなり限定的だと考えられます。広木氏も「会社で使うサービスはオプトアウトができている前提のものを使えばよい」と述べていますが、私もこの考え方は合理的だと感じています[1:2]。

「生成AIガイドライン」という括り方の問題

ここで一つ、私が共感した論点を紹介したいと思います。それは、「生成AIガイドライン」という名前空間が大きすぎるのではないか、という問題です[1:3]。

多くの企業が「生成AI利用ガイドライン」を策定しようとしている印象です。JDLA（日本ディープラーニング協会）のひな形[6]をベースにカスタマイズしている企業も多いようです。しかし、1つのガイドラインでテキスト生成AI、画像生成AI、AIエージェント、外部SaaSに組み込まれたAI機能、ローカルLLMをまとめてカバーしようとすると、抱えているリスクの種類がまったく異なるものを一律に扱うことになってしまいます。

たとえばローカルLLMに業務データを入力する場合、データは外部に一切出ません。それを「生成AIだから」という理由で禁止する根拠はないはずです。一方で、消費者向けのChatGPTに顧客情報を入力するのは、学習利用の観点からリスクがあるかもしれません。この2つを同じガイドラインで一括りにすること自体に無理があるのではないでしょうか。

ツールごとにルールを決めるという考え方

私の考えとしては、ツールごとにルールを決めるのが現実的ではないかと思っています。Claude CodeにはClaude Codeのリスクに応じたルールを、CodexにはCodexの、GitHub CopilotにはGitHub Copilotの。それを「生成AI」という大きな括りで抽象化してガイドラインにまとめてしまうと、運用が必要以上に厳しくなるか、逆に緩くなるか、どちらかに振れてしまうのではないかという広木氏の主張に大いに同意します。

ただ策定側の負担はかかる

もちろん、ツールごとにルールを整備するのはガイドラインを策定する側にとって大きな負担になることは理解しています。ツールの数だけルールが必要になり、アップデートへの追従も求められます。それでも、実態に合わないガイドラインが形骸化してしまうよりは、負担を引き受けてでもツール単位で整理するほうが、結果的に組織を守ることに繋がるのではないかと思っています。最初から完璧を目指さなくても、たとえば四半期ごとに利用ツールの一覧と各ツールのデータポリシーを棚卸しするだけでも、最初の一歩としては十分ではないでしょうか。

AIエージェントの本領発揮にはサービス連携が大事だという考え

ここまで「ツールごとにルールを決めるべきではないか」という話をしてきましたが、ルールの設計を考えるうえで避けて通れないのが、AIエージェントと業務ツールの連携の問題です。冒頭で紹介したSNSのやり取り、「AIツールでGmailやGoogleチャットの情報を扱うのはNG」という判断について考えてみます。

AIエージェントがその威力を発揮するのは、メールやチャット、カレンダー、ファイルストレージといった業務ツールと連携したときではないかと思います。AIエージェントがローカルのファイルしか読めず、メールもチャットも参照できない状態では、ワークフローの各ステップで結局人間が情報を取ってきて渡す作業が発生してしまい、エージェントに期待しているはずの自律性が活かせないのではないでしょうか。

広木氏の記事では、Googleカレンダーの確認、メッセンジャーの確認、メール送信、資料の書き換えなど、30以上のワークフローと連携したAIエージェントの運用事例が紹介されています[1:4]。議事録作成から給与明細の変動検知まで自動化しているとのことで、こうした連携ができて初めてエージェントとしての価値が生まれるのだろうと感じました。

「外部にデータが送信されるからNG」と一律に制限してしまうと、AIエージェントの導入効果を大きく削いでしまう可能性があります。もちろんリスク管理は必要ですが、リスクを理由に連携そのものを封じてしまうのではなく、適切な権限管理のもとで連携を実現する方向で考えたほうが建設的ではないかと思います。

本当に議論すべきはエージェントの権限管理

では、生成AI、とりわけAIエージェントにおいて本当に新しいガイドラインが必要な領域はどこなのか。私はエージェントに対する権限の制御がその本丸ではないかと考えています。

AIエージェントに業務ツールへのアクセス権限を渡すとき、考えなければならないのは「誰の権限で」「何ができるか」「誰がそれをトリガーできるか」という3つの観点です。たとえば、私がAIエージェントにGmailの閲覧・送信権限を渡したとします。私だけが指示を出す環境であれば、私がメーラーを操作しているのと大きくは変わりません。しかし、そのエージェントをチーム共有のチャットボットとして公開し、誰でも「このメールに返信しておいて」と頼める状態にしたらどうでしょうか。私のメールアカウントの権限で、他の人が意図した内容を送信できてしまうことになります。これは「データが外に漏れる」とは別次元の、権限委譲の問題です。

さらに、AIエージェントのセキュリティリスクは「データの外部送信」だけに限りません。Check Point Researchが発見したClaude Codeの脆弱性（すでに修正済み）では、悪意のある設定ファイルを含むリポジトリをcloneするだけで任意コードが実行されたり、APIキーが窃取されたりする問題が報告されています[7]。

「致命的な三角形」という考え方

セキュリティ研究者のSimon Willisonが提唱する「Lethal Trifecta（致命的な三角形）」という概念が、この問題の構造を理解するうえで参考になります[8]。AIエージェントが以下の3条件を同時に満たすと、高度な技術がなくても情報の持ち出しが構造的に成立してしまうとされています。

  • 機密データへのアクセス: .envファイルやローカルの設定ファイルを自動的に読み取れる
  • 外部への送信能力: curlやHTTP通信、MCPツール経由で外部と通信できる
  • 外部からの命令注入: Webページや設定ファイルを通じてプロンプトインジェクションを受け付けてしまう

ここで重要なのは、「機密情報を外部に送るな」というルールは、この3条件のうち1つ目にしか対処できていないということです。送信能力や命令注入のリスクが残ったままでは、構造的な安全性は確保できません。

実際、プロンプトインジェクションの検証においても興味深い結果が報告されています。curlを使った明示的な外部送信型の攻撃はAIが検知してくれるものの、自然なコード例にprintデバッグを混ぜる手法は検知されなかったそうです[9]。これは「AIがファイルを読める・コードを実行できる」という新しい信頼境界を意識する必要があることを示しているように思います。

こうしたリスクに対処するために必要なのは、「機密情報を外部に送るな」という包括的な禁止ではなく、エージェントごとの権限設計ではないでしょうか。Claude Codeでいえば、settings.jsonでの権限制御、.envファイルの適切な管理、MCPサーバーの棚卸し、auto-acceptモードの回避といった具体的な対策を、ツールごとに整理して運用に落とし込むことが重要だと考えています。

敏感になるべきこと、過剰に反応すべきでないこと

ここまでの内容を踏まえて、「これは過剰な警戒かもしれない」と「これは正当に敏感であるべき」の線引きを、私なりに整理してみます。

以下に当てはまるなら、過剰な警戒になっている可能性があります:

  • そのリスク、BoxやNotionなどの既存クラウドサービスでも同じ構造ではないか？　→ 生成AI固有のリスクではなく、外部サービス全般の問題かもしれません
  • 法人契約でオプトアウト済みのサービスに対して「学習に使われるかもしれない」と懸念していないか？　→ 契約とポリシーで技術的に担保されているなら、感覚的な不安と切り分けて考える余地があります
  • 「生成AIだから」という理由だけでNGを出していないか？　→ 同じデータを既存のSaaSに渡すのはOKなのに、生成AIだけNGとしている場合、判断基準が一貫していない可能性があります

一方で、以下は正当に敏感であるべきだと考えます:

  • AIエージェントに渡している権限は、本当にその業務に必要な最小限の範囲か？
  • そのエージェントを操作できるのは誰か？　意図しない第三者がトリガーできる状態になっていないか？
  • 利用しているMCPサーバやプラグインの中身を把握しているか？　外部からの命令注入の経路になっていないか？
  • ツールごとにリスク特性が異なることを前提にした運用ルールが存在するか？

生成AIのリスクをゼロにすることは不可能ですし、それは生成AI以外のあらゆる外部サービスについても同じことが言えます。大切なのは、漠然とした不安に基づく一律の制限ではなく、リスクの所在を正確に理解したうえで適切に管理することではないかと思います。

おわりに

本記事で述べたことは、あくまで広木氏の記事をもとにした一個人の考えであり、もっと適切な整理の仕方があるかもしれません。また、業種や扱うデータの機密度によって、取るべきアプローチは当然異なります。セキュリティ部門がリスクがある以上は制限をかけるという判断をすることは、その職責として正しいと思っています。本記事は「制限をなくせ」と主張したいのではなく、「制限の粒度をもう少し細かくできないか」という提案です。「生成AIだから危険」「外部にデータが出るからNG」という粒度の粗い議論が、本質的なリスク管理から目をそらすことに繋がっていないか。その点を一度立ち止まって考えてみる価値はあるのではないかと思っています。

リスクの所在を正確に理解することが、結果的に活用を前に進める第一歩になるのではないでしょうか。何が本当に危険で、何が過剰な警戒なのかを整理できれば、「使わない理由」ではなく「どう使うか」の議論に進めるはずです。

ガイドラインは不安を払拭するための法的整理としては意味があると思います。しかし、広木氏が述べているように、本当の課題は活用の促進であって、制約の設計だけではないはずです[1:5]。使いこなせていない段階でルールを厳しくしても、「やっぱりAI使わなくていいよね」という結論を補強するだけになってしまわないか。その点が少し気がかりです。

冒頭で紹介したSNSでのやり取り、「AIツールで業務情報を扱うのはポリシー違反では？」という問いに対して、私なりの答えを一言でまとめるなら、「ポリシー違反かどうかは、そのポリシーが何を守ろうとしているか次第」ということになるかと思います。本記事がその問いを考えるうえでの一つの視点になれば幸いです。

脚注

  1. 広木大地, 「『生成AIガイドライン』がナンセンスになる理由」, NewsPicks, 2026年3月5日. https://newspicks.com/news/16174293/body/ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. OpenAI, "How your data is used to improve model performance". https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance ↩︎

  3. Anthropic, "Is my data used for model training?". https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training ↩︎

  4. Microsoft, "Demystifying GitHub Copilot Security Controls". https://techcommunity.microsoft.com/blog/azuredevcommunityblog/demystifying-github-copilot-security-controls-easing-concerns-for-organizational/4468193 ↩︎

  5. Google, "Generative AI and Google Workspace". https://support.google.com/a/answer/15706919 ↩︎

  6. JDLA（日本ディープラーニング協会）, 「生成AIの利用ガイドライン」. https://www.jdla.org/document/ ↩︎

  7. ゆーき, 「Claude Codeの.env漏洩問題：何が起きたのか、なぜ危険なのか、どう防ぐか」, note, 2026年3月6日. https://note.com/yuki_gpts/n/n1382d30c65ce ↩︎

  8. Simon Willison, "The lethal trifecta for AI agents: private data, untrusted content, and external communication", 2025年6月16日. https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ ↩︎

  9. NF0000, 「Claude Codeはプロンプトインジェクションで.envを漏洩させるのか？検証してみた」, Qiita, 2026年3月5日. https://qiita.com/NF0000/items/6743216583b66168ec12 ↩︎

Accenture Japan (有志)
Accenture Japan (有志)

アクセンチュア株式会社に所属する社員有志による運営です。アクセンチュアの社員による様々な発信をまとめています。なお、投稿内容は社員個人の見解であり、所属する組織を代表するものではありません。

Discussion