2026年 OpenClaw：Docker から本番ハードニングまで（逆プロキシ・トークン・トラブルシュート・リモート Mac ワークフロー）

2026年3月30日 · 約8分 · MacCompute テクニカルチーム · ガイド

本稿は OpenClaw の公式 Docker ドキュメント（openclaws.io、2026年3月時点の公開内容）に合わせ、Docker デプロイから本番環境の最小ハードニング、よくあるエラーの切り分け、リモート Mac上での長時間エージェント／バッチ連携までを一気通貫で整理します。料金・契約は 料金ページ、初回接続は ヘルプセンター、記事一覧は ブログ索引からどうぞ。

① 2026年の前提：なぜ今 OpenClaw を「自前ゲートウェイ」で持つか

エージェントをチャットや社内ツールに載せるほど、「常時起動のゲートウェイ」「設定とワークスペースの永続化」「隔離されたツール実行（サンドボックス）」が実務上のボトルネックになります。Docker 経由は再現性と隔離に強く、VPS や社内サーバ、あるいは MacCompute のようなリモート Mac に置いて夜間バッチと同居させる構成が現実的です。本稿は概念紹介ではなく、コピー可能なコマンドと検証項目中心です。

② 環境と前置チェックリスト（着手前にチェック）

次を満たしてから docker-setup.sh に進むと手戻りが減ります。

  • Docker Engine / Desktop ＋ Compose v2 が動作している（docker compose version）。
  • RAM：イメージビルドは公式に「約2GB以上推奨、1GB級では exit 137 の可能性」とあります。運用だけなら OPENCLAW_IMAGE=ghcr.io/openclaw/openclaw:latest でビルドを避けられます。
  • ディスク：イメージ・ログ・~/.openclaw バインド用に余裕（公式は数GB規模を想定）。
  • 本番公開時：ドメイン・証明書（Let’s Encrypt 等）、ファイアウォール方針。公式は VPS 公開時に「ネットワーク露出（bind・ポート・ファイアウォール）」のハードニング文書と Docker の DOCKER-USER への言及があります。
  • macOS/Windows：Docker Desktop 側でバインドマウントパスが共有対象になっているか。

③ 再現インストール：ホスト CLI と Docker／docker-setup の対比

公式の整理では、普段使いの最短ループはホスト直インストール、隔離・サーバ常駐・検証はコンテナ化、が基準です。Docker ではリポジトリ直下の ./docker-setup.sh がビルドまたはプル、オンボーディング、Compose 起動、.env へのゲートウェイトークン書き込みまでを担います。

観点 ホスト標準インストール（通常フロー） Docker + docker-setup.sh
向く用途 ローカル開発の反復が最優先 VPS／専用機での常駐、チームで同一イメージを再現
主な入口 公式インストーラ手順（ドキュメントの Installer） git clone …/openclaw.git && cd openclaw && ./docker-setup.sh
ビルド省略 該当（ホスト依存） export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest" で docker pull 側へ
設定の置き場 ユーザー環境 ホストに ~/.openclaw と ~/.openclaw/workspace をバインド
Control UI 既定で http://127.0.0.1:18789/（トークンは設定画面へ）
公式 Docker ページの説明を要約した対比。一次情報は https://openclaws.io/docs/install/docker、ネットワーク露出時の観点は Security（bind・ポート・ファイアウォール） を参照してください。

手順（最小）

git clone https://github.com/openclaw/openclaw.git
cd openclaw
# 任意: ローカルビルドを避ける
export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
./docker-setup.sh

起動後のスモーク：curl -fsS http://127.0.0.1:18789/healthz および …/readyz（公式にプローブ用として記載）。

④ 最小セキュリティ：待受、トークン、サンドボックスと外向き通信

待受（bind）：設定の gateway.bind には lan／loopback などのモード値を使うのが前提で、0.0.0.0 などのホスト別名はレガシー扱いです。Docker では既定が LAN 寄りで、ホストのブラウザから 127.0.0.1:18789 へ届く想定です。loopback のみにすると、名前空間の関係でホスト公開ポートから期待どおり繋がらないことがあります。

トークンと端末：.env にゲートウェイトークンが生成されます。Control UI は Settings → token。未承認端末は docker compose run --rm openclaw-cli devices list と devices approve <requestId> で公式手順どおり解消します。

サンドボックス：エージェントツールを Docker 内に閉じる構成は export OPENCLAW_SANDBOX=1 を付けて docker-setup.sh（docker.sock マウント等）。既定は外向き network: "none" 思想で、egress が要る場合は設定で明示的に見直す必要があります（ deny が allow に勝つポリシー）。

共有境界の自覚：同梱の openclaw-cli コンテナはゲートウェイとネットワークを共有しループバックで通信する設計のため、CLI とゲートウェイを「完全分離した信頼境界」として扱うなら別ホスト／別ネットワークパスを検討、と公式に注意書きがあります。

⑤ Nginx / Caddy：HTTPS ターミネーションと 18789 への中継

インターネットに晒す前に、(1) ファイアウォールで 直接 18789 を全世界に開けない、(2) TLS は逆プロキシで終端、(3) 管理 UI は IP 制限または VPN 背後、を推奨します。WebSocket を使うクライアントがあるため、アップグレードヘッダを通すのが一般的です。

Nginx（概念スニペット）：証明書パスは環境に合わせて差し替え。

location / {
  proxy_pass http://127.0.0.1:18789;
  proxy_http_version 1.1;
  proxy_set_header Host $host;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
}

Caddy：reverse_proxy 127.0.0.1:18789 に自動 HTTPS を載せる構成が簡潔です。公開後も healthz を監視対象に入れてください。

⑥ 問題排查マトリクス（症状→最初の一手）

ログはホスト側のバインド先（~/.openclaw 以下）とコンテナログを併読すると早いです。

症状・ログ よくある原因 確認・対処
ビルド exit 137 ビルド時 OOM RAM 増設、または OPENCLAW_IMAGE で GHCR イメージ利用
18789 接続拒否 Compose 未起動／ポート競合 docker compose ps、ホストで lsof -i :18789 相当で占有確認
pairing required / 1008 端末未承認 openclaw-cli dashboard --no-open、devices approve
CLI が ws://172.x に向く等 gateway.mode / bind 不整合 公式記載のとおり config set gateway.mode local と gateway.bind lan を確認
EACCES（.openclaw 配下） バインドマウントの UID 不一致 コンテナは uid 1000 想定。Linux なら chown -R 1000:1000（公式例）
readyz が 503 管理チャネル未接続など 公式説明：起動猶予後も必須チャネルが落ちていると準備未完
一次対応用。根因はログと設定差分で深掘りしてください。

⑦ 業務例：リモート Mac 上で「ビルド → スクリプト → 通知」まで繋ぐ

MacCompute などのリモート Macは、Xcode ネイティブビルドとコンテナ／エージェントを同居しやすいのが強みです。OpenClaw を載せる場合の一例：

  1. 接続：SSH でログイン（鍵・known_hosts は 初回セットアップ記事参照）。
  2. Docker：Desktop または Colima 等、社内標準に合わせて起動し、上記 docker-setup.sh を実行。
  3. ワークスペース：リポジトリを ~/.openclaw/workspace にマッピングされるホスト側に配置し、CI と同じスクリプトを叩けるようにする。
  4. 長時間ジョブ：launchd または nohup＋ログローテで夜間ビルド。OpenClaw 側の自動化は docker compose run -T --rm openclaw-cli … 形式が公式に「CI 向け」と紹介されています。
  5. 通知：ビルド結果を Slack/Webhook へ。ゲートウェイと業務通知は疎結合にし、トークン類はリポジトリに入れない。

期待結果：リモート Mac 単体で「エージェントがゲートウェイ経由でツール実行し、ホストのワークスペースに成果物が残り、バッチ完了を外部に通知する」一連が cron／launchd 周期で再実行可能になる状態です。

⑧ FAQ と短い排错リスト

Q. サンドボックスを有効にすると何が変わる？
A. メイン以外のセッションのツールが Docker 内に隔離され、既定はネットワークも厳しめです。外向き API が必要なワークロードはポリシー設計が必須です。

Q. なぜ「同じ Docker 構成」をチームで共有したい？
A. 依存と権限の差分を減らし、CI と本番の再現性を上げるため。トークンとチャネル秘密情報だけは Secret 管理に分離します。

切り分けチェック（短文）：docker compose ps → healthz → devices list → ホストの ~/.openclaw 権限 → 逆プロキシの Upgrade ヘッダ、の順が短いです。

まとめ：OpenClaw の Docker 経路は docker-setup.sh と 18789、gateway.bind のモード設計、トークン＋端末承認が中心です。本番では逆プロキシ＋TLSとファイアウォールで露出面を抑え、サンドボックスとツール allow/deny を業務に合わせて絞ってください。夜間バッチや長時間エージェントを安定して回すなら、自前 Mac の冷却・停電・回線よりデータセンター常駐のリモート Macに寄せた方が運用が単純になるケースが多いです。購入・レンタルでスペックを選び、手順の補足は ヘルプ、サイト全体は ホームからどうぞ。

リモート Mac を選ぶ 料金を見る ヘルプ
今すぐ購入