Concepts
利用状況 / 変動原価トラッキング
利用状況 / 変動原価トラッキング
定義
通話ごとの外部サービス利用量 (Twilio 通話料・Scribe ストリーム時間・TTS 文字数・Claude token 数等) をテナント別に計測・集計し、Admin UI で透明に開示する仕組み。変動原価・固定原価どちらの請求モデルも選べる設計の基盤となる。
現在の理解
計測メトリクス (FR-US-1, §3.9)
usage_records テーブルに通話ごとに以下を記録:
- 通話時間 (秒)
- Twilio 通話料 (Twilio 側 API / CSV で算出)
- ElevenLabs Scribe 使用時間 (ストリーム ms 単位)
- ElevenLabs TTS 生成文字数
- Claude 入力/出力 token 数 (対話 + 構造化の別で)
- Media Streams 通信時間
集計 (FR-US-2)
usage_aggregates テーブルでテナント別日次・月次を自動生成。estimated_cost_jpy 列に単価マスタ適用後の概算コストを保持。
UI (FR-US-3〜6)
- Admin アプリで時系列グラフ・数値表示
- 変動原価の概算値を表示
- tenant_admin は自テナント分を閲覧可能 (§3.10 ACL)
- CSV エクスポートで請求業務用データを出力
リスクとの関連
§11.3 で「変動原価がスケール時に想定超過」が 高 リスクとされ、対応策は「利用状況ダッシュボードで早期発見 + 単価交渉」とされる。つまりこの機能自体がリスク緩和の中核。
論点
- 単価マスタの更新頻度・責任: 各ベンダー (Twilio / Scribe / TTS / Claude) の単価変動にどう追従するか。自動取得 or 手動更新
- Twilio 通話料の取得タイミング: Twilio API で完了後に取得するか、CSV で月次突合か。リアルタイム表示の粒度が変わる
- 概算値 vs 実請求値の乖離:
estimated_cost_jpyはあくまで概算。実請求との差異許容範囲を定義する必要 - 固定原価プラン時の意味:
tenants.planがvariable | fixed | hybridのいずれでも計測自体は同じ。表示時の見せ方 (割引適用後・上限到達時等) をどうするか
根拠となる資料
関連する entity
未解決の問い
- 単価マスタの管理・更新フロー
- Twilio 通話料のリアルタイム取得可否
- hybrid プラン (固定 + 従量) の具体定義
- テナント自身による閲覧時のデータ鮮度 SLA
更新メモ
- 2026-04-19: v3.0 要件定義書から初版作成