【Codex安全7ルール】触る前に絶対知るべきセキュリティ基本

📌 はじめに読んでほしいお知らせ

この記事は、OpenAI公式ドキュメント(developers.openai.com/codex)・OpenAI APIキー安全性ガイド・GitHub公式ドキュメントなどをもとに、2026年5月時点の情報で書いています。

ただしCodexはアップデートがとても多いツールです。私(みやび)が書いた時点では正しくても、数週間後には仕様が変わって、内容が古くなっている可能性があります。実際に手を動かす前に、念のため最新の公式ドキュメントもチラッと確認してくださいね☕

もし『ここ、もう違うよ！』という箇所を見つけたら、Xのみやび(@hello_im_miyabi)にDMでこっそり教えてもらえると、とても嬉しいです。すぐに記事を直して、他の読者の方を助けられます👍

この記事を読むとわかること:

• ✅ Codexに見せていい情報・ダメな情報の線引きがわかる
• ✅ .envファイルやSecret Keyを安全に守る方法がわかる
• ✅ うっかり情報を外に出してしまう『3つの落とし穴』を避けられる
• ✅ X(旧Twitter)で出回る『公式にない情報』を見分けられる
• ✅ 副業でCodexを使うとき、お客さんの大事な情報を守れる

そもそも、なぜCodexに『セキュリティ』の話が必要なの？

Codexは『あなたの代わりに作業してくれるAI』です。とても便利な反面、扱う情報の中には『絶対に外に出してはいけないもの』が混ざります。

例えば、お客さんから預かったログイン情報や、自分が契約している有料サービスの合鍵のような番号。これらが間違って外に出ると、お金や信用に直結する事故になります。

もし守らないと…実際に起きる4つの事故

『どうせ自分は大丈夫』──いちばん危ないのは、この油断です。実際に起きている事故を4つだけ紹介します。脅すためではなく、『そうなる前に防げる』ことを知ってほしいからです。

事故①：知らないうちに数十万円の請求が届く

APIキー(サービスの合鍵)が外に漏れると、世界中のbot(自動巡回プログラム)が数分で見つけて悪用します。1晩で数十万円規模の請求が来た事例も国内外で報告されています。気づくのはたいてい翌朝、メールを開いた瞬間です💭

原因：ルール1・2を守らず、.envや直書きの鍵を公開してしまった。

事故②：お客さんの情報が検索エンジンに残る

うっかりお客さんの名前・メールアドレス入りのファイルを公開リポジトリやWebページに置くと、検索エンジンや外部サービスに保存される可能性があります。後から消しても、キャッシュ(つまり保存済みの古いコピー)にしばらく残ることがあります。

原因：ルール3・5を守らず、.gitignoreに書くべきファイルを書かなかった。

事故③：副業案件を打ち切られる・損害賠償の話に発展

クラウドソーシングや個人受注で、お客さんから預かった情報を漏らすと、案件はその場で終わります。それだけで済めばよいのですが、契約書に『秘密保持』の項目が入っていると、損害賠償の話に進むこともあります。

原因：ルール5(情報の線引き)を曖昧にしたまま、お客さんの本物データをCodexに丸ごと貼り付けた。

事故④：自分のアカウントが乗っ取られる

パスワードやセッション情報(つまりログイン中の通行証)が漏れると、SNS・銀行・サブスクなど横展開で乗っ取られます。クレジットカードを登録しているサービスから順に被害が広がります。

原因：ルール6・7を知らず、漏れた後の対応が遅れて被害が拡大した。

実際に世界で起きている事例(2025〜2026年)

『でも本当にそんなこと起きるの？』と思いますよね。私もそうでした💭 でも残念ながら、ニュースや調査レポートには実例がずらりと並んでいます。代表的なものだけ4つ紹介します。

事例①:1回のコミットで高額請求につながったケース

セキュリティ系ベンダーのブログでは、ある開発者がOpenAIのAPIキーをコード(JavaScriptファイル)に直書きしたまま、GitHubの公開リポジトリ(つまり誰でも見られるファイル保管場所)にコミットしてしまい、短時間で約1,260万円(87,000ドル)規模の利用料が請求された事例が紹介されています。個別事例の詳細は一次情報で確認しにくいため、ここでは『APIキー漏洩は高額請求につながり得る』という教訓として受け取ってください。

事例②：週末の数日間で高額請求につながった報告も

開発者コミュニティ(dev.to等)では、漏洩したAPIキーが大量アクセスに使われ、週末の数日間で約170万円(12,000ドル)規模の請求につながったという報告もあります。月曜の朝にメールを開いて気づいた、というよくあるパターンです。個別金額は環境や料金体系で変わるため、ここでは参考例として受け取ってください。

事例③:2025年に2,865万件の秘密情報がGitHubに漏洩

セキュリティ調査会社GitGuardianの2026年レポートによると、2025年だけで2,865万件もの『秘密情報(APIキー・パスワード等)』がpublic GitHub commits(誰でも見られるGitHubの公開コミット)で検出されました。前年比+34%という、過去最大の単年増加です。

とくに増えたのが『AIサービス関連の鍵』。なんと前年から+81%という急増ぶりで、AIブームに合わせて漏洩も加速しているという結論です。

事例④:回答者の約20%が『AIコード由来の侵害』を経験

2026年のAikido Security社の調査(欧米450名のエンジニアが回答)では、回答者の約20%が『AI生成コードに関連する深刻なインシデント』を経験したと答えています。AI自身も学習元のコードを真似て、うっかりキーを直書きしてしまうことがあるんです。

【ルール1】.envファイルは絶対に外に出さない

まず、いちばん大事なものから。.env（ドットイーエヌブイ）というファイルです。つまり、合鍵や暗証番号をまとめて入れておく『金庫ファイル』のことだと思ってください。

このファイルには、有料サービスのAPIキー(つまりサービスの合鍵)・データベースの暗証番号・お客さんのメール送信用のパスワードなど、外に出たら一発アウトの情報が入ります。

【ルール2】APIキー・Secret Keyをコードに直接書かない

APIキーやSecret Keyは『サービスの合鍵』です。これをコードの中に直接書いてしまうと、その合鍵ごと外に流れていきます。

正しいやり方は、コードには『金庫(.env)から取り出す指示』だけを書くこと。鍵そのものは金庫にしまったままにします。OpenAI公式も、APIキーは環境変数や、本番運用ならシークレット管理サービス(AWS Secrets Manager等)に置くことを推奨しています。

【ルール3】.gitignoreを最初に作る(これが土台)

.gitignore(ギットイグノア)は、つまり『この子たちはお外に連れて行かないでね』という名簿です。ここに.envなどを書いておくと、うっかりコミットを防げます。

正しいフォルダの形はこれ(図で確認)

言葉だけだとピンと来ないですよね。実際のフォルダの中身を、絵で確認しましょう。下の図がCodexプロジェクトの『正しい形』です。

my-codex-project/
├── .env              🔒 金庫(絶対外に出さない)
├── .env.example      ✅ 中身は空。形だけ共有OK
├── .gitignore        📋 名簿(.envをここに書く)
├── README.md         ✅ 公開してOKな説明書
├── package.json      ✅ 必要なお薬リスト
├── src/
│   ├── index.js      ✅ コード本体(鍵は書かない)
│   └── config.js     ✅ .envから鍵を呼び出すだけ
└── node_modules/     📋 .gitignoreで除外推奨

ポイントは2つだけ。.env(本物の金庫)は外に出さない。.env.example(空っぽの見本)だけは外に出してOK。これで『中身は秘密、形だけ共有』という安全な状態が作れます。

【ルール4】『.claudeignore』など公式にないファイルに頼らない

最近X(旧Twitter)で『.claudeignoreを置けばCodexが読まなくなる』という情報が流れています。気持ちはわかります。でも、ちょっと立ち止まってください。

2026年5月現在、Codex公式にはこのファイル名のサポートはありません。つまり『置いても効かないかもしれない』お守りです。お守りに頼って大事な情報を置きっぱなしにすると、結局Codexに読まれてしまう可能性があります。

では、公式の『正しい除外設定』はどう書く？

否定だけで終わると不安ですよね。安心してください。Codexには公式の正しいやり方がちゃんと用意されています。プロジェクトの中に .codex/config.toml という設定ファイルを置いて、こう書くだけです。

# .codex/config.toml
default_permissions = "workspace"

[permissions.workspace.filesystem]
":project_roots" = { "." = "write", "**/*.env" = "none" }
glob_scan_max_depth = 3

意味はシンプル。『このプロジェクトの中は書き換えてOK。でも.env系のファイルだけは絶対に読まないで(none)』という命令です📝 OpenAI公式ドキュメントには、カスタム権限プロファイルとしてこのように.env系ファイルへのアクセスをnoneにする例が掲載されています。Codexのバージョンや実行環境によって設定の効き方は変わる可能性があるため、最新の公式ドキュメントもあわせて確認してくださいね。

さらに公式の安心ポイントを3つだけ。これを知っておくと夜よく眠れます☕

• ✅ ネットワーク通信はデフォルトでオフ。Codex CLI / IDE Extensionのworkspace-writeでは、明示的に[sandbox_workspace_write] network_access = trueを設定しない限り、外部ネットワークへのアクセスは許可されません
• ✅ git管理されたフォルダなら、承認モード『Auto』が推奨。通常、作業フォルダの外を編集したり、ネットワークが必要なコマンドを動かすときは承認が求められます（git管理されていないフォルダは、さらに安全な『read-only』が初期値）
• ✅ 多くの環境で.git / .codex は読み取り専用として保護されます。Codex自身が壊せないよう守られています

【ルール5】Codexに見せていい情報・ダメな情報

Codexはとても賢いですが、見せた情報は『送信される』前提で考えてください。安全な線引きはこの3つだけ覚えれば十分です。

• ✅ OK：自分が書いたコード、公開してもいい説明文、ダミーのテストデータ
• ⚠️ 要注意：自分のメールアドレス、社内資料、お客さんの名前を含む文章
• 🚫 絶対NG：APIキー、Secret Key、パスワード、クレジットカード番号、本物の個人情報

副業でお客さんのお仕事を受けるときは、特に真ん中の『要注意』をどう扱うかでプロかどうかが決まります。迷ったら『載せない・伏せ字にする』を選んでください。

みやびのLINEで一緒に学びませんか

ここまで読んでくれてありがとうございます☕ 続きを読む前に、ひと休みのご案内です。

【ルール6】公開する前に『1分セルフチェック』

『公開する(インターネットに出す)』ボタンを押す前に、必ずこの1分セルフチェックをしてください。慣れれば30秒で終わります。

【ルール7】事故ったときの『3分リカバリ』を覚えておく

どれだけ気をつけていても、人は事故ります。私も過去に1度やりました💭 大事なのは『起きた後の動きが速いこと』です。

副業でCodexを使うあなたへ、ひとこと

副業でAIを使うとき、お客さんが本当に評価してくれるのは『速さ』ではなく『安心して任せられること』です。鍵をしっかり守れる人は、それだけで他のライバルと一段違って見えます。

つまり、今日お伝えした7つのルールは、単なる『お行儀の話』ではなく、あなたの単価を上げる土台にもなります。ここを最初に固めておきましょうね。

今日できること(ひとつだけ)

最後に、今日試してほしいことを1つだけお伝えします。それは『あなたのプロジェクトに.gitignoreがあるか、見に行く』ことです。たった1分で終わります。

もし無ければ、ルール3の代表的な7行を書き写してください。それだけで、今日からあなたのCodex生活は『事故りにくい状態』に変わります。

あわせて読みたい

• おばあちゃんでもわかる『Codexの教科書』｜AIに作業させる始め方
• Codexはじめての設定ガイド｜つまずきポイントを先回りで解説
• Codexプロジェクトに最初に置く8つのファイル