Codex CLI でローカル LLM を動かす設定と gpt-oss 手順

Codex でローカル LLM を動かすとは — クラウドに送らず手元で完結

Codex は依頼を受けると、モデル自身がファイルを読み書きし、コマンドを走らせ、長い作業を自律的に進めるエージェント型のツールだ。その判断を担う推論モデルは、既定ではクラウド上の OpenAI モデルが使われる。ローカル LLM を動かすとは、この推論部分だけを手元の PC で走るモデルへ差し替える操作を指す。コードや依頼の内容がクラウドの API に送られず、マシンの中で処理が完結するため、社外に出せないリポジトリを扱う場面や、ネットワークが使えない環境での作業、あるいは利用量に応じた課金を避けたい場面で意味を持つ。逆に言えば、エージェントとしての振る舞い——ファイルを編集し、テストを走らせ、差分を積み上げていく流れ——そのものは変わらない。Codex CLI はモデルの接続先を抽象化して扱うため、賢いクラウドモデルを呼ぶか、手元の gpt-oss を呼ぶかは設定の一行で切り替わる。つまりローカル化は別物のツールへ乗り換える話ではなく、同じ Codex の土台だけを入れ替える話だと捉えると見通しがよい(出典: https://developers.openai.com/codex/config-advanced)。

--oss フラグと model_providers の二つの入り口

接続のやり方は性格の異なる二つに分かれる。一つは --oss フラグで、codex --oss と起動するだけで既定のローカルプロバイダへつなぐ手早い入り口だ。既定の送信先は config.toml の oss_provider で "ollama" か "lmstudio" を選んで決める。もう一つは model_providers を自分で定義する方法で、接続先の名前と base_url を書いて、どのエンドポイントへつなぐかを明示する。試しに動かすなら前者、日常的に使うなら後者を固定しておく、という住み分けが自然だ。なお独自プロバイダの ID には openai / ollama / lmstudio という予約名は使えないため、local_ollama のような別名を付ける必要がある(出典: https://developers.openai.com/codex/config-advanced)。

事前準備 — Ollama と gpt-oss モデルの用意

ローカルで推論を走らせるには、まずモデルを配信・実行する基盤を手元に置く必要がある。最も案内が整っているのは Ollama を使う構成で、Ollama がローカルに HTTP のエンドポイントを立て、そこへ Codex がつなぐ形になる。土台のモデルには OpenAI が公開したオープンウェイトの gpt-oss が扱いやすく、Ollama の Codex 連携ページでは gpt-oss:20b と gpt-oss:120b の二種類が示されている。20b は要求リソースが軽く、120b は応答の品質で勝るという関係で、まずは手元のマシンの余力に合わせて選ぶとよい。準備の流れは次のとおりだ。

1. Ollama を PC にインストールし、ローカルサービスを起動する(既定で http://localhost:11434 で待ち受ける)。
2. 使うモデルを取得する。軽さ優先なら ollama pull gpt-oss:20b、品質優先なら ollama pull gpt-oss:120b を実行する。
3. Codex CLI を最新版へ更新し、ローカル接続に対応したバージョンになっていることを確認する。
4. Codex はエージェント用途で長い文脈を読むため、コンテキストウィンドウを最低 64k トークン確保しておく。

このうち 4 点目は見落としやすい。コンテキストが短いと、リポジトリの読み込みや長い作業の途中で文脈が切れ、エージェントとしての挙動が安定しないことがあるためだ(出典: https://docs.ollama.com/integrations/codex)。

config.toml でローカルプロバイダを設定する

恒常的に使うなら、--oss の手早さよりも ~/.codex/config.toml への記述で接続先を固定するほうが扱いやすい。設定は、どのプロバイダを使うかを示す model_provider と、そのプロバイダの接続情報を書く model_providers.<id> の組で成り立つ。Ollama へつなぐ最小の例は次のようになる。

model_provider = "local_ollama"

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

base_url はモデルを実行している基盤のエンドポイントで、Ollama の既定ならこの値で届く。model キーに gpt-oss:120b のように使うモデル名を併記しておけば、起動時の指定を省ける。手早く試した --oss の挙動を、そのまま設定ファイルへ写し取って既定化するイメージだ。前述のとおり、独自プロバイダの ID に openai / ollama / lmstudio の予約名は使えないため、local_ollama のような任意の名前を付ける点だけ守ればよい(出典: https://developers.openai.com/codex/config-advanced)。

プロファイルで切り替える

クラウドモデルとローカルモデルを行き来したいなら、プロファイルを分けておくと切り替えが一手で済む。設定をプロファイル単位に分け、起動時に codex --profile <名前> で読み込ませる方式だ。たとえばローカル用のプロファイルに oss_provider と model を書いておけば、codex --profile local で手元のモデルへ、無指定ならクラウドへ、と使い分けられる。Ollama 公式の案内でも、model_provider を指定したプロファイルを用意し codex --profile ollama-launch で起動する手順や、その場限りで動かす codex --oss -m gpt-oss:120b という書き方が示されている。日常はクラウド、機密案件だけローカル、という運用を一つの環境の中で無理なく回せる(出典: https://docs.ollama.com/integrations/codex)。

承認ポリシーとサンドボックスはモデルと独立

ローカル化でつまずきやすいのが、安全面の設定を「モデルを手元に移したから不要」と誤解する点だ。推論をローカルへ移しても、Codex がファイルを書き換えたりコマンドを実行したりする際にどこまで人の承認を求めるか、どの範囲の操作を許すかは、モデルの動く場所とは別の軸で決まる。公式ドキュメントも、承認ポリシーとサンドボックスのモードは推論がどこで走るかとは独立して働くと説明しており、ローカル接続の設定はこれらを上書きしない。したがってローカル LLM を入れても、approval_policy でコマンド実行時の確認をどう扱うか、sandbox_mode で書き込みやネットワークをどこまで許すかは、従来どおり基底の config.toml で整える必要がある。ローカル化はあくまで推論の送信先を手元へ変える操作であって、エージェントの実行権限を絞る操作ではない。送信先と実行権限は別物だと切り分けて設定すれば、ローカルでも安全側に倒した運用を保てる(出典: https://developers.openai.com/codex/config-advanced)。

ローカル LLM が向く場面・向かない場面

最後に、どこでローカル構成を選ぶべきかを整理しておく。向くのは、外部に送れないコードを扱う案件、ネットワークが不安定または使えない環境、そしてクラウド利用量の上限や課金を気にせず試行回数を稼ぎたい場面だ。推論が手元で完結するため、送信先を理由に手が止まることがなくなる。一方で割り切りも要る。手元の PC で動かす gpt-oss は、クラウドの最新世代の Codex 専用モデルと比べると、込み入った設計判断や長い自律作業での粘り強さで差が出ることがある。とりわけ軽い 20b を選んだ場合は、難所では応答が浅くなりやすい。実務では、込み入ったタスクや仕上げはクラウドモデルへ、機密性が高い読み書きやオフラインでの下書きはローカルへ、とプロファイルで割り振るのが現実的だ。ローカルかクラウドかを二者択一にせず、案件の機密性と難易度の二軸で使い分ければ、Codex の同じ操作感のまま、送信先を状況に合わせて選べるようになる(出典: https://developers.openai.com/codex/config-advanced)。