OpenClawをローカルLLMで動かすには？必要メモリ・Ollama・LM Studioの設定を整理

OpenClawは、ローカルモデルを自分でserverとして用意する方法に加えて、llama.cppを使うManaged local serverを選べる。2026年9月6日時点の公式Local models docsでは、hardwareに合わせて始める場合はManaged local serverが最初の選択肢として案内されている。

LM StudioやOllamaも引き続き正式対応している。すでに普段使っているlocal runtimeがあるなら、そのserverをOpenClawへ接続する構成も選べる。

OpenClawで注意したいのは、モデルが1回返答できることと、Agentとしてtoolを使いながら仕事を完了できることが同じではない点だ。tool schema、履歴、memory、browserやterminalの結果までcontextへ入るため、短いchatだけの動作確認では足りない。

3つの始め方

現行docsから整理すると、最初に比較するのは次の3経路だ。

方法	向いている状況	OpenClaw側の特徴
Managed local server	hardwareに合う構成をOpenClaw側で選びたい	llama.cpp plugin、hardware-aware recommendation、実tool call検証
LM Studio	GUIでmodelを入れ替えながら管理したい	native Responses APIを利用できる
Ollama	CLI・model library・常駐serviceを使いたい	native /api/chat providerを利用する

MLX、vLLM、SGLangやOpenAI-compatible proxyも使える。複数requestのthroughputや既存serverとの統合が必要な場合は候補になるが、最初のlocal setupを完了するだけならManaged local server、LM Studio、Ollamaの方が構成を絞りやすい。

Managed local serverで始める

OpenClaw公式docsは、hardware-awareな構成を使う手順として、llama.cpp pluginを導入したうえでopenclaw onboardを実行し、Managed local serverを選ぶ流れを案内している。

setupではdownloadを始める前に、Gateway host、model、download size、execution backendが表示される。さらに、default modelを書き換える前に実際のtool callを1回検証する。

この流れの利点は、modelが起動しただけで設定完了にしないことだ。OpenClawはAgentなので、tool callまで通るかをsetup gateに含めている。

必要VRAMは固定値では決められない

現行OpenClaw docsは「最低GPU VRAMは何GB」と固定していない。必要memoryは、model weight、context size、runtime、同じhost上で動く他のworkloadによって変わる。

ただし、NVIDIAが2026年9月3日に案内したOpenClaw Windows Appの最適化local model経路は別条件で、RTX GPUは24GB VRAM以上が対象とされている。これはOpenClawの全backendに共通する最低要件ではなく、NVIDIA・Microsoft・OpenClawがWindows向けに用意する簡略化されたsetup経路の条件だ。

Managed llama.cpp setupでは、特定PCを前提にする代わりに、次を確認する。

• 利用可能なRAM
• 対応GPU memory
• disk space

curated recipeは64K contextを使い、最小recipeには8GiBのhost-memory floorが設定されている。これは8GB VRAMで十分という意味ではない。公式docs自身が、このfloorはfitやspeedを保証しないと明記している。

custom serverを使う場合も、model weightだけでmemoryを使い切らず、OpenClawのprompt、tools、history、model outputまで入る余白を残す必要がある。

GPU容量そのものを比較する場合は、ローカルAI向けGPUのVRAM比較と量子化の基礎を分けて確認した方がよい。

LM Studioを使う場合

自分でmodel serverを管理したい場合、LM Studioは公式のlocal backendの1つだ。

OpenClaw docsでは、LM Studioでhardwareに収まるmodelをloadし、local serverを有効化して、Responses APIを使う構成が案内されている。LM Studioのdefault serverは次のaddressだ。

http://127.0.0.1:1234

model一覧は/v1/modelsで確認できる。OpenClaw側ではbackendが対応する場合にapi: "openai-responses"を使い、reasoningとfinal textを分けて扱う。

GUIでquantizationやmodelを交換しながら、どの構成なら長いAgent taskでも安定するか試したい場合に扱いやすい。

Ollamaでは/v1を付けない

OllamaもOpenClawの正式providerだが、接続方式に重要な制約がある。

OpenClawはOllamaのnative APIである/api/chatを使う。公式docsは、次のようなOpenAI-compatible endpointを使わないよう明示している。

http://host:11434/v1

このmodeではtool callingが壊れ、modelがtool-call JSONを通常のtextとして出力する場合がある。

Ollama providerへ接続する場合は、/v1を付けずserver base URLを指定する。

http://127.0.0.1:11434

普通のchatでは見逃せる互換性差でも、Agentではtool call失敗がtask失敗へ直結する。

modelが返答できた後にAgentとして検証する

local modelの確認は、段階を分けると原因を切り分けやすい。

1. model単体の応答を確認する

公式docsは、toolsやAgent contextを入れずにmodelだけを確認するprobeを用意している。

openclaw infer model run --local --model <provider/model> --prompt "Reply with exactly: pong" --json

ここで失敗する場合は、OpenClawのAgent loopより前にmodel serverやprovider設定を確認する。

2. Gateway routingを確認する

model単体が通ったら、Gateway経由でprovider selectionやauthを確認する。

openclaw infer model run --gateway --model <provider/model> --prompt "Reply with exactly: pong" --json

このprobeもまだ通常のAgent toolsや長いtranscriptを持たない。

3. 実際のAgent taskを試す

最後に、実際に使うtoolを含むtaskを試す。text-only probeが成功しても、tool call、context、memory pressureを含むAgent turnが成功する保証はない。

速度だけでなく、tool callの正確さ、task成功率、長いcontextでの安定性を確認してからdefault modelへ切り替える方が安全だ。

Tool Searchが小さいmodelのtool schemaを抑える

現行docsでは、local Ollama model、LM Studio、Managed local serviceは、tools.toolSearchが未設定ならstructured Tool Searchを自動利用する。

これは全tool schemaを最初からpromptへ詰め込まず、必要なtoolを検索して使うための仕組みだ。policyで許可されたcapabilityを維持しつつ、promptを抑えやすくなる。

旧来の「小型modelならlocalModelLeanを有効化する」という単純な整理には注意が必要だ。現行Local models docsは、optional toolを残したい場合はlocalModelLeanを未設定またはfalseにし、Tool Searchを使う流れを案内している。

context不足とmemory pressureを分ける

Agent turnが失敗した場合は、modelの能力不足だけでなく、contextとmemoryの両方を確認する。

OpenClawはmodel windowまたはcontextTokensからpreflight thresholdを計算し、contextが少なすぎる場合にwarningやhard blockを行う。LM StudioやOllamaのserverが途中で終了する場合は、同時刻のserver logとOpenClaw diagnosticsを照合し、memory pressureでprocessが落ちていないか切り分ける。

「modelがloadできた」ことは「長いAgent turnが安定する」ことの証明にはならない。

prompt injectionはlocal化しても残る

local modelには、hosted provider側のsafety filterがない。OpenClaw公式docsは、modelとtaskに合わせてtool permissionとprompt-injection防御を設定するよう求めている。

browserやmessageから入る外部textは、modelにとって命令に見える場合がある。model inferenceをPC内へ置いても、untrusted inputからtool実行へつながる攻撃面は消えない。

local化と同時に、sandbox、tool権限、外部入力の扱いも確認する必要がある。

local inferenceと完全offlineは別

LM Studio、Ollama、Managed local serverで推論をlocalにしても、OpenClawがbrowser、GitHub、Slack、Gmail、Web APIなどを使えばtool通信は外部へ出る。

hosted modelをfallbackに残せば、条件によってcloudへの推論requestも発生する。

完全offlineを目的にする場合は、model providerだけでなく、fallback、tool、plugin、browser、messaging channelを個別に確認する。

どの構成から始めるか

hardwareに合わせたmodel選択までOpenClaw側へ任せたいなら、llama.cpp pluginを使うManaged local serverが現行docsで最も直接的な入口だ。

すでにLM Studioを使っているならResponses API経由、Ollamaを使っているならnative provider経由で既存serverを活かせる。複数requestや独自serverが必要になってからMLX、vLLM、SGLangなどを比較すればよい。

必要memoryは固定のVRAM数字だけでは決められない。modelを起動した後にtext-only probe、Gateway routing、実Agent taskの順で確認し、tool callとcontextまで通った構成をdefaultにするのがOpenClawの現行local setupに合っている。