CodexでOpenAIのAPIキーを安全に作る — OpenAI Developersプラグインの仕組み

結論 — キーはチャットを通らず、暗号化されて手元のファイルに書かれる

先に結論です。OpenAI DevelopersプラグインでAPIキーを作ると、キーの文字列そのものはCodexのチャットにも、Codexが動かすコマンドの出力にも現れません。OpenAI側で発行されたキーは暗号化されて手元のパソコンに届き、復号した結果は指定したファイル（既定は .env.local）にだけ書き込まれます。

1. 1Codexが既存の OPENAI_API_KEY の有無を、値を表示しない方法で確かめ、使い回すか新しく作るかを聞いて止まる
2. 2新しく作る場合、OpenAI Platformの設定画面（ピッカー）が開き、キーの名前と組織・プロジェクトを人が選ぶ
3. 3保存先の確認フォームが出る。既定は作業フォルダの .env.local で、作業フォルダの外は選べない
4. 4手元のパソコンで暗号化用の鍵ペアを作り、公開鍵だけをOpenAIへ送る。OpenAI側でキーを発行し、公開鍵で暗号化した状態で返す
5. 5手元で復号し、確認したファイルにだけ書き込む。画面に出るのは保存先のパスと変数名だけ

なぜ「チャットにAPIキーを貼る」と困るのか

これまでのAPIキーの扱いは、platform.openai.com でキーを発行し、表示された文字列をコピーして、環境変数や .env ファイルに貼るのが普通でした。キーは発行時に一度しか表示されないので、コピーの手順は避けられません。

AIエージェントに開発を任せると、この「貼る」作業もAIに頼みたくなります。ところがチャットにキーを貼ると、その文字列は会話履歴・ログ・モデルへの入力として残ります。会社のワークスペースで履歴を共有していれば、他のメンバーの目にも触れます。

OpenAIの公式ヘルプ「Best Practices for API Key Safety」も、キーをソースコードやリポジトリに置かない・環境変数で渡す・用途ごとにキーを分ける・使わないキーは失効させる、といった原則を挙げています。AIに任せる開発でも、この原則は変わりません。

つまり必要なのは、AIの目に触れずにキーを発行し、正しい場所に置く経路です。OpenAI Developersプラグインは、この経路をCodexに組み込むためのものです。

OpenAI Developersプラグインとは — 4つの部品でできている

OpenAI Developersは、OpenAIが提供する公式プラグインです。プラグイン一覧の「OpenAIプラグイン」のタブに並び、説明文には「OpenAI API・Agents SDK・ChatGPTアプリで開発し、CodexからOpenAIのAPIキーを作成・保存する」とあります。プラグイン全般の位置づけはCodexの標準プラグインを参照してください。

残りのスキルは、API呼び出しが失敗したときの原因切り分け、Agents SDKでのエージェント構築、ChatGPTアプリの雛形作成と申請用ファイルの生成です。キー作成はこのプラグインの入口の役割で、他のスキルより先に動くよう設計されています。

Claude Code・Cursor版との違い

同じ名前のプラグインはClaude CodeとCursorにも配布されていますが、公式ページの説明ではCodex向けが「キーを作成・保存・接続」、Claude Code・Cursor向けは「OPENAI_API_KEYの手動設定をガイドする」と役割が分かれています。暗号化してキーを発行する経路は、OpenAI Platformアプリを持つCodexだけの機能です。

インストール手順

1. 1Codexで /plugins と入力してプラグイン一覧を開く（ChatGPTデスクトップアプリ〔Codex〕なら「プラグイン」のタブ）
2. 2「OpenAI Developers」を検索してインストールする
3. 3案内に従ってOpenAI Platformアプリを接続する（インストール時に認証を求める設計になっています）
4. 4新しいチャットを開いて使い始める

「安全な設定画面」で何が起きているか — 手順を追う

Step 1: 既存キーの確認 — 値を見ないで有無だけ調べる

スキルはまず、環境変数と .env.local などのファイルに使えるキーがあるかを調べます。このときキーの値が画面に出るコマンドは禁止されています。手順書には cat .env* や grep OPENAI_API_KEY .env* を使わず、有無だけが分かる方法で確認せよ、と明記されています。

キーが見つかっても、勝手には使いません。「既存のキーを使い回すか、新しく作るか」を聞いて止まるのがルールで、答えるまでアプリの設計もコードの作成も始めない設計です。見つからなければ「安全に作成しますか」と聞きます。

Step 2: OpenAI Platformの設定画面で、名前と組織・プロジェクトを選ぶ

新規作成を選ぶと、CodexはOpenAI Platformアプリの open_codex_api_key_setup を引数なしで呼びます。手順書は、キーの名前・作業フォルダのパス・保存先などを送ることを禁じています。開いた画面がキー名の入力欄と組織・プロジェクトの候補を表示し、人が選んで確定します。

選んだ結果は、組織・プロジェクトの内部IDとキー名としてCodexに戻ります。これがCodexの返答に出てくる「安全な設定画面」の正体で、どの組織に・どんな名前で発行するかをAIに推測させないための仕組みです。

Step 3: 保存先の確認フォーム — 既定は .env.local

次に、プラグイン同梱のMCPサーバーが保存先を確認するフォームを表示します。文言は「Choose where OpenAI Developers should save the new API key as OPENAI_API_KEY.」で、入力欄には作業フォルダの .env.local があらかじめ入っています。

パスは書き換えられますが、作業フォルダの外は受け付けません（「The env file must be inside the selected workspace.」と拒否されます）。承認しなければ「キーを作成も書き込みもしない」で終わります。gitで追跡中のファイルを選んだ場合は、秘密情報を書いてよいか改めて確認が入ります。

Step 4: 暗号化されたキーを受け取り、手元で復号して書き込む

ここが「安全」の中核です。ヘルパースクリプトの prepare コマンドが、手元のパソコンにRSA-OAEP 4096ビットの鍵ペアを作ります。秘密鍵は権限を絞った一時フォルダに置き、OpenAIへ送るのは公開鍵の3要素（kty・n・e）だけです。

CodexはOpenAI Platformアプリの create_encrypted_openai_api_key に、キー名・組織とプロジェクトのID・公開鍵を渡します。OpenAI側でキーが発行され、公開鍵で暗号化した暗号文だけが返ってきます。暗号文はCodexにも見えますが、復号できるのは手元の秘密鍵だけです。

最後に decrypt コマンドが秘密鍵で復号し、sk- で始まる正しい形式かを検査したうえで、確認済みのファイルに書き込みます。同名の変数があれば更新、なければ末尾に追記し、書き込みは一時ファイル経由で行ってファイルの権限を所有者だけに絞ります。

{
  "target_path": "/Users/you/my-app/.env.local",
  "env_name": "OPENAI_API_KEY",
  "existed": true,
  "updated_existing": false,
  "wrote_plaintext_to_stdout": false
}

書き込み先の安全確認も厳格です。シンボリックリンク・ハードリンク・作業フォルダの外・リンクをたどって外に出る親フォルダはすべて拒否します。これらはプラグインに同梱された自動テストで検証されており、「秘密情報は確認したファイルにだけ書く」という手順書の原則を実装で担保しています。

Step 5: 動作確認

書き込みが終わると、Codexはプロジェクトの起動コマンドやテストを実行して動作を確かめます。ここでもキーの値を表示して確認することはしません。Next.jsなど .env.local を自動で読む仕組みなら、そのままアプリが動きます。

実際の頼み方と、Codexの返答がそっけない理由

頼み方はシンプルです。プラグインが例として挙げている既定の依頼文は「このプロジェクトで使うOpenAI APIキーを作って」（原文: Create an OpenAI API key to use in this project）で、これだけでStep 1から始まります。

もう1つの入口は、キーのことを一言も言わずに「OpenAI APIで◯◯するスクリプトを作って」と頼む場合です。スキルはAPIを呼ぶアプリ・スクリプト・ツールの作成依頼を検知して自動で発火し、「AIを使って」とだけ書いた依頼で他社のAIが指定されていない場合も対象にします。

Codexの返答は意図的に短く設計されています。手順書には「暗号化・復号・RSA・一時ファイルといった仕組みの説明を、エラーで必要にならない限りしない」とあり、利用者には「安全に作成して確認したファイルに書きます」程度しか見えません。本記事はその裏側をまとめたものです。

人の承認が入る場面は3回です。①使い回すか新規か ②設定画面での名前と組織・プロジェクト ③保存先フォーム。どれかで止まっても、それは設計どおりの動きです。

詰まりやすいところ — OpenAI Platform連携の再接続

当社の環境でも、設定画面が開かない・キー作成の段階で止まる、という形で連携が詰まることがありました。原因の見立ては、ChatGPTのログインとOpenAI Platform（API側）のアカウント・組織は別物だという点にあります。

キーの発行は、OpenAI Platformアプリを通じてPlatform側に認証したうえで行われます。この認証が切れている、またはキーを発行したい組織とは別のアカウントで認証していると、設定画面や発行の段階で失敗します。

手順書自体も、接続が無い・認証に失敗したときは「/apps か $ のアプリ選択からOpenAI Platformを接続し直してから再試行」と定めています。デスクトップアプリでの再接続の流れは次のとおりです。

1. 1Codex（ChatGPTデスクトップアプリ）のプラグイン一覧から「OpenAI Developers」を開く
2. 2プラグインの中にある「OpenAI Platform」アプリを接続し直す
3. 3案内に従ってOpenAI Platformへ進み、APIキーを発行したい組織にサインインしているアカウントで認証する（ChatGPTのアカウントと同じとは限りません）
4. 4新しいチャットを開いて、あらためて頼み直す

会社と個人など複数のOpenAI組織を持っている人は、設定画面に表示される組織・プロジェクトが意図したものかを必ず確認してください。キーの請求先は、そのキーが属する組織・プロジェクトになります。

保存先フォームが出ずに止まる場合

保存先の確認フォームが表示されないまま「承認されなかった」と止まる不具合が、2026年7月3日にGitHubの openai/codex リポジトリへ報告されています（Issue #30978）。フォームを表示する仕組みを、当時のデスクトップアプリが自動で拒否していた事例です。

同じ症状が出たら、まずアプリを最新版に更新してから再試行してください。それでも進まない場合は、従来どおり platform.openai.com でキーを発行し、自分の手で .env.local に貼るのが確実です。Codexにキーの文字列を渡さない、という原則はどちらの経路でも同じです。

法人で使うときに押さえること

• キーはプロジェクト単位で作る — 設定画面で組織とプロジェクトを選ぶので、用途ごとのプロジェクトをPlatform側で先に作っておくと、請求と失効の管理が楽になります
• キー名に用途・担当・日付を入れる — キー名はPlatformのダッシュボードで一覧できるため、「誰が何のために作ったか」が名前だけで分かるようにしておきます
• .env.local をgit管理外にしておく — プラグインは追跡中のファイルへの書き込みに確認を挟みますが、.gitignore の設定自体は自分たちで行います
• 使用上限と請求はChatGPTのプランと別 — API課金の考え方と上限の設定はCodexのAPIとはを参照してください
• 誰がキーを作れるかはPlatform側の権限で決まる — プラグインは権限を広げません。組織のメンバー管理と合わせて設計します

扱ってよいデータやツールの線引きは、Codexのセキュリティで整理しています。当社のCodex研修・導入伴走支援では、APIキーの発行・保管・失効までの運用ルールを、開発を任せる範囲の設計とあわせてご支援しています。