Concepts
通話セッション連続性
通話セッション連続性
定義
AI → Agent A → Agent B と転送を跨いでも、同一通話を 1 つの論理セッションとして連続追跡する仕組み。Twilio <Dial> 転送時に caller leg の Media Stream が継続する性質と、CallSid が不変である性質を組み合わせて実現する。カケトク v3.0 で Desktop App を廃止できた技術的根拠そのもの。
現在の理解
相関キー設計 (§2.5)
| キー | 性質 |
|---|---|
session_id (UUID) | 1 通話に紐づく通し ID。全 transcript / escalation / 構造化結果の紐付け |
twilio_call_sid | caller leg の Twilio CallSid。転送前後で不変、session_id と 1:1 |
conference_sid | Conference 方式使用時のみ。Warm transfer 用 |
tenant_id | テナント識別。全テーブルに必須 (RLS 対象) |
campaign_id | 架電キャンペーン識別 |
転送方式の使い分け (§2.4)
<Dial>方式 (MVP 基本): AI → Agent A、Agent A → Agent B の cold transfer を TwiML 書き換えで実現。最もシンプル- Conference 方式 (将来オプション):
<Connect><Conference>+ 各参加者<Dial>で入室。Warm transfer (引継会話あり) が要件化した段階で拡張
仕組みの要点
- caller leg の Media Stream は転送後も attach されたまま → Bridge 後も両者の音声がサーバーに流れ続ける (
track="both_tracks") - TwiML 更新は
POST /Calls/{CallSid}で動的に書き換え可能 - 発信者音声と エージェント/AI 音声は物理的に別トラックで、別々の Scribe セッションに送って話者分離
論点
- Twilio 側仕様変更リスク:
<Dial>転送時の Media Streams 継続挙動は v3.0 の前提。仕様変更時は Conference 方式へのフォールバック経路を設計で確保 (§11.3) - Conference 方式への移行閾値: Warm transfer の顧客要求が出た時点で移行判断。MVP では割り切り (§11.1)
- CallSid の可搬性: Twilio 依存なので、将来他キャリア (Microsoft Teams Phone / 楽天 Link) 対応時の抽象化が必要 (§12.6)
根拠となる資料
関連する entity
未解決の問い
<Dial>転送で Media Streams 継続が切れるエッジケース (失敗パターン) の網羅- Conference 方式に切り替えた場合の transcript 統合コスト
更新メモ
- 2026-04-19: v3.0 要件定義書から初版作成