2026年版 OpenClaw 本番運用:
Docker・Gateway 常駐、トラブルシュートとロールバック

約 16 分で読めます · MACCOME

プラットフォーム別に導入できても、本番では 24/7 Gateway・健全な Docker ボリューム・状態を壊さないアップグレードが別問題です。 本稿はエージェントを「契約できるサービス」に近づけたいチーム向けに、事前チェックリスト、Docker と npm のトレードオフ、常駐 Compose の型、症状別の切り分け表、トークン・ログ・バックアップ・ロールバックの順序を整理します。Windows / macOS / Linux の導入編とあわせ、安定した出口ホストが要る場合はリモート Mac 実行層も参照してください。

「動く」から「当番になる」までで踏みがちな六つの落とし穴

  1. 開発ノートだけを唯一の Gateway にする:スリープ・アップデート・GUI ダイアログでセッションが途切れ、専用ノードより復旧コストが膨らみます。
  2. latest を匿名追従:上流が一晩でポートや設定スキーマを変え、CI の pull が無公告リリースになります。
  3. ボリューム UID の綱引き:root とコンテナユーザの所有権不一致が、SQLite や I/O の曖昧なエラーに見えます。
  4. モデルベンダーと出口が噛み合わない:企業プロキシや地域制限は 403 よりタイムアウトで現れがちです。
  5. Gateway トークンを平文で Git に:CI とノートの秘密情報混在はオフボーディングと fork リスクを増幅します。
  6. 「再インストール」以外にロールバック手順がない:RTO を説明できず、復旧手順も再現できません。

Windows / macOS / Linux の差分がまだ曖昧なら、先に OpenClaw 導入とプラットフォーム選択 を読み、コンテナ化の話に戻ってください。

事前チェック:Node・メモリ・鍵・出口(15 分)

コミュニティインストーラと Docker イメージは進化します。以下はオーダー感の目安で、固定するリリースの説明と必ず突き合わせてください。

  • ランタイム:2026 年時点の多くの文書は Node 20 LTS または 22 を基準にします。イメージ側に同梱されることが多く、ホストは Docker Engine と Compose プラグインが新しめであれば十分な場合があります。
  • メモリ:軽量 Gateway でもコンテナ上限 2〜4 GB を目安にし、チャネル並列やローカルモデルがあるなら余白を足します。
  • 秘密情報:ベンダー用と Gateway 認証用で最小権限の鍵を分け、オーケストレーションの secret とマウントファイルを同時にローテーションします。
  • 出口:Gateway と同じ経路からベンダ API をプローブし、企業 MITM ルートやプロキシを検証します。
観点Docker Compose(本番寄り)ローカル npm / インストーラ(反復寄り)
再現性高:イメージが依存を固定中:グローバル Node/OS ドリフトの影響
分離・複数インスタンス容易:ネットワーク・ボリューム・リソース上限難:ポートと設定の衝突
アップグレード速度制御:タグやダイジェストで段階投入速い:上流 main を追いやすい
デバッグexec やソース bind-mountブレークポイントが直截
運用コストpull・ボリュームバックアップ・compose 衛生ホスト汚染・デーモン整合
bash
# 流れの例—サービス名は固定したリリースのドキュメントに従う
git clone https://github.com/openclaw/openclaw.git && cd openclaw
# 提供されていれば: bash docker-setup.sh
# docker compose pull
# docker compose run --rm <cli-service> onboard
# docker compose up -d <gateway-service>
# docker compose ps
# curl -fsS http://127.0.0.1:<health-port>/health || echo "パスはドキュメント参照"
warning

注意:サービス名・環境変数・ヘルスパスはリリースで変わります。スニペットは型として扱い、凍結したタグの公式手順で必ず検証してください。

Gateway を Compose で常駐させる六ステップ

  1. 版を固定:compose にイメージタグまたはダイジェストを明記し、本番での匿名 drift を禁止します。
  2. ボリューム分割:設定・状態・ログを分け、クラスごとにバックアップ RPO を決めます。
  3. 依存と再起動:restart: unless-stopped はクラッシュ復帰用で、設定ミスは直しません。ヘルスチェックを足します。
  4. ヘルスチェック:公式の HTTP/TCP プローブを使い、LB や watchdog の意味と揃えます。
  5. 可観測性:stdout かファイルのどちらかで検索可能なログを一本残し、アラートに繋ぎます。
  6. 変更管理:ポート・ボリューム・環境変数の変更は diff とロールバック用タグを残し、口頭インフラにしません。
症状疑う順推奨アクション
Gateway が即終了環境変数不足・エントリポイント変更compose ログを読み、必須キーをリリースノートと突合
ポート使用中古いプロセスやホスト競合ss -lntp で所有者を特定し再マップまたは停止
モデルタイムアウト出口・プロキシ・DNS・リージョンコンテナ内 curl で確認し証明書/プロキシを点検
SQLite / ロック二重ライター・UID 不一致主ライターを一つにしボリューム権限を修正

本番の固め方:トークン・露出・バックアップ・ロールバック順

Gateway トークンはシークレット注入とし、イメージ層に焼かないでください。HTTP を公開する場合は手前で TLS 終端とレート制限を置き、内聞きでも横展開を想定します。

ロールバック順:① 稼働ダイジェストと compose リビジョンを記録 ② Gateway 停止 ③ ボリュームスナップショット復元 ④ 前タグで docker compose up -d ⑤ ヘルスチェックと E2E プローブを一発

運用レビューに載せる三つの数値指標

  1. コールドスタートから健全化まで:compose up からプローブ成功までの P95 を追跡し、跳ねたら CPU 増設より pull とボリューム I/O を疑います。
  2. エラー種別と遅延:4xx/5xx と TCP タイムアウトを分け、レート制限を Gateway 死と誤認しないようにします。
  3. リストア訓練:四半期ごとに隔離ホストへボリューム復元して Gateway 起動—RTO を数字で出し、感覚語を捨てます。

常時稼働リモート Mac に Gateway を載せる判断

Xcode ビルド・シミュレータ・署名など Apple ツールチェーンとエージェントを同居させるチームは、個人ノートから 課金可能な 24/7 専用 Mac(ベアメタル)へ Gateway を移すほうが安定しやすいです。デーモンとログは SSH 既定、GUI 切り分けだけ VNC とし、SSH と VNC のガイド を参照してください。

ノート単体では本番 Gateway になりにくい理由

スリープ方針、バラバラな OS アップデート、複数人デバッグ時のポート漏れがノート運用の弱点です。ダイジェスト未固定のコンテナは、ホストドリフトを再現性の幻想で隠すだけになりがちです。

持続可能な型は 専用リモート Mac(または同等ベアメタル)上で Compose によりランタイムを固定する実行面 です。MACCOME のクラウド Mac は複数リージョンの Apple Silicon と明確なレンタル条件を提供し、OpenClaw を iOS/macOS 自動化と同居させるときに有効です。地域は マルチリージョンガイド と公開の 料金 で比較し、シンガポール東京ソウル香港米国東海岸米国西海岸 から発注できます。

接続・セッションは ヘルプセンター を参照してください。

よくある質問

本番は Docker と npm のどちらですか?

再現性なら Compose、深いデバッグならローカル npm。段階設計は 導入とプラットフォーム選択 から。

Gateway が落ちたとき最初に?

ポート・ヘルスパス・コンテナ出口・ボリューム権限。SSH/VNC と接続は ヘルプセンター を参照。

リモート Mac 接続との組み合わせは?

自動化は SSH 優先、GUI は必要時のみ VNC—SSH/VNC ガイド

リージョンと料金の比較は?

マルチリージョン意思決定表レンタル料金