イメージをロールバックしたあと、Gateway トークンの再ペアリングは必須ですか。

必ずしも必要ではありません。データボリュームが無事で設定の契約が互換であれば、既存のトークンを維持できることが多いです。1006/1008 や TOKEN の二重注入アラートが残る場合は、固定したビルド向けのペアリング手順に従ってください。

リリースチャネル固定の記事との違いは何ですか。

2026-05-13 の記事は stable/beta/dev の戦略と日々の固定マトリクスを扱います。本記事はインシデント発生後のロールバック順序、読み取り専用ボリューム監査、不良リリース後の数分単位の受け入れ検証を扱います。症状の重複を避けるため、相互リンクで意図を分けてください。

2026 OpenClaw 不良リリースを数分でロールバック：ダイジェスト固定、Compose/npm の二系統と読み取り専用ボリューム監査

OpenClaw をアップグレードした直後に、Gateway の挙動がおかしい、CLI とコンテナの版が食い違う、コミュニティで退行の時間帯が指摘されているといった状況になった場合、本記事では次の三点を整理します。すぐにロールバックすべきか、Docker 系と npm 系それぞれでダイジェストをどう固定し版を揃えるか、そして 読み取り専用のボリューム確認と検証ラダーで、既知の良好状態に戻れたことをどう証明するかです。リリースチャネル固定マトリクス（戦略とインシデント運用の役割分担）を補完し、専用リモート Mac への SSH ローカル転送およびアップグレードと移行のチェックリストとあわせて読むことを想定しています。

ロールバック前に切り分けるべき「不良リリースのような」誤検知六パターン

スプリットブレイン型アップグレード：ホストの openclaw バイナリだけが新しく、コンテナ Gateway が古い（またはその逆）。サブコマンド欠如や未知フラグが出て、WebSocket 1006 のノイズと取り違えやすくなります。
ボリューム権限やマウントのずれ：アップグレード手順が新しい UID/GID 前提なのに compose が追従していない。「新ビルドが古い状態を読めない」ように見えて、実際はファイルシステム契約の破綻である場合があります。
設定ツリーの重複：.openclaw がバインドマウントと匿名ボリュームの両方に存在する。イメージだけ戻しても空ツリーを読み続け、ロールバックが効いていないように見えます。
プロキシ、TLS インターセプト、企業 MITM：アップグレードで新しい取得パスに触れ TLS が失敗し、上流のビルド不良と誤認されがちです。
リソース上限：アップグレード後のデフォルトでサンドボックスや同時セッションが重くなり、メモリの小さいホストでは OOM により Gateway が不安定に見えますが、ビット自体は問題ないこともあります。
文書化された破壊的変更：リリースノートに新挙動が書かれているのに、自動化が旧フラグを呼び続けている。これは移行タスクであり、ダイジェストのロールバック対象ではありません。

インシデントでのロールバックは、まず症状を 版の真実トリプル に写像します。すなわち CLI のセマバーまたはビルド ID、イメージダイジェスト（または監査可能な別参照）、設定ディレクトリの inode とマウント関係です。このスナップショットなしに戻すのは、イメージだけ古くして別ボリュームや別 TOKEN 注入層を読むランダムなダウングレードに近づきます。本稿はグリーンフィールドの導入や doctor の症状カタログ全文は繰り返さず、ロールバック後の受け入れに効くプローブに絞ります。

Gateway が スリープしやすいノート PC やデスクトップ拘束セッション上にある場合、電源ポリシー、VPN の瞬断、ディスク逼迫が「アップグレード後の不安定」として現れ、ロールバックの時間予算を浪費します。ダイジェスト A から B、再び A へとチケットに明記できる監査可能な記録が必要なら、権威ある Gateway を 常時稼働の専用リモート Mac に置き、ノート側は CLI のみにする構成の方が、多くのチームで総コストが有利です。セクション四では、そのままオンコール手帳に貼れる KPI 形式の閾値を三つ示します。

観点	まだ切り分け（ロールバック延期）	今すぐロールバック（まずサービス復旧）
影響範囲	本番と隔離された TOKEN とボリュームを持つ非本番サンドボックス	本番トラフィックで静かな失敗、ジョブ落ち、セキュリティアラートが出ている、またはコミュニティが退行範囲を確認した
証跡チェーン	真実トリプルを取得済みで doctor が具体的な設定ノブを指している	スナップショットが欠落している、またはトリプルがすでに不整合で、設定をいじるほど影響が広がる
Docker 側のレバー	一サービスに対する `docker compose logs` を絞り、公式の破壊的変更メモと突き合わせる	`OPENCLAW_IMAGE` を最後の良好なダイジェストに向ける。`pull` のあと `up -d`。続けて読み取り専用ボリューム確認を行う
npm 側のレバー	Node のメジャー基準線と単一のグローバル PATH を確認する	直前のグローバル版を公式手順どおり再インストールし、Gateway デーモンを再起動し、トラフィックを戻す前に最小プローブを行う
リモート常駐	専用ホスト上で別ボリューム名とポートを使いシャドウダイジェストを走らせてよい	本番とシャドウのボリューム名を必ず分離し、ロールバックが実験データを消さないようにする

リリースチャネル固定の記事との組み合わせ方

2026-05-13 の固定マトリクスは、どの stable/beta/dev のレールに乗るかと いつ先回りでダイジェストを固定するかを扱います。本記事は、すでにビルドが悪いと判断したあとに何をするか、すなわちロールバックと検証と監査証跡を数分に圧縮し、読み取り専用のボリューム監査で「イメージだけ戻したのに状態はずれている」を防ぐことです。ペアリング、1006/1008、TOKEN の二重ソースで行き詰まる場合はペアリングとトークン競合の Runbook へ移り、本稿ではロールバック後にペアリングをやり直す必要があるかの 判断閾値 にとどめます。

Docker 本番系ではログ保持、cgroup 上限、18789 などの露出方針を Docker 本番 Runbook の隣に置かないと、「ダイジェストは固定したが、その夜の compose の SHA が誰にも分からない」状態になります。下の bash は フィールドの型 を列挙したスケッチです。サービス名、ボリューム名、レジストリは自環境の値に置き換え、サブコマンドは固定したビルドの公式ドキュメントに合わせてください。

warning

注意：コミュニティの「不良マイナーリリース」談義は時間依存です。本稿は特定のセマバーをハードコードしません。実行前にチケットへ 目標ダイジェストまたはタグ、compose の git SHA、実験用ボリュームの削除可否 を必ず記載してください。

六段階「ダイジェスト固定からロールバック、受け入れまで」の Runbook

証跡の凍結：openclaw --version、イメージの RepoDigests、トリムした docker compose config、状態ツリーの読み取り専用ディレクトリ一覧をエクスポートします（bash スケッチ参照）。
単一レールの選択：一つの変更チケットでは Docker か npm のどちらか一方を触ることを優先します。両方動かす必要がある場合は Gateway に近い側から戻し、すぐ再検証します。
Docker でのロールバック：OPENCLAW_IMAGE を ghcr.io/.../...@sha256:<known-good> に設定し、docker compose pull のあと docker compose up -d を実行します。pull だけで up を省略しないでください。
読み取り専用ボリューム監査：コンテナ内でマウントポイントに ls -la し、重要ファイルの存在を確認します。空のホストディレクトリに誤バインドしていないかを見ます。
npm でのロールバック：上流ドキュメントに従い直前のグローバル版を再インストールし、Node 基準を再確認し、Gateway を包む launchd や systemd 相当のユニットを再起動します。
検証ラダー：gateway status 相当から始め、18789 の Control UI に到達できること、非破壊の最小プローブ、openclaw doctor の順に進みます。いずれかで失敗したらトラフィックを戻さずログを保全します。

bash

# Evidence snapshot (rename fields to your environment)
openclaw --version 2>/dev/null || true
docker compose config | sed -n '1,160p'
docker image inspect "${IMAGE_REF}" --format '{{json .RepoDigests}}' 2>/dev/null || true

# Read-only volume sweep (replace container and mount path)
# docker exec -it <gw_container> sh -lc 'ls -la /path/to/mounted/state | head'

# Pin OPENCLAW_IMAGE to digest (do not copy a random digest from the internet)
# export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw@sha256:<KNOWN_GOOD>"
# docker compose pull && docker compose up -d

オンコール手帳向けの定量閾値（三つ）

MTTR_rollback：「ロールバック決定」から「ラダーすべて緑」までの中央値分。小規模チームでは 15 分以内を目安にします。二週連続で超えるならスナップショット自動化か compose の分岐が壊れています。
週あたりのスプリットブレイン検出：CLI が報告するビルドと Gateway のダイジェストが食い違う自動アラート。ゼロでない週は grep を増やすのではなく「単一の真実の源泉」への是正が必要です。
ボリューム漂移率：ロールバック後の初回プローブ失敗のうち、根本原因が「空ディレクトリのマウント」または「UID 不一致」である割合。10% を超えるなら compose のバインドパスをコードレビュー必須にします。

これらはベンチマークではなく 運用上の観測指標 です。「悪い版」を感覚ではなく数えられる事象に落とし込みます。重い Xcode ビルドと Gateway を同一ホストに置く場合は、ディスクの水位とログローテーション をアップグレード窓に紐づけないと I/O 飽和で MTTR が伸びます。キャパシティとリースの枠組みは多地域レンタルガイドを参照し、本稿では課金の細部には触れません。

「ノート上の浮動タグ追従と手動ロールバック」が「専用リモート Mac とダイジェスト固定」に負けやすい理由

ノート PC は操作には優れますが、スリープ、クラムシェル、VPN の変動、OS アップデート、キーチェーン文脈が Gateway の稼働と重なります。同一台でロールバックすると「コマンドは成功したがデーモンは再読み込みされない」半端状態が出やすくなります。権威ある Gateway を 常時オンラインの専用リモート Mac に置き、文書化された SSH 転送やプライベート入口で届けると、版変更の面 と 個人端末のノイズ が分離され、多くのチームがエージェント Gateway を本番化する形になります。ローカルで最先端を走らせる場合でも、真実トリプルは CI か cron に残し、チャットのスクロールには残さない方が安全です。

何度も docker compose restart するだけや、盲目的な npm reinstall に比べ、ダイジェスト優先のロールバックは監査と二台目での再現が可能であり、セキュリティやポストモーテムで実際に求められる要件に応えます。7×24 で監査可能な Gateway をチームの変更リズムに合わせて載せるなら、六地域で柔軟なリースを持つ MACCOME の Mac mini（M4 / M4 Pro）にワークロードを置く方が、ノートの電源ポリシーと戦うより総所有コストで有利なことが多いです。まず多地域ガイドを読み、トポロジは上記 SSH Runbook で配線してください。

締め：最後に良好だったダイジェストはシェル履歴ではなく ROLLBACK.md に書く

成果物には既定のダイジェスト参照、許容するプレビュー窓、禁止パターン（例：本番は digest のない latest に浮かせない）、ラダー出力のサンプル、ロールバック担当とタイムアウトを列挙してください。二台目のマシンで再現できない手順は、文書として未完成です。GHCR ブートストラップと Control UI と併読する際は、「イメージのロールバック」と「18789 の露出方針」を同一チケットにまとめ、緊急ダウングレードのあとに管理 UI を誤って公開しないようにしてください。