16. OpenClawにおけるエージェント間通信の信頼性確保戦略
同期的な呼び出しが抱える耐障害性の問題
最も単純なエージェント間通信は、AがBを直接呼び出し、Bが応答を返すという同期的な流れです。しかし、この方式は、Bが一時的にダウンしていたり、ネットワークが不安定な場合、Aの処理全体が停止（ブロック）してしまうという致命的な欠陥を抱えています。
メッセージキューによる非同期通信への移行
信頼性の高いシステム設計では、この同期的な依存関係を排除し、メッセージキュー（Message Queue）を介した非同期通信に移行することが基本となります。これは、送信側（Producer）と受信側（Consumer）が互いの稼働状況に依存しない、疎結合な通信モデルを確立することを意味します。
OpenClawのワークフローにおいて、メッセージキューは「時間差」と「耐障害性」という二つの大きなメリットを提供します。
信頼性を高めるための3つの原則
メッセージキューを利用する際、以下の3つの原則を必ず設計に組み込む必要があります。
| 原則 | 目的 | 実装上の対応 |
|---|---|---|
| 1. 冪等性の保証 (Idempotency) |
同じメッセージが複数回処理されても、システムの状態が二重に更新されないようにする | メッセージに一意のトランザクションIDを付与し、処理開始時にDB等で既処理済みかチェックする機構を組み込む |
| 2. 永続化と再試行 (Persistence & Retry) |
メッセージが一時的に処理できなくても、失われないようにキューに保持し、一定回数再試行する仕組みを構築する | DLQ (Dead Letter Queue) を設け、再試行回数上限を超えたメッセージは手動調査用のキューに隔離する |
| 3. 状態同期の管理 (State Synchronization) |
メッセージの送受信だけでは不十分であり、処理の「進捗」を外部の共有ストア（例：Redis）で管理する | メッセージ受信時、まず共有ストアをチェックし、既に処理が完了している場合は、メッセージを破棄するロジックを組み込む |
メッセージの「順序保証」の理解
メッセージキューは、メッセージの順序を保証しない（At-Least-Once Delivery）場合があります。例えば、メッセージAとメッセージBが発行されたとしても、Bが先に処理されてしまう可能性があります。もし処理の順序が絶対的に重要な場合（例：アカウント作成 $\rightarrow$ プロファイル更新）、メッセージキューのトピックやパーティション設計を工夫するか、あるいは処理を同期的なAPIコールに戻すか、設計のトレードオフを理解する必要があります。
まとめ：非同期通信は「イベントの伝播」として捉える
エージェント間通信を「メッセージの送受信」として捉えるのではなく、「イベントの伝播（Event Propagation）」として捉え直すことが重要です。これにより、システムは障害や遅延に対して極めて高い耐性を持ち、真にスケーラブルな自動化基盤が実現します。
