コーディングエージェントにとって最適なOllamaモデルは、必ずしもダウンロードできる最大サイズのモデルではありません。エージェントは反復処理を行います。ファイルを読み、ツールを呼び出し、計画を修正し、パッチを生成する。この流れを繰り返します。1回のプロンプトでは良い結果を出すモデルでも、ツール呼び出しのたびに遅いローカル推論が挟まれば、すぐに使い物にならなくなります。
このランキングを実用的な出発点として使ってください。どのモデルをプルすべきか、どんなハードウェアが必要か、そしていつローカル推論を打ち切ってクラウドフォールバックへ切り替えるべきか。
クイックランキング
| 順位 | モデル | プルコマンド | 最適な用途 | 実行に必要なハードウェア |
|---|---|---|---|---|
| 1 | Qwen3 Coder 30B | ollama pull qwen3-coder:30b | ローカルコーディングエージェントのデフォルトとして最適 | 24GB以上のVRAMまたは32GB以上のユニファイドメモリ |
| 2 | Qwen3 30B | ollama pull qwen3:30b | 汎用エージェントタスク、推論、コードレビュー | 24GB以上のVRAMまたは32GB以上のユニファイドメモリ |
| 3 | Gemma 4 26B MoE | ollama pull gemma4:26b | 高性能ワークステーションでの高速ローカルコーディング支援 | 24GB以上のVRAMまたは32GB以上のユニファイドメモリ |
| 4 | Kimi K2.7 Code | ollama pull kimi-k2.7-code | 本格的なハードウェアでの最先端モデル系譜のコーディング | 48GB以上のVRAMまたは96GB以上のユニファイドメモリ |
| 5 | gpt-oss 20B | ollama pull gpt-oss:20b | 16GB環境での最有力候補、推論強度の調整が可能 | 16GBのVRAMまたはユニファイドメモリ |
| 6 | Gemma 4 E4B | ollama pull gemma4:e4b | 軽量なノートPCでの利用 | 16GBのユニファイドメモリ |
| 7 | Qwen3 8B | ollama pull qwen3:8b | 小さな編集やコード解説 | 8〜16GBのメモリ |
1つだけ試すなら、Qwen3 Coder 30Bを選んでください。Ollamaのページではコーディングおよびエージェント型モデルとして紹介されており、256Kコンテキストに対応しています。コーディングエージェントが実際に行う作業、つまりコードの読み取り、ツールの使用、長いタスクにわたる状態の維持に合わせて設計されています。
マシン別の選び方
8〜16GBメモリ
gpt-oss 20B、Qwen3 8B、またはGemma 4 E4Bを使いましょう。gpt-oss 20Bはリリース以来、16GB環境のコミュニティ定番になっています。メモリ予算に収まり、タスクごとに推論の強弱を調整できます。
このクラスが得意な作業:
- 見慣れないコードの解説
- 小さな関数の作成
- テストの下書き
- 設定ファイルの生成
- ログの要約
このクラスで信頼性の高い複数ファイルのリファクタリングは期待しないでください。小さいモデルでも役立つコードは書けますが、エージェントがファイルを開き、パッチを修正し、ツール出力をさばき始めると、すぐに文脈を見失います。
24〜32GBメモリ
Qwen3 Coder 30B、Qwen3 30B、またはGemma 4 26B MoEを使いましょう。
ここが実用的なローカルエージェントのクラスです。リポジトリの文脈を追える大きさがありながら、本格的なデスクトップGPUやメモリ多めのMacで動く小ささでもあります。多くの開発者にとって、Ollamaが物珍しさを超えて日常のワークフローに入ってくるのはこのクラスからです。
64GB以上のメモリ
より大きなQwenやDeepSeekのバリアントは、その理由が明確な場合だけ試してください。
ライブラリ内の最大モデルを追いたくなるものですが、エージェント用途ではたいてい誤った判断です。巨大なローカルモデルは技術的に印象的でも、エージェントの試行ループを遅くしすぎることがあります。本当に推論力や文脈長が必要なタスクでは大きいモデルが役立ちますが、エージェントがファイル読み取りやボイラープレート作成、テストの下書きしかしていないなら、それは単なる足かせです。
プロバイダーごとにAPIキーを管理せず、ローカルファーストかつクラウドフォールバックの構成を実現したいですか? haimakerなら、シンプルなコーディングエージェントの作業はローカルモデルへ回し、難しいタスクだけを1つのエンドポイント経由でクラウドモデルにエスカレーションできます。
HAIMAKERでローカルとクラウドモデルをルーティング総合1位:Qwen3 Coder
Qwen3 Coderは、ローカルコーディングエージェント環境で最初に試してほしいモデルです。
プル方法:
ollama pull qwen3-coder:30b
簡単な動作確認:
ollama run qwen3-coder:30b "Explain this repo structure and suggest where tests should live."
1位に選んだ理由:
- コーディングおよびエージェント型ワークフロー向けに明示的にチューニングされています。
- Ollamaのページには
ollama launchのサポートが記載されており、Claude Code、Codex、OpenCode、OpenClawに対応しています。 - 30B版は480B版よりローカルでの実用性がはるかに高いです。
- 長文コンテキストに対応しているため、従来のローカルコードモデルよりリポジトリ作業に向いています。
コードレビュー、テスト生成、中規模のリファクタリング、プライバシーを重視するローカルファーストのエージェントセッションに使いましょう。
ベスト軽量モデル:Gemma 4
Gemma 4は、Qwen3 Coderが重すぎる場合に試したいモデルファミリーです。小型のGemma 4バリアントはローカル/オンデバイス利用向けに設計されており、26B MoE版はトークンごとに全パラメータを計算に回すことなく、ワークステーション向けの高い性能を提供します。
ノートPC向けの軽量版をプル:
ollama pull gemma4:e4b
より強力なワークステーション版をプル:
ollama pull gemma4:26b
Gemma 4は、コード解説や小さな編集、プライベートなコードを対象に、高速なローカル支援がほしい場合のコーディングエージェントに適しています。エージェントがマイグレーション計画全体を正確に把握し続けるような長い自律セッションにはあまり向きません。
最新モデル:Kimi K2.7 CodeとLaguna XS 2.1
この夏、コーディングに特化した2モデルがOllamaライブラリに登場しました。どちらも注目に値します。
Kimi K2.7 Codeは、MoonshotがK2.6系列を基にコーディング向けへチューニングしたビルドです。同じファミリーのK3はアリーナリーダーボードで、クローズドな最先端モデルを上回っています。本格的なハードウェア(48GB以上のVRAMか大容量メモリのMac)が必要ですが、それが用意できるなら、現在ローカルで実行できるオープン系コーディングモデルとして最強クラスです。
ollama pull kimi-k2.7-code
Laguna XS 2.1は、Poolsideのエージェント型コーディングMoEです。総パラメータ数は33Bですが、トークンあたりのアクティブパラメータは3Bしかないため、サイズから想像できないほど軽快に動きます。コーディングエージェントが繰り返し実行するツール呼び出しのループに特化して設計されています。
以前のバージョンのこのガイドでDeepSeek Coder V2を使っていた方は、使用をやめて乗り換えてください。現在の選択肢から2世代遅れており、コミュニティのランキングからも完全に姿を消しています。
これらのモデルの活用場所
- haimaker.ai - ローカルのOllamaモデルとより強力なクラウドモデルを併用し、シンプルな作業はローカルへ、難しいタスクは有料モデルへルーティングできます。
- OpenClaw - コーディングエージェントセッションのローカルプロバイダーとしてOllamaを利用できます。詳しくはOpenClawローカルモデルガイドを参照してください。
- OpenCode - OpenAI互換プロバイダーとしてOllamaを追加できます。詳しくはOllamaとOpenCodeの連携を参照してください。
- CodexとClaude Code - Ollamaのモデルページには
ollama launchの例も掲載されており、CodexやClaude Codeなどのエージェントランタイムに対応しています。
OpenAI互換エージェントのセットアップ
ほとんどのコーディングエージェントは、OllamaのローカルOpenAI互換エンドポイントを通じて利用できます。
http://localhost:11434/v1
ツールがAPIキーを要求する場合は、ダミーのキーを設定してください。Ollamaはローカルではキーを検証しません。
{
"baseURL": "http://localhost:11434/v1",
"apiKey": "ollama",
"model": "qwen3-coder:30b"
}
OpenCodeの場合、プロバイダーブロックは以下のとおりです。
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen3-coder:30b": {
"name": "Qwen3 Coder 30B"
}
}
}
}
}
ツール呼び出しが不安定な場合は、まずモデルサイズを下げ、そのうえでハードウェアが耐えられる範囲にコンテキストを広げてください。メモリスワップが発生する巨大なコンテキストウィンドウは、応答性を保てる小さいウィンドウより実用性で劣ります。
Ollamaを使うべきでない場面
ローカルモデルが真価を発揮するのは、プライバシー、コスト、オフライン動作が重要な場合です。すべてのコーディングタスクで自動的に優れているわけではありません。
クラウドモデルを使うべき場面:
- 多数のファイルにまたがるタスク
- バグが微妙で再現しにくい場合
- 確実に動くツール呼び出しが必要な場合
- パッチが本番システムに影響する場合
- 生成されたすべての行をレビューする時間がない場合
実用的なセットアップはローカルファーストであって、ローカルオンリーではありません。安く済ませたいプライベートな作業にはQwen3 CoderやGemma 4を使い、トークンよりもレビューや確認の手間が増えてきたら、より強力なクラウドモデルにエスカレーションしましょう。
OpenClaw固有のローカルセットアップについては、OpenClaw向けベストローカルモデルを参照してください。OpenCodeのセットアップについては、OllamaとOpenCodeの連携を参照してください。