OPENCLAW_2026
INSTALL_
NPM_DOCKER_
PNPM_MATRIX.

// 課題：npm グローバル・Compose・pnpm ソースが混在し、設定の単一真実源が失われると CLI と Gateway が別々のパスを読む。結論：三経路マトリクスと五ステップ運用、リモート Mac launchd の観点を提示。関連：Docker 本番、onboard とデーモン、systemd/launchd、Mac セットアップ、プラン。

サーバーラックとネットワーク

1. 痛みの分解

（1）経路分裂＝設定分裂。グローバル CLI はホーム、コンテナは別マウント、リポジトリに別設定があり reload が効かないように見える。（2）Node 22 は契約。18/20 前提の手順は CI とノートで minor がずれるとネイティブ拡張で即死する。（3）更新順序。イメージだけ戻してボリュームを放置すると半移行状態になる。（4）観測と権限のズレ。sudo で入れたグローバルとユーザー prefix が混在したり、launchd の実行ユーザーと状態ディレクトリ所有者が一致しないと「動いているのに書き込めない」偽陽性が出ます。runbook には実行ユーザー・カレント・umaskを固定で記載してください。

2. 三経路マトリクス

軸npm グローバルDocker Composepnpm ソース
速度最速の試行中、ボリューム必須遅い、監査向き
隔離弱い強い中程度
永続化ホーム配下を文書化明示マウント実行方法に依存
更新npm i -gタグ変更＋pullgit + pnpm + build
ロールバック版固定タグ＋スナップショットタグ/ブランチ

3. 五ステップ

  1. ランタイム固定：Node 22+ または README が明示する LTS 帯を全環境で統一し、「非対応レンジ」を文書化します。Docker では compose ファイル名・イメージ参照（タグか digest か）・ベース更新権限まで凍結します。
  2. 四類のディレクトリ地図：設定・秘密・セッション/スキル状態・ログを図示し、compose にはホスト側バインドパスをコメントで残し、インシデント時にコンテナ内パスだけを追わないようにします。
  3. ゴールデンパス：onboard → 最小チャネル smoke → 前景 Gateway → launchd/デーモン化まで、期待ログと正常判定を runbook にコマンド単位で記録します。
  4. 更新 SOP：変更票 → ボリューム/ディレクトリのバックアップまたはストレージスナップショット → 更新 → openclaw doctor → channels probe。バックアップ省略はチェックリストで止めます。
  5. ロールバック SOP：パッケージ/イメージとデータをセットで戻し、無応答ランブックの status/doctor を再実行してから復旧宣言をします。
node -v which openclaw openclaw --version

4. 計画数値

  • 形態を二種類以上、14 日以上ドキュメントなしで併存すると週 2～4 時間の「どの Gateway が本番か」会議が増える。
  • 本番変更は少なくとも一回復元可能なボリューム/ディレクトリスナップショットを伴うべき。
  • リモート Mac では launchd の WorkingDirectory を CLI 既定と揃える。

5. リモート Mac の判断

シグナルアクション
7×24 が要るがノートはスリープVPS またはリモート Mac＋launchd
コンテナとホストで DNS/NTP が食い違う本番はトポロジを一本化
Apple クリエイティブツールと同一 SLAリモート Apple Silicon を検討

変更規律：チケットまたは構成管理に「インストール形態・ボリューム ID・オンコール責任者」の三つ組を必ず紐づけます。無いと事後レビューは「どこかで動いていた」止まりになります。リモート Mac では SSH 踏み台・画面共有・Gateway ヘルスのアラート経路を分け、ノイズで本障害が隠れないようにします。四半期ごとに「スナップショットからの復元＋ channels smoke」を演習すると、本番障害時の徹夜コストを大きく下げられます。

6. FAQ

グローバル CLI からコンテナ Gateway を操作する場合は URL・トークン・設定パスを一表にまとめないと「CLI は A、daemon は B」になります。rootless Docker は UID マッピングと compose の user 明示が重要です。

pnpm CI は pnpm i --frozen-lockfile を固定し、テスト用 Gateway の状態ディレクトリを本番から分離します。更新後にチャネル沈黙：三回再インストールする前に doctor／pairing を実行してください。

compose に healthcheck は必要か：Gateway に最小の生存確認（HTTP/TCP またはプロセス）を置き、restart とバックオフ上限を変更票に書きます。半起動のスラッシングを防げます。dev/stage/prod でスナップショット手順を共有してよいか：手順は共有、秘密は共有しない。環境ごとにリストア演習を行い、stage のトークンが prod ボリュームに混ざらないようにします。

7. 深掘り

2026 年は機能より単一真実源がボトルネックです。npm は速度、Docker は隔離とボリューム規律、pnpm ソースは監査性とビルド責務のトレードオフです。

Docker 運用ではイメージタグ方針（検証のみ latest、本番は不変タグまたは digest）、バックアップ窓（チャネル閑散帯）、compose プロジェクト命名を同一ページにまとめ、「誰がどのスタックを編集したか」を監査可能にします。pnpm では corepack・.npmrc・プライベートレジストリミラーをコードレビュー対象に含めないと、夜間ビルドで依存解決が揺れます。

カスタマーサクセス／オペレーション自動化では予測可能なロールバックと再現可能な環境が「常に最新」より優先されます。スナップショットなしの失敗アップグレードは日単位の損失になり、SLA では専用リモート Mac の月額より高くつくこともあります。インストール形態は運用半径と捉えると、半径が広いほど並行変更・交代・委託引き継ぎに耐えます。

長時間 Gateway と重いツール呼び出しは専用リモート Macへ分離し、インタラクティブ機は軽量 CLI に留める構成が増えています。Final Cut や Xcode とユニファイドメモリを奪い合わず、Docker／npm を否定するのではなく対話用とサーバ用を物理的に分ける発想です。本番は固定トポロジ（裸 launchd または単一 compose スタック）、ノートはチャネルペアリングとスキル検証に専念し、フタを閉じた瞬間に自動化が死ぬ事故を設計で潰します。

8. まとめと MACGPU

（1）各経路の限界：グローバルはシステム Node・権限・MDM/セキュリティ製品と衝突しがちです。Docker はボリュームとイメージ規律が要で、DNS/NTP のズレがあると調査コストが跳ね上がります。ソースは lockfile と CI 規律が無いと「ビルドは通るが Gateway が不安定」になります。文書なしの混在は設定ドリフトを指数関数的に増幅します。

（2）リモート Mac の利点：Apple Silicon・ユニファイドメモリ・クリエイティブ／自動化スタックが揃い、24/7 Gateway に向きます。launchd をデスクトップセッションから切り離すとチャネルジッターと GUI 割り込みが減り、運用境界が明瞭になります。

（3）MACGPU：低リスクで「単一路径＋launchd 常駐」を検証したい場合、専用リモート Mac をレンタルし、大きな設備投資の前に実測できます。CTA はログイン不要で公開プランへ誘導します。