OllamaとOpenClawをローカル導入：モデル、ポート、権限、メモリの診断

OllamaとOpenClawの接続失敗は、単に「モデルが小さい」ことが原因とは限りません。ポートの誤り、ネイティブproviderにOpenAI互換URLを指定したこと、Gatewayが別のnetwork namespaceにいること、過大なツール権限が典型です。まずOllama providerのネイティブAPI、次にOpenClawのモデル認識、最後にメモリと自動化を検証します。

ここではlocalhostまたは非公開LANを前提とし、OllamaやGatewayをインターネットに直接公開しません。

モデル選択：チャットとAgent処理は異なる

次の4点を確認します。

Ollamaがモデルを取得し、正常に生成できる。
first token時間と継続速度がハードウェア上で許容できる。
「こんにちは」だけでなく、最小のツールタスクが成功する。
長いタスクのcontextとRAM/VRAMに余裕がある。

小型モデルは要約、分類、固定手順に向きます。複雑なツール、リポジトリ理解、複数ターンでは実タスクをテストしてから、大型モデルやcloud fallbackを判断します。

1
2
3
4


ollama pull <model>
ollama list
curl http://127.0.0.1:11434/api/tags
curl http://127.0.0.1:11434/api/generate -d '{"model":"<model>","prompt":"Reply with exactly: ok","stream":false}'

2つ目のリクエストがokを返すまでOpenClaw側を調査しないでください。

ネイティブOllama APIを設定する

ネイティブproviderのbaseUrlに/v1を付けないでください。OpenAI互換経路では、ツール呼び出しが失敗したりツールJSONが通常テキストとして出力されたりします。

1

export OLLAMA_API_KEY="ollama-local"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        apiKey: "ollama-local",
        api: "ollama"
      }
    }
  },
  agents: {
    defaults: { model: { primary: "ollama/<model>" } }
  }
}

現在のキーはbaseUrlです。baseURLは古い例との互換用です。loopback、private address、.local、bare hostnameではローカルマーカーを使えますが、公開hostやOllama Cloudには実際の認証情報が必要です。

Gemma 4の例

gemma4:12bのような推測タグをコピーせず、ローカルの正確なタグを読みます。

1
2
3
4
5
6


ollama list
curl http://127.0.0.1:11434/api/generate -d '{
  "model": "<your-gemma-4-tag>",
  "prompt": "Reply with exactly: ok",
  "stream": false
}'

成功後、同じタグをOpenClawに設定します。ollama listと完全一致しなければなりません。

OpenClawがモデルを使うことを確認

1
2
3


openclaw models list --provider ollama
openclaw models status
openclaw infer model run --model ollama/<model> --prompt "Reply with exactly: ok"

/api/tagsが成功して一覧が空なら、providerが無効、Gatewayのservice accountに環境変数が渡っていない、またはGatewayがcontainerや別hostで動いている可能性があります。モデル名を変更する前にprocessとnetworkの境界を直します。

ポートとコンテナ：localhostの意味

Ollamaは通常127.0.0.1:11434にbindします。両方が同じhostにいる場合は安全ですが、Docker、WSL、systemd、remote Gatewayではlocalhostの指す場所が変わります。

構成	確認事項
両方がhost上	同じユーザーから`127.0.0.1:11434`へ接続できる
OpenClawがDocker内	containerのlocalhostはcontainer自身。制限したhost到達アドレスを使う
OpenClawが別host	private bind、firewall allowlist、実認証
WSLとWindows	両側から`/api/tags`を実行し、実際のrouteを確認

接続のために11434を全public interfaceへbindしないでください。private networkまたは管理されたtunnelを使います。

ツールの前に権限を制限する

ローカル推論でもツール実行が自動的に安全になるわけではありません。

Administrator/rootではなく一般ユーザーで実行する。
workspaceを専用projectまたはsandboxに限定する。
削除、公開、外部送信、認証情報、production接続は承認必須にする。
secretをprompt、memory、log、Gitへ書かない。
Skillやpluginの提供元と内容を確認する。

「実行可能」と「自動実行を許可」を分けてください。

遅いモデルのtimeoutと常駐

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


{
  models: {
    providers: {
      ollama: {
        timeoutSeconds: 300,
        models: [
          { id: "<model>", name: "<model>", params: { keep_alive: "15m" } }
        ]
      }
    }
  }
}

timeoutSecondsは接続、stream、モデルリクエスト全体を対象にします。keep_aliveはcold startの繰り返しを減らします。Agent全体のtimeoutが短ければ、そちらが先に停止します。

推論確認後にメモリpluginを追加

TencentDB Agent Memoryは次の順で確認します。

1
2
3
4


1. Ollama /api/tagsと最小生成が成功。
2. OpenClaw models list、status、inferが成功。
3. pluginを有効化し、明確な事実を別sessionで確認。
4. 最後にoffloadを有効化し、node_idから元のtool logを復元。

1
2


openclaw plugins install @tencentdb-agent-memory/memory-tencentdb
openclaw gateway restart

記憶できない場合はpluginの有効化、保存先の書き込み権限、新しいsessionかを確認します。offloadでlogが消える場合はcontext engine slotとafter-tool-call patchを確認します。詳細はTencentDB Agent Memoryガイドを参照してください。

障害の早見表

症状	最初に確認
`connection refused`	Ollama process、11434、network namespace
一覧は出るがtoolが失敗	`/v1`の誤用、モデルのtool能力
API key不足	`OLLAMA_API_KEY=ollama-local`とGateway環境
timeoutが多い	負荷、モデルサイズ、provider/Agent timeout、`keep_alive`
memoryが遅い・context消失	offloadを切り、memory単体を確認後に`node_id`復元を調査

まとめ

安定した構成はネイティブAPIから始まります。127.0.0.1:11434/apiとモデルを検証し、/v1ではないproviderを設定してから、最小限のツール権限とメモリを開放します。モデル、ポート、process境界、pluginを分けて検証する方が、再インストールより速く安全です。