OpenClawをOllamaにつなぐ設定そのものは、環境変数1行とモデル指定1行、合計2コマンドで終わります。実務で時間を取られるのはその後です。2026年5月に公表されたOllamaの脆弱性CVE-2026-7482（CVSS 9.1、通称Bleeding Llama）は0.17.1で修正済みで、現行の最新版は2026年9月2日公開のv0.33.3。まずここまでバージョンを上げ、11434番ポートをループバックに閉じ、OpenClaw側のツール権限とシークレットを締める——ローカルLLM運用のセキュリティは、この3段階でほぼ決まります。
Claudeのサブスクリプション経由でのOpenClaw利用が遮断され、API課金への移行を迫られた経緯はClaude OpenClaw遮断｜API移行と削減戦略にまとめました。その続きとして現実的な選択肢に浮上したのが、手元のマシンで動かすローカルモデルです。ただしローカルは「安いから安全」ではありません。ホスト型プロバイダが持っている安全フィルタが外れるぶん、権限設計とネットワーク境界を自分で引き直す必要があります。この記事では、2026年9月時点の公式ドキュメントで実在を確認できた設定キーとコマンドだけを使って、接続から法人向けの締め方までを順に追います。
ローカル運用が効くのは、この3ケースに絞られる
最初に期待値を合わせておきます。OpenClawをローカルモデルで動かす価値がはっきり出るのは、次の3つの場面です。
- データを外に出せない: 社内文書や顧客情報をプロンプトに載せる用途。OpenClaw公式ドキュメントは、ローカル専用構成を「依然として最も強力なプライバシー経路」と位置づけています。
- APIの従量課金を止めたい: 常時稼働のエージェントや定期実行のジョブなど、トークン消費が読みにくいワークロード。
- 外部サービスの利用条件に振り回されたくない: プロバイダ側の規約変更やアクセス遮断で運用が止まるリスクを、自分のハードウェア側に寄せたい場合。
逆に、ローカルへ全面移行すると失うものも公式に明記されています。OpenClawのローカルモデル解説ページは「ローカルモデルはホスト型プロバイダの安全フィルタを提供しない。モデルとタスクに見合ったツール権限とプロンプトインジェクション対策を維持すること」と書いています。加えて、reasoning-compatやプロンプトキャッシュ、storeといったOpenAI固有機能は使えず、ツール呼び出しの信頼性はモデルによってばらつき、構造化された呼び出しの代わりにテキストを吐くモデルもあります。メモリ逼迫で推論サーバーがターンの途中で落ちることもある、とも書かれています。
だから現実的な着地点は「全部ローカル」ではなく、OpenClawが公式にサポートする3モードのどれを採るかという判断になります。ひとつのOllamaホストでローカルモデルと:cloudモデルの両方を扱うCloud + Local、ローカルデーモンを持たずhttps://ollama.com へ直接つなぐCloud only、ローカルモデルだけのLocal onlyの3つです。機密度の高いタスクだけをLocal onlyに寄せ、それ以外はクラウドへ流す、という切り分けが最も運用しやすい形になります。
Ollama側の準備は、バージョンを上げるところから始める
接続設定を書く前に、Ollamaを最新に上げてください。順番を逆にしないことが重要です。2026年5月、セキュリティ企業Cyeraが公表したCVE-2026-7482は、GGUFモデルローダのヒープ領域外読み取りの脆弱性で、CVSSスコアは9.1。/api/createエンドポイントが受け取るGGUFファイルで、宣言されたテンソルのオフセットとサイズが実ファイル長を超えているとき、量子化処理がヒープバッファの外を読んでしまいます。漏れうるメモリ内容には環境変数、APIキー、システムプロンプト、同時接続している他ユーザーの会話が含まれ、生成されたモデル成果物を/api/pushで攻撃者のレジストリへ送ることで持ち出しまで成立する、という構造です。
この2つのエンドポイントは、上流の配布物では認証を持ちません。Ollamaはもともとローカルマシンで動かす前提のツールとして設計されており、認証機構が組み込まれていないためです。つまり、Ollamaに今後見つかる脆弱性は自動的に「認証不要」で成立します。修正はv0.17.1で入りました。執筆時点の最新版は2026年9月2日公開のv0.33.3です。
# 現在のバージョンを確認する
ollama --version
# 動作確認（デーモンが生きていればモデル一覧が返る）
curl http://127.0.0.1:11434/api/tags
次にモデルを選びます。Ollama公式のOpenClaw連携ページが挙げている推奨モデルは以下のとおりです。VRAMの目安も公式表記のままです。
| モデル | 種別 | 公式の説明 | 目安 |
|---|---|---|---|
gemma4 |
ローカル | ローカルでの推論とコード生成 | VRAM 約16GB |
qwen3.5 |
ローカル | 推論・コーディング・視覚理解をローカルで | VRAM 約11GB |
kimi-k2.5:cloud |
クラウド | サブエージェントを伴うマルチモーダル推論 | ローカルVRAM不要 |
qwen3.5:cloud |
クラウド | 推論・コーディング・視覚付きエージェント的ツール利用 | ローカルVRAM不要 |
ここで見落とされがちなのがコンテキスト長です。Ollamaのデフォルトのコンテキストウィンドウは4,096トークンですが、Ollama公式のOpenClawページは「OpenClawはより大きなコンテキストウィンドウを必要とする。ローカルモデルを使う場合は最低64kトークンのコンテキストウィンドウを推奨する」と明記しています。デフォルトのまま動かすと、ツール定義と会話履歴だけで枠を食い潰し、エージェントが指示を忘れたように振る舞います。
# サーバー起動時にコンテキスト長を上げる
OLLAMA_CONTEXT_LENGTH=65536 ollama serve
# モデルの取得
ollama pull gemma4
環境変数の入れ方はOSごとに違います。macOSはlaunchctl setenvで設定してアプリを再起動、Linuxはsystemctl edit ollama.serviceで[Service]セクションに追記、Windowsは設定またはコントロールパネルの環境変数から登録してOllamaを再起動する、というのが公式FAQの手順です。ここを systemd のユニットに書かずにシェルだけで設定すると、再起動後に元の4,096へ戻っていて「なぜか急に賢くなくなった」という事故になります。
Ollama単体の基本操作やモデル選定はOllamaの使い方 2026｜ローカルLLMでAIエージェントで扱っているので、モデルの選び分けに迷う場合はそちらを先に読んでおくと判断が早くなります。
OpenClaw側の接続設定は、実質2コマンドで通る
OpenClawはOllamaのネイティブAPI（/api/chat）と話します。ここが最大の落とし穴で、公式ドキュメントは「/v1のOpenAI互換URL（http://host:11434/v1）を使ってはいけない。ツール呼び出しが壊れ、モデルが生のツール呼び出しJSONをプレーンテキストとして吐くことがある」と警告しています。他のOpenAI互換プロバイダの設定例をコピーしてくると、まずここで踏みます。baseUrlには/v1を付けません。
最短経路は環境変数を1本立てて、モデルを指定するだけです。
# ローカル／LAN のOllamaに対しては、このマーカートークンで通る
export OLLAMA_API_KEY="ollama-local"
# 検出されたモデルを確認して選ぶ
openclaw models list --provider ollama
openclaw models set ollama/gemma4
OLLAMA_API_KEYが設定されていて、かつmodels.providers.ollamaの明示設定が存在しない場合、OpenClawはhttp://127.0.0.1:11434からモデルを自動検出します。カタログの取得は/api/tags、能力の判定は/api/showで、コンテキストウィンドウ、Modelfileのnum_ctxパラメータ、vision・tools・thinkingといったcapabilityを読み取ります。ここで重要なのは、自動検出に出てくるのはツール対応を申告したモデルだけだ、という点です。目当てのモデルが一覧に出ないときは、多くの場合ツール呼び出しにネイティブ対応していません。その場合は設定ファイルのmodels.providers.ollamaに手で定義すれば使えます。
接続先を明示したい場合、あるいは別マシンのGPUボックスにつなぐ場合は、設定を書き下します。
{
models: {
providers: {
ollama: {
baseUrl: "http://gpu-box.local:11434",
apiKey: "ollama-local",
api: "ollama",
timeoutSeconds: 300,
models: [
{
id: "qwen3.5:9b",
name: "qwen3.5:9b",
params: {
num_ctx: 32768,
keep_alive: "15m"
}
}
]
}
}
}
}
主要なキーの役割を整理しておきます。
| キー | 役割 | 注意点 |
|---|---|---|
baseUrl |
Ollamaサーバーのエンドポイント | /v1を付けない。新規設定はbaseURLではなくbaseUrlを使う |
apiKey |
認証値 | ループバックとプライベートネットワークは"ollama-local"というマーカーで足りる |
api |
APIの種類 | Ollamaは"ollama"を指定する |
timeoutSeconds |
HTTPリクエスト全体のタイムアウト | 接続確立・ヘッダ・ボディのストリーミング・中断までを含む。遅いローカルモデルでは伸ばす |
params.num_ctx |
リクエスト時のコンテキスト長 | モデル定義のcontextTokensと揃える。ハードウェアが公称値を回せないときは両方下げる |
params.keep_alive |
モデルをメモリに保持する時間 | ネイティブ/api/chatのトップレベルkeep_aliveとして転送される |
公開ホストやhttps://ollama.com につなぐ場合はルールが変わります。この場合は実際の資格情報が必要で、OLLAMA_API_KEY環境変数、認証プロファイル、プロバイダのapiKeyフィールドのいずれかを使います。資格情報はホストスコープで扱われ、OLLAMA_API_KEY単体はOllama Cloudの慣習として解釈されるため、既定では自己ホストのローカルエンドポイントへは送信されません。この挙動は、社内のLANホストへ誤ってクラウド用トークンを飛ばさないための安全側の設計です。
速いマシンと大きいマシンを使い分けたいなら、プロバイダIDを分けて登録できます。OpenClawはリクエスト時にプロバイダ接頭辞を取り除くため、ollama-large/qwen3.5:27bはqwen3.5:27bとしてOllamaに渡ります。
{
models: {
providers: {
"ollama-fast": {
baseUrl: "http://mini.local:11434",
apiKey: "ollama-local",
api: "ollama",
models: [
{ id: "gemma4", name: "gemma4", input: ["text"], contextTokens: 32768 }
]
},
"ollama-large": {
baseUrl: "http://gpu-box.local:11434",
apiKey: "ollama-local",
api: "ollama",
timeoutSeconds: 420,
models: [
{ id: "qwen3.5:27b", name: "qwen3.5:27b", input: ["text"], contextTokens: 131072 }
]
}
}
},
agents: {
defaults: {
model: {
primary: "ollama-fast/gemma4",
fallbacks: ["ollama-large/qwen3.5:27b"]
}
}
}
}
対話でやりたい場合はopenclaw onboardを実行してOllamaを選び、Cloud + Local / Cloud only / Local onlyのいずれかを選択します。オンボーディング時の検出は/api/psでメモリに読み込み済みのモデルだけを見て、/api/showでツール対応を確認します。アイドル状態のモデルをpullしたり読み込んだりはしません。CI やサーバー初期化のように対話できない場面では、非対話フラグが用意されています。
openclaw onboard --non-interactive --accept-risk --skip-health \
--auth-choice ollama \
--custom-base-url "http://ollama-host:11434" \
--custom-model-id "qwen3.5:27b"
Ollama側から一気に立ち上げるルートもあります。Ollama公式はollama launch openclawというコマンドを用意しており、OpenClawが未インストールならnpm経由での導入を促し、モデル選択、プロバイダ設定、Gatewayの初期化までを自動化します。--configで起動せずにモデルだけ選ぶ、--model kimi-k2.5:cloudでモデルを直接指定する、--yesでヘッドレス実行する、といった使い分けができます。なお、ローカルモデルからOllamaのWeb検索を使うにはollama signinが必要です。
Dockerで動かしている場合の注意点も押さえておきます。コンテナ内から見た127.0.0.1はホストではなくコンテナ自身なので、ホスト側のOllamaへはhttp://host.docker.internal:11434で接続します。環境別の常駐方法はOpenClawセットアップ｜Docker/Windows/Mac mini手順で整理しています。
つながったかどうかを、手で確かめる
「モデルを選べた＝動いている」ではありません。ツール呼び出しまで含めて通るかを、下から順に確認します。
# 1. Ollamaデーモンの生存
curl http://127.0.0.1:11434/api/tags
# 2. OpenClawが認識しているモデル
openclaw models list --provider ollama
openclaw models status
# 3. 実際に推論を1往復させる
OLLAMA_API_KEY=ollama-local \
openclaw infer model run \
--local \
--model ollama/gemma4 \
--prompt "Reply with exactly: pong" \
--json
# 4. Gatewayの深い診断
openclaw gateway status --deep
画像も扱いたい場合は、vision対応モデルを明示します。手動定義ではinputにimageを含めるのを忘れないでください。
ollama pull qwen2.5vl:7b
OLLAMA_API_KEY=ollama-local \
openclaw infer image describe --file ./photo.jpg --model ollama/qwen2.5vl:7b
ここで注意したい仕様がひとつあります。ollama/<model>のように明示的にモデルを参照した場合、プロバイダのbaseUrlに到達できないと、別のモデルへ黙ってフォールバックせずに即座に失敗します。挙動としては正しい設計ですが、GPUボックスを落としたまま出社した朝にエージェント全体が止まる、という形で表面化します。fallbacksに軽量なローカルモデルを1つ入れておくと、この手の停止を吸収できます。
もうひとつ、ローカルモデル特有の最適化が自動で効いています。tools.toolSearchが未設定のとき、ローカルのOllamaモデルは構造化されたTool Searchを自動的に使い、必要になった時点でツールスキーマを読み込みます。アプリとCLIは32,768トークンのランタイムコンテキスト（モデルのネイティブウィンドウがそれより小さければそちら）で動作します。以前localModelLeanを有効化していた場合はfalseに戻すと、自動Tool Searchを維持したままオプションのツールが復活します。
法人で締めるなら、この7点を上から順に
ローカルにしたぶん、安全側の責任は自分に移ります。OpenClawとOllamaの公式ドキュメントで確認できた対策を、効き目の大きい順に7つ並べます。
| # | 締める場所 | 具体的な操作 | 効く脅威 |
|---|---|---|---|
| 1 | Ollamaのバージョン | 0.17.1以上へ更新（現行はv0.33.3） | CVE-2026-7482によるプロセスメモリ漏洩 |
| 2 | 11434番ポート | 既定の127.0.0.1バインドを維持する |
認証なしAPIへの外部到達 |
| 3 | クラウド送信 | OLLAMA_NO_CLOUD=1またはserver.jsonのdisable_ollama_cloud |
意図しない外部へのプロンプト送出 |
| 4 | Gatewayの公開範囲 | openclaw security auditで監査、公開時はexposure runbookに従う |
Gatewayの無認証公開 |
| 5 | ツール権限 | 3つの権限ゲートとサンドボックスを設定 | プロンプトインジェクション経由の任意実行 |
| 6 | シークレット | SecretRefへ移行しopenclaw secrets audit --check |
平文APIキーの残留 |
| 7 | ログ・トランスクリプト | logging.redactSensitiveとlogging.redactPatterns |
ログ経由の資格情報流出 |
1〜3: Ollama側の境界を引き直す
Ollamaは既定で127.0.0.1のポート11434にバインドします。OLLAMA_HOSTでバインドアドレスを変更できますが、ここを0.0.0.0にした瞬間、認証のないAPIがネットワークに開きます。CVE-2026-7482の報道で「300,000台規模のインスタンスが影響を受けうる」と言われたのは、まさにこのOLLAMA_HOST=0.0.0.0という設定が広く使われていたためです。別マシンから使いたい場合でも、インターネットに直接晒すのではなく、ファイアウォールで送信元を絞る、認証プロキシを前段に置く、ネットワークを分離する、といった対策を組み合わせるのが公式・第三者双方の推奨です。ブラウザ経由のアクセスを絞るならOLLAMA_ORIGINSでオリジンを限定します（既定では127.0.0.1と0.0.0.0からのクロスオリジンリクエストが許可されています）。
外部送信を完全に止めたい場合は、Ollama側にいわゆる機内モードがあります。~/.ollama/server.jsonでdisable_ollama_cloudをtrueにするか、OLLAMA_NO_CLOUD=1を設定すれば、クラウド機能が無効化されます。「ローカルで動かしているつもりが:cloudサフィックスのモデルを踏んで外に出ていた」という事故を、構成レベルで潰せます。
4: Gatewayをどこまで開くか
OpenClaw側の既定は保守的です。通常のホストインストールではGatewayはループバックにバインドされます。ただしコンテナイメージは公開バインドが既定なので、認証とセットで運用する必要があります。チャネルの側も、多くのチャットチャネルは未知のDM送信者に対して処理を行わずペアリングコードを返し、グループアクセスは許可リスト方式でメンション制限の背後に置かれます。
設定のドリフトを検出するコマンドが用意されているので、定期実行に載せる価値があります。
# 設定のドリフトと典型的な地雷を検出する
openclaw security audit
# 自動修正: 開いたグループポリシーを許可リストに戻し、
# logging.redactSensitive: "tools" を復元し、
# state/config/include ファイルの権限を締める
openclaw security audit --fix
この監査が拾うのは、Gateway認証の露出、ブラウザ操作の露出、elevated許可リスト、ファイルシステム権限、緩すぎるexec承認、開放チャネルへのツール露出です。もうひとつ、設計思想として押さえておくべき一文があります。公式ドキュメントは「1つのGatewayにつき1つの信頼境界。単一のオペレータか、メンバーが互いを信頼しているチーム」と明言しており、敵対的なマルチテナント環境はサポート対象外です。信頼レベルの混ざる利用者を1つのGatewayに同居させず、Gatewayと資格情報を分け、できればOSユーザーかホストごと分けるのが公式の指針です。
5: ツール権限は3ゲートで考える
ローカルモデルは安全フィルタを持ちません。したがって、モデルに期待するのではなく、実行できる範囲そのものを狭めます。OpenClawのサンドボックスは3つの権限ゲートで構成されています。1つ目はツールポリシーで、許可・拒否のルールがサンドボックスの判定より先に適用され、拒否されたツールはサンドボックスの有無にかかわらずブロックされます。2つ目はサンドボックスモードで、隔離をいつ有効化するかを決めます。3つ目はtools.elevatedによるelevated execで、サンドボックスの外で実行する明示的な脱出口です（作成者ロールがサンドボックスを強制している場合は上書きできません）。
{
agents: {
defaults: {
sandbox: {
mode: "all",
scope: "session",
backend: "docker",
workspaceAccess: "ro"
}
}
}
}
modeはoff／non-main／all（既定はoff）、scopeはagent／session／shared（既定はagent）、backendはdocker／podman／ssh／openshell（既定はdocker）、workspaceAccessはnone／ro／rw（既定はnone）です。Dockerバックエンドの既定値は厳しめで、ネットワークはnone（外向き通信なし）、ルートファイルシステムは読み取り専用、Linux capabilityは全ドロップです。Gatewayプロセス自体はホストに残り、サンドボックス化されるのはツール実行だけである点も理解しておく必要があります。
コマンド実行の承認はexecポリシーで制御します。現在の状態を確認してから締めるのが安全です。
# 現在の実効ポリシーを表示
openclaw exec-policy show
openclaw approvals get
# サンドボックスの実効設定を説明させる
openclaw sandbox explain
openclaw sandbox list
サンドボックスを有効にした後の典型的な詰まりどころも公式に整理されています。エージェントレベルでツールが許可されていても、サンドボックス側のツールフィルタが許可していなければ通りません。Dockerコンテナではネットワークが既定で無効です。環境変数はサンドボックス内に継承されません。「動かない」と感じたときは、この3つを順に確認すると原因に早く辿り着けます。
6〜7: 資格情報とログ
ローカル運用にしても、モデルAPIキーやチャネルのトークンは手元に残ります。OpenClawはSecretRefという仕組みで、設定ファイルから平文を追い出せます。参照の形は{ source: "env" | "file" | "exec" | "store", provider: "default", id: "..." }で、環境変数なら"${OPENAI_API_KEY}"のような短縮記法も使えます。execソースを使えばVaultや1Passwordのような外部リゾルバに委譲できます。
# 平文の残留を検出する
openclaw secrets audit --check
# 対話的にSecretRefへ移行する
openclaw secrets configure --apply
# 反映
openclaw secrets reload
平文が残りやすい場所はopenclaw.json、.env、state/openclaw.sqliteの認証プロファイル行、生成されるagents/*/agent/models.jsonです。ここで一点、誤解しやすい仕様を明示しておきます。storeプロバイダが使う共有SQLiteの値は暗号化されておらず、ファイル0600・ディレクトリ0700のパーミッションで保護されているだけです。ディスク暗号化やバックアップの扱いは別途設計する必要があります。
ログ側は既定でも守られています。機微値の伏字化は常時有効で、18文字以上の値は先頭6文字と末尾4文字を残してマスクされ、それより短い値は***になります。既定のパターンは、よくあるキー代入、CLIフラグ、JSONフィールド、bearerヘッダ、PEMブロック、主要ベンダーのトークン接頭辞、決済情報のフィールド名をカバーします。社内固有のトークン形式がある場合はlogging.redactPatternsに正規表現を足します（このキーを設定すると既定を上書きする点に注意）。
{
logging: {
level: "info",
consoleLevel: "warn",
maxFileBytes: 104857600,
redactPatterns: ["ACME_[A-Z0-9_]+=\\S+"]
}
}
ログの既定の書き出し先は/tmp/openclaw/配下で、ホストのタイムゾーンで日次ローテーションされ、既定プロファイルはopenclaw-YYYY-MM-DD.logという名前になります。/tmp配下である以上、保管期間とバックアップ方針は自分で決める必要があります。また、ファイルログの水準はlogging.levelだけで決まり、--verboseはコンソール側の詳細度にしか効きません。「詳細ログを出したつもりでファイルには残っていなかった」という取りこぼしを避けるための重要な区別です。
よくある質問
OpenClawをOllamaにつなぐと、プロンプトは一切外部に出ませんか？
Local onlyモードで、かつ:cloudサフィックスのモデルを使わない構成であれば、推論リクエストは手元のOllamaに閉じます。ただしOpenClawはWeb検索やブラウザ操作などのツールを持つため、ツール経由の外部通信は別問題です。確実に止めたいなら、Ollama側でOLLAMA_NO_CLOUD=1を設定し、OpenClaw側でサンドボックスのネットワークを既定のnoneのまま運用してください。
どのくらいのVRAMが必要ですか？
Ollama公式のOpenClaw連携ページの目安はgemma4で約16GB、qwen3.5で約11GBです。加えて、OpenClawは最低64kトークンのコンテキストウィンドウを推奨しているため、コンテキストを広げるぶんのメモリも見込む必要があります。OpenClawのローカルモデル解説ページは、llama.cppのマネージド構成について最小レシピでもホストメモリ8GiBが下限で、大きいレシピはさらに必要だとしつつ、「これらの下限は収まることや速度を保証しない」と明記しています。
モデル一覧にpullしたはずのモデルが出てきません
自動検出はツール対応を申告したモデルだけを表示します。ネイティブなツール呼び出しに対応していないモデルは一覧に出ません。設定ファイルのmodels.providers.ollama.modelsに手動で定義すれば使えますが、その場合はエージェント用途でのツール呼び出しの信頼性を実タスクで確認してから既定モデルに据えてください。なお、models配列が空でない場合は自動検出がスキップされ、手動定義だけが使われます。
ローカルモデルの生成速度はどれくらいですか？
2026年9月時点で、OpenClawとOllamaの公式ドキュメントにモデル別のトークン毎秒の公表値は確認できていません。GPUの世代、量子化の方式、コンテキスト長で大きく変わるため、導入判断は自分のハードウェアでの実測に基づいて行ってください。公式が示しているのはメモリの下限とコンテキストの推奨値までです。
埋め込み専用モデルを既定に設定できますか？
できません。埋め込み専用として申告されたモデルはチャットの既定として選択できず、セットアップはエラーを報告して既存の設定をそのまま残します。
つまずきポイントと、その直し方
接続まわりで報告の多いパターンを、症状と対処のセットで挙げます。
- ❌ ツールが呼ばれず、生のJSONが返信本文に出てくる → ⭕
baseUrlに/v1を付けている。OpenAI互換パスはツール呼び出しを壊すため、http://host:11434（/v1なし）へ直し、api: "ollama"を指定する - ❌ 会話が数往復で文脈を失う／指示を忘れる → ⭕ Ollamaの既定コンテキストが4,096トークンのまま。
OLLAMA_CONTEXT_LENGTHで64k以上に上げ、params.num_ctxとcontextTokensを揃える - ❌ Dockerコンテナ内からOllamaに接続してタイムアウトする → ⭕ コンテナ内の
127.0.0.1はコンテナ自身。接続先をhttp://host.docker.internal:11434に変更する - ❌ OSを再起動したらコンテキスト設定が元に戻っていた → ⭕ シェルだけで環境変数を設定している。macOSは
launchctl setenv、Linuxはsystemctl edit ollama.serviceの[Service]、Windowsはシステム環境変数で永続化してから再起動する - ❌ GPUボックスの電源を落としたらエージェント全体が停止した → ⭕ 明示的な
ollama/<model>参照はbaseUrl到達不能時に即失敗する仕様。agents.defaults.model.fallbacksに軽量モデルを登録しておく - ❌ サンドボックス有効化後にツールが軒並み動かない → ⭕ サンドボックス側のツールフィルタ、Dockerの既定ネットワーク
none、環境変数が継承されない仕様の3点を順に確認する。openclaw sandbox explainで実効設定を出力させる
費用と性能の現実的な見立て
ローカル化の損得は、トークン単価ではなく「初期投資と運用制約をどう評価するか」で決まります。公式に確認できる範囲で、判断材料を整理します。
| 観点 | ローカル（Ollama） | クラウド（:cloud／API） |
|---|---|---|
| 推論の従量課金 | なし（電気代とハードウェアのみ） | あり |
| 必要VRAM | gemma4で約16GB、qwen3.5で約11GB |
不要 |
| 安全フィルタ | 提供されない（公式明記） | ホスト型プロバイダ側で提供 |
| ツール呼び出しの信頼性 | モデル差が大きい。テキストを吐くケースあり | 相対的に安定 |
| OpenAI固有機能 | reasoning-compat／プロンプトキャッシュ／storeは不可 |
利用可能 |
| プライバシー | Local onlyが最も強力な経路（公式表現） | プロバイダのポリシーに依存 |
| 停止要因 | メモリ逼迫でターン途中に推論サーバーが落ちうる | プロバイダ側の障害・規約変更 |
この表を素直に読むと、答えは二択ではありません。機密度の高いタスクだけをローカルに寄せ、複雑な計画立案やツールを多用するタスクはクラウドに残す、というハイブリッドが最も安定します。OpenClawはこれを設定で表現できます。agents.defaults.model.primaryにローカルモデルを置き、fallbacksにクラウドモデルを並べる書き方です。
{
agents: {
defaults: {
model: {
primary: "ollama/gemma4",
fallbacks: ["ollama/kimi-k2.5:cloud"]
}
}
}
}
なお、OpenClaw本体は2026年8月30日（米国時間）に「OpenClaw 2.0」として16,000件超のプルリクエストを含む大型更新が入ったと報じられており、モデル・プロバイダまわりも改善対象に含まれています。GitHubのリリース情報では、執筆時点の最新版はv2026.9.3（2026年9月8日公開）です。設定キーの挙動は版によって変わりうるため、本記事のスニペットを適用する前に、必ず自分の環境のバージョンで公式ドキュメントを再確認してください。本番環境で使用する前に、必ずテスト環境で動作確認してください。
ローカルモデルをエージェント用途で回した場合の挙動については、Muse Glimmerの使い方｜30BをOllamaでローカル実行や、コーディング支援側での接続例としてGitHub Copilot×Ollama接続ガイド｜BYOKでローカルLLMも参考になります。OpenClawそのものの全体像はOpenClawとは｜できること・セットアップ難易度・注意点で押さえられます。
結論
OpenClawとOllamaの接続は、OLLAMA_API_KEY="ollama-local"とopenclaw models setの2手で通ります。難所は接続ではなく、その後の境界設計です。今日中に確認すべきことを3段階で並べます。
- 今すぐ:
ollama --versionで0.17.1以上（できれば現行のv0.33.3）かを確認し、OLLAMA_HOSTが0.0.0.0になっていないかを見る。この2点だけでCVE-2026-7482の露出は塞がる - 接続時:
baseUrlに/v1を付けず、OLLAMA_CONTEXT_LENGTHを64k以上に上げ、openclaw infer model runで1往復を実測する - 本番投入前:
openclaw security audit、openclaw secrets audit --check、openclaw sandbox explainの3コマンドを通し、ツール権限・シークレット・ログ伏字化の状態を記録に残す
ローカルLLMは「外に出さない」を実現する手段であって、「何をしても安全」を意味しません。安全フィルタが外れるぶん、権限とネットワークで守る——この置き換えを意識して設計すれば、法人環境でも十分に実用の範囲に入ります。
あわせて読みたい:
- Ollamaの使い方 2026｜ローカルLLMでAIエージェント — モデル選定とOllama単体の基本操作から始めたい方へ
- OpenClawセットアップ｜Docker/Windows/Mac mini手順 — Gatewayをどこに常駐させるか決めたい方へ
- Claude OpenClaw遮断｜API移行と削減戦略 — なぜローカル移行を検討するに至ったかの背景へ
参考・出典
- Ollama — OpenClaw Docs — OpenClaw公式ドキュメント。接続設定キー・認証ルール・num_ctx・検証コマンド（参照日: 2026-09-09）
- Local models — OpenClaw Docs — OpenClaw公式ドキュメント。安全フィルタ不在の明記・メモリ下限・制約（参照日: 2026-09-09）
- Security — OpenClaw Docs — OpenClaw公式ドキュメント。バインド既定・信頼境界・security audit（参照日: 2026-09-09）
- Sandboxing — OpenClaw Docs — OpenClaw公式ドキュメント。sandbox設定キーとDocker既定値・3ゲート（参照日: 2026-09-09）
- Secrets management — OpenClaw Docs — OpenClaw公式ドキュメント。SecretRef構文と平文残留箇所（参照日: 2026-09-09）
- Gateway logging — OpenClaw Docs — OpenClaw公式ドキュメント。ログ出力先・伏字化・logging.level（参照日: 2026-09-09）
- OpenClaw — Ollama Docs — Ollama公式ドキュメント。推奨モデルとVRAM目安・64kコンテキスト推奨・ollama launch（参照日: 2026-09-09）
- FAQ — Ollama Docs — Ollama公式ドキュメント。既定バインド・OLLAMA_CONTEXT_LENGTH・OLLAMA_NO_CLOUD・OS別の環境変数設定（参照日: 2026-09-09）
- Releases — ollama/ollama — 最新版v0.33.3の公開日（2026-09-02）を確認（参照日: 2026-09-09）
- Releases — openclaw/openclaw — 最新版v2026.9.3の公開日（2026-09-08）を確認（参照日: 2026-09-09）
- Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak — The Hacker News。CVE-2026-7482の技術詳細と影響範囲（参照日: 2026-09-09）
- Critical Bug Could Expose 300,000 Ollama Deployments to Information Theft — SecurityWeek。CVSS 9.1・Bleeding Llama命名・0.17.1での修正（参照日: 2026-09-09）
- 7週間の沈黙破り「OpenClaw 2.0」登場。プルリクエスト1万6千件の史上最大更新 — PC Watch（参照日: 2026-09-09）
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
