Documentation Index
Fetch the complete documentation index at: https://docs.shannon.run/llms.txt
Use this file to discover all available pages before exploring further.
概要
Daemon WebSocket API は、Daemon クライアントがリアルタイムでメッセージを受信・処理するための永続的な双方向接続を提供します。クライアントがポーリングする REST API とは異なり、WebSocket 接続により Shannon は受信メッセージ(Slack、LINE、またはシステムイベントから)を接続済みの Daemon に直接プッシュできます。 このプロトコルの中核は Claim ベースのメッセージディスパッチモデルです。Shannon は対象となるすべての接続にメッセージをブロードキャストし、Daemon が排他的処理権を競い合ってから応答します。エンドポイント
認証
認証は WebSocket アップグレードの前に、REST Endpoint と同じミドルウェアで実行されます。| 方式 | ヘッダー |
|---|---|
| JWT Bearer | Authorization: Bearer <token> |
| API Key | X-API-Key: <key> |
接続ライフサイクル
接続パラメータ
| パラメータ | 値 |
|---|---|
| Ping 間隔 | 20s |
| Pong タイムアウト | 60s |
| 最大メッセージサイズ | 64 KB |
| 書き込みタイムアウト | 10s |
| 読み書きバッファ | 4 KB |
メッセージエンベロープ
すべてのメッセージ(双方向)は統一されたエンベロープ形式に従います:| フィールド | 型 | 説明 |
|---|---|---|
type | string | メッセージタイプ識別子 |
message_id | string (UUID) | 一意のメッセージ識別子(connected および disconnect では省略) |
payload | object | タイプ固有のデータ |
サーバーからクライアントへのメッセージ
connected
WebSocket 接続の確立直後に一度だけ送信されます。
message
処理のためにディスパッチされたインバウンドメッセージ。これは主要なメッセージタイプで、Channel Webhook(Slack、LINE)またはシステムイベントからのメッセージを伝達します。
MessagePayload フィールド
| フィールド | 型 | 説明 |
|---|---|---|
channel | string | 送信元 Channel タイプ:"slack"、"line" など |
thread_id | string | 会話のスレッド識別子 |
sender | string | 送信者識別子(メール、ユーザー ID など) |
text | string | メッセージ内容 |
agent_name | string | 処理対象の Agent |
timestamp | string (ISO 8601) | メッセージ受信時刻 |
system
Shannon からのシステムレベル通知。
claim_ack
クライアントの claim リクエストへの応答。Claim が許可されたかどうかを示します。
| フィールド | 型 | 説明 |
|---|---|---|
granted | boolean | true の場合、このクライアントに排他的処理権が付与された |
クライアントからサーバーへのメッセージ
claim
メッセージの排他的処理権を要求します。同一メッセージを Claim できるのは 1 つのクライアントのみです。
progress
Claim 済みメッセージの処理中にハートビート/進捗更新を送信します。Claim のリースが延長され、タイムアウトを防ぎます。
reply
Claim 済みメッセージの処理結果を送信します。Shannon はこれを送信元 Channel(Slack、LINE など)にルーティングします。
ReplyPayload フィールド
| フィールド | 型 | 説明 |
|---|---|---|
channel | string | 送信先 Channel タイプ |
thread_id | string | 返信先のスレッド |
text | string | 応答内容 |
format | string | 出力形式:"text" または "markdown" |
disconnect
接続をグレースフルに閉じます。
Claim フロー
Claim フローは分散メッセージ処理の中核プロトコルです。複数の Daemon が接続されていても、各メッセージが 1 つの Daemon のみで処理されることを保証します。メッセージディスパッチ
メッセージが到着すると(Channel Webhook またはシステム経由)、Gateway は
tenant:user でインデックスされたすべての対象 WebSocket 接続にメッセージをディスパッチします。アトミック解決
Gateway が Redis でアトミックに Claim を実行します(
SETNX)。最初のクライアントが獲得し、他のクライアントは {"granted": false} を受信します。Claim メタデータ
メッセージが Claim されると、Gateway は Redis にメタデータを保存します(TTL 60 秒):| フィールド | 説明 |
|---|---|
conn_id | WebSocket 接続識別子 |
channel_id | 送信元 Channel ID |
channel_type | Channel タイプ(slack、line など) |
thread_id | 会話スレッド ID |
reply_token | プラットフォーム固有の応答トークン(該当する場合) |
timestamp | Claim タイムスタンプ |
workflow_id | 関連する Temporal Workflow ID(該当する場合) |
workflow_run_id | 関連する Temporal Workflow Run ID(該当する場合) |
保留中メッセージのメタデータの TTL は 90 秒です。Claim 済みメッセージが 60 秒以内に応答されない場合、Claim は期限切れとなり、メッセージは再ディスパッチの対象となります。
Hub アーキテクチャ
WebSocket Hub はすべてのアクティブな接続を管理し、以下のルーティング戦略を採用しています:- Tenant-User インデックス — 接続は
"tenant:user"キーでインデックスされ、ターゲットディスパッチを実現 - スレッドスティッキールーティング — 同一スレッド(
"channel_type:thread_id")からのメッセージは可能な限り同じ接続にルーティング - Redis バックドの Claim — 分散 Claim 解決により、複数の Gateway インスタンス間の一貫性を確保
応答ルーティング
Gateway が Daemon からreply を受信すると、Claim メタデータに基づいて応答をルーティングします:
- Workflow 応答 — Claim メタデータに
workflow_idが存在する場合、Gateway は関連する Temporal Workflow に Signal で通知します - Channel 応答 — それ以外の場合、応答は送信元 Channel にルーティングされます(Slack メッセージ、LINE Push メッセージなど)
エラーハンドリング
| シナリオ | 動作 |
|---|---|
| アップグレード時の認証失敗 | HTTP 401 を返却、WebSocket は確立されない |
| メッセージが 64 KB を超過 | 接続切断 |
| Pong タイムアウト(60s) | サーバーが接続を切断 |
| 書き込みタイムアウト(10s) | メッセージ破棄、接続が切断される可能性あり |
| Claim 期限切れ(60s TTL) | メッセージは再ディスパッチの対象 |
| 不正な JSON | メッセージ無視 |
次のステップ
Channels API
Slack と LINE の Channel 統合を管理
ストリーミング
Server-Sent Events によるタスクストリーミング