2026 OPENCLAW
GATEWAY_
UP_
RPC_
TIMEOUT.

OpenClaw v2026.5.2へアップグレード後、支配的な障害モードはプロセス終了ではなく、Gateway は Active のまま /health・openclaw status・Dashboard ポーリングがすべてタイムアウトし、sessions.list が 30–70 秒かかり、CPU が 95–100 %に張り付くことです。コミュニティ Issue は transcript compaction がイベントループを長時間ブロックすることを指し、巨大セッションストア（数百 MB・数千 jsonl）とマルチ Agent/Telegram 構成が増幅します。本稿は症状マトリクス・意思決定表・六手順 Runbook・三ゲート・ケーススタディ・業界観点・数値しきい値・FAQを示し、サイト内《多渠道 JSONL と Bootstrap 停止》《invalid config と doctor --fix》《stale skillsSnapshot》と相互参照し、リモート Apple Silicon Gateway 対照ノードで 7×24 検収とロールバックを行えます。

1. 課題の分解：「Active だが到達不能」≠ チャネル無応答

1）HTTP 表面タイムアウト：Gateway プロセスは生存しポート 18789 はリッスンするが、curl /health と openclaw gateway status --deep --require-rpc がデフォルト 10s 内に応答しない——ネットワークや FW と誤判定されやすい。2）コントロールプレーン RPC 飢餓：compaction 中に sessions.list・cron.list・node.list がサブ秒から 33–145 秒へ跳ね上がり、WebSocket 要求がすべてキューイングされる。3）JSONL 膨張とは別根因：Bootstrap 停止は巨大 jsonl が多い；5.2 回帰は compaction がイベントループを 10–15 秒同期ブロックし、ログに event loop delay が数万 ms 現れる。4）状態移行の副作用：2026.4.24 から 5.2 へ跳ぶと、クリーンアップ前は旧バイナリでも遅くなる状態が残る。5）リモート Mac 7×24 の増幅：ノートの偶発タイムアウトは再起動でごまかせる；本番ノードの連続タイムアウトはチャネル「間欠オンライン」——バージョン・セッションストア容量・compaction ウィンドウ・CPU サンプル四元組を凍結してから作業する。

2. 意思決定表：スリム化、ダウングレード、ロールバック？

現場シグナル	第一アクション	禁止
/health タイムアウト + CPU >90 % + sessions.list >30 s	compaction ウィンドウ外の書き込み停止 → jsonl アーカイブ → Telegram/メモリ検索を一時停止	ピーク時に sessions ツリー全体を rm -rf しない
Dashboard のみ遅い；CLI は間欠正常	ポール頻度を下げる；gateway restart --wait	バックアップなしで openclaw.json を編集しない
5.2 後に全チャネル停止	2026.4.24 にピン；状態ディレクトリ diff	CLI だけの「偽アップグレード」
単一 Agent セッションが gigantic	Agent 単位で jsonl/transcript アーカイブ	skillsSnapshot 修正と混在させない
監査可能な本番変更	リモート対照ノードで六手順を先に実行	30 分プローブ窓なしでチケット closure

3. 六手順 Runbook

Step 1 証拠を凍結

バージョン、Gateway PID 起動時刻、セッションディレクトリの du -sh、ログの compaction キーワードを記録。直近 300 行をチケットへ添付。

Step 2 公式診断ラダー

openclaw status → gateway status → doctor → channels status --probe。status 自体がタイムアウトなら ps/lsof でプロセスとポートを確認してから設定変更。

Step 3 セッションストアの層別スリム化

バックアップ後、Agent ごとにしきい値超の jsonl をアーカイブ。目標は sessions.list を 3 秒以内——ゼロファイルではない。

Step 4 機能の一時ダウングレード対照

Telegram ポーリング、memory search、Bonjour 等を順に切り替え、各トグル前後の CPU と RPC レイテンシを記録してボトルネック特定。

Step 5 順序付き再起動と RPC プローブ

openclaw gateway restart --force --wait のあと、gateway status --deep --require-rpc を三回計測。launchd ホストでは launchctl kick -k 後に繰り返す。

Step 6 リモート 7×24 対照とロールバック窓

対照 Mac で Step 1–5 を繰り返し、sessions.list P95 を比較。5.2 が SLO を満たさなければ本番を 2026.4.24 にピン。closure 前に 30 分 /health と channels.probe が緑であること。

4. 三ゲート

到達性：/health が三回とも 2 秒未満で成功。RPC：sessions.list が三回 5 秒未満（巨大ストアは 10 秒、変更票に記載）。チャネル：30 分間 probes が緑でタイムアウト再発なし。

5. ケーススタディ：Dashboard 全灰、Telegram は時々一言

MACGPU 借り受けリモート Mac 上の SaaS 当番 Bot が、アップグレード直後にコントロールプレーン飢餓：Dashboard 不能、openclaw status タイムアウト、Telegram は長寿命接続で断続応答——チャネル層障害と誤判定寸前。380 MB 履歴 jsonl のアーカイブと memory search 一時停止で CPU は 40 % 未満、/health 復旧。対照ノードは 5.2 修正版まで 2026.4.24 を維持；変更票に金曜ピークアップグレード禁止。

JSONL 専稿との役割分担：巨大 jsonl → 起動/セッション取得が遅い；5.2 compaction → 稼働中の周期的フリーズ。skills 不更新は skillsSnapshot 専稿を先に——フリーズ窓で reset を繰り返すと jsonl が増え compaction が悪化する。

6. 業界観点：コントロールプレーン SLO が 2026 のハードル

2026 年の Agent Gateway は transcript 整理を主プロセスに載せるが、運用側は compaction ウィンドウと RPC SLO（sessions.list P95 <5 s 等）が必要。発注者は /health レイテンシヒストグラムとセッションストア曲線を求める——バージョン文字列だけでは足りない。教訓：Active ≠ Healthy。リモート Mac クラスタはロールバック可能なピンで黄金対照を維持する。

Windows/Linux でもイベントループブロックは同型でサービスマネージャのみ異なる。マルチメディア Agent ワークフローと 24/7 専有メモリでは Apple Silicon リモート Macが黄金環境として選ばれ続ける。本番と隔離・スナップショット可能・チケット再生可能なノードで 5.2 回帰・スリム化・ロールバックをリハーサルするなら、MACGPU リモート Mac を借り、六手順 Runbook と 30 分プローブを対照ハードで通してから本番へ——両端 RPC レイテンシがチームと監査を説得する。

7. 引用可能な数値しきい値

① 単一 Agent sessions >200 MB かつ sessions.list >10 s：アップグレード前にアーカイブ。② /health が三回連続 2 s 超失敗：Unhealthy、チャネル問題と宣言しない。③ compaction ログの event loop delay >5000 ms：変更ウィンドウ、スキル並行インストール禁止。④ 5.2 後 30 分 RPC プローブ失敗：デフォルト 2026.4.24 へロールバック。⑤ リモート対照と本番の openclaw --version 不一致：設定 diff マージ禁止。

8. FAQ

「無応答」汎用トラブルシュートとの違い？ 認証/チャネル層が多い；本稿はコントロールプレーンタイムアウト + CPU 満杯。スリム化なし再起動？ 巨大ストアでは一時的。Docker？ 同じ論理、ボリューム I/O に注意。4.24 へ必須ロールバック？ RPC SLO 次第。MACGPU の役割？ 対照検収とロールバック窓——貴社変更承認の代替ではない。