音声AIのデモから本番運用へ：導入企業が最初の30日間に必要なこと

音声AIエージェントをデモから30日で本番運用に移行するための進め方は次のとおりです。まず1つの通話タイプにスコープを絞ります。2週目に構築と接続を行い、3週目にシミュレーション通話と実際の通話でテストし、4週目にライブトラフィックの一部でソフトローンチします。各作業には担当者を1人ずつ明確に割り当てます。デモが証明するのは、プラットフォームが会話を成立させられることです。30日間で証明するのは、自社のチームがそれを運用できることです。最後に、パイロットから本番運用へのスコアカードで、エージェントがより多くのトラフィックを受け入れられる状態かどうかを判断します。

優れたデモだけでは、なぜ本番運用に到達できないのですか？

デモが答えるのは「話せるか？」という問いです。本番運用では、まったく別の4つの問いに答える必要があります。どの通話を担当するのか、どのシステムに書き込むのか、通話がうまくいかなかったときに誰が修正するのか、そして発信者が耳にする前に変更をどうテストするのか、です。デモの後で停滞するチームの多くは、ソフトウェアでつまずいているわけではありません。ダッシュボードの使い方は理解しています。足りないのは、計画と明確な担当者、そして自社固有のワークフローについてドキュメントでは答えが見つからない疑問にぶつかったときに相談できる相手です。

まだプラットフォームを選定中であれば、まず本番稼働前に音声エージェントプラットフォームを評価する方法をご覧ください。有力候補はあるもののまだ決めていない場合は、次のセクションで説明するとおり、まず自社のエッジケースで検証してください。それ以降の内容は、プラットフォームを選定済みで、これから本番に出す段階にあることを前提としています。

自社のエッジケースで音声AIの概念実証（POC）をどう実施しますか？

音声AIの概念実証（POC）は、デモで省かれた通話を対象に実施します。自社のスタッフが最も手ごわい発信者を演じ、実際のものと同じ形式のレコードを使います。評価は双方が事前に署名した成功基準に照らして行い、テストの費用も事前に合意しておきます。デモが試すのはハッピーパスだけです。POCでは、通話を難しくしている自社のルールにエージェントが対応できるかどうかを確認します。

実際のレコードを使い、自社のスタッフでテストする

現在これらの通話を担当している人に、新人がつまずくケースを聞きます。そのうえで、その発信者になりきってエージェントに電話してもらいます。各ケースは、実際のものと同じ形式のレコードで実行してください。整ったテスト用レコードでは、乱雑なレコードで表面化する問題が見えなくなるからです。

実際のレコードをテストに使う前に、データの取り扱いを決めておきます。Retell のコンプライアンスドキュメントでは、保護対象保健情報（PHI）を Retell で扱う前に、署名済みのBAAが必要とされています。自社のルールでまだ実際のレコードを使えない場合は、その形式をコピーして使います。Retell のシミュレーションテストでは、ケースごとに動的変数の値とモック化した関数の結果を設定できます。自社のルールで何が許されるかは、法務顧問またはコンプライアンスチームに確認してください。

パイロット開始前に成功基準に合意する

成功基準には、最初のテスト通話の前に双方が署名します。後から書いた基準は、エージェントがたまたま出した結果に引きずられてしまうからです。基準には次の内容を明記します。対象となるケース、各ケースの合格基準と実行回数、重大な失敗とみなす条件、評価者、そして合格した場合の次のステップです。こうしておけば、合格した時点でテストを重ねるのではなく、意思決定に進めます。指標についてはプラットフォーム評価ガイドを参照してください。このガイドの後半で紹介するスコアカードは、別の意思決定に使うものです。

双方のテストコストを把握する

自社側では、通話の発信と評価にかかるスタッフの工数に加え、ITとコンプライアンスの時間がかかります。ベンダー側では、自社のルールに合わせてエージェントを構築する時間がかかります。さらに、プラットフォームの利用料も発生します。Retell のテスト料金によると、テストは本番と同じ料金で課金され、無料のサンドボックスはありません。音声は1分あたり$0.07から、テキストはメッセージ単位で課金されます。そのため、ほとんどのケースはテキストで実行してください。各コストの負担者、POCの期間、契約に算入されるかどうかは書面にしておきます。ケースリストと期間を固定すれば、双方のコストを抑えられます。

最初の30日間は、週ごとにどう進めるべきですか？

期間は4週間で、各週に1つの目標と明確な「完了条件」を設けます。その週の作業が完了するまで、次の週には進まないでください。

1つの通話タイプにスコープを絞る（1〜7日目）

通話量が安定していて、成果を記録システムで確認できる通話タイプを1つ選びます。たとえば、予約の確定、リードの振り分け、チケットの作成などです。その通話タイプの実際の録音や文字起こしを集めてください。チームが「発信者はこう話すはず」と考えているスクリプトでは不十分です。

スコープ文書では、次の5点を明確にします。

• 対象とする1つの通話タイプと、明示的に対象外とするすべての通話タイプ。
• 機械が真か偽かを判定できるように定義した成功指標。
• エージェントが読み取りまたは書き込みを行う1つの記録システム。
• エージェントが対応できない場合に、どの時間帯にどこへ通話を回すか。
• エージェントの文言を承認する人と、ローンチを最終承認する人。

構築と接続（8〜14日目）

構築はドラフトバージョンで行います。Retell では、新しいバージョンは編集・テストできるドラフトとして作成されます。公開すると読み取り専用になるため、いつでも戻れる固定の構成が常に残ります。接続するのは、スコープで定めた1つのシステムだけにしてください。その接続がチームにとって初めての場合は、CRMと音声AIのワークフローで、通話の各段階でどのデータがやり取りされるかを確認できます。

成功指標はローンチ後ではなく、この段階で設定します。Retell の Post Call Extraction（通話後抽出）は各通話の終了後に実行され、組み込みのcall_successfulフィールドを含みます。さらに、boolean、テキスト、数値、セレクターとして定義できるカスタムフィールドも使えます。「appointment_booked」のようなフィールドが、4週目にグラフ化しアラートを設定する対象になります。

シミュレーション通話と実際の通話でテスト（15〜21日目）

テストはテキスト、音声、電話の順に進めます。Retell のシミュレーションテストは、実際に電話をかけずにテストケースを実行します。作成したペルソナに基づいてAIが発信者を演じ、成功基準に照らして合格か不合格かが説明文付きで判定されます。保存したケースはバッチでまとめて実行でき、合格率がレポートされます。このスイートが、変更のたびの回帰チェックになります。Retell のダッシュボード内コパイロットである Conductor を使えば、ゼロから、または実際の通話からテストケースを作成できます。

この週に押さえておくべきポイントは3つです。

• ライブシステムに書き込むものはすべてモック化する。Retell のドキュメントでは、モック化されていないカスタム関数はテスト中に実際のendpointを呼び出すと警告しています。つまり、テストで実際の予約やレコードが作成される可能性があります。
• 音声の確認にはWeb通話、テレフォニーの確認には電話を使う。ブラウザ通話では割り込みやターンテイキングを確認できますが、電話番号への転送は失敗します。転送、キーパッド入力、キャリア音声の確認には、実際の電話を使ってください。
• 予算を確保する。Retell ではテストも本番と同じ料金で課金されます。テキストテストはメッセージ単位、音声テストは分単位です。

週の最後には、対応が難しい発信者も含め、スタッフに実際の発信者と同じように電話をかけてもらいます。

ソフトローンチとモニタリング（22〜30日目）

実際のトラフィックの一部をエージェントに送り、毎日確認します。あわせて、ワンステップでロールバックできる状態を保ちます。最初の割り当てでは、テレフォニー担当者が既存のIVRやキューから通話の一部をエージェントの番号に振り分けます。その後は、Retell の3つのツールを活用できます。

• A/Bテストは、電話番号のトラフィックを割合を指定してエージェント間で分割します。修正版には少量だけを割り当て、残りは信頼できるエージェントで処理できます。
• 環境タグは、電話番号をバージョンに紐づけます。prodタグを新しいバージョンに移すとライブ通話が切り替わり、元に戻せばロールバックされます。
• アラートルールは、通話成功率、通話量、使用中の同時通話数、ネガティブな感情、コストが設定したしきい値を超えると、メールまたはwebhookで通知します。

通話は毎日レビューします。Call History（通話履歴）では、成果、切断理由、エージェントのバージョンで絞り込めます。Live Monitoring（ライブモニタリング）では、スーパーバイザーがリアルタイムの文字起こしを追ったり、無音で聞き取ったり、通話を引き継いだりできます。分析ダッシュボードでは、カスタム抽出フィールドを通話量と並べて、エージェントのバージョン別にグラフ化できます。修正によって数値が改善したかどうかが一目でわかります。大量の通話を構造化して採点する必要がある場合は、Retell の AI QA が、サンプリングした通話を定義した基準に照らして採点します。

ロールアウト中、誰が何を担当しますか？

担当者は1行につき1人です。担当を共有している行こそ、ロールアウトが停滞する原因になります。

最も重要なのは2行目です。チケットを起票しないとエージェントを変更できない状態では、エージェントの改善スピードが他社のキューの処理速度に左右されます。この行を担うのは、CXオートメーションエンジニア、つまり社内の担当者であるケースが増えています。ベンダーのフォワードデプロイドエンジニアが最初のバージョンの構築を支援し、チームをトレーニングした後は、この担当者が日々エージェントを運用します。

契約前に、導入支援についてベンダーに何を確認すべきですか？

プランに含まれる支援の内容を書面で確認し、構築で行き詰まったときの連絡先も聞いておきます。セルフサービスが機能するのは、時間を確保できる社内のビルダーがいる場合です。そうでない場合は、2週目になって不足に気づく前に、最初から支援を購入してください。

Retell の料金ページには、従量課金プランにコミュニティサポートとメールサポートが含まれると記載されています。Enterpriseプランには、専用ポータル付きの24時間365日サポートと専任のアカウントマネージャーが含まれ、アドオンとしてDedicated Implementation Support（専任導入支援）も用意されています。サードパーティによる実践的な構築支援が必要な場合は、Retell のソリューションパートナーディレクトリで認定パートナーを探せます。所在地、言語、連携、初回相談が無料かどうか、価格帯で絞り込むことができます。

どのベンダーにも確認すべき質問は次のとおりです。

1. プランに含まれるサポートチャネルと対応時間は何ですか？また、どのような事象が緊急とみなされますか？
2. 導入支援はプランに含まれていますか、アドオンですか、それともパートナー経由で提供されますか？費用はいくらで、固定料金ですか、それともプロジェクトごとの見積もりですか？
3. ソフトローンチ前に、スコープ、エージェント設計、テストスイートのレビューを受けられますか？
4. ソフトローンチ週に問題が発生した場合、誰に連絡すればよく、どのくらいの速さで対応してもらえますか？
5. ベンダーへのチケットなしに、自社チームだけで変更ループ全体（失敗した通話の発見、修正、テスト、公開、ロールバック）を回せますか？
6. プラットフォームのインシデントはどのように通知されますか？

パートナーと共同で構築する場合は、音声AIベンダーとパートナーが最初の案件のスコープをどう決めるかで、パートナー側から見た役割分担を解説しています。

本番運用に移行する前に、AIパイロットをどう採点しますか？

ライブトラフィックで少なくとも丸1週間運用した後、固定のスコアカードでパイロットを採点します。本番運用に移行するのは、すべてのゲート行が合格し、合計点が1週目に設定した基準をクリアした場合だけです。スコアカードを使うと、「うまくいっているようだ」という感覚を、拡大、保留して修正、再スコープの3つの意思決定のいずれかに変えられます。

数値を見た後で基準を引き下げる議論が起きないよう、ソフトローンチ前にスコープ文書に基準を書き込んでおきます。各行は0（未達）、1（一部達成）、2（達成）で採点します。ゲート行は、合計点に関係なく2点でなければなりません。9行で満点は18点となり、16点が妥当なデフォルトの基準です。

トラフィックを引き上げるたびに、再度採点してください。少量では問題なく動作していても、比率を上げると破綻することがあるからです。変更ループの行は、チームが最も省略したくなる行です。しかし、本番運用でエージェントがどれだけ速く改善するかは、この行で決まります。プロンプトの編集はすべて、テスト可能な新しいバージョンとして扱います。これはプロンプトのバージョン管理と呼ばれる手法で、失敗した修正をワンステップで元に戻せます。

このスコアカードは、選定済みのプラットフォームでソフトローンチから本番運用に移行するためのものです。パイロットでベンダーを比較する場合は、プラットフォーム評価ガイドのGo／No-Goリストを使ってください。

最初に何を拡大すべきですか？

一度に変えるのは1つだけにします。まずトラフィック比率を引き上げ、次に2つ目の通話タイプ、その後に2つ目のシステムを追加します。どの拡大でも、スコープ設定、ドラフトでの構築、スイートの実行、ソフトローンチ、レビューという同じループを繰り返します。失敗した本番通話はすべて新しいテストケースにし、発信者の実際の行動に合わせてスイートを充実させます。トラフィックを大幅に引き上げる前には、実際の通話経路に沿った負荷テストを実施してください。

適切なレベルの支援から始める

必要な支援の量を最初に決めておくと、最初の30日間を最も早く進められます。各 Retell プランに含まれる内容は料金ページで比較できます。チーム内に構築を担える人がいない場合は、Retell ソリューションパートナーディレクトリで認定パートナーを探してください。

よくある質問

「AIパイロットから本番運用へ」とは何を意味しますか？

AIパイロットから本番運用への移行とは、実際のトラフィックの一部で試験運用している段階から、AIエージェントをその通話タイプの標準ルートとして運用する段階に進むことです。本番運用では、明確な担当者、モニタリング、テスト済みのロールバック手段を備えます。パイロットは、エージェントが通話を完了できることを証明します。本番運用は、チームがそれを安定して機能させ続けられることを証明します。

音声AIの概念実証には何を含めるべきですか？

含めるべきものは3つです。1つ目は、実際と同じ形式のレコードを使い、自社のスタッフが電話で試す、最も難しい実際のケースです。2つ目は、最初のテスト通話の前に双方が署名する成功基準です。3つ目は、プラットフォーム利用料、構築時間、スタッフの工数を誰が負担するかを定めた書面です。意思決定で締めくくれるよう、ケースリストと期間は固定してください。

実際の顧客データをベンダーに送らずに、音声エージェントをテストできますか？

はい、できます。実際のレコードの形式をテストケースにコピーして使います。Retell のシミュレーションテストでは、ケースごとに動的変数の値とモック化した関数の結果を設定できます。ライブシステムにアクセスする関数はすべてモック化し、それぞれのモックに結果を設定してください。空のモックは実際の関数を実行してしまい、MCPツールはモックを無視するためです。実際のデータを使う必要がある場合は、先に契約を締結してください。Retell では、保護対象保健情報を扱う前に署名済みのBAAが必要です。自社のルールについては、法務顧問またはコンプライアンスチームに確認してください。

音声AIパイロットから本番運用まで、どのくらいかかりますか？

1つの通話タイプであれば、約30日を見込んでください。スコープ設定、構築、テストにそれぞれ1週間ずつかけ、その後ライブトラフィックの一部でソフトローンチします。ライブ通話で少なくとも丸1週間運用した後にパイロットを採点し、その後もトラフィックを引き上げるたびに再度採点します。

音声エージェントが本番運用に対応できる状態かどうかは、どう判断しますか？

ライブトラフィックで丸1週間運用した結果、スコアカードのすべてのゲート行が2点になった時点が目安です。具体的には、成功指標が維持されている、レビューした通話に重大なエラーがない、チームがベンダーの支援なしにバージョンを修正・ロールバックできた、すべてのワークストリームに明確な担当者がいる、コンプライアンスの承認が記録されている、という状態です。

パイロットの成果が振るわない場合はどうすべきですか？

トラフィック比率を維持するか、本番タグを最後に正常に動作したバージョンに戻します。ドラフトバージョンで修正してテストスイートを再実行し、さらに1週間後に再度採点します。2回の修正サイクル後も成果または重大なエラーの行が0点のままであれば、通話タイプを絞り込むか、成功の定義を見直してください。