OpenClawが壊れた?Claude Codeで直します

私のローカルOpenClawエージェントは、このサイトやチャットアプリ、細々とした自動化を動かしています。無料で、疲れ知らずで、本当に優秀 — 動いている土台が壊れるまでは。壊れたときに、溺れているシステム自身に助けを求めたりはしません。同じマシンでClaude Codeを開いて、より強いモデルに直してもらいます。

二段構えの考え方

ローカルモデルはかなりの仕事をこなせます。記事の下書き、サービスの監視、チャットへの通知、定期ジョブ。ただし限界もあります — コンテキストが小さく、デバッグの勘が弱く、本当は診断が必要な場面でも自信満々に再起動しがちです。

目安はシンプル。決まった手順で直るならOpenClaw。「原因を突き止める」必要があるならClaude Codeです。

実例: クラッシュループするゲートウェイ

ある朝、OpenClawのゲートウェイがこれだけを残してクラッシュループしていました:

agents.list.5: Invalid input

どのエージェントが原因かも書いてありません。再起動しても直らない — 直したそばから設定が壊され続けるからです。ローカルモデルなら永遠に再起動を繰り返していたでしょう。

マシン上で動かしたClaude Codeが突き止めた原因はこうでした。OpenClawのアイデンティティ整合処理が、以前の整理で残っていた古いワークスペースファイルを読み込み、起動のたびに無効なエージェント定義を本番設定へ注入し直していたのです。恒久的な修正は三段構え:

1. 実際の原因である古いソースファイルを修正する
2. きれいなゲートウェイ設定を復元する
3. 全ユニットが安定するまで起動と再起動のサイクルを回して検証する

これがパターンです。見えているエラーは設定にあっても、原因は何週間も誰も見ていなかったファイルにある。再起動ではなく、診断です。

「次はOpenClawができるように直す」

Claude Codeセッションの後半こそ、多くの人が省略してしまう部分です。修理のあと、得られた知見をローカルシステムに還元させます。同じ種類の問題で高価なモデルを二度と呼ばなくて済むように。具体的には:

• ローカルエージェントが実行できるランブック。 小さなモデル向けに書かれた手順書 — 確認可能なステップ、正確なコマンド、厳格なルール。このサイトの週次更新ジョブは、まさにこの形式のファイルで動いています。
• 注意力ではなくガードレール。 ある障害のあと、Claude Codeはこのサイトのビルドにフェイルクローズドな公開前チェック(シークレットスキャン+コンテンツルール)を追加しました。ローカルでもクラウドでも、どのエージェントも恥ずかしいものを公開できません。
• 既知の故障モードへのウォッチドッグ。 遅いローカルモデルに合わせたタイムアウト調整、ディスパッチ作業への自己削除式フォローアップタイマー、黙って失敗せずチャットアプリに通知するヘルスチェック。

次に同じ問題が起きたときは、OpenClawが無料トークンで対処します。Claude Codeの出番は、本当に新しい問題だけです。

なぜOpenClawのマシン上でClaude Codeを動かすのか

同じマシンで動かせば、本物のログ、本物の設定、本物のサービス状態を直接読めます。修正が効いたかも端から端まで検証できる。私の説明を経由した伝聞情報は、「もっともらしいが間違った修正」の温床です。

ハマりどころ

• 障害の最中にローカルエージェント自身に直させない。 自分のゲートウェイが壊れたエージェントは事態を悪化させます。外側(Claude Code)から直して、それから制御を返すこと。
• 恒久修正にこだわる。 「再起動」は対症療法です。根本原因を明示的に要求し、修正が再起動サイクルを生き延びることを証明させましょう。
• 記憶が新しいうちにランブックを書かせる。 障害の最良のドキュメントは、直した本人が直した数分後に書くものです。
• ループにシークレットを入れない。 エージェントが読むランブックや説明書はシークレットフリーに。鍵は文章ではなく環境変数に置きます。