オートリザーブ問題から考える、AI電話予約の設計条件

AIによる電話予約を業務にするなら、予約を成立させる会話だけでなく、電話をかけない条件まで設計する必要があります。むしろ後者が先です。再架電の上限、店舗の拒否状態、予約の確定条件、情報修正の責任が曖昧なままだと、個々の会話が成立しても運用は続きません。

AutoReserve（オートリザーブ）は、利用者に代わってAIが飲食店へ電話し、予約を取るサービスです。電話予約しか受け付けていない店も、利用者から見ればオンラインで予約できます。一方、店舗側からは繰り返しの着信や誤った店舗情報が報告されています[1]。ここで扱うのは、このサービスの是非ではありません。公開されている事例と運営側の説明から、AI電話予約を業務システムとして運用するための設計条件を考えます。

再架電は「成功するまで」ではなく停止条件から決める

報道では、店舗が電話に出られない場合に、何十分も架電が続いた例が紹介されています[1]。

自動架電の仕組みは、発信のキュー、かけ直しの制御、かけない相手を持つ抑止リストの3つに分かれるのが一般的です。会話そのものは、その上で動く別の層になります。たとえば、かけ直しを終える条件を「相手が応答した」ではなく「予約が取れた」に置けば、応答が取れないあいだ再試行が続く設計になります。実際の実装は公開情報からは分かりません。それでも、こうした挙動を避けるには停止条件を仕様として書いておく必要があります。

運営側は、営業中で電話を受けられない店舗や、営業時間外でも予約を受け付ける店舗があるとして、時間外でも予約確認の連絡をする場合があると案内しています[3]。発信のタイミングを、店舗の営業時間ではなく利用者のリクエストを起点に決めているということです。実際の実装は分かりません。それでも、回数と間隔の上限を発注仕様に書く理由としては足ります。

自動架電では、接続率を上げる目標だけを置くと再試行が増えます。発注仕様には、少なくとも次の条件が要ります。

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

つながらなかった理由も区別します。話中、留守番電話、着信拒否、応答直後の終話は、どれも結果としては「予約が取れなかった」です。それでも、次にかけてよいかはそれぞれ別に決まります。留守番電話の判定自体が誤りうる点は「AIの電話は、留守番電話をどう見分けるのか」に記載しています。

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

店舗の拒否は会話履歴ではなく発信制御に反映する

掲載の側から見ます。店舗からは、削除を依頼してもページが残るという声が出ています[1]。運営会社は、店舗ページを公開情報や利用者からのフィードバックで構成しているため、ページの削除には対応できないと案内しています[2]。店舗情報の修正については、問い合わせフォームからの連絡と、店舗ページからの修正提案を受け付けるとしています[2]。

架電の側には、別の説明があります。予約受付を拒否している店舗に予約画面が表示される例が報告されています[1]。連絡手段については、自動音声のほかに、端末からワンタッチで承認・却下ができるウェブアプリでの送客があり、人間のオペレーターによる電話も可能と案内されています[4]。

「店舗情報を掲載するか」と「その店舗へ予約電話をかけるか」は、分けて扱います。ページを残す方針でも、架電拒否を受けた番号を発信対象から外すことは別の制御です。

拒否状態は、発信前に必ず参照されるデータとして保持します。オペレーターのメモに書くだけでは、次の発信に効きません。「AI音声のみ拒否」「予約代行からの電話をすべて拒否」「特定時間のみ受付」のように状態を分け、有効期限や変更履歴も残します。単位は電話番号だけにしません。回線が増えたり番号が変わったりすると抜けるので、店舗の識別子でも持ちます。新しい予約要求が入るたびに拒否状態が上書きされる設計では、停止の申し出が次の架電に反映されません。

公正取引委員会は、消費者が投稿・編集できる基本的な店舗情報や口コミについて、客観的に正確でないと判断できる場合には、加盟店でない飲食店からの削除・修正要望にも特段の条件なく応じることが望ましいとしています[5]。対象は掲載情報で、架電の話ではありません。この考え方を予約システムに当てはめるなら、修正依頼の受付窓口、確認手順、反映期限、そして発信停止との連携までが設計の範囲になります。

予約の完了条件と例外処理を利用者にも見せる

AIが予約日時を聞き取れても、予約が成立したとは限りません。定休日や営業時間が誤って登録されていたために予約が入り、当日に利用者が来店した事例が報じられています[1]。アレルギーや料理の好みなど、定型項目だけでは処理しにくい要望を店舗が確認できないという指摘もあります[1]。

予約状態は「依頼を受け付けた」「店舗へ発信中」「店舗が承諾した」「確認できなかった」を分けます。利用者の画面でも、「依頼を受け付けた」と「店舗が承諾した」を同じ「予約済み」として見せないようにします。発注側は、どの応答をもって確定に遷移するのかを決めます。日時や人数の復唱が一致しないとき、条件付きの返答が来たときに誰が確認するのかも、受入テストに含めます。

アレルギー対応、コース選択、席の条件を自由な会話だけで完結させると、伝達漏れを検証しにくくなります。定型化できない要望が出た時点でオペレーターへ切り替える、店舗から受けた条件を利用者に再確認してから確定する、といった分岐が必要です。会話が想定どおり進まない場合の設計は「AIからの電話は、なぜ台本どおりに進まないのか」にも記載しています。

AI電話予約の品質は、音声が自然かどうかでは判断できません。発注時には、成功率と並べて、店舗別の発信回数、拒否後の発信件数、確定前の不一致、有人対応への切替件数を確認します。電話を成立させる機能と、電話を止める機能は、同じ要件表で扱います。それが運用を続けるための前提です。