AI音声リクルーターとは、応募があった直後に応募者へ折り返し電話をかけ、スクリーニング質問を行い、次のステップを予約し、条件を満たした候補者をリクルーターへ引き継ぐ音声エージェントです。これにより、誰も対応していないステータスのまま放置される候補者がいなくなります。候補者をスクリーニングするその他のツールについては、おすすめのAI候補者スクリーニングソフトウェアをご覧ください。
ループが途切れるポイントは4つあり、スピードに関するものは最初の1つだけです。最初の電話が遅れる、候補者が条件を満たした時点でリクルーターが手いっぱいである、候補者からの折り返しが留守番電話につながるか、すべてを一から聞き直す担当者につながる、そして連絡がつかない候補者が求人が埋まるまで「連絡試行中」のまま放置される、という4点です。本ガイドでは各ポイントを解説します。応募数の試算とスクリーニング質問の一覧については大量採用を、面接の無断欠席やリスケジュールについてはAI面接スケジューリングをご覧ください。
AI音声リクルーターはループ全体で何を担うのか？
担うのは連絡であり、判断ではありません。エージェントは電話の発信・受信を行い、候補者の発言を記録します。採用に関する判断はすべてリクルーターが行います。
| ループの段階 | トリガー | エージェントの動作 | ATSに戻される情報 |
|---|
| 最初のコールバック | 新規応募、または「リクルーターが連絡試行中」などのステータス | 電話をかけ、関心を確認し、スクリーニング質問を行う | 各回答、結果 |
| 引き継ぎ | 候補者が設定した基準を満たす | 非公開の要約を添えてリクルーターへウォームトランスファー（事前取次）する | 担当リクルーター、転送結果 |
| 引き継ぎ失敗 | リクルーターが応答しない | 候補者を取りこぼさず、コールバック日時を予約する | コールバック日時、担当者 |
| 着信コールバック | 候補者が不在着信に折り返す | 応答し、相手を認識し、前回の通話の続きから再開する | 新しい回答、結果 |
| 応答のない候補者 | 許可した試行回数を超えても応答なし | 設定した頻度で再発信し、その後停止する | 試行回数、最終ステータス |
応募者にはどれくらい早く折り返すべきか？
レコードが「この人に電話する」を意味するステータスに入った直後、かつ許可した時間帯内です。時給制の職種の応募者は複数の企業に応募していることが多いため、最初の電話が遅いと候補者を逃す可能性があります。
RetellにはATSとの既製の連携がないため、トリガーは自社ワークフローの短い処理として実装します。ATSが新規応募やステータス変更時にwebhookを送信すると（またはスケジュールされたジョブが新規レコードを検出すると）、自社システムがRetellのCreate Phone Call APIを呼び出します。候補者の名、職種、勤務地をダイナミック変数として渡せば、エージェントは「コロンバスの倉庫スタッフ職にご応募いただきました」と切り出せます。また、ATSのレコードIDをメタデータとして渡すことで、結果が正しいレコードに反映されます。
最初の発信の前に、応募フォームに電話に関する記載があるか確認してください。FCCは、AI生成音声がTCPA上の「人工」音声に該当することを確認しているため、こうした電話には通常、候補者の事前の明示的な同意が必要です。応募フォームの文言が応募に関する自動電話およびSMSをカバーしているかどうか、弁護士に確認してください。アウトバウンドAI通話のためのTCPAガイドに確認すべき事項がまとめられています。本記事は法的助言ではありません。
コールバックにはどのスクリーニング質問を含めるべきか？
候補者自身が答えられる3〜5つの事実を、決まった順序で尋ねます。まだ関心があるか、勤務可能日時、居住地または通勤、職種に必要な免許や資格です。スコアリングやランキングは通話に含めないでください。AI採用に関する規制が適用されるのはその部分だからです。
より重要な設計上の選択は、回答の保存先です。各質問を通話後の抽出フィールドとして定義します。「必要な免許を保有」にはブール値、希望シフトにはセレクター、自由回答にはテキストを使います。つながった通話はすべて文字起こしされ、そこからフィールドが入力されるため、リクルーターは録音ではなく回答を読むだけで済みます。通話中に回答が必要な場合（たとえば転送を提案するかどうかを判断する場合）は、extract dynamic variableツールでリアルタイムに取得できます。
ルーティングルールはローンチ前に作成してください。担当者との会話を希望した候補者、障がいや配慮について言及した候補者、給与交渉を持ち出した候補者は、スクリーニングの回答にかかわらずリクルーターへつなぎます。
エージェントは条件を満たした候補者をどのようにリクルーターへ引き継ぐのか？
ウォームトランスファー（事前取次）を使うことで、リクルーターは話し始める前に相手が誰かを把握できます。Retellの通話転送では、エージェントが通話を維持したままリクルーターに発信し、リクルーターだけに聞こえるウィスパーブリーフィングを再生します。「マリアさん、火曜日に夜勤に応募、フォークリフトの資格あり、月曜から勤務可能です」。その後、候補者をつなぎます。転送先がキューの場合、エージェントは実際の担当者が話すまで待ってからブリーフィングを行います。
適切なリクルーターにつなぐには、転送先番号を固定番号ではなくダイナミック変数として設定します。求人を担当するリクルーターなのか、ラウンドロビン方式で次の担当者なのかは自社システムが決定し、通話作成時にその番号を渡します。着信の場合は、inbound webhookで同じ変数を設定できます。
リクルーターが応答しない場合はどうなるのか？
候補者は口約束ではなく、予約済みのコールバックを得て通話を終えます。Retellでは、ドキュメント化された3つの方法が用意されています。
- エージェント型ウォームトランスファー。2つ目のAIエージェントである転送エージェントが、候補者を保留にしたままリクルーターに電話をかけます。対応できる人がいなければ転送をキャンセルし、候補者はメインエージェントに戻り、会話が再開されます。呼び出し時間とタイムアウト時の動作を設定できます。
- 会話フローでの失敗パス。通話転送ノードには、転送失敗時の組み込みエッジがあります。これをコールバック日時を提案するノードに接続します。
- リクルーターのカレンダーにコールバックを予約。Cal.comを連携すれば、エージェントが空き状況を確認して予約できます。Calendlyでも空き状況の確認と予約が可能です。リクルーターのコールバックを別の場所で管理している場合は、CRMツールまたは自社APIへのカスタム関数でタスクを作成します。
引き継ぎ失敗は自社システムにも通知されます。transfer_cancelled webhookは転送がキャンセルされたか接続に失敗したときに送信されるため、リクルーターにアラートを送ったり、レコードを「コールバック予約済み」ステータスに移したりできます。
コールバック自体を一からやり直すべきではありません。コンタクトメモリを有効にすると、エージェントはその電話番号との過去の会話の簡単な要約を受け取ります。会話フローでスクリーニングノードにUse memory to skip this nodeを設定すれば、再度連絡してきた候補者にはまだ不足している情報だけを尋ねます。回答をカスタムコンタクトフィールドに書き込めば、毎回の通話開始時にダイナミック変数としてエージェントに渡されます。メモリの動作には文字起こしの保存が必要です。保存設定が「Everything except PII」の場合は、マスキングされた文字起こしから作成されます。
候補者が折り返してきた場合はどうなるのか？
候補者は、すでに相手を認識している同じエージェントにつながるべきです。候補者が不在着信に折り返すのは昼休み、シフト後、週末など、採用担当窓口が最も応答しにくい時間帯です。
発信に使うすべての番号にインバウンドエージェントを紐付けてください。番号にインバウンドエージェントを設定しないままだと、折り返しの電話を受けられません。そのうえで、inbound webhookを使い、通話接続前にATSで発信者を検索します。候補者の名前、進行中の応募、担当リクルーターなどのダイナミック変数を設定したり、別のエージェントに切り替えたりできます。コンタクトメモリを有効にしておけば、エージェントは「ご用件は何でしょうか？」ではなく、昨日話した職種にまだ関心があるかを尋ねます。
連絡が途絶えた候補者にどう再アプローチするか？
連絡がつかない候補者ごとに、短く固定された試行回数を設定し、その後は停止します。Retellは再発信の上限設定やスケジューリングを単独では行わないため、頻度は自社システムで管理します。
- 毎日の一括発信。「連絡試行中」のままの候補者をエクスポートし、発信時間帯を指定した一括発信（バッチコール）としてアップロードします。予約済み以外のCSV列はすべてダイナミック変数になります。一括発信には通話ごとの遅延設定がなく、ペースは割り当てた同時通話数で決まります。
- 自社スケジューラー。候補者ごとにCreate Phone Callを呼び出し、事前にGet contact by phoneで確認します。
last_conversation_timestampが直近すぎる候補者はスキップします。応答のなかった通話も含め、すべての発信が会話としてカウントされるため、このチェックで発信試行もカバーできます。
留守番電話の対応は試行回ごとに変えます。一括発信のCSVでは行ごとに異なるエージェントを設定できるため、初期の試行では留守番電話なら切断し、最後の試行では職種名と折り返し先の番号を伝える短いメッセージを残す、といった設定が可能です。
停止ルール（最初の一括発信の前に作成）：
| 結果 | ルール |
|---|
| 採用済み、配置済み、または辞退 | すべてのリストから削除 |
| 電話しないよう依頼された | 恒久的に停止。do-not-contact対応を有効にしている場合、エージェントは一度確認してから通話を終了し、連絡先にフラグを立てる |
| この職種の条件を満たさない | この職種では停止し、将来の職種のためにレコードを保持 |
| 最終試行後も応答なし | 連絡不可としてマークし、レコードを解放 |
注意点が1つあります。一括発信ではdo-not-callフラグがチェックされず、Create Phone Callでもhonor_internal_dnc: trueを渡した場合にのみチェックされます。すべてのエクスポートからフラグ付きの連絡先を除外してください。また、連邦規則では、合理的な方法で行われた停止依頼に10営業日以内に対応することが義務付けられているため、電話、SMS、メールからのオプトアウトが同じリストに反映されるようにしてください。さらに連邦規則では、相手の所在地で午前8時前または午後9時以降の電話勧誘が禁止されており、州によって追加の制限がある場合もあります。すべての候補者への電話をこの時間帯内に収めることが、シンプルな出発点となります。いずれも弁護士に確認してください。
各通話後にATSに何を記録すべきか？
リクルーターが録音を聞かなくても何が起きたか分かる程度の情報です。通話後のカスタム関数でこれらのフィールドをATSのAPIに送信できます。留守番電話の結果がスクリーニング済みのレコードを上書きしないよう、結果に応じて送信を制御します。
callback_outcome（セレクター）：条件を満たし転送済み、条件を満たしコールバック予約済み、条件を満たさない、応答なし、留守番電話、番号違い、発信禁止- スクリーニングの回答ごとに1つのフィールド
- コールバックが予約された場合は
callback_timeとassigned_recruiter - 通話の要約と通話へのリンク
CRMから音声AIへのワークフローでは、同じ検索と書き戻しのパターンを解説しており、ATSにも適用できます。
同じループはクライアントからの求人依頼にも使えるか？
はい。営業時間外にクライアントから求人依頼の電話があった場合、エージェントはリクルーターに必要な情報を収集します。会社名と担当者名（綴りを確認）、開始日時、職種、必要人数、勤務地の住所、そして1桁ずつ読み上げて確認した折り返し先の番号です。その後、同じ経路で転送またはコールバックの予約を行います。
ローンチチェックリスト
- 応募時の同意文言を弁護士と確認済み
- ATSトリガーで名前、職種、勤務地、レコードIDを渡している
- 3〜5つのスクリーニング項目を、それぞれ抽出フィールドとして設定
- 配慮、給与、「担当者と話したい」に関するルーティングルール
- ウィスパー要約付きのウォームトランスファー、リクルーターごとに番号を設定
- コールバックを予約する引き継ぎ失敗パスと、
transfer_cancelledアラート - コンタクトメモリを有効化し、スクリーニングノードで既知の回答をスキップするよう設定
- すべての発信番号にインバウンドエージェントとwebhookによる検索を設定
- 発信頻度、試行ごとの留守番電話対応、停止ルールを文書化
- すべてのエクスポートから発信禁止の連絡先を除外し、発信時間帯を設定
どこから始めるか
まずは応募が安定して集まる1つの求人で1週間ループ全体を運用し、職種を追加する前に各ポイントの文字起こしを確認してください。人材派遣会社向けリード選別エージェントではスクリーニング通話そのものを紹介しており、人材業界の概要では人材会社がRetellで運用するあらゆる通話タイプを解説しています。
