Codexに入れた情報って、外に漏れないんですか。
この問いは、これから生成AIを仕事に入れる人ほど、一度ちゃんと考えた方がいいです。
僕自身、AIを使って記事を書いたり、HPを更新したり、コードを直したりしています。
便利です。
めちゃくちゃ便利です。
でも、便利だからこそ怖い。
なぜなら、AIに渡す情報は、ただの雑談ではないことが多いからです。
お客様の名前。
見積もり。
社内の議事録。
未公開のサービス内容。
ソースコード。
APIキー。
契約書の下書き。
問い合わせ内容。
こういうものを、何も考えずにAIへ貼り付けると、流出リスクは確実に上がります。
ここで大事なのは、「AIは危ないから使わない」と決めることではありません。
どこから漏れる可能性があるのか。
何を入れてよくて、何を入れてはいけないのか。
生成されたものを、公開前にどう確認するのか。
ここを決めてから使うことです。
生成AIの情報事故は、SFみたいな話ではありません。
2023年には、OpenAIがChatGPTの不具合により、一部ユーザーのチャット履歴タイトルや支払い関連情報が他ユーザーに見える可能性があったと公表しました。Samsungでは、社員がChatGPTに機密情報を入力したことをきっかけに、社内利用制限が報じられました。2025年には、共有設定されたChatGPT会話が検索エンジンに表示される問題も報じられています。
つまり、リスクは「モデルが勝手に秘密をしゃべる」だけではありません。
人が貼る。
人が共有する。
人がgitに入れる。
人が公開物に混ぜる。
だいたい、こっちです。
今日は、CodexやChatGPTのような生成AIに情報を入れるとき、どこから情報が漏れるのかを整理します。
中小企業やひとり社長が、生成AIを怖がりすぎず、でも雑に扱わないための実務メモです。
まず分けたいのは、AIサービス側のリスクと自分側の運用リスク
生成AIの情報漏洩を考えるとき、最初に分けた方がいいものがあります。
AIサービス側のリスク。
自分側の運用リスク。
この2つです。
AIサービス側のリスクとは、入力した情報がサービス提供者側でどのように保存されるか、学習に使われるか、管理者に閲覧される可能性があるか、障害や不具合で露出しないか、という話です。
たとえばOpenAIの場合、ChatGPTの個人向け利用、TeamやEnterprise、APIでは、データの扱いが同じではありません。
OpenAIは、ChatGPT Team、Enterprise、Edu、API Platformについて、ビジネスデータをモデル学習に使わないと説明しています。一方で、個人向けChatGPTでは、設定やデータコントロールによって学習利用を管理する必要があります。
ここは必ず公式情報を確認するべきです。
プラン、設定、利用規約、管理者設定、保持期間。
このあたりは変わります。
今日の正解が、半年後も同じとは限りません。
一方で、自分側の運用リスクはもっと身近です。
社員が顧客情報をそのまま貼る。
議事録に個人名や未公開情報が入ったまま要約させる。
APIキーを含む .env をCodexに読ませる。
AIが生成した文章に、お客様名や社内事情が残ったままブログに出す。
修正したコードに秘密情報が混ざり、gitへコミットする。
共有リンクを作って、そのまま外部に送る。
このあたりは、サービス側の規約以前に、日々の使い方で起きます。
そして現実の事故は、こっちの方が起きやすいです。
「どのAIなら絶対安全か」だけを探しても、答えは出ません。
安全に使うには、サービス選定と同時に、社内の入力ルール、出力確認、公開前チェック、権限管理を作る必要があります。
AIを使うこと自体が危険なのではなく、情報の通り道を見ないまま使うことが危険です。
モデル学習だけを見ていると、保持・閲覧・共有のリスクを見落とす
生成AIの情報漏洩でよく聞かれるのが、これです。
「入力した内容は、モデルの学習に使われますか」
もちろん大事です。
でも、ここだけ見ていると足りません。
たとえ学習に使われなくても、情報が一定期間保存されることはあります。
不正利用監視やセキュリティ目的でログが残ることもあります。
組織アカウントなら、管理者が利用状況を管理できることもあります。
ファイルアップロード、コネクタ、外部サービス連携を使えば、AIに渡る情報の範囲も広がります。
つまり、確認すべき問いは「学習に使われるか」だけではありません。
少なくとも、次のように分けて見た方がいいです。
1つ目は、学習利用です。
入力や出力が、将来のモデル改善に使われるか。
設定でオフにできるか。
ビジネス向けプランではどう扱われるか。
2つ目は、保存期間です。
会話履歴、アップロードファイル、ログ、監査データがどれくらい残るか。
削除したとき、本当にどこまで削除されるのか。
3つ目は、閲覧可能性です。
サービス提供者、社内管理者、プロジェクトメンバー、連携先ツールの誰が見られるのか。
4つ目は、共有範囲です。
共有リンクを作ったとき、リンクを知っている人だけが見られるのか。
検索エンジンに拾われる可能性はないのか。
社外に転送してもよい内容なのか。
2025年には、共有されたChatGPT会話が検索エンジンに表示される問題が報じられました。OpenAIは、その機能を削除したと報じられています。
この話の怖さは、「AIが勝手に漏らした」というより、「便利な共有機能を、公開範囲の理解が曖昧なまま使うと漏れる」という点です。
Codexのような開発支援ツールでも同じです。
作業対象のリポジトリ。
読み込ませたファイル。
貼り付けたエラーログ。
連携したGitHubやGoogle Drive。
ブラウザ操作で開いた管理画面。
便利な連携ほど、渡す情報の範囲が広がります。
だから、導入時には「AIに何をさせるか」と同じくらい、「AIがどこまで見える状態で使うか」を決めた方がいいです。
gitへのコミットは、AI利用時にかなり現実的な漏洩経路になる
Codexを使うと、コード修正が速くなります。
エラーを読ませる。
原因を探す。
ファイルを編集する。
テストを走らせる。
コミットメッセージを作る。
ここまで一気に進められるのは、とても便利です。
でも、開発支援AIで気をつけたいのが、gitへの混入です。
たとえば、こんなものです。
APIキー。
アクセストークン。
.env。
本番DBの接続文字列。
顧客データ入りのCSV。
ログファイル。
個人情報を含むテストデータ。
管理画面のスクリーンショット。
AIに作業させていると、原因調査のためにログや設定ファイルを広めに見たくなります。
その流れで、秘密情報が作業ディレクトリに残る。
修正確認のための一時ファイルを作る。
そのまま git add . してしまう。
これ、かなり現実的です。
しかも、公開リポジトリにpushした秘密情報は、削除しても安心とは言えません。
gitの履歴に残ります。
外部にクローンされている可能性もあります。
GitHubにはsecret scanningやpush protectionがありますが、それでも「検知してくれるから大丈夫」ではありません。
検知されない形式の秘密情報もあります。
自社独自の認証情報、顧客データ、社内資料名、未公開の事業計画は、一般的なsecret scanningでは拾えないことも多いです。
Codexを使うなら、最低限この運用にした方がいいです。
git status を見る。
差分をファイル単位で見る。
.env、ログ、CSV、スクリーンショット、PDF、バックアップファイルをコミット対象から外す。
秘密情報が入った可能性があるときは、コミット前に止める。
公開リポジトリへpushする前に、AIではなく人が差分を見る。
AIにコミットまで任せるとしても、最後の公開判断は人が持つ。
ここは譲らない方がいいです。
AIの作業速度が上がるほど、事故も速くなります。
生成物に混ざって外へ出るリスクは、文章・画像・資料・コード全部にある
情報漏洩は、入力時だけではありません。
出力時にも起きます。
AIに渡した情報が、生成物の中に残ることがあります。
たとえばブログ記事。
下書きの中に、お客様との会話内容が具体的に残る。
匿名化したつもりでも、業種、地域、時期、金額、課題を組み合わせると相手が分かる。
「あるクライアント」と書いていても、本人が読めば分かる。
これも情報漏洩です。
提案資料でも起きます。
他社向けに作った資料をもとにAIで流用すると、前の会社名、課題、価格、担当者名が残ることがあります。
メール返信でも起きます。
問い合わせ内容をAIに貼って返信案を作り、別のお客様へ送るときに、前のお客様の情報が残る。
画像生成でも起きます。
社内資料のスクリーンショットや顧客情報入りの画面を素材として使えば、その情報が画像やプロンプトに含まれます。
コードでも起きます。
AIが生成したサンプルコードに、実在するURL、トークン、管理画面パス、社内だけの設定値が入ったまま残る。
「AIが作ったものだから大丈夫」ではありません。
むしろ、AIが作ったものほど、人が確認しないと危ないです。
公開前チェックでは、文章の良し悪しだけでなく、情報の混入を見る必要があります。
名前は残っていないか。
メールアドレスはないか。
電話番号はないか。
住所、学校名、会社名、担当者名はないか。
金額や契約条件が特定されないか。
社内の事情が分かりすぎないか。
画像の中に画面キャプチャや個人情報がないか。
コードに秘密情報がないか。
ここを見ます。
AI活用のルールは、入力禁止リストだけでは足りません。
出力確認リストも必要です。
事故例から見ると、原因はだいたい「便利さにルールが追いついていない」
生成AIの情報事故は、すでにいくつも起きています。
代表的なものを、実務上の教訓として整理します。
1つ目は、OpenAI自身が公表した2023年3月のChatGPT障害です。
不具合により、一部ユーザーに他ユーザーのチャット履歴タイトルが見える可能性があり、さらにChatGPT Plus利用者の一部で、氏名、メールアドレス、支払い住所、クレジットカード番号の下4桁などが見える可能性があったと説明されています。
教訓は、クラウドサービスである以上、サービス側の障害リスクはゼロではないということです。
だからこそ、最初から「万一見えても致命傷にならない情報の渡し方」を考える必要があります。
2つ目は、Samsungの事例です。
2023年に、社員がChatGPTへ機密情報を入力したことが報じられ、その後、社内で生成AI利用を制限したとされています。
教訓は、社員が悪意なく、便利だから貼ってしまうということです。
コードを直したい。
議事録を要約したい。
エラーを説明してほしい。
その場では仕事を進めたいだけです。
でも、貼ったものが機密なら事故になります。
3つ目は、共有リンクや公開範囲の問題です。
2025年に、共有されたChatGPT会話が検索エンジンに表示される問題が報じられました。
教訓は、「リンクを知っている人だけ」のつもりが、実際にはもっと広い公開状態になることがあるということです。
Notion、Google Drive、GitHub、ChatGPTの共有リンク。
どれも便利です。
でも、共有リンクは実質公開に近いことがあります。
4つ目は、git上の秘密情報漏洩です。
これは生成AIに限った話ではありませんが、AIで開発速度が上がるほど重要になります。
GitHubはsecret scanningやpush protectionを提供していますが、秘密情報がリポジトリに混ざる問題がなくなったわけではありません。
AIが編集したファイルをそのままコミットすると、不要なログ、一時ファイル、設定値まで入ることがあります。
これらに共通しているのは、技術そのものより運用です。
便利な道具が先に来て、ルールが後から追いかけている。
この状態が危ないんです。
小さな会社ほど、禁止ではなく「入れていい情報」を決めた方が続く
では、どうすればいいのか。
大企業のような分厚いAI利用規程を作る必要はありません。
小さな会社やひとり社長なら、まずは1枚のルールで十分です。
ポイントは、「禁止」だけにしないことです。
全部禁止にすると、誰も使わなくなります。
逆に、何でもOKにすると事故が起きます。
だから、入れていい情報、加工すれば入れていい情報、入れてはいけない情報を分けます。
入れていい情報は、公開済みの情報です。
自社サイトに載っている文章。
公開済みのサービス説明。
一般的な業務手順。
個人や顧客を特定しない架空例。
すでに外に出してよいと判断済みの資料。
加工すれば入れていい情報は、匿名化や要約をした情報です。
お客様名を「A社」に変える。
担当者名を消す。
メールアドレスや電話番号を消す。
金額を幅で表現する。
地域や業種をぼかす。
社内固有のIDやURLを削る。
入れてはいけない情報は、事故になりやすいものです。
個人情報。
顧客情報。
契約書の未公開部分。
見積もりや価格交渉の詳細。
APIキー、パスワード、アクセストークン。
本番DBの接続情報。
未公開の事業計画。
クライアントから預かった資料。
守秘義務のある情報。
Codexを使う場合は、さらに開発用のルールを足します。
.env は読ませない。
本番データをローカル作業に置かない。
ログを共有するときはトークンやメールアドレスをマスクする。
コミット前に差分を見る。
公開リポジトリへpushする前にsecret scanningだけでなく人の確認を入れる。
AIが作ったファイルでも、公開判断は人が持つ。
これだけでも、かなり変わります。
ルールは細かすぎると使われません。
でも、ゼロだと事故ります。
最初はA4一枚でいいので、「これはOK」「これは加工」「これは禁止」を決める。
AI内製化は、こういう地味な運用設計から始まります。
万一入れてしまったときは、削除より先に影響範囲を確認する
どれだけ気をつけても、ミスは起きます。
だから、入れてしまった後の動きも決めておいた方がいいです。
まず、何を入れたのかを確認します。
個人情報なのか。
顧客情報なのか。
秘密情報なのか。
APIキーなのか。
公開前資料なのか。
次に、どこへ入れたのかを確認します。
ChatGPTの個人アカウントか。
TeamやEnterpriseか。
APIか。
Codexの作業環境か。
GitHubか。
Google DriveやNotionのコネクタ経由か。
共有リンクを作ったのか。
その次に、外へ出た可能性を見ます。
共有したか。
公開リポジトリへpushしたか。
ブログや資料として公開したか。
メールやチャットで送ったか。
検索エンジンに拾われる場所に置いたか。
APIキーやパスワードなら、削除より先に無効化・再発行です。
公開リポジトリに入れたなら、履歴削除だけでなく、キーのローテーション、関係者への連絡、アクセスログ確認が必要です。
個人情報や顧客情報なら、社内ルールや契約、法令に沿って報告判断が必要になります。
ここでやってはいけないのは、焦って履歴だけ消して「なかったこと」にすることです。
消すことは大事です。
でも、影響範囲を見ないと再発防止になりません。
AIに入れてしまった。
gitに入れてしまった。
公開物に混ぜてしまった。
この3つは、対応が少しずつ違います。
だから、事故対応メモも事前に作っておくと安心です。
誰に連絡するか。
どのキーを止めるか。
どの公開ページを下げるか。
どのログを見るか。
どこに記録を残すか。
この順番があるだけで、かなり落ち着いて対応できます。
生成AIは、怖がるより「情報の入口と出口」を決めて使う
CodexやChatGPTに入れた情報が流出するリスクは、あります。
ゼロではありません。
でも、それは「AIを使うな」という意味ではありません。
メールにも誤送信があります。
Google Driveにも共有ミスがあります。
GitHubにも秘密情報のpushがあります。
人が道具を使う以上、情報事故のリスクは必ずあります。
大事なのは、リスクの場所を見えるようにすることです。
モデル学習に使われるか。
どれくらい保存されるか。
誰が見られるか。
共有リンクはどこまで公開されるか。
gitに秘密情報が混ざらないか。
生成物に顧客情報が残っていないか。
公開前に誰が確認するか。
入れてしまったとき、どう動くか。
このあたりを決めておけば、生成AIはかなり使いやすくなります。
逆に、ここを決めないまま「便利だから」で進めると、いつか怖くなって止まります。
それはもったいないです。
小さな会社ほど、AIを使えると仕事は軽くなります。
文章の下書き。
問い合わせ対応の整理。
提案資料の構成。
社内マニュアル。
コード修正。
ブログ更新。
こういう日々の作業を助けてくれます。
だからこそ、最初に情報の入口と出口を決める。
何を入れていいか。
何を入れてはいけないか。
何を公開前に見るか。
ここまで含めてAI活用です。
カタチ舎の AI内製化パートナー でも、ツールの使い方だけでなく、業務棚卸し、入力情報の整理、公開前チェック、社内で続けられる運用づくりまで一緒に設計しています。
AIを使うこと自体を目的にしない。
事故を怖がって止まることも目的にしない。
安心して使い続けられる形にする。
そのために、まずは「この情報、AIに入れていいんだっけ？」と立ち止まれる仕組みを作っておく。
僕はそこから始めるのが、いちばん現実的だと思っています。
参考情報
- OpenAI Data Controls FAQ
- OpenAI Enterprise privacy
- OpenAI March 20 ChatGPT outage explanation
- OpenAI Platform: Data controls
- GitHub Docs: About secret scanning
- GitHub Docs: Push protection
- BBC: Samsung workers accidentally leak confidential data via ChatGPT
- Fast Company: Google is indexing ChatGPT conversations
Author
村上龍平
カタチ舎代表。言葉、生成AI活用、資料・Web制作を行き来しながら、事業の考えを届く形へ整理しています。