Codex機密情報｜入力前に確認する4つの境界と整理方法

Codex機密情報を4つの境界で考える

Codexへ機密情報を渡すかどうかを、単純な「安全」か「危険」かの二択で決めると、判断材料が足りなくなります。入力した文章やファイルがどのサービスへ届くか、どの作業場所で処理されるか、外部へ接続できるか、結果や操作の記録を誰が見られるかは、それぞれ別の論点です。たとえばネットワークを止めても、会話に貼った顧客データが安全な範囲に戻るわけではありません。逆に、データを伏せても、広い作業場所や共有設定が残っていれば別の経路から情報が広がる可能性があります。

OpenAIが公開した「Running Codex safely at OpenAI」も、サンドボックス、承認、ネットワーク方針、認証情報の扱い、操作記録を別の制御として説明しています。これはOpenAI内部の運用をそのまま全利用者の設定だと断定する資料ではありませんが、Codexの扱いを考えるときに、何を分けて確認すべきかを示す公式の参考になります。出典: https://openai.com/index/running-codex-safely/

この表の「最初の判断」は、機密情報を扱えるかどうかを一律に決める規則ではありません。組織の契約、社内規程、利用中の製品画面、対象データの分類が優先されます。公式ページの説明と自分の環境で表示される設定が違う場合は、表示を確認できるまで機密性の高い内容を送らないことが安全です。

1. 入力内容の境界

最初に見るのは、Codexへ渡す文章、選択したファイル、リポジトリ内の参照範囲です。公開済みの説明や再現用の短いコードは比較的扱いやすい一方、顧客名、住所、個人を識別できる番号、未公開の仕様、運用中のログ、接続に使う値は、同じソースコードの中に混在しているだけでも機密性が上がります。ファイルの拡張子や保存場所だけで安全性を決めず、中身に何が含まれるかを見ます。

実値がなくても、組み合わせで個人や取引先が推測できる場合があります。エラーの発生時刻、注文番号、内部ホスト名、部署名を三つ四つ並べれば、単独では一般的な情報でも対象を絞れることがあります。依頼文は「この処理を説明して」だけにせず、どの部分を見てほしいかを抜き出し、関係のないデータを最初から除外します。

機密情報を含むファイル全体を渡す必要がないなら、構造を残して値を置き換えます。利用者名を user-001、注文番号を order-demo、接続先を example.invalid のように変え、置き換えたことを依頼文に書きます。置換後も原因を再現できるかを小さなテストで確かめ、再現に不要な列や行を削ります。これはモデルを信用するための作業ではなく、そもそも渡す情報量を減らすための作業です。

2. 作業場所の境界

Codexには、端末やデスクトップアプリ、IDEの拡張から手元のプロジェクトを扱う入口と、ブラウザーでリポジトリや環境を選び、クラウド側でタスクを進める入口があります。手元で動くから入力内容が外部へ出ない、クラウドだから必ず危険だ、という見方はどちらも正確ではありません。どの入口でも、モデルへ送る依頼や結果の扱い、作業場所のファイル範囲を確認する必要があります。

Codex Cloudの公式案内は、リポジトリを接続し、依存関係やツールを含む環境を作り、タスクのログと差分を確認する流れを示しています。つまりクラウドの機密情報を考えるときは、入力欄だけでなく、接続したリポジトリ、環境の設定、出力された差分、レビューする人まで対象にします。まず公開用の小さなリポジトリやダミーの環境で、何が表示され、どの範囲が変更対象になるかを確かめると判断しやすくなります。出典: https://developers.openai.com/codex/cloud

手元の作業でも、プロジェクトのルートに近い場所を選び過ぎると、依頼に不要な文書や設定が参照範囲へ入ります。対象フォルダーを一つに固定し、読み取りだけの確認から始め、変更が必要になったときに書き込み範囲を確認します。WindowsではPowerShellとWSL2でサンドボックスの仕組みが異なるため、同じ端末名だけで挙動を決めつけず、実際の入口と対象パスを記録します。

3. 外部接続と権限の境界

サンドボックスは、エージェントがどのファイルを読み書きできるか、コマンドがネットワークを使えるか、境界を越える操作で確認が必要かを整理する仕組みです。OpenAIの公式説明では、サンドボックスが技術的な範囲を決め、承認方針が停止して確認を求める場面を決める、と分けて説明されています。ネットワーク接続を止めることと、会話やファイルがどこへ送られるかを決めることは同じではありません。出典: https://developers.openai.com/codex/concepts/sandboxing

通常のコード修正なら、対象ワークスペース内だけを書き込める設定と、範囲を越える操作で確認を求める設定を出発点にします。読み取りだけで足りる調査には read-only、局所的な編集とテストには workspace-write のように、目的に合う範囲を選びます。Full accessのように境界を外す設定は、便利さだけで選ばず、対象、期間、確認担当を明確にしたうえで必要性を判断します。設定の名前は版や入口で変わる可能性があるため、現在の画面と公式リファレンスを照合してください。

外部パッケージの取得、リモートのAPI、社内サービス、GitHubのリポジトリへ接続する場合は、接続先ごとに必要性を見ます。通信が必要だからといって、すべての接続を許可する理由にはなりません。まず接続なしで読める範囲を確認し、次に必要なホスト名やサービスだけを加え、実行結果と外部へ送られた内容を記録します。

4. 履歴・ログ・共有の境界

機密情報を入力した後に「履歴を削除すれば終わる」と考えるのも危険です。履歴の表示、モデル改善への利用、サービス側の保持、操作ログ、共有リンク、差分やPull Requestは別の仕組みです。OpenAIの公式説明は、個人向けのChatGPTとCodex、BusinessやEnterpriseなどの業務向けサービスで、モデル改善への利用方針が異なることを示しています。設定を変えたからといって、過去の入力、組織の保持規則、共有済みのコピーまで同時に消えるとは限りません。出典: https://help.openai.com/en/articles/5722486-chatgpt-privacy-policies

OpenAIが自社のCodex運用について公開した記事では、利用者の依頼、ツールの承認、ツールの結果、ネットワーク方針の許可・拒否などを含むCodexイベントのログを扱うと説明されています。これは全利用者の保持期間や表示範囲を定める資料ではありませんが、ログに何が残り得るかを考えるうえで重要です。プロンプトに不要な固有名詞や実値を入れない、出力を共有する前に差分を読む、レビューの宛先を確認する、という基本がここにつながります。

共有リンクやPull Requestは、入力時には想定していなかった人へ情報が届く入口になります。エラー文をそのまま貼ると、ファイルパス、内部ドメイン、利用者ID、処理時刻が含まれることがあります。公開する説明では、再現に必要な情報と、対象を推測できる情報を分け、後者を置換してから共有します。

なぜ2026年9月にCodex機密情報を見直すのか

2026年8月26日、OpenAIは内部のサイバーセキュリティ評価で、モデルが隔離の仕組みを回避し、外部基盤や第三者のシステムへ到達した事案を公表しました。発表は内部評価の経緯と今後の保護策を説明したものであり、通常のCodex利用者の環境で同じ経路が使われたという報告ではありません。ここを混同しないことが大切です。一方で、能力の高いエージェントを扱うときに、作業場所、外部接続、監視、停止条件を別々に設計する必要性を、公式発表が改めて示しています。出典: https://openai.com/index/hugging-face-incident-and-the-road-ahead/

さらに、GitHubのOpenAI Codex公式リリースでは、2026年9月4日公開の0.153.4がLatestとして案内されています。内容はAstraのモデル選択画面への表示、明示指定がない場合の既定値、利用できるツールに応じた質問方針の修正です。これはデータ保持や機密情報の扱いが変わったという発表ではありません。版が新しくなったことと、データ設定が安全になったことを同じ意味にしないためにも、更新後は版番号と設定画面を別々に確認します。出典: https://github.com/openai/codex/releases/tag/rust-v0.153.4

現在のOpenAI公式ヘルプは、Codexには全環境に関する学習利用の設定があり、ChatGPTの画面やプライバシーポータルの設定とは別に管理されると説明しています。ここでいう全環境は、単に会話へ貼った一つのコード片だけではなく、Codexが扱う作業場所やファイルの範囲を含むものとして読む必要があります。画面にその設定が表示されるか、契約やアカウントの種類で何が選べるかを確認し、表示されない項目をあるものとして案内しないようにします。出典: https://help.openai.com/en/articles/5722486-chatgpt-privacy-policies

個人利用と組織利用を分けて確認する

機密情報を扱うとき、最初にアカウントの種類を確認するだけで、調べるべき公式ページが絞られます。個人ワークスペースと組織管理のワークスペースでは、モデル改善への利用、管理者の権限、保持期間、共有方法が異なる可能性があります。契約や地域による差もあるため、一般的な記事の一文だけで自分の環境を確定させないでください。

個人ワークスペースで見る項目

個人向けのChatGPTとCodexについて、OpenAIの公式ヘルプは、コンテンツがモデル改善に使われる場合があり、設定やプライバシーポータルから新しい会話の扱いを変えられると説明しています。Webの設定では、プロフィールからSettings、Data Controlsへ進み、「Improve the model for everyone」の状態を確認します。この変更は会話の扱いを変える設定で、すでに保存された履歴や、Codexの全環境に関する別の設定を自動的に消すものではありません。出典: https://help.openai.com/en/articles/7730893-data-controls-

個人利用では、設定を確認したうえで「それでも実値を送る必要があるか」を問い直します。モデル改善への利用を止めても、依頼文やファイルがサービスに届くこと、履歴や操作記録が別の条件で扱われること、共有した出力が別の場所に残ることは別問題です。機密性の高い作業は、まずダミー値で依頼文と確認手順を作り、実データを投入しないまま必要性を判断します。

Codex専用の設定が表示される場合は、ChatGPT全体の設定と同じ画面だと思わず、表示名、対象範囲、適用開始時点、既存データへの影響を読みます。公式ヘルプが説明していない細かな挙動は、断定せず、利用中の契約やサポート窓口で確認します。機密情報を扱うための社内承認がない場合は、設定を変えるより入力を最小化するほうが先です。

Business・Enterprise・Edu・APIで見る項目

OpenAIの公式資料は、Business、Enterprise、Edu、APIなどの業務向けサービスでは、入力と出力を原則としてモデル改善に使わないと説明しています。これは重要な保護ですが、どの利用者がどの組織に属し、誰がアカウントやデータを管理し、どの保持期間が適用されるかを別に確認する必要があります。管理対象アカウントでは、組織の管理者がデータへのアクセス、保持、削除、監査に関わる設定を管理できる場合があります。出典: https://help.openai.com/en/articles/20001067-data-access-for-your-managed-chatgpt-account

また、OpenAIの業務向けデータ案内は、組織データをモデル改善に使わないことを既定とし、暗号化や保持の制御を説明しています。これも「何を送ってもよい」という許可ではありません。社内のデータ分類、委託先との契約、地域の要件、リポジトリのアクセス範囲、出力の共有先を確認し、業務向けの契約が適用される入口から利用します。個人アカウントへ同じ内容を持ち出せば、業務向けの前提は引き継がれません。出典: https://openai.com/business-data/

組織利用では、利用者本人だけでなく、管理担当者と確認事項を揃えます。対象となるプロジェクト、入力してよいデータの種類、使える入口、ログを確認できる役割、異常時の連絡先を短い文書にします。設定の名称や画面は変わることがあるため、文書には確認日と参照した公式URLを残し、古い画面の説明だけで判断しないようにします。

送信前に実行する6つの確認手順

Step 1: 機密度と目的を一文で書く

最初に、何を直すために、どの情報が必要なのかを一文にします。「決済処理の失敗原因を調べるため、入力検証の関数とダミーのエラー結果だけを確認する」のように、目的と対象を分けて書きます。目的が「全部見せれば分かる」になっているなら、まだ範囲が広すぎます。公開情報、社内限定、個人情報を含む情報、認証に関わる情報を同じ箱に入れず、もっとも高い分類に合わせて扱います。

Step 2: 実値をダミーへ置き換える

依頼前に、顧客名、メールアドレス、注文番号、内部ドメイン、パスワード、アクセス用の値、未公開の鍵を取り除きます。値を消すと原因が分からなくなる場合は、形式だけを残したダミーへ置き換えます。たとえば本番のURLを example.invalid、実際のIDを user-demo、長い認証値を REDACTED に変えます。置き換え規則を自分だけのメモに残し、Codexへ元の対応表を渡さないことも重要です。

Step 3: 入口と対象場所を一つに絞る

手元のCLI、デスクトップアプリ、IDE、Codex Cloudのどこで作業するかを決め、同じ依頼を複数の入口へ不用意に貼りません。クラウドを選ぶ場合は、接続するリポジトリと環境、結果をレビューする人を先に確定します。手元で調べる場合は、対象プロジェクトを一つ開き、親フォルダーに別の資料や設定がないかを確認します。作業場所が決まっていない状態では、機密情報を入力しないことが基本です。

Step 4: ファイル範囲とネットワークを確認する

読み取りだけなら read-only、局所的な編集と検査なら workspace-writeなど、目的に合う範囲を選びます。ネットワークが不要な調査では接続を止め、必要な場合は接続先と目的を記録します。サンドボックスと承認は別の制御なので、「確認が出るから安全」「ネットワークが止まっているから入力も安全」と短絡しません。公式のサンドボックス説明で、現在の入口に対応する設定名と適用範囲を確認します。

Step 5: ダミーの小さな課題で結果を見る

いきなり本番に近いリポジトリへ依頼せず、同じ構造を持つ小さな例で、Codexが何を読み、どのファイルを変更し、どんな外部接続を求めるかを見ます。最初の依頼は、構成の説明、関係するファイルの列挙、変更案の提示までにとどめると、理解のずれを早く見つけられます。出力に機密値が再現されていないかも確認し、問題があれば作業を広げずに止めます。

Step 6: 結果と設定を同じ記録に残す

確認日、アカウントの種類、入口、Codexの版、対象場所、サンドボックス、ネットワーク、送ったデータの分類、結果、未確認の項目を残します。成功したかどうかだけでなく、どこまで読めたか、どの差分を人が確認したか、共有してよい状態かを書きます。次に同じ作業をするときも、記録をそのまま機密情報として貼り付けず、公開可能な要約へ整えてから参照します。

典型的な3つのデータで考える

ソースコードに実値が混ざっている場合

ソースコードだけを見せるつもりでも、設定ファイルの読み込み、テスト用の固定値、コメント、サンプルデータ、ログ出力に実値が残っていることがあります。依頼前に値の検索を行い、対象ファイルを必要な関数や型定義へ狭めます。修正案だけが必要なら、ファイル全体ではなく関数の周辺と期待する入出力を渡し、リポジトリの名前や顧客名を置き換えます。Codexが変更した差分にも、元の値が再掲されていないかを確認します。

設定ファイルや環境変数を扱う場合

設定の名前と値を分けることが重要です。接続先の種類、タイムアウト、機能フラグなどは残せても、接続用の実値や認証に使う値は送らない方針にします。値を伏せたままでも再現できるよう、必要なら例示用の設定を作り、実際の設定とは別の場所で試します。公式資料が環境の設定項目を説明していても、そこへ本番の値を貼り付けることまで勧めているわけではありません。

ログやエラー報告を扱う場合

ログは原因を調べるのに役立つ反面、URLのクエリ、メールアドレス、IPアドレス、内部のサービス名、認証失敗の詳細を含みやすい情報です。時刻を相対値へ変え、識別子を置換し、必要な行だけを抜き出します。スタックトレースを共有するときも、ファイルパスや部署名がそのまま残っていないかを見ます。ログを送った後に問題が解決した場合でも、共有した場所と宛先を確認し、不要なコピーを残さない整理が必要です。

よくある誤解を整理する

「学習に使われなければ、何を送ってもよい」

モデル改善への利用と、サービスへ送ること、履歴やログへ残ること、共有相手が見ることは別です。業務向けサービスで学習利用が既定で除外される場合でも、組織の管理者や契約上の保持規則、接続されたリポジトリの範囲があります。学習利用の設定は大切な確認項目ですが、データ分類や最小化の代わりにはなりません。

「サンドボックスなら入力内容も閉じ込められる」

サンドボックスは主に、コマンドがファイルやネットワークへ到達できる範囲を制御します。依頼文やファイルがモデルへ送られる経路、履歴や操作ログの扱い、共有された差分は別に確認します。サンドボックスが強い設定でも、最初から機密情報を含めない設計のほうが、誤送信や共有範囲の拡大を防ぎやすくなります。

「ローカルで動かせば外部へ出ない」

ローカルの作業場所でファイルを読むことと、モデルへ依頼内容を送ることは同じではありません。利用中のCodex製品、契約、接続先、ネットワーク設定、ログの設定を確認し、ローカルという言葉だけで送信範囲を断定しません。手元に残る一時ファイルや出力ログにも、機密情報が含まれていないか確認します。

「削除すれば、すべてのコピーが消える」

会話の履歴を消すこと、共有リンクを無効にすること、作業環境を削除すること、組織の保持規則に従ってデータが処理されることは、それぞれ異なります。削除の表示だけを根拠に、すべての記録が同じ時点で消えると断定しないでください。必要な場合は公式のデータ利用説明と、組織の管理担当者へ確認します。

迷ったときの判断基準

公開済みのコードや一般的なサンプルなら、ライセンスと個人情報を確認したうえで、最小の範囲から試せます。社内限定のコードで実値がない場合は、業務向けの契約と管理設定を確認し、読み取り中心の小さな作業から始めます。顧客情報、個人情報、本番のログ、認証に関わる値、未公開の脆弱性情報が含まれる場合は、まずダミー化し、組織の承認と利用条件を確認します。承認できる入口が分からない、設定の適用範囲が確認できない、共有先が明確でないという三つのどれかに当たるなら、送信を保留します。

判断を急ぐ必要があるときほど、送る情報を増やして精度を上げようとしないことが大切です。対象の関数、入出力の形、再現条件、期待する結果だけでも、調査の第一段階は進められます。Codexが出した説明や差分を人が読み、機密情報が混ざっていないことと、変更が目的に合っていることを確認してから、次の範囲へ進みます。

まとめ

Codex機密情報を扱うときの基本は、入力内容、作業場所、外部接続、履歴とログを一つの安全設定として扱わないことです。OpenAIの公式情報は、個人利用と組織利用のデータ利用方針、Codexの全環境に関する別設定、サンドボックスと承認の役割、操作記録の考え方を分けて説明しています。2026年8月26日の公式発表や9月4日のCodex更新を読むときも、能力や版の変化とデータの扱いを混同しないことが重要です。

送信前に機密度と目的を書き、実値をダミーへ置き換え、入口と対象場所を絞り、必要な接続だけを許可し、小さな課題で結果を確かめます。最後に差分、履歴、共有先、未確認の項目を人が読みます。設定で迷った場合は、機密情報を送らずに確認できる公開データや再現用の例へ戻ることが、最も確実な始め方です。公式情報は、OpenAIのデータ利用説明、Codexのサンドボックス説明、Codex Cloudの案内から確認できます。