April 18, 2026 • バージョン: 26.4.12 - 26.4.14

Active Memory Timeout: Blocking Recall Pass が設定された Timeout を超過

Active Memory は、複数のモデルとプロバイダ間で呼び出し済みサマリーを返す前に一貫してタイムアウトし、8000ms の設定にもかかわらず ~8084ms でタイムアウトが発生しています。

🔍 症状

Active Memoryが、 구성된タイムアウト時間内でブロッキングリコールパスを完了できません。以下の診断出力が一貫して表示されます：


🧩 Active Memory: timeout 8084ms message 0 chars
🔎 Active Memory Debug: none retrieved

ゲートウェイログでもタイムアウトの動作が確認できます：


active-memory ... done status=timeout elapsedMs=8092 summaryChars=0
embedded_run_failover_decision ... failoverReason=timeout profileFailureReason=timeout

診断上の特徴

  • タイムアウトのしきい値: タイムアウトは~8084-8092msでトリガーされます（設定値は8000ms）。これは、ブロッキング呼び出し開始後にタイムアウトチェックが行われることを示しています
  • ゼロバイトの応答: summaryChars=0により、タイムアウト前にサマリーが生成されなかったことが確認されます
  • モデルに依存しない: 問題はすべてのテスト済みモデルで再現されます：
    • openai-codex/gpt-5.4
    • ollama/glm-5.1:cloud
    • ollama/llama3.1:8b
    • ollama/gemma4:e4b
  • バックエンドに依存しない: アイドル状態およびキュー済み/ビジー状態の実行環境の両方で同一の動作が確認されます
  • プロバイダチェーン: openclaw → ollamaルーティング構成に影響します

環境コンテキスト

コンポーネント値
OpenClaw Version2026.4.12 / 26.4.14
Operating SystemmacOS
Install Methodnpm global
Memory Backendbuiltin/default (memory-core)
Embedding Modelqwen3-embedding (Ollama)
Chat ContextDiscord DM (direct)

🧠 原因

主な原因：同期型エンベディング検索のブロッキング

タイムアウトが発生する理由は、Active MemoryのブロッキングリコールパスがLLMによる要約呼び出しの前段階で、メモリバックエンドに対して同期的なエンベディング検索を実行するためです。エンベディング検索フェーズが設定されたタイムアウト時間を超過すると、LLM呼び出しは実行されません。

障害シーケンスの分析


┌─────────────────────────────────────────────────────────────┐
│ Active Memory Blocking Recall Pass                          │
├─────────────────────────────────────────────────────────────┤
│ 1. Memory Query (synchronous)                               │
│    └─→ Embedding retrieval via qwen3-embedding             │
│        └─→ Memory backend search                           │
│            └─→ BLOCKS HERE (timeout: 8084ms)                │
│                                                             │
│ 2. LLM Summarization (never reached)                        │
│    └─→ Summary generation                                   │
└─────────────────────────────────────────────────────────────┘

寄与因子

  1. Embedded Runへのタイムアウト伝播: embedded_run_failover_decisionログエントリは、Active Memoryのタイムアウトがembedded runコンテキストに伝播し、フェイルオーバー判断のログ記録を引き起こすことを示しています。これはメモリリコールと応答生成フェーズ間の密結合を示唆しています。

  2. 同期型メモリバックエンドクエリ: メモリ検索は同期的なエンベディング検索を使用します。qwen3-embeddingがレイテンシを経験する場合（Ollamaへのネットワーク往返、モデルロード、ベクトル検索オーバーヘッド）、累積遅延が最初のトークン生成前に8000msのタイムアウトを超過します。

  3. タイムアウトチェックのタイミング: 84-92msの超過（実際の8084ms vs. 設定の8000ms）は以下を示しています：

    • タイムアウトは各ブロッキング操作完了後にチェックされます
    • エンベディング検索自体は~8084msを要します
    • サブミリ秒のタイムアウトチェックのための早期終了メカニズムが存在しません

  4. クエリモードの設定: queryMode: “message”設定は、軽量なセマンティック検索ではなく、完全なメッセージエンベディングをトリガーする可能性があり、検索結果の遅延を増加させます。

アーキテクチャ上の不整合

memory-coreバックエンドのエンベッデッドメモリ検索には以下が実装されていません：

  • 非同期/非ブロッキングのエンベディング検索
  • フェーズごとのタイムアウト予算（検索と生成の отдельные budgets）
  • 最初の実質的な結果による早期終了

🛠️ 解決手順

修正1：Active Memoryタイムアウトの増加（即時の緩和策）

エンベディング検索のレイテンシに対応するようタイムアウト увеличить：

変更前：

"active-memory": {
  "enabled": true,
  "config": {
    "timeoutMs": 8000,
    ...
  }
}

変更後：

"active-memory": {
  "enabled": true,
  "config": {
    "timeoutMs": 30000,
    ...
  }
}

修正2：検索フェーズと生成フェーズで別々のタイムアウトを設定

エンベディング検索とLLM生成に対して別々のタイムアウト予算を設定：

"active-memory": {
  "enabled": true,
  "config": {
    "timeoutMs": 30000,
    "retrievalTimeoutMs": 10000,
    "generationTimeoutMs": 20000,
    ...
  }
}

修正3：非同期/軽量なクエリモードへの切り替え

queryModeを“message”から“semantic”または“hybrid”に変更：

変更前：

"queryMode": "message"

変更後：

"queryMode": "semantic"

修正4：より高速なエンベディングモデルの使用

qwen3-embeddingをより高速なローカルエンベディングモデルに置き換え：

"active-memory": {
  "config": {
    "embeddingModel": "ollama/nomic-embed-text"
  }
}

次に、モデルがキャッシュされていることを確認するためにOllamaを再起動：

ollama pull nomic-embed-text
systemctl restart ollama

修正5：Active Memoryの一時的な無効化（本番環境向け）

タイムアウトが本番環境をブロックしている場合は、ブロッキングリコールを無効化：

"active-memory": {
  "enabled": false
}

または非ブロッキングモードに制限：

"active-memory": {
  "config": {
    "blockingMode": false,
    "asyncRecall": true
  }
}

修正6：メモリバックエンドのヘルスチェック

メモリバックエンドの接続性とインデックス状態を検証：

# Check memory backend status
openclaw memory status

# Verify embedding model availability
ollama list | grep qwen3-embedding

# Test memory search latency manually
openclaw memory search "test query" --verbose

🧪 検証

修正適用後の検証手順

ステップ1：詳細ログとトレースログを有効化

/verbose on
/trace on

ステップ2：Active Memoryリコールをトリガー

メモリリコールがトリガーされるはずのメッセージを送信：

what was my last message to you

ステップ3：タイムアウトが発生しないことを確認

期待される出力（成功）：


🧩 Active Memory: completed 2341ms message 87 chars
🔎 Active Memory Debug: retrieved summary "User asked about..."

期待されるゲートウェイログ：


active-memory ... done status=success elapsedMs=2345 summaryChars=87

ステップ4：フェイルオーバーがトリガーされていないことを確認

以下の отсутствиеを確認：


embedded_run_failover_decision ... failoverReason=timeout

ステップ5：診断コマンドを実行

openclaw memory test --mode recall --verbose

期待される出力：


Memory recall test: PASS
Retrieval latency: 1243ms
Generation latency: 892ms
Total: 2135ms (within timeout budget)

ステップ6：メモリバックエンドの健全性を確認

openclaw memory status

期待される出力は以下の示す内容：

  • backend: memory-core
  • indexed: true
  • embedding: qwen3-embedding (or configured model)
  • status: healthy

⚠️ よくある落とし穴

  • タイムアウトがエンベディングレイテンシに近すぎる: timeoutMsを典型的なエンベディング検索時間よりわずかに高く設定すると、LLM生成の予算が残されません。合計タイムアウトが両フェーズ plus 20%のバッファをカバーすることを確認してください。

  • Ollamaモデルのプリロード忘れ: 初回リクエスト時、Ollamaはエンベディングモデルをダウンロードしてロードするため、大きなレイテンシが発生します。常にモデルをプリロードしてください：

    ollama pull ollama/gemma4:e4b
ollama pull qwen3-embedding

  • リモートOllamaでのネットワークレイテンシ: OllamaがリモートホストまたはDockerコンテナで実行されている場合、ネットワークレイテンシがエンベディング検索時間に加算されます。ローカルOllamaを使用するか、タイムアウトを2〜3倍 增加させてください。

  • メモリインデックスの未構築: メモリバックエンドにインデックス付きコンテンツがない場合、リコールパスは空の結果に対してエンベディングクエリを実行し続ける可能性があり、予期しないレイテンシが発生する可能性があります。タイムアウトのトラブルシューティング前にインデックス状態を確認してください。

  • ブロッキングモードの上書き: 一部の設定やプラグインは、ユーザーの設定に関係なく blockingMode: true を強制する可能性があります。以下を確認してください：

    openclaw config get active-memory.blockingMode

  • Discord DMの特殊性: この問題はDiscord DMコンテキストで観察されました。他のプラットフォーム（Slack、Teams、ターミナル）では、ゲートウェイ実装の違いにより、異なるタイムアウト動作が発生する可能性があります。

  • バージョンの不一致: 問題は2026.4.12で報告されましたが、26.4.14も言及されています。クライアントとゲートウェイが同じバージョンであることを確認してください。タイムアウト処理はバージョン間で変更されている可能性があります。

  • 同時実行されるメモリ操作: 複数のメモリ操作（インデックス作成、検索、リコール）が同時に実行されている場合，它们がエンベディングモデルリソースを競合する可能性があります。メモリ操作をキューに入れるか、 dedicated エンベディングインスタンスを使用してください。

🔗 関連するエラー

  • embedded_run_failover_decision: Active Memoryのブロッキングリコールからembedded runコンテキストへのタイムアウト伝播によってトリガーされたフェイルオーバー判断。

  • memory.search.timeout: メモリバックエンドの検索操作がタイムアウトしきい値を超過（独立して発生、またはActive Memory障害の一部として発生）。

  • embedding.model.not_found: 設定されたエンベディングモデル（qwen3-embedding）がOllamaで 利用不可で、同期フォールバックの遅延がタイムアウト前に発生。

  • active-memory.summary_chars=0: Active Memoryが完了したがゼロ文字を生成。要約フェーズがスキップされたか、静かに失敗したかを示します。

  • gateway.active_memory.done.status=timeout: Active Memory操作がタイムアウトステータスで完了したことを示すゲートレベルステータス。status=successまたはstatus=errorとは異なります。

  • llm.context.window.exceeded: メモリリコールサマリーが後続のリクエストに含まれる場合にコンテキスト制限を超過する可能性があり、maxSummaryCharsの誤設定に関連。

  • 履歴的情報：v2026.3.x メモリバックエンドの回帰: 以前のバージョンでは、バックエンド初期化によるメモリリコールレイテンシの問題が報告されていました。アップグレード後に新鮮なインデックス再構築ことを確認してください。

エビデンスとソース

このトラブルシューティングガイドは、FixClaw Intelligence パイプラインによってコミュニティの議論から自動的に合成されました。