Syntheses
AI 対話パイプライン: ConversationRelay vs 自前パイプラインの比較
AI 対話パイプライン: ConversationRelay vs 自前パイプラインの比較
問い
カケトク MVP の AI 対話パイプラインとして、Twilio ConversationRelay (候補 A) と 自前パイプライン (候補 B) のどちらを採用すべきか。Phase A (PoC) で何を測り、何をもって意思決定するか。
結論
Phase A PoC 完了まで未確定。暫定方針は「自前パイプライン (候補 B) に倒れる可能性が高い」。
根拠:
- Dispatcher (§3.5) で「AI 提案 + 5 秒介入窓」「管理者手動オーバーライド」等の細粒度な割り込み・再ルーティング制御が要件化されている
- 要件定義書 §5.3.2 自身が「Dispatcher 機能や細かいフロー制御が重要視される場合、B に倒れる可能性が高い」と明記
- カケトクの差別化軸 (法律事務所向けの介入余地を残した UX) が Dispatcher 側に寄っている
ただし、PoC で A と B を並行実装し、レイテンシと実装工数の差が想定超過なら A を採る判断は残る。
根拠
- カケトク 要件定義書 v3.0 §5.3.2 (AI 対話レイヤー)
- ai-dialogue-pipeline 概念ページ
- dispatcher 概念ページ (細粒度制御要件の出所)
- server-centric-architecture (TwiML 自社管理の原則)
解釈
両候補の特性整理
| 観点 | A: ConversationRelay | B: 自前パイプライン |
|---|---|---|
| 実装工数 | 小 (Twilio マネージド) | 大 (Media Streams → Scribe → Claude → TTS を全て自前組立) |
| レイテンシ | 最適化済 (Twilio 内部で最短経路) | 要実装チューニング。Scribe + Claude + TTS の合計 1.5 秒以内 (NFR-PF-1) を自前達成 |
| 割り込み制御 | Twilio 側に依存 (仕様に従う) | 完全自前制御 (barge-in / 中断検知を細かく定義可能) |
| Dispatcher 連携 | ツール呼び出し結果を Twilio が解釈して反映 | Backend が直接判定 → TwiML 更新 → 転送まで一気通貫 |
| LLM 選択 | Claude (Twilio 対応) | 任意 (Claude Opus/Sonnet/Haiku の使い分け、将来の他 LLM 差し替えも可) |
| STT/TTS 差し替え | Twilio 内部 (制御小さい) | 自由 (Scribe → Deepgram/whisper/Azure 等への差し替えが要件で明記されている) |
| ログ・監視 | Twilio ログ依存 | Backend で構造化ログを自在に記録 (audit_logs / usage_records) |
| 可搬性 | Twilio 依存強い | Twilio 依存を telephony 層に限定できる |
Phase A で測るべき指標
PoC 成果物 A-3 (Claude + TTS で AI 一次対話) と A-5 (転送後 Media Streams 継続) で 両候補を並行試作 し、以下を実測:
- E2E レイテンシ: ユーザー発話終了 → AI 発話開始まで (NFR-PF-1: 1.5 秒以内)
- 割り込み検知精度: ユーザーが AI の発話中に話し始めた場合の barge-in 動作
- Dispatcher 統合容易性: AI のツール呼び出し → TwiML 更新 → Zoom Phone 転送の 1 連のフロー実現コスト
- 実装工数: A と B それぞれの PoC 実装で要した人日
- 透明性: エラー原因の切り分け容易性 (Twilio 側 vs 自前コード vs 外部 API)
- コスト: ConversationRelay 独自の料金 vs 各要素 (Scribe + Claude + TTS) 合算
意思決定ルール (暫定)
- A を採用: B のレイテンシが 1.5 秒を大きく超え、A なら達成できる場合
- B を採用: A で Dispatcher の細粒度制御が不可能 or 実装迂回コストが大きすぎる場合 / A と B のレイテンシ差が小さい場合
- ハイブリッド検討: 定型応対は A、Dispatcher 発動セッションは B など。ただし PoC 段階では避ける (複雑化)
要件との対応
- NFR-PF-1 (AI 応答 1.5 秒以内) が最大の制約。ここが達成不能なら根本見直し
- §11.3 の「Media Streams + AI + TTS パイプラインのレイテンシ」は 高リスク 扱い。PoC で実機測定必須
不確実性
- ConversationRelay が Dispatcher ツール呼び出し結果の TwiML 更新にどこまで対応するか、公式仕様の細部は未調査
- Scribe v2 Realtime の実測レイテンシ (committed 配信までの 300ms 目標) が達成できるか未検証
- Claude (Sonnet/Opus/Haiku) のどのモデルが対話品質とレイテンシのバランスで最適か未検証
- TTS 生成の streaming ぶつけ方 (最初のフレーム到達までの時間) の実測値が無い
- barge-in 検知の実装難度は B で顕著。VAD (Voice Activity Detection) の追加要否
次のアクション
- Phase A 成果物 A-1〜A-7 で A と B の両方を最小構成で実装し実測 する (当初計画に両方測定を明記)
- 実測データが揃った段階で本 synthesis を更新し、最終決定を
結論に反映 - 決定後、ai-dialogue-pipeline 概念ページの「2 つの実装候補」を確定版に更新し、棄却された候補を
superseded扱いで残す - open-questions.md の最重要項目から外し、追跡中に降格
- Phase B 実装で採用側の実装詳細 (割り込み制御ロジック等) を追加の concept / synthesis 化