AIの電話予約を発注する前に決めておきたい条件

AIの電話予約では、予約を成立させる会話だけを設計しても足りません。電話をかけない条件を先に決める必要があります。再架電（つながらなかったときに電話をかけ直すこと）の上限や、店舗の拒否状態が曖昧では、個々の会話が成立しても運用は続きません。

発注時には、予約の確定条件と情報修正の責任も決めます。利用者には、依頼の受付と店舗の承諾を分けて見せます。電話を成立させる機能と止める機能は、同じ要件表で扱います。

AutoReserve（オートリザーブ）は、利用者に代わってAIが飲食店へ電話し、予約を取るサービスです。電話予約しか受け付けない店も、利用者はオンラインで予約できます。一方、店舗からは繰り返しの着信や誤った店舗情報が報告されています[1]。公開された事例と運営側の説明をもとに、「なぜ何度も電話がかかってくるのか」「店が断ったらどうなるのか」「いつ予約できたと言えるのか」という3つの疑問に沿って、発注前に決めておく条件を整理します。

なぜ何度も電話がかかってくるのか？

店舗が電話に出られない場合に、何十分も架電が続いた例があります[1]。こうした事態を防ぐ鍵は、再架電をいつ止めるかを仕様で定めておくことです。

自動架電（システムが自動で電話をかけること）には、AIが何を話すかとは別に、「いつ電話するか」「何回までかけ直すか」「どの番号にはかけないか」を制御する仕組みがあります。かけ直しを終える条件を「予約が取れたとき」だけにすると、店舗が出ないかぎり電話が続きかねません。そこで、発信回数・間隔・かけない番号を、停止条件として仕様に書きます。

運営側は、営業中に電話を受けられない店舗や、時間外にも予約を受ける店舗があるため、時間外にも予約確認の連絡をする場合があると案内しています[3]。このため、発信してよい時間帯は営業時間だけでは決まりません。店舗が指定した受付時間や、利用者のリクエストの内容も判断材料になります。そのうえで、時間帯にかかわらず、回数と間隔の上限を発注側が仕様に書いておきます。

発注仕様には、少なくとも次の条件を入れます。

• 1件の予約リクエストに対する最大発信回数
• 再架電までに空ける時間
• 店舗単位と電話番号単位の発信上限
• 営業時間、仕込み時間、店舗が指定した受付時間に応じた発信制限
• 相手が拒否を伝えた場合の即時停止
• 上限に達した後、利用者へ返す結果

つながらなかった理由も区別します。話中、留守番電話、無応答では、再架電してよい条件が異なります。着信拒否や応答直後の終話も、別の結果として扱います。留守番電話の判定自体が誤ることもあります。詳しくは「AIの電話は、留守番電話をどう見分けるのか」に記載しています。

「応答なし」は、再試行してよいという意思表示ではありません。一定回数で打ち切り、利用者へ予約不成立を返す流れも正常系（異常ではなく想定どおりの流れ）です。AI架電の処理全体は「AIからの電話は、AIが受ける電話と何が違うのか」で整理しています。

納品後の確認では、店舗別の発信回数を見て、設定した上限どおりに止まるかを確かめます。

店が「やめてほしい」と言ったら、電話と掲載はどうなる？

答えを先に言うと、店舗ページの掲載、電話の発信、店舗情報の修正は、それぞれ別の状態として管理します。ページの掲載を止められなくても、架電を拒否した番号は発信対象から外す仕様にします。

実際、店舗からは削除を依頼しても掲載が続くという声が出ています[1]。運営会社は、掲載内容を公開情報や利用者の意見で構成しているため、ページの削除には対応できないと案内しています[2]。情報の修正は、問い合わせフォームか店舗ページから提案できます[2]。

一方で架電の側では、予約受付を拒否した店舗に予約画面が表示される例が報告されています[1]。店舗が承認や却下を伝える手段としては、自動音声のほかに、ウェブアプリや人間のオペレーターによる電話も案内されています[4]。それでも、「かけないでほしい」という意思が、電話をかける・止める仕組みに反映されなければ、電話は止まりません。

そこで拒否状態は、発信前に必ず確認するデータとして保持します。オペレーターのメモだけに残しても、自動発信の制御には反映されません。拒否の対象は、「AI音声のみ拒否」か「予約代行からの電話をすべて拒否」かを分けて持ちます。「特定の時間だけ受付」は、拒否とは別の時間条件として管理します。

拒否状態には、有効期限と変更履歴も残します。電話番号だけでなく、店舗の識別子（店舗ごとに割り当てる固有の管理ID）でも保持します。電話番号だけで管理すると、番号の変更や回線の追加の際に拒否状態を引き継げないためです。新しい予約要求で拒否状態を上書きすると、停止の申し出が次の架電に反映されません。

店舗情報の修正の扱いには、公正取引委員会の考え方が参考になります。同委員会は、客観的に不正確な店舗情報などへの対応を示しています。加盟店でない飲食店からの削除や修正要望にも、特段の条件なく応じることが望ましいとしています[5]。対象は、消費者が投稿や編集をできる基本的な店舗情報と口コミです。

予約システムの設計では、修正依頼を受け付ける窓口を置くだけでなく、受け付けた修正をいつまでに確認して反映するか、その結果を発信停止にどうつなげるかまでを決めておきます。

納品後は、拒否後の発信件数を確認し、拒否の申し出が次の発信に反映されているかを確かめます。

いつ「予約できた」と判断すればよい？

AIが日時を聞き取っても、予約が成立したとは限りません。営業時間と合わないなど、誤った情報をもとに予約が入った事例が報じられています[1]。また、アレルギーや料理の好みのように定型項目では扱いにくい要望を、店舗が事前に確認できないという指摘もあります[1]。

予約状態は、次のように分けます。

• 依頼を受け付けた
• 店舗へ発信中
• 店舗が承諾した
• 確認できなかった

利用者の画面でも、「依頼を受け付けた」と「店舗が承諾した」を分けます。「依頼を受け付けた」段階で「予約済み」と表示してはいけません。発注側は、どの応答で予約確定へ移るかを決めます。

受入テスト（納品された仕組みが要件を満たすかの確認）には、予約確定に進めない場合も含めます。たとえば日時や人数の復唱が一致しない場合や、条件付きの返答が来た場合に、誰が確認するのかを決めておきます。

アレルギー対応や席の条件のような定型化できない要望を、自由な会話だけで完結させると、伝達漏れを検証しにくくなります。

そこで、定型化しにくい要望が出た時点でオペレーターへ切り替える設計が考えられます。店舗が示した条件を利用者に再確認してから確定する方法もあります。想定どおりに会話が進まない場合の設計は「AIからの電話は、なぜ台本どおりに進まないのか」にも記載しています。

あわせて、予約確定前の不一致と有人対応への切替件数を確認します。例外がそのまま「予約済み」と表示されていないかを確かめるためです。

まとめ

AIの電話予約を発注するなら、会話の精度だけでなく、再架電の上限、拒否状態の管理、予約を確定とみなす条件の3つを先に決めます。冒頭の3つの疑問の答えは、この3つの条件に対応します。電話を成立させる機能と止める機能を同じ要件表で扱うことが、運用を続ける条件です。

よくある質問

AIで飲食店への予約電話を自動化するとき、何に注意すべきですか？

予約を成立させる会話だけでなく、電話を止める条件を決めます。予約の確定条件や情報修正の責任も必要です。利用者には、依頼の受付と店舗の承諾を分けて表示します。

自動架電の再試行や停止条件はどう決めますか？

最大発信回数と再架電の間隔を仕様に書きます。店舗や電話番号ごとの上限も必要です。相手が拒否したら即時に停止し、上限後は予約不成立を利用者へ返します。

店舗が予約代行の電話を拒否した場合はどう扱いますか？

拒否状態を、発信前に必ず確認するデータとして保存します。電話番号と店舗の識別子の両方で管理します。掲載を続けるかどうかと、電話を止めるかどうかは分けて扱います。

AIが日時を聞き取れば予約は完了ですか？

日時を聞き取っただけでは、予約成立とは限りません。店舗が承諾した状態を、依頼受付や発信中と区別します。条件付きの返答や定型化できない要望には、有人対応への切り替えも設けます。