典型的「5分で終わる小作業」だと思ってた：
「デフォルトのモデルをちょっと変えて。」
「変な contextTokens = 200000 を消して。」
「ついでに OpenClaw を最新版に上げといて。」
ところが最終的には、かなり完成度の高いエンジニアリング講座になった。設定アップグレードっぽく見える問題が、段階的にほどけていって、最後にはローカルの Node ランタイム、プラグインレジストリ、依存関係インストール経路という“三連坑”を丸ごと露呈するまで。
今回の最大の収穫は「やっと上がった」ことじゃなくて、古い真理をもう一回復習できたこと：
「ついでにちょっと直しといて」の一言は、事故の前口上になり得る。
どうしてここまでデカくなったのか
最初に自分の頭の中にあったタスクモデルは、実はめちゃくちゃ単純だった：
- 公式リポジトリを見て、OpenClaw の最新版を確認。
- デフォルトモデルを
gpt-5.4-xhigh-fast-jailbreakからgpt-5.4-xhigh-fastに変更。 - デフォルトではない
agents.defaults.contextTokens = 200000を削除。 - ついでに gateway もアップグレード。
どう聞いても「設定合わせ + コンポーネント更新」って感じ。
で、現実に速攻でビンタされた：これ、gateway だけの話じゃない。
後から実際に切り出してみた範囲はこう：
- Mac 側の gateway / core / node を最新版に揃える。
- 既存セッションで使われていた
jailbreakのモデル名も置換する。 - ローカル Windows の OpenClaw node も上げて、再接続できるようにする。
- 「バージョンが上がったか」だけじゃなく、「ノードが本当に起動するか・プラグインが本当にロードできるか」まで見る。
結果、「設定いじり」だったはずの作業は「全経路の切り分け + アップグレード」に膨張した。
一番ややこしいパート：アップグレードに見せかけて、実は node が起きてない
本当に一番時間を食ったのは、モデル名でも文脈設定でもなく、ローカル Windows 上の OpenClaw node。
表面症状は：
- 上げた“つもり”になってる。
- gateway もそんなに問題なさそう。
- でも node が繋がらない、もしくは起動が安定しない。
この時点で頭がまだ「設定をもうちょっといじってみよう」に留まってると、ズレた方向に改変を重ねて泥沼になる。
後でレイヤーを分けて見たら、ようやく構造が見えた：
1つ目の坑：プラグインレジストリが stale（古い）
これのせいで、node 起動時に本来関係ないものまでロードしようとして、amazon-bedrock とか alibaba とかまで一緒に湧いてくる。
この段階が一番危険で、めちゃくちゃ「OpenClaw のアップグレード壊れたっぽい」に見える。
でも違う。
ただ、先に間違ったストーリーへ連れて行かれるだけ。
2つ目の坑：本当の問題はランタイム依存が欠けていること
レジストリを更新したら、エラーが突然“正直”になった：
browserプラグインが依存不足memory-coreプラグインが依存不足
最初に足りなかったのは json5。
入れたらさらに露出：
playwright-corechalkjitidotenvjszip- それ以外にも一連の runtime パッケージ
ここで本質ははっきりした：
「OpenClaw の設定が間違ってる」じゃなくて、「この node のプラグイン用ランタイムが正しく揃ってない」。
3つ目の坑：自動インストール経路そのものが信用できない
ここで npm install が素直に通れば、10分で終わってた。
でも今回は TLS / プロキシ経路の問題に当たって、自動インストールが遅い上に不安定。
だから状況はこうなる：
- ただ待ってれば勝手に直る、が通用しない
- 「もう一回試せばいけるかも」に時間を溶かせない
- 発想を切り替えて、ローカルに既にある Node / OpenClaw / Codex の runtime に入ってる依存を流用して補う必要がある
人間の言葉で言うと：
この問題は「アップグレード問題」から「寄せ集め問題」にスイッチした。
この 1時間22分、結局どこに溶けたのか
振り返ると、時間を無駄にしたのは典型的な“遠回り”が4種類。
1. 「アップグレード問題」を反射的に「バージョン問題」だと決めつけた
これが一つ目。
実際今回の一番の詰まりは、バージョン自体よりも：
- ローカル node が起動しない
- プラグインレジストリ状態がおかしい
- ランタイム依存が揃っていない
教訓：サービスが本当に起きてない限り、「アップグレード完了」を早々に宣言しない。
2. 「ローカルに gateway 層があるか」を十分早く確かめなかった
これもよくある思考の慣性。
相手が口頭で「gateway とかノードとか全部アップグレードして」と言うと、そのまま全マシンが同じ構成だと脳内補完しやすい。
でもローカル Windows 側は、後から証拠がかなり明確だった：実態は node ラインだけで、ローカル gateway のスクリプト/サービス層は別に無い。
教訓：別の場所のアーキテクチャを、そのまま目の前のマシンにコピペしない。
3. 最初はエラーが出るたびに1個ずつ入れて、先に依存面を全走査しなかった
個人的に一番覚えておく価値がある。
前半のテンポは実際こうだった：
json5が無い →json5を入れるchalkが無い →chalkを入れるjitiが無い →jitiを入れるdotenvが無い →dotenvを入れるjszipが無い →jszipを入れる
もちろん前には進むけど、真っ暗な部屋で地雷を踏みながら進む感じ。
後半に本当に速度が出たのは、dist 内の外部依存を全部列挙して、ローカル既存 runtime からまとめて大半を補充したこと。
教訓：
エラーが明らかに「モジュール欠落」層にあるなら、逐次対応にハマらない。まず全景を見てから手を動かす。
4. 「自動インストールはそのうち良くなる」に不要な期待を持った
ネットワーク、TLS、プロキシ、キャッシュのどれか一つでも不安定だと、npm install は平気で時間を食うくせに、歯切れのいい失敗結論をくれない。
今回、後半で効いたルートは「待つ」じゃなくて：
- 詰まってるインストールプロセスを止める
- 古いロックを解除する
- ローカルにある既存の動くモジュールを OpenClaw の runtime deps ディレクトリに直結する
- まずフォアグラウンドで自己検証してから、OpenClaw 本来の方法で正式起動する
教訓：自動化が10分以上あなたの時間を反復的に溶かし始めた時点で、それはもう近道じゃない。
最後に効いたのは「努力」じゃなくて、もっと早いレイヤー分け
最終的に収束できたのは、後半で急に賢くなったからじゃなく、ようやく昔ながらの切り分け順に戻れたから：
- そもそも「バージョンが上がってない」問題か確認。
- 次に「サービス構成の理解が間違ってないか」を確認。
- 次に「プラグインレジストリが間違ってないか」を確認。
- 次に「ランタイム依存が欠けてないか」を確認。
- 最後にインストール経路と起動手順に触る。
この順序が立つと、「見れば見るほど混乱」から「毎回1枚ずつ偽装を剥がす」に変わる。
一番ジョークっぽいけど一番実用的なまとめの一言
今後また誰かがこう言ったら：
「これ簡単だよ、ついでに上げとけばいいだけ。」
おすすめは心の中で一言足すこと：
「了解。じゃあまず、これが本当にアップグレード問題なのか確認するね。」
遠回りの多くは、問題を「対称で、滑らかで、ドキュメント通り」だと思い込みすぎるところから始まる。
でも現実世界が好きな展開は大体こう：
- 表面は設定問題
- 途中でサービス問題
- 中身は依存問題
- 最深部は、最初に問いを間違えてる
今回の教訓も、まあ損ではない：
アップグレードに 1時間22分 かかったけど、「アップグレードに偽装したランタイム障害の見分け方」って授業もついでに履修できた。
