OpenAIのモデルをアプリケーションから利用したいとき、「プログラムから呼び出すならAPI」と考えるのは自然です。しかし、2026年8月現在はそれだけでは使い分けを説明できなくなっています。
Codexには非対話実行のcodex execがあり、Codex SDKからローカルのCodex Agentをプログラムで制御できます。さらにApp Serverを使えば、認証、会話履歴、承認、Agentのイベントストリームまで含めて独自のクライアントへ組み込めます。MCPによる外部ツール連携やsubagentも利用できます。
つまり、現在は「自動化したい」「プログラムからAIを呼びたい」「Agentを動かしたい」という理由だけでは、Responses APIを直接使う理由になりません。
では、ChatGPTやCodexで多くのことができるのに、なぜOpenAI APIを直接使うのでしょうか。
ChatGPT / Codex / Responses APIの位置づけ
この記事では、ChatGPT、Codex、Responses APIを次のように捉えます。
| 選択肢 | 主な位置づけ | 実装者が主に持つもの |
|---|---|---|
| ChatGPT | OpenAIが完成した利用環境として提供するAIアプリケーション | 入力する指示、利用する機能、成果物の確認 |
| Codex | コーディングやコンピュータ操作に必要な機能を一体化したAgent Harness | タスク、実行環境、権限、プロジェクト側のルール |
| Responses API | 汎用的なAI / Agentアプリケーションを構築するためのAPI基盤 | 利用するモデルやTool、ワークフロー、権限、状態管理、UIなど |
これは厳密な製品階層ではありません。Responses APIは単なる「モデルを1回呼ぶ低レベルAPI」ではなく、組み込みTool、MCP、状態管理、Background Modeなどを備えています。2026年8月時点では、対応モデルでHosted ShellやApply Patchなどを利用でき、GPT-5.6ではProgrammatic Tool CallingやMulti-agentも提供されています。利用できるToolや機能はモデルによって異なります。
一方のCodexは、それらと競合する「より高性能なAPI」というより、コードを探索し、変更し、実行結果を確認しながら作業を進めるための機能がコーディングAgentとして一体化されていることに価値があります。
Model guidance | OpenAI API
Compare model features, migration guidance, and prompting best practices across OpenAI models.
https://developers.openai.com/api/docs/guides/latest-model
Responses APIは汎用的な基盤で、Codexはコード作業向けの機能が最初からまとまっています。この違いで見る方が、現在の両者の位置づけに近いです。
Application
├─ Codex SDK / App Server
│ └─ Codex Agent Harness
│ ├─ agent loop
│ ├─ context management
│ ├─ repository exploration
│ ├─ shell / filesystem
│ ├─ sandbox / approval
│ ├─ compaction
│ └─ model / tools
│
└─ Responses API
├─ model response / reasoning
├─ function / MCP / built-in tools
├─ hosted shell / apply patch など
├─ conversation / response state
├─ structured output
├─ programmatic tool calling
└─ multi-agent / background / streaming などCodexとResponses APIは用途がかなり重なっています。コード作業向けに用意されたCodexの仕組みをそのまま使うか、Application側で必要な構成を決めるかで選択が変わります。
Codexはすでに「プログラムから呼び出せるAgent」である
APIの意味を考える前に、現在のCodexを過小評価しないことが重要です。
codex execならスクリプトやCIから実行できる
Codexの非対話モードでは、codex execを使ってCI、定期ジョブ、シェルパイプラインなどからAgentを実行できます。JSONLでイベントを受け取ることもでき、JSON Schemaに沿った最終出力も指定できます。
そのため、「CLIでは自動化できない」「構造化データを返せないからAPIが必要」という比較は現在のCodexには当てはまりません。
Non-interactive mode | ChatGPT Learn
Use `codex exec` to run Codex in scripts and CI
https://learn.chatgpt.com/docs/non-interactive-mode
Codex SDKならアプリケーションからAgentを制御できる
Codex SDKは、ローカルのCodex Agentをプログラムから開始・継続・再開するためのSDKです。CI/CDへ組み込む、自社ツールからCodexを動かす、アプリケーション内でコーディングAgentを利用するといった用途が公式に想定されています。
Codex SDK | ChatGPT Learn
Programmatically control local Codex agents
https://learn.chatgpt.com/docs/codex-sdk
App Serverなら独自UIへ深く組み込める
Codex App Serverは、CodexのVS Code拡張のようなリッチクライアントを支えるインターフェースです。独自プロダクトにCodexを埋め込み、認証、会話履歴、承認、ストリーミングされるAgentイベントなどを扱えます。
「独自UIを作りたいからResponses API」というのも、必ずしも正しくありません。作りたいものがコーディングAgentのUIなら、App Serverの方が既存のCodex機能を再実装せずに済む可能性があります。
Codex App Server | ChatGPT Learn
Embed Codex into your product with the app-server protocol
https://learn.chatgpt.com/docs/app-server
MCPやsubagentもCodex側にある
CodexはMCPを通じて外部のツールやコンテキストへ接続できます。また、独立して進められる作業をsubagentへ委譲し、結果をメインのAgentへ戻すこともできます。
したがって、次の説明はAPI固有の利点としては弱くなっています。
- 外部サービスと連携できる
- 複数のAgentを使える
- shellを実行できる
- 自動化できる
- プログラムから呼び出せる
これらが必要なら即Responses API、とは言えません。
Model Context Protocol | ChatGPT Learn
Give Codex access to third-party tools and context
https://learn.chatgpt.com/docs/extend/mcp
Subagents | ChatGPT Learn
Use subagents in ChatGPT and Codex, and configure custom Codex agents
https://learn.chatgpt.com/docs/agent-configuration/subagents
違いはコーディング向けAgent Harnessをどこまで利用するか
Codexが強いのは、モデルにコード生成能力があるからだけではありません。
リポジトリを探索し、関連ファイルを見つけ、コマンドを実行し、結果を読み、修正し、テストし、失敗すれば別の方法を試す。この一連の作業を継続するには、モデルの前後に多くの機構が必要です。
たとえば次のようなものです。
- Agent loop
- 会話や作業履歴のコンテキスト管理
- shellとfilesystemへのアクセス
- sandboxとapproval
- ツール結果の取り込み
- 長い作業を継続するためのcompaction
- subagentの起動と結果の統合
Codexでは、この部分がコーディング作業向けのAgent Harnessとして一体化されています。
一方、Responses API側にもAgent的な機能があります。Tool Callingだけでなく、対応モデルではHosted Shell、Apply Patch、Computer Use、MCPなどを利用でき、複数の処理をまとめるProgrammatic Tool CallingやMulti-agentも選択肢に入ります。そのため、Responses APIからAgentを構築する場合に、shellやAgent機能をすべてゼロから再実装する必要があるわけではありません。
Codexではコード探索から変更、検証までの流れが最初からまとまっています。Responses APIでは、必要なToolやAgent機能をApplicationに合わせて選びます。
Application側では、たとえば次のような責務を持てます。
Application
├─ request validation
├─ state machine
├─ permission
├─ queue
├─ transaction
├─ retry
├─ database
├─ workflow
└─ Responses API / Codex などここにCodexを1ステップとして組み込むことも、Responses APIを使ってAgent的な処理を構成することもできます。「Applicationが状態を持つかどうか」自体が両者を分けるわけではありません。
APIを直接使う理由1：LLMを「Agent」ではなく処理の一部にできる
すべてのAI処理にAgentは必要ありません。
たとえば、フォームから届いた文章を次の5カテゴリのどれかへ分類する処理を考えます。
ユーザー入力
↓
入力チェック
↓
LLMでカテゴリ判定
↓
JSON Schemaで結果を検証
↓
DBへ保存必要なのは、入力を読み、カテゴリを決め、決められた形式で返すことです。
この処理では、リポジトリ探索もshellもfilesystemも不要です。AIが自律的に次の行動を考える必要もありません。状態遷移はApplication側ですでに決まっています。
同じことをCodexで実行すること自体は可能です。codex execには構造化出力もあります。しかし、業務アプリケーションのリクエストごとに分類だけを行うなら、コーディングAgentとしての周辺機構を利用する必然性は薄くなります。
Responses APIを直接呼び出せば、LLMを「仕事を任せるAgent」ではなく、関数や外部APIに近い一つの処理ステップとして配置できます。
この形が向くのは、たとえば次のような処理です。
- テキスト分類
- タグ付け
- JSONへの構造化
- 短い要約
- 入力内容の判定
- 文書から特定項目だけを抽出
- 既存データを使った定型文生成
こうした処理では「AIに何をさせるか」より、「システムのどの地点でモデルを呼び、返り値をどう検証して次へ渡すか」が設計の中心になります。
Structured model outputs | OpenAI API
Understand how to ensure model responses follow specific JSON Schema you define.
https://developers.openai.com/api/docs/guides/structured-outputs
APIを直接使う理由2：Agent loopへ委ねる範囲を限定しやすい
Applicationが状態遷移を持てること自体は、Responses API固有の特徴ではありません。codex execやCodex SDKも、Application側のState Machineやワークフローの1ステップとして呼び出せます。
差が出やすいのは、その1ステップの内部で、どこまでをAgentの判断に任せるかです。
注文処理を例にすると、次のような状態があるかもしれません。
received
↓
validated
↓
approved
↓
charged
↓
completedこの状態遷移に「AIがたぶん次は決済だと判断したから進む」という曖昧さを入れたくないケースは多くあります。
Application側で状態機械を持ち、AIには「入力文を分類する」「必要な項目を抽出する」といった限定された判断だけを担当させれば、次に進める条件、失敗時のrollback、再試行回数、監査ログ、権限確認などを通常のプログラムとして実装できます。
Application
├─ 状態遷移を判定する
├─ 権限を確認する
├─ DB transactionを開始する
├─ 限定された判断だけResponses APIへ渡す
├─ 出力を検証する
└─ 成功した場合だけ次の状態へ進めるもちろん、同じApplicationからCodexを呼び出す設計も可能です。ただし、リポジトリ探索や試行錯誤を必要としない1ステップなら、コーディングAgentのloopへ処理を委ねるより、Responses APIへ必要な入力とToolだけを渡す方が境界を明確にしやすい場合があります。
コード修正のようにAgent自身へ次の操作を選ばせたい処理もあります。分類や抽出なら、モデルに任せる範囲を狭くした方が実装は単純です。
APIを直接使う理由3：Capabilityをプロンプトではなく構成で制限できる
AIに対して「この処理ではshellを使わないでください」とプロンプトへ書く方法と、そもそもshellを利用可能なToolとして渡さない方法は意味が異なります。
たとえば、顧客問い合わせの分類処理でAIに必要なのが次の2つだけだとします。
利用可能
- search_docs
- get_customer
利用不可
- shell
- filesystem
- update_customer
- image generationこのとき、不要なCapabilityをTool一覧から外せば、モデルはそのToolを選択できません。複数のToolを定義している場合も、tool_choiceのallowed_toolsでそのリクエスト中に利用できるToolを一部へ限定できます。
これは「モデルにお願いして使わないでもらう」というPrompt Engineeringとは別の層です。Applicationが権限境界を作り、モデルはその境界の中で判断します。
Codexにもsandboxやapprovalがあり、Agentへ与える権限を制御できます。ただし、CodexではコーディングAgentとしての実行環境を安全に使わせることが中心です。業務アプリケーション固有のFunctionだけを公開したい場合は、Responses API側でCapabilityを定義する方が自然なことがあります。
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
Sandbox | ChatGPT Learn
How sandboxing works across ChatGPT and Codex clients
https://learn.chatgpt.com/docs/sandboxing
APIを直接使う理由4：Agentとは別の実行形態を選べる
OpenAI APIを使う意味は、1リクエストごとにチャット応答を返すことだけではありません。
APIプラットフォームには、用途に応じた別の実行形態があります。
| 機能 | 向いている処理 |
|---|---|
| Batch API | 大量の独立したリクエストをまとめて非同期処理する |
| Background Mode | 1回の処理が長時間になるResponses APIのタスクをバックグラウンド実行する |
| Webhooks | 完了などのイベントをApplication側で受け取る |
| Structured Outputs | JSON Schemaに沿った出力をApplicationへ返す |
| Realtime API | 音声など低遅延・双方向のやり取りを行う |
| Embeddings | 検索、類似度計算、クラスタリングなどに使うベクトル表現を作る |
これはCodexより高性能という意味ではなく、用途が違います。
たとえば、10万件の既存文章へカテゴリを付けたいなら、リポジトリを探索するAgentを10万回動かす設計より、大量処理向けのAPIを選ぶ方が目的に合っています。音声UIを作りたいなら、比較対象はコーディングAgentではなくRealtime APIです。
つまり、OpenAI APIを直接利用する理由の一つは、コーディングAgentとは異なる実行モデルも選べることです。
Batch API | OpenAI API
Learn how to use OpenAI's Batch API for processing jobs with asynchronous requests, increased rate limits, and cost efficiency.
https://developers.openai.com/api/docs/guides/batch
Background mode | OpenAI API
Run long running tasks asynchronously in the background.
https://developers.openai.com/api/docs/guides/background
Realtime and audio | OpenAI API
Learn which realtime and audio guide to use for each speech application.
https://developers.openai.com/api/docs/guides/realtime
Vector embeddings | OpenAI API
Learn how to turn text into numbers, unlocking use cases like search, clustering, and more with OpenAI API embeddings.
https://developers.openai.com/api/docs/guides/embeddings
Agent HarnessのToken消費は「無駄」とは限らない
CodexのようなAgentは、単純な1回のモデル呼び出しより多くのコンテキストやTokenを使うことがあります。
しかし、それだけを見て「APIの方が安い」と結論づけるのは危険です。
Codexがリポジトリの情報を読み、shellの結果を受け取り、修正内容を確認し、テスト結果から再判断するなら、それらはタスクを完了するために必要な情報です。subagentを使えば各Agentが独立してモデルとToolを使うため、公式ドキュメントでも単一AgentよりToken消費が増えることが明記されています。
一方、カテゴリ分類のような処理にリポジトリ情報やshellの実行履歴は必要ありません。その処理では、より小さいコンテキストでResponses APIを呼び出せる可能性があります。
Token数だけで比較すると、必要な処理を見落とします。カテゴリ分類にrepository探索やshellの履歴は不要ですが、コード修正ではそれらが判断材料になります。その処理に何の情報とToolが必要なのかを先に確認します。
Responses API側にもshell、Tool Calling、Multi-agentなどAgentを構成する機能があるため、Codexを使わないからといって周辺機能をすべて自作するわけではありません。ただし、どのToolを与え、どの状態をApplication側で持ち、どの範囲をAgentに任せるかは自分で設計する必要があります。
逆にCodexでは、コード探索・変更・コマンド実行・検証を繰り返すための構成があらかじめ一体化されています。見かけ上のTokenだけでなく、そのタスクに必要なHarnessと実装コストを含めて比較する必要があります。
ケースA：GitHubリポジトリのbuild errorを直す
次のタスクを考えます。
GitHubリポジトリでbuildが失敗している。原因を見つけて修正し、再度buildして確認する。
必要になる作業は固定されていません。
- リポジトリの構成を確認する
- エラーログを読む
- 関係しそうなファイルを探す
- 必要なら依存関係や設定を確認する
- 修正する
- buildやtestを実行する
- 失敗したら結果を読んで別の修正を試す
- 最後にdiffと検証結果を確認する
これはAgent Harnessと相性がよい仕事です。
最初から「3番目にこのFunctionを呼び、その後この状態へ遷移する」とApplication側で決めるのは難しく、途中の観測結果によって次の行動が変わります。
Responses API側にもHosted ShellやApply Patchなどがあり、この種のAgentを構成することは可能です。ただしCodexでは、リポジトリ探索、コード変更、shell、sandbox、approval、検証を繰り返す流れがコーディングAgentとして一体化されています。
そのため、一般的なコード修正を目的とするならCodex CLIやCodex SDKが自然な第一候補になります。Responses APIを選ぶ場合は、Codexにはない独自のワークフローやTool構成、権限境界をApplication側で設計する必要があるかを判断材料にできます。
ケースB：受け取った文章をカテゴリ分類する
今度は次の処理です。
APIで受け取った文章を5カテゴリのどれかに分類し、カテゴリIDと判定理由をJSONで返す。
必要な処理はほぼ固定できます。
- 入力を検証する
- モデルへ文章とカテゴリ定義を渡す
- 構造化された結果を受け取る
- Application側で結果を検証する
- DBへ保存する
ここではAIがfilesystemを探索する必要も、shellで試行錯誤する必要もありません。
Codexでも実行可能ですが、Application内部の一つの処理としてResponses APIを直接呼ぶ方が構造に合います。
ケースAでは、途中の結果によって次の操作が変わります。ケースBでは処理の流れはApplication側で決まっており、モデルが担当するのは分類だけです。
実装時の選び分け
2026年8月時点の機能を前提にすると、次のような選択が考えられます。
| やりたいこと | 第一候補 | 理由 |
|---|---|---|
| リポジトリを探索して修正・testまで任せたい | Codex | coding Agentとして必要なHarnessが一体化されている |
| CIや定期ジョブからCodexを非対話実行したい | codex exec | CLIをそのまま自動化へ組み込める |
| 自社アプリからコーディングAgentを制御したい | Codex SDK | Codex threadをプログラムから開始・継続できる |
| Codexを独自UIへ深く統合したい | App Server | 履歴、承認、Agentイベントなどを扱える |
| テキスト分類や抽出を業務処理の1ステップにしたい | Responses API | Agent loopを必須にせず、限定したモデル処理として配置しやすい |
| 独自Toolを組み合わせた汎用Agentを構築したい | Responses API | Tool、MCP、対応モデルのAgent機能をApplicationに合わせて構成できる |
| Toolの権限をリクエスト単位で限定したい | Responses API | 渡すToolやallowed_toolsをApplication側で決められる |
| 大量の独立したAI処理を非同期で流したい | Batch API | 大量処理向けの実行形態が用意されている |
| 長時間のモデル処理をHTTP接続から切り離したい | Background Mode | 非同期で実行し、状態を取得できる |
| 音声中心の低遅延UIを作りたい | Realtime API | 双方向・低遅延の用途に特化している |
| セマンティック検索用のベクトルを作りたい | Embeddings | Agentではなくベクトル化そのものが目的 |
もちろん、実際のシステムでは組み合わせることもあります。
たとえば業務アプリ全体はResponses APIを中心にしつつ、コード変更が必要な処理だけCodexを専門Agentとして呼ぶ構成も可能です。逆にCodexからMCP経由で社内システムを参照する構成もあります。
「APIの方が自由」という説明だけでは足りない
Responses APIについて「APIだから自由に作れる」と説明することがあります。間違いではありませんが、実装判断には情報が足りません。
自由という言葉の中には、Application側が引き受ける責務も含まれています。
たとえば次のものです。
- どのToolを渡すか
- Tool実行前後の認可をどうするか
- 失敗時に何回retryするか
- 会話や処理状態をどこへ保存するか
- 同じイベントを二重処理しないためにどうするか
- どの出力を信用し、どこを通常のコードで検証するか
- ログや監査情報をどう残すか
これらを自分で管理したいなら、APIを直接使う価値があります。
逆に、目的が「未知のコードベースを探索して問題を直す」であれば、汎用的なAgent基盤から構成を選ぶ自由は必ずしも利益ではありません。Codexがすでにコーディング向けに統合している仕組みを利用した方が、実装対象を本来の問題へ絞れる場合があります。
まとめ
ChatGPTやCodexで多くのことができる現在、OpenAI APIを使う理由を「APIならAgentを作れる」「自動化できる」「プログラムから呼べる」と説明するだけでは不十分です。これらの多くはCodex側でも実現できます。
同時に、Responses APIも単なるモデル呼び出しのprimitiveではありません。Tool Calling、MCP、Hosted Shellなどを使ったAgent的な処理を構成でき、対応モデルではProgrammatic Tool CallingやMulti-agentも利用できます。
未知のコードベースを探索しながら問題を解かせたい
リポジトリを読み、shellを実行し、修正と検証を繰り返させたい
→ Codex / Codex SDK / App Server
Application固有の状態・権限・transaction・retry・workflowの中で、
限定したLLM処理や独自Toolを使いたい
→ Responses API
汎用的なAgentを独自のTool構成や境界で作りたい
→ Responses APIのAgent機能も選択肢コード作業そのものを任せたいなら、Codexは探索・変更・実行・検証の仕組みが最初からまとまっています。Applicationの中で必要なAI機能を選び、モデルに任せる範囲を細かく決めたいならResponses APIが候補になります。
