Ollama ローカル推論 · クラウド API コストマトリックス · 6 ステップ Runbook · Gateway 症状表
Ollama で OpenClaw を動かしクラウド API 料金を抑えたい一方、ノート PC のスリープで Gateway が落ちる、初回の ollama pull がタイムアウトする、Agent がコンテキスト不足を報告する——そんな経験はありませんか。本文は「ollama launch openclaw + 24/7 制御面」をリモート Mac に載せる開発者向けです。まずクラウド API とローカル推論の意思決定マトリックスを示し、6 ステップ Runbook で導入と受け入れを行い、症状対照表 で Gateway を揃えます。インストール排障チェックリストとマルチモデルルーティングと役割分担して読むことをお勧めします。
2026 年、Ollama 公式統合では ollama launch openclaw がモデル取得、Gateway、OpenClaw ウィザードを一コマンドにまとめます。しかし本番で多い失敗は「OpenClaw 未導入」ではなく、モデルサービスとチャネル／Gateway 常駐をスリープするノート PC に同居させることです。Ollama ブログと OpenClaw 導入ドキュメントは Node 22.14+（環境により 24 推奨）を要求し、長い会話には十分なコンテキストのモデルが必要です（コミュニティでは少なくとも 64k token 級、qwen3-coder、glm-4.7 など）。8k 級の軽量モデルだけを選ぶと、Gateway のヘルスチェックは通っても、多段ツール呼び出し後に Skill が溢れます。
レビュー会では「モデルが壊れた」と決めつける前に、バックエンド・Gateway・チャネルの三層に分解してください。Ollama の API が応答しても、OpenClaw の制御面が 18789 系ポートで安定していなければ、IM からのメッセージは届きません。逆に Gateway が緑でも、provider がクラウドのままなら請求は下がりません。五つの隠れコストをリリースゲートに書き込むと、変更は監査可能になります。
pull 成功を E2E 合格と誤認：重みの配置は Ollama 準備完了に過ぎません。openclaw gateway status と最小 Skill の試走が必要です。
コンテキスト選定ミス：VRAM 節約で小さすぎるモデルを選び、長セッションやブラウザ系 Skill で切り詰めが発生。Ollama のモデルカードの context を先に確認してください。
ノート PC スリープで Gateway 断：ローカル推論は API 料を抑えますが、コールバックと heartbeat は 24/7 が前提です。クラウド常駐ガイドと同型の課題です。
Docker 経路と混同：コンテナ内 OpenClaw は mem_limit の話、Ollama ベアメタルはディスクキャッシュとユニファイドメモリの話。故障ツリーを分けてください。
クラウドルートを全開のまま：Ollama を接続済みでも設定のデフォルトが高単価モデルのままでは請求は下がりません。provider の明示変更とコスト上限は マルチモデルルーティング記事を参照してください。
五項目をゲート化すると、次節のマトリックスでクラウド API、OpenRouter、Ollama ローカルのいずれかに署名できます。
選定はプライバシーと鍵の境界、予測可能な月額、運用面が 24/7 かの三つです。下表はレビュー一枚用です。決めたら対応 Runbook のみを実行してください。
| バックエンド | 向くチーム | 主なコスト | OpenClaw 連携 |
|---|---|---|---|
| クラウド API 直結 | 低遅延・token 従量を許容 | 鍵ローテーション、請求スパイク、リージョン要件 | デフォルト経路。ルーティング分岐と上限を併用 |
| OpenRouter 集約 | 多モデル試行・迅速切替 | 従量のまま。第三者 SLA 依存 | Ollama と「ローカル主・クラウド備」に適合 |
| Ollama ローカル | データを機外に出さない。算力コスト前倒し可 | RAM/ディスク、pull 時間、64k+ モデル必須 | ollama launch openclaw または手動モデル指定 |
| リモート Mac + Ollama | ローカル推論 + チャネル 24/7 | ノード月額 + 運用 Runbook | Gateway と Ollama を同機または同リージョンに |
API 料を下げるにはデフォルトを本当に Ollama に切り替え、長会話用のコンテキストを選ぶこと。そうでなければプロセスが一つ増えただけです。
Ollama 公式例では ollama launch openclaw --model qwen3-coder などが使えます。OpenClaw 側は openclaw onboard --install-daemon でデーモンを入れてください。ハイブリッドでは「Ollama 主ルート + クラウド API 緊急フォールバック」を変更チケットに書き、口頭合意にしないでください。
小規模チームでは、まず一週間だけノート PC で試し、週次で token 請求と pull 失敗率を記録するのが有効です。数値が閾値を超えたらリモート Mac へ移す判断が客観的になります。
順序は Gateway インストール排障チェックリストと接続します。先に Ollama とモデル、次に OpenClaw 制御面とチャネル。各ステップの出力をチケットに貼ってください。
Ollama をインストール：対象 Mac に Ollama 0.17+。ollama --version と ollama list。ローカル API（既定 11434、環境により異なる）を確認します。
コンテキスト十分なモデルを pull：例 ollama pull qwen3-coder または承認済み glm 系。ディスク使用量と pull 時間を容量計画に記録します。
OpenClaw 統合を起動：ollama launch openclaw --config で事前確認の後 ollama launch openclaw。または公式 install.sh で Node スタックを入れ Ollama provider を手動接続します。
onboard とデーモン：openclaw onboard --install-daemon で Ollama をデフォルトに。openclaw gateway status で 18789 系制御ポート（出力に従う）を確認します。
最小 Skill 試走：ブラウザ不要の短い命令（状態取得や echo）と openclaw logs --follow。失敗時はモデルとチャネル設定を同時に変えないでください。
チャネルスモーク（任意）：Telegram/Slack 接続時は マルチチャネル強化チェックリストでコールバック到達性。モデルバックエンドとは切り離して検証します。
ollama --version ollama pull qwen3-coder ollama launch openclaw --config ollama launch openclaw --model qwen3-coder openclaw onboard --install-daemon openclaw gateway status openclaw doctor --fix
ヒント：初回 pull は国境をまたぐ回線や低速リンクでタイムアウトしやすいです。リモートノードで screen や systemd でセッションを保ち、SSH 切断による中途半端なレイヤーを避けてください。
| 症状 | 先に確認 | よくある対処 |
|---|---|---|
| ollama pull 停滞・タイムアウト | ディスク空き、ネットワーク、SSH 切断 | 保活セッションで再 pull。~/.ollama の破損レイヤー削除後に再試行 |
| Gateway 緑だが応答が切れる | モデル context、会話ターン数 | 64k+ モデルへ変更。長タスクはクラウド備または分岐ルート |
| openclaw が Ollama に接続できない | 11434 リッスン、FW、provider URL | curl で Ollama API。loopback と設定項目を一致 |
| doctor が Node 版を指摘 | node -v | 22.14+ または文書推奨の 24 へ。コンテナ内 Node と混同しない |
| チャネルコールバックなし | パブリック到達、逆プロキシ WS | 先にインストール排障記事。モデル変更は後回し |
~/.ollama/models。リモート Mac のディスク計画に単独計上。7B〜30B 級は数十 GB に達します。注意：同一変更チケットでクラウド API Key、Ollama モデル tag、チャネル webhook を同時ローテーションしないでください。三角変更は二分探索で戻せません。
ノート PC 経路は ollama launch openclaw とモデルカードの検証に向きます。IM チャネル、夜間 cron、チーム共有 Gateway が必要になると、スリープと NAT が SLA を壊します。Ollama キャッシュ、Gateway データ、デーモンを同スペックで予測可能なリモート Macへまとめて移す方が、都度の復帰より安くつくことが多いです。
自前 VPS（ユニファイドメモリ最適なし）での大モデルは推論遅延、OOM、ディスク IO 揺れが出やすいです。Mac クラウドは Apple Silicon とメモリ帯域でローカル推論に合います。個人開発者には「ローカル試験 + リモート常駐」の二段階が、最初から最高スペックを買うより安定しやすいです。専有算力とチャネル安定、監査可能な変更が必要な小チームには、VpsMesh の Mac Mini クラウドレンタルが通常最適です。Ollama と Gateway を同一リースノードに置き、Mac Mesh の協調ストーリーとも整合します。料金は 価格ページ、手順は ヘルプセンターをご覧ください。
受け入れ後は週次で Gateway uptime、pull 成功率、月次 token 請求を一枚にまとめ、閾値超過時だけスペックアップまたはクラウド備を増やす運用が、過剰プロビジョニングを防ぎます。
はい。IM チャネルは Gateway が管理し、モデルが Ollama かクラウドかは無関係です。必要なのは Gateway の24/7と webhook 到達性です。強化は マルチチャネルチェックリスト、常駐は クラウド Mac ガイドを参照してください。
まず Ollama で 64k+ モデルに切り替え、単一セッションのツールチェーン深度を短くします。それでも溢れる場合は マルチモデルルーティング記事で分岐とクラウドフォールバックを行い、二重変更で二分できない状態を避けてください。
Ollama と Gateway をリモート Mac へ移しデーモンを入れます。24/7 常駐ガイドを参照してください。選定と申込は 申込ページからどうぞ。