通話は自然だったのに、予約が誤って入った
AI電話エージェントがはっきり話し、適切に相づちを打ったからといって、業務まで成功したとは限りません。顧客名を誤って記録したり、対応していない日程変更を確定したり、人に引き継ぐべき依頼を自分だけで完了させたりする可能性があるためです。アウトバウンド通話では、発信組織と目的を明かさないことや、再連絡拒否の依頼を見落とすことも失敗です。会話の品質と業務完了の品質は異なります。
ThunderPhoneで最初に見るべきなのは、1分2セントという価格よりも失敗を扱う仕組みです。デプロイ前にはAI発信者で会話全体をシミュレーションでき、限定的な実通話で見つけた特定の失敗ターンはValidation exampleとして保存し、修正した下書きで再生できます。
ただし、Validationの失敗がデプロイを自動的に止めるわけではありません。結果を確認したうえでそのままデプロイでき、ダッシュボードのSuccess RateもAI採点に基づいています。 結局、運用者が失敗を収集し、人が業務結果を判定し、修正後に同じ状況を再実行する手順を作る必要があります。
登録から最初のシミュレーション確認までつなげましょう
最初の課題には、「ウェビナー出席の確認」のように結果を明確に判定できる業務が適しています。最初から営業フロー全体を任せると、どの指示に問題があったのかを見つけにくくなります。以下の入力と判定基準は、ThunderPhoneが性能を保証する公式テンプレートではなく、品質ループを始めるための編集例です。
- ThunderPhoneアプリに登録またはログインし、エージェントの下書きを開きます。役割、発信組織・連絡先番号と目的、必ず確認する値、禁止行為、再連絡拒否の処理、具体的な人への引き継ぎ手順をプロンプトに記載します。ThunderPhoneのプロンプティングガイドでは、転送番号やコールバックの約束など、エージェントが実際に実行できるhand-off経路を指定するよう案内しています。 Talkを押し、ブラウザのマイク権限を許可して、現在の下書きが応答することを確認します。シミュレーション前にコールバック担当者と確認担当者を決め、以下のフォローアップ依頼記録表も準備します。まだDeployはしません。TalkとSimulationは現在の下書きを対象に動作します。
- 支払い方法と最初のシミュレーション費用を準備します。Organization → Billing Settingsで支払い方法を登録し、最初のSimulation承認画面に表示される見積額をまかなえる組織残高をチャージします。シミュレーションでは、AI発信者と対象エージェントの両方の費用が組織残高から差し引かれます。電話番号を通じた実通話まで試すには、公式クイックスタートで案内されている最低US$3の前払い残高が必要です。続いてConfigでエンジン・言語・音声を選び、画面に表示されるオールインの分単価を記録します。
- エージェントビルダーでSimulationを開きます。最初の検証では、電話番号ではなくエージェントへの直接接続を選びます。通常ケースに加え、人の担当者を求めるケース、対応していない変更、再連絡拒否を含む例外ケースを入力します。実行前に、最大10分を基準に表示される見積費用を確認して承認します。AI発信者と対象エージェントの両方に利用料金が発生します。
- Call Historyで終了したシミュレーションを確認します。会話ログ、録音、自動評価、ツール呼び出しをあわせて確認します。組織名・連絡先番号・通話目的を明かしたか、氏名と出席可否が正確か、禁止された変更を確定していないか、人への依頼では折り返し番号と期限を確認したか、フォローアップ依頼記録表で担当者が割り当てられたか、再連絡拒否には謝罪して追加の説得をせず終了したかを、運用者が別途判定します。
- 内部の必須基準を満たした下書きだけをDeployします。発信者の識別、必須値の正確性、禁止行為の防止、人への引き継ぎ手順、再連絡拒否時の終了手順をすべて通過した場合にのみ、運用バージョンへ昇格させます。1つでも失敗した場合は、プロンプトを修正し、同じSimulationから再実行します。
最初の入力例
エージェントプロンプト: 「あなたは[組織名]のウェビナー出席確認担当者です。通話を始めたら、『こんにちは、[組織名]から[ウェビナー名]への出席可否を確認するためにお電話しています。当社の連絡先は[組織の連絡先番号]です』と、組織名・連絡先・目的を先に明かします。申込者の氏名と出席可否だけを確認します。支払い・割引・個人情報の変更を約束しません。相手が再連絡を望まないと言った場合は謝罪し、接続された再連絡拒否記録ツールがあれば、その連絡先を再連絡拒否として記録してから直ちに通話を終了します。記録ツールがなくても、追加の質問や説得をせず終了します。記録と回答が食い違う場合、または相手が人と話すことを求めた場合は、まず折り返し先の番号を読み上げて確認し、『担当者が確認した連絡先へ次の営業日までにお電話し直します』と案内します。その後に再連絡を拒否した場合は、コールバックの約束を取り消し、再連絡拒否の手順を優先します。その後は出席状況や時間を変更せず、会話を終了します。」
[組織名]、[組織の連絡先番号]、[ウェビナー名]、「次の営業日」は、内部テストのための編集例です。テスト前にすべての角括弧を実際の組織名・連絡可能な組織電話番号・通話目的に置き換え、コールバック期限は担当者が守れる値に設定してください。ThunderPhoneの米国向け発信ガイドには、発信者の識別と連絡先番号の提供があわせて記載されています。 実際の通話転送を試すには、組織が管理するテスト用のE.164形式の宛先番号をプロンプトに明記し、シミュレーション中に外部通話が発生しうることをあらかじめ確認する必要があります。
例外ケース: 「申込者が騒がしい場所から韓国語で氏名のつづりを2回訂正した後、対応していない出席時間の変更と人の担当者を求め、最後にもう電話しないでほしいと言う。」組織と目的を先に明かしたか、氏名を推測したり変更を確定したりしなかったか、再連絡拒否の依頼後に追加の説得をせず終了したかを確認します。再連絡拒否記録ツールが接続されている場合は、そのツール呼び出しも必須の判定項目です。
2セントは完了した通話の価格ではありません
公式の基本エンジン料金は、Sparkが2セント、Boltが5セント、Stormが9セントです。前払いの従量課金ですが、Supervisionを有効にするとSparkとStormでは1分あたり8セントが追加されます。これは人が聞くサービスではなく、2つ目のAIが各ターンで指示遵守を確認し、必要に応じて静かに介入するオプションです。音声・言語の経路、長いプロンプト、Stormの追加オプション、番号、電話網費用により最終料金は変わる可能性があります。
| 選択肢 | 基本料金 | まず比較する業務 |
|---|---|---|
| Spark | 2¢/分 | 出席確認のような短く定型的なフロー |
| Bolt | 5¢/分 | 一般的な応答品質と速度のバランスが必要なフロー |
| Storm | 9¢/分 | 長い指示と多数の例外を処理する必要があるフロー |
| Supervision | +8¢/分 | Spark・Stormで第2のAIによるターンごとの確認が必要なフロー |
シミュレーションも無料の複製通話ではありません。AI発信者はSpark料金で、対象エージェントは実際の設定に応じて計算されます。両方がSparkで追加オプションと電話網費用がなければ、エンジン料金の単純合計は1分あたり4セントですが、これは実際の請求額を保証する見積もりではありません。
価格は成功した業務1件あたりの原価で比較してください。
通話費とシミュレーション費用に、再通話、人への引き継ぎまたはコールバック、誤った予約と再連絡拒否の見落としを処理した費用を加え、実際に完了した予約または検証済みリード数で割ります。分単価が低くても、失敗や再通話が増えれば総原価は高くなりえます。
限定的な実通話では番号検証とCampaign設定まで必要です
ブラウザシミュレーションを通過しても、実際の電話経路まで検証されたことにはなりません。ThunderPhoneの米国デモ番号はインバウンドテスト専用のため、顧客に発信するテストではVoIPプロバイダーで保有する番号を接続し、往復検証を行います。
- Connections → VoIPでプロバイダーを接続します。Twilio・Telnyxなどの対応プロバイダーの認証情報を入力してConnect & Testを完了するか、手動SIP接続の場合はTest & Save Connectionを通過させます。
- Phone Numbers → Add number → Connect VoIP providerで保有番号を取り込みます。インバウンド確認とアウトバウンド権限確認を含む往復検証が終わり、番号が双方向で使える状態かを確認します。検証に失敗した場合は、まずプロバイダーの認証情報とSIP設定を修正する必要があります。
- 対象組織であれば、管理者のコンプライアンス責任確認を完了します。これは最初のキャンペーンまたはAPI発信前に求められる一度限りの手順ですが、この画面自体が実際の受信者同意、発信者識別、告知、再連絡拒否要件を検証するわけではありません。
- Engagement → Campaigns → New campaignを開きます。デプロイ済みエージェントと検証済みVoIP発信番号を選択し、
phoneまたはphone_number列のある連絡先CSVをアップロードします。最初のテストには、通話目的と同意が確認され、内部の再連絡拒否リストにない少数の連絡先だけを入れます。 - 再連絡拒否記録の担当者と完了基準を先に決めます。
以下は編集部が提案する運用手順です。通話前にCall History確認担当者と実際のコールバック担当者を指定し、共有シートまたはCRMに通話ID・確認した折り返し番号・依頼時刻・担当者・期限・状態・完了時刻を記録する欄を作ります。毎通話後、確認担当者が会話ログを読み、コールバック案件を登録・割り当てし、コールバック担当者が期限内に返信して、実際の接続結果と時刻を残します。未接続なら完了として閉じず、再試行状態にします。自動登録ツールを接続した場合は、実際のタスク作成と担当者・期限の保存まで確認する必要があります。
再連絡拒否はコールバックより優先されます。依頼が出たら保留中のコールバックを取り消し、内部除外リストに登録したうえで、次のキャンペーンCSVから番号が外れていることを確認します。「折り返します」という発話は受付にすぎません。実際の返信完了や依頼撤回の確認とは区別して記録します。 - 通話時間帯と再試行条件を決めます。製品は同時通話1〜10をサポートし、デフォルトは3ですが、最初は同時通話1にすることを編集例として推奨します。これは公式の性能保証値ではなく、失敗1件をすぐ確認するための保守的な開始値です。再連絡拒否や明示的な拒否には再試行しないよう運用基準を整え、見積費用に同意してStartを押します。
- 成功はCall Historyと内部除外リストであわせて確認します。検証済み番号から発信された通話が終了状態で記録され、会話ログ・録音・ツール呼び出しを確認できなければなりません。組織名・連絡先番号・目的を明かしたか、依頼記録表で約束したコールバックが実際に完了したか、または依頼が撤回されたか、再連絡拒否の依頼では直ちに終了し、記録ツールまたは指定運用者を通じて次の発信対象から除外したかまで確認して、電話網テストは完了です。
製品の確認画面は法的レビューの代わりにはなりません。
連絡先をアップロードする前に、通話目的と受信地域に適用される同意、発信者識別、AI・録音の告知、個人情報処理、再連絡拒否の基準を確認してください。対象国と通話種別が定まっていない場合、適用規則を1つに断定することはできません。
実通話の失敗ターン1つを回帰テストに変えましょう
Validation setsの実務的な価値は、実際の非シミュレーション通話で起きた問題の場面を固定して再実行できる点にあります。特定のエージェントターンを選ぶと、その時点までの会話コンテキスト、関連する発信者音声、実際の応答を取り込め、人が期待行動と許可するツール呼び出しを修正してActive exampleとして保存できます。
修正した現在の下書きで例を実行すると、Pass・Warn・Fail・Skipped・Errorの状態と通過率を確認でき、直前の実行でPassだった項目がFailに変わった回帰も確認できます。ただし、これは通話全体を最初からかけ直す検査ではありません。実際の電話網、変更されたCRM状態、長い会話で蓄積したすべての誤解まで、そのまま再現するものではありません。
- 限定的な実通話で業務結果を変えたターンを見つけます。発信組織や目的を明かさない開始、聞き間違えた氏名、禁止された約束、誤ったツール呼び出し、再連絡拒否後の追加説得、人への依頼を無視した応答や約束したコールバック手順から外れた応答など、具体的な失敗を選びます。
- そのターンをValidation exampleとして保存します。期待行動と許可する応答・ツール呼び出しを運用者が具体化し、Active状態にします。再連絡拒否のケースでは、謝罪、即時終了、接続済み記録ツールの呼び出しを判定項目に記載しますが、ツールのない運用ではCall History後の手動リスト反映を別途確認する必要があります。
- プロンプト修正後に例の状態をもう一度確認します。プロンプト変更によりその例がStale状態になった場合は、期待行動と許可する応答・ツール呼び出しが依然として適切かを確認し、再びActiveに切り替えます。完全なValidation runにはActive exampleだけが含まれるため、この確認を省くと、保存したばかりの失敗ケースが実行から外れることがあります。
- 現在の下書きでValidation runを実行します。新しい失敗がPassに変わったかだけでなく、発信者識別、既存の再連絡拒否処理、ほかの成功ケースがFailに戻っていないかも確認します。個別の例を先に下書きへ再生できますが、全体通過率と回帰確認に含めるにはActive状態である必要があります。
- 内部のデプロイ中止基準を適用します。たとえば必須ケースにFailが1つでもある場合や、既存Passの回帰がある場合にはデプロイを止められます。これは製品のデフォルトではなく、組織が定める基準です。ThunderPhoneでは、失敗を確認した後でも意図的にデプロイできます。
自動成功率は実際の業務結果と照合してください
ObservabilityのSuccess RateはAI採点に基づき、インフラエラーは分母から除外されます。通話量が多い期間の詳細指標は、最近の通話サンプルから計算されることもあります。 そのため、この数値をCRMの予約完了率やリード検証率と同じものとして読んではいけません。
自動スコアの横に、運用者が確認した発信者識別、氏名・出席可否、実際のCRM反映、コールバック手順の遵守、再連絡拒否リストへの反映、再通話、誤ったツール実行を記録します。自動評価と人の判定が食い違う通話では、エージェントのプロンプトだけを修正する前に、評価基準が曖昧でないかも確認する必要があります。
ThunderPhone評価の最小の完成単位は、エージェントを1つデプロイすることではありません。下書きをシミュレーションし、検証済みの保有番号で限定キャンペーンを実行し、再連絡拒否の依頼を次の発信対象から除外し、見つけた失敗ターンをValidation exampleとして保存するところまでつなげる必要があります。プロンプトを修正した場合は、例のStale状態と期待行動を再確認してActiveに切り替え、修正した下書きの完全なValidation runで必須ケースと既存の成功ケースがすべて内部基準を通過してから、次のデプロイへ進めます。 分単価はそのサイクルのコストの1つにすぎません。
さらに深く知りたい場合
Prompting guide - ThunderPhone — 実際の転送番号やコールバックの約束など、エージェントが実行できる具体的なhand-off経路とアウトバウンドプロンプトの構成を確認できます。 thunderphone.com
Outbound calling compliance — 発信者識別、再連絡拒否の処理、最初のアウトバウンド実行前に確認すべき責任範囲を確認できます。 thunderphone.com
Validation sets: replay real call turns before deployment — 実通話の特定の失敗ターンを下書きに再生する手順、Active・Stale状態、回帰表示、確認を迂回したデプロイの可否を確認できます。 thunderphone.com
Outbound campaigns — デプロイ済みエージェント、検証済み発信番号、連絡先CSV、通話設定をつないでキャンペーンを開始する公式手順です。 thunderphone.com
