発信者を選別してから予約するAIアポイント獲得エージェントの構築方法
11
MIN READ
October 2, 2026
AI電話エージェントに関するガイドの多くは、エージェントが電話に出て挨拶するところで終わっています。その部分は簡単です。難しいのは、最も優秀な配車担当者が尋ねるような質問をエージェントにさせ、予約する価値のある回答が得られたときだけ案件を予約させることです。
ここを誤ると、ノイズを自動化するだけになります。カレンダーは、作業を承認できない賃借人、サービスエリア外の発信者、何かを決めるまでまだ3か月もかかる人たちで埋まってしまいます。そのどれもが、本来なら実際の案件に使えたはずの枠です。
このガイドでは、まず選別し、その後で予約するAIアポイント獲得エージェントを構築します。これはライブのCal.comカレンダーに接続されたカンバセーションフローで、構築にかかる時間は約15分です。プロンプトだけが目的の方は、終盤のプロンプト一覧にすべてまとめてあります。
以下の動画は、同じ構築作業を最初から最後まで画面上で紹介しています。読むより見る方がよい場合は、動画に沿って進めてください。このページの手順とプロンプトは動画と一致しているため、別のタブでこのページを開いたまま、進めながらコピーできます。
選別のための会話が行われない着信は、2つのうちどちらかの結果になります。1つは、最初から見込みのない案件を予約してしまい、枠と技術者の移動時間を無駄にすること。もう1つは、誰もすぐに電話に出られず、発信者がリストの次の業者に移ってしまうことです。
どちらも同じコストを生みます。前者はすでに費用を払っている稼働能力を浪費し、後者は電話に出た競合他社に売上を渡してしまいます。選別を行うエージェントなら、1回目の呼び出し音で応答し、予約すべきでない電話は予約しないため、両方の問題を解決できます。
新しい音声エージェントを作成するとき、選択肢は2つあります。シングルプロンプトエージェントか、カンバセーションフローエージェントです。
シングルプロンプトエージェントは、モデルが読み込んでそれを基に臨機応変に対応する1つの指示ブロックです。設定が速く、営業時間や住所を読み上げるような直線的なスクリプトには十分です。
カンバセーションフローは、明示的な分岐を持つ、ノード単位の通話マップです。各ノードでの発信者の回答によって、次にどのノードに進むかが決まります。ドキュメントのエージェントタイプ比較で、両者のトレードオフを詳しく説明しています。
選別にはフローが適しています。選別とは判断であり、判断には目で確認し、テストし、修正できる分岐が必要です。賃借人が断られるノードを指し示せないなら、それは選別ステップではなく、モデルが指示を覚えていることへの期待にすぎません。
選別基準が自社に固有のものであれば（ほぼ必ずそうです）、テンプレートではなくゼロから始めましょう。
すべてのノードを手作業でドラッグして配置する必要はありません。ConductorはRetellに組み込まれたAIコパイロットです。求める通話の内容を説明すると、ノードと分岐を提案してくれるので、公開前に確認できます。
このガイドの最後にあるプロンプト一覧のプロンプト1を使ってください。説明文が重要な役割を果たすため、願望ではなく仕様書のように書きましょう。
Conductorは構築前に確認の質問を返してきます。具体的に答えてください。正確なサービスエリアを示し、予約ツールとしてCal.comを指定することで、推測ではなく正しい位置に除外分岐と予約ノードを配置できるようになります。まだ接続していない認証情報が必要な部分には、プレースホルダーを入れるよう依頼しましょう。
承認する前に、すべてのノードを読んでください。プルリクエストをレビューするのと同じように、Conductorが提案し、あなたが承認します。これは多くの人が省略するステップですが、分岐の抜けを最も低コストで見つけられるのはここです。
ここで理解しておくべき失敗例があります。「発信者が賃借人だと言ったら通話を終了する」と書いても、発信者が別の質問に答える中でたまたま賃借人だと自ら言った場合にしか作動しない除外パスを含むフローができあがることがあります。
それは選別のための質問ではありません。単なる運です。
明示的に求めなかったことは、確実には得られません。持ち家か賃貸かでトラックを出すかどうかが決まるなら、その質問を直接尋ねることだけを役割とするノードが必要です。サービスエリアも同様です。一覧のプロンプト7でそれらのノードが存在するかを確認し、プロンプト8で追加します。
予約には実際のカレンダーが必要です。これは認証情報が必要なため、コパイロットが代行できない唯一のステップです。
Cal.comでSettingsを開き、API keysタブで新しいキーを作成します。有効期限は使用予定期間に合わせて設定してください。Retellでは、Integrationsに移動してCal.comを追加し、キーを貼り付けます。反映されると、アカウントが接続済みと表示されます。
構築作業のうち手作業が必要なのは、これだけです。
予約用のサブフローを開きます。その中に、空き状況を確認する関数と予約を行う関数の2つが必要です。
どちらにもCal.comのイベントタイプIDが必要です。これは、エージェントに使わせたい予約リンクのURLに含まれています。URL内の数字がそれで、各関数のイベントタイプID入力欄に入力します。
まず空き状況確認の関数を追加し、イベントタイプIDを貼り付けて保存します。次に予約の関数を追加し、同じイベントタイプIDを入れ、残りの入力欄を埋めて保存します。Cal.com関数の一覧では、必要になったときのための予約変更やキャンセルについても説明しています。
両方の関数が揃ったら、一覧のプロンプト3を実行し、Conductorにノードをライブの連携先へ接続し直してもらいます。
ダッシュボード内からテスト通話を行い、条件を満たす発信者を演じてみます。
確認すべきなのは、エージェントの話し方が良いかどうかではありません。手順の順序が守られているかどうかです。正しく動作していれば、エージェントは何が問題かを尋ね、修理か交換かを尋ね、持ち家か賃貸かを尋ね、サービスエリアを確認し、緊急度を尋ねてから、候補の時間を提示します。
よくある不具合は次の3つのチェックで見つかります。一覧のプロンプト4、5、6がその修正方法です。
実際の空き時間を提示するか？カレンダーが空いているのにエージェントが空きはないと言う場合、たいていは今日の日付を認識しておらず、過去の期間を確認しています。
まだ取得していない日付に対応できるか？最初に提示された時間以外の日を尋ねてみてください。一度だけ確認して再確認しないフローは、その日が空いていても空きがないと言い張ります。
予約前に名前とメールアドレスを収集するか？Cal.comはこれらがない予約を受け付けません。誰も尋ねなければ、発信者が時間を選んだ後で予約が失敗します。これは失敗が起きる場所として最悪です。
除外パスもテストしてください。承認のない賃借人とサービスエリア外の発信者は、どちらも予約を試みることなく丁寧に通話が終了されるべきです。思い込まずに、実際に確認しましょう。
エージェントを公開したら、電話番号を購入して割り当てます。同じ番号を着信と発信の両方に使えます。
身につけるべき習慣は、通話履歴を読むことです。すべての通話に文字起こしと要約が残るため、発信者が何を求め、エージェントがどう対応したかを確認できます。今回の構築のテスト通話では、Long Island Cityの賃貸物件で、既存の屋根の穴に対する屋根修理が、大家の許可を得たうえで予約されたことが記録されています。
これは、トラックが出発する前に技術者が必要とする情報であり、誰も入力していません。一覧のプロンプト9では、通話後分析を使って、同じ情報をCRMが読み取れる構造化フィールドに変換します。
最初の数週間の文字起こしは、しっかり読んでください。エージェントがうまく尋ねられていない質問、誰も到達しない分岐、作り忘れた除外条件がわかります。
選別が安定したら、次に役立つ追加機能は、案件の種類ごとに別の技術者へ振り分けるための2つ目のカレンダーと、既知の顧客からの電話に対応するエージェントが一から尋ねなくても相手を把握できる動的変数です。
順序が重要です。間違った発信者をより速く予約してしまうエージェントは、エージェントがないよりも悪い結果を招きます。まず選別、次に件数です。
このフローの構築方法は2通りあります。Conductorに説明して提案を承認する方法と、自分でノードを配置して各ノードに指示文を貼り付ける方法です。両方のセットに加え、この構築で当初発生した4つの問題を回避できる1つの仕様をここにまとめています。
このページから1つだけコピーするなら、これをコピーしてください。後からバグとして発見するのではなく、4つの要件すべてを一度にConductorに渡せます。
構築前に：まずダッシュボードのIntegrationsページでCal.comを接続してください（API key、cal.comかcal.euか）。空き状況確認ノードと予約ノードは、RetellのネイティブなCal.com連携ツールを直接使って構築してください。プレースホルダーのカスタム関数は使用しないでください。
グローバルプロンプト：「現在の日時は{{current_time}}です。今日、明日、来週の月曜日、数日後などの相対的な日付は、常にこの実際の日付を基準に解釈してください。日付を推測しないでください。」を含めてください。
空き状況ノード：発信者の最初の回答が曖昧か具体的かにかかわらず、常に今日から14日間のデフォルト期間で照会してください。発信者が後から現在取得済みの期間外の日付を指定した場合は、空きがないと伝える前に、その日付を含む期間で再確認してください。
予約ノードの前に：Cal.comの予約処理で必須となる、発信者のフルネームとメールアドレスを収集してください。両方を取得するまで予約関数を呼び出さないでください。
この1つのブロックで、4つの失敗を防げます。実体のないものを指すプレースホルダー関数、今日の日付を知らないエージェント、発信者の実際の質問に答えるには狭すぎる空き状況の期間、そして誰も名前とメールアドレスを尋ねなかったために失敗する予約です。
1つずつ入力し、承認する前にConductorの提案を読んでください。問題に遭遇しながら解決していきたい場合は、プロンプト4〜6がステップ5の3つの失敗に対する修正方法です。
1. フローの骨組みを作る
HVACと屋根工事の会社向けのカンバセーションフローを構築してください。発信者に挨拶し、修理が必要か、システム全体の交換が必要かを尋ねます。回答に応じて分岐させてください。発信者が賃借人で作業を承認できない場合、またはサービスエリア外の場合は、予約せずに丁寧に通話を終了してください。それ以外の場合は、数週間以内に作業を希望しているか、見積もりを集めているだけかを尋ね、予約へと進めてください。
2. プレースホルダーを実際のカレンダーに置き換える
check-availabilityとbook-appointmentを、実際のCal.com連携に置き換えられますか？
3. 手動で接続した関数をフローに指定する
Cal.com連携の関数を追加しました。それらを使って、プレースホルダーのサブノードに置き換えてください。
4. エージェントが常に空きがないと言う
予約しようとするたびに空き状況の確認がうまくいかず、数日以内に予約枠がないと言われます。なぜですか？
5. 空き状況の期間が狭すぎる
テストしたところ、AIは空きが金曜日までしかないと言いましたが、今日は水曜日で、カレンダーでは来週の月曜日も予約できます。なぜエージェントはそれを提示しないのですか？
6. 最後のステップで予約が失敗する
月曜日の予約はできましたが、その後予約が失敗します。先に収集が必要な情報があるためだと思います。
7. 選別が実際に存在するか確認する
フロー内に選別が見当たりません。これに対応するケースは作られていますか？
8. 明示的な選別レイヤーを追加する
賃貸か持ち家かを判断するための選別質問のレイヤーをもう1つ追加する必要があります。持ち家なら問題なく、賃貸の場合は大家の承認が必要です。場所も同様で、Queens, NY以外は対象外です。
9. 通話終了時にリードデータを取得する
発信者が条件を満たしたかどうか、修理か交換か、本人が伝えた緊急度、そして技術者向けの1行の要約を取得する通話後分析ステップを追加してください。
プロンプトで指示する代わりに、各ブロックを対応するノードに貼り付けてください。
エージェントレベルのプロンプト（フローの最上位に設定）
あなたは、HVACと屋根の修理依頼に対応するホームサービス会社のスケジュール担当アシスタントです。あなたの仕事は、発信者のニーズをすばやく把握し、技術者を派遣する価値があるかを判断し、価値があれば訪問の予約を取ることです。読み上げられる台本ではなく、親しみやすい配車担当者のように、簡潔かつ自然に話してください。空き状況を作り上げてはいけません。カレンダーツールが返した情報のみを使用してください。
現在の日時は{{current_time}}です。相対的な日付は、常にこの実際の日付を基準に解釈してください。日付を推測しないでください。
ノード1：挨拶と最初の質問
発信者に挨拶し、HVACまたは屋根の問題について何が起きているかを尋ねてください。次に「修理をご希望ですか、それともシステム全体の交換をご検討ですか？」と尋ねます。先に進む前に回答を待ってください。
ノード2：分岐条件。これらは独立したノードではなく、ノード1から出るエッジに設定します。
ノード3：除外
所有者の承認がない賃借であるか、サービスエリア外であるため、現時点ではご予約をお受けできない旨を丁寧に説明してください。物件の管理会社に確認するか、状況が変わったら改めて連絡するよう提案してください。お礼を伝え、丁寧に通話を終了してください。何も予約しようとしないでください。
ノード4：緊急度の質問
「数週間以内に作業をご希望ですか、それとも現在は見積もりを集めている段階ですか？」と尋ねてください。回答を緊急度の設定に使いますが、予約する準備ができていないと明確に言われない限り、予約へ進めてください。
ノード5：連絡先の収集。このノードは緊急度の質問と予約ノードの間に置きます。ほとんどの構築で忘れられがちなステップです。
確認の連絡を送るため、発信者のフルネームとメールアドレスを尋ねてください。手短に、必要であれば1つずつ質問してください。両方を取得するまで予約に進まないでください。
予約ノード（Cal.com関数を配置する場所）
両方の質問に回答があり、発信者が除外されていなければ、Check Availabilityを呼び出してください。空いている時間を2〜3件、リスト形式ではなく自然な文章で読み上げてください。発信者が口頭でいずれかを確定するのを待ち、その時間でBook Appointmentを呼び出してください。口頭での確認前にBook Appointmentを呼び出さないでください。
通話後の抽出フィールド。すべての通話で取得する価値のあるフィールドは4つです。qualifiedはブール値で、予約されればtrue、除外または辞退されればfalse。repair_or_replacementはセレクターで、最初の回答から取得します。urgencyは「今週」「今月」「見積もりのみ」から選ぶセレクターで、2つ目の回答から取得します。そしてsummary_for_techはテキストで、訪問する担当者向けに問題を1〜2文でまとめたものです。
エージェントを実際の番号に割り当てる前に、これらをシミュレーションとして実行してください。シミュレーションの実行は課金対象のため、Conductorはまず範囲の確認を求めます。
発信者が物件を賃借していて作業を承認できないと言うシミュレーションのテスト通話を実行できますか？エージェントが予約へ進まず、予約を断って通話を終了することを確認したいです。
同じことを、サービスエリア外の発信者でもシミュレーションし、予約せずに通話を終了することを確認できますか？
実際の通話で本来断るべき相手を予約してしまった場合は、次の2つで原因を診断できます。
作業を承認できない賃借人としてテスト通話をしましたが、エージェントはそのまま進んで予約しようとしました。なぜその回答で除外されないのですか？
サービスエリア外から電話したのに、それでも予約を提案されました。なぜ除外分岐が作動しないのですか？
このガイドの構築なら、空のアカウントから電話番号付きのエージェントを公開するまで約15分です。テストにはさらに時間を見込んでください。フロー自体は1つのプロンプトから骨組みが作られますが、日付の処理、空き状況の期間、予約フィールドの抜けを見つけるテスト通話に、実際の時間の多くがかかります。
いいえ。フロー全体は、平易な言葉で説明し、コパイロットの提案を承認するだけで構築できます。手作業のステップは、Cal.comのAPIキーを貼り付けることと、URLからイベントタイプIDをコピーすることだけです。
シングルプロンプトエージェントは1つの指示ブロックを読み込み、臨機応変に対応します。カンバセーションフローは、確認・テストできる分岐を持つ明示的なノード単位のマップです。直線的なスクリプトにはシングルプロンプトを、通話に判断が伴う場合（選別では必ず伴います）はカンバセーションフローを使いましょう。
はい。ここでCal.comを使っているのは、予約APIの接続が簡単だからです。空き状況確認の関数の後に予約の関数を続けるという同じパターンは、他のカレンダー連携にも適用できます。
主な原因は2つです。エージェントが現在の日付を知らず、すでに過ぎた期間を確認しているか、狭い期間を一度だけ確認し、発信者が別の日を指定しても再確認していないかです。プロンプト一覧のプロンプト4と5で、それぞれのケースを修正できます。
除外ノードに到達し、何も予約せずに丁寧に通話が終了されます。このパスは明示的に構築する必要があります。最初のプロンプトでルールを説明するだけでは不十分であり、それを検出するためにプロンプト7と8があります。
AI搭載の音声エージェントに切り替えることで、あなたのビジネスがどれだけ節約できるかをご確認ください。
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Retell クリニックオフィスのデモ電話番号
Start building smarter conversations today.
