Concepts
サーバー集中型アーキテクチャ
サーバー集中型アーキテクチャ
定義
カケトク v3.0 の核となる設計原則。全通話音声を Twilio Media Streams (WSS) で Backend に集約し、TwiML を自社 Backend が動的生成して転送・再ルーティングを完全にコントロールする構成。v2.0 で計画されていた各エージェント PC への Desktop App (Tauri) 配布を廃止し、Web ブラウザ SPA に一本化する。
現在の理解
4 つのアーキテクチャ原則 (要件定義書 §2.1):
- 全音声はサーバーに集約 — Twilio Media Streams で双方向音声を Backend WebSocket に取り込み、ElevenLabs Scribe v2 Realtime で書き起こし
- TwiML は自社サーバーで完全コントロール — Twilio の Voice Webhook URL は常に自社 Backend を指す。AI 判定や管理者操作に応じて TwiML を動的生成
- Zoom Phone への転送は PSTN
<Dial>で実現 — エージェント側に特別なクライアント導入不要 - Web ブラウザだけで完結 — 管理者もエージェントも Web SPA にログインするだけ
v2.0 からの削除項目 (§5.5):
- Tauri v2 + Rust + Web UI の Desktop App 一式
- macOS ScreenCaptureKit / Windows WASAPI loopback の音声キャプチャ層
- Pluely / Meetily / OpenCluely / Natively 等の OSS 流用
- Apple Developer 署名 / Notarization / Windows コード署名
- Tauri Updater による自動更新機構
論点
- 検証根拠への依存: この設計は「Twilio
<Dial>で Zoom Phone 転送しても caller leg の Media Stream が継続する」検証結果に全面的に依拠する。Twilio 公式仕様として固定か、変更リスクがあるかは継続監視が必要 (§11.3 既知リスク)。 - AI 対話パイプラインの実装方式: Twilio ConversationRelay (マネージド) か自前パイプライン (Media Streams → Scribe → Claude → TTS) かは PoC 後に決定 (§5.3.2)。→ ai-dialogue-pipeline
- Cloud Run の WebSocket 60 分上限: 長時間通話で切断リスク。通常 60 分未満想定だが、超過見込み時は GKE / Compute Engine への分離オプションを設計で確保 (§11.1)。
- Media Streams 専用の Cloud Run サービスを分離可能な設計: 音声ストリーム処理は CPU バウンドになりやすいため (§4.3 NFR-SC-6)。
根拠となる資料
関連する entity
未解決の問い
<Dial>転送時の Media Streams 継続は公式仕様として保証されているか、実運用での例外ケースは- Cloud Run WS 上限 60 分を超過する通話の実際の発生頻度と、その場合の GKE 移行閾値
- Conference 方式 (warm transfer 用) への拡張コスト
更新メモ
- 2026-04-19: v3.0 要件定義書から初版作成