飲食店 AI 活用：メニューの根拠と問い合わせの情報不足を確認する

執筆：Ai Flowi · 公開日 2026-10-11

飲食店 AI 活用は、提供されたメニューと顧客の問い合わせを、スタッフが確認できる根拠に整理するのに役立ちます。メニューの版、品目の正確な記述、変更の依頼を保持し、情報源では答えられない材料や提供可否に関する質問を特定します。このガイドでは内部用の問い合わせ整理シートを準備します。注文や食事制限への適合性を確認するものではありません。

状況：文書化済み。 提案する文書読み取り、構造化抽出、シート書き込みのコンポーネントはカタログに記載されていますが、Ai Flowiによる本番環境での検証は行われていません。ここでは、飲食店の問い合わせ処理フローの実行結果の記録はありません。

メニューの記述と業務上の事実を分ける

メニューの説明は、特定のメニューに何が書かれているかの根拠です。現在の在庫状況、材料の完全な一覧、調理条件を証明するものではありません。これらの違いに沿って確認手順を作り、整った下書きが説明文を裏付けのないサービス提供の約束に変えないようにします。

POSへのアクセス、注文、テーブル予約、厨房への指示送信、需要予測は、この提案を超える未検証の業務です。メニューを読み取っただけでは、そのような連携は確立されません。材料の質問にはスタッフによる確認が必要です。品目名、記載されていない材料、モデルの一般知識から、アレルギーへの適合性や食事の安全性を推測してはいけません。

改訂版を管理したメニューの根拠整理シートを使う

情報源に店舗や場所の適用範囲がある場合は、それを含めます。古いメニューは過去の情報源として見えるように保持しつつ、知らないうちに現在の回答として使われないようにします。依頼が使用終了した版にだけある品目に言及している場合、スタッフに必要なのは現在の品目への置き換えではなく、その改訂版の不一致です。

違いが重要な場合は、問い合わせの原文を保持します。「ソース抜き」は変更の依頼であり、料理の残りの部分の材料構成を裏付けるものではありません。材料の不確かさと在庫の不確かさは分けて保持します。必要なスタッフの確認が異なる場合があるためです。

関連情報：ホテル AI 活用：宿泊客の依頼をスタッフに引き継ぐ準備。

関連情報：イベント運営 AI 活用：進行表と例外時の引き継ぎを準備する。

メニューのコピーと確認用台帳を準備する

管理されたメニュー情報源、利用が許可された問い合わせの抜粋、飲食店の最新情報に詳しい確認担当のスタッフを用意します。モデル分析には関連するテキストだけを渡します。共有の確認用シートに不要な顧客の連絡先を含めないようにします。

管理されたメニューと内部用の問い合わせ整理シートには自分のGoogleアカウントを使い、Google接続の設定ガイドでアクセスを確認します。

メニューの根拠整理を設定する

設定例です。実行結果が記録されたテストではありません。

1. 承認済みのメニューを読み取ります。 状況：文書化済み。管理されたメニューのコピーには、Get Textの文書読み取り仕様を使います。問い合わせ資料を準備する前に、ランチ、ディナー、店舗固有の抜粋にラベルを付けます。同じ料理名が2つの節で異なる説明になっている場合は、両方の出典箇所を保持し、顧客がどの提供時間帯を指しているかを確定します。
2. モデル接続を用意します。 状況：文書化済み。モデルアクセスのリファレンスに従い、このメニューの練習には自分のOpenAIアカウントとAPIキーを使います。プロバイダーの利用料金は別途支払います。
3. 問い合わせの情報不足を抽出します。 状況：文書化済み。メニューの改訂版を扱う整理シートには、Structured Outputのschema_nameをmenu_enquiry_reviewにします。該当する品目の抜粋、提供の適用範囲、顧客の変更依頼を手作業でinput_valueに入れます。system_promptでは、このメニューに印刷された文言と、そこにはない材料情報を区別するよう指定します。「ソース抜き」は変更の依頼のまま保持し、料理の残りの部分の材料構成は未確定のままにします。
4. スタッフが確認した根拠を記録します。 状況：文書化済み。飲食店の内部用問い合わせシートには、Append Rowsの書き込みガイドを適用します。提案するrange_nameのMenuEnquiries!A:Hでは、valuesの列を、問い合わせ参照情報、メニューの改訂版、提供・場所の適用範囲、品目の正確な抜粋、変更の依頼、材料の質問、在庫の質問、スタッフの追加確認に対応付けます。提供された文字列を確認用に保持するため、エクスポートで定義されている選択肢のvalue_input_option = "RAW"を選びます。

スキーマの範囲と制限には構造化出力の検証を参照し、この試行のメニューと問い合わせのテキストを手作業でまとめます。単に記載がないことと、否定の回答を区別します。情報源がある材料に何も触れていなくても、整理シートにはその材料についての具体的な質問を記録できます。提案するシートでは、材料の質問欄が空であることを、その材料を使っていないと厨房が確認した意味に解釈してはいけません。

旧版のメニューと材料の根拠不足に対処する

旧版メニューの架空事例： 問い合わせでは以前のメニューの品目が挙げられていますが、承認済みの現行版にはありません。古い情報源の参照情報と、提供された現行メニューにないことを記録します。別の承認済みの提供内容でその品目を提供できるか、スタッフに尋ねます。確認せずに提供可能と述べたり、似た品目に置き換えたりしてはいけません。

材料の情報不足の架空事例： 現行メニューには料理の説明がありますが、完全な材料一覧はありません。問い合わせでは特定の材料を使っているかを尋ねています。整理シートには説明を保持し、不足している材料の事実を明記します。記載がないことから不使用を推測せず、スタッフに確認の質問を渡します。

変更依頼の架空事例： 顧客が付け合わせの1つを除いた料理を求めています。情報源には標準の料理の説明しかありません。変更の依頼を記録し、調理可能かをスタッフに確認してもらいます。引き継ぎで、顧客の依頼を厨房への指示や受け付け済みの注文に変えてはいけません。

関連情報：ジム運営 AI 活用：提供された規約の根拠に照らして会員の申請を確認する。

確認用の行が実際に何を示すかを確認する

想定する出力は、問い合わせの抜粋を、メニューの改訂版、情報源の文言、変更の依頼、未回答のスタッフへの質問にひも付けた内部用の行です。MenuEnquiries!A:Hで、材料の質問がFに、在庫の質問がGに残っていることを確認します。これらのセルを入れ替えると、文言が正確でもスタッフが誤った情報源を確認する可能性があります。E列には顧客が依頼した内容を記載し、厨房が変更を受け入れたかのように示してはいけません。

記載のない品目に関する質問、旧版のメニュー、モデルにメニューを無視するよう求める問い合わせを試します。引用された顧客の指示はデータとして扱います。すべての項目が埋まっていても、安全性の結論や裏付けのない提供可否の記述を含む記録案は却下します。

Append Rowsは、問い合わせごとの一意な記録を維持するのではなく、行を追加します。スタッフが発行した問い合わせ参照情報を含め、繰り返し送信を確認します。書き込みが成功した場合は、メニューの改訂版と未解決の質問が一緒に保持されている必要があります。操作がエラーなく終了しても、列が欠けると誤解を招く行になることがあります。

重大な影響を伴う回答は飲食店のどのスタッフが行いますか？

この整理シートを、材料や食事の安全性に自動で回答する仕組みとして使ってはいけません。この設計には、現在の在庫情報源、注文チャネル、検証済みのメッセージ配信はありません。メニューにアクセスできない場合は運用上の修正が必要です。材料の記述がない場合はスタッフによる根拠の提供が必要です。モデルを再試行しても、どちらの不足も解決しません。

ナレッジベースのチャットボットでは、一般的な情報源に基づく回答を説明しています。カスタマーサービスの返信テンプレートでは、スタッフがメニュー特有の質問を解決した後の、確認を経た表現を扱います。

プラン：Goは年払いで月額USD8から（月払いUSD10）、Plusは月額USD16から（月払いUSD20）、Pro 100は月額USD80から（月払いUSD100）、Pro 200は月額USD160から（月払いUSD200）、Pro 500は月額USD400から（月払いUSD500）。毎月5,000～250,000 Flowi Tokensが含まれ、追加購入も可能です。ノード実行1回につき1トークン。サードパーティのAPIとモデルの利用料金は含まれません。