はじめに
前回の記事では、Qwen3.6-35b-a3bでOpenClawが実用化したと報告しました。しかし運用を続けていると、タイムアウト問題という壁にぶつかりました。
今回は、OpenClawのタイムアウト設定を調査した結果、設定では解決できないハードコードされたバグに行き着いた顛末を記録します。
症状：120秒で勝手にフォールバックする
OpenClawのログに以下のエラーが頻発するようになりました：
10:50:13 error diagnostic lane task error:
lane=session:agent:main:discord:channel:...
durationMs=122139
error="FailoverError: LLM request timed out."
timeoutSeconds: 600（10分）に設定しているのに、約122秒（2分）でタイムアウトしてフォールバック先のOpenRouterに切り替わってしまう。
調査その1：設定は効いているのか？
まず timeoutSeconds を600→900に変更して様子を見ました。すると別のログが出現：
11:36:55 embedded run timeout:
timeoutMs=600000
durationMs=600667
こちらは正しく600秒でタイムアウトしている。つまり timeoutSeconds の設定自体は効いている。
では122秒のタイムアウトは何なのか？
調査その2：Ollamaのログを確認
Ollamaのjournalctlログを確認すると、決定的な証拠が見つかりました：
12:00:54 loading model: KvSize:131072, GPULayers:15/41
12:00:59 model weights: GPU=7.6GiB, CPU=14.7GiB
12:01:10 llama runner started in 16.28 seconds
12:02:53 [GIN] 500 | 1m59s | POST "/api/chat"
Ollama側は処理中なのに、クライアント（OpenClaw）が約2分で接続を切っている。 Ollamaは500エラーを返しているが、これはクライアント切断が原因。
調査その3：2種類のタイムアウトが存在する
ログを時系列で整理すると、全体像が見えてきました：
| タイムアウト | 設定 | 効果 |
|---|---|---|
| embedded run timeout | agents.defaults.timeoutSeconds: 900 |
エージェント実行全体の制限時間。設定可能 |
| LLM HTTP fetch timeout | ハードコード（~120秒） | 個別LLMリクエストの待機時間。設定不可 |
timeoutSeconds はエージェントの「1回の実行全体」のタイムアウト。一方、個別のHTTPリクエスト（OllamaのAPIを叩く1回のfetch）には、別のハードコードされたタイムアウトが存在していました。
なぜ120秒で切れるのか
35B MoEモデルをCPU/GPU分割（15/41レイヤーのみGPU）で131Kコンテキストで動かすと、prefill（プロンプト処理）だけで120秒以上かかることがあります。
ストリーミングモードは有効ですが、prefill中は最初のトークンすら生成されないため、HTTPレスポンスとして1バイトも返りません。OpenClawのHTTPクライアントは「レスポンスが来ない」と判断してabortします。
timeoutMs を試したが…
OpenClawのGitHub Issuesで timeoutMs というパラメータの要望を見つけたので試してみました：
"models": {
"providers": {
"ollama": {
"timeoutMs": 900000
}
}
}
結果：
config reload skipped (invalid config):
- models.providers.openrouter: Unrecognized key: "timeoutMs"
Config auto-restored from last-known-good
v2026.5.4では timeoutMs は未実装。 設定に入れるとバリデーションエラーで拒否され、設定全体がロールバックされます。
OpenClawの既知バグだった
GitHub Issuesを調査すると、同じ問題が複数報告されていました：
- #61487 — “LLM HTTP request timeout hardcoded at ~60s”
- #46049 — “LLM request timeout ignores configured timeout settings”
- #45637 — “Add timeoutMs config support for LLM Providers”
ソースコード上は DEFAULT_TIMEOUT_MS$2 = 3e4（30秒）がハードコードされているとの報告もあり、バージョンによって30秒〜120秒の範囲で異なるようです。
結論：現時点でユーザーが変更する手段はない。
ワークアラウンドの検討
| 対策 | 有効性 | 理由 |
|---|---|---|
timeoutSeconds を伸ばす |
△ | embedded run全体には効くが、個別リクエストには効かない |
timeoutMs を設定する |
❌ | 未実装。設定するとconfig拒否 |
| モデルを常時ロード | ❌ | 問題は稼働中に発生。ロード済みでもprefillが遅い |
| コンテキストを下げる | ❌ | 128K未満ではエージェントとして実用にならない |
| ストリーミングで回避 | ❌ | 既にstream:true。prefill中はデータが返らないので無意味 |
| フォールバックに任せる | ○ | OpenRouterが成功するので実用上は動く |
現状の運用
結局、フォールバックが正しく動いているので、実用上は問題なく動作しています：
- Ollama（qwen36-35b-agent）にリクエスト
- ~120秒でタイムアウト → abort
- OpenRouter（deepseek-v4-flash）にフォールバック → 成功
ただし、ローカルモデルが使われる頻度が下がり、OpenRouterのAPI費用が発生するのが残念なポイントです。
まとめ
agents.defaults.timeoutSecondsはエージェント実行全体のタイムアウト。個別HTTPリクエストには効かない- OpenClawのLLM HTTPクライアントには~120秒のハードコードタイムアウトがある（バグ）
timeoutMsパラメータは未実装（Feature Requestとして存在するのみ）- 35B MoE + 131Kコンテキスト + CPU/GPU分割の環境では、prefillだけで120秒を超えることがある
- 根本修正はOpenClaw側のアップデート待ち
教訓： ローカルLLMでOpenClawを使う場合、「モデルの推論速度」だけでなく「prefill時間（最初のトークンが出るまでの時間）」も重要な指標です。VRAM不足でCPUオフロードが多いほどprefillが遅くなり、ハードコードタイムアウトに引っかかりやすくなります。
環境: OpenClaw v2026.5.4 / Ollama 0.20.5 / RTX 3060 12GB / Ryzen 5600X / RAM 32GB