なぜ OpenClaw を本番で使うとき「動く」だけでなく安定性と運用を考えるか
ローカルで試すときは再起動や設定変更で済むが、7×24 タスク・複数ユーザー接続・飛書/企微などのチャネル連携では、環境のずれ・ポート競合・API レート制限・プロセス異常終了がそのまま業務に影響する。本番の目標は予測可能・復旧可能・可観測であること。そのためデプロイ方式・依存バージョン・ログと監視・実行ノード（自機 vs リモート Mac）をあらかじめ決める必要がある。
よくある課題は、Node や NPM のバージョン差による「自分の環境では動く」、API キーや設定の漏洩、ポート 18789 の占有、メモリやコンテキスト過多による OOM、ノートPC のスリープによるタスク停止など。試用段階では許容できても、本番では規範的なデプロイと運用で避けるべきである。
Docker とベアメタルデプロイの比較：ポート・リソース・アップグレード・ロールバック
本番運用の観点で両方式を比較した表で、チームのリソースと慣習に合わせて選べるようにする。
| 観点 | Docker デプロイ | ベアメタル | 推奨 |
|---|---|---|---|
| バージョン・ロールバック | イメージタグで固定、ロールバックはイメージ差し替え | コードと依存のバージョンは自前管理 | マルチノード・CI なら Docker |
| ポート・分離 | コンテナ内ポートをマッピング、ホストと分離 | ホストの 18789 などを直接使用 | 複数インスタンスなら Docker |
| リソースオーバーヘッド | イメージ・コンテナ層のコストあり | 追加レイヤーなし、リソースを直接利用 | 単一ノード常駐ならベアメタル可 |
| アップグレード・保守 | 新イメージ取得・コンテナ再起動で完了 | マシン上で git pull・npm install など実行 | マシンに触りたくないなら Docker |
| 調査のしやすさ | コンテナに入るかコンテナログを確認 | プロセスとローカルログを直接確認 | Linux に慣れたチームはベアメタルが直感的 |
「保守を減らし可用性を高めたい」なら、ネットワークと権限を整えたリモート Mac 上で OpenClaw を動かし、ホスティング側にノードの可用性を任せる選択もある。
Node バージョン・NPM タイムアウト・API キー・ポート占有など 10 大よくあるエラーと対処
- Node が古い： Node 18.x LTS 以上を使い
node -vで確認。環境によっては 22.x が必要。 - NPM インストールがタイムアウト： 国内ミラーや
npm install --timeout=60000、必要ならプロキシ設定。 - API キーが無効： キーの完全性（余白なし）・有効期限・アカウント残高・本人確認を確認。
- ポートが占有されている：
lsof -i :18789でプロセス確認、または config.json のポートを変更。 - API 呼び出しタイムアウト： 国内から利用可能なモデル（例：智譜 GLM）に切り替えるか、タイムアウトを 60000ms に延長。
- Docker イメージの取得失敗： ミラー加速や国内レジストリを設定。
- スキルインストール失敗： スキル名のスペル確認、
openclaw skill updateでインデックス更新。 - Webhook コールバック失敗： サーバーにパブリック IP・ポート開放・ファイアウォール許可を確保。
- メモリ使用が高い： コンテキスト長を減らす・不要なプラグインをオフ・定期再起動。
- 応答が遅い： ストリーミング応答を有効化・高速モデル（glm-4-flash など）を使用・ローカルキャッシュを有効化。
監視・自動再起動・マルチノードのすすめ
本番では少なくとも：プロセス生存監視・ログの集約と保持・異常終了時の自動再起動を行いたい。
# 例：systemd または launchd でキープ（ベアメタル）
# Docker の場合は restart: unless-stopped
# ヘルスチェックの考え方
# 1. 定期的に OpenClaw のヘルスエンドポイントまたは 18789 ポートにリクエスト
# 2. 失敗時に再起動またはアラート
# 3. ログは固定ディレクトリに出力しローテーションして調査しやすくする
# マルチノード時：ロードバランシングまたはタスク分割で単一障害点を避け、キーと設定は SecretRef などで一元管理
監視指標には、プロセスの有無・ポートのリッスン状態・直近の成功応答時刻・メモリ・CPU 使用率を含めたい。アラートと自動再起動を組み合わせれば、深夜のダウンによる損失を大きく減らせる。
リモート Mac で OpenClaw を長期運用するベストプラクティスと CTA
リモート Mac で OpenClaw を動かすときは、ワークスペースと依存バージョンを固定し、設定とキーをコードから分離（SecretRef など）、ログローテーションとバックアップを設定し、API 呼び出しにレート制限とキャッシュをかけてコストと安定性をコントロールする。ホスト・ネットワーク・ファイアウォールを自前で維持したくない場合は、安定稼働とディレクトリ権限管理を提供するリモート Mac ホスティングを選ぶとよい。
自管マシンや VPS で Node バージョン・Docker・監視を維持するのは継続的な運用負荷になる。「常駐実行層」を SFTPMAC などの専門リモート Mac に任せれば、OpenClaw の業務設定と Skills に集中でき、ノードの可用性・ネットワーク・権限境界は当方で担保するため、7×24 安定運用が必要なチームに適している。
OpenClaw 本番環境は Docker とベアメタルどちらがよい？
Docker はバージョン固定・ロールバック・マルチインスタンス分離に適し、マルチノードや CI 連携向け。ベアメタルはリソースオーバーヘッドが少なく調査が直感的で、単一ノード常駐向け。7×24 安定運用でホストを触りたくない場合は、ネットワークと権限を最適化したリモート Mac ホスティングを選ぶとよい。
OpenClaw の Node バージョン・NPM タイムアウト・ポート占有エラーはどう対処する？
Node は 18.x LTS 以上を推奨し node -v で確認。NPM タイムアウトは国内ミラーや npm install --timeout=60000、必要ならプロキシ設定。ポート占有は lsof -i :18789 でプロセス確認か config.json のポート変更。API キーは完全性・有効期限・アカウント残高を確認。
リモート Mac で OpenClaw を長期運用するベストプラクティスは？
ワークスペースと依存バージョンを固定、監視と自動再起動を設定、ログとバックアップ方針、API 呼び出しのレート制限とキャッシュ。安定稼働と権限境界が必要なら、SFTPMAC などの専門リモート Mac ホスティングで自前運用コストを削減できる。
OpenClaw 本番では「動く」だけでなく「安定して動き・調査しやすく・復旧が早い」ことが重要です。運用の重心を業務と Skills に置きたいなら、7×24 の実行環境を SFTPMAC のリモート Mac に任せる選択がある。安定したノード・明確なディレクトリ権限・ネットワーク設定を提供し、OpenClaw の設定と連携に集中できるため、自管ホストと障害調査のコストを大きく削減できる。