ThunderPhoneは多数のモデルを同時に協調動作させ、モデル同士がミスを補正し合います。
高速LLMが参照するのは文字起こしだけ。
「こんにちは、Brentさん。ご用件をお聞かせください」
高速LLMと推論モデルでクロスチェック：3経路中2経路が一致。
「承知しました。つまり、賃貸ですね」
BBAは、モデルが音声プロンプトを理解し、難問に正しく答えられるかを検証します。最も高性能なStorm構成が、当社公開の評価セットで99.4%という最高記録を保持しています。
0.6% 誤り率
ThunderPhoneの結果は、上記リンクの公開評価データセットに基づいています。その他の公開スコア（Artificial Analysisのリーダーボード）は、比較の目安として掲載しています。
Vapi、Retell、Pipecat、LiveKitなどの音声AIプラットフォームでは、通話を動かすまでに、数多くの設定を自ら判断しなければなりません。ThunderPhoneでは、チューニングは私たちの仕事。スムーズな通話を実現するまでの手間は、できる限り少なくあるべきだと考えています。
これらすべてをThunderPhoneが自動でチューニング
Spark、Bolt、Stormから選択。
厳選し、実際の通話で検証済み。
振る舞いも、ポリシーも、ツールも。自然な言葉で記述。
決めるのは3つだけ。設定はそれで完了です。オーケストレーション、フォールバック、チューニングはすべて標準搭載。
用途ごとに最適なモデルを選び、組み合わせています。 OpenAI、Anthropic、Googleのフロンティアモデルとオープンソースモデルを連携させ、通話ごとに最高の性能を最適なコストで引き出せるようオーケストレーション。モデルの選定や調整を気にする必要はありません。
フロービルダーが必要になるのは、性能の低いシステムでは複雑なプロンプトに従えないからです。会話の各ステップがノードになり、それぞれを手作業で構築・保守しなければなりません。Stormなら、1つのプロンプトにまとめた詳細な指示に従えるため、ノードやエッジを気にする必要はありません。
1つの登録フローに6つのノード。プロンプト、ツール、遷移、失敗時の処理をノードごとに個別設定。
発信者に挨拶し、名前と電話番号を取得してください。登録前に同意を確認してください。これは必須です。請求について質問された場合は、以下の請求ポリシーに従ってください。すべての項目を確認した後に限り、enroll()を一度だけ呼び出してください。発信者が担当者との会話を希望した場合は、人間の担当者に転送してください。
作成・テスト・改善するのは1つのプロンプトだけ。分岐もその中に含まれます。
不明瞭な話し方、周囲の話し声、名前や数字、複数言語が混在する会話。ThunderPhoneは、他のシステムでは対応しきれない状況を前提に設計されています。
1つの文字起こしだけに頼らず、音声とテキストのシグナルを照合します。
ノイズ識別・低減モデルが音声信号をクリアに整えます。
周囲の会話がエージェントの応対に影響する前に識別します。
固有名詞、表記、数字、訂正内容を突き合わせて確認します。
必要に応じて、多言語対応の音声処理・音声生成パスへルーティングします。
エージェントの挙動を1つのルールに落とし込めない場合は、より強力な推論アプローチを用います。
音声AIには素早い応答が求められます。しかし、正確さが伴わなければ、ただ間違いを早く返すだけです。現在のLLMが信頼性を保つには、わずかな推論時間が必要です。ThunderPhoneは、レイテンシーと精度のバランスを取ります。
他社は理想的な条件下で500msのレイテンシーをうたっていますが、通常、実際の通話では2秒前後です。 実際の利用環境に即した条件でレイテンシーを測定しています。
AIベンダーではレイテンシーが突発的に跳ね上がり、通話が破綻することがあります。 ThunderPhoneはスタック全体をオーケストレーションし、こうした場合にはより高速な選択肢へフェイルオーバーします。
自動化された電話対応は、これまでストレスのたまる体験でした。技術革新のたびに改善されてきたものの、本当にスムーズだと言える水準には一度も届いていません。ThunderPhoneが、その常識を変えます。
「営業は1、サポートは2を押してください」。メニューにできるのは、振り分けだけ。
「営業」か「請求」と話し、あとはスロットパーサーが正しく拾うことを祈るだけ。
文字起こし、高速なLLMへの問い合わせ、音声での応答——各ステップは直前の結果頼み。
音声、テキスト、推論、ツール、ボイス、ガードレールをひとつのシステムに統合。