Codex CLIでできるならOpenAI APIはいらない？ codex exec・SDK・App ServerとResponses APIを使い分ける

前の記事では、ChatGPT、Codex、OpenAI APIを「何ができるか」だけで比べると境界が見えにくくなっていることを扱いました。

ChatGPTやCodexでできるのに、なぜOpenAI APIを使うのか | kuromica

ChatGPTやCodexでも自動化やAgent実行ができる現在、OpenAI APIを直接使う意味を、機能差ではなく抽象化レイヤーと責務の違いから考えます。Codex SDK・App Server・Responses APIの使い分けを実装視点で解説します。

https://kuromica.com/blog/chatgpt-codex-openai-api-abstraction-layers/

kuromica · kuromica.com

今回はもう一段具体的にします。

Codexは対話型CLIとして使うだけではありません。2026年8月27日時点では、codex execで非対話実行でき、JSONLやJSON Schemaに沿った出力を扱えます。Codex SDKからローカルのCodex threadを操作でき、App Serverでは独自クライアントからthread、turn、approval、認証、イベントストリームまで扱えます。

ここまでできると、次の疑問が出てきます。

Node.jsやPythonからCodexを呼べるなら、Responses APIを直接使う必要はあるのか。

結論から言えば、Codexだけで十分な処理はかなりあります。特に、リポジトリを調査し、shellを実行し、ファイルを変更し、結果を確認しながら進める仕事では、Codexに用意されている仕組みをそのまま使う方が自然です。

Codexには、会話の状態管理、Tool実行、shellやファイル操作、sandbox、承認、長い作業の継続など、Agentが仕事を進めるための周辺機能がまとまっています。この記事では、この一式をAgent Harnessと呼びます。

Responses APIが向いているのは、こうした一式を使うよりも、アプリケーション側でAIに任せる範囲や使わせるTool、処理の流れを細かく決めたい場合です。

OpenAIも2026年8月19日の「Codex as a platform: build on the open agent harness」で、Codexを会話の状態、Tool利用、sandboxや承認、複数turnにまたがる作業をまとめて扱える基盤として説明しています。

Codex as a platform: build on the open agent harness | OpenAI Developers

Build Codex into the products and workflows your users already know.

https://developers.openai.com/blog/codex-as-a-platform

OpenAI Developers · developers.openai.com

codex execは十分に「プログラムから呼べる」

CLIという名前から、手作業で使うためのインターフェースを想像しやすいですが、codex execはスクリプトやCIでの利用を公式に想定しています。

たとえばNode.jsから子プロセスとして起動できます。

import { spawn } from "node:child_process";
import readline from "node:readline";

const codex = spawn(
  "codex",
  [
    "exec",
    "--json",
    "このリポジトリのbuild失敗を調査し、原因を特定してください",
  ],
  {
    cwd: "/srv/example-repo",
    stdio: ["ignore", "pipe", "inherit"],
  },
);

const lines = readline.createInterface({
  input: codex.stdout,
});

lines.on("line", (line) => {
  const event = JSON.parse(line);

  if (event.type === "turn.completed") {
    console.log("Codex turn completed");
  }
});

codex.on("close", (code) => {
  if (code !== 0) {
    console.error(`Codex exited with code ${code}`);
    process.exitCode = code ?? 1;
  }
});

--jsonを付けるとstdoutはJSONLになり、thread.started、turn.started、turn.completed、item.*などのイベントを機械的に処理できます。

最終結果だけ決められた形式で受け取りたい場合は、--output-schemaでJSON Schemaを指定することもできます。

Non-interactive mode | ChatGPT Learn

Use `codex exec` to run Codex in scripts and CI

https://learn.chatgpt.com/docs/non-interactive-mode

ChatGPT Learn · learn.chatgpt.com

つまり、次の理由だけではResponses APIを直接使う根拠になりません。

• プログラムから呼びたい
• cronやCIで動かしたい
• JSONとして結果を受け取りたい
• リポジトリを自動調査したい
• shellを含む処理を自動化したい

小規模な自動化なら、子プロセスとしてCLIを呼ぶ構成は珍しいものではありません。必要な依存がCodexと自分のスクリプトだけで済むなら、むしろ構成を増やさずに実装できます。

Codex SDKならthread / turnとして扱える

codex execを子プロセスとして扱う場合、呼び出し側はプロセス、stdout、終了コード、timeoutなどを管理します。

Codex SDKを使うと、Codexを子プロセスとしてではなく、threadやturnを扱うAPIとして呼べます。

2026年8月27日時点の公式ドキュメントでは、TypeScriptとPythonのSDKが案内されています。TypeScript版はNode.js 18以降のサーバーサイド利用を前提とし、ローカルのCodex threadを開始・継続・再開できます。

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

const codex = new Codex();
const thread = codex.startThread();

const result = await thread.run(
  "CI failureの原因を調査し、修正方針を提案してください",
);

console.log(result.finalResponse);

Python SDKは内部でローカルのCodex App ServerとJSON-RPCで通信します。公式ドキュメントでは、公開SDKに対応するCodex CLIも含まれると説明されています。

Codex SDK | ChatGPT Learn

Programmatically control local Codex agents

https://learn.chatgpt.com/docs/codex-sdk

ChatGPT Learn · learn.chatgpt.com

SDKを使ったからCodex自体が賢くなるわけではありません。変わるのは、アプリケーションからの扱い方です。

codex execでは起動したプロセスとstdoutを管理します。SDKではthread / turnというCodex側の単位で操作できます。

たとえば次の条件が増えてきたら、SDKを検討しやすくなります。

• 同じthreadを複数turnにわたって継続したい
• 過去のthreadをIDから再開したい
• stdoutのイベント処理をアプリケーションの中心に置きたくない
• Node.jsやPythonのコードからCodexを自然に扱いたい

一方、1回起動して結果を受け取るだけなら、codex execの方が単純なこともあります。

App Serverなら独自UIからCodexを細かく制御できる

独自のGUIやクライアントを作る場合も、必ずResponses APIへ移る必要はありません。

Codex App Serverは、独自UIや独自クライアントからCodexを操作するための窓口です。デフォルトではstdio上のJSONLを使い、双方向のJSON-RPCメッセージで通信します。

Desktop App / Custom UI
        ↓
     JSON-RPC
        ↓
 Codex App Server
        ↓
 Codex Agent runtime

App Serverでは、たとえば次の情報をクライアント側で扱えます。

• threadの開始・再開・一覧
• turnの開始と進捗
• コマンド実行やファイル変更のイベント
• コマンド実行やファイル変更の承認
• threadの状態
• ChatGPTまたはAPI keyによる認証
• ChatGPTの利用上限に関する情報

公式ドキュメントにはWebSocketもありますが、2026年8月27日時点では実験的な機能で、正式サポートの対象ではありません。通常の組み込みでは、まずデフォルトのstdio通信を前提に考える方が無難です。

Codex App Server | ChatGPT Learn

Embed Codex into your product with the app-server protocol

https://learn.chatgpt.com/docs/app-server

ChatGPT Learn · learn.chatgpt.com

ここまで見ると、「独自UIを作りたい」という理由だけではResponses APIを選ぶ根拠にはなりません。

作りたいものがCodexというコーディングAgentの独自クライアントなら、App Serverを使う方がCodexのthread、approval、実行イベントなどを再実装せずに済みます。

Responses APIの方が向いているのはどんなときか

Codexをプログラムから呼べるのに、あえてResponses APIを直接使うのはどんなときでしょうか。

まず見るべきなのは、今回の処理にCodexのAgent Harnessが必要かどうかです。

Codexには、問題を調べながら解決するための機能が最初からまとまっています。

Codex
├─ agent loop
├─ context management
├─ リポジトリ探索
├─ shell / filesystem
├─ sandbox / approval
├─ compaction
├─ MCP
├─ subagent
└─ model / tools

リポジトリのbuild errorを直す仕事なら、この一式がそのまま役立ちます。

一方、文章を3カテゴリのどれかに分類してJSONを返すだけなら、リポジトリ探索、shell、ファイル操作、長いAgent loopは通常必要ありません。

Responses API側にもFunction Calling、MCP、Hosted Shell、Apply Patchなどがあります。そのため、「CodexはAgent、Responses APIは単純なモデル呼び出し」と分けることもできません。

今回の処理にCodexの一式が必要なのか、必要なAI機能だけをResponses APIから使えば足りるのか。この違いで考えると選びやすくなります。

処理の流れをアプリ側で決めたい場合

業務アプリでは、処理の流れを通常のコードで決めておき、AIにはその一部だけを担当させたいことがあります。いわゆるState Machineをアプリ側で持つ設計です。

NEW
 ↓
CLASSIFY
 ↓
FETCH
 ↓
REVIEW
 ↓
WAIT_APPROVAL
 ↓
EXECUTE
 ↓
DONE

この1ステップからcodex execやCodex SDKを呼ぶこともできます。Codexを使っても、処理全体の流れをアプリ側で決めることは可能です。

違いが出るのは、そのステップの中でAIにどこまで自由に動いてほしいかです。

たとえばCLASSIFYが「文章を3カテゴリから選び、JSONを返す」だけなら、Responses APIへ限定された処理として渡す方が単純です。逆にREVIEWでリポジトリやログを調べながら原因を探すなら、そのステップだけCodexへ任せる構成も考えられます。

AIに使わせる機能を絞りたい場合

業務アプリケーションでAIへ公開したい操作が次の3つだけだとします。

利用可能
- searchCustomer()
- readInvoice()
- createDraft()

Responses APIではアプリ側がFunctionを定義し、そのリクエストで使えるToolをallowed_toolsでさらに絞れます。

Codexにもsandboxやapprovalがあります。ただ、業務処理で「この3つのFunction以外は最初から使わせない」と決めたいなら、Responses APIで必要なToolだけを渡す方が分かりやすい設計になります。

Function calling | OpenAI API

Learn how function calling enables large language models to connect to external data and systems.

https://developers.openai.com/api/docs/guides/function-calling

OpenAI Developers · developers.openai.com

大量処理や音声処理は、そもそも別のAPIが向いている

Responses APIを直接使う理由は、Agentの作り方だけではありません。数万件の文章をまとめて分類するならBatch API、低遅延の音声UIならRealtime API、検索用ベクトルを作るならEmbeddingsが向いています。

CodexからこれらのAPIを呼ぶコードを書くこともできますが、最初から目的が決まっているなら、その用途に合ったAPIを直接使う方がシンプルです。詳細はそれぞれ別記事で扱うテーマです。

CLIだから本番では使えない、とは限らない

codex execを本番処理へ組み込めるかどうかは、CLIという形式だけでは決まりません。

確認するのは、「CLIかどうか」よりも、実際に安定して運用できるかです。

観点	codex execで考えること
プロセス管理	起動、終了、異常終了を誰が管理するか
同時実行	同時実行数をどこで制御するか
タイムアウト	長時間タスクをどこで中断するか
中断処理	親プロセスから停止をどう伝えるか
ログ・監視	JSONLイベント、stderr、終了コードをどう記録するか
更新	Codex CLIのバージョン差をどう検証するか
作業ディレクトリ	どのディレクトリと権限で起動するか
認証	保存済み認証やCI用の認証情報をどう扱うか

認証方法も確認が必要です。codex execは保存済みのCLI認証を再利用できます。CIではAPI keyなどの認証情報を渡す構成になります。短時間だけ有効な認証情報を発行できる環境では、OpenAIはworkload identity federationも案内しています。

GitHub Actionsでは、CLIを自前でinstallしてjob全体へOPENAI_API_KEYやCODEX_API_KEYを置くより、openai/codex-actionの利用が推奨されています。リポジトリ内のbuild scriptやtestから同じ環境変数を読めてしまうためです。GitHub Actions以外でも、API keyを必要以上に広い範囲へ渡さないようにします。

Non-interactive mode | ChatGPT Learn

Use `codex exec` to run Codex in scripts and CI

https://learn.chatgpt.com/docs/non-interactive-mode

ChatGPT Learn · learn.chatgpt.com

これらを管理できるなら、CLIを子プロセスとして呼ぶ設計は十分成立します。

逆に、アプリの主要機能としてCodexを組み込み、threadやapprovalを細かく扱いたいなら、SDKやApp Serverの方が扱いやすくなります。

一回のAgent実行を既存automationへ追加
→ codex exec

Applicationコードからthread / turnとして扱う
→ Codex SDK

独自UIからapprovalやイベントまで制御
→ App Server

つまり、codex execが試作用でSDKが本番用、という分け方ではありません。どこまで細かくCodexを操作したいかで選びます。

配布するアプリでは、誰が認証するかも重要になる

自分だけが使う自動化では、端末やサーバーにCodexを用意し、認証を済ませておけば成立するケースが多くあります。

他人へ配布するアプリになると、考えることが増えます。

• Codexをどこで動かすか
• 利用者のCodex / ChatGPT認証をどう扱うか
• Codexのバージョン差をどう扱うか
• 更新にどう追従するか
• sandboxやapprovalを画面上でどう見せるか

App ServerはAPI keyだけでなく、ChatGPTのブラウザ認証やdevice-code flowも提供しています。そのため、配布アプリでCodexを使う場合も、全利用者にAPI keyを入力してもらう方法だけではありません。

一方、SaaSのバックエンドからResponses APIを呼ぶなら、通常はサービス側がAPI利用と認証を管理します。利用者のブラウザやアプリは、自分のサービスのバックエンドを呼びます。

ここでは「誰の認証情報を使うのか」「CodexやAPIをどこで動かすのか」が設計上の違いになります。

ケースA：自宅サーバーのログ解析

次の自動化を考えます。

cron
 ↓
ログファイル
 ↓
AIが原因調査
 ↓
結果をJSONで出力
 ↓
自作scriptがDiscordへ通知

ログの周辺ファイルを読んだり、サービス状態を調べたり、必要に応じてshellで追加確認したりするなら、codex execはかなり合理的です。

自作スクリプトはCodexを起動し、JSONLまたは構造化された結果を受け取り、通知だけ担当できます。

この規模であれば、Responses APIへ移行する理由を無理に作る必要はありません。

一方、毎日同じ形式のログ1ファイルを読み、障害カテゴリを5種類から選ぶだけなら、Agentの探索能力を使わずResponses APIへ直接渡す構成も候補になります。

ケースB：デスクトップアプリにAIコード修正機能を入れる

ユーザーがGUIでリポジトリを選び、AIが調査、修正、testまで行うアプリを考えます。

必要になるのは、単純なテキスト生成より次の要素です。

• リポジトリ探索
• shell実行
• ファイル変更
• sandbox
• approval
• 進捗イベント
• thread継続

この場合、Codex SDKまたはApp Serverが第一候補になりやすくなります。

アプリ内部からCodex threadを呼べれば十分ならSDK、承認ダイアログや実行中のcommand、file changeをGUIへ細かく出したいならApp Serverという選び方ができます。

Responses APIから同じようなAgentを作ることもできます。ただし、Codexにはコード作業に必要な機能がすでにまとまっています。それを使わずに自分で組み立てる理由があるかは、先に確認したいところです。

ケースC：SaaSで毎日数万件の文章を分類する

今度は、ユーザー投稿を毎日数万件処理し、カテゴリIDを付けるSaaSを考えます。

処理は固定できます。

database
 ↓
未分類データを取得
 ↓
モデルへ分類を依頼
 ↓
結果を決められた形式で受け取る
 ↓
databaseへ保存

リポジトリを探索する必要はありません。shellもファイル操作も不要です。

この用途ではResponses APIやBatch APIを直接使う方が設計しやすくなります。

このケースの中心は、大量の入力を決められたworkflowへ流し、各結果を検証して保存することです。

4つの選択肢をどう使い分けるか

実装時の第一候補をまとめると、次のようになります。

やりたいこと	第一候補	主な理由
cronやCIからCodexを1タスク実行したい	codex exec	子プロセスとして簡単に組み込め、JSONLや構造化出力を扱える
Node.js / PythonからCodex threadを扱いたい	Codex SDK	thread / turnとして操作できる
独自UIでCodexの進捗・approval・認証を扱いたい	App Server	Codexの実行状況や承認を細かく扱える
文章分類や抽出をアプリの一処理として使いたい	Responses API	必要なモデル処理とToolだけに絞りやすい
決められたFunctionだけAIへ使わせたい	Responses API	AIに渡すToolをアプリ側で限定できる
数万件の独立処理をまとめて流したい	Batch API	大量の非同期処理に向いている
コード探索・変更・検証をまとめて任せたい	Codex	コード作業に必要な機能が最初からまとまっている

実際のシステムでは併用もできます。

たとえば通常の業務処理はResponses APIで実装し、リポジトリ修正が必要になったときだけCodexを専門Agentとして呼ぶ構成も可能です。

Tokenや処理時間は用途ごとに測る

Codexはリポジトリの内容、shellの結果、修正内容、test結果などを次の判断に使います。そのため、1回だけモデルを呼ぶ処理より多くのコンテキストやTool結果を扱うことがあります。コード修正には必要でも、文章分類には不要な情報です。

そのため「Codexの方が重い」「APIの方が安い」と一般化するのではなく、同じタスクで入力Token、Tool呼び出し回数、AIが判断と実行を繰り返した回数、処理時間を比べる必要があります。料金やAgent Harnessによる差の実測は、別記事で扱う方が適しています。

まとめ

Codexをプログラムから呼べる現在、「自動化したいからResponses API」「独自UIだからResponses API」という説明では技術選定になりません。

codex execはスクリプトやCIから利用でき、JSONLと構造化出力を扱えます。SDKではCodex threadをアプリから操作でき、App Serverでは独自クライアントからthread、approval、認証、進捗イベントまで扱えます。

そのため、コーディング向けの探索・変更・実行・検証ループをそのまま利用したい処理では、Codex側で完結するケースが多くあります。

Responses APIが向いているのは、アプリ側で決めた処理の流れの中でAIの担当範囲を小さくしたい、AIに使わせるToolを限定したい、Batch・Realtime・Embeddingsなど別のAPI機能を使いたい、といった場合です。

既存の自動処理にCodexを追加する
→ codex exec

アプリのコードからCodex threadを扱う
→ Codex SDK

独自UIからCodexの進捗や承認まで扱う
→ App Server

決められた処理の中で、
必要なAI機能とToolだけを使う
→ Responses API

「できるかどうか」だけを見ると、CodexとResponses APIでできることはかなり重なっています。

選ぶときは、どこまでをCodexに任せたいのか、どこからを自分のアプリで決めたいのかを見ると分かりやすくなります。