生成AIを業務に使う企業が増えるなかで、入力した情報が学習に取り込まれたり、アカウントを乗っ取られたりと、情報漏洩の経路は思いのほか多岐にわたります。実際、ダイレクトクラウドの調査では、生成AIを使わない理由の2位に「セキュリティとプライバシーの懸念」(46.2%)が挙がっています。ただ、経路を正しく把握し、対策に優先順位をつければ、AIを禁止せずに安全に使い続けることは十分に可能です。
本記事では、AIから情報が漏れる4つの経路と実際の事例を示したうえで、サービス設定・社内ルール・仕組みという順に、どこから手をつければよいかを解説します。あわせて、設定やルールだけでは防ぎきれない範囲をDirectCloudでどう統制するかも紹介していますので、自社の対策づくりの参考にしてください。
本記事のサマリ
-
AIの情報漏洩は、入力データの学習利用、社内データとの連携、提供元の不具合、アカウントの窃取という4つの経路で起こり、いずれも実際の事案として公表されている
-
対策はすぐ変えられるサービス設定と社内ルールから始め、効果の早い層から優先順位をつけて進めるのが現実的である
-
設定とルールだけでは、AIに渡すデータの範囲、持ち出しの追跡、承認外の利用に代わる受け皿という3点が残り、データ基盤の側での統制が鍵となる
-
7段階のアクセス権と250種類以上の操作ログ、社内文書を扱える生成AIを備えたDirectCloudなら、AIに渡るデータと持ち出しを一つの環境で統制できる
AIの利用で情報漏洩が起きる4つの経路
従業員による生成AIの利用が広がるほど、企業の機密情報が外部へ漏れるリスクは現実の脅威になりつつあります。生成AIからの情報漏洩は、学習データの管理やシステムの脆弱性、利用者の誤りなど複数の要因が絡み合って生じます。
原因を大づかみに捉えるだけでは、どこから対策すべきか判断できません。情報が漏れる経路を「入力データの残存」「社内データとの連携」「提供元の不具合」「アカウントの窃取」の4つに分け、発生の仕組みと責任の所在を解説します。
入力したデータが学習や履歴として残る
プロンプトに入力した情報は、AIの学習用データや会話履歴として残り、そのまま漏洩につながる場合があります。多くの生成AIサービスでは会話履歴が初期設定で保存され、入力した機密情報が学習に取り込まれて他の利用者への回答に反映された例も報告されました。
悪意がなくても、要約や修正のつもりで顧客名簿や社内文書を貼り付ける行為が漏洩の入り口になります。個人情報保護委員会は、個人情報を含むプロンプトを入力する場合は利用目的の範囲内かを見極め、提供事業者が機械学習に使わないことをたしかめるよう求めています。
参照元:個人情報保護委員会|生成AIサービスの利用に関する注意喚起等について
社内データとの連携範囲が広がる
AIを社内システムやクラウドストレージと連携させると、AIが扱える範囲がそのまま漏洩時の影響範囲になります。社内の文書を探し出して回答に使うRAGという仕組みでは、権限設計を伴わないまま機密情報を格納すると、部門ごとに閲覧権限を分けられず全利用者が読み出せてしまう課題があります。
アクセス権限の設定に不備があれば、想定より広い範囲のファイルがAIの参照対象になりかねません。さらに、外部サイトなどに仕込んだ指示文でAIの動作を乗っ取る間接プロンプトインジェクションという攻撃も存在します。
提供元の不具合や脆弱性で他者に見える
利用者が正しく使っていても、提供元のバグや設定の不備で情報が第三者から見えてしまう場合があります。2023年3月には、ChatGPTでオープンソースの部品のバグが原因で、有料会員の氏名やクレジットカード情報が別の契約者から閲覧できる状態になりました。
2025年7月には、利用者が任意で作った公開リンクが検索エンジン経由で見つかり、会話内容が意図せず表に出た事例も起きています。この経路は現場の設定やルールだけでは防ぎきれないため、提供元の選定とインシデント対応体制の確認が対策の柱になります。
参照元:OpenAI|March 20 ChatGPT outage: Here’s what happened(2023年3月24日)
アカウントが窃取され第三者に使われる
端末が情報を抜き取るマルウェアに感染すると、ブラウザに保存した認証情報が盗まれ、会話履歴ごと第三者に渡ります。この手口では、AIサービスそのものが破られていなくても、盗まれたIDとパスワードだけで漏洩が成立します。
攻撃はサービス提供元ではなく利用者側で起きるため、アカウントの管理と端末の防御を組み合わせることが欠かせません。管理部門が把握していない個人アカウントでの利用は、感染や不正ログインの発見をいっそう難しくします。
実際に起きたAI経由の情報漏洩
AIによる情報漏洩は理屈のうえの心配にとどまらず、すでに具体的な事故として表面化しています。ここでは、原因の異なる3つの事例を実際の記録から取り上げます。
従業員が機密情報を入力して社外に渡った事例、提供元の不具合で他の利用者に情報が見えた事例、そして端末から認証情報が盗まれて闇市場で売買された事例です。いずれも公表された内容にもとづき、何が起きたのか、責任はどこにあったのかを確認します。
機密のソースコードを入力して流出した事例
業務を効率化するつもりの入力が、そのまま社外への流出になった事例があります。2023年3月、海外の大手電子製品メーカーで、技術者がエラー修正やコードの最適化、議事録の要約に生成AIを使う過程で機密情報を入力し、ソースコードや歩留まり関連のプログラム、会議の内容が社外に渡ったと複数のメディアが報じました。
その後、同社は社内ネットワークでの生成AI利用を禁止し、個人の端末で使う際のルールを定めたと伝えられています。悪意がなくても日々の業務改善が漏洩に直結する、典型的なケースです。
参照元:Forbes|Samsung Bans ChatGPT And Other Chatbots For Employees After Sensitive Code Leak
提供元の不具合で他の利用者に表示された事例
先に触れた2023年3月のChatGPTの事例は、オープンソースのライブラリの不具合が原因でした。この不具合で、一部の利用者に他の人の会話履歴のタイトルが表示され、9時間の時間帯には有料会員の約1.2%について、氏名やクレジットカードの一部などの課金情報が別の利用者に見える状態になったと提供元が公表しました。
同社は問題を修正してサービスと履歴を復旧させ、影響を受けた人へ通知しています。使う側がどれだけ気をつけても防げない経路です。
参照元:OpenAI|March 20 ChatGPT outage: Here’s what happened
認証情報が窃取され闇市場で売買された事例
提供元が破られていなくても、端末を経由して認証情報が盗まれ、売買される被害が起きています。シンガポールのセキュリティ企業Group-IBは2023年6月、情報窃取型マルウェアに感染した端末からChatGPTのログイン情報が盗まれ、過去1年で10万件を超える認証情報がダークウェブで取引されていたと発表しました。
これはChatGPT側の侵害ではなく、利用者の端末に入り込んだマルウェアが引き起こしたものです。サービスそのものが安全でも、端末が破られれば漏洩は成立します。
参照元:Group-IB|Group-IB Discovers 100K+ Compromised ChatGPT Accounts on Dark Web Marketplaces
対策は設定・ルール・仕組みの3層で考える
AIの情報漏洩対策は、手のつけやすさと効果の及ぶ範囲が層によって変わります。そこで「すぐに変更できる設定」「社内で定めるルール」「仕組みで担保する統制」の3層に分けて考えると、着手の順番を決めやすくなります。前章までに挙げた経路が、それぞれどの層で抑えられるかを、着手の目安とあわせて下表にまとめました。
| 対策の層 | 主に抑えられる経路 | 着手の目安 |
| すぐに変更できる設定 | 入力・アカウント | 即日〜数日 |
| 社内で定めるルール | 入力・連携・提供元 | 1か月程度 |
| 仕組みで担保する統制 | 連携・アカウント | 四半期単位 |
| すぐに変更できる設定 | |
| 主に抑えられる経路 | |
| 入力・アカウント | |
| 着手の目安 | |
| 即日〜数日 | |
| 社内で定めるルール | |
| 主に抑えられる経路 | |
| 入力・連携・提供元 | |
| 着手の目安 | |
| 1か月程度 | |
| 仕組みで担保する統制 | |
| 主に抑えられる経路 | |
| 連携・アカウント | |
| 着手の目安 | |
| 四半期単位 | |
提供元の不具合に起因する経路は、利用中の設定では抑えられません。そのため、サービスを選ぶ段階での確認事項として、ルールの層で扱います。3つの層を同時に進める必要はなく、設定から着手するほど効果は早く現れます。まず設定とルールの2層を順に見直し、そこで残る範囲を確認したうえで、仕組みで担保する層へ進みます。
すぐに変更できるサービス設定
対策で最初に手をつけるべきは、いま使っているサービスの設定です。多くの設定は管理画面から即日〜数日で変更でき、追加の費用もほとんどかかりません。
ここでは、入力データを学習に使わせない設定、会話履歴を残さない設定、学習されにくい契約形態への切り替え、アカウントと端末の保護という4つの見直しを取り上げます。いずれも情報システム部門が既定値を確認し、全社で統一して適用することが前提です。
入力データの学習利用を停止する
最初の設定は、入力した内容をAIの学習に使わせないオプトアウトです。これを有効にすると、入力した情報がモデルの改善に使われなくなります。
ただし既定値はプランによって異なり、ChatGPT APIや法人向けプランは最初から学習しない状態になっている一方、無料版やChatGPT Plusでは、設定画面で学習をオフにしない限り入力内容が使われてしまいます。
設定を従業員任せにすると抜け漏れが生じるため、情報システム部門が利用中のプランごとに既定値を確認し、全社に周知することが必要です。
履歴を残さない設定に切り替える
会話履歴を保存しない設定に切り替えると、アカウントを乗っ取られたときに読まれる情報を減らせます。履歴が残っていなければ、認証情報を盗んだ第三者がさかのぼって過去のやり取りを見ることを防げるからです。ただし、自分でも過去の会話を後から参照できなくなるため、業務への影響を踏まえた判断が要ります。
なお、履歴を残さない設定にしても、提供元が一定期間データを保持する場合があります。OpenAIは、削除した会話や一時的な会話も最大30日ほど保持してから消去すると公表しています。
参照元:OpenAI|How we’re responding to The New York Times’ data demands
法人向けプランやAPI経由の利用に移す
学習に使われにくい法人向けプランやAPI経由の利用へ移すと、入力データを学習に使わない設定が最初から適用されるため、より確実に漏洩を防げます。法人向けサービスの多くは専用の環境で動き、入力内容を暗号化する仕組みも備わっています。
ただし契約の形態によってデータの扱いは変わるので、全社に広げる前に、利用規約とデータの保持期間を確認しておく必要があります。個別のサービスごとの設定手順は、本記事では扱いません。具体的な手順は関連記事を参照してください。
アカウントと端末の保護設定を見直す
アカウントと端末側の設定を見直し、認証情報が漏れても悪用されにくくします。まず多要素認証(ログイン時に追加の確認を求める仕組み)を設定すれば、IDとパスワードを盗まれても、それだけでは第三者がログインできません。
Group-IBも、二要素認証などの追加の認証を設定するよう勧めています。あわせてブラウザへの認証情報の保存を禁止すると、端末がマルウェアに感染しても盗まれる範囲を狭められます。さらに、部署異動や退職のときに確実に止められるよう、会社が管理するアカウントで使わせることが重要です。
社内ルールとして定めること
国内でも生成AIの業務利用は広がっています。総務省の令和7年版情報通信白書によると、何らかの業務で生成AIを使っていると答えた日本企業は55.2%に達し、半数を超えました。ダイレクトクラウドの調査でも、生成AIの導入時に重視した点として「セキュリティ」が精度・品質と並ぶ76.5%で首位に挙がり、情報漏えいへの懸念が選定を左右しています。
利用が現場に定着してからルールを作ろうとすると、機密情報が入力された後になりかねません。設定の見直しと並行して、社内で守るべきルールを言葉にしておく必要があります。
参照元:総務省|令和7年版 情報通信白書 企業におけるAI利用の現状
参照元:ダイレクトクラウド|生成AI導入率8割超!半数が予算100万円未満 現場の効果と課題
入力してよい情報を機密度で線引きする
「機密情報は入力しない」という言い方だけでは、現場は何が該当するのか判断できません。そこで、入力を禁じる情報を具体的に書き出しておきます。個人情報、顧客情報、未公開の財務情報、設計や開発に関する情報、取引条件といった区分を立て、それぞれ何が当てはまるかを明文化します。
開発中の製品名や取引先との契約金額、社内の人事評価まで具体例を添えると、迷いが減ります。ただし、機密度の分類そのものが自社で未整備であれば、まず分類の枠組みを整えることが先になります。
利用を許可するAIサービスの範囲を決める
業務で使ってよいAIサービスをあらかじめ決めて一覧にし、それ以外を使う場合は申請制にします。一律に禁止すると、従業員が隠れて未承認のツールを使うシャドーAIをかえって招くためです。正規の受け皿を用意したうえで許可する範囲を定めれば、現場は無理に隠れて使わずに済みます。
対象は対話型のAIだけではありません。会議の文字起こしツールやブラウザの拡張機能など、AIが使われていると気づきにくいものも範囲に含めます。
提供元に求めるセキュリティ要件を決める
提供元の不具合や脆弱性に起因する経路は、利用者側の設定では抑えられません。契約前に提供元を確認することでしか防げないため、下表の項目を社内の選定基準として定めます。
新しいAIサービスを許可するときは、必ずこの基準を通す運用にします。
| 確認項目 | 確認する内容 | 確認先 |
| 入力データの学習利用 | 既定で学習に使われるか、契約で除外できるか | 利用規約・データ処理条項 |
| データの保存期間と保存先 | 入力内容と履歴を何日保持するか、どの国で保管するか | 利用規約・セキュリティ説明資料 |
| インシデント時の公表体制 | 障害や漏洩の発生時に原因と影響範囲を公表しているか | 提供元の過去のインシデント報告 |
| 第三者認証の取得状況 | 外部監査にもとづく認証を取得しているか | 提供元のセキュリティ情報ページ |
| 入力データの学習利用 | |
| 確認する内容 | |
| 既定で学習に使われるか、契約で除外できるか | |
| 確認先 | |
| 利用規約・データ処理条項 | |
| データの保存期間と保存先 | |
| 確認する内容 | |
| 入力内容と履歴を何日保持するか、どの国で保管するか | |
| 確認先 | |
| 利用規約・セキュリティ説明資料 | |
| インシデント時の公表体制 | |
| 確認する内容 | |
| 障害や漏洩の発生時に原因と影響範囲を公表しているか | |
| 確認先 | |
| 提供元の過去のインシデント報告 | |
| 第三者認証の取得状況 | |
| 確認する内容 | |
| 外部監査にもとづく認証を取得しているか | |
| 確認先 | |
| 提供元のセキュリティ情報ページ | |
確認できない項目がある提供元は、機密度の高い情報を扱う業務では使わせないという判断もあり得ます。基準を満たすサービスに絞ることで、提供元に起因するリスクを入り口で下げられます。
判断できる状態をつくる従業員教育を行う
教育では、禁止事項を並べるだけでなく、なぜその情報を入力してはいけないのかを仕組みから理解させます。入力した内容が学習に取り込まれ、別の場面で他人への回答に出てくる可能性がある、という仕組みがわかると、ルールが腑に落ちるからです。
IPA(情報処理推進機構)などが示すガイドラインを土台にしつつ、自社の業務に置き換えた事例で研修を組み立てると、現場は自分ごととして受け止めます。教育を支える体制づくりの全体像は本記事では扱わないため、関連記事を参照してください。
設定とルールだけでは防げない範囲
設定とルールを重ねても、それだけでは防ぎきれない範囲が残ります。前の2章で見てきた対策が、どこまでカバーでき、どこが手つかずで残るのかを下表にまとめました。
| 対策手段 | 効力が及ぶ範囲 | 及ばない範囲 |
| 学習利用の停止設定 | モデル改善への入力データの利用 | 履歴の保存、端末側のマルウェア感染 |
| 法人向けプランの契約 | 契約したサービス内のデータ取り扱い | 契約外のサービスでの利用 |
| 社内ルールと従業員教育 | 従業員が認識している行為 | 認識されていない連携設定や共有設定 |
| 提供元のセキュリティ要件の確認 | 契約前に確認できる範囲 | 契約後に生じる不具合や仕様変更 |
| アカウントと端末の保護設定 | 認証情報の窃取と不正ログイン | 正規の利用者による持ち出し |
| 学習利用の停止設定 | |
| 効力が及ぶ範囲 | |
| モデル改善への入力データの利用 | |
| 及ばない範囲 | |
| 履歴の保存、端末側のマルウェア感染 | |
| 法人向けプランの契約 | |
| 効力が及ぶ範囲 | |
| 契約したサービス内のデータ取り扱い | |
| 及ばない範囲 | |
| 契約外のサービスでの利用 | |
| 社内ルールと従業員教育 | |
| 効力が及ぶ範囲 | |
| 従業員が認識している行為 | |
| 及ばない範囲 | |
| 認識されていない連携設定や共有設定 | |
| 提供元のセキュリティ要件の確認 | |
| 効力が及ぶ範囲 | |
| 契約前に確認できる範囲 | |
| 及ばない範囲 | |
| 契約後に生じる不具合や仕様変更 | |
| アカウントと端末の保護設定 | |
| 効力が及ぶ範囲 | |
| 認証情報の窃取と不正ログイン | |
| 及ばない範囲 | |
| 正規の利用者による持ち出し | |
残る範囲には、共通する3つの弱点があります。AIに渡し得るデータそのものを絞れていないこと、持ち出しを後から追跡できないこと、そして承認外の利用に代わる正規の受け皿がないことです。
いずれもAIサービス側の設定だけでは解決できません。データを保管している基盤の側で担保する必要があります。次章では、その担保をどう実現するかを紹介します。
DirectCloudでAIに渡るデータと持ち出しを統制する
ここまでの対策で残った弱点は、AIサービスの設定では埋められません。鍵になるのは、AIに渡るデータそのものを保管している基盤の側で統制するという発想です。
DirectCloudは、クラウドストレージにアクセス制御・操作ログ・生成AIを備え、データを絞る・持ち出しを追う・正規の受け皿を用意するという3方向から、こうしたリスクに対応します。
下表に、前章で残った課題と対応する機能、抑えられる経路をまとめました。
| 課題 | 対応するDirectCloudの機能 | 対応する経路 |
| AIに渡し得るファイルの範囲を絞れていない | 7段階のアクセスレベル、アクセス制御の個別設定 | 連携 |
| 機密ファイルの持ち出しを追跡できない | 250種類以上の操作ログ、監査機能 | 入力・アカウント |
| 承認外のAI利用に代わる受け皿がない | クラウドストレージ統合型の生成AI | 入力 |
| AIに渡し得るファイルの範囲を絞れていない | |
| 対応するDirectCloudの機能 | |
| 7段階のアクセスレベル、アクセス制御の個別設定 | |
| 対応する経路 | |
| 連携 | |
| 機密ファイルの持ち出しを追跡できない | |
| 対応するDirectCloudの機能 | |
| 250種類以上の操作ログ、監査機能 | |
| 対応する経路 | |
| 入力・アカウント | |
| 承認外のAI利用に代わる受け皿がない | |
| 対応するDirectCloudの機能 | |
| クラウドストレージ統合型の生成AI | |
| 対応する経路 | |
| 入力 | |
業務に必要な範囲だけにファイルを開示できる
最初の一手は、業務に必要な範囲だけにファイルを開示する仕組みです。DirectCloudは7段階のアクセスレベルを備え、フォルダ単位・ユーザー単位で、誰がどのファイルを扱えるかを細かく決められます。共有やAIの参照対象になり得る範囲を、必要な人と必要なファイルに絞り込める点が強みです。
さらにデバイス認証やIPアドレス制限を組み合わせると、接続してくる端末や拠点そのものを限定できます。AIに渡り得るデータの範囲を、入り口の段階で狭められるのが要点です。
参照元:DirectCloud|ユーザーID管理で管理作業を効率化
ファイルの持ち出しを操作ログで追える
入力やアカウント経由の持ち出しは、事後に追える状態にしておくことが歯止めになります。DirectCloudは250種類以上の操作ログを記録し、誰がどのファイルをダウンロードし、誰に共有したかを後からたどれます。
監査機能を使えば、退職者や管理者の操作も対象になり、削除されたファイルも残したまま内容を確認できるため、IT監査にも耐えられます。記録が捉えるのはダウンロードや共有であり、AIへの貼り付け自体は残りませんが、その手前の持ち出しを押さえる手がかりになります。
参照元:DirectCloud|DirectCloud 監査
社内文書を外部に出さずAIで活用できる
最後に、社内文書を外部に出さずにAIで活用できる受け皿を用意します。DirectCloud AIは、クラウドストレージに保管したファイルへそのまま質問や要約を行え、社外の無償サービスに社内文書を貼り付ける必要がなくなります。
入力したデータはDirectCloudの管理内にとどまり、他社のモデルに再利用されません。全社員が使える正規の受け皿があれば、承認外のツールに手を伸ばすシャドーAIも減らせます。貼り付けそのものをなくすことが、入力経由の漏洩を根から断ちます。
管理外のファイル共有を正規環境に集約した事例(シャドーAI対策にも通じる)
ここでは、管理外の利用を正規の環境に集約したDirectCloudの導入事例を3つ紹介します。用途ごとに乱立したツールを統一してアクセス権を細かく設定した企業、共有手段を一本化してログで内部統制を強めた企業、容量の制約から無料サービスへ流れていた職員を正規環境に戻した自治体です。
いずれもストレージや共有手段の乱立から生じた事例ですが、こうした管理外の利用を集約する正規環境は、承認外のAI利用に代わる受け皿としても働き、シャドーAIの抑制につながります。
乱立したツールを統一し権限を細かく設定できた事例
株式会社エス・エム・エス様は、用途ごとに複数のクラウドストレージを使い分けていました。そのため「どのサービスを申請すればよいか分からない」という問い合わせが増え、社員が混乱していたといいます。ユーザーごとに細やかなセキュリティ設定を施したいという要望も、以前からの課題でした。
同社はクラウドストレージをDirectCloudに一本化し、問い合わせ対応の工数を大きく減らしています。現在は社内ユーザーと外部ゲストのそれぞれに、細やかなアクセス権を設定できるようになりました。
共有手段を統一しログで内部統制を強化した事例
合同会社EXNOA様は、共有手段を一本化し、ログで内部統制を強めた企業です。導入前は、ファイルの共有方法が統一されておらず、多岐にわたるチャットツールやサードパーティのソフトでやり取りしていたため、情報が散在していました。そのため、後からログを探すのが難しく、追跡できないこともあったといいます。
同社がファイル共有のツールをDirectCloudに統一したところ、ログを正確に追えるようになりました。誰が何を共有したかを把握できる状態が整い、内部統制の強化につながっています。
無料サービスへの依存を解消し管理外の利用を抑えた事例
ひたちなか市役所様は、無料サービスへの依存を解消し、管理外の利用を抑えた自治体です。外部とやり取りするファイルの容量が大きく、メールでは分割して送る手間が生じていました。その不便さから、職員が無料のファイル共有サービスを使ってしまい、内部統制が行き届かない状態になっていたといいます。
DirectCloudの導入後は、容量を気にせずファイルを授受できるようになり、無料サービスに頼る必要がなくなりました。結果として、職員によるシャドーITの抑制につながっています。
漏洩が起きたときに取るべき初動
どれだけ備えても、漏洩の可能性をゼロにはできません。漏洩が疑われたら、まず被害の拡大を止め、ログなどの証跡を保全し、どこまで漏れたのかという影響範囲を特定します。そのうえで、個人データの漏えい等が起きて個人の権利利益を害するおそれが大きい場合、個人情報保護法にもとづき、発覚から3〜5日以内に個人情報保護委員会へ速報を、30日以内(不正な目的による場合は60日以内)に確報を提出し、あわせて本人へ通知する義務があります。誰がいつ何を報告するかをあらかじめ手順にしておくと、初動の遅れを防げます。
まとめ
AIの情報漏洩を防ぐには、対策に優先順位をつけて進めることが欠かせません。従業員のAI利用が広がる今、情報が漏れる経路は複数あり、どの層で対応するかによって防げる範囲が変わるためです。すぐ変えられる設定から着手し、残る範囲をデータ基盤の側で担保することで、AIの利便性を保ちながらリスクを確実に下げられます。優先順位に沿って手を打てば、AIを禁止することなく、安全に使い続ける体制づくりが可能です。
データを保管する基盤の側で統制するなら、DirectCloudが選択肢になります。細かなアクセス制御と操作ログ、社内文書をそのまま扱える生成AIを備え、AIに渡すデータと持ち出しの両方を一つの環境で管理できます。AIの情報漏洩対策の第一歩として、DirectCloudの導入をぜひご検討ください。
- タグ:
- セキュリティ

