CLIコーディングの流行と「ローカルでもできるの？」問題
ここ最近、「ターミナルから直接AIにコードを書かせる」というスタイルがちょっとしたブームになっています。
Charmbracelet が出している Crush（旧OpenCode）や、VS Code 連携で人気の Cursor、そしてもちろん GitHub Copilot。
エディタやブラウザを介さず、CLIでAIに「ファイルを生成・修正」させる体験は、エンジニア心をくすぐります。
一方で、こうしたツールの多くは クラウドのLLM依存。
「ChatGPT API」や「Anthropic Claude」など外部サービスが必須で、オフラインや閉じた環境では使えません。
でも思いませんか？
「これ、ローカルLLMでもできたら面白いんじゃない？」
GPUさえあれば Hugging Face や LM Studio でモデルを走らせられる時代です。
ならば「エディタに頼らず、ターミナルからAIに指示を飛ばし、本当にファイルを書き換えさせる」ことができるのか？
今回、その実験として LM Studio 上の gpt-oss モデル × Codex CLI を組み合わせて試してみました。
Crush も触ってはみましたが、こちらは残念ながら安定性に欠けたため、本命は「Codexごっこ」。
というわけで、本記事は「ローカル環境で Codex を再現してみた記録」です。
花火は打ち上がったのか、パドルは動いたのか――結果をどうぞ。
Codexとは何者か
「Codex」という名前を聞いて「懐かしい」と感じる方もいるかもしれません。
これはもともと OpenAIが開発した「コード特化LLM」 で、2021年に発表されました。
GitHub Copilot の初期バージョンに組み込まれていたモデルとして有名で、当時は「自然言語でコメントするとコードが出てくる」体験が大きな話題になりました。
やがて OpenAI は Codex を GPT 系の統合ラインに吸収し、現在では単独のAPIとしては提供されていません。
しかし、「CLIからAIにコードを書かせる」「ローカルファイルを直接編集させる」というスタイルは残り、オープンソースの Codex CLI として受け継がれています。
この Codex CLI の特徴は、ChatGPTのようにテキストを返すだけではなく、実際にファイルを新規作成・編集・削除するところにあります。
つまり「AIが本当に手を動かす」感覚を味わえるのです。
今回はこの Codex CLI を活用し、クラウドAPIの代わりに ローカルの gpt-oss モデル を組み合わせました。
モデルのサービングには LM Studio を利用し、ターミナルから「Codexごっこ」をしてみよう、というのが本記事の趣旨です。
今回の構成
今回の実験は、クラウド依存を避けて すべてローカル完結で進めました。
使ったのは次の3つです。
1. LM Studio
ローカルで大規模言語モデルを簡単に動かせるフロントエンド。
GUIからモデルをダウンロード・起動でき、サーバーモードを有効にすると OpenAI互換API（http://localhost:1234/v1） を提供してくれます。
→ 実際のアプリからは「ChatGPT APIっぽい」インターフェースで叩けるわけです。
2. gpt-oss
OpenAI が公開しているオープンソースモデル。
今回は gpt-oss-20b を LM Studio 経由で動かしました。
規模としては十分大きいですが、クラウドモデル（GPT-4o や Claude など）と比べるとまだ重く、RTX3060 ではかなり動作が厳しい印象でした。
3. Codex CLI
ターミナルで動くコーディングアシスタント。
ユーザーが自然言語で指示すると、対象のディレクトリ内にファイルを新規作成・編集・削除します。
ChatGPTや私（アシスタント）のように「コード片をテキストで返す」だけでなく、リアルにファイルを触るのが最大の特徴です。
接続イメージ
[ Codex CLI ]
↓（OpenAI API互換）
[ LM Studio サーバー ]
↓
[ gpt-oss モデル ]Codex CLI にとっては「普通の OpenAI API」を呼んでいるだけ。
バックエンドがクラウドではなくローカルの gpt-oss に差し替わっている、という構図です。
試行錯誤：Crushは失敗
実は最初から Codex CLI を使ったわけではありません。
同じく Charmbracelet が公開している Crush（旧 OpenCode）も気になり、こちらを先に試しました。
Crush は「ターミナル上で AI と対話しながらコードを書かせる」ことを売りにした新しいツールです。
見た目も Charmbracelet らしい華やかなUIで、ちょうど Codex 的な CLI コーディング体験ができるのでは？と期待していました。
ところが実際にインストールして動かすと、以下のような問題が次々と発生：
- 設定ファイルのエンコード不具合で 起動エラー
- プロンプトを投げても 紫文字の制御コードが乱舞
- LM Studio 側にリクエストが飛ばず、モデルがまったく応答しない
さらに GitHub の Issue を見ても、LM Studio / Ollama と組み合わせた利用は未成熟という声が多く、実用はまだ難しそうな印象でした。
そのため本記事では Crush は早々に諦め、Codex CLI に切り替えることにしました。
結果的にはこちらの方がシンプルで、ローカル LLM とも素直に繋がりました。
Codex CLIでローカル gpt-oss を動かす
気を取り直して、今度は Codex CLI を導入。
こちらは比較的シンプルで、手順も少なく済みました。
インストール
npm i -g @openai/codex
codex --version # 例: codex-cli 0.22.0インストールが終わったらバージョン確認：
codex --version
# 例: codex-cli 0.22.0これが表示されればOKです。
初回起動時の挙動
最初に Codex を立ち上げると、カレントディレクトリでのファイル操作に関する確認が入ります。
> 1. Allow Codex to work in this folder without asking for approval
2. Require approval of edits and commands普段使う作業ディレクトリなら 1番 を選んでおくと快適ですが、安全を優先するなら 2番 で逐一確認させる運用もアリです。
Codex起動直後の画面
なんか、GeminiとかClaudeとかと比べると地味な感じ。
LM Studio との接続設定
Codex CLI は OpenAI API互換 のエンドポイントを参照します。
設定ファイル（%USERPROFILE%\.codex\config.toml）に以下を記述すれば、LM Studio で立てた gpt-oss に接続できます。
model = "openai/gpt-oss-20b"
model_provider = "lmstudio"
[model_providers.lmstudio]
name = "LM Studio"
base_url = "http://localhost:1234/v1"
# 認証不要なので env_key は省略可手作業でも編集できますが、PowerShell なら以下を一発で書き込めます。
# Codex の設定ディレクトリへ移動
cd "$env:USERPROFILE\.codex"
# 設定ファイルを一発で書き込み
@"
model = "openai/gpt-oss-20b"
model_provider = "lmstudio"
[model_providers.lmstudio]
name = "LM Studio"
base_url = "http://localhost:1234/v1"
"@ | Out-File -Encoding utf8 "$HOME\.codex\config.toml"これで %USERPROFILE%\.codex\config.toml に必要な設定が入ります。
これで Codex 側から「ChatGPT APIを呼ぶ」つもりでアクセスすると、
実際には ローカルで動いている gpt-oss が応答してくれる、というわけです。
接続テスト
試しに以下のように入力すると──
user
Say 'Hello from gpt-oss local via config'Codex がきちんと応答しました。
codex
Hello from gpt-oss local via config
ここまで来れば接続成功。
準備は整ったので、いよいよ実際にコードを書かせてみます。
実験：Codexにコードを書かせてみる
ここからが本題。Codex CLI に実際のコードを書かせ、本当にファイルが生成されるのかを試しました。
6-1 花火JS（成功）
まずは派手さ重視で「花火アニメーション」をお願いしました。
プロンプトはシンプルに以下だけ：
codex "Create fireworks.html with a colorful fireworks animation using JavaScript and canvas."すると数十行の HTML+JavaScript が生成され、fireworks.html がカレントディレクトリに出現。
ブラウザで開くと黒背景にカラフルな花火が打ち上がり、華やかに弾ける──
最初の試みとしては大成功でした。
ちなみに日本語で「花火のコードを書いて」と投げても通りました。
Codex CLI 側は入力をそのままモデルに流すので、gpt-oss が理解できる言語なら日本語でも問題ありません。
6-2 ブロック崩しJS（未完成）
次に「遊べるもの」を狙って、ブロック崩しを作成してみました。
codex "Create breakout.html with a simple breakout game using canvas and JavaScript in about 50 lines."生成結果は確かにゲームらしい画面が出てきました。
ボールもブロックも描画され、雰囲気はブロック崩しそのもの。
しかし、残念ながら パドルが動かない。
矢印キーでもマウスでも反応せず、ゲームとしては成り立ちません。
さらに修正を依頼してみました：
codex "Modify breakout.html so the paddle follows the mouse X and responds to arrow keys. Bounce angle depends on hit position."ところが期待通りには直らず、挙動は改善しませんでした。
どうやら Codex の「差分パッチ適用」がうまくいかず、また コンテキスト長の制約（12kに設定） によって会話が途切れてしまうケースも確認。
つまり、生成はできても修正までは難しいというのが今回の結果です。
学びと限界
今回、Codex CLI と gpt-oss を組み合わせてローカルで試してみて、動いた喜びと同時に、限界も強く実感しました。
RTX 3060 では遅い
テスト環境は RTX 3060 でしたが、モデルサイズが大きいせいで処理は重く、応答までにかなり時間がかかりました。
実用レベルで快適に回すには、やはり RTX 5090 クラスのGPUが欲しくなるところです。
コンテキスト長はすぐに枯れる
gpt-oss は 最大128K（=131,072）トークンのコンテキストに対応（OpenAI公称）。LM Studio では“131k”として表示されます。しかし LM Studio の設定を 12k(経験則による限界) にしていたこともあり、コード生成や修正を何度か繰り返すと あっという間に上限に到達。
「context overflow」で生成が中断することもありました。
クラウドAIに慣れた身体には、絶望的に狭いコンテキストです..。
→ 対策としては：
- 履歴を切る：Codexを終了して新しい会話にする
- diffオンリー出力を強制：全文ではなく差分だけを返させる
- 作業を分割：大きな修正を小出しにする
- 長コンテキスト対応モデルに切り替える：Gemma 3n や Mistral Large 32k 版をLM Studioに読み込む
といった工夫が必要です。
文字化けやUIの不安定さ
Codex CLI の出力が Windows の PowerShell 上で文字化け（ANSI制御コードのカラフルなゴミが表示される）することもありました。
Windows Terminal で UTF-8 に設定すれば改善しますが、CLIとしての安定性は「まだ荒削り」という印象です。
実用性は限定的
率直に言えば、実務で使うならクラウドのGPTやGeminiの方が圧倒的に速く安定しています。
Gemini 2.5 が「ほぼ無料」で利用できる今、ローカル LLM であえて Codex CLI を動かす意味は限られます。
それでも価値はある？
ここまで見てきたように、ローカル Codex × gpt-oss には速度や安定性の面で限界があります。
実務で「とにかく速く・確実に」コードを書かせたいなら、正直 ChatGPT や Gemini、Claude などクラウドLLMの方が圧倒的に実用的です。
それでも、ローカル Codex にはクラウドにはない独自の価値がありました。
実ファイルを直接操作する体験
ChatGPT のような通常の対話AIは「コード片」を返すだけです。
一方 Codex CLI は本当にファイルを生成・修正・削除する。
「100個のテスト用ファイルを作って」→実際にファイルシステムに並ぶ、この体験はローカルならではです。
オフライン・クローズド環境で使える
社内システムや研究データのように「クラウドに出せないコードベース」を相手にする場面。
ここでは ローカルで動くLLM＋Codex CLI が唯一の選択肢になります。
研究・教材としての価値
Codex CLI のログは「AIがどうコードを提案し、どう直したか」の履歴そのもの。
AIエージェントの実験や、教育用教材としてのサンプルに使うには絶好です。
体験として面白い
「AIが自分の手元のディレクトリで、本当にファイルをゴリゴリ改変していく」
──この光景自体がエンジニアにとっては楽しい体験。
うまく動いても、動かなくても、それを含めて「遊べる」のが魅力です。
まとめ
今回、Codex CLI × LM Studio × gpt-oss という組み合わせで「ローカルでCodexごっこ」をしてみました。
結果としては：
- 花火JS → ちゃんと動いて大成功 🎆
- ブロック崩しJS → 一応生成されたがパドルが動かず、修正依頼も不発
- Crush → まだ不安定で実用は難しい
と、成功と失敗の両方を体験できました。
学びとしては：
- RTX3060では遅すぎる、実用にはハイエンドGPUが必要
- コンテキスト長（今回は12k設定）がすぐ枯れるので工夫が要る
- クラウドモデル（ChatGPT / Gemini / Claude）と比べると、速さ・精度・安定性で大きな差
──と、正直「実務に投入する意味は薄い」というのが本音です。
しかし一方で：
- ローカルでファイルを直接生成・改変する体験
- オフラインやクローズド環境で使える強み
- 研究や教材として“AIがコードを書く挙動”を観察できる面白さ
といったクラウドにはない価値も見つかりました。
結論
「普段の開発ならクラウドLLM。遊び・研究ならローカルCodex。」
AIが勝手にファイルを作り、修正し、時にはバグらせる──
その過程を手元で体験できるのは、やはりユニークでワクワクするものでした。
参考リンク集
本文中で触れたツールやモデルへの公式リンクをまとめておきます。
気になった方はぜひ触ってみてください。
- Codex CLI（今回の主役）
https://github.com/openai/codex - gpt-oss（OpenAI公開のオープンソースモデル）
openai/gpt-oss-20b · Hugging Face - LM Studio（ローカルでLLMを動かせるGUIフロントエンド）
https://lmstudio.ai/ - Crush（Charmbracelet製CLIアシスタント。未だ不安定）
https://github.com/charmbracelet/crush
