2026年 OpenClaw 独占リモート Mac ノード交換と災害復旧移行：Gateway Token、LaunchAgent plist、Skills／プラグインデータディレクトリを SSH ヘッドレスで再現切り替えるチェックリスト＋意思決定マトリクスと FAQ

独占リモート Mac 上で OpenClaw を常駐させていると、ハード交換・再イメージ・別リージョンへの切り戻しで「同じ振る舞いを別金属に瞬時に復元」する要求が出ます。本稿は Gateway Token（クライアントとゲートウェイの境界）、LaunchAgent plist と launchctl、Skills／プラグインのデータディレクトリを一つの Runbook に束ね、SSH ヘッドレスだけで検証できる再現チェックリストと意思決定マトリクス、FAQ に落とし込みます。ヘッドレス上のリソース争いや観測性の整理は 2026年独占リモート Mac CI：Xcode テストプランと並列テストのセルフホスト Runner 上の資源争奪——xcresult 集約、Simulator 並列度、SSH ヘッドレス flaky 再現の意思決定マトリクス＋FAQ が参考になり、リモート Mac での自動化パイプライン全体のイメージは 2026年版：Fastlane + SSHで実現するリモートMac miniによるiOS自動ビルドと配信と併読すると「人間が触らないブートストラップ」の粒度が揃いやすいです。

1. 用語の固定：ノード交換と災害復旧（DR）の違い

計画ノード交換：同一方針のまま金属だけ入れ替える。DNS／Tailscale 名、証明書、ポート束縛を維持しやすい。DR 切り戻し：プライマリが応答不能になったあと、スタンバイまたはクリーン OS に「最小セット」だけ復元してトラフィックを寄せる。前者は「差分同期と段階的切替」、後者は「コールドスタートと秘密の再発行」を前提に設計が変わります。

どちらでも共通なのは、Gateway（リスナー）・常駐プロセス（launchd）・ツール／Skill が読む状態の三つを同じ順序で並べることです。

2. 再現チェックリスト（貼り付け用）

フェーズ	確認項目	合格基準（ヘッドレス）
事前	旧ノードから `launchctl print` で `Label` と `ProgramArguments` を書き出し、plist を Git に固定	新ノードで同じパスに展開し `plutil -lint` が通る
事前	Gateway Token／API 鍵の所在を「ファイル」「環境変数」「キーチェーン」のどれにしたか記録	新ノードで権限 `0400` 相当と所有者のみが読めることを確認
事前	Skills／プラグインのデータルート（キャッシュ、索引、ダウンロード物）を `tar` またはオブジェクトストレージに退避	リストア後に inode とパーミッションが旧と一致、または意図した差分のみ
カットオーバー	旧 Gateway を停止（`launchctl bootout`）→ 新で `bootstrap` → ヘルス URL を `curl`	インバウンドが二重起動していない（同一トークンで二重登録しない）
事後	ログローテーションとディスク水位、メモリ常駐サイズを 24h 観測	旧ノードの秘密をローテーションまたは失効済み

3. Gateway Token と秘密境界

移行で最も壊れやすいのは「Dashboard や CLI が参照する基底 URL」と「ゲートウェイが検証するトークン／Cookie／ヘッダ」の組です。DR ではトークン再発行を前提に、クライアント側のプロファイルを一括で置換できる Ansible／シェル片を先に用意しておきます。

単一ライター原則：新旧が同時に同じインバウンドアカウントへ接続しない。切替ウィンドウは秒ではなく「接続が落ちるまで」を明示。
ローカルループバック束縛：上流リバプロがいる構成では、ゲートウェイを 127.0.0.1 に閉じ、証明書と allowedOrigins を plist と同じリポジトリで管理する。
ローテーション順序：先に新側で受け入れ可能なトークンを発行し、DNS またはプロキシの重みを移してから旧を失効。

4. LaunchAgent plist と launchctl（ヘッドレスの現実）

LaunchAgent はログインユーザセッションにぶら下がります。SSH だけの運用では バックグラウンド用の専用ユーザ と 再起動後の自動ログイン（限定的・ポリシー順守） の設計が絡みます。混ぜると PATH や Keychain の参照先がズレ、移行直後だけ失敗するタイプの不具合になります。

症状早見：launchctl kickstart -k gui/$(id -u)/label で直るなら依存順かゾンビ。直らず exit 78 なら plist の環境変数かワーキングディレクトリ。ヘッドレスでは Console.app が使えないので log show --predicate を Runbook に固定してください。

5. Skills／プラグインデータディレクトリ

Skill は「コード」よりキャッシュと索引が状態を持ちます。プラグインはバージョンアップでスキーマが変わることがあるため、バージョンごとのサブディレクトリに寄せるか、マイグレーション手順を Skill README に明記します。

移行時のコピーは rsync -aHAX 相当の属性保持が安全です。大容量キャッシュは DR では捨て、再生成コストと RTO のトレードオフをマトリクスに書いておくと現場の判断が速くなります。

6. 意思決定マトリクス（要約）

軸	計画ノード交換向き	DR 向き
状態の持ち方	差分同期・ブルー／グリーンで並走検証	コールドバックアップ＋最小ブートストラップ、キャッシュは捨てる選択肢あり
トークン	同一トークンを短時間だけ二ノードに載せないルール徹底	スタンバイ用に別トークンプール、切替時に一括スワップ
RTO／RPO	低ダウンタイム優先、事前検証を厚く	数分〜数十分の停止許容なら手順を単純化できる

7. FAQ

Q1：新旧を短時間だけ並走させてもよいか？

同一インバウンド接続や Webhook エンドポイントに二重のゲートウェイがぶら下がると、重複配信・承認キューの分裂が起きやすいです。どうしても並走するなら、インバウンドを論理分割するか、片方を読み取り専用モードに落とすなど、チームで意味のある分離を入れてください。

Q2：plist だけ Git 管理で足りるか？

足りることもありますが、環境ごとの差分（バインドポート、ログパス、Feature Flag）を .local.plist オーバレイやテンプレ＋レンダリングにすると、DR 時のコピペミスが減ります。

Q3：Skills データを丸ごと rsync しない方がよいケースは？

機微がディスクに残る設定や、旧バージョンの索引が新バイナリと不整合を起こすケースです。その場合は「コードと設定だけ移し、キャッシュはウォームアップ手順で再生成」とマトリクスに明記します。

常時ノードを張るなら、金属と OS の一体設計が効く

ノード交換と DR は、最終的に同じ手順を何度でも無人で回せるかが勝負です。Apple Silicon の Mac mini はアイドル電力が低く、リスナー常駐の電費と発熱を抑えやすい一方、macOS は Unix ツールチェーンと launchd の挙動が文書化され、SSH 越しの運用実績が積み上がっています。Gatekeeper・SIP・FileVault による境界も、自作 Linux イメージの長期メンテと比べて説明コストが低い場面が多いです。

OpenClaw の Gateway・Skills・プラグインを「静かな箱の上」に固定したいチームにとって、Mac mini M4 は依然として現実的なデフォルトです。今こそ金属を揃え、切り替え Runbook を本番相当の負荷で焼き直すなら、今すぐ Mac mini M4 を手元に置き、ヘッドレス検証を同じ土台で回し始めるのが近道になります。