想定読者：断片的な手順で npm i -g openclaw は入れたが、ワークスペース・Gateway・チャンネル・Skillsの間を行き来するだけで、推奨のopenclaw onboard シーケンスに落ちておらず、Node 24・デーモン・stable／beta／dev チャンネルの揃え方に自信が持てない方です。成果： レビュー可能な手順としてdoctor → onboard → 初回チャンネル検証 → 初回 ClawHub Skill → デーモン導入 → 文書化されたアップグレード／巻き戻しを一続きで示し、「とりあえず起動した」から「手離れで常駐する」まで持っていきます。地図： 六つの落とし穴 → 経路表 → 六ステップ → 監査フィールド三つ。併読は docker-setup＋GHCR、Compose pairing 1008、post-install doctor です。
上流は onboard を推す理由は、Gateway・ワークスペース・チャンネル・既定モデルに順序上の依存があるからです。ウィザードを抜けて JSON を手編集すると、「プロセスは立つがメッセージが来ない」や「Skill は入ったがツールが登録されない」に落ち着きがちです。2026 年のコミュニティ スレッドで繰り返し見る誤解を六つ挙げます。
openclaw doctor の省略： onboard 終盤に詰まったとき、 doctor を通していないと二分の足場がありません。doctor は装飾ではなく関所として扱います。コンテナ運用を主にする方は、docker-setup＋GHCR を第一に、本稿を第二に置いてください。サブエージェントのペアリングに悩む場合は、npm を入れ直す前に Compose 1008 を先に確認します。
運用面の補足として、同じリリース週内で CLI・Gateway・Skills の各ログ先頭行を変更チケットに貼っておくと、定例の週次レビューで「誰の端末の実験版が本番向け口に入ったか」を素早く追跡できます。大げさに聞こえますが、多人数環境ではこの一行ログの採番だけで週一の手戻りを潰せることが多いです。
複数拠点でノードを分けている場合、変更多に「このホストの node -v、openclaw --version 相当、Gateway プロセスの起動時刻（UTC）」の三行を毎回そろえておくと、週次のふるまい不具合の多くがチャンネル混線として説明可能になります。三行が揃わない週は、雲事業者や回線のせいにする前に、まず社内のデプロイ順序を疑う価値があります。
| 道筋 | 向いている用途 | 採取すべき成果物 | 本稿との関係 |
|---|---|---|---|
openclaw onboard（npm グローバル） | 常時稼働 Gateway を据える専用 Mac や VPS | ワークスペース、openclaw.json、launchd/systemd ユニット、チャンネル実証、Skill 検証ログ | 主軸 |
| 公式 Docker／Compose | イメージ配布と揃ったランタイム | Compose 定義、ボリューム割当、OPENCLAW_IMAGE の切替方針 | 補完 |
| doctor 中心の切り分け | 入れ終わったが健全でない | 症状の枝とログの特徴 | 平行して読む |
注意： onboard はユーザーのホーム配下に書き込みます。共有 macOS アカウントでは方針を確認してから実行してください。本番は専用ホストやサービス アカウントを推奨します。
node -v を記録します。npm i -g openclaw@latest のあと openclaw doctor。高リスクは onboard 前に解消します。openclaw onboard： ワークスペース、既定モデル、AGENTS.md 注入、少なくとも一つチャンネルを完了。ウィザード表示から Gateway ポートと Control UI パスを控えます。openclaw skills search → openclaw skills install <name> → Gateway 再起動 → openclaw skills list。openclaw onboard --install-daemon（または同値のウィザード操作）。openclaw update --channel beta|dev を試す前に、ログローテーションとディスク余裕の監視を置きます。node -v npm i -g openclaw@latest openclaw doctor openclaw onboard openclaw skills search "calendar" openclaw skills install example-org/some-skill openclaw restart openclaw skills list openclaw onboard --install-daemon openclaw update --channel stable
v24.x、nvm など。OS アップグレードのたびに doctor を再実行します。stable|beta|dev をカレンダー上の窓に対応づけ、巻き戻しでは CLI と Gateway のバージョンの組を残します。これはベンダー SLA ではなく、社内の監査用フィールドです。CI と同じホストを使うなら、ビルドがログや SQLite のステートを飢えさせないよう CPU・ディスクのアラートを足します。
設計として onboard は自動化の錨（いかり）です。ワークスペースと Skills ディレクトリが固まると、バックアップと更新の真実は一箇所に揃います。ここを抜くと、会議は「誰の openclaw.json か」に費やされます。月次の容量レビューでは、チャット履歴のエクスポート方針と併せて、~/.openclaw 相当の位置を一緒に見る習慣にすると、四半期ごとの緊急掃除が減ります。
スリープ、VPN の瞬断、企業ポリシーは Gateway の時間の連続性を壊します。OpenClaw が小チームの事実上の制御面になるなら、7×24 で安定したディスクと出口を持つホストを優先し、必要ならノートは CLI クライアントに留めます。
自宅やオフィスのタワー型もパッチと電源の窓が予測しづらい場所があります。iOS 向けビルド農場と AI エージェントを同居させ、複数リージョンで governed な Apple Silicon クラウドに載せる方が、借り物ノートより運用指標が出しやすいことが多いです。MACCOME ではベアメタル ノードと柔軟な契約枠を用意しています。まず公開料金とヘルプセンターで接続とアクセス方針を確認してください。
パイロット案：一週間、専用リモート Mac 上で onboard＋デーモンを回し、ログ量と CPU ピークを取ったうえで、本番用 Gateway を最初の一週間から個人開発機に縛るのを避けてください。
本番切替の前に、同じホスト上で openclaw doctor を再実行し、環境に合わせた Gateway のヘルス応答（ある場合は URL）のスクショも変更票に添付する運用にすると、定例のロールアウト審査が短く済みます。一時的に beta CLI と stable Gateway を併用する場合は、週次で一つのチャンネル合わせに戻すをチームルールに明文化してください。パッチ直後のディスク圧迫は、ログローテ未設定のときに多発するため、openclaw のステート配下とシステムログの両方にしきい値を掛けておくのが安全です。これらは公式 SLA ではなく、中規模以上のチームで週一の定例品質を落とさないための最低限の型です。機微なセッション内容を含むデプロイでは、保持期間と匿名化方針を法務と先に揃えてください。ノート PC を CI と共用する拠点では、週次で openclaw の作業用ディレクトリと DerivedData の大きさを併記すると、月次のディスク圧迫事故をほぼ防げます。
FAQ
WSL2 でも手順は macOS と同じですか？
大枠は同じですが、パスとネットワーク制約は異なります。launchd 前提にせず、doctor＋WSL2 切り分けの順に進めてください。
Skill を入れたのに list が空です。最初の一手は？
Gateway の再起動とワークスペース可視性を確認し、Gateway 無反応向け切り分けを読んでから、ベータ チャンネル変更に進んでください。
Docker 導入と衝突しますか？
併用は可能ですが、同一のデータ ディレクトリは共有しないでください。方針に合わせて npm かコンテナのどちらを主にするか選び、docker-setup＋GHCRの前提と揃えてください。