すでにサイト内のUbuntu 24.04 + systemd + TunnelおよびDocker Compose本番の「重い運用形」を読んでいても、Windows／macOS／汎用Linux上でOpenClaw CLIとGatewayを確実に入れ、常駐させ、ヘルスチェックまで通す必要があります。本文はその層を補い、三環境共通の前提、OS別対照表、インストールからデーモンまでの6ステップ、導入段階で多いエラー、および2本の本番記事との境界を示し、ノートPC、WSL2、小さめVPSでも同じ思考モデルを再現できるようにします。
OpenClaw Gatewayは長時間動くサービスプロセスにCLIツールチェーンが重なったものです。前提がずれると、その後のsystemd、Compose、Tunnelの設定が正しくても別の形で失敗します。以下はマルチプラットフォームの切り分けで頻出するパターンであり、チャットログではなく社内の「インストールRunbook」に書き残す価値があります。
Nodeバージョンの漂流：開発者PCは古いLTS、CIは別の系列、といった状態だと、Gateway起動スクリプトが機械Aでは動き、機械Bでは構文や依存で落ちます。公式バイナリやnvm、fnmなどで揃えた上で許容するマイナー範囲を文書化してください。
状態ディレクトリを同期ドライブへ：~/.openclawや同等パスをiCloud、OneDrive、各種クラウド同期配下に置くとロック、権限、競合が起きやすくなります。ローカルディスクに置き、バックアップ方針は別設計にします。
WindowsネイティブとWSL2のPATH混在：PowerShellで入れたCLIをWSLから叩く、あるいはその逆で、コマンド不在や証明書パス崩壊が起きます。主に使う実行面を1つに決め、チームで統一します。
macOSのTCCと配置：GUIに近いコンポーネントをダウンロードフォルダから直接動かすと、補助機能や自動操作の承認で止まり、無人運用が壊れます。/Applicationsなど安定パスを使い、OSアップグレード後は権限を再確認します。
ヘルスチェックの欠如：「プロセスがある」だけで終わり、ループバックのcurlやダッシュボードを見ないと、本番ネットワーク変更後に502だけが残る状況になります。
0.0.0.0への安易なバインド：管理面を全インターフェースに晒すと、監査とポートスキャンリスクが一気に増えます。トンネルやリバースプロキシと組み合わせ、ループバック寄せを基本にします。
トークンをシェル履歴へ：対話シェルにexportして共有したりスクショで流すのは鍵の共有と同義です。権限の厳しいファイルやシークレット管理に寄せます。
このチェックリストを踏んでから対照表に進むと、「同じコマンドが3台で3様」という摩擦が減ります。iOSビルドや常時GUIが必要なら、GatewayはLinuxやワークステーションに置き、重いApple Silicon作業は専用のリモートMac実行ノードへ分離する構成も取りやすくなります。
もう一つの隠れコストはドキュメントの分裂です。README、社内Wiki、数か月前のスクショが混在すると、誰も正とするNode範囲や状態パスを持てません。概念説明より、単一の正（Single Source of Truth）に「Nodeの許容マイナー」「状態ディレクトリ」「デーモン登録サブコマンド」を書いた方が効きます。
アップグレードにはロールバック窓を残します。CLIやGatewayのパッチ前に設定ディレクトリとトークンファイルを退避し、デーモン登録に失敗したら前のバイナリや前のイメージダイジェストへ戻せるようにします。「起動した」だけで祝うチームは、設定キー廃止に夜中に遭遇しがちで、変更ログとステージングでのonboard試行で先に潰せます。
複数のエージェント事業線がある場合、「開発機の手作業インストール」と「本番のsystemd／Compose」をタグや名前空間で分け、実験用プラグインディレクトリを本番の状態パスへ同期しないようにします。開発は独立プレフィックス、本番は読み取り専用設定マウントと書き込みデータボリューム、の最小分離が有効です。
余裕があれば予備VMでプロセスkillやAPIキーローテーションを演習し、status、ログ、デーモン削除コマンドがRunbookに揃っているか確認します。図より手順の暗記が運用では効きます。
三環境は同じGatewayを動かせますが、プロセス監督、ログの見方、アップグレードとロールバックの持ち主が異なります。表に固定しておけば、設計レビューでWindowsサービスとLaunchAgentを混同しにくくなります。
| プラットフォーム | よくある導入経路 | 常駐（デーモン）の考え方 | 典型のつまずき |
|---|---|---|---|
| Windows | 公式インストーラ、PowerShell一発スクリプト、パッケージマネージャ | Windowsサービスやタスクスケジューラ（ログディレクトリのACLを明示） | ネイティブとWSL2の二重環境、AVの誤検知、スペース入りパス |
| macOS | Homebrew、curl系インストーラ、上流リリース | LaunchAgent／LaunchDaemon（ログインセッション要否で選択） | TCC、Gatekeeper、状態ディレクトリの所有者 |
| Linux（汎用） | ディストリパッケージ、静的バイナリ、npmグローバル（上流推奨に従う） | systemdユーザ／システムユニット（本番例は裸機長編） | SELinuxやAppArmor、最小イメージの依存欠如、127.0.0.1のループバックがiptablesで誤って潰される |
クロスプラットフォームで揃えるのは「どのインストーラを押したか」ではなく、バージョン固定、状態のローカル化、リスナー面の縮小、スクリプト可能なヘルスチェックです。
Linuxで本番級のTunnelとユニットファイルまで行く場合はUbuntu 24.04 + systemd + Tunnelの手順へ切り替え、イメージダイジェストと命名ボリュームが主題ならDocker Compose本番編を使います。本文は「CLI／Gatewayを正しく入れてデーモン化する」層に留め、3記事でスコープを奪い合わないようにします。
以下は上流CLIがonboardとデーモン登録系サブコマンドを提供している前提です。名称が違えば--helpに従いつつ、順序だけは崩さないでください（設定が先、監督が後）。
ランタイム固定：node -vを上流要件と突き合わせ、足りなければ先にNodeを上げます。
CLI導入：OSごとの推奨経路を使い、sudo管理のグローバルとユーザーグローバルを同一アカウントで混ぜないようにします。
設定と秘密情報：モデルベンダーのキーはenvファイルやシークレットストアへ、権限は600相当に。公開リポジトリへ書かない。
onboard実行：Gateway設定とトークンを生成または検証し、出力パスをRunbookに記録。
デーモン導入：上流のinstall-daemon系コマンドでクラッシュ時自動再起動とログディレクトリを一度に整える。
検収：status、health（あれば）、ローカルループバックのcurlの3点で「見かけ上のrunning」を排除する。
node -v openclaw --version openclaw onboard --install-daemon openclaw gateway status openclaw dashboard
ヒント：statusが正常でも外向きが死んでいるときは、プロセス問題と経路問題を分けます。先にホスト上でループバックcurl、次にトンネルやリバースプロキシを見て、Linux長編と同じ順で切り分けます。
Windows：開発の主戦場がWSL2なら、そのディストリ内でCLIとGatewayを完結させ、Linux本番とパス約束を揃えます。Windows側ファイルをDrvFs越しに触るとIOと権限差に注意。ネイティブサービスで載せるなら、サービスアカウントに状態・ログパスのACLを明示します。
macOS：GUI承認が必要な部品は安定パスに置き、ダウンロード直実行を避けます。OSアップグレード後は自動操作と補助機能を再確認。無人運用では、上流がUIを要求しない限りLaunchDaemon寄りが安全です。
Linux：すでにsystemdユニットを書けるなら本文を飛ばして裸機長編のテンプレへ。Dockerなら、コンテナとホストのループバック／Tunnelの責務をComposeに書き、二重Gatewayのポート争いを防ぎます。
トラブル時は症状→証拠→仮説の順で、ログを読めるverboseに一時的に上げつつ（常時ONはディスク圧迫）、同一バージョンで再現します。1台だけ失敗するなら環境変数、プロキシ、時刻ずれを比較してください。時刻ずれはトークンとTLSで奇妙な失敗を起こし、業務ロジックとは無関係に時間を奪います。
「ダッシュボードが開く」を本番準備完了とみなさないでください。ダッシュボードは局所的な検証に留まりがちです。本番前に典型タスクを上流からGateway経由で端到端に流し、認可・ルーティング・コールバックと再試行・レート制限を確認します。
注意：2026年も、スキャン可能なGateway管理面の公開は代表的な誤設定です。自動スキャンがある前提で、許可リスト、トンネル、mTLS、プライベート到達をオプションではなく基線として扱います。
以下は社内合意用のたたき台であり、第三者プロジェクトへの保証ではありません。実際に入れたバージョンのヘルプとリリースノートを正とします。
ノートPCや小さなVMだけでGatewayを「とりあえず」動かすのはデモには足りますが、スリープ、ディスクIO、Wi-Fiの揺らぎでエージェントワークフローが不安定になります。自前ラックのMacは減価償却と現場運用も乗ります。安定したApple Silicon実行層でビルドやスクリプト署名、Gatewayと並行する自動化が必要なら、重い処理を契約に基づくリモートMac専用ノードへ寄せる方が本番に近いことが多いです。導入の手間と長期運用を合わせると、コントロール面は慣れたWindows／Linuxに置き、実行面をNodeMiniのクラウドMac miniレンタルで拡張する構成は現実的です。
調達語彙を「ノード」に揃えると財務とも話しやすく、リージョンとディスク段、契約期間で予算を切れます。OpenClawのトラフィックが増えたときに、開発機イメージを毎回作り直さず実行層だけを増やせます。
トークン輪番の所有者、ファイアウォール例外の承認者、正とするダッシュボードURLを決めておくと、機能フラグよりそこで障害が減ります。
本文は三環境の汎用インストールとデーモン検収を扱います。Ubuntu systemd編とDocker編は本番トポロジです。ほかの記事はOpenClawカテゴリから絞り込めます。
Nodeのバージョン、状態ディレクトリが同期ディスク上にないか、ターミナルがWindowsネイティブかWSL2かです。並列ノードが必要ならレンタル料金を参照してください。
SSH／VNCや一般的なネットワークはヘルプセンターを検索してください。Gatewayのルートとトンネルは上記2本の本番長編へ戻って照合します。