タイ料理店

顧客はオープンキッチンのタイ料理店です。メニューの半分は説明が必要でした。馴染みのない食材、辛さの段階、ソース、言葉だけでは想像しづらいデザートなどです。客層は多様で、店の言語が母語ではない旅行者と、「タイを味わいたい」地元客が来店します。従来の紙メニューには3つの問題がありました。価格や品目を変更するたびに再印刷が必要ですぐ古くなること、料理を写真で見せられず別紙を挟む必要があること、そしてスタッフの負担が大きいことです。ピーク時には注文するだけで5〜10分待ち、「聞き違えて別の料理を作る」ことも頻繁でした。注文とシフト別の金額も手作業で集計していたため、オーナーは店内の状況をリアルタイムに把握できませんでした。初来店客のかなりの割合が訪れるGoogleマップの店舗情報に、公開メニューのリンクを載せたいという希望もありました。

一つのメニューを二つのモードで運用し、注文が「伝言」を介さずキッチンに届くシステムを設計・構築します。

課題は4つです。第一に、Googleマップ、SNS、販促物に掲載できる固定リンクの公開メニュー。第二に、テーブルのQRを読み込むと同じメニューが注文画面になり、品目を選んでスタッフ用Telegramボットへ送信できる専用リンク。テーブル番号はリンクに含めます。第三に、全注文を集約して記録・集計するスタッフ用Telegramボット。第四に、オーナーが開発者なしで品目を追加・編集・削除できる管理画面です。スタッフの低性能な端末でも動作し、客にはスマートフォンのカメラ以外を求めないことも条件でした。

客からは「メニューが載った普通のサイト」に見えますが、裏側には二つのアクセスモードと、客・スタッフ・メニュー管理者という3つの役割を考えたロジックがあります。技術的な判断はすべて、注文の手間をどう減らすかという問いに答えるものでした。

• 一つのコンテンツ基盤に二つのアクセス範囲を設ける構成を設計しました。公開リンクはカテゴリ、写真、食材、辛さ、価格を載せた案内メニューを開き、注文ボタンは表示しません。GoogleマップやSNSで料理を紹介するための画面です。テーブルのリンクには注文モードを有効にするパラメータが含まれ、カート、料理へのコメント、注文送信が表示されます。コンテンツは常に一つなので、同期は不要です。
• 公開メニューを高速でレスポンシブなページとして構築しました。客はGoogleマップの店舗情報から、店の近くで屋外のモバイル回線を使って開くことも多いため、1秒で表示されます。料理写真、辛さと食材を記した説明、スープから飲み物・デザートまでのカテゴリ、最新価格を掲載しました。ホスティングを店内ネットワークの外に置いたため、店のWi-Fiや混雑状況に左右されず安定して開きます。
• テーブルごとに固有のQRコードを作成し、リンクにテーブル番号を埋め込みました。客がリストから「N番テーブル」を選んだり、スタッフに席を伝えたりする必要はありません。リンクからシステムが自動で席を認識し、同種システムでよくある間違いを減らします。QRプレートはテーブルのどの席からも読み取りやすい位置に置きました。
• 登録なしで使えるカートと注文送信を実装しました。客は品目を追加し、「ピーナッツ抜き」「辛め」「ソースは別添え」などのコメントを入力し、内容を確認して送信します。注文は固有番号とテーブル番号付きでスタッフ用Telegramボットに届きます。アプリのインストール、電話番号入力、アカウント作成は不要で、スキャンから送信までは1〜2分。どの代替手順よりも意図的に短くしました。
• スタッフ用Telegramボットを開発しました。注文番号、テーブル、品目、客のコメント、合計金額を含む注文がリアルタイムで届きます。受信だけでなく、シフト・日別の注文履歴、メニューや品目別の金額、再送、処理状況も管理します。スタッフが業務端末で普段から使っているTelegramなので、別ソフトの導入も研修も不要です。見慣れたチャットがそのまま画面になります。
• メニュー管理画面を構築しました。品目の追加、価格・説明・写真・カテゴリの編集、削除、在庫の有無の即時切り替えができます。一つのメニューを共有しているため、変更は公開メニューと注文モードの両方に即時反映されます。オーナーはスマートフォンから自分で品揃えを管理でき、開発者も細かな変更ごとの依頼も不要です。
• 店内で起こる細かな状況も考慮しました。注文された品目が厨房で売り切れた場合、管理画面からすぐ非表示にでき、注文モードから消えます。誤って同じ注文が二度送られた場合、スタッフは両方を確認して重複分を拒否できます。価格変更は一か所を直すだけで全体に反映されます。こうした日常の場面こそ、システムが実際の店で定着するかを左右します。
• システムを公開してスタッフをトレーニングしました。QRの印刷と設置、ボットの使い方の説明、最初の数シフトへの立ち会い、客とスタッフからのフィードバック収集、実運用に基づく画面の細かな調整を行いました。

成功を決めたのは3つの設計判断です。第一は「メニューは一つ、モードは二つ」。店が管理するコンテンツは一つだけで、公開表示と注文内容が食い違いません。第二は、スタッフの端末としてTelegramを使うこと。機器費用はゼロで、注文はスタッフが普段いる場所へ届き、注文履歴も「帳面」なしで自動保存されます。第三は、QRリンクにテーブル番号を埋め込むこと。システムが自力で分かることを客に尋ねません。システム全体の費用は紙メニューを一度全面再印刷するより安く、継続利用のサブスクリプション、自社サーバー、店内専用機器も必要ありません。

次の段階として店舗に提案すること：

• メニュー内での決済。スタッフを待たずにテーブルで会計でき、テーブル回転が速くなり、ピーク時の会計待ちもなくなります。
• 多言語対応。旅行者向けに料理の説明を英語などへ翻訳し、同じコンテンツ基盤で言語別の表示を追加します。
• GEO（Generative Engine Optimization）での露出。料理、メニュー、雰囲気の情報を構造化し、AIアシスタントが「タイ料理を食べるならどこ？」に答える際に店を正しく紹介できるようにします。レストラン選びでこの経路を使う人は増えています。
• メニュー分析。見られているのに注文されない料理、客単価を押し上げる品目を把握し、品揃えや季節メニューを改善します。