ハードウェアの入れ替え、クラウドリージョンの移動、災害訓練はすべて同じ OpenClaw ワークスペースに触れます。マークダウンのペルソナ、ツールマニフェスト、モデルキャッシュ、launchd のパスは一貫したままにする必要があります。ホームディレクトリごとコピーすると、古いシークレットに加え、不要な 120 GB 近いキャッシュまで運んでしまいがちです。本2026年ガイドでは除外ルール、SHA-256 による検証、順序付き7ステップ、移行前後のチェック表、大容量転送の帯域計算、DNS 切り替えの注意、ロールバックのタイムボックス、移行後にゲートウェイがループする場合の FAQ 的トラブルシュートを定義します。
デーモンの健全性は ヘッドレスオンボード受け入れ基準 でベースライン化し、シークレットは Keychain と .env、アップグレードは 運用ランブック に沿ってください。移行の途中で TCC のダイアログをクリックする必要があるときは VNC を使います。
tar の前に解決すべき3つのパス依存
- ワークスペースのルート： plist に
WorkingDirectoryがハードコードされている場合、移行先のユーザーまたは plist が一致する必要があります。ファイルだけコピーして終わり、が最頻の失敗パターンです。 - キャッシュ： モデルや npm のキャッシュは 30〜120 GB を食うことがあり、帯域と時間の余裕がなければ除外します。
- バインドアドレス： 特定の en0 IP にゲートウェイをバインドすると、DHCP 変更後にヘルスチェックが壊れます。トラフィックを切り替える前に意図したバインドモードを文書化してください。
変更チケットに許容できるドリフトを書き入れましょう。例えばキャッシュのウォーム中は初回応答レイテンシがベースラインより 20% 悪化してもよいが、ツール呼び出しの失敗率は動かしてはならない、とします。数値で受け入れ基準を決めると、深夜2時の「なんとなく大丈夫」論争を避けられます。
アーカイブ除外の指針
| パスパターン | 含める？ | メモ |
|---|---|---|
| SOUL.md, TOOLS.md, AGENTS.md | 必須 | 多くの場合 5 MB 未満 |
| **/node_modules | 通常は除外 | 再現性のため npm ci で再インストール |
| モデル重みキャッシュ | 方針次第 | 狭い上り回線ならカット後 15 分のウォームアップを許容する選択も |
大容量転送と再開可能な同期
50 GB を超える場合は rsync --partial やマルチパートオブジェクトアップロードを優先し、両側でチェックサムを取ります。対称 100 Mbps なら理論上 80 GB は約 110 分ですが、実 WAN はしばしば倍近くかかるので、最悪ケースの時間窓を関係者に伝えてください。平文のまま汎用バケットへ機密 tarball を流さない。中間にプロバイダのオブジェクトストアがあるなら顧客 KMS で包みます。
7ステップの移行シーケンス
- 読み取り専用スナップショット： ゲートウェイを止めるかメンテナンスラベルを付け、コピー中に
MEMORY.mdが変わらないようにする。 - アーカイブとハッシュ： SHA-256 をチケット本文に残す。チャットだけにしない。
- 転送： プライベートネットワークを優先し、一時ストレージの ACL を絞る。
- 最終パスへ展開： サービスユーザーに所有権を合わせる。
- 依存関係のインストール： Node のマイナーを固定しロックファイルを尊重する。黙ってメジャーが上がると「OpenClaw が壊れた」に見える。
- LaunchAgent の整合：
ProgramArgumentsとEnvironmentVariablesを確認する。 - 二重受け入れ： 連続3回のヘルスチェックに加え、最小限のツール呼び出しを1回。
移行前後のチェック表
| 確認項目 | 移行前ベースライン | 移行後の期待 |
|---|---|---|
| openclaw semver | 記録した3桁 | 一致、または doctor 出力付きで意図的アップグレードと文書化 |
| API キー指紋 | 末尾 6 桁の16進 | キーを同時ローテーションしない限り一致 |
| 待ち受けポート | lsof の記録 |
一致、またはセキュリティグループの文書を更新 |
ロールバックのタイムボックス： 二重受け入れが 45 分以内に通らない場合は、デュアルライトではなく旧ゲートウェイを読み取り専用に戻すのがデフォルトです。スプリットブレインと二重課金は、並行パスがぐちゃぐちゃになると続きます。コンプライアンスで長期保管が要らない限り、読み取り専用のレガシーを 72 時間より長く残さない。
カットオーバー後の FAQ 的トラブルシュート
キャッシュなしで設定だけ移行してよいか
はい。むしろ推奨されることが多いです。マークダウンとロックファイルだけの軽量バンドルを運び、移行先で依存関係を入れ直し、キャッシュが再構築される間は初回応答が 2〜4 倍遅くなることを受け入れます。低レイテンシ SLA なら、メインアーカイブと同じチェックサム規律でキャッシュディレクトリを増分 rsync してください。
ゲートウェイが再起動を繰り返す
plist の環境変数に、コピペで紛れ込んだ空白がないか比較してください。ホスト間で Node の絶対パスが違うことも検証します。一時的にバイナリをフォアグラウンドで動かし、最後の 200 行の stderr をキャプチャしてチケットに貼る。未来の自分が感謝する紙の跡になります。
ステージングは本番のディスクレイアウトを鏡像すべきか
はい。非本番の Mac mini で四半期ごとに同じパス・ユーザー名・plist の位置でリハーサルしてください。ノートPC だけで移行練習をしているチームは、マーケローンチ前の金曜夜にパスのサプライズを踏みます。ステージングのドリルは、役員エスカレーションよりはるかに安いです。
DNS、イングレス、マルチゲートウェイの注意
まだ旧インスタンスを指しているインバウンド経路を凍結してください。Slack のイベント購読や IP 許可リストが、休止したと思っていたホストにトラフィックを届け続けます。移動中は DNS の TTL をおおよそ 60 秒に下げてロールバックを速くし、24 時間安定したら長めの TTL に戻してリゾルバの負荷を下げます。
1ページの移行差分を公開しましょう。アーカイブのバイト数、除外リスト、新旧ポート、doctor 出力の差分。検索可能なドキュメントは、3か月後に「なぜ node_modules を除外したのか」と聞かれたときの Slack スクロールより役立ちます。
自動化のフック：スクリプト化するタイミングと手作業のままにするタイミング
初回の移行は慎重な手動チェックポイントが効きます。変な plist のクォートや想定外のファイルモードは人間が拾いやすいです。同じ除外リストで2回成功したら、tar・ハッシュ・rsync を OpenClaw のバージョンでタグ付けしたバージョン管理スクリプトにまとめましょう。チェックサム比較を自動化で飛ばさない。安い Wi-Fi でビットが反転し、アーカイブが壊れた事例は想像以上にあります。部分失敗後の再実行でディレクトリが二重にならないよう、スクリプトは冪等に保ちます。
移行イベントをカレンダーと連携し、初回応答 SLO が広がる可能性があるときは下流チームに通知し、ロールバック用コマンド断片をカレンダー説明に貼っておきます。半年後にメールを検索するオペレーターは、消えゆくチャットより早く文脈を見つけられます。
レイテンシ、データ所在地、コンプライアンス
香港から東京へ移すと RTT が 25 ms から 55 ms へ変わり、ツールにハードコードされたタイムアウトが表面化します。ログには会話に含まれる個人情報が残ることがあるため、転送中はアーカイブを暗号化し、ROPA に処理を登録してください。NodeMac の香港・日本・韓国・シンガポール・米国リージョンなら、データの隣にゲートウェイを置き、アプリケーションコードを書き換えずに済みます。
Mac mini M4 のユニファイドメモリとキャッシュ帯域は、移行後の依存関係の再構築を速くし、ネイティブ macOS ならコンテナのパス驚きも避けられます。NodeMac で専用ホストをレンタルすれば、旧ホストから新ホストまで SSH／VNC のワークフローは同じままです。ハード移動を一度きりのヒーロー劇ではなく、繰り返し可能なオペレーションにできます。ベアメタルの予測可能性は、インシデントが設定ドリフトなのか上流モデルの振る舞いなのかを議論するとき、移行前後の表の比較を信頼できる材料にします。成功した移行は再利用できるテンプレートとして残し、武勇伝で終わらせないでください。