OllamaでCodexをローカルLLM実行する方法|ollama launch codex-appの手順と対処法

OpenAIのCodexを、APIの従量課金もレート制限も気にせず手元のマシンだけで動かしたい。その要望に応えるのが、Ollamaのollama launch codex-appによるローカルLLM連携です。コマンドを1行実行するだけでOllamaが接続設定を書き換え、ローカルモデルがセットされた状態でCodexが立ち上がります。本記事では、対応バージョンの要件から、モデルを指定した起動、CLI版との使い分け、起動しない・モデルが切り替わらないといった典型的なつまずきへの対処、--restoreによる設定の復元までを、公式ドキュメントの実際の挙動に沿って解説します。

目次

まとめ

  • OllamaのCodexアプリ対応はv0.24.0以降。ターミナルでollama launch codex-appを実行すると、OpenAI互換エンドポイント経由でローカルモデルを使うようCodex側の設定が書き換わり、アプリが起動します
  • モデルはollama launch codex-app --model gemma4:31bのように起動時に指定でき、選んだモデルは次回起動時も保持されます。--model kimi-k2.6:cloudのようにOllama Cloudのモデルも同じ書式で呼び出せます
  • ターミナルで完結させたい場合はCLI版のollama launch codexを使います。アプリ用とCLI用で設定プロファイルが分かれる点が運用上の注意点です
  • アプリが開かないときは一度手動で起動してからコマンドを再実行し、モデルが切り替わらないときはアプリの再起動を許可します。連携前の構成へ戻すときはollama launch codex-app --restoreを実行します(書き換え前のバックアップは~/.ollama/backup/codex-app/に保存されます)

クラウドAPIへコードを送らずに済むため、機密性の高いコードを扱う現場でもAI支援を受けやすくなります。以下、導入の背景からモデル選定、セットアップ手順、トラブル対処までを順に見ていきます。

Ollama v0.24.0によるCodexアプリ対応で変わるローカルAI開発の要点

ローカルでLLMを動かす環境として支持を集めてきたOllamaは、v0.24.0でOpenAIのCodexアプリに対応しました。本章では、この対応の全体像と、ローカルAI開発の現場にどのような変化をもたらしたのかを整理します。

2026年5月14日に公開されたOllama v0.24.0の主な変更点

ローカル環境で大規模言語モデルを実行するオープンソースツール「Ollama」でCodexアプリ対応が入ったのは、2026年5月14日公開のv0.24.0です。Ollama自体はその後も更新が続いており、2026年7月時点の最新安定版はv0.31.2ですが、公式ドキュメントが示す要件は「v0.24.0以降」なので、それより新しいバージョンを使っていれば本記事の手順はそのまま通用します。Windows・macOS・Linuxのいずれにも対応しており、公式サイトから無償でダウンロードできます。v0.24.0で入った主な変更点は次のとおりです。

  • デスクトップ版「Codex」アプリ(Codex app)への正式対応が追加され、GUI上でローカルモデルを使ったコーディングが行えるようになりました
  • Apple Silicon向けにMLXサンプラーが改良され、生成されるテキストの品質が向上しています
  • ローカルモデルとOllama Cloudのモデルを同じ環境から呼び出せる仕組みが整理されました

とりわけ注目度が高かったのはCodexアプリへの対応で、これがv0.24.0の目玉と位置づけられました。従来はターミナル中心だったローカルLLMの活用が、使い慣れたGUIアプリへと広がった点が大きな転換です。要件はv0.24.0以降なので、それより古いバージョンを使っている場合はまず更新してください。

v0.24.0の目玉となったCodexアプリ対応で実現する開発体験

v0.24.0で最も注目されたのが、デスクトップ版Codexアプリへの対応です。ターミナルで所定のコマンドを実行すると、Ollamaにローカルモデルがセットされた状態で、GUIのCodexアプリが立ち上がります。これまでコマンドライン操作に慣れていなかった開発者でも、視覚的なインターフェースを通してローカルLLMによるコーディングを始められるようになりました。

Codexアプリは、コードの生成や修正をエージェントに任せられるOpenAI製のツールです。そこにOllamaのローカルモデルを組み合わせることで、外部のクラウドサービスに頼らずに同等の開発体験を得られる点が大きな特徴と言えるでしょう。使い慣れたアプリの操作感はそのままに、処理基盤だけを手元のマシンへ置き換えられるイメージです。実務では、機密性の高いプロジェクトでも安心してAI支援を受けられるようになります。ローカルとクラウドの利点を一つのアプリで扱えるようになった意義は決して小さくありません。

Windows・macOS・Linuxに対応し無償で導入できる提供条件

Ollamaは、Windows・macOS・Linuxの主要なデスクトップ環境すべてに対応しています。公式サイトからインストーラーやバイナリを無償で入手でき、商用・非商用を問わず使えるのが魅力です。ライセンスはMITが採用されており、オープンソースとして開発が進められている点も、導入のハードルを下げる要因となっています。費用負担なく試せるため、まずは手元の環境で動かしてみる入り口として選びやすいツールです。

一方で、Codexアプリ対応の機能を使うにはv0.24.0以降が必要です。すでにOllamaを利用している場合でも、古いバージョンのままでは新機能が反映されないため、事前に更新しておく必要があります。また、Codexアプリ自体はmacOSとWindowsが対象であり、Linux環境ではアプリ版ではなくCLIなど別の連携手段を検討することになります。導入前に、自分の利用環境がどの組み合わせに該当するかを確認しておくと安心です。対応状況を最初に押さえておけば、過不足のない準備が整えられます。

ローカル開発者やプライバシー重視の現場にとっての恩恵と注意点

今回の対応によって最も恩恵を受けるのは、手元のマシンでAIコーディングを完結させたい開発者です。クラウドAPIへソースコードを送信せずに済むため、社外秘のプロジェクトや顧客データを扱う現場でも、情報漏えいのリスクを抑えながらAI支援を活用できます。従量課金が発生しない点も、日常的にAIを使う開発者には見逃せない利点でしょう。

ただし、注意すべき点もあります。ローカルで動かすモデルの応答品質や速度は、利用するマシンのGPUやメモリといったハードウェア性能に大きく左右されます。クラウドの大規模モデルと同じ水準を常に期待できるわけではないため、用途に応じてモデルを選び分ける視点が欠かせません。導入の判断では、得られる恩恵とハードウェア要件の両面を見比べることが重要になります。得られる効果と必要なコストを天秤にかける姿勢が欠かせない点も覚えておきたいところです。実際の運用では、扱うデータの機密度に合わせて使い方を調整するのが現実的でしょう。

AIコーディングツールのローカル実行が広がる近年の技術的背景

Codexアプリ対応の背景には、AIコーディングツールをローカルで動かそうとする近年の流れがあります。オープンなLLMの性能が急速に向上し、数十億から数百億規模のパラメータを持つモデルでも、個人のワークステーションで実用的に動かせるようになってきました。量子化技術の進歩によって、限られたメモリでも大きめのモデルを扱える環境が整いつつあります。ハードウェアの進化も後押しとなり、ローカル実行のハードルは年々下がってきました。

同時に、クラウドAIの利用に伴うコストやデータの取り扱いに対する懸念も高まってきました。こうした課題を背景に、Ollamaのようなローカル実行基盤とCodexのようなコーディングエージェントを組み合わせる動きが加速しています。v0.24.0のCodexアプリ対応は、その流れを象徴する一歩でした。手元の環境で完結する開発スタイルは、今後さらに広がっていくと考えられます。ツールの選択肢が増えるほど、自分の環境に合った組み合わせを見つけやすくなるはずです。

ローカルLLM実行基盤Ollamaとデスクトップ版Codexアプリの基本機能

連携の中身を理解するには、OllamaとCodexアプリそれぞれの役割を押さえておく必要があります。本章では、両者の基本的な仕様と、どのように組み合わさって動くのかを解説します。

コマンド一つでオープンLLMを動かせるOllamaの基本仕様

Ollamaは、コマンドを一つ実行するだけでオープンなLLMをダウンロードし、ローカルで実行・管理できるツールです。モデルの取得から起動までを自動で処理してくれるため、環境構築に手間取ることなくすぐに対話を始められます。チャット形式での利用に加えて、API経由でアプリケーションへ組み込む使い方にも対応しています。難しい初期設定を求められない手軽さこそ、多くの利用者に支持される大きな理由でしょう。

動作の仕組みとしては、Ollamaがバックグラウンドでローカルサーバーを立ち上げ、そこにモデルを読み込んで応答を返します。利用者はコマンドやAPIを通じてこのサーバーにリクエストを送るだけで、複雑な設定を意識する必要はありません。モデルの切り替えや削除といった管理操作も、いずれも短いコマンドで完結します。こうした手軽さが、ローカルLLMの裾野を広げる原動力になってきました。導入のしやすさと管理のシンプルさが両立している点は、初めてローカルLLMに触れる人にも心強い特長です。

GemmaやQwenなど主要なオープンモデルを扱える対応範囲

Ollamaが扱えるモデルは幅広く、GoogleのGemma、AlibabaのQwen、MetaのLlamaといった主要なオープンモデルを手軽に導入できます。いずれもコマンドでモデル名を指定すれば自動的にダウンロードされ、すぐにローカルで動かせる状態になります。用途や手持ちのハードウェアに合わせて、サイズの異なる複数のモデルを使い分けられるのも利点です。

今回のCodexアプリ対応では、こうした多彩なモデル群をそのままコーディング用途に活用できます。軽量なモデルで素早く下書きを生成したり、大きめのモデルで複雑な実装を任せたりと、場面ごとに最適な選択が可能になりました。さらにOllama Cloud上のモデルも同じ枠組みで呼び出せるため、ローカルとクラウドを柔軟に行き来できる設計になっています。扱えるモデルの選択肢が広い点は、長く使ううえで安心材料になるはずです。新しいモデルが公開されたときも、コマンドひとつで取り込んで試せる身軽さが魅力です。

OpenAI製デスクトップコーディングエージェントCodexアプリの特徴

Codexアプリは、OpenAIが提供するデスクトップ向けのコーディングエージェントです。macOSとWindowsに対応しており、コードの生成や修正、リポジトリの操作などを一つのアプリ内で進められます。コマンドラインで動作するCodex CLIとは別系統のツールで、GUIならではの直感的な操作性が持ち味となっています。

アプリ内には、複数の作業を並行して管理する仕組みや、Git連携の機能が標準で組み込まれています。タスクを分割しながら開発を進められるため、規模の大きなプロジェクトでも作業の見通しを保ちやすい構成です。本来はOpenAIのモデルを使う前提のツールですが、Ollamaと組み合わせることで、その操作性を保ったままローカルモデルへ処理を切り替えられます。使い慣れた環境を捨てずにローカル実行へ移行できる点が魅力です。慣れたワークフローを崩さずに導入できるため、移行にともなう学習コストも抑えられます。段階的にローカル実行へ寄せていく進め方も取りやすいでしょう。

OpenAI互換エンドポイント経由でローカルモデルを呼び出す仕組み

OllamaとCodexアプリが連携できるのは、OpenAI互換のエンドポイントが鍵になっています。Ollamaはローカルでサーバーを起動し、OpenAIのAPIと同じ形式でリクエストを受け付ける窓口を用意します。Codexアプリ側から見ると、接続先がOpenAIのサーバーから手元のOllamaに置き換わっただけで、通信の作法はほとんど変わりません。

Ollamaは標準でローカルの待ち受けポートにサーバーを立てており、OpenAI互換のパスを通じて応答を返します。

http://localhost:11434/v1/

このエンドポイントがCodexアプリの接続先として設定されることで、アプリの機能はそのままにモデルだけがローカルへ切り替わります。互換性のある形式を採用しているからこそ、既存のツールを大きく書き換えずに連携が成立する仕組みです。仕組みを理解しておくと、接続がうまくいかないときの切り分けにも役立ちます。

ターミナル操作を介さずに利用できるGUI主体のアプリ全体構成

Codexアプリの大きな魅力は、ターミナルを開かずに一連の開発作業を進められるGUI主体の構成にあります。コードの生成や修正の指示、変更内容の確認、リポジトリの操作までを、すべてアプリのウィンドウ内で完結できる仕組みです。コマンドの記憶や入力に不慣れな利用者でも、画面上のボタンやメニューをたどるだけで主要な機能を扱えます。

もっとも、最初にOllamaと連携させる段階では、ターミナルから所定のコマンドを一度だけ実行する必要があります。いったん起動してしまえば、その後の日常的な作業はGUIだけで進められるため、コマンド操作が負担になることはほとんどありません。視覚的なインターフェースとローカルモデルの組み合わせは、AIコーディングの間口を大きく広げる構成と言えるでしょう。導入後の運用イメージを描きやすい点も、移行を後押しします。導入の手間と日々の使いやすさのバランスが取れている点も、検討するうえで見逃せません。

API課金とレート制限なしでローカルLLMコーディングが可能になる利点

ローカル実行に切り替える最大の動機は、クラウドAPI特有の制約から解放される点にあります。本章では、コスト・制限・プライバシー・オフライン対応・性能という観点から、ローカルLLMコーディングの利点を具体的に見ていきます。

従量課金のクラウドAPIが不要になるコスト面での具体的な利点

クラウドのAIコーディングサービスは、多くの場合リクエスト量やトークン数に応じた従量課金が発生します。日常的にコード生成を繰り返す開発者にとって、この費用は積み重なると無視できない金額になりがちです。ローカルでモデルを動かす方式に切り替えると、こうした利用ごとの課金が発生しなくなります。使うほどに費用がかさむという心配から解放されるのは、大きな安心材料です。

初期費用として相応のスペックを備えたマシンは必要になりますが、いったん環境を整えてしまえば、どれだけ使っても追加の料金はかかりません。検証作業で大量のリクエストを投げる場面や、長時間にわたって試行錯誤を続ける場面でも、コストを気にせず作業に集中できます。費用の上限が読みやすくなる点は、チームで予算を管理するうえでも扱いやすい要素です。月々の請求額に振り回されずに済む安心感は、ローカル実行ならではの強みと言えます。費用面の不安が小さくなることで、AIを使う頻度そのものを増やしやすくなる効果も期待できます。

レート制限を回避し連続的にリクエストを処理できる作業上の利点

クラウドAPIには、一定時間あたりのリクエスト回数やトークン量に上限を設けるレート制限が存在することが一般的です。短時間に多くの処理を投げると制限にかかり、待機を強いられたり処理が一時的に止まったりすることがあります。エージェントに連続したタスクを任せたい場面では、この制限がボトルネックになりがちです。規模の大きな処理を任せるほど、この制約が作業の足かせになりやすい傾向があります。

ローカル実行では、こうした外部サービス側の制限を意識する必要がありません。処理の速度は手元のハードウェア性能に依存しますが、回数そのものに上限が設けられることはなく、思い立ったときに連続してリクエストを送れます。大量のファイルを一気に解析させたり、反復的な修正を繰り返したりする作業でも、流れを止めずに進められる点が大きな利点です。制限を気にしないで済むぶん、思考のリズムを保ちやすくなります。待ち時間に作業を中断されないことは、集中を要する開発において見過ごせない利点です。

ソースコードや機密情報を外部送信しないプライバシー保護の効果

クラウドのAIサービスを利用する場合、コードやプロンプトの内容が外部のサーバーへ送信されます。社外秘のロジックや個人情報を含むデータを扱う現場では、この送信そのものがセキュリティ上の懸念となることがあります。利用規約上は学習に使われないとされていても、送信を避けたい組織は少なくありません。情報の取り扱い規程が厳しい組織ほど、この懸念は導入判断に直結しがちです。

ローカルでモデルを動かす方式なら、入力したコードや情報が手元のマシンの外へ出ることはありません。インターネットを経由しないため、通信途上での漏えいリスクも構造的に抑えられます。金融や医療、行政といった機密性の高い領域や、厳格な情報管理が求められる企業にとって、この点は導入を後押しする決め手になり得ます。データの流れを自分たちで完全に把握できる安心感は、クラウドにはない強みと言えるでしょう。外部に出さないという前提を技術的に担保できることは、監査や説明責任の面でも価値があります。

インターネット非接続のオフライン環境でも活用できる運用上の強み

ローカル実行のもう一つの強みは、インターネットに接続していない環境でもAIコーディングを続けられる点です。モデルを一度ダウンロードしてしまえば、その後の推論はすべて手元のマシンで完結します。外部サービスへ接続できない状況でも、機能が損なわれることはありません。通信環境を整える手間がかからない点も、現場での導入を後押しする要素でしょう。

移動中の作業や、ネットワークが不安定な現場、あるいはセキュリティ上の理由で外部接続を遮断している閉域環境などでも、変わらず開発を進められます。クラウド型のツールでは通信が途切れると作業が止まってしまいますが、ローカル型にはそうした弱点がありません。接続状況に左右されずに安定した開発環境を保てる点は、出張や現地作業の多い技術者にとって心強い要素です。回線品質を気にせず集中できる環境は、生産性の維持にもつながります。回線の有無に依存しない開発環境は、不測の状況でも作業を止めない備えになります。

ローカル実行ならではの処理性能や速度面で押さえておく判断材料

ローカル実行には多くの利点がある一方で、処理性能の面では事前に把握しておくべき点があります。応答の速さや扱えるモデルの規模は、搭載するGPUやメモリ、ストレージといったハードウェア構成に大きく左右される点に注意が必要です。高性能なGPUを備えたマシンであれば、大きめのモデルでも快適に動かせます。

反対に、メモリやGPU性能が限られた環境では、モデルの応答が遅くなったり、扱えるモデルのサイズが制約を受けたりすることがあります。v0.24.0ではApple Silicon向けにMLXサンプラーが改良され、生成品質が高まる調整も加えられました。こうした最適化により、対応するマシンでは以前より快適に利用できる場面も増えています。導入を検討する際は、自分のハードウェアでどの程度の規模のモデルが動くかを見極めることが、満足度を左右する判断材料になります。事前にメモリ容量やGPUの世代を把握しておくと、選べるモデルの幅も見通しやすいはずです。

内蔵ブラウザーとレビューモードを活用したコード修正の実務フロー

Codexアプリには、開発作業を一つの画面で完結させるための機能が用意されています。本章では、内蔵ブラウザーやレビューモードといった代表的な機能が、実際のコード修正の流れの中でどう役立つのかを具体的に紹介します。

ローカルサーバーや開発中サイトを表示できる内蔵ブラウザーの役割

Codexアプリには、開発中のローカルサーバーやWebサイトをそのまま表示できる内蔵ブラウザーが備わっています。たとえばローカルで起動したアプリケーションの画面を、アプリの外にあるブラウザーへ切り替えることなく、同じウィンドウ内で確認できる仕組みです。コードの編集と動作確認を行き来する手間が減り、作業の流れが途切れにくくなります。

表示している画面は単なるプレビューではなく、修正指示の起点としても機能します。実際の見た目を確認しながら、気になる箇所をその場でCodexに伝えられるため、認識のずれが生じにくいのも利点です。フロントエンド開発のように、見た目と実装の対応関係が重要な場面では、この内蔵ブラウザーの存在が作業効率を大きく左右します。確認と修正を一つの環境にまとめられる点が、内蔵ブラウザーの中心的な役割と言えるでしょう。確認のたびに別ウィンドウへ移る煩わしさがなくなる点も、地味ながら効率を底上げします。

開発中の画面上に直接注釈を付けて変更を依頼できる操作の実務例

内蔵ブラウザーで表示したページには、直接注釈を付けて変更を依頼できます。たとえば「このボタンの配置を右寄せにしたい」「この余白を詰めたい」といった要望を、該当する箇所を指し示しながら伝えられるのが特徴です。文章だけで位置や対象を説明する必要がなくなるため、指示の意図が正確に伝わりやすくなります。意図が正確に届くほど、返ってくる修正の精度も自然と高まりやすくなります。

デザインツールでコメントを残す感覚に近く、視覚的なフィードバックをそのままコードの修正につなげられるのが特徴です。実務では、画面を見ながら気づいた改善点をその場で書き込み、Codexに修正を任せるという流れが組み立てられます。指摘の往復にかかる時間が短くなり、細かな調整を重ねる作業もスムーズに進む点が魅力です。言葉での説明が難しい視覚的な変更ほど、この注釈機能の利点が際立ちます。口頭やテキストでは伝えにくい微妙なニュアンスも、指し示すことで具体的に共有できます。

コード差分にコメントを残し修正を反復できるレビューモードの使い方

Codexアプリには、コードの変更内容を確認しながらフィードバックを返せるレビューモードが用意されています。生成されたコードや修正案の差分を見比べ、気になる部分にコメントを残せるのが特徴です。「ここはもう少し簡潔にしたい」「この処理は分割したほうがよい」といった指摘を、差分の該当箇所に紐づけて伝えられます。

コメントを受け取ったCodexは、その内容を踏まえて修正を加え、再び差分として提示します。利用者はその結果を確認し、必要であればさらにコメントを重ねるという反復が可能です。こうしたやり取りを別のツールへ移動せずにアプリ内で完結できるため、レビューと修正のサイクルを素早く回せます。コードの品質を段階的に高めていく作業を、一貫した環境で進められる点がレビューモードの強みです。納得のいくまで修正を重ねられる柔軟さも、実務では重宝します。指摘と反映の履歴がアプリ内に残るため、変更の経緯を後から追いやすい利点もあります。

アプリ内で確認から修正までを完結できる一連の作業フローの効率性

内蔵ブラウザーと注釈機能、そしてレビューモードを組み合わせると、確認から修正までの一連の流れをアプリ内で完結できます。動作中の画面を内蔵ブラウザーで確かめ、気になる箇所に注釈を付けて修正を依頼し、返ってきた差分をレビューモードで確認するという流れが、同じウィンドウの中でつながります。

従来は、エディタとブラウザー、レビュー用のツールを行き来しながら作業を進めるのが一般的でした。Codexアプリでは、これらの工程が一つの画面に集約されているため、ツール間を移動する切り替えのコストがほとんどかかりません。作業の文脈を保ったまま次の工程へ進めるので、集中力を途切れさせずに開発を続けられます。一連の流れがなめらかにつながることで、細かな修正を多く含むタスクほど効率の差が表れやすくなります。画面を切り替える小さな手間が積み重なりにくい構成は、長時間の作業ほど恩恵を実感しやすいはずです。作業に慣れるほど、その効率の差は明確に感じられるようになります。

IDEとブラウザーを往復する従来手法と比較した手戻りの削減効果

従来のAIコーディングでは、コードを書くエディタやIDE、動作を確かめるブラウザー、変更を確認するレビュー画面が、それぞれ別の場所に分かれていました。修正のたびにこれらを行き来する必要があり、画面の切り替えや文脈の取り直しに少なからぬ時間がかかっていました。指示の意図がうまく伝わらず、想定と違う修正が返ってくる手戻りも起きがちです。

Codexアプリでは、実際の画面を見ながら該当箇所を指し示して指示できるため、認識のずれが生じにくくなります。差分にコメントを直接紐づけられることで、どこをどう直してほしいのかが明確に伝わるのも強みです。結果として、想定外の修正が返ってくる回数が減り、やり直しにかかる時間を抑えられます。手戻りの少なさは、タスク全体の所要時間にそのまま響くため、実務での恩恵は小さくありません。指示と確認のずれが減るほど、開発全体のテンポも安定しやすくなります。結果として、当初の見積もりどおりに作業を終えやすくなる効果も見込めます。

Codexアプリ版とCodex CLI版の違いと使い分けの判断基準

Codexには、GUI主体のアプリ版とターミナルで動くCLI版の二つがあります。Ollamaはそれぞれに対応しており、目的に応じて選ぶことが大切です。本章では、両者の違いと使い分けの判断軸を整理します。

GUI操作で視覚的に扱えるCodexアプリ版の特性と向き不向き

Codexアプリ版は、グラフィカルな画面で操作を完結できるGUI主体のツールです。内蔵ブラウザーやレビューモードといった視覚的な機能が充実しており、画面を見ながら作業を進めたい開発者に向いています。一方のCLI版は、ターミナル上でコマンドを通じて操作する軽量な構成で、キーボード中心の作業や自動化と相性がよいのが特徴です。両者の特性を整理すると次のようになります。

観点 Codexアプリ版 Codex CLI版
操作方法 GUIによる視覚的な操作 ターミナルでのコマンド操作
得意な作業 画面確認やレビューを伴う開発 軽快な実行やスクリプト連携
主な対応環境 macOS・Windows 各OSのターミナル環境
向いている利用者 視覚的に作業したい開発者 CLI操作に慣れた開発者

アプリ版は、見た目の確認や対話的なレビューを重視する場面で力を発揮します。反対に、軽快さや自動化を優先するならCLI版が適しています。自分の作業スタイルに照らして、どちらが負担なく使えるかを基準に選ぶとよいでしょう。視覚的な確認の比重が高い開発ほど、アプリ版の利点が生きやすい傾向があります。

ターミナルで完結するCodex CLI版が適する作業の判断基準

Codex CLI版は、ターミナル上ですべての操作が完結する軽量なツールです。GUIを起動する必要がないため、リソースの消費を抑えながら素早く立ち上げられます。コマンドやスクリプトと組み合わせやすく、定型的な処理を自動化したい場面に向いています。サーバー上のリモート環境のように、グラフィカルな画面を使いにくい状況でも扱える点も見逃せません。

判断の基準としては、作業に視覚的な確認が欠かせないかどうかが一つの目安になります。画面を見ながらの修正やレビューが中心ならアプリ版が、コマンド操作や自動化が中心ならCLI版が適しています。また、CI環境への組み込みやバッチ処理のように、人手を介さない実行を想定する場合もCLI版が無難です。自分の作業のうち、どの割合が画面操作で、どの割合がコマンド操作かを見渡すと、選びやすくなるでしょう。軽さと再現性を重視する現場では、CLI版が長く使いやすい選択になります。

起動コマンドの違いで呼び出されるCLI版とアプリ版の切り替え

CLI版とアプリ版は、Ollamaから起動する際のコマンドによって切り替わります。デスクトップ版のCodexアプリを立ち上げたい場合は、専用のサブコマンドを指定して実行します。それぞれ別のコマンドが割り当てられているため、どちらを起動したいかをコマンドの段階で明確に指定する形です。

たとえば、GUIのCodexアプリを起動するコマンドは次のとおりです。

ollama launch codex-app

一方、ターミナルで動くCLI版を起動する場合は、末尾のサブコマンドが異なります。コマンドの違いを把握しておけば、目的に合ったほうを迷わず立ち上げられるはずです。同じCodexでも呼び出し方によって挙動が変わるため、最初に両者のコマンドを区別して覚えておくと安心でしょう。誤って別のほうを起動しても、正しいコマンドを実行し直せば切り替えられます。短いコマンドで切り替えられる手軽さは、用途に応じて両方を併用したいときにも役立ちます。

アプリ用とCLI用で設定プロファイルが分離される管理上の違い

OllamaがCodexと連携する際、アプリ版とCLI版では設定プロファイルが別々に管理されます。アプリ版の起動コマンドを実行しても、CLI版の設定はそのまま保たれ、互いに上書きし合うことはありません。両者の設定が独立しているため、片方の変更がもう片方に影響を及ぼす心配は少なくなっています。

この分離は、アプリ版とCLI版を併用する利用者にとって扱いやすい仕組みです。たとえば、アプリ版では対話的な開発向けのモデルを、CLI版では自動化向けの軽量なモデルを、といった具合に用途ごとに設定を分けられます。それぞれのプロファイルが干渉しないため、目的に応じた構成を保ったまま使い分けが可能です。設定がどちらに紐づいているかを意識しておくと、思わぬ挙動の変化に戸惑うことも避けられます。設定が混ざらない構造になっているおかげで、片方を気軽に試したり戻したりしやすくなっています。設定の独立性は、複数の用途を並行して扱う運用ほど頼りになる特長でしょう。

複数人のチーム開発か個人での作業かで選ぶべき最適な構成の判断軸

どちらの版を選ぶかは、開発が個人中心かチーム中心かによっても変わってきます。個人で試行錯誤を重ねる作業では、画面を見ながら直感的に操作できるアプリ版が手になじみやすい傾向があります。視覚的なレビューや動作確認を一人で完結させたい場合、GUIの利点が生きやすいと言えるでしょう。

一方、チームで開発を進める場面では、自動化や再現性が重視されることが多くなります。共通のスクリプトやCIに組み込んで、誰が実行しても同じ手順をたどれるようにするなら、コマンドで制御しやすいCLI版が扱いやすいはずです。もっとも、両者は排他的ではなく、設定が分離されているため併用も無理なく行えます。チームの規模や作業の標準化の度合いを見極めたうえで、状況に応じて使い分ける構成が現実的な選択になります。役割や場面ごとに版を切り替える運用も、十分に検討する価値があるでしょう。チームの成熟度に応じて構成を見直していく柔軟さも、長期的には欠かせません。

用途別に選ぶ推奨ローカルモデルとOllama Cloud活用の指針

ローカルLLMコーディングの満足度は、どのモデルを選ぶかに大きく左右されます。用途やハードウェアに合わない選択は、性能不足や過剰なリソース消費を招きかねません。本章では、目的別の推奨モデルとOllama Cloudの活用方針を整理します。

複雑なコーディングやエージェント処理に向く推奨モデルの選び方

モデルを選ぶ際は、任せたい作業の複雑さを最初の基準にすると考えやすくなります。込み入ったロジックの実装や、複数の工程をまたぐエージェント的な処理を任せたい場合は、推論能力の高い大きめのモデルが向いています。規模の大きなモデルほど文脈の理解や長い手順の追跡に強く、複雑な指示にも対応しやすいのが特徴です。

一方で、大きなモデルは相応のメモリやGPU性能を要求します。手元のマシンが十分なスペックを備えているかどうかが、現実的な選択を左右する要素です。簡単な補完や短いコード生成が中心なら、無理に大きなモデルを選ぶ必要はありません。作業の難易度とハードウェアの余力を照らし合わせ、過不足のないモデルを選ぶことが、快適な開発への近道になります。まずは用途を見極めることが、適切なモデル選びの出発点です。迷ったときは小さめのモデルから試し、必要に応じて規模を上げていくと無駄が少なくなります。身の丈に合った選択が、結局は最も効率のよいモデル運用につながります。

視覚対応のKimi K2.6やGLM-5.1など高性能モデルの特徴

複雑なコーディングやエージェント処理を任せたい場合の選択肢として、いくつかの高性能モデルが推奨されています。視覚的な情報にも対応するKimi K2.6や、高い処理能力を備えたGLM-5.1などがその代表です。これらは規模が大きいぶん推論能力に優れ、難度の高い実装やエージェント的な処理を任せたい場面で力を発揮します。主な特徴を整理すると次のとおりです。

モデル 規模 実行形態 向いている用途
Kimi K2.6 1T級MoE Ollama Cloud(:cloudタグ) 画像も絡む複雑なコーディング
GLM-5.1 744B級MoE Ollama Cloud(:cloudタグ) 込み入った実装やエージェント処理

注意したいのは、この2つは一般的な開発マシンにpullして動かせる規模ではないという点です。公式ドキュメントの用例もollama launch codex-app --model kimi-k2.6:cloudのように:cloudタグ付き、すなわちOllama Cloud経由での利用を前提としています。手元のハードウェアだけで完結させたい場合は、次に挙げるローカル向けモデルから選ぶことになります。

Cloud契約なしでローカル利用に適したモデルの具体的な候補

Ollama Cloudのサブスクリプションを使わず、手元の環境だけで利用したい場合にも、適したモデルがいくつか挙げられています。クラウド契約なしでローカル運用したいニーズに応える候補として、次のようなモデルが示されています。

  • gemma4:31b:扱いやすく汎用的な用途に向くモデル。単体GPUやApple Siliconの一般的な開発マシンでも実用域に入ります
  • Qwen3.6:幅広いタスクに対応する定番のオープンモデル。27Bの密モデルで、量子化すればメモリ24GB前後の環境が目安です
  • Nemotron 3 Super:120BのMoE(アクティブ12B)。アクティブパラメータが小さいぶん推論効率は高いものの、重みは全量をメモリに載せる必要があり、64GB以上のユニファイドメモリ級の環境が前提になります

これらは、クラウドの大規模モデルに頼らずとも、手元のマシンで実用的なコーディング支援を得たい場面に適しています。どれを選ぶかは、搭載しているハードウェアの性能や、扱いたい作業の規模によって変わってきます。まずは比較的軽いモデルから試し、応答の速さや品質を確かめながら、必要に応じて規模を調整していくと失敗が少ないはずです。ローカル運用を前提にするなら、こうした候補から検討を始めると安心です。

Nemotron 3 SuperやQwen3.6を含む軽量モデルの使い分け

ローカル利用に向くモデルといっても、必要なメモリ量には差があります。Qwen3.6(27B)やgemma4:31bは量子化すれば24GB前後の環境で動かせる一方、Nemotron 3 Superは120BのMoEでアクティブは12Bにとどまるものの、重み自体は全量ロードが必要なため、同じ「ローカル向け」でも要求スペックの桁が違います。日常的なコード補完や短い関数の生成が中心なら、まず前者の規模から試すのが現実的です。

使い分けの考え方としては、まず軽量なモデルで日々の作業をこなし、難度の高いタスクに直面したときだけ大きなモデルへ切り替える方法が現実的です。複数のモデルを用意しておけば、作業の内容に合わせて手早く持ち替えられます。応答が物足りないと感じたら一段上の規模を試し、逆に過剰だと感じたら軽いモデルに戻すといった調整も容易です。手持ちのハードウェアと相談しながら、最も負担の少ない組み合わせを探っていくとよいでしょう。普段使いのモデルを一つ決めておくと、起動のたびに迷わずに済みます。

ローカルとOllama Cloudモデルを併用する際の選択指針

Ollamaでは、手元で動かすローカルモデルだけでなく、Ollama Cloud上のモデルも同じ枠組みで呼び出せます。日常の軽い作業はローカルモデルで処理し、より高い性能が必要な場面ではクラウド側のモデルに任せる、といった併用が可能です。状況に応じて両者を切り替えられるため、ハードウェアの制約と処理能力のバランスを取りやすくなります。

選択の指針としては、機密性や費用を重視するならローカルを、処理の重さや精度を優先するならクラウドを軸に考えると整理しやすくなります。たとえば、社外秘のコードはローカルで扱い、公開前提の検証はクラウドで処理するといった切り分けも有効です。Codexアプリ起動時にモデルを指定できるため、用途ごとに使い分ける運用も無理なく組み立てられます。両者の長所を理解したうえで、場面に応じて柔軟に選ぶ姿勢が、快適な運用につながります。手元の性能が足りない場面だけクラウドに頼る使い方なら、コストと性能の折り合いもつけやすいでしょう。

Ollamaインストールからcodex-app起動までのセットアップ手順

ここからは、実際にOllamaとCodexアプリを連携させるまでの手順を順を追って解説します。導入からモデル指定までの流れを押さえておけば、初めての方でも迷わずに環境を整えられます。本章で具体的な操作を確認していきましょう。

v0.24.0以降を公式サイトから導入する最初のインストール手順

最初に必要なのは、Codexアプリ対応を含むOllama v0.24.0以降の導入です。すでに古いバージョンを使っている場合も、新機能を利用するには更新が欠かせません。インストールの大まかな流れは次のとおりです。

  1. Ollamaの公式サイトにアクセスし、自分のOSに合ったインストーラーをダウンロードします
  2. ダウンロードしたファイルを実行し、画面の指示に従ってインストールを進めます
  3. インストール後にバージョンを確認し、v0.24.0以降になっているかを確かめます

導入が済んだら、Ollamaが正しく動作するかを簡単に確認しておくと安心です。すでに以前のバージョンを利用していた場合は、更新後にバージョン表示が新しくなっているかを必ずチェックしてください。ここでバージョンが古いままだと、後続のCodexアプリ連携がうまく機能しないため、最初の段階で確実に最新版へ揃えておくことが大切です。土台となる環境を整えておくことで、その後の手順がスムーズに進みます。最初のひと手間を惜しまないことが、つまずきを防ぐ近道になります。

macOSまたはWindowsへCodexアプリを用意する事前準備

Ollamaの導入と並行して、連携先となるCodexアプリ本体も用意しておく必要があります。ここで押さえておきたいのが入手方法の変更です。2026年7月9日にOpenAIはCodexアプリをChatGPTデスクトップアプリへ統合し、Codexは単体アプリではなく、Chat・Work・Codexという3つのモードのひとつになりました。現在CodexをGUIで使うには、macOSまたはWindows向けのChatGPTデスクトップアプリを入手し、Codexモードを開く形になります。統合前のCodexアプリをすでに導入している場合は、通常のアップデートでそのまま新しいChatGPTデスクトップアプリへ切り替わります(従来のChatGPTデスクトップアプリはChatGPT Classicへ名称変更されました)。

注意したいのは、Codexアプリ自体はOpenAIのツールであり、Ollamaとは別に入手する必要がある点です。Ollama側の準備だけでは連携は成立せず、アプリ本体がインストールされていることが前提です。Ollama公式ドキュメントは2026年7月11日時点で統合に触れておらず、コマンドはollama launch codex-appのまま案内されています。統合後の環境で起動しない場合は、後述の手動起動から再実行する手順で切り分けてください。なお本記事で「Codexアプリ」と呼ぶのは、統合後はChatGPTデスクトップアプリのCodexモードを指します。Linux環境を使っている場合はデスクトップアプリの対象外となるため、Codex CLI版での連携を検討することになります。アプリ版とCLI版の入手手順や違いはWindows版Codexの使い方|アプリ版とCLIの違い・導入手順・プロキシ設定【2026年7月版】で整理しています。両方の準備がそろって初めて、Ollamaからの起動コマンドが意味を持ちます。アプリの初回起動まで済ませておくと、連携時の動作がいっそう安定します。

launchコマンドでCodexアプリを起動する基本的な実行手順

OllamaとCodexアプリの両方が用意できたら、いよいよ連携の起動です。ターミナルを開き、Ollamaに用意された専用のコマンドを実行すると、ローカルモデルがセットされた状態でCodexアプリが立ち上がります。最も基本となる起動コマンドは次のとおりです。

ollama launch codex-app

このコマンドを実行すると、Ollamaが必要な設定を整えたうえでCodexアプリを起動します。アプリが開いたら、いつもどおりにタスクを始めたり、リポジトリを開いたりするだけで作業に入れる状態です。接続先がローカルのOllamaに切り替わっているため、外部のクラウドへリクエストを送ることなくコーディングを進められます。初回はアプリの起動まで少し時間がかかることもありますが、二回目以降はよりスムーズに立ち上がるはずです。一度この流れを覚えてしまえば、日々の起動は短い操作で済みます。最初の一回さえ通れば、以降は迷うことなく使い続けられます。

起動時にモデル名を指定して特定のローカルモデルで開始する手順

起動コマンドには、使用するモデルをあらかじめ指定するオプションも用意されています。特定のローカルモデルでCodexアプリを開始したい場合は、コマンドにモデル名を添えて実行する形です。たとえばローカルのモデルを指定するなら、次のように記述します。

ollama launch codex-app --model gemma4:31b

このようにモデル名を渡すと、指定したモデルがセットされた状態でCodexアプリが立ち上がります。用途に応じて、軽量なモデルや高性能なモデルを起動時に選び分けられるのが便利な点です。クラウド側のモデルを使いたい場合も、同じ要領でモデル名を指定すれば呼び出せます。毎回同じモデルを使うのであれば一度指定しておけば十分ですが、作業ごとにモデルを変えたいときは、このオプションを使い分けると効率的です。指定するモデル名は、あらかじめOllamaで利用できる状態にしておく点に注意しておきましょう。

一度選択したモデルが次回起動時も保持される設定の確認ポイント

Codexアプリ向けの起動設定には、選んだモデルが保持されるという便利な性質があります。一度起動コマンドでモデルを指定すると、その選択が記録され、次回Codexアプリを開いたときも同じモデルが使われる仕組みです。毎回モデルを指定し直す必要がないため、決まったモデルで作業を続ける場合は手間が大きく省けます。

確認しておきたいのは、意図したモデルが実際に保持されているかどうかです。前回と異なるモデルで作業したいときは、起動時に改めてモデル名を指定すれば、その内容で設定が更新されます。逆に、知らないうちに別のモデルのまま作業を進めてしまわないよう、起動時に選択されているモデルを一度確かめておくと安心です。設定が持続する仕組みを理解しておけば、毎回の起動を効率化しつつ、想定外のモデルで作業する事態も防げます。普段使うモデルを固定しておくと、運用がいっそう安定します。意図したモデルで動いているかを最初に一目で確かめる習慣をつけておくと安心でしょう。

モデル切り替えや設定復元を含む運用段階でのトラブル対処と注意点

連携の設定が済んだ後も、起動や切り替えがうまくいかない場面に出会うことがあります。本章では、よくあるつまずきへの対処法と、設定を元に戻す方法、運用上の注意点をまとめます。あらかじめ把握しておけば、いざというときに落ち着いて対応できるはずです。

セットアップ後にCodexアプリが起動しない場合の具体的な対処法

起動コマンドを実行してもCodexアプリが立ち上がらないことがあります。多くの場合、アプリ側の初期状態が整っていないことが原因です。こうしたときは、次の手順で対処すると解決しやすくなります。

  1. Codexアプリを手動で一度起動し、正常に開くことを確認します
  2. いったんアプリを閉じ、改めて起動コマンドを実行します
  3. それでも開かない場合は、アプリとOllamaの状態を確認して再度試します

多くのケースでは、Codexアプリを一度手動で開いておくことで、その後の連携起動がうまく通るようになります。初回のセットアップ直後はアプリ側の準備が整っていないことがあり、手動起動がその橋渡しの役割を果たします。何度試しても改善しないときは、バージョンが要件を満たしているかや、アプリが正しくインストールされているかをあわせて見直すとよいでしょう。落ち着いて一つずつ切り分けていけば、原因にたどり着きやすくなります。慌てて何度も実行し直すより、状態を一つずつ確かめる進め方が結果的に早く済みます。

選択したモデルが切り替わらない場合に再起動で解決する具体的手順

起動コマンドでモデルを指定したのに、Codexアプリ側で期待したモデルに切り替わらないことがあります。これは、すでにアプリが起動している状態でコマンドを実行した場合に起こりやすい現象です。アプリが古い設定のまま動き続けているために、新しい指定が反映されないわけです。

このようなときは、Ollamaがアプリの再起動を促してきたら、それを許可するのが基本的な対処になります。再起動によって新しい設定が読み込まれ、指定したモデルが正しく反映されます。もし再起動の確認が表示されない場合は、いったんCodexアプリを完全に終了させてから、改めて起動コマンドを実行してください。手動で閉じてからやり直すことで、設定が確実に反映されます。切り替えがうまくいかないと感じたら、まずアプリを一度閉じることを試すと、解決の糸口がつかめるはずです。起動中のアプリに後から指定を反映させにくい点を覚えておくと、無用な戸惑いを避けられます。

restoreオプションで以前のプロファイルに戻す設定復元の方法

Codexアプリの設定をOllama連携前の状態に戻したい場面もあります。たとえば、本来のOpenAIのモデルを使う構成へ戻したいときなどです。こうしたケースでは、専用のオプションを付けてコマンドを実行することで、以前のプロファイルに復元できます。復元用のコマンドは次のとおりです。

ollama launch codex-app --restore

このコマンドを実行すると、Ollamaが連携前のCodexアプリの設定や構成を元に戻してくれます。もしCodexアプリが起動している状態であれば、再起動してよいかを確認してくることがあり、その指示に従えば復元が完了します。連携を試したあとで元の環境に戻したくなっても、こうした手段が用意されているため安心です。なお、この復元はアプリ版の設定が対象であり、CLI版の設定には影響しません。状態を行き来できる仕組みを知っておくと、気軽に連携を試せるようになります。元に戻す手段があるという前提は、最初の一歩を踏み出すうえでの心理的なハードルも下げてくれます。

設定ファイルの上書き前にバックアップが保存される保存先の確認事項

Ollamaは、Codexアプリの設定ファイルを書き換える前に、元の内容を自動でバックアップしてくれます。連携によって設定が上書きされても、以前の状態をたどれる仕組みが用意されているわけです。万一のときに元へ戻せる安心感があるため、初めての連携でも比較的気軽に試せます。バックアップは所定のディレクトリに保存されます。

保存先のディレクトリは、おおよそ次の場所が目安になります。

~/.ollama/backup/codex-app/

Windowsではこのチルダがユーザープロファイルのフォルダーにあたるため、実際のパスは環境によって読み替える形になります。どこにバックアップが置かれるかを把握しておけば、設定に問題が起きたときにも落ち着いて確認できるはずです。普段は意識する必要のない部分ですが、トラブル時の手がかりとして覚えておくと役立ちます。保存先を知っておくことは、安心して連携を運用するための小さな備えと言えるでしょう。手動で設定を見比べたいときにも、この保存先が出発点として役立ちます。

Codex CLI用プロファイルと混同しないため押さえる運用上の注意点

運用上の注意点として押さえておきたいのが、アプリ版とCLI版で設定プロファイルが別々に管理されているという点です。Codexアプリ向けの設定を変更しても、CLI版の設定はそのまま保たれ、互いに影響を及ぼしません。この分離のおかげで、片方をいじったつもりがもう片方まで変わってしまう、といった混乱を避けられます。CLI版を起動するコマンドはアプリ版とは別に用意されています。

たとえば、CLI版を扱う際に使うコマンドは次のように異なります。

ollama launch codex

このコマンドはCLI版のプロファイルを対象とし、アプリ版の設定とは切り離して管理されます。どちらのコマンドがどちらの設定に対応しているかを取り違えると、思ったとおりに切り替わらず戸惑う原因になりがちです。アプリ版を使いたいのか、CLI版を使いたいのかを意識し、対応するコマンドを選ぶことが運用を安定させるコツです。両者の違いを最初に整理しておけば、設定が交ざる心配なく安心して使い分けられます。コマンド末尾の違いを意識する習慣をつけておくと、取り違えはほとんど起こらなくなります。

よくある質問

OllamaのどのバージョンからCodexアプリに対応していますか?

公式ドキュメントでは、Codexアプリ対応は「Ollama v0.24.0以降」と明記されています。v0.24.0は2026年5月14日に公開されたバージョンで、それ以降であればより新しいバージョン(2026年7月時点の最新安定版はv0.31.2)でも同じ手順が使えます。古いバージョンのままではollama launch codex-appが利用できないため、まずバージョンを確かめ、要件を満たしていなければ公式サイトから更新してください。

Codex CLI版もOllamaのローカルモデルで動かせますか?

動かせます。CLI版はollama launch codex(アプリ版はcodex-app)を実行すると、モデルカタログの更新とCodex用プロファイルの適用が行われた状態でCLIが起動します。手動で設定する場合はcodex --oss -m gpt-oss:120bのように--ossフラグでローカルモデルを指定する方法もあります。エージェント動作ではコンテキスト長が効いてくるため、公式は64kトークン以上を目安として挙げています。

ollama launch codex-appを実行してもアプリが起動しません。どうすればよいですか?

セットアップ直後はアプリ側の初期状態が整っておらず、連携起動に失敗することがあります。この場合はCodexを一度手動で開いて正常に起動することを確認し、閉じてからollama launch codex-appを実行し直すと通ることが多いです。それでも改善しないときは、Ollamaがv0.24.0以降かどうか、アプリ本体が正しくインストールされているかを切り分けて確認します。

指定したモデルに切り替わらないときの対処法は?

Codexがすでに起動している状態でコマンドを実行すると、古い設定のまま動き続けてモデル指定が反映されないことがあります。Ollamaがアプリの再起動を促してきたら許可してください。確認が表示されない場合は、Codexを完全に終了させてからollama launch codex-app --model gemma4:31bのようにモデル名を添えて実行し直すと、新しい設定が読み込まれます。

Ollama連携をやめて元のOpenAIの構成に戻すには?

ollama launch codex-app --restoreを実行すると、Ollamaが書き換える前のCodexの設定へ復元されます。Ollamaは設定ファイルを変更する前にバックアップを~/.ollama/backup/codex-app/(Windowsではユーザープロファイル配下)に保存しているため、連携を試したあとで元の環境へ戻すのは容易です。CLI版のプロファイルとカタログを削除したい場合はollama launch codex --restoreを使います。

関連記事

資料請求

RELATED POSTS 関連記事