ChatGPT 情報漏洩 対策を技術責任者視点で完全解説【2026年版】

ChatGPT 情報漏洩 対策を設計する前に：リスク構造をデータフロー単位で把握する

ChatGPT の情報漏洩対策を語る議論の多くが、「機密情報を貼り付けてはいけない」という運用論に収束する。しかし技術責任者として対策アーキテクチャを設計するには、まずデータがどこを流れ、どの地点でどのようなリスクが生じるかを構造的に把握しなければならない。感覚論ではなく、仕組みに基づいた対策だけが実効性を持つ。

ChatGPT にテキストを送信すると、データは HTTPS 経由で OpenAI のサーバーに到達し、モデルの推論処理が行われる。問題はその後の扱いだ。総務省「LLMとセキュリティ」資料は、外部LLMサービス利用時の主なリスクとして、（1）入力データのサーバー側保存・学習への利用、（2）プロンプトインジェクションによる意図しない情報開示、（3）モデルのコンテキスト窓を通じた間接的な情報混入、という三層の脅威を整理している（出典：総務省「LLMとセキュリティ」https://www.soumu.go.jp/main_content/000948624.pdf）。

この三層のうち、利用者側が技術的に直接制御できるのは「入力の内容」と「プラン選択による学習オプトアウト」のみだ。OpenAI サーバー側で発生するインシデントは原則として利用者が防ぐことができない。2023年3月には ChatGPT のバグにより、一部ユーザーの決済情報（氏名・メールアドレス・クレジットカード末4桁・有効期限）が他ユーザーに表示されるインシデントが発生し、OpenAI が公式に認めている。また同年、Samsung Electronics の社員がソースコードや会議議事録を ChatGPT に入力し社外流出につながったとされる事例、および約10万件の ChatGPT アカウント認証情報がダークウェブ上で流通していたという報告も存在する。これらは「利用者の不注意」だけでなく、プラットフォーム側のバグや第三者攻撃に起因するリスクが並存することを示す。

弊社が開発するバーチャルヒューマン／AIアバターソリューション DeepAI の設計においても、どの処理をクラウドに出すか・社内閉域に留めるかの境界設計が情報セキュリティの根幹であると実感している。LLM を活用するシステムでも同じ問いが設計の出発点となる。深層学習モデルがどのようにデータを内部表現するかを理解することは、どの情報を外部モデルに渡すべきでないかの判断軸になる。詳しくは深層学習（ディープラーニング）の仕組みと実装を参照されたい。

プラン別の ChatGPT 情報漏洩リスク比較：2026年6月時点の現行仕様

対策設計において最も影響の大きい変数はプラン選択だ。以下に現行プラン（2026年6月時点、OpenAI 公式情報に基づく）のセキュリティ観点での差異を整理する。

プラン	学習オプトアウト	SSO／管理コンソール	監査ログ	DPA締結	法人利用の適合性
Free	手動設定が必要	なし	なし	なし	非推奨
Go	手動設定が必要	なし	なし	なし	非推奨
Plus	手動設定が必要	なし	なし	なし	非推奨
Business（旧Team相当）	デフォルトOFF（学習除外）	SSO対応	限定的	一部対応	最低ライン
Enterprise	デフォルトOFF（学習除外）	SSO／SCIM対応	詳細ログあり	締結可	推奨

出典：OpenAI公式サイト（https://chatgpt.com/pricing/、https://openai.com/business/chatgpt-pricing/）2026年6月時点。価格・仕様は変動する場合がある。

Free・Go・Plus は個人アカウント扱いであり、組織としての管理コンソールを持てない。デフォルトでは会話データがモデル改善に利用される設定であり、オプトアウトするには各ユーザーが「Settings → Data controls → Improve the model for everyone」をオフにする操作を個別に実行しなければならない。この設定を組織全体で強制する手段がないことが、Free・Go・Plus での法人利用における最大の構造的リスクとなる。

Business・Enterprise では、OpenAI がデータを学習に利用しないことがデフォルトの契約条件となる。Enterprise ではさらにデータ処理契約（DPA）の締結が可能であり、GDPR・個人情報保護法対応の観点でも質的な差異が生じる。現行モデルである GPT-5.5 系・GPT-5.4 系（OpenAI 公式：https://openai.com/index/introducing-gpt-5-5/）を Business・Enterprise プランで使う場合も、プランの契約条件はモデル世代に依存せず同様に適用される。

ChatGPT 情報漏洩 対策：技術実装レベルで実行すべき7つの施策

デジタル庁「ChatGPT 等の生成AIの業務利用に関する申合せ（第2.1版）」（2025年3月）は、生成AI利用時の基本方針として「機密情報・個人情報・未公開情報の入力を避ける」ことを明示している（出典：digital.go.jp）。しかし運用ルールだけでは人的ミスを防ぎきれない。以下に、技術責任者が実装・検討すべき対策を実務的に整理する。

1. プロンプト・レイヤーへの DLP（データ損失防止）実装

ChatGPT をブラウザ経由で利用する環境であれば、企業ネットワーク層またはエンドポイントに DLP ソリューションを配置し、個人番号・クレジットカード番号・社員 ID・メールアドレスといったパターンを正規表現でフィルタリングする設計が有効だ。API 経由であればアプリケーション層での入力サニタイズを実装できる。ただし DLP には明確な限界がある。自然言語で迂回的に機密情報を伝える「意味的漏洩」には正規表現ベースの検知は対応しにくい。DLP はあくまで多層防御の一要素として位置づける必要がある。

2. Business または Enterprise プランへの移行

法人利用において、学習オプトアウトがデフォルトで有効な Business プラン（月額 $25/ユーザー、年払い $20）以上を選択することが技術的最低ラインだ。Enterprise では SCIM によるユーザープロビジョニング自動化、SSO 強制、詳細な監査ログの取得が可能になり、インシデント発生時の事後追跡を現実的なものにする。Free・Go・Plus での業務利用は、組織管理の観点から設計上の欠陥を内包すると認識すべきだ。

3. 会話履歴保存ポリシーの一元制御

Enterprise・Business の管理コンソールでは、会話履歴の保存ポリシーを組織単位で設定できる。プロジェクト横断での機密情報混入を防ぐ観点から、デフォルトでの履歴保存を無効化し、業務上必要なケースのみ例外設定する運用が実務上効果的だ。ユーザー個人の設定変更に依存する構成は、ヒューマンエラーを組み込む設計と同義であることを認識しておきたい。

4. OpenAI API 経由の社内ポータル構築によるアクセス制御の内製化

ChatGPT の Web UI ではなく OpenAI API を通じてモデルにアクセスする構成では、入出力のログ管理・フィルタリング・ユーザーごとのアクセス制御をすべてアプリケーション層で実装できる。OpenAI API 利用規約において、API 経由のデータはデフォルトでモデルのトレーニングに利用されない旨が定められている。セキュリティ要件が高い組織では、API ラッパーとして社内ポータルを構築し、UI から直接 ChatGPT.com にアクセスさせない構成が標準的な選択となる。この設計はテキストマイニングによる利用ログの自動分析とも相性がよく、テキストマイニング解説で紹介している手法を監査ログ解析に応用できる。

5. MFA 強制とパスワードマネージャー運用

約10万件のアカウント認証情報がダークウェブ上に流通した事象の主因は、情報窃取マルウェア（インフォスティーラー）によるブラウザ保存パスワードの盗取とみられる。MFA を強制し、パスワードを使い回さない運用を徹底することで、認証情報を起点とした不正アクセスリスクを実質的に低減できる。Enterprise では SSO と MFA の強制を管理コンソールから設定可能だ。特権アカウント（管理者）については、FIDO2 ハードウェアキー等の強力な認証手段の採用を検討すべきだ。

6. 入力禁止情報の分類マトリクスを社内ガイドラインに明示

総務省「LLMとセキュリティ」資料は、外部LLMへの入力を禁止すべき情報カテゴリとして、個人情報・機密情報・未公開の研究成果・顧客データ等を例示している（出典：https://www.soumu.go.jp/main_content/000948624.pdf）。これを自社のデータ分類（機密レベル定義）と対応させ、「どの分類の情報をどのプランで利用可とするか」の具体的なマトリクスに落とし込むことが重要だ。「機密情報は入力禁止」という抽象的な記述は現場の判断基準にならない。マトリクスには、社内資料・顧客情報・個人情報・公開情報の区分を縦軸に、利用プラン（Free/Business/Enterprise/API）を横軸に置き、各セルに許可・条件付許可・禁止を明記する形式が実務的に機能しやすい。

7. プロンプトインジェクション対策の設計

RAG（Retrieval-Augmented Generation）構成や社内文書を参照させるシステムを構築する場合、外部から取り込んだ悪意あるテキストがモデルへの指示として機能するプロンプトインジェクション攻撃への対策が不可欠だ。具体的には、入力値のエスケープ・システムプロンプトとユーザー入力の明確な分離・出力のサニタイズ・信頼境界の明示的な設計を実装する。BERTをはじめとするトランスフォーマー系モデルがどのようにテキストを内部表現するかを理解することは、この設計の勘所を掴む上で役立つ。BERTとは何か：NLPガイドも参照されたい。

弊社が開発するバーチャルヒューマン／AIアバターソリューション DeepAI は、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現する技術を核としており、対話AIなど複数のコンポーネントを組み合わせている。その設計においても「どのデータを外部に出さないか」という境界設計が情報セキュリティの根幹となる。LLM ベースのシステムでも同じ問いが対策設計の出発点となる。機械学習全般のアーキテクチャ設計については機械学習の基礎と実装に詳しい。

法人向け ChatGPT 情報漏洩 対策：ガバナンス体制として整備すべき3つの柱

技術的対策は必要条件であって十分条件ではない。デジタル庁・総務省の両ガイドラインはいずれも、技術的措置と組織的措置の両輪が不可欠であることを明示している。以下に、ガバナンス体制として最低限整備すべき要素を示す。

インシデント対応フローの事前整備と法的報告義務の把握

ChatGPT 関連の情報漏洩インシデントが発生した際、誰がどの順番で何を確認し、どの経路でエスカレーションするかを事前に定義していない組織では、発覚から初動対応まで数日を要するケースが現実に生じている。特に個人情報を含む漏洩の場合、個人情報保護法に基づく個人情報保護委員会への速報義務（原則として事態を知った日から72時間以内）が課される場合があり、初動の遅延は法的リスクに直結する。対応フローは、OpenAI からのインシデント通知を受け取る担当者・セキュリティ責任者・法務・広報・経営層への連絡ルートを明確化した上で文書化しておく必要がある。

利用部門への権限委譲と中央統制のバランス設計

Enterprise の管理コンソールでは、組織単位でのモデル利用可否・外部ツール連携の制御が可能だ。しかし全機能を一律に禁止する「過剰制限」は生産性を著しく損ない、シャドーIT（業務外の個人アカウントでの利用）の温床となる。機密レベルに応じた利用許可ポリシーをあらかじめ設計し、現場の判断余地を適切に残すことが重要だ。「禁止」と「許可」の二値ではなく、「条件付き許可」の領域を設けることが実務上の運用安定に寄与する。

監査ログの定期レビューと異常検知の運用

Enterprise の監査ログは、誰がいつどのモデルを使用したかのアクセス記録を提供する。これを定期的にレビューし、想定外の利用パターン（異常に大量のデータ送信、権限外ユーザーによるアクセス、特定時間帯への集中など）を検知する運用を組み込む。監査ログの保管期間は法令要件・社内方針に従い設定する。テキストマイニング技術を活用した自動監査についてはテキストマイニング解説が参考になる。また、強化学習の知見を応用した異常検知の設計については強化学習の仕組みと実装も参照されたい。

ガバナンス体制の骨格として、デジタル庁「ChatGPT 等の生成AIの業務利用に関する申合せ（第2.1版）」（2025年3月、出典：digital.go.jp）を一読することを強く推奨する。同文書は入力禁止情報の分類・アウトプットの検証義務・著作権・誤情報リスクへの対処方針を網羅しており、社内ガイドライン策定の出発点として活用できる。総務省「ChatGPT等の生成AIの業務利用に関する申合せ」（出典：soumu.go.jp）も合わせて参照することで、省庁横断の基本方針を把握できる。

ChatGPT 情報漏洩 対策の限界：残存リスクを正確に認識した上で意思決定する

いかなる対策を講じてもゼロリスクは存在しない。この点を明示せず「完璧な対策」として施策を列挙することは、エンジニアリングとして誠実ではない。技術責任者は残存リスクを正確に経営層に伝え、リスク受容の意思決定を促す役割を担う。

第一に、OpenAI のサーバー側で発生するインシデント（2023年3月の決済情報バグのような事象）は、利用者側の対策では防ぎようがない。プラットフォームの信頼性評価として、OpenAI の SOC 2 Type II 認証の取得状況やセキュリティ開示情報を継続的にモニタリングする姿勢が求められる。

第二に、モデルが学習データから特定の情報を「記憶」して出力するメモリゼーション問題は、学習オプトアウトとは独立したリスクだ。すでに学習済みのモデルが何らかの形で機密性の高い情報を再現する可能性は理論的にはゼロではない。これは利用者側で直接制御できない領域であり、機密度の高いデータは原則として外部LLMに入力しないという設計原則を保持することが現時点での最も確実な方針となる。

第三に、マルチモーダルAIの進化により、ChatGPT は画像・音声・ドキュメントを処理する機能を拡充している。これは利便性の向上と同時に、意図せず画像内の機密情報（名刺・ホワイトボード・設計図面など）が送信されるリスクを意味する。利用ガイドラインには、テキスト入力だけでなく添付ファイル・画像のリスクを明記する必要がある。マルチモーダルAIの技術的背景についてはマルチモーダルAI解説を参照されたい。また、画像内の機密情報を合成データで代替するアプローチとして、GAN を用いたデータ生成技術も検討に値する。GAN（敵対的生成ネットワーク）解説が技術的背景の理解に役立つ。

第四に、Enterprise プランであっても、管理者アカウントがフィッシングにより奪取されたり、内部関係者が意図的に設定を変更したりするリスクは残る。特権アカウントの管理は他の SaaS と同様に厳格に扱うべきであり、最小権限の原則と定期的な権限棚卸を徹底する。

技術的対策・組織的対策・プラン選択の三層を組み合わせたリスク管理アーキテクチャを構築し、残存リスクを経営層に正確に伝えた上でリスク受容の意思決定を行うことが、技術責任者としての本来の役割だ。スパースモデリングのような解釈可能性の高いアプローチとの組み合わせも、AIシステム設計の選択肢として参照されたい（スパースモデリング解説）。AI 活用と情報セキュリティは相反するものではなく、設計の精度次第で両立できる。

---

弊社が開発する DeepAI は、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン／AIアバターソリューションだ。リップシンク・表情生成・音声合成・対話AIなどを組み合わせ、接客・研修・面接練習・広報等への活用を想定した社内閉域環境での処理を基本設計としており、外部LLMへのデータ送信を前提としないアーキテクチャを採用している。AI導入においてセキュリティ要件を重視する技術責任者は、まずクリスタルメソッド技術ブログからご覧いただきたい。

---

参考文献

• デジタル庁「ChatGPT 等の生成AIの業務利用に関する申合せ（第2.1版）」（2025年3月）
  https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/debd5eca-6832-406e-a530-4e98ec032133/c60c5872/20250325_meeting_executive_agreement_07.pdf
• 総務省「ChatGPT 等の生成AIの業務利用に関する申合せ」
  https://www.soumu.go.jp/main_content/000879561.pdf
• 総務省「LLMとセキュリティ」
  https://www.soumu.go.jp/main_content/000948624.pdf
• OpenAI 公式料金ページ（2026年6月時点）
  https://chatgpt.com/pricing/
• OpenAI Business ChatGPT Pricing
  https://openai.com/business/chatgpt-pricing/
• OpenAI「Introducing GPT-5.5」
  https://openai.com/index/introducing-gpt-5-5/
• OpenAI Help Center「Model release notes」
  https://help.openai.com/en/articles/9624314-model-release-notes

関連記事

• ChatGPT とは 使い方
• ChatGPT 料金プラン 比較
• ChatGPT Claude Gemini 比較
• chatgpt 解約方法
• chatgpt gpts
• chatgpt sora
• chatgpt canvas