Codex APIとは？APIキーでの使い方・料金・自動化の方法を解説

「Codex APIという言葉を見かけたが、何のことか分からない」「APIキーでCodexを使うと、ChatGPTのプランで使う場合と何が違うのか」「CIや社内のツールからCodexを動かしたい」と調べている方は多いのではないでしょうか。

先に整理しておくと、OpenAIの公式ドキュメントの一覧には、「Codex API」という名前の独立した製品やページは見当たりません（2026年10月時点で確認）。この言葉は、実際にはAPIキーでCodexにサインインして使うこと、プログラムの中からCodexを動かすこと、OpenAIのAPIでモデルを直接呼び出すことのどれかを指して使われています。どれを指しているかで、必要なものも費用のかかり方も変わります。

この記事では、この3つの意味を切り分けたうえで、APIキーでの使い方、モデルと料金、codex exec・SDK・GitHub Actionでの自動化、OpenAIのAPIを直接使う場合の違い、キーの管理までを順に解説します。内容は2026年10月時点の公式情報をもとにしています。料金やモデルは変わることがあるので、契約や導入の前には公式ページもあわせて確認してください。

Codex APIとは

CodexはOpenAIが提供するプログラミング用のAIエージェントで、デスクトップアプリ・ターミナル（文字で命令を打つ画面）のCLI・VS CodeなどのIDE拡張・Web版などから使えます。そのCodexに対して「API」という言葉が付くとき、多くは次の3つのどれかです。

1と2は、Codexという「道具」を使う話です。ファイルを読み、コマンドを実行し、作業を進めるところまでをCodexが担当します。3は、Codexを使わず、AIモデルそのものを部品として呼び出す話です。検索で「codex api」と調べている方の多くは、1か2を知りたいのだと思われます。

目的別の早見表

何をしたいかから、使う方法を選べるようにまとめました。

APIキーでCodexを使う

ここでは、1つ目の意味である「APIキーでCodexにサインインして使う」方法を説明します。ChatGPTでサインインする場合との違いを先に押さえておくと、あとの話が分かりやすくなります。

サインインの方式は3種類

公式の認証のページには、Codexのサインイン方式が3つ載っています。

アクセストークンは、ChatGPTのBusinessまたはEnterpriseのワークスペースで、管理者が許可した場合だけ使える仕組みです。公式の説明では、トークンを作った人のワークスペース上の立場で動くため、秘密の情報として扱い、信頼できる実行環境だけで使うよう案内されています。一般的なOpenAIのAPIの呼び出しには、これまでどおりAPIキーを使います。

APIキーで使えないもの

APIキーでサインインしても、ローカルでの作業（自分のパソコンのフォルダに対する作業）は、ふつうに使えます。一方、ChatGPTのワークスペースやクラウドのサービスと結びついた機能は、制限されたり使えなかったりします。公式の料金ページと認証のページの内容を整理しました。

公式の認証のページには、このほかに2つの注意があります。1つは、CLIとデスクトップアプリでは、OAuth（外部サービスへの許可の仕組み）でつなぐ一部のプラグインが、APIキーでは使えないことです。もう1つは、ワークスペースの設定でパソコンの操作を許可する機能（Local computer access with Work Cloud）が、APIキーでは有効にならないことです。「APIキーに切り替えたら、いつも使っていた連携が出てこない」という場合は、この違いが原因です。

管理者の設定とデータの扱い

どちらでサインインするかで、適用される管理者の設定も変わります。

会社でChatGPTのBusinessなどを契約している場合、ふだんの利用はワークスペースの管理下にあります。そこに「個人が自分のAPIキーでCodexを使う」ケースが混ざると、費用もデータの扱いも管理の外に出てしまいます。誰がどちらを使うかを、先に決めておきましょう。

APIキーでサインインする手順

APIキーは、OpenAIのAPIの管理画面（OpenAI Platform）で作成します。作成したあとの手順は、使う道具によって異なります。

1. APIキーを作るOpenAIの管理画面でAPIキーを作成し、安全な場所に保管します。キーは他人に見せないように保管し、リポジトリには入れません。
2. CLIの場合キーを環境変数に入れておき、printenv OPENAI_API_KEY | codex login --with-api-keyのように、キーをcodex loginに渡します。公式の例はmacOS・Linuxのものです。
3. デスクトップアプリの場合サインアウトした画面で「Sign in another way」を選び、キーを入力して「Continue」を選びます。
4. IDE拡張の場合サインアウトした画面で「Use API Key」を選び、キーを入力して「OK」を選びます。
5. サインインの状態を確かめるCLIならcodex login statusで、いま使っている認証方式を確認できます。

Windowsで、キーを標準入力に渡す具体的な書き方（PowerShellの場合）は、公式には案内がありません。Windowsで試す場合は、デスクトップアプリやIDE拡張の画面からキーを入力する方法が分かりやすいでしょう。

サインイン状態の確認と切り替え

CLIでの確認と切り替えに使うコマンドは次のとおりです。

なお、ログインの情報はCLIとIDE拡張で共有されます。どちらか一方でサインアウトすると、もう一方でも、次に起動したときに、もう一度サインインが必要になります。

キーの保存場所を選ぶ

サインインしたキーやトークンは、config.tomlのcli_auth_credentials_storeで、保存先を選べます。

プランとAPIキーを併用する

公式の料金ページには、使用量の上限に達したあとも、APIキーを使えば、追加のローカルの作業を標準のAPI料金で続けられると書かれています。「ふだんはPlusの使用量で使い、上限に達した日だけAPIキーに切り替える」という使い方です。

切り替えている間は、前の表のとおり、クラウドの機能やGitHubの連携は使えません。切り替えが必要になる前に、キーと費用の上限を準備しておくと、慌てずに済みます。上限に達したときの対応には、ほかにもクレジットを買い足す方法があります。どちらが安いかは、使うモデルや作業によって変わります。

会社の方針でサインイン方式を固定する

管理者が、使うサインイン方式を決めておくこともできます。config.tomlにforced_login_method = "chatgpt"または"api"と書くと、方式を固定できます。いまのサインイン情報が設定と合っていない場合、Codexはサインアウトして終了します。ワークスペースを特定のものに限定するforced_chatgpt_workspace_idという設定もあります。

モデルと費用

APIキーで使うと、使った分が従量課金で請求されます。月額のプランと違い、使いすぎれば請求も増えるため、モデルの選び方と上限の設定をあわせて決めておくことが大切です。

モデルを指定する

APIキーでサインインしたときに使えるモデルは、APIの組織とプロジェクトで利用できるモデルに従います。公式のモデルのページには、APIキー向けの全モデルの一覧はなく、OpenAIのAPIのモデル一覧を見るよう案内されています。モデルを選ぶ方法は次の3つです。

公式は、アカウントとクライアントが対応している場合は、gpt-6.1-solを推奨しています。決まった作業を繰り返す場合はgpt-6-lunaが案内されています。ただし、モデル名は「その名前を書けば使える」というものではありません。自分のAPIの組織で使えるかどうかは、管理画面か、モデルの一覧で確認してください。

APIの料金

OpenAIのAPI料金のページに載っている、おもなモデルの標準の料金は次のとおりです（100万トークンあたり。入力が27.2万トークン以下の場合）。

入力が27.2万トークンを超える長いコンテキストでは、単価が別になります。大きなリポジトリの全体を一度に読ませると、この長いコンテキストの料金になりやすくなります。

金額の感覚をつかむために、10万トークンを読ませて、1万トークンを書かせる作業を1回行った場合を計算してみます。

実際のCodexは、ファイルを何度も読み直しながら進めるため、入力のトークンは想像より多くなりがちです。キャッシュが効くと入力の費用は下がりますが、上の表はあくまで計算の例として見てください。公式の料金ページでも、APIのトークン料金は、ChatGPTのプランで何回使えるかを見積もる材料にはしないよう注意されています。

Codex向けの名前が付いたモデルの扱い

以前は「gpt-5.3-codex」のように、名前にcodexが付いたモデルがCodex向けに案内されていました。いまのAPIの廃止予定の一覧では、これらのモデルに廃止の日付と、推奨される置き換え先が載っています。

古い記事やサンプルのコードには、これらのモデル名が書かれていることがあります。設定ファイルやスクリプトの--modelに残っていないか、確認しておきましょう。なお、OpenAIのコード生成のガイドでは、Codexで使うモデルとして、そのときの最新の汎用モデル（例：gpt-6.1-sol）を勧めています。

GPT-5.5については、ChatGPTでサインインして使う場合は2026年10月14日に提供が終わりましたが、APIキーでのCodexの利用には影響しないと公式のモデルのページに書かれています。

費用の上限を決める

従量課金で一番心配なのは、自動実行が止まらずに費用がふくらむことです。OpenAIのAPIでは、組織とプロジェクトの単位で、月ごとの上限を設定できます。

上限に達すると、APIはorganization_spend_limit_exceededまたはproject_spend_limit_exceededというコードを含むエラーを返します。前払いの残高がなくなった場合はcredit_balance_exhaustedになります。上限の反映は瞬時ではないので、記録された金額が上限をわずかに超えることがあります。

費用を抑える工夫

APIでは、読ませるトークンの量と、出力させるトークンの量が、そのまま費用になります。費用を抑える工夫として、次のような方法があります。

codex execで自動化する

codex execは、Codexを人の操作なしで最後まで動かすコマンドです。スクリプト・定期ジョブ・CIから呼び出す用途に向いています。2つ目の意味である「プログラムからCodexを動かす」ときの、一番手軽な入口です。

基本の使い方

依頼の文章を引数として渡します。

codex exec "リポジトリの構成を要約して、リスクの高い箇所を5つ挙げて"

途中の経過はstderr（エラー出力）に流れ、最後の回答だけがstdout（標準出力）に出ます。そのため、結果をファイルに保存したり、ほかのコマンドに渡したりしやすくなっています。

codex exec "直近10件のコミットからリリースノートを作って" | tee release-notes.md

ほかのコマンドの出力を渡して、「これを整形して」と頼むこともできます。パイプで渡した内容は追加の情報として扱われ、指示は引数の文章です。

npm test 2>&1 | codex exec "失敗したテストを要約して、最小の修正案を示して" | tee test-summary.md

標準入力の内容をまるごと指示にしたい場合は、codex exec -と書きます（引数を省略しても同じです）。

cat prompt.txt | codex exec -

出力を機械で扱う

別のプログラムで結果を処理したいときは、次のオプションを使います。

--jsonを付けると、thread.started・turn.completed・turn.failed・item.*・errorといった種類のイベントが流れます。公式の例では、--output-schemaと-oを組み合わせて、プロジェクトの情報を決まった形のJSONファイルとして取り出しています。

codex exec "プロジェクトの情報を抽出して" \
  --output-schema ./schema.json \
  -o ./project-metadata.json

書き換えを許す範囲を決める

codex execは、初期設定では読み取り専用のサンドボックスで動きます。ファイルを書き換えさせたいときは、許可を明示する必要があります。

以前あった--full-autoは、いまは使えません。--sandbox workspace-writeに置き換えるか、承認の確認を自動のレビューに回す--approve-for-meを使うよう、公式に案内されています。読み取り専用で、確認も一切求めない形にしたいCIでは、--sandbox read-onlyと--ask-for-approval neverを組み合わせます。

ネットワークの利用は初期設定でオフです。外部のサービスに接続させたい場合は、config.tomlの[sandbox_workspace_write]にnetwork_access = trueと書く方法があります。許可する範囲は、必要なものだけに絞ってください。

APIキーを渡す

codex execは、初期設定では、CLIに保存されたサインイン情報を再利用します。APIキーを渡して実行したい場合は、環境変数CODEX_API_KEYを、そのコマンドの実行にだけ付けます。

CODEX_API_KEY=<APIキー> codex exec --json "未対応のバグ報告を整理して"

公式の環境変数のページでは、CODEX_API_KEYはcodex exec・codex review・TypeScript SDK・codex exec-server --remoteで使えると書かれています。

自動実行で結果をそろえるための設定

人のパソコンで動かすときと、CIで動かすときで、結果が変わってしまうことがあります。個人の設定ファイルや、ルールのファイルの影響を受けるためです。公式のドキュメントには、そのための指定がいくつかあります。

また、無人で動かす場合は、安全のための監視によって、作業が途中で止められることがあると公式に書かれています。CLIでは、そのまま終了して、再開できない場合もあるため、自動実行の側で、途中終了を前提にした処理（失敗の通知や再実行）を用意しておくと安心です。.gitや.codexなどの保護されたフォルダは、書き込みを許可した範囲の中でも、読み取り専用のままです。

自動実行の使い方の例

公式のドキュメントには、ほかのコマンドの出力をcodex execに渡す例が、いくつも載っています。業務に置き換えやすいものを選んで紹介します。

いずれも、読み取り専用の初期設定のまま使える処理です。まずは、こうした「読んで、まとめるだけ」の処理から始めると、安全に効果を確かめられます。

前回の続きから動かす・Gitの条件

1回目の作業の続きを、あとから頼むこともできます。

codex exec "変更に競合状態がないか確認して"
codex exec resume --last "見つかった競合状態を直して"

--lastは、いまのフォルダで最後に動かしたセッションを選ぶ指定です。特定のセッションを指定する場合は、codex exec resume <SESSION_ID>と書きます。

また、Codexは、意図しない破壊的な変更を避けるため、Gitのリポジトリの中で実行されることを前提にしています。Gitの管理外のフォルダで動かすと止まります。安全な環境だと確信できる場合に限り、--skip-git-repo-checkで確認を省略できます。

SDKとGitHub Actionで組み込む

コマンドを呼び出すだけでは足りず、自社のアプリや、GitHubの流れの中にCodexを組み込みたい場合は、SDKかGitHub Actionを使います。

Codex SDK

Codex SDKは、Codexをプログラムの中から操作するためのライブラリです。公式のページには、CI/CDのパイプライン、自作のエージェント、社内ツール、自社のアプリへの組み込みといった用途が挙げられています。

TypeScriptでの最小の形は、次のようになります。

import { Codex } from "@openai/codex-sdk";

const codex = new Codex();
const thread = codex.startThread();
const result = await thread.run("このリポジトリのテストの実行方法を調べて、手順にまとめて");
console.log(result.finalResponse);

Pythonでは、モデルや書き込みの範囲を、スレッドを作るときに指定できます。

from openai_codex import Codex, Sandbox

with Codex() as codex:
    thread = codex.thread_start(
        model="gpt-6.1-sol",
        sandbox=Sandbox.workspace_write,
    )
    result = thread.run("テストの失敗の原因を調べて")
    print(result.final_response)

サンドボックスの指定は、Sandbox.read_only・Sandbox.workspace_write・Sandbox.full_accessから選べます。指定しない場合は、app serverに設定されている初期値が使われます。サンプルのモデル名は、自分のアカウントで使えるものに置き換えるか、modelを省略して初期値を使ってください。

app serverとの使い分け

公式によると、Python SDKは、ローカルで動くCodex app serverをJSON-RPCで操作する仕組みです。認証・会話の履歴・承認・進行状況の配信まで、自分で作り込みたい場合は、app serverを直接使うことが案内されています。一方、決まった処理をCIなどで動かしたいだけなら、SDKかcodex execで足ります。

app serverの仕組みと注意点は、別の記事で詳しく解説しています。

GitHub Action

GitHub Actionは、GitHubの自動実行の仕組み（ワークフロー）の中でCodexを動かすための、OpenAI公式のアクション（openai/codex-action@v1）です。Codex CLIを入れ、APIキーが渡されるとResponses APIのプロキシを起動し、指定した権限でcodex execを実行します。最小のワークフローは次のとおりです。

name: Codex
on: workflow_dispatch
jobs:
  codex:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
        with:
          persist-credentials: false
      - uses: openai/codex-action@v1
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          prompt: リポジトリの構成を要約して

APIキーは、GitHubのシークレットにOPENAI_API_KEYとして登録し、ワークフローから参照します。実行環境はLinuxかmacOSです。Windowsのランナーでは、safety-strategy: unsafeが必要になります。指示は、prompt（直接書く）かprompt-file（リポジトリ内のファイル）のどちらか一方で渡します。両方を指定するとエラーになります。

最後のメッセージは、final-messageという出力に入ります。次のジョブに渡して、プルリクエストへのコメントとして投稿する、といった使い方ができます。

失敗したCIの修正案を作る流れの例

公式のドキュメントには、CIが失敗したときに、修正案をプルリクエストとして出す流れの例が載っています。ポイントは、Codexを動かすジョブと、PRを作るジョブを分けていることです。

1. 失敗を検知するメインのCIのワークフローが失敗したら、続きのワークフローが起動します。
2. 修正案を作る失敗したコミットを、読み取り権限だけでチェックアウトし、セットアップのあとにCodexを実行します。このジョブにだけAPIキーを渡します。
3. 差分を保存するCodexが作った変更を、パッチのファイルとして保存します。
4. PRを作る別のジョブが、書き込み権限でパッチを適用し、プルリクエストを開きます。このジョブにはAPIキーを渡しません。

こうすると、Codexが動くジョブは書き込みの権限を持たず、書き込みの権限を持つジョブは、キーを持ちません。1つのジョブに、強い権限をすべて持たせない設計です。

GitHub Actionで気をつけること

公式のドキュメントには、安全に使うためのチェックリストがあります。

OpenAIのAPIを直接使う場合

3つ目の意味である「OpenAIのAPIでモデルを直接呼び出す」方法も、整理しておきます。Codexを使う場合と、何が違うのでしょうか。

Responses APIの最小の例

OpenAIのAPIのクイックスタートでは、APIキーを環境変数OPENAI_API_KEYに設定し、Responses APIでモデルに質問する例が紹介されています。Pythonでの最小の形は次のとおりです。

pip install openai

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-6-astra",
    input="この関数の問題点を3つ挙げて：...",
)

print(response.output_text)

JavaScript（Node.js）やcurlでも、同じ形で呼び出せます。OpenAIのコード生成のガイドでは、APIでのコード生成は、まずgpt-6-astraから始めるよう案内されています。

APIを使い始めるまでの準備

OpenAIのAPIのクイックスタートに沿った、準備の流れです。

1. APIキーを作るOpenAIの管理画面でAPIキーを作成し、安全な場所に保管します。
2. 環境変数に設定するmacOS・Linuxではexport OPENAI_API_KEY="キー"、Windows（PowerShell）ではsetx OPENAI_API_KEY "キー"と入力します。OpenAIの各言語のライブラリは、この環境変数を自動で読み取ります。
3. ライブラリを入れるPythonならpip install openai、JavaScript（Node.js）ならnpm install openaiです。
4. 最小のコードを動かす前の節で示した形で、モデルに入力を送り、返ってきた文章を表示します。

Codexで使うAPIキーと、ここで作るAPIキーは、同じOpenAIのAPIのキーです。管理画面の同じプロジェクトで作れば、費用の上限も共通になります。用途ごとにプロジェクトを分けるかどうかは、先に決めておきましょう。

CodexとAPIの直接利用の違い

自社のサービスの画面に、AIの回答を表示したいといった用途は、後者のAPIの直接利用です。一方、社内のリポジトリのコードを直したり、調べたりしたいのであれば、Codexを使うのが近道です。なお、Codexの接続先は、公式のモデルのページと設定のページで、Responses APIと互換性のあるものが必要だと案内されています（wire_api = "chat"は、いまのCodexでは使えません）。

接続先や認証を変える

Codexの接続先は、~/.codex/config.tomlで変えられます。社内で使うプロキシやゲートウェイを通したい場合や、データの保管場所の指定がある場合に使います。

ゲートウェイを使う場合、公式は次の点を挙げています。ストリーミング（少しずつ返す通信）が動くこと、完了を示す最後のイベントが送られること、モデルの別名を使うなら、その中身に合ったカタログ情報があることです。設定を変えたら、CLIを再起動し、/statusで、使っているモデルとプロバイダーを確認します。返事が返っただけでは、そのゲートウェイを通ったことの確認にはならないため、管理者が、ゲートウェイ側のログを確認するよう案内されています。

キーの管理と困ったとき

APIキーは、誰かに知られると、その人があなたの費用で、OpenAIのAPIを使えてしまいます。自動実行の仕組みは、人が気づかないうちに動き続けるため、管理のルールを先に決めておくことが大切です。

キーを守るための基本

もう1つ、見落としやすい点があります。公式の詳細設定のページによると、初期設定では、名前にKEY・SECRET・TOKENを含む環境変数は、Codexが実行するコマンドからも見えます。config.tomlの[shell_environment_policy]にignore_default_excludes = falseと書くと、これらが自動で除かれます。キーを環境変数に入れて使う場合は、設定しておくと安心です。

CIでの認証の考え方

公式のCI/CDの認証のページでは、自動化にはAPIキーを使うのが正しい方法であり、ほとんどのCI/CDのジョブで推奨されています。一方、ChatGPTのアカウントとして動かしたい場合の方法も、上級者向けに用意されています。

3つ目の方法では、auth.jsonがおよそ8日たつと自動で更新されるため、更新後のファイルを保管し直す必要があります。失敗が続く場合は、サインインし直して、ファイルを作り直します。この方法は設定の手間が大きく、公式でもAPIキーの方が簡単な初期値だとされています。

うまくいかないときの対処

会社で使う前に決めておくこと

• APIキーでCodexを使ってよい人と、使ってはいけない人
• キーを発行・保管・再発行する担当者と、その手順
• 自動実行に使うプロジェクトと、月の上限額
• Codexに読ませてよいリポジトリと、読ませてはいけない情報（顧客の個人情報、認証情報など）
• 自動実行の結果を、誰がいつ確認するか（人の承認は残す）
• キーが漏れた疑いがあるときの連絡先と、対応の流れ

導入の進め方

自動実行を会社に取り入れるときは、いきなり本番の処理に組み込むより、次の順で進めると失敗が少なくなります。

1. 読み取り専用で試すまず、要約や調査など、ファイルを変更しない処理だけをcodex execで動かし、結果の質と費用を見ます。
2. 専用のキーと上限を用意する自動実行用のプロジェクトを作り、月の上限と通知を設定します。
3. 書き込みを許可して、範囲を絞るファイルの変更が必要な処理に限って、workspace-writeを許可します。変更は、そのまま反映せず、差分（パッチ）として出力させ、人が確認してから取り込む形にします。
4. 実行の記録を見直す費用と、実行した結果を定期的に見て、想定外の使われ方がないかを確かめます。

よくある質問

まとめ

Codexを自動実行や社内ツールに組み込む場合、サインイン方式の選び方、キーと上限の管理、書き換えを許す範囲の設計など、決めることが一気に増えます。まずは読み取り専用の小さな処理から試して、費用と結果を確かめながら広げていくのがおすすめです。

INTERCREATE JAPANでは、Codex・Claude Codeなどの導入から、社内で安全に使い続けられる仕組みづくりまでをお手伝いしています。