Codexをあらゆるオープンソースモデルで活用する方法 (OSSモード)

CodexはデフォルトでOpenAIモデルを搭載していますが、それらに限定されるわけではありません。CLIには、OllamaやLM Studioのようなローカルランタイム用の組み込みOSSモードと、TOMLファイルで定義した任意の互換性のあるエンドポイントにエージェントを接続するカスタムプロバイダーシステムが備わっています。つまり、ノートパソコンでgpt-ossを実行したり、ホストされたDeepSeekまたはQwen APIでCodexを駆動したり、プロジェクトごとにプロバイダーを切り替えたりすることができます。

このガイドでは、OSSモードとは何か、正確な設定キー、モデルごとのレシピ、そしてOpenAIモデルを交換する際に受け入れるトレードオフなど、全体的なセットアップについて解説します。ここにあるすべての情報は、公式のCodex高度設定ドキュメントに基づいています。ドキュメントがあいまいな場合は、推測せずにその旨を明記しています。

始める前に一点注意です。Codex内でモデルが実行されても、モデルはワークフローの半分に過ぎません。もう半分は、エージェントが構築・呼び出すAPIの検証です。そこでApidogが役立ち、このガイドの後半でその連携について説明します。

TL;DR

Codex OSSモードはCLI機能です。codex --ossを実行すると、CodexはOpenAIではなくローカルのOllamaまたはLM Studioサーバーと通信します。~/.codex/config.tomlでoss_provider = "ollama"を設定するとそれがデフォルトになり、-m <model>を渡して実行するローカルモデルを選択します。ホストされたオープンソースモデル（DeepSeek、Qwen、GLMのAPI経由）の場合、base_urlとenv_keyを持つ[model_providers.<id>]ブロックを定義し、model_providerで選択します。注意点として、現在の設定リファレンスではresponsesが唯一サポートされているwire_api値として挙げられているため、エンドポイントはResponses APIプロトコルに対応している必要があります。

OSSモードとは

OSSモードは、ローカルのオープンソースモデルサーバーに対してCodexを実行するためのショートカットです。ドキュメントには、2つのサポートされているローカルプロバイダーが記載されています。

Ollama、人気のローカルモデルランタイム
LM Studio、組み込みのローカルサーバーを持つデスクトップアプリ

--ossフラグで有効にします。Codex開発者コマンドリファレンスより：

--oss: ローカルのオープンソースモデルプロバイダーを使用します。Codexは--local-provider、設定済みのoss_providerを使用するか、LM StudioとOllamaのどちらかを選択するように促します。

--local-providerというコンパニオンフラグがあり、lmstudioまたはollamaを受け取り、1回の実行についてデフォルトを上書きします。フラグも設定デフォルトも設定しない場合、対話型CLIが選択を促します。非対話型codex execはプロンプトを表示せず、エラーで終了します。したがって、スクリプトやCIでは常にプロバイダーを明示的に設定してください。

表面的な正直な注記：ドキュメントは、CLIのconfig.tomlシステムの下でOSSモードとカスタムプロバイダーをカバーしています。IDE拡張機能とCodexクラウドがローカルプロバイダーをサポートしているとは、設定ドキュメントのどこにも記載されていません。[検証：Codex IDE拡張機能がCLIと同様にconfig.tomlからmodel_providersを読み取るかどうか。ドキュメントにはどちらの言及もありません。] OpenAIが別途ドキュメント化するまでは、これをCLIワークフローとして扱ってください。

なぜCodex内でオープンソースモデルを実行するのか

CodexがOpenAI独自のエージェントであるため、当然の疑問です。いくつか現実的な理由があります。

コスト管理。 Ollamaを通じたローカル推論は、トークンあたり無料です。長時間のエージェントセッションで利用制限を使い果たしている場合、ローカルモデルは単純な作業を処理し、難しい問題のためにホストされた呼び出しを節約できます。
プライバシーとエアギャップ作業。 一部のコードベースはマシンから持ち出すことができません。ローカルのKimi、GLM、またはgpt-ossモデルは、すべてのトークンをハードウェア上に保持します。Kimi K3をローカルで実行するためのガイドでは、そのための実践的な方法を説明しています。
モデルの好み。 オープンウェイトモデルは、コーディングのギャップのほとんどを埋めてきました。DeepSeekとQwenのホストされたAPIはOpenAIの料金を下回り、コーディングベンチマークでは同等のスコアを出すことができ、単純に特定のモデルのコード作成方法を気に入っているかもしれません。
1つのエージェントハーネス、多くのモデル。 CodexのターミナルUX、サンドボックス、承認フローは優れています。プロバイダー設定により、そのハーネスを維持し、頭脳を交換できます。

設定の場所

CodexはCODEX_HOME（デフォルトは~/.codex）の下に状態を保存します。ユーザーレベルの設定は~/.codex/config.tomlで、リポジトリは.codex/config.tomlにプロジェクトレベルのオーバーライドを持つことができます。以下のすべては、これら2つのファイルのいずれかに記述されます。

クイックスタート：OllamaでCodexを使用する

Codexでオープンソースモデルを最も速く利用する方法はOllamaです。

ollama.comからOllamaをインストールし、起動します。Ollamaはポート11434でOpenAI互換APIを提供します。
モデルをプルします。OpenAI独自のオープンウェイトリリースが自然な最初の選択肢です。gpt-ossライブラリページには20bと120bのバリアントがあります。Ollamaを使ってgpt-ossを実行する方法でスタンドアロンのセットアップについて説明しました。

ollama pull gpt-oss:20b

CodexをOSSモードで実行し、モデル名を指定します。

codex --oss -m gpt-oss:20b

-m/--modelフラグは設定されたモデルを上書きし、--ossと組み合わせることで実行するローカルモデルを選択します。非対話型で使用する場合：

codex exec --oss --local-provider ollama -m gpt-oss:20b "add input validation to the signup route"

フラグを省略できるようにデフォルトに設定します。~/.codex/config.tomlに以下を記述します。

# `--oss`で使用されるデフォルトのローカルプロバイダー
oss_provider = "ollama" # または "lmstudio"

これがローカルモデルの機能のすべてです。APIキーもカスタムプロバイダーブロックも不要です。LM Studioも同様に機能します。アプリにモデルをロードし、そのローカルサーバーを起動し、codex --oss --local-provider lmstudioを実行します。サーバーのセットアップについてはlmstudio.aiを参照してください。

カスタムプロバイダー：Codexを任意の互換性のあるエンドポイントに接続する

OSSモードはOllamaとLM Studioをカバーしています。DeepSeekやQwenのホストされたAPI、プロキシ、LAN上のvLLMサーバーなど、その他すべてについては、Codexにはカスタムモデルプロバイダーがあります。ドキュメントでは、プロバイダーを「Codexがモデルに接続する方法（ベースURL、ワイヤーAPI、認証、およびオプションのHTTPヘッダー）」と定義しています。

公式ドキュメントのパターン：

model = "gpt-5.6-terra"
model_provider = "proxy"

[model_providers.proxy]
name = "OpenAI using LLM proxy"
base_url = "http://proxy.example.com"
env_key = "OPENAI_API_KEY"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"

[model_providers.mistral]
name = "Mistral"
base_url = "https://api.mistral.ai/v1"
env_key = "MISTRAL_API_KEY"

重要なキーは次のとおりです。

キー	機能
`model_provider`	Codexが使用するプロバイダーID (デフォルト: `openai`)
`model`	そのプロバイダーに送信されるモデル名
`name`	プロバイダーの表示名
`base_url`	APIベースURL
`env_key`	APIキーを保持する環境変数
`wire_api`	プロバイダーが使用するプロトコル
`query_params`	リクエストに追加される追加のクエリパラメーター
`http_headers` / `env_http_headers`	静的ヘッダー、または環境変数から埋められるヘッダー

プロバイダーごとのネットワークチューニングも利用可能です。request_max_retries (デフォルト4)、stream_max_retries (デフォルト5)、およびstream_idle_timeout_ms (デフォルト300000)です。遅いローカルハードウェアは、アイドルタイムアウトを長くすることで恩恵を受けます。なぜなら、ノートパソコン上の120bモデルは、トークン間でしばらく静かに待機することがあるからです。

ドキュメントが直接指摘している2つのルールがあります。まず、IDのopenai、ollama、lmstudioは予約されており、組み込みプロバイダーを上書きすることはできません。組み込みのOpenAIプロバイダーのベースURLを変更するには、[model_providers.openai]を作成する代わりにopenai_base_urlを設定します。次に、これがすべてを形作るのですが、設定リファレンスには、wire_apiについて「responsesが唯一サポートされている値であり、省略された場合のデフォルトです」と記載されています。

これは厳しい制約です。以前のCodexバージョンでは、Chat Completionsエンドポイントにwire_api = "chat"を受け入れていましたが、モデル概要ページには、Codexを「Chat CompletionsまたはResponses API」をサポートするプロバイダーに接続できるとまだ記載されています。リファレンスと概要が矛盾しています。[検証：現在のCLIリリースでwire_api = "chat"がまだ機能するかどうか。設定リファレンスはresponsesのみと述べていますが、モデルページはチャットも機能すると示唆しています。公開前にチャットのみのエンドポイントでテストしてください。] もしresponsesのみという制約が残るなら、プロバイダーはResponses APIエンドポイントが必要であり、ほとんどのOpenAI互換サーバーは現在これを公開していますが、一部のホストされたAPIはまだ公開していません。

モデルごとのレシピ

以下の各レシピは、設定ブロックと実行コマンドです。起動前にAPIキーの環境変数を設定してください。

DeepSeek (ホストされたAPI)

DeepSeekは、Codexのワイヤープロトコルがまさに求めるResponses APIのサポートを、V4 Flashベータ版と共に追加しました。この展開については、DeepSeek V4 Flash、Responses API、およびCodexで取り上げました。

model = "deepseek-chat"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

export DEEPSEEK_API_KEY="sk-..."
codex

現在のモデルIDについてはDeepSeek APIドキュメントを確認してください。[検証：DeepSeekがResponsesプロトコルアクセス用にドキュメント化している正確なbase_urlパス。/v1チャットパスとは異なる場合があります。]

Qwen (Model Studio経由でホスト)

AlibabaのModel Studio (DashScope)は、Qwen 3.8ファミリー向けにOpenAI互換モードを公開しています。この互換モードエンドポイントは、これまでChat Completions形式でした。[検証：DashScopeの互換モードが現在Responsesプロトコルを提供しているかどうか。提供していない場合、このレシピは上記のwire_api = "chat"の質問に依存します。]

model = "qwen3.8-max"
model_provider = "qwen"

[model_providers.qwen]
name = "Model Studio経由のQwen"
base_url = "https://dashscope-intl.aliyuncs.com/compatible-mode/v1"
env_key = "DASHSCOPE_API_KEY"

Qwen 3.8 APIガイドでは、ホストされたルートのキー、モデルID、料金について説明しています。

Kimi、GLM、その他のオープンウェイト (Ollama経由でローカル)

Ollamaにプルできるものはすべて、プロバイダーブロックなしで通常のOSSモードで動作します。

ollama pull <model>
codex --oss -m <model>

これにはGLMとQwenのオープンウェイトが含まれ、さらにハードウェアが耐えられるならKimi K3も含まれます（K3のウェイトはMXFP4で594 GBなので、ほとんどの人は試す前にローカルでKimi K3を実行するを読んでください）。中規模のマシンでは、gpt-oss:20bまたは量子化されたQwenコーダービルドが現実的な選択肢です。

セルフホスト型vLLMまたはLANサーバー

別のマシン上のvLLMまたは同様のOpenAI互換サーバーは、OSSモードではなくカスタムプロバイダーです。

model_provider = "lan_vllm"

[model_providers.lan_vllm]
name = "ワークステーション上のvLLM"
base_url = "http://192.168.1.50:8000/v1"
env_key = "VLLM_API_KEY"

プロファイル：タスクごとに頭脳を切り替える

一つの設定を選ぶ必要はありません。Codexプロファイルは、~/.codex/<profile-name>.config.tomlにある別のTOMLファイルで、--profileを渡すとベース設定の上に重ねて適用されます。ローカルモデルプロファイルは次のようになります。

# ~/.codex/oss-local.config.toml
oss_provider = "ollama"
model = "gpt-oss:20b"

codex --profile oss-local
codex exec --profile oss-local "write unit tests for utils/dates.ts"

難しいリファクタリングにはデフォルト設定をOpenAIモデルに保ち、リンターの修正、テストのスキャフォールディング、ドキュメントのパスには--profile oss-localを立ち上げてください。一時的なオーバーライドはプロファイルなしでも機能します：codex -c model='"deepseek-chat"' -c model_provider='"deepseek"'。

OpenAIモデルに対するトレードオフ

何をトレードオフしているのか、正直に認識しましょう。

能力。 gpt-oss:20bはgpt-5.6-terraではありません。ローカルモデルは、長い複数ファイルの編集で失敗することが多く、エージェントループはすべてのステップが前のステップの上に構築されるため、モデルの弱点を増幅させます。
速度。 ホストされたAPIは高速にストリーミングします。コンシューマーハードウェア上の大きなローカルモデルは、作業方法を変えるほど遅くなることがあります。
ツール連携の忠実度。 Codexのプロンプトとツール呼び出しは、OpenAIモデル用に調整されています。オープンソースモデルは、ツール呼び出しをいかに確実に生成するかで異なり、responsesオンリーのワイヤープロトコルは、どのエンドポイントがそもそも適格であるかを狭めます。
サポート範囲。 OSSモードはドキュメント化されたCLIパスですが、サードパーティプロバイダーは自己責任です。モデルID、レート制限、プロトコルの癖などは、あなたとベンダーの間の問題です。

実用的な使い分け：高頻度でリスクの低い作業にはローカルまたは安価なホストモデル、失敗した場合に午後の時間を失うようなタスクにはフロンティアモデルを使用します。

エージェントが触れるAPIを検証する

Codex内でどのモデルが実行されても、出力は通常、APIを呼び出すか定義するコードであり、オープンソースモデルはフロンティアモデルよりも頻繁にエンドポイントとスキーマを幻覚します。本番環境ではなく、API層でそれを捕捉してください。

Apidogは、ワークフローのその側面をカバーします。Apidog MCPサーバーをプロジェクトに接続すると、Codexエージェントはフィールド名をでっち上げる代わりに、コードを書きながら実際のAPI仕様を読み取ることができます。次に、Apidog CLIをCodex内で使用して、各変更後にエージェントがターミナルからテストシナリオを実行できるようにします。エージェントが編集し、テストし、あなたはパスする差分を確認するわけです。このループは、小規模なモデルがコードを作成する場合、より重要になります。Apidogをダウンロードして設定してください。CLIとMCPサーバーは、設定したどのモデルでも動作します。

トラブルシューティング

codex execがOSSモードですぐにエラーになる。 プロバイダーを設定していません。非対話型実行はプロンプトを表示しないため、--local-provider ollamaを渡すか、設定でoss_providerを設定してください。
ポート11434で接続拒否される。 Ollamaが実行されていないか、別のアドレスにバインドされています。アプリを起動するかollama serveを実行し、curl http://localhost:11434/v1/modelsで確認してください。
ホストされたプロバイダーからの404またはプロトコルエラー。 base_urlの形式が間違っているか、エンドポイントがResponsesプロトコルを話しません。ベンダーがResponses互換パスを文書化しているか確認してください。
認証失敗。 env_keyは環境変数名を指定します。Codexは起動時にシェル環境からキーを読み取ります。同じシェルでエクスポートし、launchdやCIシェルがドットファイルをロードしない場合があることを覚えておいてください。
遅いローカルモデルで生成中にストリームが停止する。 プロバイダーブロックでstream_idle_timeout_msとstream_max_retriesを増やしてください。
設定の編集が無視される。 プロジェクトレベルの.codex/config.tomlがユーザー設定を上書きしていないか確認し、プロファイルは両方の上に重ねて適用されることを覚えておいてください。

FAQ

Codex OSSモードはIDE拡張機能やCodexクラウドで動作しますか？

ドキュメントは、CLIの設定システムの一部としてOSSモードとカスタムプロバイダーを説明しています。IDEまたはクラウドでのローカルプロバイダーのサポートは文書化されていないため、これはCLI機能として扱ってください。[IDEサポートに頼る前に検証してください。]

CodexのOSSモードで最も効果的に機能するモデルはどれですか？

OllamaまたはLM Studioがハードウェア上で提供できるものなら何でも動作します。gpt-oss:20bは摩擦の少ないデフォルトです。強力なオープンウェイトのコーディングオプションには、Qwen 3.8ファミリーとGLMがあります。Kimi K3のような巨大モデルについては、まずローカルKimi K3ガイドでハードウェアの計算を確認してください。

OpenRouterまたは他のアグリゲーターをCodexで使用できますか？

互換性のあるエンドポイントを公開している任意のアグリゲーターは、[model_providers.<id>]パターンに適合します。base_urlとenv_keyを設定し、model_providerで選択します。問題はプロトコルです。設定リファレンスでは、responsesが唯一サポートされているwire_apiとして挙げられているため、アグリゲーターがResponses APIを提供していることを確認してください。

オープンソースモデルでCodexを実行するためにOpenAI APIキーが必要ですか？

ローカルのOllamaまたはLM Studioサーバーを使用するOSSモードではキーは不要です。カスタムホスト型プロバイダーは、独自のキーをenv_keyを通じて使用します。OpenAIのサービスに触れるものについては、通常通りCodex自体にサインインする必要があります。

タスクに合ったセットアップを実行してください。安価なループにはローカルのgpt-oss、低コストでホストされた速度が必要な場合はDeepSeekまたはQwen、そして問題が難しい場合はOpenAIのフロンティアモデルを使います。Codexの設定により、これら3つはフラグ1つで切り替え可能になり、API側でApidogが検証を処理することで、モデルはコミットメントではなく交換可能なパーツになります。