AIツール

Ollama が Codex App に接続：ローカル LLM はどう AI コーディング Agent になるのか

Ollama Launch の Codex App 対応を解説します。ollama launch codex-app により、Codex App をローカルまたはクラウドモデルへ接続し、ローカル LLM をチャットツールから AI コーディング Agent ワークフローへ進められます。

Ollama は、ローカル LLM と AI コーディングツールの距離をさらに縮めました。ollama launch codex-app により、Codex App を Ollama が管理するローカルまたはクラウドモデルへ接続できます。

これは単に「モデルバックエンドを変える」だけではありません。ローカル LLM をチャット画面から開発ワークフローへ押し出す動きです。モデルは質問に答えるだけでなく、コードプロジェクトに入り、ファイル構造を理解し、コード修正を支援し、タスクを実行し、AI コーディング Agent の一部になります。

まず確認：OpenAI の全機能が永久無料になったわけではない

ネット上では、この話を「Codex が無料になった」とまとめる言い方もあります。しかし、それは誤解を招きやすい表現です。

より正確には次のように理解できます。

  • Codex App は OpenAI の AI コーディングツール；
  • Ollama Launch は Codex App が Ollama モデルを使うための設定を支援する；
  • モデルはローカルモデルでも Ollama のクラウドモデルでもよい；
  • ローカルモデルを使う場合、推論コストは API token 課金ではなく、自分のハードウェア、電気代、時間になる；
  • Codex App、OpenAI アカウント権限、モデル利用可否、公式制限は、引き続き OpenAI と Ollama の現在のルールに従う。

つまり「Codex の全能力が永久無料」という話ではなく、AI コーディング Agent が OpenAI API、Claude API、Gemini API に完全依存しないためのローカルルートが増えた、ということです。

ollama launch codex-app は何をするのか

Ollama の公式ドキュメントでは、Codex App 連携のコマンドはシンプルです。

1

ollama launch codex-app

モデルを指定したい場合は次のように書けます。

1

ollama launch codex-app --model gpt-oss:120b

すぐ起動せず、設定だけ生成することもできます。

1

ollama launch codex-app --config

元の Codex 設定に戻したい場合：

1

ollama launch codex-app --restore

価値は、手動設定の手間を減らすことです。これまでは AI コーディングツールをローカルモデルへ接続するために、環境変数、OpenAI-compatible endpoint、config.toml、モデル名、profile を自分で編集することがよくありました。Ollama Launch はその手順をより直接的な流れにまとめています。

なぜローカルモデルの Agent 接続が重要なのか

以前のローカル LLM の主な用途はチャットでした。

  • 短い文章を書く；
  • 質問に答える；
  • コード片を説明する；
  • 簡単な補完をする；
  • ドキュメントを要約する。

これらは有用ですが、まだ「質問応答ツール」の段階です。

AI コーディング Agent の違いは、実際のプロジェクトを相手にすることです。ディレクトリを読み、ファイルを確認し、エラーを理解し、コードを修正し、コマンドを実行し、結果を検査して、さらに反復します。つまり、答えを出すだけではなく、タスク実行に参加します。

ローカルモデルが Codex App、Claude Code、OpenCode、Aider、OpenHands のようなツールへ接続されると、ローカル AI の役割は変わります。

  • プロジェクト構造をスキャンできる；
  • Bug を特定できる；
  • ファイルを変更できる；
  • 新しいページや小さなゲームを生成できる；
  • コードを説明しリファクタリングできる；
  • 開発ループの中で実行、検証、修正を繰り返せる。

これは、ローカル LLM が「会話できる」状態から「作業できる」状態へ進む重要な一歩です。

ローカル Agent の利点

1. コストを制御しやすい

大規模プロジェクトは大量の token を消費しがちです。プロジェクト全体のスキャン、長いコンテキスト分析、複数回の修正ループをクラウドモデルで行うと、費用がすぐ積み上がることがあります。

ローカルモデルにも GPU、メモリ、電気代、時間といったコストはあります。しかし token 単位で直接課金されません。大量の試行錯誤、個人プロジェクト、オフライン実験には、ローカルルートの方がじっくり試しやすいです。

2. オフラインでも作業できる

モデル、ツール、依存関係がすでにローカルに準備されていれば、ローカル Agent は多くの場面でネットワークなしでも作業を続けられます。ローカルコードを読み、プロジェクトを分析し、ファイルを変更し、ページやスクリプトを生成できます。

もちろん、Web 検索、依存関係のダウンロード、オンライン API へのアクセスが必要なタスクにはネットワークが必要です。それでも、基本的なコード分析やローカルプロジェクト修正は、必ずしもクラウドモデルに依存しません。

3. プライバシー境界が明確になる

多くのコードベース、社内文書、実験プロジェクトは、そのままクラウドモデルへ送るのに向いていません。モデルをローカルに置けば、コード内容がマシン外へ出る機会を減らせます。

ただし、ローカルだから自動的に安全というわけではありません。Agent はコマンド実行、ファイル編集、機密パスへのアクセスを行う可能性があるため、権限、サンドボックス、Git diff review は引き続き重要です。それでもモデル推論レイヤーでは、ローカル化によりユーザーの制御は増えます。

どのモデルを選ぶべきか

Ollama の公式 ollama launch ドキュメントでは、コード系ツールには大きめのコンテキストウィンドウ、少なくとも 64K tokens が推奨されています。AI コーディングタスクでは、プロジェクト構造、複数ファイル、エラーログ、要求仕様、過去の変更を同時に読む必要があるからです。

ローカルモデルでは次の方向を試せます。

  • qwen3-coder：コードタスク寄り；
  • gpt-oss:20b：ローカル実験向け；
  • glm-4.7-flash：Ollama が推奨する coding モデルの一つ；
  • より大きなクラウドモデル：ローカルハードウェアが足りない場合、Ollama cloud モデルでより完全なコンテキストを得る。

中国語シナリオでは、Qwen 系列は引き続き優先的に試す価値があります。中国語理解、コード生成、推論、ローカルエコシステム対応が比較的成熟しています。

ハードウェア要件は思ったほど高くない

AI Agent と聞くと、RTX 4090、24GB VRAM、あるいは企業向け GPU が必要だと考える人も多いです。

実際はもっと柔軟です。小型モデル、量子化モデル、MoE モデル、KV cache 量子化、CPU/GPU mixed offload により、6GB、8GB、12GB VRAM のマシンでもかなりのことができます。

もちろん、低 VRAM マシンで最高の体験は期待しにくいです。

  • 速度は遅くなる；
  • コンテキストは大きくできない；
  • 大規模プロジェクトのスキャンは重い；
  • 複数同時実行は現実的でない；
  • モデル品質は 100B+ クラウドモデルにはまだ及ばない。

それでも、個人プロジェクト、スクリプト修正、簡単なフロントエンドページ、小さなゲーム、コード説明、オフライン実験が目的なら、ローカルモデルはすでに「使える」段階に入っています。

llama.cpp で OpenAI-compatible API に接続する方法もある

Ollama 以外にも、llama.cpp の llama-server でローカル OpenAI-compatible API を提供し、AI コーディングツールをローカルポートへ接続する方法があります。

典型的な llama.cpp 起動コマンドは次のような形です。

1
2
3
4
5
6
7
8
9

llama-server.exe ^
 -m "models\Qwen3.6-27B-UD-Q5_K_XL.gguf" ^
 -ngl 999 ^
 -c 16384 ^
 -n 2048 ^
 -fa on ^
 --jinja ^
 --host 127.0.0.1 ^
 --port 8080

そしてツール設定で model provider を次のように指定します。

1
2
3
4

[model_providers.llamacpp]
name = "llama.cpp"
base_url = "http://127.0.0.1:8080/v1/"
wire_api = "responses"

このルートはより柔軟ですが、設定はやや複雑です。Ollama Launch の利点は簡単さ、llama.cpp の利点は VRAM、コンテキスト、量子化、推論バックエンドを細かく制御できることです。

ローカル AI Agent 利用時の注意点

ローカルだからリスクがないわけではありません。Agent がファイルを変更し、コマンドを実行し、プロジェクトを作成できるなら、誤ってファイルを消したり、間違ったコードを変更したり、不適切なコマンドを実行したりする可能性もあります。

推奨事項：

  1. Git リポジトリ内で作業し、いつでも diff を確認して戻せるようにする。
  2. Agent に過大なシステム権限を与えない。
  3. まずテストプロジェクトで試し、本番コードベースへ直接投入しない。
  4. 重要なファイル変更は必ず人間が review する。
  5. 鍵、アカウント、本番環境設定を Agent に見せない。
  6. ローカルモデルには限界があるため、複雑なアーキテクチャ判断を完全に任せない。

ローカル Agent は「タスクを実行できる助手」として扱い、「完全に信頼できるエンジニア」とは見なさない方が健全です。

私の理解

Ollama が Codex App に接続する意味は、ローカルモデルを本当に AI コーディングワークフローへ入れることです。

以前のローカルモデルは、多くの場合チャットボックスでした。今はプロジェクトに入り、コードを読み、ファイルを変更し、タスクを実行し始めています。この変化は、多くの一般開発者に手元の PC を見直させるはずです。最も高価な GPU がなくても、低コストでオフライン可能、かつ制御しやすい AI コーディング環境を作れるかもしれません。

クラウドモデルは今も強力です。特に複雑な推論、大きなコンテキスト、マルチモーダル、長時間タスクの安定性では優位があります。しかしローカルモデルは「実行ツール」としての部分を埋め始めています。

今後の AI コーディングは、純クラウドでも純ローカルでもなく、ハイブリッドになる可能性が高いです。

  • 小さなタスク、ローカルコード、プライベートプロジェクトはローカルモデルへ；
  • 難しい推論、大きなコンテキスト、複数システムにまたがるタスクはクラウドモデルへ；
  • Ollama、Codex App、Claude Code、OpenCode のようなツールが両方を一つのワークフローへ接続する。

これこそ、ローカル AI Agent が本当に注目に値する理由です。

参考リンク

© 2022 - 2026 KnightLiブログ
记录并分享
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。