会話の情報源を、生成AIモデルが学習済みの一般的な知識と、自社のメニューマスターデータの二つに切り分けた設計が、この仕組みを実店舗に出せる水準に引き上げたと考えられます。メニュー情報はAzure Cosmos DBに置いてAzure AI Searchで引き当てるRAGの構成とし、商品に関する具体的な回答は必ず自社データを経由させています。生成AIに対する漠然とした不安の中身は、多くの場合「商品の説明が事実と違ったらどうするか」という一点に集約されます。その部分だけをデータ参照に固定してしまえば、残る自由な会話は多少ゆらいでも実害が小さい。この線引きが、実店舗での運用を可能にしたのではないでしょうか。
キャラクター設定に相応の手間をかけた判断も、見逃せない要素です。クリオネに似た姿のロボットが「研修中」のバッジを付け、北極から光るタブレットに吸い込まれてガストで働くようになった、というバックストーリーまで用意されています。奇抜さを抑え、少しだけ抜けた雰囲気を残すという方向づけは、UI/UXを担当するチームが握っていました。AIの回答が完璧ではないことを前提に置いたうえで、その不完全さを欠陥ではなく親しみに変換する設計であり、機能の説明では埋められない「話しかけてよい相手なのか」という心理的な障壁を下げる役割を果たしています。
会話ログを毎日確認し、必要に応じてプロンプトを調整していく運用も、成立を支えた柱です。この積み重ねでプロンプトはかなりのトークン数まで膨らみ、現在は内容を整理してよりシンプルな形へ戻す作業が進められています。作り込んでから削るというこの往復は、実際の来店客の入力を見ないと必要な指示が判断できない領域で、机上の設計より現場のログを優先した進め方だと読み取れます。