キャパシティとスケール

端的に言えば、同時通話は数千件、1日あたりの通話は数万件、月間では数十万件に対応します。プラットフォームは水平スケールするよう設計されています。このページでは、これらの数値が実際にどのような意味を持つのか、各プランティアの上限、そして想定外の事態を招かずに拡張する方法を説明します。

スケールを先回りして最適化しないでください。 ほとんどのアカウントは本番環境で同時通話100件未満です。ミッドマーケットの顧客でも同時500件に達することはまれです。ピークがどの程度になるか分からない場合は、まず開始し、計測し、後からスケールアップしてください。プランのアップグレードは簡単です。

上限の一覧

Finnごとの上限があるのは、1つのFinnがオーディエンスにとって1つの窓口として認識されるためです。1つのIDから数百件を超える同時発信を行うと、現実的でない通話量パターンが生じます。Finnごとの上限を超えて拡張するには、複数のFinnまたはナンバープールを使用してください。

「同時通話」の実際の意味

プラットフォームが「同時通話200件」と表現する場合、200件の会話が同時に進行していることを意味します。各通話は次の専用リソースを使用します。

• LLM推論インスタンス（会話の処理）
• TTSストリーミングインスタンス（音声オーディオの生成）
• STTインスタンス（発信先の音声の文字起こし）
• テレフォニーチャネル（実際の電話接続）

プラットフォームはこれらをそれぞれ独立してスケールします。プロビジョニングを意識する必要はなく、自動的に処理されます。

ピーク負荷の見積もり方

おおまかな試算をいくつか紹介します:

アウトバウンドキャンペーン

peak concurrent calls ≈ (calls per hour) × (avg duration in minutes) / 60

例: 発信1,000件、平均通話時間2分、4時間で実施 = 250件/時 × 2/60 = 同時実行ピーク約8。

インバウンド

peak concurrent calls ≈ (calls per hour at peak time) × (avg duration in minutes) / 60

例: あるクリニックで昼のピーク時に30件/時の着信、平均通話時間4分 = 30 × 4/60 = 同時実行ピーク2。

実際の同時実行ピークが想像より低いことに多くの企業が驚きます。多忙な受付担当のFinnでも、同時実行が10〜20を超えることはめったにありません。

並列デプロイで数値が跳ね上がる場合

並列デプロイ (Enterprise) は別物です。大量のリストを短時間で消化するため、同時発信を意図的に最大化します。

例: 連絡先50,000件、平均通話90秒、4時間で完了させたい = 50,000件 / (4 × 3600/90) = 同時実行平均約313、ピークはその2倍で約625。

並列デプロイでは、プラン側の容量と番号プールの容量の両方が必要です。単一の番号では、物理的に同時アウトバウンド通話を約50件までしか処理できません (キャリア側の制限)。

番号プールと同時実行容量

高い同時実行数のアウトバウンドでは、制約となるのはプラットフォームの容量ではなく電話番号であるのが一般的です。

番号あたりの上限

これらはキャリア側の制限であり、プラットフォーム側の制限ではありません。上限を超えると、着信側キャリアによって通話が拒否されます。

プールのサイズ設定の目安

pool size ≈ peak concurrent calls / per-number limit × 1.5 (safety margin)

例: 米国向けに同時500件の発信を計画する場合 = 500/50 × 1.5 = プールに15番号。

必要と思う数より多めに番号を購入してください。番号は安価です (月額$1〜$5) が、プール不足による失敗コールは高くつきます (応答機会の損失に加え、「この番号にはおつなぎできません」エラーによるブランド毀損)。

スケール時のレイテンシと品質

プラットフォームのレイテンシ目標は、ユーザーの発話終了からFinnの応答開始まで800ms未満です。これは1件の通話でも同時1,000件でも変わりません。システムはスループットだけでなく通話ごとの品質も含めて水平にスケールする設計になっています。

スケール時に品質を低下させる要因:

レート制限

同時通話数の上限に加え、プラットフォームは以下にリクエストレート制限を適用します:

レート制限された応答は 429 Too Many Requests を返し、再試行のタイミングを示す Retry-After ヘッダーが付きます。

マルチリージョンとデータレジデンシー

レイテンシが重要なユースケースやコンプライアンス要件に応じて、アカウントを稼働させるリージョンを選択できます。

アカウント作成時にリージョンを選択します。後から変更するにはデータ移行が必要です。 EU の顧客を対象とする場合は、サインアップ時に EU を選択してください。

データが選択したリージョンの外に出ることはありません。録音、文字起こし、オーディエンスレコード、通話後分析はすべてリージョン内に保持されます。

バースト容量

プランの上限を一時的に超える必要が生じる場合があります (選挙アウトリーチ、製品ローンチ、気象イベント対応など)。

• 事前承認バースト — 想定ピークを添えて 48 時間前までにサポートへご連絡ください。容量を確保し、ティアを超えた実使用分のみが課金されます。
• ソフトバースト — プランの同時実行上限を最大 20% 超える短時間 (15 分未満) のバーストが許可されます。継続的なバーストはスロットリングされるため、多用しないでください。

上限に達した場合

同時通話数の上限を超えると、新しい発信通話は失敗せずにキューに入ります。通話が終了するとキューが処理されます。

着信の場合、上限を超えると新しい着信通話には「通話中」トーンが再生されるか、フォールバックのボイスメールに転送されます (番号ごとに設定可能)。

いずれの場合も、ダッシュボードに黄色の警告バナーが表示されます。頻繁に表示される場合はプランのアップグレードを検討してください。

本番環境でのパフォーマンスベンチマーク

大規模に運用している顧客の実測値 (匿名化済み):

想定数値がこの範囲内またはそれ以下であれば、プラットフォームは問題なく処理できます。最上段を超える場合は、キャパシティプランニングについて営業にお問い合わせください。

安全にスケールする方法

ステージ1 — パイロット（1日1〜50件）

• 単一のFinn、単一のデプロイメント。
• StarterまたはGrowthプランのトライアルで実行。
• 計測項目：成功率、完了率、成果あたりのコスト。

ステージ2 — 本番リリース（1日50〜1,000件）

• 同じFinn設定にモニタリングを追加。
• デプロイメントごとの支出上限を設定。
• 発信者番号を登録し、自動抑止を設定。

ステージ3 — スケール（1日1,000〜10,000件）

• 番号プールを追加（5〜15番号）。
• マルチFinnによるセグメント分けを検討（オーディエンスセグメントごとに異なるFinn）。
• デプロイメント失敗時のSlackアラートを設定。
• Scaleプランへ移行。

ステージ4 — 大規模（1日10,000件以上）

• 並列デプロイメント。
• より大きな番号プール（50以上）。
• 自社システムでのリアルタイム分析向けWebhookストリーム。
• 専任CSM＋SLA付きのEnterpriseプラン。

ステージ5 — 大規模スケール（1日10万件以上の通話）

• 専用インフラ（Enterprise）。
• レイテンシ最適化のためのマルチリージョン対応。
• カスタムレート制限、カスタム連携。
• スパイク計画についてはエンジニアリングに直接相談可能。

よくある質問

Q: 同時通話数の実際の技術的上限は？ A: 公表している数値はありません。5万同時通話を超える負荷テストを実施済みです。実際に到達する上限は、プラットフォームの容量ではなく、プランのティアまたは番号プールのサイズです。

Q: プラン上限を超えた場合、自動でアップグレードされますか？ A: いいえ — 想定外の請求につながるためです。プラットフォームは通話をキューに入れるか拒否し、警告を表示します。準備ができたら手動でアップグレードしてください。

Q: ピーク時間帯は通話料金が高くなりますか？ A: いいえ。料金は通話の時間帯にかかわらず、分単位の定額です。

Q: 複数のFinnをそれぞれ異なる同時通話数で実行できますか？ A: はい。各FinnにはFinnごとの上限があり、アカウント全体の上限はすべてのFinnで共有されます。同時100件のクオリファイアーと同時20件の受付担当を問題なく並行実行できます。

Q: 新しいデプロイメントはどれくらい早く増強できますか？ A: ほとんどのデプロイメントは、開始から2〜5分で目標の同時通話数に到達します。非常に大規模な増強（1分未満で1,000同時通話以上）は、事前にサポートとの調整が必要です。

次のステップ

• 電話番号 → 番号プール — スケールに向けたプールの設定方法。
• 請求 → — 各プランティアの料金。
• キャンペーンとデプロイメント → 並列デプロイメント — 高同時実行のアウトバウンド向け。