Linuxクラウドに OpenClaw 2.0 を置くとき、つまずきやすいのはインストール手順ではない。安い枠を買って Gateway は立ち上がるのに、チャネルを繋ぎ、スキルを走らせた瞬間にメモリが尽きる。私たちはよくある VPS 枠を Ubuntu に揃え、ホストインストール、Docker、リモート API、ローカルモデルを同じ手順で回し、CPU・メモリ・ディスクの実測を残した。SSH できることではなく、仕事が回る枠で発注するための数字である。
先に結論だけ置く。リモート API でテキストチャネルだけなら、2 vCPU / 8 GB / 40 GB が日常の起点として安定する。2 vCPU / 4 GB でも起動はするが、ブラウザスキルやその場でのイメージビルドは載せない。同じマシンで 7B のローカル推論までやるなら、メモリは最初から 16 GB を確保する。公式ドキュメントはゲートウェイを自前ホスト・多チャネルの Agent 入口として書いており、インストールもモデル選択も「自分の一台」前提だ。カタログ上の最低値より、余白の方が大事になる。
最安値ではなく、仕事の束で枠を切る
OpenClaw 2.0 のプロセス自体は重い部類ではない。アイドル時の Gateway 常駐はだいたい 200〜300 MB、CPU はほぼ 0 に張り付く。マシンを潰すのは、初回起動のサンドボックスコンパイル、そのマシン上での Docker ビルド、そしてローカル推論が重なったときだ。OpenClaw の Docker インストール案内 ははっきり書いている。ソースからイメージを組むなら少なくとも 6 GB RAM。先に ghcr.io/openclaw/openclaw のプリビルドを引けば、このピークは避けられる。
だから同じ OpenClaw 2.0 でも、4 GB と 16 GB の差は「少し速い」ではない。「生きている」と「仕事ができる」の差になる。調達用に切った三段階が下図である。スキル側の工程を Workflow に落とす話は、別稿の Agent Skillsでソフトウェア開発工程をWorkflow化 と合わせて読むと、どのチャネルを常時載せるかが決めやすい。
測定環境を揃えた理由
世代差を OpenClaw の罪にしないため、同じ Ubuntu イメージで CPU・メモリ・ディスクだけを変えた。投入後はまず apt update && apt upgrade、続けて Node（公式は Node 26、または Node 24.16+）、Git、Docker Compose v2。SSH は鍵認証のみ。入れないときは、先に LinuxサーバーでSSH接続が拒否されるときの5つの切り分け方法 でセキュリティグループ、sshd、鍵を切り分けてからゲートウェイに進む。
各枠で四つの数字を取った。OS アイドル、Gateway アイドル、Telegram を一本繋いだ定常、ツール呼び出し付きメッセージ後のピーク。ディスクはルート、Docker レイヤ、~/.openclaw 作業領域。値は三回測った中央値で、「たまたま落ちなかった」一回は使っていない。
free -h の available。見かけだけの VIRT は見ない。CPU は 60 秒平均で、単コアの瞬間尖りは捨てる。ディスクに swap ファイル自体は含めない。
Ubuntu と Docker がそれぞれ食う分
22.04 でも 24.04 でも OpenClaw 2.0 は動く。24.04 はアイドルでだいたい 100–200 MB 多く、その代わりカーネルが新しく LTS の窓も長い。22.04 の利点は、ネット上の切り分け記事が多いことだ。どちらにもデスクトップ環境は載せない。クラウド上のデスクトップは、ゲートウェイに残したかった 1 GB をそのまま持っていく。
Docker のコストは二口ある。エンジンのアイドルがおよそ 150–250 MB。イメージ本体は slim でディスク 1–2 GB、Chromium 付きの -browser 変種はさらに伸びる。ホストで curl -fsSL https://openclaw.ai/install.sh | bash すればコンテナ層はなく、アイドルは細い。ただしロールバックは、自分でバイナリと設定の控えを残す必要がある。4 GB ではホストインストール＋リモート API だけを勧める。Docker にするならプリビルドを引き、そのマシンで docker build しない。
Docker Engine は公式リポジトリから入れる。ディストリの古いパッケージは使わない。手順は Docker 公式の Ubuntu インストール案内 に合わせ、終わったら docker compose プラグインであること（古い docker-compose バイナリではないこと）を確認する。OpenClaw の Compose は v2 前提で書かれている。
| 入れ方 | アイドルメモリ | ディスク増分 | 向いている人 |
|---|---|---|---|
| ホスト install.sh | 約 250–400 MB | 約 0.4–0.8 GB | 4 GB の試運転、最小オーバーヘッド |
| Docker プリビルド | 約 450–700 MB | 約 2–4 GB | 8 GB の日常、隔離とロールバック |
| その場でイメージ構築 | ピーク ≥ 6 GB | ビルドキャッシュは別途 | 8 GB+ か CI マシンだけ |
四枠の実測：CPU・メモリ・ディスク
ここが今回の核になる表である。CPU 列は「スケジューリングが持つか」、メモリ列は「OOM するか」、ディスク列は「入れたあとログが残せるか」。すべてリモート API、単チャネル、ローカルモデルなしの結果だ。
| 枠 | CPU | メモリ | ディスク目安 | 所見 |
|---|---|---|---|---|
| 2C2G / 25 GB | 回るが、並列ですぐ揺れる | available が長く 300 MB 未満 | 入れたあとほぼ余らない | 非推奨。Docker ビルドは必ず OOM |
| 2C4G / 40 GB | 単チャネルなら足りる | 定常で約 2.1–2.6 GB 使用 | 40 GB でちょうど | テキストのみ可。ブラウザは切る |
| 2C8G / 80 GB | 二チャネルでも安定 | available が 3 GB+ 残ることが多い | 80 GB なら余裕 | リモートAPIの日常の第一候補 |
| 4C16G / 160 GB | ツール呼び出しのピークでも列にならない | 7B かブラウザのどちらかを重ねられる | モデルファイルは別計算 | ローカル推論をするならこの枠 |
2C2G の壊れ方はほぼ同じだ。Gateway が上がったあと available は 100〜200 MB しか残らず、Docker を一層載せるか onboard を一度走らせるとカーネルが OOM する。コンテナ終了コード 137 で、業務ログにはほとんど何も残らない。4 GB は生きる。ただしブラウザスキルを切り、その場ビルドをやめ、ログローテーションを入れる。8 GB になって初めて「もう一本チャネルを足せる」余白が出る。16 GB の意味はテキストチャットを速くすることではなく、ローカルモデルの議論に参加する資格を得ることだ。
ディスクは想像より早く埋まる。Ubuntu の更新後、ルートは 8–12 GB に達する。Docker イメージが 2–6 GB。作業領域とログは月 1–5 GB。公式は「イメージとログの空きを残せ」としか書いていない。運用できる書き方にするなら、ローカルモデルなしで少なくとも 40 GB、日常は 80 GB、ホストにモデルを置くならさらに 10–20 GB。swap は 2–4 GB を保険にしてもよいが、メモリ計画の代わりにはできない。swap に入った瞬間、ツール呼び出しのテール遅延がはっきり悪化する。
ローカルモデルとリモート API：費用の見方
リモート API は推論を VPS の外へ出す。マシンが持つのは Gateway、チャネル、ツールだけになる。ハードウェアを一番抑えられる使い方で、OpenClaw 公式ドキュメント も、モデル事業者の鍵は自分で用意する前提で書かれている。対価はトークン課金と、コンテキストがこのマシンを離れることだ。
ローカルモデルは請求をメモリに付け替える。7B の量子化ウェイトはおよそ 4–5 GB。Ollama ランタイムと KV cache を足すと、16 GB なら Gateway と同居できる。14B は 32 GB で考える。同じ機で Ollama に繋ぐとき、詰まりやすいのは「モデルが落ちるか」より TLS、SSH トンネル、NO_PROXY の側である。
2026 年によく見る Linux クラウドの表示価格で、一か月を粗く見積もる（米ドル、帯域超過は含まない）。
| 構成 | マシン月額 | モデル請求 | 合計の目安 | 向く用途 |
|---|---|---|---|---|
| 2C8G + リモート API | 約 10–18 | 軽量 15–40、重いとそれ以上 | 25–60 | 個人アシスタント、低機密度の文脈 |
| 4C16G + ローカル 7B | 約 20–40 | 0 | 20–40 | 日次呼び出しが多い、データを機外に出したくない |
| 8C32G + ローカル 14B | 約 40–80 | 0 | 40–80 | 品質をクラウド中型モデルに近づけたい |
「ローカルなら必ず安い」と思いがちだが、帳は分ける。月に短い対話が数百回なら、リモート API の請求は、8 GB から 16 GB へ上げる差額より小さいことが多い。ローカル 7B は品質、ツール追従、長いコンテキストでも折れる。逆に、Cron の定時巡回、チャネルで一日数百件、あるいはログを外に出せないなら、16 GB + 7B が先に API 請求を追い越し、機密度も残す。
折衷はこちらを勧める。Gateway の主モデルはリモートのまま、タイトル生成や短い要約だけ公式の utility 小モデルへ渡す。たまにホストの 7B へ切ってもよい。同じ 8 GB でブラウザスキルとローカル 14B を同時に開くと、メモリの帳が合わない。
発注の切り方：一枚の判断表
欲しい能力を「同時に成立しなければならない条件」として書いてから買う。条件がぶつかるなら、一台にブラウザと 14B を同居させるより、二台に割った方が安く、切り分けも楽になる。
| 欲しい能力 | 最低限起動する枠 | 発注の推奨 | やらないこと |
|---|---|---|---|
| Telegram / Discord のテキスト助手 | 2C4G ホストインストール | 2C8G + Docker プリビルド | その場ビルド、デスクトップ搭載 |
| さらにブラウザスキル | 4C8G | 4C8G または 4C16G | ローカル 14B との同居 |
| ホストで 7B 推論 | 4C16G | 4C16G NVMe 80 GB+ | 8 GB で押し切ろうとすること |
| チームの多チャネル＋監査ログ | 4C8G | 4C8G / 80–160 GB | ログを回さないこと |
本番では、枠とは別に「メモリ不足に見える」原因が二つある。Gateway を 0.0.0.0 に結びながらリバースプロキシを置いていないことと、ログディスクが満杯になることだ。前者は 127.0.0.1 に結び、Nginx / Caddy を前に置く。後者は Docker と journald にサイズ上限を付ける。枠を正しく買ったあと、来週の深夜にディスク拡張で起こされるかを決めるのはこの二点である。
FAQ
1C1G や 2C2G で試せるか？
確認できるのは「インストールスクリプトが最後まで走る」ことまでだ。Gateway にチャネルを繋いだ瞬間に揺れ、Docker ビルドはほぼ確実に 137 で落ちる。試すなら少なくとも 4 GB。残すつもりなら最初から 8 GB にする。
Ubuntu 必須か。Debian は使えるか？
Debian 12 でも動く。Docker 公式も対応している。私たちが Ubuntu を選んだのは、イメージが見つかりやすく、文書と切り分け記事が揃うからだ。本番に非 LTS のデスクトップ版を充てない。
ボトルネックは CPU か、メモリか？
リモート API ではほぼメモリとディスクである。CPU が最初の警戒線になるのは、ローカル推論、ブラウザ描画、その場ビルドのときだけだ。4 vCPU はテキストゲートウェイには贅沢で、14B には必須になる。
ディスクは普通の SSD か NVMe か？
リモート API はディスクに鈍感だ。ローカルモデルのロードと Docker レイヤの展開では NVMe の差を感じる。ログローテーションを入れているなら、80 GB の NVMe の方が 160 GB の遅いディスクより価値がある。
ゲートウェイは Linux、制御面はクラウド Mac mini でもよい
常駐の OpenClaw Gateway には Linux VPS が向く。安い、イメージが標準、Docker の資料が揃っている。一方で、同じ流れの中で Safari 受け入れ、Xcode 署名、あるいは低消費で落ちにくい当番機が欲しくなったとき、すでに Docker とログを抱えた Linux へ負荷を足すと、メモリの帳はすぐに元へ戻る。Apple Silicon のユニファイドメモリ、待機およそ 4W、長時間の無人運転に向く macOS。この三点は、「Linux を 32 GB へ上げる」とは別の軸の選択になる。
安定する分け方はこうだ。Linux クラウドはゲートウェイとリモート API 専用。クラウド Mac mini は、本物の macOS が要るビルドとデスクトップ自動化専用。Homebrew、Docker、SSH は Mac ですぐ使え、ブラウザスキルを足すために Ollama と同じ RAM を奪い合う必要もない。
Linux の枠を本稿で決めたなら、次は推論とメモリを奪い合わない制御ノードをチームに残す番だ。VPSSpark クラウド Mac mini M4 がその位置に当たる。プランを今すぐ確認し、週単位でも月単位でも一台足す。すべてのプロセスを同じ VPS に詰めるより、切り分けが楽になる。