Sources
カケトク 要件定義書 v3.0 要約
カケトク 要件定義書 v3.0 要約
概要
株式会社 AI DOG が開発する SaaS「カケトク」の要件定義書 (Draft v3.0、2026-04-19 作成)。法律事務所・債務整理・士業系コールセンター向けに、AI 一次応対 + 人間エスカレーション + 構造化データ連携で受電負荷削減と架電効率化を実現する。v3.0 では技術検証結果を受けて サーバー集中型アーキテクチャ に大幅刷新し、v2.0 の Desktop App (Tauri) を完全廃止、Web ブラウザ SPA に一本化した。
重要ポイント
- v3.0 の核心的変更: Twilio
<Dial>による Zoom Phone 転送時に Media Stream が caller leg 側で継続し、CallSid/ConferenceSid で同一セッションとして追跡可能であることを検証。これにより Desktop App が不要になり、全音声処理をサーバー側に集約できる。 - 2 つのコアフロー: ① インバウンド (受電) — Twilio 着信 → AI 一次応対 → 必要時 Zoom Phone へ転送、② アウトバウンド (架電) — CSV リスト → AI 順次発信 → 有効リードは Zoom Phone へ転送。
- Dispatcher 機能の明文化: MVP では AI 自動采配 + 管理者手動オーバーライド。v1.1 で Web 采配 UI (ドラッグ&ドロップ) と AI 提案 + 承認ワークフロー (5 秒介入窓) を追加予定。
- マルチテナント前提: 200-400 名規模コールセンターを複数収容、累計数千同時通話を想定したインフラ設計。MVP は 1〜数社から段階的拡大。
- PostgreSQL RLS によるテナント境界の物理強制: Backend コードの不具合でもクロステナント漏洩が DB 層で阻止される設計。
- 変動原価トラッキング: Twilio / Scribe / TTS / Claude の通話単位メトリクスを
usage_recordsに記録し、Admin UI で透明開示 + 請求データ生成。 - MVP では PII マスキング非実装: ただし
transcript_processorinterface 等で差し替え可能な疎結合設計を明示的に確保。
主要な主張・観察
- 「サーバー集中型」への統一: 全音声は Twilio Media Streams (WSS) で Backend に集約され、ElevenLabs Scribe v2 Realtime で書き起こし。TwiML は自社 Backend が動的生成し、
POST /Calls/{CallSid}で転送・再ルーティングを制御する。- 意味: エージェント PC への配布物ゼロ、管理者もエージェントも Web ブラウザだけで完結。配布・自動更新・コード署名・ScreenCaptureKit/WASAPI・Tauri Updater が全て不要になり、Phase B (MVP) が v2.0 の 4 週間 → 3 週間に短縮。
- 会話連続性の相関キー:
session_id(UUID) +twilio_call_sid(caller leg 不変) の 1:1 マッピングで、AI → Agent A → Agent B の転送を跨いで transcript と構造化結果を紐付ける。 - 話者分離は物理的に行う: Scribe v2 Realtime はダイアリゼーション非対応のため、Twilio Media Streams の
inbound/outboundtrack を別々の Scribe セッションに送って物理分離。 - SLA 重視: 収益直撃業務なので稼働率 99.9% 最低・99.95% 目標、Cloud SQL HA、Cloud Run マルチインスタンス等で SPOF 排除。
- AI 対話パイプラインは 2 候補で PoC: (A) Twilio ConversationRelay のマネージド方式 vs (B) 自前パイプライン。Dispatcher の細粒度制御を重視する場合は B に倒れる可能性。
- 法律事務所特有のニーズへの配慮: 「AI 勝手判断は怖い」という感覚に対し、AI 提案 + 人手承認の介入余地を UX として用意する方針 (v1.1 で実装)。
根拠メモ
- §1.6: v2.0 からの主要変更点 (Desktop App 廃止の検証根拠)
- §2.1, §2.3: アーキテクチャ原則と主要コンポーネント表
- §2.4, §2.5: 会話連続性と相関キー設計
- §3.1〜3.11: 機能要件 (インバウンド / アウトバウンド / エスカレーション / Dispatcher / 書き起こし / Web UI / 構造化 / 利用状況 / ACL / CRM 連携)
- §4.1〜4.5: 非機能要件 (可用性 / パフォーマンス / スケーラビリティ / セキュリティ / コンプライアンス)
- §5: 技術スタック (Hono + Next.js + Cloud Run + Cloud SQL + Terraform/Terragrunt)
- §6.1, §6.2: 主要エンティティの DDL と RLS ポリシー例
- §10: PII マスキングロードマップ
- §11.3: 既知リスク (Scribe コスト・パイプラインレイテンシ・TwiML 実機挙動等)
- §12: Phase A〜E のロードマップ
- 変更履歴末尾: v1.0 → v2.0 → v3.0 の主要差分
既存 wiki への影響
- overview.md: 研究テーマがこの要件定義を中心に定まる。目的・範囲・仮説の項目を実値で上書きすべき。
- 新規概念ページ: server-centric-architecture / call-session-continuity / dispatcher / escalation-flow / ai-dialogue-pipeline / usage-cost-tracking / multi-tenant-rls / pii-masking-roadmap を作成。
- 新規エンティティページ: kaketoku (product) / ai-dog (運営会社) / twilio / elevenlabs / zoom-phone / claude-anthropic を作成。
- 既存結論との矛盾: なし (これが最初の source)。ただし v1.0/v2.0 の方針 (Desktop App あり) は v3.0 で
supersededと扱う。
未解決の問い
- AI 対話パイプライン: ConversationRelay vs 自前パイプラインの採用判断は PoC で実測後。Dispatcher の細粒度制御要件との兼ね合いで B になる可能性が高いが未確定。
- Cloud Run の WebSocket 接続時間上限 (最大 60 分) が長時間通話で問題になるかは負荷テスト待ち。超過時の GKE / Compute Engine 移行オプションを設計で確保とあるが、具体的閾値は未定。
<Dial>の Media Streams 継続挙動は Twilio 公式仕様として固定か、変更リスクがあるか継続監視が必要。- Scribe v2 Realtime の keyterm prompting (現状 batch のみ) の realtime 展開時期が不明。
- Zoom Phone の caller ID 表示問題 (Twilio 番号が見える) の運用対応は Agent 教育でカバーとあるが、顧客 UX 面での最終判断は未完。