【ITニュース解説】What is the OpenClaw (Moltbot/Clawdbot) heartbeat feature?

OpenClawというシステムは、コンピュータのローカル環境における自動化を効率的に行うために開発された。これは、自分のマシンを常に監視し、システムの状態変化（ドリフト）を検知し、問題が大きくなる前に対応することを目指している。このシステムの中心的な機能が「ハートビート」と呼ばれるものだ。このハートビートは、単なる機器の動作確認だけでなく、多層的な判断プロセスを経てシステムの状態を把握し、適切な行動を決定する重要な役割を担う。

OpenClawのハートビートの根幹にあるのは、「安価なチェックをまず行い、高度な人工知能（大規模言語モデル、LLM）のような複雑な判断は本当に必要な場合にのみ利用する」という原則だ。このアプローチは、システムの運用コストを抑え、より予測可能な動作を実現し、不必要なLLMの利用を減らすために非常に効果的である。まず、CPUの負荷、ディスクの空き容量、実行中のプロセス、外部APIの応答状況など、瞬時に、かつ客観的な結果が得られる決定論的なチェックを優先的に実行する。これらのチェック結果が、事前に定められたルールやポリシーの範囲内にあるか評価し、それでも状況が曖昧で判断が難しい場合にのみ、LLMによる詳細な分析や判断を行う「エスカレーション」の段階に進む。

このハートビート機能は、実行時に五つの段階からなるループとして動作する。まず、スケジューラが一定間隔（例えば15秒、30秒、60秒など）でハートビートの「刻み」を発生させる。次に、プローブランナーが、システムの様々な状態を調査する決定論的なプローブ（簡単なチェック）を実行する。これらのチェック結果は、ポリシーエンジンによって評価され、システムの状態が「正常」「劣化」「危険」といったカテゴリに分類され、その重要度が計算される。その結果に基づき、エスカレーションゲートがLLMや専用のツールを用いた複雑な判断が必要かどうかを決定する。最後に、アクションディスパッチャが、必要に応じてアラートを送信したり、問題の修復タスクを開始したり、あるいは何もせずに様子を見たりといった対応を行う。

ハートビートが送信するデータは、例えば以下のような形式となる。送信元エージェントのID、今回のハートビートに固有のID、発生日時、そして「プローブ」として取得されたCPU負荷、ディスク空き容量、メールキューの深さ、APIの応答ステータスなどの具体的な数値や状態が含まれる。さらに、ポリシーエンジンによる評価結果として「状態（例：劣化）」や「理由（例：ディスク空き容量が警告値を下回った）」も含まれる。LLMによる判断が必要だったか、その信頼度はどの程度かといった情報も含まれる場合がある。このデータ形式は、後の処理の安定性を保つため、厳格なスキーマ（定義）に従うことが重要だ。

システムが確実に動作するための主要な原則は、決定論的なプローブの結果がシステムの「一次的な真実」として扱われること、ポリシーエンジンの出力が再現可能でテスト可能であること、そしてLLMの使用は控えめにし、利用は監査可能で厳格なゲートによって制限されることである。

「安価なチェックをまず行う」という実装では、各チェック項目が低レイテンシー（応答時間が短い）、低コスト（LLMのトークン消費がない）、決定論的（同じ入力に対して同じ出力）、そしてデフォルトで副作用がないことを満たす必要がある。典型的なプローブの種類としては、プロセスの稼働状況やメモリの使用量といったローカルシステムの状態、ディスクの空き容量やファイルのアクセス権などのI/O健全性、連携するAPIのステータスコードや応答時間といった統合システムの健全性、キューの遅延や再試行回数などのタスクの健全性、認証情報の有効期限といった前提条件の確認などが挙げられる。

LLMのようなモデル推論へのエスカレーションは、決定論的なロジックだけでは安全に判断できない場合にのみ行う。エスカレーションは明確なゲートとして定義されるべきだ。良いエスカレーションの例は、APIは正常と報告しているがビジネス上の重要な指標が急落しているような矛盾した信号がある場合や、これまでに経験のない新しい種類のエラーが複数発生している場合などである。一方で、些細な警告イベントごとや、既知の対処法がある単なる閾値の超過、少し待てば落ち着くような高頻度で状態が変動する場合は、LLMを呼び出すべきではない。

システムの運用において、状態が頻繁に変動し、誤ったアラートが大量に発生する「アラートのバタつき」は大きな問題となる。これを防ぐため、OpenClawでは、システムの健全性を「正常」「劣化」「危険」「回復中」といった状態を定義し、状態機械として設計する。各状態間の遷移は、例えばディスク空き容量が15%を下回ったら「劣化」に遷移するといった明確な「エントリ閾値」と、ディスク空き容量が20%を3回連続で上回ったら「正常」に戻るといった「終了閾値」を定める。また、デバウンス（N回連続で同じ状態が観測されたら遷移する）や、一度アクションを実行したら一定期間は同じアクションを繰り返さない「アクションクールダウン」を設定することで、ノイズによる不要なアラートや処理を防ぎ、システムの安定性を保つ。

ハートビート機能のAPI設計では、明示的で、可能であれば冪等性（同じ操作を複数回実行しても結果が変わらない性質）を持つように心がけるべきだ。例えば、ハートビートイベントを取り込むAPI、特定のエージェントの最新の状態を取得するAPI、オペレーターがアラートを確認したことを示すAPIなどが考えられる。特に「ポリシーシミュレーション」エンドポイントは非常に重要で、本番環境で実際に問題が発生する前に、サンプルデータに対してポリシーがどのように動作するかを事前に検証できるため、意図しない動作を未然に防ぐことができる。

ハートビートは自動的にアクションをトリガーする場合があるため、セキュリティは非常に重要である。最低限の対策として、ハートビートのデータが改ざんされていないことを保証するための署名、各エージェントが持つ権限を最小限に制限するトークン、実行可能なポリシーやアクションを事前に許可されたものに限定するリスト、修復作業を隔離された環境で行うサンドボックス化、そしてすべての状態遷移やアクションを記録する監査証跡の実装が必須となる。LLMが判断に関わる場合、その出力は無信頼なものとして扱い、ツールを呼び出す際には、スキーマ（定義）とポリシーに対して検証を行い、実行前には決定論的なガードチェックを挟む必要がある。要するに、ハートビートの検出は柔軟に行えるが、それに基づいて実行されるアクションには厳格な制約を設けるべきだ。

ハートビートシステムのデバッグや運用監視を効果的に行うには、特定の指標を計測することが重要となる。例えば、ハートビートの取り込みレート、遅延または欠落したハートビートの割合、プローブの種類ごとの応答時間、ポリシー評価にかかる時間、LLMへのエスカレーションが発生する割合、エージェントあたりのLLMトークン消費量、そして誤検知や見逃しのアラートの発生率などである。これらの情報は、システムの健全性を把握し、問題発生時に迅速に原因を特定するために役立つ。

システムを構築する際には、クロックスキュー（エージェントのタイムスタンプのずれ）、ネットワーク分断（一時的な接続不良後のイベント集中）、サイレントプローブ障害（「データなし」を「正常」と判断してしまう）、暴走修復ループ（アクションが同じアクションを繰り返しトリガーする）といった、エンジニアが見落としがちなエッジケースにも対処する必要がある。これらに対しては、タイムスタンプのずれの許容、シーケンス番号によるイベント順序付け、明示的な「不明な状態」の定義、アクションごとのクールダウン期間設定などの対策が有効である。

OpenClawのハートビート機能は、エージェントの健全性を規律ある制御ループとして扱うことで大きな価値を提供する。その成功パターンは、「決定論的なプローブを最初に、明示的なポリシー状態機械を次に、不確実性がある場合のみモデルエスカレーション」という明確な流れにある。この設計アプローチにより、低コストで、予測可能性が高く、安全な自動化を実現できる。ハートビートAPIを実装する際には、APIの契約定義、冪等性、ポリシーのシミュレーション、そしてテストの自動化に力を入れるべきだ。厳格な決定論的ルールから始め、徐々にLLMのようなモデル知能を追加していくことで、より信頼性の高いシステムを構築できる。信頼性は、まず制約から生まれ、次に知能が加わるのだ。