CodexとローカルモデルGemma 4を連携する方法

このガイドでできること

Codex CLIはオープンモデル用の実行経路を持ち、Ollamaをローカルプロバイダーとして選べます。モデルが端末に入っていること、Ollamaが応答すること、Codex側でモデル名を正しく渡すことが接続の三条件です。

三つの部品がそろって初めて動く

ローカルモデル連携は、Codexだけを入れれば終わる話ではありません。作業を受けるCodex CLI、モデルを起動するOllama、実際に文章を考えるGemma 4の三つが必要です。会社に例えるなら、Codexは仕事を配る窓口、Ollamaは担当者を呼び出す内線、Gemma 4は仕事をする担当者です。どれか一つが止まると、モデル名が見つからない、接続できない、返答が来ないという形で失敗します。

今回の確認では、Ollamaの一覧にGemma 4が表示され、Codexからそのモデルを選んで短い返答を得られるところまで実行しました。最初から長い仕事を渡さず、短い一言が返るかを確かめると、モデルがない問題と接続の問題を切り分けやすくなります。短い確認に成功してから、コピーしたテスト用フォルダで文章整理や分類へ進みます。

モデル名は一覧に出た表記をそのまま使う

Ollamaでは、同じモデル系列でもサイズや量子化の違いで名前が分かれます。Codexへ渡すモデル名は、記憶で書かず、Ollamaの一覧に表示された表記を使います。今回の動作確認ではgemma4:e4bという名前でした。別の端末では名前が異なる可能性があるため、記事の文字列を無条件に写すのではなく、自分の一覧を基準にします。

接続コマンドでは、Codexにオープンモデルを使うことを伝え、ローカルプロバイダーとしてOllamaを指定し、最後にモデル名を渡します。ここでクラウドのCodexと同じ品質や速度を期待すると、判断を誤ります。ローカルモデルは端末性能、メモリ、モデルサイズの影響を直接受けます。短い文章整理は快適でも、大きなコードベースの理解や長時間の自律作業では、応答速度や精度に差が出ます。使えるかどうかではなく、どの重さの仕事まで任せるかを小さく試すのが現実的です。

情報を外へ出しにくいことと安全は同じではない

ローカルモデルの大きな利点は、推論を自分の端末で動かせることです。ただし、ローカルで動くから自動的に安全になるわけではありません。Codexが読めるフォルダ、実行できるコマンド、ネットワークへ出られる範囲は別に管理する必要があります。金庫を社内へ置いても、鍵を誰でも使えれば安全ではないのと同じです。モデルの置き場所と、エージェントの権限を分けて考えます。

業務で使う場合は、最初にテスト用フォルダだけを対象にし、削除や外部送信を伴わない作業から始めます。結果が安定してから、読み取り範囲や処理量を広げます。機密文書を扱うなら、OllamaやCodexの設定だけでなく、端末の利用者、ログ、バックアップ、社内規程まで含めて判断します。ローカルモデルは情報管理の選択肢を増やしますが、組織のルールを不要にする仕組みではありません。

向く仕事と向かない仕事を先に分ける

Gemma 4のようなローカルモデルに向きやすいのは、文章の分類、定型的な整形、短い要約、下書き、繰り返し処理です。外部へ送りたくない素材を端末内で下処理し、難しい判断だけを人間や別のモデルへ回す使い方もできます。工場のラインで、単純な選別を手元の機械に任せ、例外だけを熟練者へ渡すイメージです。

一方、最新情報の調査、長い文脈の厳密な理解、複数ツールをまたぐ自律作業は、モデル能力と環境設定の影響が大きくなります。失敗を検知する仕組みがないまま重要作業へ使うべきではありません。まず同じ短い課題をクラウドモデルとローカルモデルへ渡し、正確さ、時間、修正回数を比べると使い分けが見えます。要するに、ローカルモデルはクラウドの代用品ではなく、情報、費用、速度を自分で配分するための別の作業レーンです。

一度通った短い課題と期待する答えを保存しておくと、モデルを更新した後も同じ条件で比べられます。速さだけでなく、答えの抜け、修正回数、端末の負荷を見ることで、その仕事をローカルへ任せ続けてよいか判断できます。

動作確認した入力例