OpenAI Codex の大型アップデート：Ollama、LM Studio などのローカル大規模モデルに接続可能に

Thu, 18 Jun 2026 22:41:34 +0800

Codex CLI は OSS モードを通じて、ローカルまたはカスタムのモデルサービスに接続できるようになりました。開発者にとって、この意味は分かりやすいものです。すべてのタスクで OpenAI のデフォルトモデルを使う必要はなく、Codex を Ollama、LM Studio、OpenRouter、社内ゲートウェイ、あるいは自前で運用する OpenAI 互換の推論サービスに向けることができます。

この記事は CSDN/AtomGit コミュニティの記事をもとにしつつ、現在の OpenAI Codex manual で内容を確認したものです。特に注意したいのは、元記事にある一部の profile の書き方が古い形式だという点です。Codex 0.134.0 以降、profile は独立した ~/.codex/<profile-name>.config.toml ファイルになり、config.toml の [profiles.xxx] テーブルからは読み込まれません。

元記事：https://tianqi.csdn.net/6a33be7210ee7a33f27f7913.html

OSS モードが解決すること

Codex CLI は、プロジェクトを読み、コマンドを実行し、ファイルを編集し、コードレビューやデバッグに参加できる coding agent です。モデルは、その推論品質、速度、コスト、データ境界を決めます。

OSS モードを有効にすると、Codex は Ollama や LM Studio のようなローカルの「open source」provider に接続できます。より広く言えば、バックエンドが OpenAI の Responses API または Chat Completions API をサポートしていれば、カスタム provider 経由でも接続できます。

OSS モードを検討しやすい場面は次のとおりです。

ローカルハードウェアでモデルを動かし、コードが外へ出る機会を減らしたい；
軽いタスクをローカルモデルに任せてコストを下げたい；
Qwen、DeepSeek、Mistral、Llama など、複数のモデルを切り替えたい；
会社に統一されたモデルゲートウェイやプライベート推論サービスがある；
イントラネットや LAN 内で Codex を実行したい。

ただし境界は明確にしておく必要があります。モデルを接続できることと、体験が OpenAI の推奨モデルと同等になることは別です。ツール呼び出し、長いコンテキスト、コード編集の安定性、指示追従能力はモデルごとに大きく異なります。複雑なタスクには、より強いモデルの profile を残しておくのがおすすめです。

Codex CLI をインストールする

Codex CLI をまだインストールしていない場合は、公式インストールスクリプトを使えます。

`1`	`curl -fsSL https://chatgpt.com/codex/install.sh \| sh`

Windows ユーザーが WSL 内で使う場合も、WSL ターミナルで同じコマンドを実行し、その後に次を実行します。

codex

インストール後は、まずバージョンを確認します。

`1`	`codex --version`

古いバージョンを使っている場合は、先にアップグレードすることをおすすめします。OSS モード、provider 設定、profile の挙動はいずれも Codex のバージョンに依存し、古いチュートリアルの設定はすでに使えない場合があります。

`--oss` でローカル provider を起動する

最も簡単な入口は、起動時に --oss を付けることです。

`1`	`codex --oss`

公式ドキュメントでは、--oss を渡すと Codex は Ollama や LM Studio などのローカル open source provider 上で動作できる、と説明されています。--oss だけを渡した場合、Codex は設定内の oss_provider をデフォルトの OSS provider として使います。

~/.codex/config.toml でデフォルトのローカル provider を設定できます。

`1`	`oss_provider = "ollama" # または "lmstudio"`

以後は次のように起動します。

`1`	`codex --oss`

Codex は oss_provider が指すローカル provider で起動します。

デフォルトモデルと provider を設定する

Codex のユーザーレベル設定ファイルは次の場所にあります。

`1`	`~/.codex/config.toml`

CLI と IDE extension はこの設定を共有します。最もよく使う二つのフィールドは次のとおりです。

1
2

model = "your-model-name"
model_provider = "your-provider-id"

model はバックエンドに渡すモデル名です。model_provider は下で定義する provider を指します。provider は、リクエストをどこへ送るか、どの wire API を使うか、認証方式は何かを Codex に伝えます。

たとえば、ローカル Ollama 用の provider は次のように定義できます。

model = "qwen2.5-coder:32b"
model_provider = "local_ollama"

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

各フィールドの意味は次のとおりです。

model：モデル名。通常はバックエンド側で決まる；
model_provider：現在使う provider；
[model_providers.local_ollama]：カスタム provider の設定テーブル；
name：表示名；
base_url：モデルサービスの OpenAI 互換 API アドレス；
wire_api：プロトコル種別。一般的な値は responses または chat。

現在の Codex は Chat Completions 対応バックエンドにも向けられますが、公式 manual は Chat Completions サポートが deprecated 状態で、将来 Codex から削除されると明示しています。新しい設定では wire_api = "responses" を優先しましょう。

Ollama を接続する

Ollama はローカルでモデルを動かすのに向いています。まず Ollama がインストール済みで、モデルが pull 済みであり、サービスが実行中であることを確認します。

設定例：

model = "qwen2.5-coder:32b"
model_provider = "local_ollama"
oss_provider = "ollama"

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

その後、起動します。

`1`	`codex --oss`

起動時に一時的にモデルを指定したい場合は、-m も使えます。

`1`	`codex --oss -m qwen2.5-coder:32b`

トラブルシュートでは、まず三つを確認します。

Ollama サービスが実行中か；
base_url に /v1 が付いているか；
model が Ollama で実際に利用できるモデル名か。

LM Studio を接続する

LM Studio もローカルの OpenAI 互換インターフェースを提供できます。一般的なアドレスは次のとおりです。

`1`	`http://localhost:1234/v1`

設定は次のように書けます。

model = "local-model"
model_provider = "lmstudio_local"
oss_provider = "lmstudio"

[model_providers.lmstudio_local]
name = "LM Studio"
base_url = "http://localhost:1234/v1"
wire_api = "responses"

ここでの model は、LM Studio が現在公開しているモデル名と一致している必要があります。LM Studio が Chat Completions 互換インターフェースしか公開していない場合に限り、wire_api を次のように変更することを検討します。

`1`	`wire_api = "chat"`

ただしこれは互換性のための回避策に近く、新しい設定のデフォルトとしてはおすすめしません。

OpenRouter または他のクラウドゲートウェイを接続する

クラウドゲートウェイ経由で複数のモデルにアクセスしたい場合は、リモート provider を定義できます。OpenRouter 風の OpenAI 互換ゲートウェイを例にすると、次のようになります。

model = "anthropic/claude-sonnet-4-20250514"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
wire_api = "responses"
experimental_bearer_token = "sk-or-v1-your-key"

秘密鍵を設定ファイルに書きたくない場合は、環境変数を使うか、チームのセキュリティ規約に従って token を注入する方法をおすすめします。秘密鍵はリポジトリにコミットすべきではなく、プロジェクトレベルの .codex/config.toml にも書かないでください。

自前の OpenAI 互換サービスを接続する

LAN やサーバー上に vLLM、SGLang、TGI、または社内モデルゲートウェイをデプロイしている場合、Codex をそのサービスに向けることができます。

model = "my-custom-model"
model_provider = "self_hosted"

[model_providers.self_hosted]
name = "Self Hosted"
base_url = "http://192.168.1.100:8080/v1"
wire_api = "responses"
experimental_bearer_token = "local-dev-key"

この種の設定で最も問題になりやすいのはプロトコル互換性です。バックエンドが OpenAI compatible を名乗っていても、Responses API のすべてのフィールド、ストリーミング出力、ツール呼び出し、エラー形式まで完全に互換とは限りません。大規模なコード変更を任せる前に、小さなタスクで検証しましょう。

profile を正しく使う：`[profiles.xxx]` はもう書かない

古いチュートリアルでは、次のような書き方をよく見かけます。

[profiles.fast-coder]
model = "qwen2.5-coder:7b"
model_provider = "ollama"
model_reasoning_effort = "low"

現在はこの形式を使わないでください。公式 manual は、Codex 0.134.0 以降、--profile は config.toml 内の [profiles.profile-name] を読まず、トップレベルの profile = "profile-name" セレクターもサポートしないと明記しています。

新しい書き方では、profile ごとに独立したファイルを作ります。

`1`	`~/.codex/fast-coder.config.toml`

ファイル内ではトップレベル設定項目を使います。

model = "qwen2.5-coder:7b"
model_provider = "local_ollama"
model_reasoning_effort = "low"

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

起動時に profile を選択します。

`1`	`codex --profile fast-coder`

複雑なタスク用の profile も作れます。

`1`	`~/.codex/deep-review.config.toml`

例：

1
2
3

model = "gpt-5.5"
model_provider = "openai"
model_reasoning_effort = "high"

起動：

`1`	`codex --profile deep-review`

こうすると、日常的な小さな修正、複雑なアーキテクチャ設計、ローカルのオフライン作業、クラウドの強力なモデルを使う作業を分けて管理できます。

プロジェクトレベル設定に provider の認証情報を置かない

Codex はプロジェクトレベルの .codex/config.toml をサポートしていますが、provider、認証、profile 選択のような設定はユーザーレベルの設定に置くほうが適しています。公式 manual でも、プロジェクトローカル設定は認証情報のリダイレクト、provider auth の変更、profile 選択などの機密設定を上書きできないと説明されています。Codex はこれらのキーを見ると無視し、起動時に警告します。

簡単に整理すると次のとおりです。

ユーザーレベルの ~/.codex/config.toml：モデル provider、認証方式、個人のデフォルトモデル；
profile ファイル ~/.codex/<name>.config.toml：タスクモードごとの差分設定；
プロジェクトレベルの .codex/config.toml：プロジェクト関連で、リポジトリ共有に適した非機密設定；
秘密鍵：環境変数、システム認証情報、またはチーム管理の注入方式を優先する。

OSS モードを使う前のチェックリスト

開始前に、次の順序で確認できます。

codex --version で十分新しいバージョンか確認する；
Ollama や LM Studio など、ローカルモデルサービスが起動している；
モデルがダウンロード済み、またはサーバー側で利用可能；
base_url が正しく、通常は /v1 を含む；
wire_api は responses を優先する；
provider ID が予約名を使っていない；
API Key がリポジトリに書かれていない；
小さなタスクでツール呼び出し、ファイル編集、コマンド実行を検証する；
複雑なタスク用に強いモデルの profile を残しておく。

結論

Codex CLI の OSS モードにより、モデル選択はより柔軟になります。軽いタスクはローカルモデルに任せ、機密性の高いコードはできるだけローカルマシンやイントラネットに留め、複雑なタスクではより強いモデルへ切り替えられます。本当に注意すべきなのは、設定形式とモデル能力の境界です。

すばやく試したいだけなら、まず次を実行します。

1
2

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --oss

長期的に使うなら、早めに ~/.codex/config.toml といくつかの独立した profile ファイルを整理し、ローカルモデル、クラウドゲートウェイ、強モデルのレビュー用モードを分けておくとよいでしょう。そうすれば Codex は「任意のモデルに接続できる」だけでなく、開発シーンごとに適切なモデルを選べるようになります。

Codex CLI on KnightLiブログ