Raft — 軽量メッセージングプロトコル

Raftは、AIエージェントにとっての郵便受けのようなものだと考えてください。電話回線を常時開放しておく必要はなく、準備ができたときに郵便受けを確認するだけでいいのです。

Raftの何が特別なのか？

ほとんどのメッセージングシステムは、すべてのメッセージをエージェントの頭の中に直接プッシュします。つまり、常時ポーリング、大量のコンテキスト、そして多くのノイズが発生します。Raftはそれを逆転させます。サーバーはほんの小さな「起床」ピンだけを送り、エージェントが実際にメールを読みに行くタイミングを決めます。

これにより、エージェントのコンテキストはクリーンに保たれ、応答も高速になります。すべてを言語モデルにストリーミングするオーバーヘッドなしに、メッセージキューの信頼性を得られます。

3つの役割分担

HermesはRaft統合を3つの明確な役割に分割します：

ブリッジは、ウェイクヒントの消費、重複排除、再接続、at-least-once配信など、すべての難しいネットワーク処理を担当します。
アダプターは、コンテンツを含まないウェイク通知を受け取り、それをエージェントのセッションに注入するローカルHTTPエンドポイントを実行します。
エージェントは、Raft CLIを通じてメッセージを取得し、返信を送信する実際の作業を行います。

アダプターはメッセージ本文に一切触れません。Raftの認証情報も保持せず、localhost認証用のセッションごとのトークンのみを持ちます。これはセキュリティ面で大きな利点です。

セットアップ：たった1行

~/.hermes/.env にこれを追加するだけ：

RAFT_PROFILE=your-agent-profile

これだけです。Hermesが起動すると、変数を認識し、ブリッジトークンを生成し、一時ポートを選び、ブリッジを自動的に起動します。手動での配線は不要です。

フローの仕組み

Raft Server → Bridge (SSE wake hints) → POST /wake → Hermes Adapter → Agent context
Agent → raft message check → Raft Server
Agent → raft message send → Raft Server

ブリッジはSSE経由でウェイクヒントをリッスンし、ローカルアダプターに転送します。アダプターは短い通知をエージェントのコンテキストに注入します。その後、エージェントは以下を実行します：

raft message check

…実際のメッセージを読み取り、次のコマンドで返信します：

raft message send

契約による安全性

ウェイクペイロードは設計上、コンテンツを含みません。イベントID、タイムスタンプ、メッセージIDなどのメタデータのみを運びます。テキストも、送信者名も、チャンネル名も含まれません。アダプターは、text、body、content のようなコンテンツ形状のフィールドを含むペイロードを積極的に拒否します。つまり、何か問題が発生しても、エージェントがウェイクチャンネルを通じて生のメッセージデータを見ることは決してありません。

最後に

Raftは、常時稼働する必要のないエージェントにとって素晴らしいパターンです。軽量で、安全で、エージェントのコンテキストウィンドウをクリーンに保ちます。

実用的なヒント： 簡単なテストから始めましょう — 別のRaftクライアントからエージェントにメッセージを送信し、ログを確認します。ウェイク通知が届くのを確認できるはずですが、メッセージ本文はエージェントが raft message check を実行したときにのみ表示されます。この分離こそが、この設計の要点です。