1. なぜ「起動できるか」より「安定して走り続けるか」が重要なのか
2026 年の OpenClaw は単なる CLI ではなく、ブラウザ、モデル API、ファイル、OCR、スクリーンショット、Webhook、定期実行を束ねる複合 Agent です。重要なのは起動成否ではなく、ピーク負荷でも止まらず処理を続けられるかどうかです。
軽いコマンド自動化だけなら入門ノードでも動きます。しかしブラウザ自動化、長文脈、添付解析、複数 Agent の並列処理が加わると、負荷曲線は急に上がります。高くつくのは上位プランではなく、再試行と手動復旧です。
2. OpenClaw が重く感じられる三つの要因
（1）CPU スパイク。 OCR、スクリーンショット、ブラウザ収集、圧縮、複数段階の計画実行で 150%〜320% の瞬間ピークが起こります。
（2）メモリ蓄積。 アイドル時は 1.5GB〜2.5GB 程度でも、Chromium、長いセッション、添付解析が加わると 6GB〜10GB に到達します。
（3）ディスクとキャッシュ。 プロファイル、ログ、スクリーンショット、一時ファイルが数日で数十 GB に膨らむことがあります。
3. 2026年 リモート Mac 向け構成マトリクス
| シナリオ | 推奨 CPU / メモリ | 典型ピーク | 向いている用途 |
|---|---|---|---|
| 単独試用 | 8コア / 16GB | CPU 180%、メモリ 8GB | 個人検証 |
| 単独本番運用 | 10-12コア / 24GB-32GB | CPU 240%、メモリ 12GB | 日常自動化 |
| 2〜3 Agent 並列 | 12-14コア / 32GB-48GB | CPU 320%、メモリ 20GB+ | 小規模チーム |
| 24/7 常時稼働 | 14コア以上 / 64GB | CPU 350%+、メモリ 30GB+ | 企業運用 |
4. 5ステップの拡張手順
ステップ1： 24時間の実負荷を測る。
ステップ2： ブラウザと Agent を分けて計測する。
ステップ3： キャッシュ、ダウンロード、スクリーンショット、ログに上限を設ける。
ステップ4： ボトルネック別に拡張する。ブラウザ中心ならメモリ、待ち行列なら CPU、スクリーンショットとログ中心ならディスク。
ステップ5： 本番では 30% 以上の余裕を確保する。
5. 参考になる閾値
- 単一 Agent + ブラウザ： メモリピークは 6GB〜10GB が一般的。12GB を超えて張り付くなら 32GB ノードを検討。
- ログとキャッシュ： スクリーンショット + OCR で 1日 2GB〜5GB 増えることが多く、7GB/日を超えたら保持戦略の見直しが必要。
- 拡張トリガー： CPU ピークが 3日連続で 280% 超、または失敗率 2% 超なら、入門構成は卒業です。
6. 低スペック試行を飛ばすべきチーム
デモ目的なら低スペックでも構いません。しかし 24/7 稼働、複数ブラウザ、長期文脈、チーム共有、運用タスクを前提にするなら、最初から小さすぎる構成は避けるべきです。最初に起きる問題は速度低下だけではなく、時間窓の逸失、再試行の蓄積、状態汚染、アラート過多です。
2026 年の現実的な出発点は、ほとんどの利用者にとって 24GB〜32GB メモリです。並列数に応じて 48GB や 64GB に広げていく方が、速度だけでなく予測可能性と復旧性を確保できます。