はじめに
本記事では、ローカルLLM(今回はOllama)をCodex CLIやClaude Codeで駆動するための方法についてまとめる。
前提とし、既にCodexまたはClaudeのどちらかのCLI環境は既に構築されているものとする。
背景
詳細はこちらの記事を参照してほしいが、事の起こりは、筆者が普段通り個人開発を楽しんでいた時のことだった。
筆者はchatGPT Plusを契約しており、Codexをプライベートでは常用しているのだが、ふとAI駆動開発というものを経験してみようと思い立ったのだ。
そこでこちらの記事にあるようなプロンプトを試してみたところ、Codexの制限に簡単に達してしまった。
前記事で解決できたのは、仕様不足や終了条件の曖昧さによって、エージェントが任意の地点で作業を終了してしまう問題である。
一方、今回直面したのは、長時間作業を実現した結果として発生したクラウドサービス側の利用上限である。
これはまずい。これから先、CodexやClaudeなど、LLMの性能は格段に上がっていくことは容易に想像できるが、できることの拡張に伴い、トークン数の消費は膨大となっていくことも想像に難くない。
そこで、筆者はローカルLLMを試してみることを思いついた。
今回はローカルLLMツールのOllamaを活用してみた記事となる。
注意
本記事では安全性を優先し、権限確認を完全に無効化するオプションは使用していない。
そのため、長時間作業中であっても、新しい種類のコマンドや重要なファイル操作について承認待ちとなり、一時的に作業が停止する可能性がある。
ここでいう長時間駆動とは、すべての操作を無条件に許可した完全無人運転ではなく、事前に許可された範囲で継続的に作業させる運用を指す。
Ollamaの導入
Ollamaの公式ページはこちらである。
筆者の私用PCはWindowsであるため、Powershellにて以下のコマンドを実行する
irm https://ollama.com/install.ps1 | iex
これにて、Ollamaの自体のインストールが完了する。
続いて、筆者はコーディング用途として導入を行ったため、筆者のPC環境で最も快適に動くコーディング用モデルとしてQwen2.5-Coderの14Bモデルを使用しすることとした。
こちらの導入コマンドは以下のよう
ollama pull qwen2.5-coder:14b
筆者のGPUのVRAMが16GBモデルのため、普段の作業では14Bを使用することで、快適に動かそうという魂胆である。
難解な作業の際に、RAMへのオンロード時間が発生することを許容するのであれば、32Bモデルなどの使用も選択肢には入るであろう。
こちらはプロンプトで制御し、難解な作業だと判断したら使用するモデルを切り替えるような指示を書けば、後述するクラウドLLMへの切り替えの前に数段ローカルLLMを挟むことも可能である。
モデル選定は現在公開されているモデルの中で自分のGPU性能などと相談し、普段の自分の作業を考慮して最も賢い選択を取られたし。
モデルのインストールが完了後、
# バージョン確認
ollama --version
# OllamaのローカルAPIが気道しているかどうか確認
curl http://localhost:11434/api/tags
curlコマンドを実行してモデルの一覧が返ってくれば成功である。
以下のコマンドを実行すればOllamaにてインストールしたモデルが立ち上がるようになっているはずである。
ollama run qwen2.5-coder:14b
例えば以下のような文言を入力すると、システム設定を変更することができる。
>>> /set system あなたは日本語で回答する熟練ソフトウェアエンジニアです。質問には具体的なコード例を添えてください。
ここからOllamaのCLI上で自由にチャットコミュニケーションを行うことができる。
なお、今回筆者が導入したモデルはコーディング用のモデルのため、雑談を期待するとずっこけることとなる。気になる方は試されたし。
Codex CLI / Claude Codeと接続
今回、PCにローカルLLMツールのOllamaを導入したが、CLIツールの使い勝手をCodex CLI / Claude Codeに寄せつつ、これらのエージェント機能を用いることが可能である。
つまり、ファイル操作などの作業やコマンド実行はCodex CLI/Claude codeに行わせ、コード生成や大量作業・テスト・定型修正などの軽量なタスクはローカルLLMで請け負い、難しい設計タスクや解決の糸口がなかなか見つからないバグ・ローカルLLMの吐き出したコードのレビュータスクなどをクラウドLLMとしてのCodex/Claudeに行わせることで、トークンの消費を削減しようということである。
まずは、任意のCLIツール上でインストールしたローカルLLMモデルを使用してみる。
今回はQwen2.5-coder 14Bモデルを使用したため、コマンドは以下のように実行することで、Codex CLI / Claude Codeにて任意のモデルを実行できるようになる。
なお、注意点として、こちらのモデルはthinking非対応である。そのため、筆者はthinking対応であるqwen-3.5:9Bモデルを別途インストールしてモデルのオーケストレーションを記述し、それを用いている。
筆者はWSLからWindowsで動いているOllamaのモデルを使用し制御しているが、こちらは環境によって対応が異なってくるためこちらでは割愛することとする。
tomlファイルを複数設定することで
codex --strict-config
とするだけで立ち上がるように設定することが可能であり、筆者は現在この環境で作業を行っている。
Codex CLI
codex --oss --local-provider ollama -m qwen2.5-coder:14b
こちらを実行することでCodex CLI環境にてメインモデルの接続先をOllamaとし、ローカルLLMモデルを立ち上げることが可能となる。
次に、クラウド処理用のCodexサブエージェントを作成する。
以下一例。
Codexでは、ユーザー単位のカスタムエージェントを「~/.codex/agents」ディレクトリ下に配置できる。
こちら、「~/.codex/agents/cloud-expert.toml」などの名前でTOMLファイルを作成し
name = "cloud_expert"
description = """
複雑な設計、難しい不具合、セキュリティ上重要な変更、
またはローカルモデルが複数回失敗した場合だけ利用する
クラウドモデルのエージェント。
"""
model_provider = "openai"
model = "gpt-5.6"
model_reasoning_effort = "high"
developer_instructions = """
あなたは難易度の高い処理だけを担当する上位エージェントです。
作業を始める前に、次の情報を確認してください。
- ユーザーの最終目的
- 現在のgit status
- 現在のgit diff
- ローカルエージェントが試した内容
- 発生しているエラーとログ
- 関連するテストコード
ローカルエージェントの変更を無条件に破棄しないでください。
必要最小限の変更を実施し、関連するテスト、型チェック、
Lintを実行してください。
完了時には次を報告してください。
- 原因
- 採用した実装方針
- 変更したファイル
- 実行した検証
- 残っている問題
"""
このように、cloud_expertエージェントを作成し、プロジェクト下で使用することができる。
また、通常のCodex CLIにてchatGPTアカウントまたはAPIキーにて認証することを忘れぬよう。
こちらのTOMLファイルを作成後、プロジェクトルートにあるAGENTS.mdに振り分けルールを記述する。
以下一例
# AIエージェント運用ルール
## 基本方針
通常の調査、実装、テスト、修正はメインエージェントで行うこと。
メインエージェントはOllama上のローカルモデルとして動作しているため、
可能な限り自分で作業を完了すること。
## ローカルで処理する作業
次の作業は原則としてローカルで処理すること。
- 既存パターンに従った実装
- CRUDやAPIルートの追加
- 型エラーやLintエラーの修正
- 単体テストの追加
- 小規模なリファクタリング
- ドキュメントの更新
- エラーログから原因が明確に分かる不具合
- 影響範囲が限定されたUI修正
## クラウドへ委譲する条件
次のいずれかに該当する場合だけ、
cloud_expertサブエージェントへ委譲すること。
- 認証、認可、暗号、決済、秘密情報を扱う
- データ消失の可能性があるDBマイグレーション
- 複数サービスをまたぐ設計変更
- 影響範囲が5モジュール以上に及ぶ
- 既存仕様と新しい要求が矛盾している
- 原因を特定できない不具合
- 異なる方法を2回試しても解決しない
- セキュリティレビューが必要
- 実装方針に重大な不確実性がある
## 委譲時の手順
cloud_expertへ委譲する前に、次の情報を整理すること。
1. 最終目的
2. 現在判明していること
3. すでに試した内容
4. エラーメッセージとログ
5. 現在のgit diff
6. 変更してはいけない箇所
7. 完了条件
cloud_expertが作業中の間は、同じファイルを編集しないこと。
cloud_expertの完了後に差分を確認し、必要なテストを再実行すること。
Codexは、明示的な指示だけでなく、AGENTS.mdやスキルに書かれた指示に従ってサブエージェントを起動できる。
サブエージェントは別コンテキストで作業し、結果を親エージェントへ返す。
さて、いよいよ先ほどのコマンドにてCodex CLIをメインモデルの接続先をOllamaとして起動する。
以下プロンプト例
この機能を実装し、関連するテストまで完了してください。
通常の調査、実装、テスト、修正はローカルモデルで進めてください。
AGENTS.mdに定義されたクラウド委譲条件に該当する場合だけ、
cloud_expertサブエージェントへ委譲してください。
cloud_expertを起動するときは、現在の目的、試した内容、
エラー、git diff、完了条件を必ず渡してください。
クラウドエージェントとローカルエージェントが
同じファイルを同時に編集しないようにしてください。
最後にテスト、型チェック、Lintを実行し、
変更内容と検証結果を報告してください。
確実にクラウドモデルに依頼したい問題はこのときに明示してやるとよい。
Claude Code
ollama launch claude --model qwen2.5-coder:14b
Claude Codeの場合、Codex CLIとは異なり、Ollamaをメインモデルの接続先に据えて1プロセス内でサブエージェントだけAnthoropicへ戻す構成は組みにくい。そのため、ローカル作業とクラウド作業のセッションは分けるほうが安全である。というのも、Claude Codeのサブエージェントにはmodelを指定できるが、この項目が変更するのはモデル名であり、接続先プロバイダそのものではない。そのため、ローカルLLMに前段として通常の実装・調査・テストを行わせ、エスカレーション資料を作成させ、その後に別セッションを立ち上げてクラウドClaude Codeを別セッションで起動し、むずかしい部分のみを実装させる、といったことが必要となる。
もし、Codexのように1つのClaude Codeセッションにてプロバイダーの自動切換えまで行いたい場合、モデル名によって接続先を振り分けるLLM Gatewayが必要となる。
(Codexにおいてもバージョンによってはプロバイダ切り替えがうまくいかないバグは報告されているため、こちらうまく行かない場合は同様に安定構成である2セッション構成を試されたし)
続いて、CLAUDE.mdにローカル用の運用ルールを記述する。
以下一例
# ローカルLLM運用ルール
現在のセッションはOllama上のローカルモデルで動作している。
## ローカルで担当する作業
次の処理はこのセッションで完了すること。
- コードベースの調査
- 既存実装に従った機能追加
- CRUDの実装
- 型エラーやLintエラーの修正
- テストコードの追加
- 小規模なリファクタリング
- ドキュメント更新
- 再現手順が明確な不具合修正
## クラウドへエスカレーションする条件
次のいずれかに該当する場合は、
推測で実装を続けず、クラウドエスカレーションを要求すること。
- 認証、認可、暗号、決済に関係する
- DBデータを破壊する可能性がある
- 複数サービスの設計判断が必要
- 異なる方法を2回試しても解決しない
- 原因を特定できない
- 要件同士が矛盾している
- セキュリティレビューが必要
- 大規模なアーキテクチャ変更が必要
## エスカレーション手順
クラウドでの判断が必要になったら、作業を一旦停止すること。
`.claude/escalation.md`を作成し、次の情報を記録すること。
- 最終目的
- 現在の実装状況
- 関連ファイル
- すでに試した方法
- 発生しているエラー
- 重要なログ
- 現在のgit diffの概要
- 変更してはいけない部分
- クラウドモデルへ質問したい内容
- 完了条件
資料を作成したら、それ以上コードを変更せず、
クラウドClaude Codeでの確認が必要だと報告すること。
ローカルLLM(Ollamaセッション)でのプロンプト一例
この機能を実装し、関連テストまで実行してください。
通常の調査、実装、テスト、修正はローカルで進めてください。
CLAUDE.mdのエスカレーション条件に該当した場合は、
推測で作業を続けず、.claude/escalation.mdを作成してください。
エスカレーション資料を作成したあとはコード編集を止め、
クラウドモデルへ確認すべき内容を報告してください。
次に、クラウドClaude用のカスタムサブエージェントを作成する。
.claude/agents/cloud-expert.mdを作成し、マークダウンに記述する。
以下一例
---
name: cloud-expert
description: 複雑な設計や難しい不具合だけを担当するクラウドエージェント
model: opus
permissionMode: default
---
あなたは難易度の高い開発タスクを担当するエージェントです。
最初に次を確認してください。
- CLAUDE.md
- .claude/escalation.md
- git status
- git diff
- 関連するソースコード
- 関連するテストコード
ローカルモデルの変更を無条件に破棄しないでください。
エスカレーション資料に書かれた問題だけを解決してください。
必要最小限の変更を行い、関連するテスト、型チェック、
Lintを実行してください。
最後に次を報告してください。
- 原因
- 採用した方針
- 変更したファイル
- 検証結果
- 残っているリスク
こちらのサブエージェントを利用する際、以下のコマンドを実行すると作成したサブエージェントを読み込むことができる。
claude --agent cloud-expert
また、通常のClaude Codeを起動し、明示的に以下のように依頼することでもサブエージェントを利用可能である。
.claude/escalation.mdを読み、
現在のgit statusとgit diffを確認してください。
ローカルモデルが解決できなかった部分だけを担当し、
必要最小限の変更を実施してください。
変更後は関連するテスト、型チェック、Lintを実行し、
原因、変更内容、検証結果、残っている問題を報告してください。
まとめ
現時点では、ローカルセッションがエスカレーション資料を作成し、別のクラウドセッションがその資料とgit diffを確認して作業を引き継ぐ構成が、Codex CLIとClaude Codeの双方で再現性が高い。
セッションを分ける方式には手作業が一段増えるものの、ローカルモデルが何を試し、どこで失敗し、クラウドモデルが何を引き継いだのかが明文化される。
注意点として、ローカルLLMはクラウドLLMを完全に置き換えるものではない。
大量の定型作業をローカルへ任せ、高度な判断が必要な場面だけクラウドモデルと人間が介入することで、利用枠、コスト、品質のバランスを取りやすくなるというのが本記事の趣旨である。
長時間AIを動かす上で重要なのは、単に「最後まで作業せよ」と命令することではなく、仕様、完了条件、検証方法、進捗記録、停止条件、そして引き継ぎ方法をあらかじめ設計することである。