OpenClawが壊れてしまった？ Claude Codeで直してみる
- カテゴリ
- AIとローカルLLM
- 公開日
- 2026年7月11日
- 更新日
- 2026年9月16日
- 著者
- Jacob Lloyd — プロジェクト完了後、AIの支援を受けて執筆
- 読了時間
- 約5分で読めます
かんたんに言うと: 私は自宅でサーバーを運用しており、日常的な作業を担ってくれるローカルなAIアシスタント（OpenClaw）を使用しています。何か本当に不具合が生じたり、処理が複雑化したりした際には、より強力なクラウド型アシスタント（Claude Code）を同じマシン上で利用して問題を解決します。また、今後はローカルなAIアシスタントでもその状況に対応できるよう、指示内容も記述しておくのです。
私のローカル環境で動作するOpenClawエージェントが、このウェブサイトやチャットアプリ、そしてさまざまな小規模な自動化処理を担当しています。これらは定額料金制のもとで24時間体制で実行されており、ただし稼働中のシステムが故障するまでの話です。システムが危機的状態になった際には、無理に自力で回復させようとはせず、同じマシン上でClaude Codeを起動し、より強力なモデルに修復作業を任せます。
要約
- 単純で繰り返し行う作業： ローカルのOpenClawエージェント。定額制トークンで常時稼働。
- 極めて複雑または破損している場合： OpenClawが動作するマシン上で直接Claude Codeを実行。
- 重要な点： Claude Codeは単に修復するだけでなく、次回以降もOpenClawが同様の作業をこなせるように設定まで整えてくれる。
二層構造のアプローチ
ローカルモデルは多くの用途に十分対応できます。例えば投稿の下書き、サービスの監視、チャットメッセージの送信、定期的なジョブの実行などです。ただし限界もあります。コンテキストウィンドウが狭く、デバッグ能力も限られており、本来は診断が必要な状況でも自信満々に再起動を繰り返す傾向があります。
基本的な判断基準としては、既知の手順で修復可能な場合はOpenClawが対応し、何をすべきか「考える」必要がある場合にはClaude Codeを利用します。OpenClaw Model ManagerというGUIもまさにこのサイクルから生まれた手順の一つです。これによりモデルIDが正しいか事前に検証され、不適切な設定がシステムに反映されることを防いでいます。
実例：クラッシュを繰り返すゲートウェイ
ある朝、OpenClawのゲートウェイが以下のエラーと共にクラッシュを繰り返していました。
agents.list.5: Invalid input
エラーメッセージ内に記載された名前のエージェントは存在しませんでした。再起動しても状況は改善せず、設定は直すたびにまた壊れていく状態でした。ローカルモデルであれば永遠に再起動を繰り返していたでしょう。
同じマシン上で実行されたClaude Codeが原因を突き止めました。OpenClawのID整合処理部分が、以前のクリーンアップ作業で残った古いワークスペースファイルを読み込み、起動するたびに無効なエージェント定義を実際の設定に再挿入していたのです。恒久的な修復には以下の3段階が必要でした。
- 問題の原因となる古いソースファイルを修正する。
- 正常なゲートウェイ設定を復元する。
- 全ユニットが安定して稼働するまで起動・再起動サイクルを繰り返し検証する。
このように、目に見えるエラーは設定上にあるものの、実際の原因は何週間も誰も見ていなかったファイルだったのです。つまり診断こそが重要で、単なる再起動では不十分なのです。
「次回以降もOpenClawが対応できるように修復する」
Claude Codeによる作業の後半部分は多くの人が見落としがちです。修復完了後、私はモデルにその知識をローカルシステム側にも反映させるよう指示します。そうすることで同種の問題が発生しても高価なモデルを必要としなくなります。具体的には以下のような対策です。
- ローカルエージェントが実行可能な手順書。 小規模なモデル向けに作成された段階的な指示書で、検証可能なステップや正確なコマンド、厳格なルールを含みます。以前私が週次で実施していたサイト更新作業もこの種のファイルに基づいていました。
- 監視ではなく防護機能。 ある事故をきっかけに、Claude Codeはこのサイトのビルドプロセスに「失敗したら公開しない」という事前チェック機能を追加しました。これによりローカル・クラウド問わずいかなるエージェントも不適切な内容を公開できなくなります。
- 既知の障害パターンに対する監視機能。 動作が遅いローカルモデル向けにタイムアウト値を調整したり、処理完了後に自動消去されるタイマーを設けたり、異常時に無言で失敗せず私のチャットアプリへ通知するヘルスチェックなどです。
今後同様の不具合が生じた際にも、OpenClawは定額制トークン内で対応し、本当に新規性のある問題だけにClaude Codeが活用されることになります。
なぜOpenClawマシン上でClaude Codeを実行するのか？
同じマシン上で動作させることで、実際のログや設定情報、サービスの状態を直接読み取れます。そうすることで私の説明から推測するだけでなく、エンドツーエンドでの修復確認が可能になります。私の解釈を介した説明では、論理的だが実際には間違った対策を導き出してしまう危険性があるのです。
注意点
- 障害発生中にローカルエージェント自身に修復させない。 自らのゲートウェイが故障しているエージェントが作業を行えば事態は悪化します。外部からClaude Codeで修復した後、制御権を元のエージェントに戻すべきです。
- 恒久的な修復を求める。 「再起動するだけ」は対症療法に過ぎません。根本的な原因を明確に問い、再起動サイクルを経ても問題が残らないことを確認させましょう。
- 状況が鮮明なうちに手順書を作成させる。 事故の記録として最良なのは、修復直後にその処置を行ったモデル自身が作成する文書です。
- 機密情報は混入させない。 エージェントが参照する手順書や説明資料には機密情報を含めず、キー類は環境変数に格納しテキスト内には記載しないようにします。
関連記事：この修復戦略が守るOpenClawエージェントスタック、DeepSeekをClaude CodeおよびOpenClawスタックに組み込む方法、OpenClaw Model Manager、Claude Codeが初めての方向けにLLMアシスタントの設定方法もご参照ください。