Dispatcher (転送先采配)

定義

通話をどのエージェントにエスカレーションするかを決定する機能・役割。カケトクでは「AI 自動采配」「管理者オーバーライド」「AI 提案 + 承認ワークフロー」を段階的に提供する。法律事務所特有の「AI の勝手判断は怖い」という感覚に、人間の介入余地を確保する UX で応える。

現在の理解

段階的なロードマップ (§3.5, §12.5)

フェーズ	機能
MVP (Phase B)	FR-DP-1: AI 自動采配 (Claude のツール呼び出し)
MVP (Phase B)	FR-DP-2: 管理者オーバーライド (live transcript 画面のボタン)
v1.1 (Phase E)	FR-DP-3: Web 采配 UI (進行中セッション + 候補者状態 + D&D)
v1.1 (Phase E)	FR-DP-4: AI 提案 + 承認ワークフロー (5 秒表示 → 介入なければ自動実行)
v1.1 (Phase E)	E-3: スキルベースルーティング (案件種別 × スキル × 負荷)
v1.1 (Phase E)	E-4: 時間帯・曜日別ルーティングルール

補助要件

FR-DP-5: 采配操作は全て audit_logs に記録
FR-DP-6: 候補者リスト・ルールはテナント単位で定義可能
ユーザー (users テーブル) に skills TEXT[] を持たせて Dispatcher がスキルベース采配に使う

AI 自動采配の仕組み

Claude のツール呼び出しでエスカレーション先を決定。ツール定義にテナント別のルール (スキルベース・負荷分散・時間帯) を含める。エスカレーション判定時、Backend は Twilio REST API (POST /Calls/{CallSid}) で TwiML を更新し <Dial> で Zoom Phone へ転送。

論点

AI 提案 + 承認ワークフローの 5 秒介入窓の妥当性: 長すぎると発信者を待たせ、短すぎると介入できない。実運用での調整必要
AI 対話パイプラインの選択に影響: Dispatcher の細粒度制御を重視する場合、ConversationRelay より自前パイプラインに倒れる可能性が高い (§5.3.2)
管理者の認知負荷: 全セッションを見張る UI は情報過多になりやすい。優先度・候補者 online 状態・案件重要度の見せ方が鍵
スキルベースルーティングの定義方法: スキルタグの粒度、案件種別と候補者スキルのマッチングロジックは未決