Codex に機密情報を渡して大丈夫か｜ログに残るリスクと守り方
2026 年 7 月 1 日公開の Codex 安定版 v0.142.5 は、リクエストのペイロード全体がトレースログへ書き込まれるのを防ぐ修正を入れた。コマンドを実行できるツールだけに、「Codex に会社のコードや API キーを渡して大丈夫か、渡した情報はどこに残るのか」という不安は自然だ。本記事では、機密情報を渡すときのリスクと守り方を公式情報で裏の取れる範囲に絞って整理する（出典: https://github.com/openai/codex ）。
機密情報が漏れるとすれば、その原因はツール本体の悪意よりも「どこに情報が渡り、どこに記録されるのか」を把握していないことに寄りやすい。Codex はモデルに文脈を送って動くため、コードやプロンプトが渡る先とログに残る内容を理解しないまま使うと、不安だけが先に立つ。実際、v0.142.5 ではリクエストのペイロード全体がトレースログへ書き込まれる挙動を抑止する修正が入った。何がどこに残るのかを知ることが、守り方の出発点になる（出典: https://github.com/openai/codex ）。
もう一つ押さえたいのは、Codex が既定で備える安全装置だ。Codex はサンドボックスによって書き込み範囲を作業フォルダに閉じ、ネットワークアクセスを既定で遮断する。加えて承認ポリシーにより、状態を変える操作の前に人の確認を挟める。機密がログに残るような挙動も、v0.142.5 のように見つかれば修正されていく。つまり「勝手に何もかも実行され、外に送られる」という前提は、既定の設計とは異なる（出典: https://developers.openai.com/codex/concepts/sandboxing ）。
だから守り方の軸はシンプルだ。API キーやトークンはコードやプロンプトに直書きせず、環境変数や設定で扱う。そしてサンドボックスと承認ポリシーで「どこまで任せるか」を自分で決める。この二つを押さえれば、機密情報を扱う現場でも過度に恐れる必要はない。「怖いから使わない」ではなく「仕組みを理解して守りながら使う」判断軸を、この記事で持ち帰ってほしい。
何がリスクなのか — 情報はどこへ渡るのか
Codex は、渡された文脈をもとにモデルが応答を組み立てて動くツールだ。ここで言う文脈とは、開いているコード、あなたが書いたプロンプト、Codex が読み込んだファイルの内容などを指す。コードを生成したり修正案を出したりするには、モデルがそれらの情報を受け取る必要がある。つまり「機密情報を渡して大丈夫か」という問いは、突き詰めれば「渡した情報がどこへ行き、どこに残るのか」を把握できているか、という問いに置き換わる。
不安の中心になりやすいのが、ログやトレースに何が残るのかという点だ。この点について、2026 年 7 月 1 日に公開された安定版 v0.142.5 は具体的な一例を示している。リリースノートには、リクエストのペイロード全体がトレースログへ書き込まれるのを防止する、という修正が明記された。裏を返せば、この修正が入るまでは特定の状況でリクエストの中身がトレースログに残り得たということであり、こうした「どこに何が記録されるか」の理解不足こそがリスクの本体だと分かる（出典: https://github.com/openai/codex ）。
ここで大切なのは、リスクの範囲を過大にも過小にも見積もらないことだ。断定できるのは、公開されたリリースノートに書かれた事実の範囲にとどまる。どのログにどんな情報がどこまで残るのかを網羅的に説明することは本記事の目的ではないし、公式情報の裏が取れない挙動を推測で語るのは、かえって判断を誤らせる。押さえるべきは「情報はモデルに渡り、ログにも残り得る。だから何を渡すかを自分で管理する」という一点だ。
Codex が備える安全装置 — サンドボックスと承認ポリシー
Codex には、実行範囲を利用者が決めるための標準的な仕組みが二つある。一つ目がサンドボックスだ。Codex は既定で書き込みできる範囲を作業フォルダの内側に閉じ、ネットワークアクセスを遮断する。これにより、Codex が意図せず作業フォルダの外に変更を加えたり、勝手に外部へ通信したりすることを既定で防いでいる。隔離そのものは OS の仕組みが担い、利用者は「どこまで書き込みを許すか」「ネットワークを開けるか」を選ぶ形になる（出典: https://developers.openai.com/codex/concepts/sandboxing ）。
二つ目が承認ポリシーだ。これは、状態を変える操作を実行する前に人へ確認を求めるかどうかを決める設定で、コマンドの実行やファイルの変更といった踏み込んだ操作の手前にゲートを置ける。サンドボックスが「触れる範囲」を区切るのに対し、承認ポリシーは「実行してよいか」を都度確認する仕組みだと考えると分かりやすい。この二軸を組み合わせることで、読み取りだけに絞る使い方から、確認を挟みつつ任せる使い方まで、機密の度合いに応じて調整できる。
機密情報を扱う現場で意味を持つのは、この境界を自分の手に保てる点だ。codex セキュリティ という観点で見ても、核心は「ツールを恐れるか否か」ではなく「どこまで操作を任せ、どこで確認するか」を設定として決められることにある。そして v0.142.5 のトレースログ修正が示すように、機密がログに残るような挙動も、見つかれば修正されていく。安全装置が用意され、問題が直されていく前提を理解しておくことが、過度な不安を手放す助けになる。
機密情報を渡すときの実務的な守り方
安全装置を理解したうえで、手元でできる具体的な守り方を整理する。まず基本になるのが、API キーやトークンといった秘密情報をコードやプロンプトに直書きしないことだ。認証情報をソースに埋め込めば、それは Codex に渡る文脈にもそのまま乗ってしまう。秘密は環境変数や設定で扱い、コードからは参照だけを行う形にしておけば、モデルに渡る内容から秘密そのものを切り離せる。これはセキュリティの一般原則でもあり、Codex を使うかどうかに関わらず守っておきたい前提だ。
次に、機微なリポジトリを扱うときは、サンドボックスと承認ポリシーの設定を意識して絞る。codex セキュリティ 設定 として調整できるのは、書き込み範囲を作業フォルダに限る既定を維持すること、ネットワークを必要なときだけ開けること、そして状態を変える操作には承認を挟む設定にすることだ。これらの設定は Codex の設定ファイルで管理でき、書き込み範囲を決めるキー（sandbox_mode）や、承認の求め方を決めるキー（approval_policy）が用意されている。設定ファイルの具体的な書き方は「Codex の設定ファイル config.toml の書き方と推奨設定」(/codex-config/)で詳しく解説しているので、そちらを参照してほしい（出典: https://developers.openai.com/codex/config-basic ）。
三つ目は、そもそも不要な情報を文脈に含めないことだ。機密を含むファイルを作業フォルダに置いたまま Codex に広い範囲を読ませれば、渡す必要のなかった情報まで文脈に乗る。作業に必要なファイルだけを対象にし、秘密を含むファイルは分離しておく。「渡さなくてよいものは渡さない」という運用は、どんな安全装置よりも確実に情報の露出を減らす。設定で守りを固めることと、渡す情報そのものを絞ることは、両輪として効く。
それでも心配なときは
ここまでは「機密情報をどう扱うか」に絞って整理してきたが、その一段手前に「そもそも Codex というツール自体が安全なのか、ウイルスではないのか」という不安がある人もいるはずだ。この問いには、Codex がオープンソースで中身を検証できること、危険があるとすれば本体より入手経路であること、といった別の観点からの整理が必要になる。これらは「Codex はウイルス?安全性と本物の入手・安全な使い方」(/is-codex-safe/)で扱っているので、ツールそのものの安全性が気になる場合はそちらを読んでほしい。本記事は、あくまで「機密情報を渡すときの扱いと守り方」に主題を絞っている。
まとめ
Codex は既定で書き込みを作業フォルダに閉じ、ネットワークを遮断し、状態を変える操作には承認を挟める。今回の安定版 v0.142.5 が入れたトレースログ書き込み抑止の修正のように、機密がログに残るような挙動も見つかれば直されていく（出典: https://github.com/openai/codex ）。だから「Codex に機密情報を渡して大丈夫か」という不安は、「どこに情報が渡り、どこに残るのかを理解し、任せる範囲を自分で決められているか」という運用の問いに置き換えられる。秘密はコードやプロンプトに直書きせず設定で管理し、サンドボックスと承認ポリシーで境界を自分の手に保つ。この二つを押さえれば、機密情報を扱う現場でも、Codex を守りながら使っていける。
