OpenClawはローカルモデルで動作しますか？

はい。~/.openclaw/openclaw.json にOllamaまたはLM Studioをプロバイダーとして追加し、baseUrlをlocalhostに向けてください。OpenClawはローカルモデルをクラウドAPIと同じように扱うため、ツール呼び出しやワークフローも共通です。

OpenClawでローカルモデルを使うにはどんなハードウェアが必要ですか？

Qwen3.6 9B / 35B-A3B MoE：VRAM 8〜16GB、またはユニファイドメモリ16GB。Qwen3.6 27B（推奨）：VRAM 18〜24GB（RTX 5090）、またはユニファイドメモリ36GB以上（M5 Pro/Max）。Qwen3 Coder Plus / Llama 3.3 70B：RTX 5090×2、またはユニファイドメモリ96GB以上（M5 Max）。

OpenClawのコーディングに最適なローカルモデルはどれですか？

Qwen3.6 27Bが品質とハードウェア要件のバランスで最良です。SWE-bench Verifiedで77.2%、Terminal-Bench 2.0でもClaude Opus 4.5と同スコアを記録し、VRAM 18GBで動作します。軽量環境なら、アクティブパラメータが3Bだけで16GBでも高速なQwen3.6 35B-A3B MoEが候補です。

OpenClaw向けローカルLLM 2026年：Ollamaモデル7選ランキング

モデルをローカルで実行すれば、APIキーは不要で、従量課金もなく、自社のプロプライエタリコードを外部サーバーに送る必要もありません。一方で、レスポンスは遅くなり、難しい問題では品質も下がります。このトレードオフが許容できるかは、何をするかによって変わります。

「openclaw local model」や「openclaw local llm」で検索してここにたどり着いた方は、まずシンプルに始めてください。16GBマシンでは Gemma 4 8B か Qwen3.6 9B、24GB以上のGPU（RTX 5090単体またはM5 Pro）では Qwen3.6 27B を使い、ローカルモデルが行き詰まる作業に備えてクラウドへのフォールバックを1つ用意しておきます。OpenClawのローカル実行はもう実用的ですが、魔法の解決策ではありません。

2026年、状況を変えた出来事が2つあります。4月22日のQwen3.6リリースでは、SWE-benchで397B MoEを上回る27B Denseコーディングモデルが登場しました。AppleのM5 Max（2026年3月発表）は最大128GBのユニファイドメモリを備え、GPUコアごとにNeural Acceleratorを搭載し、70BクラスのモデルがノートPCで動くようになりました。OllamaがOpenClawの公式プロバイダーになったこともあり、セットアップはこれまでになく簡単になっています。

モデルランキング

OpenClawでのコーディング作業に使える現在のローカルモデルを、SWE-bench Verifiedスコア、ツール呼び出しの信頼性、実際のエージェント性能をもとにランキングしました：

モデル	パラメータ数	アクティブパラメータ数	必要VRAM	SWE-bench	速度（RTX 5090）	最適な用途
Qwen3.6 27B	27B	27B（Dense）	18GB以上	77.2%	約70 t/s	コーディング用途で品質とサイズのバランスが最良
Qwen3 Coder Plus	72B	72B（Dense）	48GB以上	70.6%	約30 t/s	最難関のコーディングタスク、フルエージェントループ
Qwen3.6 35B-A3B	35B	3B（MoE）	16GB以上	—	約180 t/s	速度重視の作業、高スループット
Qwen3.6 9B	9B	9B（Dense）	8GB以上	—	約186 t/s	エントリー向け、簡単なタスク
Llama 3.3 70B	70B	70B（Dense）	デュアルGPU	—	約27 t/s（5090×2）	汎用コーディング、指示追従性が高い
gpt-oss 20B	21B	3.6B（MoE）	16GB	—	約160 t/s	16GB環境のベストチョイス、推論強度を調整可能
Laguna XS 2.1	33B	3B（MoE）	24GB以上	—	高速（MoE）	エージェント型コーディング、ツール呼び出しループ
Gemma 4 8B	8B	8B（Dense）	8GB以上	—	約150 t/s	プライバシー重視、軽量構成
Qwen3 32B	32B	32B（Dense）	24GB以上	—	約60 t/s	実績のあるオールラウンダー

Qwen3.6 27Bが今回の主役です。 SWE-bench Verifiedは77.2%、Terminal-Bench 2.0は59.3%でClaude Opus 4.5と同スコア。VRAM 18GBで動作します。27BのDenseモデルがコーディングで397B MoEを上回るのは、3.6リリースでのアーキテクチャ変更、つまりGated Delta Networksと実際のPRを対象としたポストトレーニングの成果です。

35B-A3B MoEは意外な伏兵です。フォワードパスごとにアクティブになるパラメータが3Bだけなので、RTX 5090単体で約180 t/sを出します。難しい問題では27B Denseより品質は落ちますが、ファイル読み取り、ボイラープレート生成、簡単な編集ではクラウドAPIと遜色のない感覚で使えます。

新たに登場した注目モデルも3つあります。gpt-oss 20Bは16GBマシンでコミュニティの定番になっています。推論強度を調整できる小型MoEです。Laguna XS 2.1（Poolside）は、エージェント型コーディングループに特化した33B（アクティブ3B）のMoEです。Kimi K2.7 CodeはMoonshotの最先端に近いK2系統をOllamaに導入し、48GB以上の環境向けに提供されています。完全なオープンウェイト版Kimi K3は7月末に登場予定で、サーバークラスのハードウェアを使っている人向けです。

ハードウェア要件

ローカルモデルの品質はモデルサイズに比例し、モデルサイズは必要なハードウェアに比例します。以下では2026年時点のハードウェア、つまりNVIDIA側はRTX 50シリーズ、Apple側はM5を前提にしています。

VRAM 8〜16GB（エントリーレベル）

RTX 5060/5070、またはユニファイドメモリ16GB（M5ベース、M5 Proエントリー）。Qwen3.6 9Bと35B-A3B MoEには十分です。9Bは簡単なタスクとコード要約を、5090では約186 t/sで処理します。5070では約120 t/sを見込んでください。35B-A3Bはパラメータ数から想像するよりはるかに少ないメモリで動きます。フォワードパスごとにアクティブになるのは3Bだけだからです。

対象モデル：Qwen3.6 9B、Qwen3.6 35B-A3B、Gemma 4 8B

VRAM 18〜32GB（推奨）

RTX 5090単体（GDDR7 32GB、1,792GB/s） またはユニファイドメモリ36〜64GB（M5 Pro/M5 Maxベース）です。ローカルモデルが実務で実用的になるのはこの層からです。Qwen3.6 27Bは18GBで快適に動作し、SWE-benchスコア（77.2%）はトークン単位課金のクラウドモデルに匹敵します。

推論において意味を持つのは、RTX 5090の4090に対する帯域幅の向上（1,792GB/s対1,008GB/s、78%増）であり、生のFLOPSではありません。トークン生成はメモリ帯域幅に律速されるため、5090単体ではQwen 8Bで約186 t/s、14Bクラスでは124 t/sになります。

対象モデル：Qwen3.6 27B、Qwen3 32B、Qwen3.6 Plus（搭載可能な場合）

実効メモリ48GB以上（プレミアム）

RTX 5090×2（合計64GB）またはM5 Max 96〜128GBユニファイドメモリです。Qwen3 Coder PlusとLlama 3.3 70Bはここに属します。

構成は2つあります：

RTX 5090×2構成：vLLMのテンソル並列でLlama 70B Q4_K_Mを27 t/sで処理します。H100に迫る性能をはるかに低コストで得られるため、カードを2枚積めるデスクトップに最適です。
M5 Max 128GB MacBook Pro：70B Q4_K_Mモデル（ディスク上で約40GB）をユニファイドメモリに丸ごとロードでき、コンテキスト用の余裕も残ります。全GPUコアに組み込まれたAppleのNeural Acceleratorsにより、プロンプト処理はM4 Max比で3.3〜4倍速くなり、安定生成速度は約18〜25 t/sです。トレードオフは携帯性です。バックパックに入る唯一の構成でもあります。

対象モデル：Qwen3 Coder Plus、Llama 3.3 70B、Qwen3.6 Plus（フル精度）

ユニファイドメモリ128GBのM5 Maxは、ノートPCで本格的なローカル作業をするための新たな最適解です。AppleのMLXフレームワークはNeural Acceleratorサポートを含めて出荷されるようになり、GPUとNeural Engineが毎フォワードパスで並列動作します。

この層に合うハードウェアをお持ちでない場合も、haimakerを使えばOpenClawにクラウドルーティング用の単一エンドポイントを用意できます。ローカルモデルが得意な作業はローカルで処理し、対応しきれない作業だけクラウドモデルにフォールバックできます。

クラウドルーティングにHAIMAKERを試す

Ollamaのセットアップ

Ollamaはローカルモデルを動かす最も簡単な方法です。インストールしてモデルをプルすれば、localhost上でOpenAI互換APIがすぐに使えます。

# Install
curl -fsSL https://ollama.com/install.sh | sh

# Pull a model (pick one based on your hardware)
ollama pull qwen3.6:27b          # Best quality, needs 18GB+ VRAM
ollama pull qwen3.6:35b-a3b      # Fast MoE model, runs on 16GB
ollama pull qwen3.6:9b           # Lightweight, runs on 8GB
ollama pull qwen3-coder-plus     # Premium, needs 48GB+ or 96GB unified

OllamaのデフォルトのAPIエンドポイントは http://localhost:11434 です。

r/LocalLLaMAからのヒント： 27B以上のモデルでは、Ollamaからllama.cppへ直接切り替えた方がパフォーマンスが上がったという報告が複数あります。Ollamaは手軽ですが、llama.cppは量子化やメモリ割り当てを細かく制御できます。まずOllamaで始め、性能の壁にぶつかったらllama.cppへ移ってください。

OpenClawの設定

Ollamaが公式プロバイダーになったため、セットアップは簡単です。オンボーディングウィザードを実行します：

openclaw onboard --auth-choice ollama

または、~/.openclaw/openclaw.json にOllamaを手動で追加します：

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://localhost:11434/v1",
        api: "openai-completions",
        models: [
          {
            id: "qwen3.6:27b",
            name: "Qwen3.6 27B",
            reasoning: false,
            contextWindow: 131072,
            maxTokens: 8192
          }
        ]
      }
    }
  },
  agents: {
    defaults: {
      model: { primary: "ollama/qwen3.6:27b" },
      models: {
        "ollama/qwen3.6:27b": { alias: "qwen-local" }
      }
    }
  }
}

ローカルモデルに切り替えます：

/model qwen-local

ローカルモデルが得意なこと

Qwen3.6 27Bを数週間にわたってローカルで運用した結果、以下の点は実用に耐えると感じました。

コードの読み取りと要約。 関数の動作を尋ねると、しっかりした回答が返ってきます。Sonnet 4.6ほどきめ細かくはありませんが、初見のコードベースを把握するには十分です。
一般的なパターンのコード生成。 ボイラープレート、CRUD操作、設定ファイル、テストの雛形。ほとんどの場合、一発で動作するコードを書きます。3.6リリースは実際にマージされたPRでポストトレーニングされており、diffの品質にそれが表れています。
ファイル操作と単純なリファクタリング。 ファイル一覧の取得、パターン検索、ファイル内の変数名変更など、深い推論が不要な機械的タスク。
エージェント型ツール呼び出し。 Qwen3.6は関数呼び出しの信頼性を大きく引き上げました。Terminal-Bench 2.0の59.3%はClaude Opus 4.5と同スコアです。OpenClawのツールループでは、「誤った関数を誤った引数で呼び出す」エラーが減ることにつながります。

ローカルモデルが苦手なこと

複数ファイルにまたがるリファクタリング。 5つ以上のファイルにまたがるコンテキスト保持が必要になると不安定になります。モデルがコンテキストを見失うか、一貫性のない変更をします。200K以上のコンテキストウィンドウを持つクラウドモデルはここでは依然として優位ですが、Qwen3.6で差は縮まりました。
複雑なデバッグ。 複数の抽象化レイヤーをまたぐ推論が必要なバグでは、問題が深い箇所にあるのに表面的な修正を提案することがあります。Claude Opus 4.8はSWE-bench VerifiedでQwen3.6 27Bをいまだに約11ポイント上回り、Claude Fable 5は約18ポイント上回ります。
旧世代ハードウェアでのDenseモデルの速度。 27BモデルはRTX 5090単体で約70 t/s、M5 Maxで約22 t/sです。まだ3090や4090を使っている場合は30〜40 t/s程度を見込んでください（35B-A3B MoEの180 t/s超は例外です）。
非常に長いコンテキスト。 Qwen3.6は理論上256Kトークンまで対応しますが、一般向けハードウェアでは32Kを超えると推論品質が下がります。設定では contextWindow を現実的な値にしておきましょう。

ハイブリッドアプローチ

ローカルモデルを試した人の多くは、最終的にハイブリッド構成に落ち着きます。軽い作業はローカル、難しい作業はクラウドという使い分けです。

{
  agents: {
    defaults: {
      model: {
        primary: "ollama/qwen3.6:27b",
        thinking: "anthropic/claude-sonnet-4-6-20260514"
      }
    }
  }
}

ローカルモデルがファイル読み取り、簡単な編集、ボイラープレートを処理し、一般的なコーディングセッションの60〜70%をカバーします。デバッグ、アーキテクチャ判断、複数ファイルにまたがる作業はSonnetが担います。API料金は1日あたり数ドルに収まり、20〜50ドルもかかることはなくなります。

より高い能力が必要だと分かっているタスクでは、手動で切り替えます：

/model sonnet

またはHaimakerの自動ルーターでルーティングを自動化しましょう。自動ルーターはタスクの複雑さを検出し、難しい問題を自動でクラウドモデルに送るため、切り替えタイミングを意識せずに済みます。

トラブルシューティング

モデルの読み込みが遅い、またはクラッシュする。 メモリ不足の可能性が高いです。より低精度の量子化モデルを試してください。ollama pull qwen3.6:27b-q4_K_M は品質を少し落とす代わりにメモリ使用量を減らせます。Q4_K_Mは多くの人にとって最適解です。品質低下は最小限で、メモリ削減効果は大きいです。

ツール呼び出しが失敗する。 モデル設定に "reasoning": false を設定し、Qwen3.6モデルを使い続けましょう。Qwen3.6はMistralや旧世代のLlamaモデルよりOpenClawのツール呼び出し形式を安定して処理できます。それでも失敗する場合は、Ollamaを最新版へ更新してください。公式プロバイダー統合により、いくつかのエッジケースが修正されています。

コンテキストウィンドウエラー。 設定で contextWindow を正しく指定してください。Qwen3.6では、VRAM 24GB以上（RTX 5090単体なら余裕があります）なら131072（128K）が安全な既定値です。16GB環境では品質劣化を避けるため32768にしてください。

生成速度が遅い。 5090上の27Bモデルが40 t/s未満、またはM5 Maxで18 t/s未満なら、他のプロセスがGPUを使っていないか確認しましょう。WebGLや動画を再生しているブラウザタブは閉じてください。Macでは、アクティビティモニタ → GPU履歴でユニファイドメモリを消費しているプロセスを確認できます。M5ユーザーはOllamaがMLXバックエンド（v0.21以降）を使っているかも確認してください。MetalのみのパスとMLXパスでは、プロンプト処理に約2倍の速度差があります。

クラウドルーティングにHAIMAKERを試す

モデル料金の比較はOpenClaw向け最安モデルを、クラウドモデルのトークンコスト削減はQMDでコストを96%削減する方法をご覧ください。