最小バックアップ集合 · 秘匿化エクスポート · Gateway コールドスタート · チャネル全再接続
想定読者と症状：OpenClaw を本番または準本番で運用している一方で、「ホスト換装、設定誤削除、鍵ローテーション後」に再現可能な復旧手順がまだ紙面上にありません。Gateway は起動するのに Slack、Discord、Telegram などのチャネルがまとめてオフラインになる、あるいは失敗がログに埋もれて見えにくい、という症状が典型です。本稿の結論：最小バックアップ集合、秘匿化エクスポート、コールドスタートの確認順、チャネル一対一の対照表を揃えることで、RTO と RPO をスローガンではなくチケットの入力欄に落とし込みます。持ち帰れる成果：五類の災害リスク、バックアップ要否の対照表、秘匿化六手順、コールドスタート六手順、IM 側と Gateway 側の最小フィールド行列、四半期演習の記録テンプレートです。持続可能アップグレードとバックアップ固定、三チャネル接続と切り分け、ランタイム障害切り分け、本番強化チェックリスト、マルチプラットフォームインストールとデーモンと相互に参照できます。
アップグレードとロールバックの文書が扱うのは版とポートの衝突です。災害対策が扱うのは身元と外部システムとの関係が失われる事象です。リポジトリだけを退避し Gateway とワークスペース境界を退避しないと、復旧後に「モデル呼び出しは成功するがメッセージが届かない」という形に現れます。逆に完全なログと秘密をそのまま共有ストレージへ複製すると、コンプライアンスと監査の両面で負債になります。持続可能アップグレードとバックアップ固定と併読する場合は、アップグレード前バックアップを高頻度の小さな集合、災害演習を低頻度の全体集合として切り分けると運用が安定します。前者は日常変更の安全網、後者はホスト全損の仮定に耐える設計レビューです。
第二のリスクはパスドリフトです。復旧先の Home パス、デーモンのラベル、旧ホスト名が一致しないと、設定ファイルは見つかるのにサービスが起動時に束縛されません。第三はチャネル秘密とコールバック URL のペア崩壊です。IM 側のトークンは有効でも、公開入口や TLS 証明書が変わると Gateway ログにはコールバック失敗が密集し、誤ってモデル側のクォータ切れと判断されがちです。第四は二重インストールと PATH 汚染で、コールドスタート時に旧バイナリが起動し新設定を読み込む半互換状態になります。第五は演習を実際に走らせていないことです。Runbook が文書庫にだけ存在し、換装当日にテンプレ項目と責任者の時間帯が欠けていると、復旧は個人の記憶頼みに退化します。
運用チームが四半期に一度でも机上で手順をなぞるだけなら、証跡は残りますが RPO の仮説は検証されません。実機演習ではスナップショット名、復元手順、検証コマンドの出力保存先をチケットに固定し、当番交代でも同じ順序で再実行できるようにします。監査観点では「誰がいつどの範囲を復元したか」を索引化し、後追いで時間短縮できることが重要です。
Git のみを退避し Gateway 境界を退避しない：復旧後に「ビルドは通るが受信できない」状態になり、三チャネル切り分けの症状に似ますが根本原因は設定面の欠落です。
秘密を平文でチケットへ貼る：最小露出の原則に反し、監査で不合格になります。
アクセスログを無差別に複製する：容量とプライバシーの両方で爆発します。保持窓とフィールドのホワイトリストを先に定義します。
デーモン名と launchd もしくは systemd ユニットを無視する：プロセスは存在するのにヘルスチェックだけ失敗する、という形に陥ります。
演習後にスナップショットへ戻さない：RPO が本当に成立したか検証できません。
| 対象 | 災害パッケージの推奨 | 理由の要約 |
|---|---|---|
| Gateway 設定と版の固定 | 要 | 待受面、ルーティング、チャネル束縛を決めます。アップグレード文書の項目名と揃えます。 |
| 長期 API 鍵と bot トークン | 要（暗号保管） | 復旧後に身元を証明するために必要です。平文添付は禁止です。 |
| ワークスペースと AgentSkills パス | 要（構造とハッシュ） | 本番強化のスキル監査フィールドと整合させます。 |
| 全量アクセスログ | 既定では不要 | サンプリング窓と秘匿化ルールを先に決めます。 |
| 一時ダウンロード領域 | 不要 | 再生成可能です。持ち出すほど漏えい面が広がります。 |
災害パッケージの目的は「PC 全体の複製」ではなく、「クリーンな機体で同じ外部契約を再構築すること」です。
秘匿化は見た目のマスキングではなく、当番が露出面を広げずに再現へ近づけるための設計です。ランタイム障害切り分けの最小再現パックと同様に、版、チャネル種別、エラーコード断片、タイムラインは復元に寄与しますが、完全な webhook 秘密やユーザー私信の全文は復元に不要です。以下の六手順はエクスポート前の自己点検順として有効で、変更管理の必須項目に落とし込むことを推奨します。運用では「誰が承認し、いつ破棄するか」を別フィールドに分け、共有リンクの有効期限とセットで管理します。
エクスポートの単位はチケット単位よりも「インシデント単位」に寄せると後追いが容易です。同一インシデントに複数の試行ログが付く場合、最新版だけでなく失敗した版の差分も短い範囲で残すと、ロールバック判断が速くなります。フィールド名はチーム内で固定し、ツールが変わっても列名を変えない方針にすると、ダッシュボード連携が壊れにくいです。
版の四つ組を固定する：CLI の版、Gateway のビルド識別子、Node ランタイム、OS のパッチレベルです。
チャネルを列挙する：有効化済みチャネルとそれぞれの「最後に成功したコールバック」の時刻を載せ、トークン本体は載せません。
設定構造の要約を作る：ツリー状のパスで主要ファイルの存在を示し、敏感な値はプレースホルダに置き換えます。
エラー断片を添付する：直近 N 件のうちチャネルまたは TLS に関係する行だけを切り出し、固定バイト上限で切り詰めます。
ネットワーク判定を添える：出口 IP、証明書フィンガープリント、リバースプロキシのルール版（該当する場合）です。
責任者と時間帯を明記する：誰がこのエクスポートを承認し、いつ破棄するかを書きます。
禁止事項：Slack の signing secret、Discord の bot token、Telegram の bot token を平文で共有ドライブや IM に貼らないでください。暗号保管庫またはプラットフォーム側のローテーション手順に置き換えます。
コールドスタートの順序は意図的にマルチプラットフォームインストールとデーモンと揃えます。まず「待受している Gateway が一つだけか」を確認し、その後でチャネルへ進みます。各手順には合格と不合格の判定基準を置き、不合格のときにいきなり再インストールへ飛ばさず、証跡表に戻って PATH、ユニットファイル、ポート占有のどれが原因かを切り分けます。演習ではコマンド出力をスクリーンショットではなくテキスト添付に寄せ、検索可能な形でチケットに残すと再発分析が速くなります。
VPN や企業プロキシが常時有効な環境では、復旧直後だけルーティングが変わりコールバック経路が分断されることがあります。その場合は Gateway のローカル検査は成功しても外部からの到達だけが失敗するため、内側と外側の両方で traceroute や証明書チェックを短く走らせ、どの段で止まるかを一行で要約してチケットへ書きます。
インストール面が単一か確認する：which とパッケージマネージャのグローバルパスを突き合わせ、二重インストールを排除します。
デーモンを起動しユニット名を記録する：インストール文書の launchd もしくは systemd ラベルと一致させます。
束縛面を確認する：待受アドレスが意図したインタフェースか、VPN やファイアウォールで書き換わっていないかを見ます。
ヘルスと doctor 系コマンドを実行する：出力はチケットの索引フィールドへ集約し、散在する画像にしません。
最小チャネルプローブを先に走らせる：全チャネル同時再接続は変数が多すぎるため避けます。
時刻同期と TLS チェーンを確認する：時刻ずれと中間証明書期限切れはコールドスタートで高頻度に出ます。
export OC_EXPORT_DIR="./openclaw-drill-$(date -u +%Y%m%d%H%M%SZ)"
mkdir -p "${OC_EXPORT_DIR}/redacted"
openclaw version > "${OC_EXPORT_DIR}/version.txt" 2>&1
openclaw gateway status > "${OC_EXPORT_DIR}/gateway-status.txt" 2>&1 || true
openclaw channels status > "${OC_EXPORT_DIR}/channels-status.txt" 2>&1 || true
tar -czf "openclaw-drill-bundle.tgz" "${OC_EXPORT_DIR}"
注：例示コマンドは状態テキストの収集に留まります。貴社環境では安全レビュー済みのエクスポートスクリプトへ置き換え、tar の権限を制限してください。
復旧後に「Gateway は健康だが返信が返らない」場合、多くはコールバック到達性か権限スコープの変更に落ち、モデルルーティングとは独立します。下表は切り分け時に照合すべき最小フィールド集合です。手順の細部は三チャネル接続と切り分けへ戻り、コールバック TLS を確認する前にモデル鍵を繰り返しローテーションしないでください。運用チームが複数リージョンに跨る場合は、DNS の伝播遅延と CDN のキャッシュも一行でメモし、切り分け順序の前提に含めます。
チャネルごとの失敗は単一の設定キーでは説明できないことが多く、IM 側のイベント購読 URL と Gateway 側のルート定義を同じ画面で並べると誤認が減ります。演習ではテスト用ワークスペースを切り、本番トラフィックとは別の bot で検証すると影響範囲を抑えられます。
| チャネル | IM 側で必ず見る項目 | Gateway 側で必ず見る項目 |
|---|---|---|
| Slack | アプリ権限、イベント購読 URL、署名鍵の版 | コールバックルート、TLS 証明書チェーン、出站 allowlist |
| Discord | Intent、bot の可視範囲、ゲートウェイ URL | WebSocket アップグレード経路、リバースプロキシのタイムアウト |
| Telegram | Webhook モードと証明書アップロード、許可 IP | 公開入口ポート、NAT セッション保持 |
チームが多モデルの段階運用と主備ルーティングを併用する場合は、チャネル復旧の後でモデルを切り替えます。そうしないとチャネル障害をクォータ切れと誤認しやすく、対応が長引きます。該当フィールドは多モデル分岐とフェイルオーバーに沿って整理します。全再接続が完了したら「テストメッセージ受信から初回ツール呼び出し成功まで」のタイムスタンプを一度残し、四半期演習の基準線にします。
次の三つは演習の添付資料に書ける経験閾値で、計画前の突き合わせに使えます。貴社の実測へ置き換えてください。RTO は災害宣言から「最初のチャネルがテストメッセージを受信するまで」の時間です。RPO は失ってよい設定変更の窓であり、構成管理ツールの履歴粒度と整合させます。
| 組織規模 | コンプライアンス要求 | 演習頻度 | 第一選択 |
|---|---|---|---|
| 個人開発者 | 標準 | 半年に一度 | 暗号化バックアップパッケージと単機コールドスタートスクリプト |
| 小規模チーム | 標準 | 四半期 | 二人レビューとチャネルプローブ一覧とチケットテンプレ |
| プラットフォームチーム | 高 | 毎月の机上、四半期の実機 | パーティション分割された鍵保管庫と自動エクスポートと監査索引 |
純粋なローカルノート PC はディスク、スリープ、OS 更新の窓により安定した RTO を満たしにくい一方、自前サーバでは TLS、バックアップ、チャネルコールバックをすべてチームで背負います。比較すると、契約条項として書けるクラウド上の Mac ノードは可用性とリージョン選択を調達資料へ落とし込みやすく、Gateway 常駐を「個人端末の運」から「サービスレベルの議論」へ移せます。
よくある誤解：演習で「プロセスが起動する」だけを見て「外部からのメッセージが届く」を見ないことです。外部契約こそが OpenClaw の本番価値です。
チームが OpenClaw の災害対策と監査可能なチャネル復旧の両方を求める場合、個人端末と一時借りの機体では鍵ローテーションと公開入口の安定性に継続的な不足が出ます。本番級の Gateway 常駐と再現可能な演習を前提にするなら、VpsMesh の Mac Mini クラウドレンタルは多くの場合により現実的な解です。周期課金で弾力的に確保でき、リージョンも選べ、専用ノードとして監査に耐える形に寄せられます。災害対策の議論を実ネットワークと可用性データの上に載せ替えられます。
アップグレード文書は版チャネルとポート衝突を扱います。災害対策文書はホスト全損と鍵関係喪失後の復元を扱います。持続可能アップグレード長文と併読してください。仕様と手配は注文ページも参照します。
版の四つ組、チャネル列挙、設定パス要約、エラー断片とタイムラインです。長期鍵の平文は含めません。料金比較は価格ページを開きます。