2026 OpenClaw：fallback が openclaw.json にモデルを書き戻す恒久ドリフト — 検知、セッション修復、Gateway 再起動

OpenClaw で プライマリ＋フォールバック を組むと稼働は守れる一方、フォールバック成功後に実行時モデルが openclaw.json に書き戻されると、宣言されたプライマリへ戻らなくなります。本稿はディスク漂移／セッション漂移／プロバイダ解析の分岐を切り分け、Gateway 停止→3点バックアップ→意図フィールド復元→古いマッピング削除→段階再起動の5 手順、そして launchd 遠隔 Mac 向けチェックを整理します。併読: 429 ログ、セッション修復、トークン LaunchAgent。

1. 痛みの分解

実行時選択が静的 agents に無差別で書き戻されると設定意図が壊れます。ベースのモデル名と限定パス付き ID が乖離すると経路がズレます。sessions.json が古い経路を抱えるとチャネルは緑でも応答先が違います。SSH で触った JSON と launchd 環境が一致しないと再起動で復活します。

本問題が厄介なのは可用性メトリクスが緑のまま進む点です。Webhook は 200 を返し、チャネルも配達しますが、コンプライアンス上のモデルラベルやコスト按分だけが静かにズレます。agents.list[].model のハッシュをダッシュボードに載せず運用すると、原因は「プロバイダ不安定」と誤認されやすく、恒久対策が後ろ倒しになります。複数タイムゾーンでは、深夜に jq で救った変更が早番の launchd により別バージョンへ戻る二重の真実も起きやすいです。

そこで本 Runbook は単発コマンドではなく、バックアップ三種・構造化 diff・マッピング剪定・段階再起動をセットとみなします。フォールバックを日常機能として使うほど、「書き戻し可否」をコードレビューとフィーチャーフラグの両面で縛る必要があります。

2. 症状マトリクス

兆候	疑い	避けること
プライマリがバックアップ名に	fallback 書き戻し	セッション整理なしの revert
単一チャンネルだけ誤ルーティング	セッションが runtime provider 保持	盲目再インストール
doctor 許可と矛盾	JSON とセッション分岐	npm 更新の連打
リモートのみ再現	plist 環境が古い	plist の半端コピー

3. 五段修復

Step 1 Gateway 停止

systemd / launchctl。WebSocket を閉じる。

Step 2 バックアップ三種

openclaw.json、sessions.json、関連 jsonl の指紋。

Step 3 意図フィールド復元

agents.list[].model と defaults.primary／fallbacks を揃え、provider 無しのモデル変更を禁止。

Step 4 マッピング剪定

未承認 runtime を指すキーを削除しログ化。

Step 5 段階再起動

openclaw doctor→Gateway→各チャンネルで3ラウンド試験。

jq '.agents.defaults.model' ~/.openclaw/openclaw.json > /tmp/model.before.json
# 修正後
jq '.agents.defaults.model' ~/.openclaw/openclaw.json > /tmp/model.after.json
diff -u /tmp/model.before.json /tmp/model.after.json || true

4. 意思決定

きっかけ	優先	次善
生きているがモデル違い	allowlist 絞り＋JSON 修復	全セッション破棄
共有ゲートウェイの複 persona	persona 単位で凍結	単一モデル強制
launchd が古 env を復活	WorkingDirectory と JSON を検証	adhoc export

5. 現場メモと監査観点

「夜は救われたが、二週間後に監査でディスク primary が小型モデルのまま」と判明。

複数プロバイダのフェイルオーバーは可用性を守りましたが、フォールバック後にセッションランタイムが agents.list[0].model を小型モデルへ書き換えたため、主回路が復旧しても「最後に成功したモデル」を優先する解決ロジックへ固定化しました。バックアップ→JSON 修復→sessions マッピング剪定→Gateway の順で再起動し、MR テンプレにフォールバック由来の永続化禁止を追記した後、同種チケットはゼロになりました。

監査ではインシデント重大度を設定完整性に分類しました（チャネル停止ではなくラベルと契約違反リスク）。以降、内報向けに models ブロックの日次ハッシュを出し、CR 番号なしの差分を検知したら自動で二次レビューに回す運用に切り替えています。

6. ガバナンスと可観測性

JSON diff は Terraform 変更と同じ承認フローに乗せるのが安全です。各成功ターンの qualified model（ネームスペース付き）を構造化ログに出し、SIEM では agents.list ハッシュの変化を CR 必須条件でアラート化します。自由記述ログだけだと、三週間後の再発分析で手が止まります。

リモート Mac の launchd 常駐は熱と電源が安定する一方、SSH 上の一時的な export が真実だと勘違いしやすいです。值班手順に「launchctl から印刷した環境→openclaw doctor のパス→最小メッセージでモデル指紋確認」を固定で挟んでください。Windows/Linux でも Gateway は動きますが、macOS 向けスクリプト資産を再利用したいチームは、MACGPU の Apple Silicon リモートノードにテンプレを載せ替えると責務境界が明快になります。

7. プロバイダ／限定パスのゲート

agents.list[].model が裸エイリアスのままだと、既定プロバイダへ暗黙結合されます。セッションが一度でも vendor/model 形式で成功すると、次ターンは同名だが別経路という幽霊ルーティングが起きます。テンプレでは provider+model を必須にし、CI で jq 検証を掛けましょう。

Telegram／Web UI／Cron を同居させる場合、チャネルごとのペルソナ上書きが古いセッションポインタを参照していないか行列で確認します。「一部チャネルだけ無事」はほぼセッション分裂です。plist を更新したのにプロセス環境が古いときは、SSH で完結させず launchctl bootstrap や LaunchAgent の再読込まで Runbook に書きます。

8. 数値ゲート（変更票に貼る）

① 修復前後で最低各 3 ラウンドのプローブメッセージとログフィンガープリント。② プロバイダ切替時は時刻と HTTP ステータスをチケットへ。③ 週あたり 2 件超の「ディスクと意図の不一致」なら、コード監査完了までフォールバックトポロジ変更を凍結。④ sessions ディレクトリに触れる操作は sha256 付きバックアップ必須。

FinOps 連携のため、修復前後の時間帯別トークンコストをスプレッドシートに落とし、ラベル誤り率（構造化ログから）と並べると、フォールバック永続化の副作用を経営にも説明しやすくなります。

9. FAQ

セッションだけ消す？JSON が曲がっていれば再発します。Docker？volume とコンテナ内 HOME を一致させる。先にバージョンアップ？修復とマッピング整理を先に。複数人で JSON を触る？ロックまたは変更窓、コンフlict は Git の意図ブロックを優先。フォールバックを無効化？削除ではなく許容モデル集合を狭める。カナリア公開？ペルソナを分離し agents.list の段落を複製、CR を別々に。