2026 OPENCLAW
SKILLS_
SNAPSHOT_
STALE_
RESET.
2026年に ClawHub や ~/.openclaw/skills/ へ新スキルを導入したのに、Telegram や Slack などのチャネルで Agent がいまだに「旧版」のように振る舞う——/new や sessions.reset を実行してもログに期待どおりの skillsSnapshot 更新が現れず、モデルや認証が auto model/auth 上書き に引きずられる——こうした事象は、多くの場合スキルパッケージ未導入ではなく、セッションスナップショット・ディスクマッピング・Gateway プロセス内キャッシュの三層が揃っていないことが原因です。本稿では課題分解・意思決定表・六手順 Runbook・三ゲート・ケーススタディ・業界観点・数値しきい値・FAQを示し、サイト内の《invalid config と doctor --fix》《Fallback 書き戻しと sessions 是正》《多渠道 JSONL と Bootstrap 停止》と相互参照します。必要に応じて黄金対照環境を7×24 専有のリモート Apple Silicon Gateway ノードへ移し、検収してください。
1. 課題の分解：reset が消すのは「会話」で、必ずしも「スキル図スナップショット」ではありません
1）skillsSnapshot とセッション reset の意味論の非同期：/new と sessions.reset は多くの場面で対話コンテキストとルーティングキーをリセットしますが、Gateway 側は性能のためスキルディレクトリ解析結果（skillsSnapshot）をキャッシュします。キャッシュキーがスキルディレクトリの mtime 無効化に追随しないと、「ディスク上の SKILL.md は新しいのに、実行時ツール一覧は古い」という乖離が起きます。2）auto model / auto auth 上書きの残留：fallback やチャネル戦略が一度でも実行時モデル・provider トークンをセッションエントリへ書き込むと、reset が sessions.json 内の runtimeOverrides に触れない限り、Agent は旧モデル能力境界で新スキルを解釈し続けます（vision 必須スキルがテキスト専用ティアへルーティングされる等）。3）sessions.json マッピングの陳腐化：マルチアカウント・マルチチャネル併存時、削除済み sessionId や旧 workspace パスが残り、reset 後に誤スロットを静かに再利用します。4）CLI 再起動 ≠ Gateway 再起動：対話シェルで openclaw status が緑でも、launchd 常駐の Gateway が起動時スキル図を保持したままのことがあります。gateway restart --force --wait とリスン準備完了の検収が必要です。5）リモート Mac 7×24 の「疑似リフレッシュ」：手元 MacBook にだけスキルを置き、リモートノードへ未同期・未強制再起動すると、引き継ぎ時に「OpenClaw がまた不安定」と誤判定しがちです。まず両端の skills ディレクトリ hash と Gateway PID 起動時刻を揃えてから npm 再インストールを検討してください。
2. 意思決定表：スナップショット確認、sessions 整理、force 再起動のどれから？
| 現場シグナル | 第一アクション | 代替 / 禁止 |
|---|---|---|
| 新スキルはディスク上にあるがツール一覧が不変 | skills mtime 照合 → Gateway force 再起動 → 新規セッションでプローブ | チャネルだけ更新し Gateway を再読込しないこと |
| reset 後も fallback ティアのモデル挙動 | sessions.json の runtimeOverrides / auto フィールド確認 | バックアップなしの全ファイル削除 |
| 単一チャネルのみ陳腐、他は正常 | channelId 単位でマッピングエントリ削除後に reset | sessions.json の一括削除 |
| v2026.5.x 以降で全体が「鈍く」なった | openclaw.json agents 節と doctor 出力を対照 | スナップショットなしでスキルと plist を並行変更 |
| 監査可能な本番ウィンドウが必要 | リモート対照ノードで同一六手順を先に実施 | ピーク時に本番 sessions を直接編集 |
3. 六手順 Runbook：「説明できる」から「対照検収できる」へ
Step 1 証拠四元組を凍結する
作業前に固定します：openclaw バージョン、Gateway PID 起動時刻、skills ディレクトリのファイル数/hash、対象 channel の session キー。openclaw status、openclaw gateway status、直近 200 行の gateway ログをチケットへ貼付します。四元組がないまま「sessions 削除 + スキル再インストール + plist 変更」を並行しないでください。
Step 2 ディスク真源の検証：スキルが正しい場所にあるか
~/.openclaw/skills/ または workspace 約定パスで SKILL.md / manifest が Gateway 実行ユーザーから読めることを確認します。リモート Mac では rsync やデプロイパイプラインでディレクトリを揃え、「手元のみ・サーバなし」の分岐を避けます。ClawHub 導入時はパッケージ名とバージョンを記録し、スナップショット内エントリと突合します。
Step 3 sessions.json の層別クリーン（全削除ではない）
先に cp sessions.json sessions.json.bak.$(date +%Y%m%d%H%M) を実行します。jq で対象 channel / account のエントリを特定し、runtimeOverrides、陳腐な model、宙ぶらりんの sessionId を持つキーのみ削除し、他チャネルマッピングは保持します。ファイルが運用しきい値（§7）を超える場合は、多渠道 JSONL 専稿に沿って剥離とアーカイブを行い、Bootstrap キューが巨大 jsonl で停止しないようにします。
Step 4 reset 直後にプローブメッセージで検収する
対象チャネルで /new または sessions.reset のあと、直ちにプローブ指示（利用可能ツール/スキル名の列挙など）を送ります。応答に新スキルが無い場合、reset を 2 回超えて繰り返さず Step 5 へ進んでください。
Step 5 Gateway 強制再起動と準備完了待ち
openclaw gateway restart --force --wait（または同等 RPC）で旧プロセス終了とスキルディレクトリ再スキャンを保証します。リモート launchd では必要に応じ launchctl kick -k のあと gateway status を三回実行します。invalid config 専稿と同様、再起動嵐の最中は openclaw.json を変更しないでください。
Step 6 リモート 7×24 対照検収マトリクス
対照ノードで Step 1–5 を繰り返し、両端ログの skillsSnapshot 要約（ツール数、hash、スキャン時間）を比較します。本番切替前に連続 30 分プローブ無退行と channels.probe 無赤を要求し、検収ログを変更票の closure に添付します。
4. 三ゲート：SOP に書けば玄学になりません
第一スナップショットゲート：再起動後、ログまたは status の skillsSnapshot ツール/スキル数がディスク上の find 結果と一致すること。一項目でも差があれば「スキル有効」と宣言しないでください。第二セッションゲート：対象 channel の reset 後最初のプローブが新スキルに命中すること。10 分以内に退行したら sessions.json.bak へロールバックし書き込みを凍結します。第三環境一致ゲート：対話シェルと launchd の OPENCLAW_*、skills パス、Gateway PID 起動時刻を項目 diff すること。リモート本番と手元開発機の hash が不一致のときは変更をマージしないでください。
5. ケーススタディ：「ClawHub で三スキル導入、チャネルは旧三種のまま」
「リモート Mac mini の当番 Bot に summarize・browser・calendar を導入し ClawHub は成功表示。Telegram で /new を連投しても新ツールが出ず、手元 MacBook では同一 openclaw.json で正常——最終的に Gateway が 11 日稼働のまま skillsSnapshot が更新されず、sessions.json の当該グループ runtimeOverrides が fallback モデルに固定されていた。」
2026年5月、あるコンテンツ運用チームが OpenClaw を 7×24 要約入口に据え、ClawHub からスキルを一括導入しました。当夜の Telegram テストでは旧組込ツールのみが呼ばれ、運用担当は /new を三回、CLI でも sessions.reset 成功表示でしたが、スキル再スキャンを示すログ行は一切ありませんでした。復盤は二段です。第一段、ps で Gateway PID 起動が 11 日前、skills 最新 mtime と大きく乖離——reset はセッションのみでプロセス内スナップショットは無効化されなかった。gateway restart --force --wait 後、ログに skills scan 要約が現れ、ツール数は 7 から 10 に増えました。第二段、sessions.json を照合すると当該グループに 429 後の runtimeOverrides.model が残り、browser スキルが能力タグ不一致でルーティング層から静かにスキップされていました。本 Runbook に沿いバックアップ後に当該 override のみ削除し、30 分プローブ窓を通過して事象を「再現可能な監査」に戻しました。
本件は《Fallback 設定ドリフト》と直列です：fallback の openclaw.json 書き戻しは設定真源の問題、本稿はセッション態 + プロセスキャッシュの問題です。Gateway CPU 100% で新ログが無い場合は、先に《多渠道 JSONL 膨張》で Bootstrap 停止を除外し、その後 skills スナップショット検収へ戻ってください。巨大 jsonl 上で reset を繰り返すと、ますます遅くなります。
当番視点で最も高いコストは「OpenClaw が新スキル非対応」と誤り、Agent を迂回するスクリプトへ移行することです。実態はスナップショットと sessions の層別クリーン不足であることがほとんどです。六手順 Runbook と三ゲートを変更テンプレートに載せると、二度目の同種障害の MTTR は数時間から 30 分以内に短縮でき、「なぜ本番 Gateway を再起動したか」という内審にも証跡で答えられます。
6. 業界観点：2026 年の Agent 運用は「パッケージ導入」から「スナップショット可観測」へ
2026 年の主流 Agent Gateway は遅延削減のためスキル図スナップショットを採用しています。これはレイテンシに有利ですが、運用側には「いつプロセスビューを force 更新しなければならないか」の規律が求められます。発注者や内審が見るのは「最新スキルを入れたか」だけでなく、「導入後に照合可能なスナップショット記録があるか」——PID 起動時刻、skills hash、sessions 整理前後 diff を含みます。OpenClaw のようなマルチチャネル Gateway はディスク状態・セッションマッピング・プロセスキャッシュが結合しており、手元 MacBook の対話起動だけではキャッシュ問題が隠れ、7×24 リモートで N 日目に集中爆発します。
業界のベストプラクティスには、スキル導入を変更ウィンドウに載せること、インストールスクリプト末尾で gateway restart --wait を強制すること、sessions.json をチャネルエントリ単位で整理することが含まれます。《doctor と fail-closed》と並べると「OpenClaw 運用パスポート」ができます：設定合法性、セッションマッピング、スキルスナップショット、Gateway 準備完了——四枚のカードの一枚でも欠けたら夜間マージは避けてください。
手元 MacBook は SKILL.md 反復と単一チャネル検証に適しています。一方、マルチチャネル 7×24・長期スナップショット未更新・リモートと手元のディレクトリ分岐が主因のとき、ノートだけに依存すると「手元は緑・本番は赤」の対照盲点が残ります。クローン可能な黄金環境、チケットで再生可能な sessions diff、GUI と launchd 混在テストの回避が必要なら、MACGPU のリモート Apple Silicon で対照ノードに六手順 Runbook と 30 分プローブ窓を先に通し、変更票を本番へ写してください。両端ログがチームと監査を説得します。
7. 引用可能な数値しきい値（変更票・当番マニュアルへ）
① Gateway 稼働が 7 日を超え skills ディレクトリに変更がある場合、導入後は必ず restart --force --wait とし、セッション reset のみに頼らないでください。② 同一 channel で /new を 2 回超えても無効なら sessions.json を調査し、三回目の盲目的 reset は禁止です。③ sessions.json が 2 MB、単一チャネル jsonl が 20 MBを超える場合は、技能刷新の前にアーカイブ剥離（多渠道専稿と一致）を行ってください。④ スキル有効検収窓は30 分以上ツール一覧無退行でチケットを閉じてください。⑤ リモート対照ノードと本番の skills hash が不一致のとき、本番更新完了を宣言しないでください。
8. FAQ
問：スキルだけ入れて Gateway を再起動しなくてよいですか？答：開発機の短時間テストでは通ることもありますが、本番 7×24 では非推奨です。スナップショットキャッシュは設計上のトレードオフであり、必ずしも不具合ではありません。問：sessions.reset と /new はどちらを使いますか？答：チャネル利用者は /new、運用バッチは sessions.reset；いずれも Gateway 強制再起動の代替にはなりません。問：sessions.json を rm してよいですか？答：止血には有効ですが必ずバックアップし、全チャネルマッピングを失います。jq によるエントリ単位の整理を優先してください。問：invalid config で Gateway に入れない場合との見分け方は？答：入れない場合は doctor と fail-closed ログを先に；本稿は入れるがスキルが古いシナリオです。問：Windows/Linux ノードでも使えますか？答：サービス管理とパスは異なりますが、スナップショットと sessions の層別ロジックは移植可能です。