1. 痛みの分解：リポジトリをコピーしただけでは実行時は動かない
（1）状態と workspace：スキルや openclaw.json を git で管理しつつ、セッションやチャネル紐付け、Gateway キャッシュはユーザープロファイル配下に残る。git だけ移すと CLI は動くが、チャネル側は幽霊セッションか空状態になる。（2）秘密と OAuth リフレッシュ：Slack／Discord／企業 IM は平文設定と暗号化ストアの両方にトークンを置くことがある。片方だけバックアップすると再認可が必要になり、旧 Gateway を止めずに新側を立ち上げると同一 bot セッションを奪い合う。（3）launchd と対話シェル：.zshrc の export は launchd に継承されない。API キーを端末だけに書き plist が空だと「手動前景は成功、デーモンは環境欠落」になる。（4）リモート Mac のユーザー境界：Screen Sharing や SSH のユーザーと Gateway 実行ユーザーは一致させる。root とログインユーザーを混ぜると所有権と Keychain が分岐し、調査時間が跳ね上がる。
2. コールド移行バンドルに含めるもの（2026）
| 対象 | 典型パス | 含める？ |
|---|---|---|
| ユーザ状態ツリー | ~/.openclaw（サブツリー名はリリースで変わり得る） | はい：チャネル紐付け・キャッシュ・ローカル秘密 |
| ワークスペース | スキル、スクリプト、バージョン管理された openclaw.json | はい：状態と同一時刻のスナップショットで揃える |
| launchd | ~/Library/LaunchAgents/ の Gateway 用 plist | はい：実行ユーザー・カレント・環境変数名 |
| Docker ボリューム | compose の名前付きボリューム／バインド | 条件付き：Docker 本番のレイアウトと一致するときにまとめてスナップショット |
| Keychain | 一部チャネルがリフレッシュを钥匙串に保存 | 慎重：ベンダー公式の再認可を優先し、コンプラに反する無秩序なエクスポートは避ける |
3. 五ステップ：凍結→パック→検証→冷起動→再ペア
ステップ1 書き込み凍結：旧機で Gateway と launchd（または compose）を止め、SQLite やロックを触るバックグラウンドセッションを無くす。cron や CI webhook でエージェントを叩くジョブも一時停止し、止めた直後に状態ファイルを開き直す経路が残っていないか確認する。複数 compose プロジェクトがある場合は依存順に停止し、docker ps で床が空である証跡を残す。
ステップ2 ペアスナップショット：~/.openclaw と workspace・lockfile を同一時刻で固め、Docker ならボリューム digest も揃える。実パス解決後にアーカイブする。
ステップ3 検証とスクラブ：チェックサム確認のうえ旧ホスト名・絶対パス・内 URL を置換。リモート移行時は DNS／VPN を再確認する。
ステップ4 冷起動 Gateway：最小表面で openclaw doctor を通し、plist とログ権限を一致させてからチャネルを有効化する。
ステップ5 チャネル再ペア：OAuth／webhook を公式手順で行い、旧 bot を止めてから新 bot を有効化。送受信プローブをスクリプト化しておく。
数値・閾値（引用可）
① 三点セット：~/.openclaw＋workspace＋plist（または compose＋ボリューム一覧）。欠けると不完全移行。
② 環境：plist の EnvironmentVariables とシェルで頼っている変数を明示的に一致。最低でも API・プロキシ・タイムゾーン系。
③ カットオーバー：旧 bot 停止と新 bot 起動の間に冷却ウィンドウ。ベンダー無言時は分単位のグレーリリース想定。
④ リモート Mac：SSH ユーザー＝Gateway ユーザー。Screen Sharing と無人 launchd で UID を混ぜない。
⑤ ロールバック：旧ホストの読み取り専用アーカイブを少なくとも一リリース周期保持。
4. プロセスは生きているのにチャネルが沈黙する理由
移行直後に多いのはヘルスプローブは通るがメッセージが届かないパターンである。第一に bind アドレス：127.0.0.1 から LAN IP に変えたのにリバプロや FW を更新していない。第二に webhook URL：クラウドコンソールのコールバックが旧トンネル名のまま。第三に時刻と TLS：NTP ズレや企業 MITM の置換証明書で TLS が静かに失敗。第四に tools.profile：旧ホストの絶対パス許可が新 PATH と合わない — sessions_spawn ランブックで allowlist を見直す。
それでも沈黙する場合、ベンダチケットを切る前に四点を揃える：マスクした plist、実際に叩かれる公開 URL、TLS ハンドシェイクが完了するかのトレース、1 イベント分の Gateway ログ。これで「HTTP が届いていない」のか「署名拒否」なのかを切り分けられる。ダッシュボードのフィールド名と設定キーの対応表も短く残し、同義語だらけのオンボード資料で迷子にならないようにする。
5. 判断：ノートに留めるかリモート Mac Gateway か
| 軸 | ローカルノート | 専用リモート Mac |
|---|---|---|
| 可用性 | フタ・スリープ・出張の影響大 | チャネル負荷向けに 7×24 の境界が明瞭 |
| 権限 | GUI デバッグは容易 | ヘッドレス規律が要る — ブロッキングプロンプトを避ける |
| ネットワーク | 住宅回線の IP 変動 | 固定 egress やトンネル名で webhook が安定しやすい |
| コスト | 減価償却が見えにくい | レンタルは透明で SLA 志向チームに合う |
6. FAQ
Q：workspace だけ同期してよい？ 純 CLI 実験なら可だが、チャネルやセッション連続性があるなら非推奨。 tarball より調査時間の方が高くつく。Q：Docker からベアメタルへ？ スタック変更＋移行の二重リスク。形態を一つに決めて文書化する。Q：plist に平文 API キー？ 動くが衛生上よくない。plist が参照する権限制限 env ファイルやマネージド秘密が望ましい。Q：リモート Mac で画面共有は？ 日常は SSH。初回 OAuth や GUI 専用ツールのときだけ VNC を短時間開き、変更票に残す。Q：旧ノートをすぐ消去？ 少なくとも一ビジネス周期は並行観測してから破壊的消去。
Q：移行と同じ変更枠で OpenClaw を上げる？ まず同版で移行だけ成功させ、チャネル検収後に別チケットでアップグレードとロールバック経路を切る。二つを混ぜると原因の次元が増える。Q：MDM 管理 Mac は？ plist・ヘルパ・ネットワーク拡張が署名付きで許可されているかデバイス管理と握る。Gateway は起動してもエンタイトルメント不足でネットワークだけ失敗することがある。Q：多地域チーム？ トークンとログの法的管轄を文書化し、レビューなしに状態を跨ぐとデータレジデンシーに抵触し得る。
7. 深掘り：移行は状態とアイデンティティの同時移動
問われるのは「インストールできるか」より状態の読み書きと外部 ID の写像である。openclaw.json は意図、プロファイルツリーは資格情報。両方を揃えないと doctor は緑でもチャネルは黙る。
launchd とシェルの分裂に注意：.zshrc だけにキーを書くとデーモンは 401。plist・シェル・CI の変数名を一枚の表で突き合わせる。
再ペアは単一エンドポイントを守る儀式。旧インスタンス退役を先に。ベンダごとに冷却と IP 許可の意味が違う。
レンタルリモート Mac では対話 GUIと無人サービスを分離する。MACGPU のようなノードは Gateway 級負荷を予測可能トポロジに載せ、ノートは創作に戻す。観測性としてログを Mac の外へ出し、移行後の沈黙はまずネットとアイデンティティを疑う。移行はトークン・URL・証明書が新環境で揃うことへの信頼の回復でもある。
8. 締め：速さと省ステップは両立しない
（1）限界：メジャーで状態レイアウトが変わることがある — アーカイブにセマンバーを添付。Keychain の丸ごと複製はコンプラで禁止されることもあり、再認可の枠を確保する。（2）リモート Mac が勝つ理由：ユーザー・出口・ハードクラスが固定され「ノートをサーバにする」長尾事故が減る。（3）MACGPU：トポロジ固定前にレンタル Apple Silicon で Gateway 常駐をリハーサルしたい場合は公開プランとヘルプ入口から。毎回の移行を次の移行のリハーサルとして記録し、runbook を厚くするほど複利で効く。