OpenCode vs Codex CLI: ターミナル型AIコーディングエージェント徹底比較（2026）

要点: OpenCodeとCodex CLIはどちらもターミナルファーストのコーディングエージェントですが、下流のすべてを左右する一点で意見が異なります。それは、どのモデルを動かすことが許されるかです。OpenCodeはモデル非依存のハーネス（75以上のプロバイダーのいずれでも、セッション途中で切り替え可能）で、MITライセンスと横に控えるデスクトップアプリを備えています。Codex CLIはOpenAI自身のエージェントで、Rustで書かれ、デフォルトではOpenAIのエンドポイントに固定され、このカテゴリで最強のサンドボックスと、他プロバイダーへの扉を開く設定ファイルを持ちます。ただしその扉は数リリース前より狭くなっています。スタックがマルチモデルであるか、ロックインを信用しないなら、OpenCodeです。OpenAIの中で暮らし、最も厳格な安全性を求めるなら、Codexです。本稿の残りは、その選択が実際に痛みを伴う細部について扱います。その中には、両者を同じゲートウェイに対して走らせて見つけたものも含まれます。

要点: どちらを選ぶべきか

自分の制約がすでに分かっているなら、本文は飛ばして構いません。シナリオ別の判断は以下のとおりです。

どちらも無料でオープンソースです。どちらもターミナルで動きます。分かれ目は思想であって価格ではありません。

5分でわかる比較

日々の使い心地を左右するスペックを、各プロジェクトのリポジトリとドキュメントに2026-07-29時点で照合して検証しました。

この表の2行がほとんどの重みを担っています。「デフォルトモデル: なし」がOpenCodeの主張そのものです。「デフォルトモデル: GPT-5-Codex」がCodexの主張そのものです。他のすべてはこの2つの事実から導かれます。

OpenCode: モデル非依存のハーネス

OpenCodeはモデルを実行時の引数として扱い、製品上の決定とは見なしません。デフォルトのプロバイダーは付いてきません。初回起動時に1つ接続し、そこからはセッションごと、あるいはメッセージごとに、models.dev 経由で組み込まれた75以上のプロバイダーの一覧からモデルを選びます。Claude、GPT、Gemini、GLM、ローカルのOllamaビルドまで、すべてが /models の中の項目にすぎません。

この設計にはいくつかの現実的な帰結があります。

誰のロードマップにも縛られません。 新しいモデルが登場し、models.devのレジストリに現れれば、クライアントの更新なしにOpenCodeに現れます。ハーネスはそのモデルを誰が作ったかを気にしません。それが要点です。

薄いラッパーではなく、完全なエージェントです。 OpenCodeはプランエージェントとビルドエージェントを走らせ、キー1つで切り替えられます。プランモードは読み取り専用で、ファイルに触れずにアプローチを提案します。ビルドモードは実行します。Language Server Protocolのサーバーを統合しているため、TypeScript、Python、Rust、Go、そして数多くの言語について、モデルは生のテキストから推測するのではなく、実際の型情報とコンパイラ診断を見ます。MCPを話し、カスタムツールに対応し、同一プロジェクトで複数のセッションを並行して走らせます。

ターミナル専用のツールではありません。 TUIと並んで、デスクトップアプリとIDE拡張があります。エージェントのループは欲しいがターミナルは要らないという場合、OpenCodeにはあなた向けのサーフェスがあります。Codexはターミナルとexecパイプラインにより強く寄っています。

痛むところ: モデル非依存とは、失敗モードも含めてモデルの決定を自分が負うということです。OpenCodeを弱い、あるいは誤設定のプロバイダーに向ければ、弱い、あるいは誤設定の出力が返り、ハーネスがまずいルーティングの選択から救ってくれることはありません。プロバイダーレジストリには既知の粗さもあります。まっさらなインストール直後、追加したばかりのプロバイダーが、レジストリのキャッシュがまだ書き込まれていないために、最初の呼び出しで現れないことがあります。modelsコマンドを一度走らせて温めれば解決します。セットアップをスクリプト化して最初の呼び出しが確定的だと仮定する前に、知っておく価値があります。

OpenCodeはモデルを実行時の引数として扱い、製品上の決定とは見なしません。この1つの選択こそが、マルチモデルのケースで勝ち、「箱を開けてすぐ動く」ケースで負ける理由です。

Codex CLI: OpenAI純正のエージェント

Codex CLIはOpenAI発で、それがすべての設計判断に現れています。Rustで書かれているため、Nodeプロセスではなく高速な単一バイナリです。OpenAI自身のエンドポイントとCodexチューンのGPT-5モデルに向けて出荷され、デフォルトユーザーにとっては設定ゼロを意味します。インストールし、ChatGPTアカウントかAPIキーで認証し、コーディングを始めるだけです。

強みは信頼と安全の周りに集まります。

サンドボックスはこの比較で最良です。 CodexはOSレベルのプリミティブ（macOSではseatbelt、LinuxではLandlockとseccomp）でコマンド実行を隔離し、その上に承認モードを載せます。エージェントにどれだけ手綱を渡すかを選べます。提案のみ、ワークスペース内での自動編集、あるいはサンドボックス内での完全自動です。エージェントが実行する rm は、モデルが行儀よく振る舞うことによってではなく、構造によって封じ込められます。タスクを自動承認したり、自分が書いていないものを何であれ実行したりするなら、その隔離こそが実際に買っている機能です。

OpenAIスタックの純正の一員です。 /review コマンドは作業ツリーに触れずにインラインのコードレビューを行います。サブエージェントが作業を並列化します。Codex RemoteはChatGPTモバイルアプリから接続されたMacやWindowsホストを操作させます。/import コマンドはCursorとClaude Codeの設定、MCPサーバー、プラグイン、コマンドをCodexに取り込み、移行を週末仕事ではなくコマンド1つにします。

デフォルトに反して、OpenAIに固定されているわけではありません。 互換ゲートウェイを指す [model_providers.<id>] ブロックを ~/.codex/config.toml に追加すれば、Codexはそのゲートウェイが提供するものを何でも呼び出します。扉は存在します。ただ手で開ける必要があるだけです。ここが、扉がデフォルトで開いているOpenCodeとの正直な違いです。

落とし穴は、どのプロトコルが互換とみなされるかで、その答えは変わりました。Codexはかつて wire_api = "chat"（つまり任意のChat Completionsエンドポイント）を受け入れていました。その値は消えました。0.146.0のソースでは WireApi enumに残っているバリアントは1つだけ、Responses で、chat を渡すと無視されるのではなく、起動時のハードエラーになります。

wire_api = "chat" is no longer supported. How to fix: set wire_api = "responses" in your provider config.

このメッセージは discussion #7782 にリンクしており、そのタイトルは「Deprecating chat/completions support in Codex」です。廃止予定としてはこれ以上ないほど明確です。Chat Completionsはほぼ普遍的な方言です。Responses APIはそうではありません。その変更以前に書かれたチュートリアルはすべて、今や読み込めない設定を生み出し、Chat Completionsだけをプロキシするゲートウェイはすべて、今や手の届かないところにあります。

痛むところ: OpenAIファーストのデフォルトは、離れたくなるまでは快適です。Codexにおけるモデルの自由はメニューではなく設定作業であり、プロトコルの境界は実在し、OpenAIに有利な方向へ動きました。base_url をAnthropicのネイティブAPIに向けて動作を期待することはできません。それはResponses APIではないからです。非OpenAIモデルはResponses対応のゲートウェイ経由でルーティングするか、まったくルーティングしないかのいずれかです。そして次のセクションで示すように、「Responses対応」はゲートウェイ単位ではなくモデル単位の性質であることが判明します。

直接対決: あなたの一日を変える差

6つの軸と、それぞれの勝者です。ここでの「勝者」は「その軸で最適化する大半の人にとってより良い」という意味であり、普遍的な判定ではありません。

その列を眺めれば、パターンは明らかです。OpenCodeは自由と独立性で勝ちます。Codexは安全性と、単一ベンダー内でのターンキー性で勝ちます。一方があらゆる面で厳密に先んじている軸はなく、それこそが、推奨が単一の名前ではなく条件付きになる理由です。

セットアップと日々のワークフロー、実測

でっち上げた品質スコアは忘れてください。正直で検証可能な差は、同じ仕事をするのに各ツールが何ステップ必要か、そして摩擦がどこにあるかにあります。

デフォルト以外のモデルで最初の応答に到達する。 OpenCodeでは、プロバイダーのキーをexportし、TUIを開き、/models を走らせて選びます。編集するファイルはありません。Codexでは、非OpenAIモデルとはまず config.toml に model_providers ブロックを書き、次に欲しいモデルが実際にResponses API経由で提供されているか確認し、それから選択することを意味します。マルチモデルのケースではOpenCodeが設計上ステップが少なく、欲しいモデルがOpenAIのものならCodexのほうがステップが少なくなります。その場合はステップがゼロだからです。

タスク途中でのモデル切り替え。 OpenCodeは走っているセッション内で /models を通じてライブに切り替えます。Codexは呼び出しごとに --model で、あるいは名前付きプロファイルを読み込んでモデルを変えます。これはハンドルを微調整するというより、レーンを選ぶことに近い操作です。「高価なモデルで推論し、安いモデルに編集を挽かせる」ワークフローなら、OpenCodeはそれを2秒のトグルにします。

シェルコマンドの実行。 OpenCodeは権限を求めます。Codexは設定した承認モードの下でサンドボックス内で実行するため、あなたがイエスと言っても隔離は保たれます。表面上は同じプロンプトでも、その下の影響範囲はまったく異なります。

プロジェクト指示。 どちらも AGENTS.md を読みます。Cursorや他のツールが採用したのと同じ慣習なので、すでにそれを持つリポジトリはどちらのエージェントでも変更なしに動きます。これはこの1年の静かな勝利です。プロジェクトのエージェント指示は今やツール間で持ち運び可能なのです。

初回起動、横並び

差を感じる最速の方法は、両方をインストールして最初の応答に到達することです。OpenCodeは、自分で用意したモデルで:

npm i -g opencode-ai
export OFOX_API_KEY=sk-your-key      # any OpenAI-compatible provider works
cd your-project
opencode                              # /models to pick, Tab to toggle plan/build

Codexは、それが最適化するケースであるOpenAIのデフォルトで:

npm i -g @openai/codex
cd your-project
codex                                 # authenticates with ChatGPT or OPENAI_API_KEY

それぞれのコマンドが何を前提としているかに注目してください。OpenCodeのハッピーパスは、あなたがプロバイダーを指定することを期待し、その報いとしてメニューを返します。Codexのハッピーパスは、あなたがOpenAIユーザーであることを期待し、その報いとして設定ゼロを返します。どちらも間違ってはいません。異なる初回ユーザーに向けて最適化しており、インストール体験がどちらのチームがどのユーザーを思い描いたかを教えてくれます。

拡張性: MCP、スキル、サブエージェント

モデルの問題を過ぎれば、両エージェントは似た形で拡張可能ですが、各所での成熟度は異なります。ここでは「純正」が思想としてではなく磨き込みとして現れ始めます。

どちらもMCPを話すため、同じコンテキストサーバーとツール統合がどちらにも差し込めます。Codexは構造化された拡張モデル、つまりスキル、名前空間付きMCP、スラッシュコマンドに寄っており、製品を出荷するチームによって統制されている感触があります。OpenCodeはサーフェスに寄っており、同じエージェントをターミナル、デスクトップウィンドウ、エディタで提供し、加えてセッションをチームメイトに渡す /share フローがあります。読み取り専用のストーリーは両者の思想をきれいに映しています。OpenCodeは切り替えて入る専用のプランエージェントを与え、Codexはツリーに触れずに批評する /review コマンドを与えます。同じ目標、2つの流儀です。

速度について実務的な注記を1つ。CodexはRustのバイナリなので、起動が速く軽いままです。OpenCodeはNode上で動きますが、モデルが考えている間に気づくような遅さはどこにもなく、ただ待機時のプロセスがより重いだけです。大半の人にとってはモデルのレイテンシがツールのそれを圧倒し、これは決して問題になりません。ヘッドレスなエージェント群をスクリプト化するなら、問題になり得ます。

1つのキー、大きく異なる2つのモデルメニュー

ここが、2つの思想が抽象論であることをやめ、私たちが推測をやめて実際に走らせた部分です。どちらのエージェントもゲートウェイのベースURLを受け入れるため、1つのキーでClaude、GPT、Gemini、オープンウェイトのモデルの課金をまかなえます。1つのキーが保証しないのは、両エージェントがそのすべてに届けるということです。私たちは2026-07-29に両者を ofox.ai に対してセットアップしましたが、結果は対称ではありませんでした。

OpenCode: 環境変数1つ、設定ファイルはゼロ。 ofoxはmodels.devレジストリの組み込みプロバイダーなので、OpenCodeはキーが存在した瞬間にそれを発見します。

export OFOX_API_KEY=sk-your-key
opencode            # /models now lists ofox/... entries, pick one

これで設定はすべてです。ファイルもプロバイダーブロックもなく、OpenCodeはChat Completionsを話すため、ゲートウェイが提供するものはすべてメニューに載ります。

Codex CLI: 設定ブロック1つ、そして思ったより短いメニュー。 Codexはゲートウェイを ~/.codex/config.toml に一度宣言する必要があります。

model = "openai/gpt-5.5"
model_provider = "ofox"

[model_providers.ofox]
name = "ofox.ai"
base_url = "https://api.ofox.io/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"
requires_openai_auth = false

wire_api = "responses" は好みではなく、現行のCodexリリースが受け入れる唯一の値です。そのため、ゲートウェイは単なるChat CompletionsではなくResponses互換のエンドポイントを公開しなければなりません。requires_openai_auth = false はデフォルトで、CodexにChatGPTのログインフローを表示させないようにし、代わりに env_key からキーを読ませます。完全なキー一覧は Codex config reference にあります。

実際に動いたもの

その設定にCodex 0.146.0を向け、codex exec --sandbox read-only を使って各モデルに1語で返答するよう求めました。これが、始める前には予想していなかった結果です。

この非対称性に注目してください。本稿で最も有用なことだからです。GLMは4つのうち、カタログが事前にサポート外と示していた唯一のモデルです。Claude、DeepSeek、Grokはすべて /v1/responses の下に列挙されていながら、それでも失敗しました。エンドポイント一覧は事前フィルターであって保証ではありません。

3つの異なる失敗、1つのテーマ。GLMはゲートウェイが /v1/responses の下でプロキシしないため、モデルに一切到達しません。DeepSeekとGrokは到達可能ですが、Codexがすべてのリクエストに付ける reasoning.encrypted_content フィールドを拒否し、そのフィールドは設定として公開されるのではなく client.rs にハードコードされているため、設定による逃げ道がありません。Claudeは到達可能で暗号化コンテンツも受け入れますが、Codexの自由形式 apply_patch ツールの形状で詰まります。

次に、同じキー、同じゲートウェイ、同じマシンで、同一のプロンプトをOpenCode 1.18.9に通しました。Codexが届けなかった4つのモデルはすべて通常どおり回答し、SDKからの素の chat/completions 呼び出しも同様でした。それが決め手です。これはCodexとゲートウェイ層の間のプロトコルの継ぎ目であって、モデルの問題でも、ゲートウェイが落ちているのでもありません。

コミットする前に確認する方法。 ゲートウェイのモデル一覧は各モデルがどのエンドポイントの下で提供されているかを報告するため、設定をデバッグする代わりに事前にふるいにかけられます。

curl -s https://api.ofox.io/v1/models \
  -H "Authorization: Bearer $OFOX_API_KEY" \
| jq -r '.data[] | select(.supported_endpoints | index("/v1/responses")) | .id'

2026-07-29時点でそれは67個のモデルIDを返しました。カタログには123エントリがありますが、そのうち18はどちらのテキストエンドポイントも公開しない画像・動画・埋め込み・文字起こしのモデルなので、意味を持つ分母は105のテキストモデルです。102がchat completions経由、67がResponses経由で提供されています。この2つの集合は入れ子ではなくほぼ完全に重なります。64のモデルが両方を提供し、正確に3つがResponses専用です（openai/gpt-5.2-codex、openai/gpt-5.3-codex、openai/gpt-5.4-pro）。

ファミリー単位で数えると、Claude、GPT、DeepSeek、Doubao、Grokのテキストモデルは最後まで網羅されていました。Qwen（21のうち10）、MiniMax（9のうち7）、Kimi（5のうち2）は一部のみで、サポートされていると思い込んでいるファミリーの中でもモデルごとの確認が重要です。GeminiとGLMはどのバージョンにもResponsesエントリがなく、Kimi K3も同様でした。その一覧はCodexが到達できたものの外縁として扱い、そのうえで具体的なモデルをテストしてください。上の表が示すように、列挙されていることは必要条件であって十分条件ではないからです。

これらはどれもOpenCodeには触れません。モデル戦略が本当に混成なら、それこそがOpenCodeを選ぶ実務的な論拠です。はっきり言っておく価値もあります。これはCodex側のプロトコル判断であり、Chat Completions専用のゲートウェイをすべて一度に壊し、おそらくはゲートウェイがより充実したResponsesシムを構築するにつれて落ち着いていくでしょう。これは今日についての真実であって、永久の判定ではありません。

同じキーはコードからも動きます。それが、どちらのエージェントもループに入れずに、同じタスクで2つのモデルをA/Bする方法です。同じベースURL、1つの文字列を差し替えるだけ、心配すべきプロトコルの継ぎ目はありません。

Python: 同じタスクを2つのモデルで走らせる

from openai import OpenAI

client = OpenAI(
    api_key="sk-your-ofox-key",
    base_url="https://api.ofox.io/v1",
)

task = "Refactor this function to remove the nested loop, keep behavior identical."

for model in ["anthropic/claude-sonnet-5", "z-ai/glm-5.2"]:
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": task}],
    )
    print(f"\n=== {model} ===")
    print(resp.choices[0].message.content)

Node: 同じ形

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "sk-your-ofox-key",
  baseURL: "https://api.ofox.io/v1",
});

const task = "Write a Postgres migration to add a nullable created_by column.";

for (const model of ["anthropic/claude-sonnet-5", "openai/gpt-5.5"]) {
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: task }],
  });
  console.log(`\n=== ${model} ===`);
  console.log(resp.choices[0].message.content);
}

モデルIDはリテラルです。それがOpenCodeに貼り付けるもので、Codexには現在到達できるサブセットに対して貼り付けるものです。それが可搬性の売り文句の正直な版です。エージェントはハーネスでモデルは変数ですが、今日その変数を自由に変えさせてくれるのは、この2つのエージェントのうち片方だけです。

そのコスト

上で使った3つのモデルのゲートウェイ料金を、2026-07-29にofoxのモデルページから読み取りました。100万トークンあたりです。

GPT-5.5は確認した日に20%のプロモーション割引がかかっていたので、$4と$24が実際に課金される数字で、取り消し線の$5と$30が定価です。プロモは期限が切れます。半年後にこの表を信じるのではなく、モデルページを読んでください。他の2つには割引は適用されていませんでした。

この表の要点は絶対値ではなく、その開きです。GLM-5.2はプロモ価格で出力においてGPT-5.5のおよそ5分の1のコストなので、「強いモデルで推論し、安いモデルで挽く」ワークフローは丸め誤差ではなく、実際の請求額の差になります。OpenCodeはそのトグルをキー1つにします。Codexは上のテストのとおり、この3つのうち2つのモデルには一切到達できませんでした。これは、エラー文字列ではなく請求書の一行として届く同じ発見です。コストのレバーは、それを引けるエージェントにのみ存在します。

その選択を段落ではなく図として見たいなら、それは2つの問いに収束します。

OpenCodeを選ぶとき

以下のいずれかが自分に当てはまるならOpenCodeを選んでください。複数のモデルベンダーにまたがって作業をルーティングし、それを移行ではなくメニューにしたい。日々の主力を単一の会社の価格とロードマップに縛り付けることを警戒している。ターミナルの外、デスクトップアプリやエディタでもエージェントが欲しい。プロジェクトがMITライセンスでコミュニティ運営であり、通行料を取るデフォルトベンダーがいないことを重んじる。モデル非依存の設計がここにいる理由であり、それを使わないなら、必要のない柔軟性に対価を払っていることになります。

Codex CLIを選ぶとき

すでにOpenAIの世界の中にいてデフォルトがそのまま動いてほしいなら、タスクを自動承認またはバッチ実行し、Codexがこのカテゴリの誰よりも堅牢化してきたOSレベルのサンドボックスが必要なら、あるいはClaude Codeから移行していて退屈な部分をインポートコマンドに任せたいなら、Codex CLIを選んでください。Rustのバイナリは速く、安全性のストーリーはここで最強で、ChatGPTアプリとCodex Remoteとの純正統合にはOpenCode側に相当するものがありません。OpenAI自身のモデルの先へめったに手を伸ばさないなら、他プロバイダーを解放する設定作業は決してやらない作業であり、それで結構です。先へ手を伸ばすと見込むなら、それに基づいて計画を立てる前に上のプロトコルのセクションを読んでください。今日その扉は、ドキュメントが示唆するより小さな部屋に通じているからです。

どちらも正解でないとき（そして代わりに何を使うか）

エディタからほとんど離れないなら、ターミナルエージェントはワークフローへの課税であり、インラインアシスタント付きのCursorやZedのほうが手になじむでしょう。仕事が固定パイプライン（これを生成し、それをレビューし、スケジュールに乗せて出荷する）なら、対話型エージェントは一切欲しくなく、モデルのAPIを直接呼ぶスクリプトが欲しいはずです。だからこそ上のコード例は、どちらのCLIもループに入れずにゲートウェイを呼んでいます。そして2つではなく4つのエージェントを比較しているなら、私たちの 4方向ターミナルエージェント比較 がCodexと並べてClaude CodeとDeepSeek TUIを扱い、価格と主力ツールの観点を整理しています。

ターミナルエージェントは特定の嗜好に対する特定のツールです。モデルをシェルの中に置き、ファイルを見守らせ、コマンドを実行させたい。それがその嗜好でないなら、このどちらもあなたの答えではありません。そして間違った形のツールに手を伸ばすことは、2つのうち間違ったほうを選ぶことよりも、ありふれた誤りです。

FAQ

質問と回答はページメタデータの上部にあります。読者と検索エンジンのために、同じ組をここにも描画しています。この2つのエージェントで迷っているなら、大半の決定を片付ける2つの事実は次のとおりです。OpenCodeはモデル非依存でCodex CLIはOpenAIファーストであること、そしてCodexのほうがサンドボックスが堅牢でOpenCodeのほうがモデルメニューが広いことです。

参考文献

• github.com/anomalyco/opencode（旧 sst/opencode のパスはここへ301される）
• github.com/openai/codex
• codex-rs/model-provider-info/src/lib.rs at rust-v0.146.0
• openai/codex discussion #7782
• opencode.ai/docs
• Codex CLI config reference
• models.dev
• ofox model pages

関連する読み物: OpenCodeセットアップガイド、Codex CLIのカスタムモデルプロバイダー、Codex config.toml徹底解説、そして Claude CodeからCodexへの移行。