OpenClawが動かない5つの症状 無反応から暴走まで、原因と直し方
Mac miniに置いたOpenClawが、数日のうちに5通りの形で動かなくなりました。
OpenClawは、Discordで頼むとAIが実装し、レビューを通してPRを作り、mainへ入れるところまで進める仕組みです。
実装はminiの中で動くローカルのAI(qwen3-coder:30b)、レビューはcodexが受け持ちます。
動かなくなる理由は1つではありませんでした。 どの層で起きているかを先に決めないと、直す場所を間違えます。 5つの症状を、起きた順に書きます。
5つの症状は、別々の層で起きた
まず、仕組みの全体と、どこで何が起きたかを1枚にまとめます。
用語を先に置きます。
- 受付役(ゲートウェイ): Discordの依頼を受けて、AIへ渡し、道具の呼び出しを仲立ちする部分。コンテナの中で動く
- Ollama: AIをminiの中で動かす道具。AI本体はここで動く
- Colima: Macの上でコンテナを動かすための、小さな仮想マシン
- トークン: AIが読み書きする文字の単位。日本語ならおおむね1〜2文字で1トークン
症状1 Discordのbotが約2日間、無反応だった
10月12日、Discordに頼んでも返事が来ないことに気づきました。 miniを見ると、10月10日にAppleのOS更新で再起動されていました。
再起動のあとに戻ったものと、戻らなかったものがあります。
| 部品 | 再起動後 |
|---|---|
| Ollama(LaunchAgentで常駐) | 戻った |
| PR監視(launchdで常駐) | 戻った |
| Colima | 戻らなかった |
Colimaが止まると、その中のコンテナ(受付役)も一緒に落ちます。 Discordの窓口だけが消えていたので、miniは動いているのに、botだけが黙っていました。
直し方は1行でした。miniに入って、Colimaを起動します。
export PATH=/opt/homebrew/bin:$PATH
colima start
CPUとメモリの設定は ~/.colima/default/colima.yaml に保存済みなので、引数は要りません。
コンテナは再起動すると自動で立ち上がり、約45秒で正常(healthy)になりました。
直すのは簡単で、問題は気づくまでに約2日かかったことです。 再起動後にColimaが戻ったかを見る仕組みは、まだ作っていません。 OS更新のたびに起きるので、次に同じことが起きる前に手当てが要ります。
切り分けの順番は、WIKIのOpenClawの切り分けに表にしました。
症状2 AIの生成が約56分、止まらなかった
miniのAIの応答を計測していました。
openclaw agent を、shellの timeout 280 を付けて流しました。
280秒で切れたように見えました。切れたのは、手元の計測コマンドだけでした。 受付役の側の実行は続き、AIは終わらない生成に入りました。
- 生成は53,000トークンを超え、約56分続いた
- その間、Ollamaの処理枠(同時にさばける数)のうち1つを占有した
- miniが熱くなっていた
- 受付役のコンテナを止めて収めた(終了コード137)
台所にたとえると、タイマーだけを止めて、コンロの火は点いたままでした。 手元で切った「つもり」と、向こうで止まったかどうかは別の話です。
効かなかった設定と、効いた設定
生成の長さには、上限を入れてありました。maxTokens: 8192 です。これは上限として効いていませんでした。
| 試したこと | 結果 |
|---|---|
maxTokens: 8192 | 上限として効かなかった |
models.providers.ollama.models[2].params.num_predict を8192 | 効いた |
| 試験として64へ下げて流す | 64トークンで止まり(stopReason=length)、全体で30秒 |
shellの timeout で計測コマンドを切る | 手元だけ切れる。受付役側は続く |
openclaw agent --timeout 秒 | 受付役の側で打ち切る |
試験のあとは、上限を8192へ戻しました。[2] は私の設定の中での並び順なので、そのまま写さず、自分の設定を見て合わせてください。
速度は、暴走の間に毎秒27トークンから11トークンへ、なだらかに落ちました。 生成が長くなるほど、読み直す文脈が伸びて遅くなるのが主因と見ています。 熱の寄与は測っていません(電源管理の記録に警告は無し)。
上限は、止めたい層に入れる。 手元のtimeoutは、手元しか止めません。
症状3 ツール呼び出しが、途中で止まった
実Issueを任せる試験で、AIが編集ツールを呼んだ直後に、次のエラーで止まりました。
XML syntax error ... element <parameter> closed by </function>
ローカルのAIが、長い引数を持つツール呼び出しで、</parameter> という閉じ印を書き忘れていました。
この試験で1回、あとの修正ループの試験で1回、計2回起きました。
最初に疑ったのは、< や <= を含む編集内容でした。XMLの記号と衝突しそうだからです。
Ollamaに <= を含む編集を直接渡すと、通りました。 文字が原因ではありません。
毎回起きるわけではないので、対処は2つにしました。
- 編集は、複数行の編集ツールではなく、
execのsedで1行だけ置き換えるよう指示する - 修正役は、1回の修正の中で最大3回やり直す。やり直すときは「編集を小さく分ける」指示を足す
症状4 報告と実際が、ずれていた
実際のIssue(E2Eテストの要素指定1行の修正)を、miniのAIに任せた最初の試験です。 読む、実装する、PRを作るところまでは通りました。ただし、途中の報告にずれがありました。
- 型検査とlintを、対象のアプリのフォルダではなく、リポジトリの一番上で実行して失敗し、「権限の問題」と誤って説明した
- レビューを呼ぶ道具(
sessions_spawn)で、1回目は引数名をobjectiveと書き間違え(正しくはtask)、2回目は「道具が見つからない」で失敗した - 1回目の報告には、レビューが失敗したことが書かれていなかった
指示書に「呼べなければ、PRを出す合図を置かない」と書き足すと、2回目は失敗を正直に報告しました。 ただ、これは頼んでいるだけで、守られる保証がありません。 そこで、レビューをAIの判断に任せるのをやめました。
マージの前に、ホスト側の固定スクリプト(決まった手順を実行するプログラム)がレビューを呼びます。 返答の最後の行が、ちょうど「判定: 問題なし」のときだけマージします。それ以外は、レビューを呼べない、差分が大きすぎる、形式が違う、のどれでもマージしません。
AIの報告は、そのまま信じず、実際の実行記録と照らします。
openclaw sessions tail --agent codese
経過をその場で追えます。あとから一式を読むなら、実行記録を書き出す export-trajectory も使いました。
使者の口上(報告)と、道に残った足跡(実行記録)が合っているかを見る作業です。
症状5 pushは通ったのに、PRにならなかった
同じ試験で、pushまで動いたのにPRの作成が失敗しました。重なっていた原因は3つです。
- ホスト側のgitが、コンテナの中で作られた作業場所(worktree)を開けなかった。
.gitが/workspace/...を指しているのに、ホストにその場所が無い。pushの前にgit worktree repairを行うようにした - 失敗の理由が
| tail -1で消えていた。出力を残し、3回まで試すようにした - 本当の原因は、launchdの設定に残っていた
BASE_BRANCH=release/v1.2。存在しないブランチで、mainに直した
2つ目が調査を遅らせました。失敗の理由を握りつぶす書き方は、原因探しの時間でいつか返ってきます。
直したあとの状態
マージ前のレビューを必須にしたうえで、「要修正」と返されたら、人を待たずにローカルのAIで直して再レビューします。最大3回です。 わざと間違えたPRで実機を試すと、要修正の指摘、ローカルのAIによる修正、再レビューで問題なし、までが約1分46秒で通りました。
まだ確かめていないこと
- 3回直しても通らず、あきらめる経路(偽物でしか試していない)
- 修正が、別の不具合を足してしまう場合
- 再起動後にColimaが戻っているかを見る仕組み(未実装)
- 熱が速度に与える影響(未測定)
- ブラウザでの検証はminiにできないため、別のMacで実行して結果を戻す往復が要る
学んだこと
- 症状を、どの層で起きたかに分ける。 無反応は土台、止まらないのはAI本体、報告のずれは指示と確認の問題。直す場所が違う
- 手元で切れたことと、向こうで止まったことは別。 timeoutは、掛けた場所までしか効かない
- AIの報告は、実行記録と照らす。 失敗を書かないことがある
- 上限は、止めたい層に入れる。 効いたかどうかは、小さな値に下げて試して確かめる
切り分けの手順と、各症状の確認コマンドはOpenClawの切り分けにまとめています。
関連する記事です。
- miniに任せた初日、3回失敗した 原因はAIの外にあった — 続き。Issueを最後まで解かせる入口を作った初日に踏んだ3つの失敗
- miniに実装を任せた結果 マージまで4秒、壊れたmainが49分残った — この仕組みに初めて実装を流した記録
- AIに鍵を渡さず、合図1枚でmainへ — 固定スクリプトに分ける設計の経緯
- 鍵を渡さないpush設計 — 同じ経路の、検査と起動の仕組み