飲食店の電話AIは「電話に出る」だけでは注文自動化になりません。席予約、テイクアウト、注文、変更、店舗情報を別々のTransactionとして扱い、聞き取り、復唱、確認、確定の順で状態を進めます。特に注文は、AIが理解した時点では未確定です。
Restaurant Order State Machine：Draft → Confirm → Commit
確認前のDraftは変更でき、Confirmでは受取時間や合計の前提を確認し、Commitで一度だけ注文システムへ送ります。この分離が、聞き間違いと二重注文の両方を抑えます。
予約と注文は同じ電話でも別のRoutingにする
| 用件 | 必要な確認 | 人へ渡す条件 |
|---|---|---|
| 席予約 | 人数・日時・連絡先 | 団体・特別席 |
| テイクアウト | 商品・数量・受取時間 | 売切れ・特殊注文 |
| 変更・キャンセル | 予約・注文候補 | 期限外・照合不可 |
| 営業時間・アクセス | 確定情報 | 臨時変更 |
| アレルギー | 店の公式方針案内 | 判断・個別相談 |
電話予約自動化は予約条件の設計、ここでは注文という取引の確定管理に重点を置きます。
Exception Matrix：店舗が忙しい時ほど自動化の境界を守る
売切れ、メニュー変更、営業時間外、大量注文、アレルギー、特殊注文、決済失敗、店舗混雑は、決め打ちで確定しない例外です。人間への転送または折り返しCaseへ移し、AIが「承りました」と誤って約束しない文言を用意します。同時着信の受付設計を組み合わせ、忙しい時間でも着信順・優先用件・人への通知を整理します。
営業時間外と店舗通知の設計
閉店後に受けた予約・注文を翌日へ持ち越す場合、確定なのか仮受付なのかを明示します。営業時間外の電話対応のルールとして、いつ店舗が確認するか、SMSなどで何を案内するかを決めます。店舗システムへ送る時は、注文IDを冪等キーにして二重送信を防ぎます。
導入前のTransaction Checklist
①メニュー・売切れ情報の正本、②受取可能時間、③予約・注文の確定権限、④復唱する必須項目、⑤アレルギー時の案内、⑥変更・取消期限、⑦店舗通知の失敗時、⑧人への転送、⑨混雑時の案内、⑩二重注文の照合を確認します。CRM等と連携する場合はAI電話とCRMの連携設計の最小権限・監査の考え方を適用します。
電話注文の実会話ケース：注文は復唱前に確定しない
Case 1：注文追加
「唐揚げ弁当に味噌汁も付けたい」には、AIはDraft cartに追加し、商品・数量・受取店舗・受取時間をまとめて復唱します。客が「それでお願いします」と確認した後だけCommitし、Order IDを発行します。追加前の合計を読み上げて既存注文を二重確定しません。
Case 2：聞き取り訂正と受取時間変更
「やっぱり二つではなく一つ、18時で」は、直前のDraftを表示して数量と時刻を置き換え、差分だけでなく最終cart全体を復唱します。すでにCommit済みなら、Order IDと店舗側の受付状態を照合し、変更可能かを人または店舗APIへ確認します。
Case 3：売切れと代替品
Menu sourceが売切れを返した時、AIは勝手に近い商品へ置換しません。「○○は現在売切れです。△△へ変更しますか」と別のDraftとして同意を取ります。在庫情報の取得時刻が古い、または店舗ごとに違う時は、仮受付と折返しに切り替えます。
Menu Source of Truthと店舗別設定
| 情報 | 正本 | 店舗別に持つ理由 | 取得不能時 |
|---|---|---|---|
| メニュー・価格 | POSまたは注文基盤 | 店舗・時間帯・税率が異なる | 価格を約束せず確認へ |
| 売切れ | 在庫・POS | 同名商品でも在庫が違う | 代替を勝手に確定しない |
| 受取時間 | 店舗の調理能力・営業時間 | 混雑、休憩、臨時営業がある | 最短時間を推測しない |
| アレルギー案内 | 店舗の公式方針 | 提供可否は店舗判断が必要 | 人へ転送または公式案内 |
会話AIの知識ベースは説明用、注文確定の正本はMenu・在庫・店舗設定です。店舗番号または選択結果をすべてのTool callへ持たせ、別店舗の価格・受取時間を混ぜないようにします。
Draft → Confirm → Commit → Order IDを状態として残す
Commitは通話ID・店舗ID・cart versionを冪等キーにして一度だけ実行します。Timeoutでは二重CommitせずOrder IDの有無を照会します。店舗通知が失敗した時は「注文確定」と言わず、復旧キューまたは人への転送で確認します。
決済を電話AIだけで安易に処理しない
カード番号・有効期限・セキュリティコードを会話で収集してAIログへ流さないことが基本です。注文をOrder IDまで確定した後、決済事業者の安全な決済リンク、既存のPCI準拠フロー、店頭決済などへ分離します。支払失敗時も注文を自動取消しせず、店舗側の状態と顧客への案内を分けます。
AWSの公式技術例から学べる「分離」の考え方
AWSは2026年8月24日、Amazon Connectを電話入口、音声処理、会話オーケストレーション、メニュー・cart・order・locationのバックエンドToolを分離する飲食店電話AIの技術例を公開しました。これは特定製品を推奨するものではなく、電話、会話、注文正本、監視を分離し、Escalateを有人経路へ接続できるという設計上の参考です。
AWS公式：Building a restaurant telephony AI host with Amazon Connect（2026-08-24）
Sample Conversation：会話とCart状態を同時に扱う
以下は実顧客ログではない、設計確認用の架空会話例です。
Case 1：通常のテイクアウト注文
客：「唐揚げ弁当を2つお願いします」
AI：「唐揚げ弁当を2点ですね。お受け取り希望時間を教えてください」
客：「19時くらい」
AI：「本日19時、唐揚げ弁当2点でよろしいですか？」
客：「はい」
この確認で初めてDraft → Confirm → Commitへ進み、注文番号を発行します。
Case 2：注文途中の訂正
客：「ハンバーグ弁当を2つ」
AI：「ハンバーグ弁当を2点ですね」
客：「あ、1つは唐揚げに変えて」
悪い設計はハンバーグ2点＋唐揚げ1点を追加します。正しい設計はDraftを更新し、ハンバーグ1点・唐揚げ1点へ戻して全体を再復唱し、Confirmを取り直します。
Case 3：売り切れ
客：「カツカレーをお願いします」
AI：「申し訳ありません。現在カツカレーは売り切れです」
代替候補はMenu Source of Truthから取得できる場合だけ提示します。「通常のカレーは注文可能です。変更しますか」と確認できても、架空のメニューを生成してはいけません。
Case 4：特殊注文・アレルギー
「卵アレルギーですが大丈夫ですか」には、LLM知識だけで安全と断定しません。公式Allergen DBと店舗ルールが揃っていない場合は、人へ引き継ぐか、公式の確認導線を案内します。
Restaurant Order State Machine
「はい」が二度聞こえた場合、通信Retry、Webhook再送でも注文を二重作成しないよう、Commitには通話ID・店舗ID・cart versionで構成するIdempotency Keyを使います。
関連論点を自社の受付へ落とし込む
電話予約を自動化、営業時間外の電話対応、同時着信の受付設計、人間への転送、AI電話とCRM連携も併せて確認し、入口の会話だけでなく、記録、例外、担当者への引継ぎまで一つの流れとして整理してください。
よくある質問
AIが聞き取った注文はそのまま確定してよいですか？
いいえ。商品、数量、受取時間、アレルギー確認の要否を復唱し、明示的な確認後に確定します。
売切れや特殊注文はどう扱いますか？
リアルタイム在庫を安全に照会できない場合は確定せず、代替案内または店舗スタッフへ引き継ぎます。