「任せるほど、線引きを先に」。すかいらーくが人・AI・ロボットで目指す、心地よい接客

2日目の最後のセッションには、すかいらーくホールディングス IT 本部から、カスタマー DX グループ ディレクターの池田裕氏と、IT 企画グループ AI 推進リーダーの藤本祥恵氏が登壇した。題は「「繋がる」からその先へ。AI がもたらす接客の価値創造」だ。

左からすかいらーくホールディングスの池田裕氏、藤本祥恵氏

最初に話したのは藤本氏だ。すかいらーくグループは、ガストをはじめ約3,000のファミリーレストランを中心に運営し、年間約3.5億人が来店する。店にはすでに多くのデジタルの道具が入っている。お客さまから見えるものだけでも、テーブルのデジタルメニューブック、セルフレジ、そして猫の形をしたロボット「ベラボット」がある。

目指すのは、お客さまの「心地よい」

店員がしきりに接客してくることよりも、行ったときに気持ちよく迎えてもらえること。それがよい経験だという。入った瞬間に気づいて、「いらっしゃいませ」と軽くあいさつしてくれる。お皿を下げてほしいといった、ちょっと困ったサインに気づいて、さっと動いてくれる。必要なときに、必要なタイミングで手を貸してくれる。そうしたサービスが自然にできる店が、心地よい店だと藤本氏は言う。

ただ、いつもそれができているわけではない。入っても気づいてもらえず、席は空いていそうなのに案内されない。呼んでも店員が忙しそうで、なかなか来ない。店員の側も、呼ばれているのは分かっていても、手が離せないことがある。混み具合に備えて余分な人を置いておくことはできないし、トレーニングがいつも完璧ということもない。どの時間帯に来ても満足して帰ってもらうために、その満足に技術でどうつなげるか。それが自分たちの挑戦だ、と藤本氏は話した。

「効率化だけじゃ味気ない？」：人と AI が協調するホスピタリティへ

ここから池田氏が話を引き取った。すかいらーくで DX（デジタルによる変革）が一気に進んだのは、コロナをきっかけとした2019年から2022年ごろだという。人と接しない接客が好まれた時期に、注文用の端末（社内では DMB と呼ぶ）や、猫型の配膳ロボットが入った。この日は、単なる効率化にとどまらず、人と AI が協調して新しいホスピタリティを生むためのロードマップを紹介したい、と池田氏は言う。スライドの題は「「効率化だけじゃ味気ない？」”Connected”から人とAIが協調する”Hospitality”へ」だ。

取り組みは3つのフェーズで進む。1つ目は「Connected Restaurants」、すべてをつなぐ段階だ。API（システム同士をつなぐ窓口）を整え、イベントバス（店で起きた出来事を各システムに配る共通の通り道）を共有して、DMB や案内システムといった機器を連携させる土台を作った。2つ目は「Detection & Visualization」で、AI カメラなどのセンサーを使い、店のいまの状態をデジタルで捉える。スライドの言葉では「「店舗の今」を定義する」段階だ。3つ目は「AI Collaboration」で、AI コンシェルジュやスマートインカムを使ったマルチエージェントの基盤（複数の AI が役割を分けて連携する仕組み）を通じて、AI が店全体を理解したうえで、スタッフとタイムリーに協調する環境を目指す。インカムは、店員が身につける無線の通話機のことだ。

「効率化だけじゃ味気ない？」2024〜2028年のロードマップ

いまは「つなぐ」段階：店の機器の状態をリアルタイムで共有する

池田氏によれば、いまはその1つ目、Connected Restaurants の段階にある。店の機器やアプリを、Firestore（Google のデータベース）を介してつなぎ、状態が変わったらすぐに知らせる仕組み（リアルタイムリスナー）で共有する。お客さまの呼び出し、待ちの順番、予約の情報が、関係する機器にすぐ伝わる。例えば、セルフレジや DMB から入った情報は、店に5〜6枚貼ってある呼び出しの通知板にすぐ表示され、キッチンやフロアのスタッフが共有できる。

配膳の猫型ロボットもつながっている。ロボットが客席に近づくと、その状態が DMB に伝わり、「もうすぐ料理が到着にゃ」といった表示が出る。店の中のさまざまな情報を持ち、見えるようにすることで、店の動きを滑らかにし、運営を効率よくしている。それが現在の状況だと池田氏は言う。

店の機器を API 基盤でつなぎ、呼び出しや待ち順を共有する

お客さまとの接点はデジタルでつながっている。そのため、来店から会計までの各段階の状態を、リアルタイムでつかめる。新しく測れるようになった指標もある。DMB については、お客さまが食べたいメニューにたどり着くまでの時間やタップ数、おすすめ商品が選ばれた割合。店舗の運営については、外国籍のお客さまの割合、テーブルの稼働率、片付けにかかる時間。これらがすべて KPI（目標にどこまで近づいたかを測る指標）として取れるようになったという。

次は「サービスの品質の定義と可視化」：「いらあり」を音で測る

次のフェーズを、池田氏は「ディテクション＆ビジュアライゼーション」と呼ぶ。検知と可視化という意味だ。テーマは「サービスの品質の定義と可視化」である。レストランがいちばん気にかけているのは、お客さまのネガティブな体験だという。料理の提供の遅れは、池田氏によれば十数年前からデジタルで測れるようになっている。今回挑んだのは、挨拶がどこまで徹底されているかである。入店のときの「いらっしゃいませ」と、退店のときの「ありがとうございました」。スライドでは、この2つをまとめて「いらあり」と呼んでいる。

取り組みは、Google Cloud の TAP の協力を得た PoC（本格導入の前に効果を確かめる試行）として始まった。TAP は Tech Acceleration Program の略だ。スライドの説明では、Google Cloud の専門家と設計や試作品づくりを進める、内製化（自社で開発できるようにすること）を支えるプログラムである。

入店のときの挨拶を、ある時点から切り取り、音声データだけを貯めていく。貯めた音声は、Google Cloud のファイル置き場である GCS（Cloud Storage）に置く。それを BigQuery の「オブジェクトテーブル」として読み込む。BigQuery は、大量のデータを表として扱えるデータベースだ。オブジェクトテーブルを使うと、音声や画像のようなファイルを、置き場所から動かさずに表の1行として扱える。その行ごとに AI モデルで挨拶があったかを判定し、結果を列として一括で保存する。最後に Looker でグラフにする。池田氏は、この仕組みを最初に教わったとき「非常に感動しました」と振り返った。

「「いらあり」検知 - Google TAP 2025」のスライド

ただ、去年の PoC の段階では精度が出なかった。当時は LLM（大規模言語モデル）や、音声を文字に起こす Speech-to-Text のモデルで試したが、店内の雑音の影響が大きく、判定の精度が上がらなかった。今年の春ごろから使っているのは、音のパターンを聞き分けるモデルである。池田氏によれば「ワードスポッティング」と呼ばれる方式で、これでやっと精度が95％以上になった。ワードスポッティングは、話をすべて文字に起こすのではなく、決まった言葉が出てきたかどうかだけを聞き分ける方式だ。いまは、本格的に店舗へ広げるための最終的な調整をしている段階だという。

次に挑んだネガティブな体験は、品切れだ。目をつけたのは、コーヒーサーバーのミルク切れの検知である。店では、ミルクが切れるタイミングを新人に音で教えているそうだ。空気を吸い上げるような音がするのだという。

これを AI や IoT（モノをネットにつなぐ技術）で捉えるには、課題が2つある。どうやって検知するかと、どうやって知らせるか（通信）だ。検知の方法は、池田氏によればおそらく4種類。重さを量るセンサー、光のセンサー（液体があるかを見るものと、気泡を見るものがある）、AI カメラ、そして先ほどの音だ。ミルクはサーバーの中の冷蔵庫に入っていて、外からは見えない。そのため AI カメラは使いにくい。いまは、重さか光のセンサーで液体が入っているかを判定する方法と、管を通る気泡を捉える方法の2つで実験を進めている。池田氏は、昔からあるテーマなので「良い方法があればぜひ皆さまに教えていただきたい」と会場に呼びかけた。

スライドによれば、対象はミルクだけではない。シロップやコーヒー豆、氷といった食材の欠品も自動で検知し、欠品や補充の「イベント」を、呼び出しの通知板やスタッフの端末にリアルタイムで送る。

最後は「AI コラボレーション」：人にしかできない温かいサービスに専念できる環境へ

最後のフェーズが「AI コラボレーション」である。お客さま、店舗のスタッフ、配膳ロボット、サービスの状態を、もっとよいタイミングでつかみ、スタッフが次のサービスに移れるようにする基盤をつくる。

その中心が「マルチエージェント協調基盤」だ。エージェントは、状況を見て自分で判断し、動く AI のこと。店で起きる出来事は、すべて「イベント」としてリアルタイムに共有される。お客さまの来店と退店、テーブルの使われ方、機器の状態などを、共通の「バス」を通じて1か所で把握する。そのイベントを見て、エージェントが状況を判断して動く。ロボットへの連携や通知、次の作業の割り当てといった調整を、AI が裏側で自律的にこなす。

これによって、スタッフは次にどの作業をすべきかの判断や調整に追われず、目の前のお客さまへの接客に集中できる。お客さまのちょっとした様子に気づいて声をかける。気持ちのよい笑顔で迎える。池田氏はそれを、「人にしかできない温かいサービスに専念できる環境」と表現した。

紹介されたのは、今年の TAP で Google の支援を受けてつくったプロトタイプである。お客さまが会計を終えた場面だ。エージェントが「12卓、15卓がお会計済みです。最終下げをお願いします」と知らせてくる。スタッフが「猫ロボ、12卓へいくよ」と言うと、猫型ロボットが「了解にゃ」と答えて12卓へ向かう。スタッフも12卓へ行き、下げた食器をロボットに載せて「猫ロボ、下げ物洗い場へ行って」と頼む。ロボットはまた「了解にゃ」と答えて、洗い場へ運ぶ。スタッフはそのまま15卓へ移り、こちらは自分で下げて戻る。人とロボットが手分けして、2つのテーブルを片付けるシナリオだ。

仕組みは、同じスライドの右側に描かれている。スタッフは、店員同士が話すためのインカムを付けている。使っているのは Buddycom だ。インカムの音声は Buddycom の API で受け渡され、呼びかけの言葉（ウェイクワード）で AI が起動する。会話を受け持つのは Gemini Live API で、Gemini（Google の生成 AI）と声でやり取りしながら、必要な「道具」を呼び出せる。

この呼び出し（Function Call）を受けるのが「音声オペレーション」のエージェントで、猫ロボを動かす、席の状態を答えたり更新したりする、中間下げや最終下げを指示する、といった役を持つ。もう1つの「営業状態サポート」のエージェントは、入店、注文、調理、決済の情報をまとめて、次にやるべきことをスタッフに働きかける。どちらも Firestore を読み書きし、入店、注文、調理、決済、席、猫ロボの状態をそこで共有する。図はこれを「共通コンテキスト」（いま店で何が起きているかという前提）と呼んでいる。

なお、図の注記によれば、デモでの配膳ロボは猫シミュレーターだった。次の一手が、画面ではなく耳に届く。両手がふさがりがちな飲食の現場には、この形が合っているように思えた。

Google TAP 2026 のプロトタイプ。左がシナリオ、右が仕組み

池田氏は、目指しているのは単なる自動化や省人化ではないと言う。人と AI、そしてロボットがリアルタイムに同じコンテキストを共有し、1つのチームとして協力しながら、お客さまに最高のおもてなしを届ける。それが目指す未来だという。池田氏は最後に、「高い生産性と最高のホスピタリティを両立した、これからの新しい店舗体験を創出していきたい」と述べた。

「任せるほど、線引きを先に」：リスクをゼロにするのではなく、扱いを決めてから使う

後半は、再び藤本氏が「安心して生成 AI を利用する取り組み」を語った。生成 AI は、最初はお客さまとチャットボットで対話するところから始まった。それがいまでは、猫型ロボットを動かし、店の中で動いて働くところまで来ている。できることが増えるのはよい。しかし、お客さまが安心して店を使える環境は守らなければならない。スライドの題は「AI が「話す」から「動く」へ。任せるほど、線引きを先に」。そこには「ガバナンスはブレーキではなく、安全に走れる範囲を決める仕事です」と添えられていた。

では、安心をどう設計するのか。藤本氏によれば、お客さまに生成 AI をこう使った、という先行事例がそもそもほとんどない。だから自分たちで決める。スライドには5つの手順が並ぶ。まず、お客さまにとってどんなリスクがあるかを洗い出し、AI に何をさせて何をさせないかを決める（洗い出す）。次に、起こりうるリスクと影響の大きさを見極める。これくらいなら許容できる、これは絶対にだめ、という見極めだ（見極める）。そのうえで扱いを決める。スライドには「回避・低減・受容を使い分ける」とある。そのリスクが出る使い方をやめるか、起きにくく小さくするか、ある程度は受け入れるかを選ぶということだ（扱いを決める）。決めたら、店舗と用途を絞って出す（限定して出す）。お客さまに出した後は、想定どおりに動いているかを見張り、ログと現場の声で直し続ける（監視して直す）。

藤本氏は、リスクを完全にゼロにするのは難しいと言う。会場の参加者も、リスクを承知のうえで AI を使っているはずだ、と語りかけた。スライドの結びは「リスクをゼロにするのではなく、扱いを決めてから使う。」。注記によれば、土台は2026年4月に策定・公表した「すかいらーくグループ責任ある AI 方針」だ。

「AI が「話す」から「動く」へ。任せるほど、線引きを先に」のスライド

例として挙がったのが、お客さまに出す生成 AI、池田氏も触れた AI コンシェルジュである。スライドでは「Co店長」と呼ばれ、2024年9月からガストとジョナサンの1店ずつで実証している。目的は、タブレット注文で減った「相談できる接客」を、生成 AI との会話で取り戻すことだ。お客さま一人ひとりに何を食べたいかを聞き、おすすめを出す。始めた当時、店で実際におすすめをしてくれる生成 AI は、藤本氏の知る限り世の中になかった。しかもハルシネーション（AI がもっともらしい誤りを答えること）は今よりずっと多く、かなりの頻度で起きた。ゼロにするのは、どう考えても無理だ。

そこで、絶対にだめなものを決めた。アレルギーへの回答である。お客さまが乳製品が入っているかを尋ね、AI が「大丈夫ですよ」と言ってしまう。実は入っていて、アレルギー事故が起きる。それはあってはならない。だから、アレルギーについては AI は答えず、必ず公式の確認先へ案内する。これを100％守れるようになるまで、AI を調整した。

一方で、存在しないメニューを案内するハルシネーションもあった。お客さまが「冷たいものが食べたい」と言うと、生成 AI は期待に応えようとしがちで、本当はないかき氷を「どうぞ」と勧めてしまう。ただ、勧められても、実際には注文できない。AI が間違えることもあるよね、とお客さまに受け止めてもらえるのではないかと考えた。もちろん、ないメニューばかり勧めていたら信用を失い、使いものにならない。そこで AI のキャラクターを「見習い中」にした。たまに存在しないメニューを言っても、見習いなら許してもらえるだろう。そう考えて、この状態でお客さまの前に出したという。スライドの表では、この誤りの扱いは「低減・受容」。メニューのデータに基づいて答えさせて減らしつつ、「見習い中」のキャラクターで AI の限界を伝える、とある。

筆者には、この話がいちばん面白かった。ハルシネーションは、そもそもゼロにできるものではない。アレルギーのように体に関わる誤りは、AI に答えさせないことで断つ。注文できないかき氷のように害の小さい誤りは、キャラクターの設定でお客さまに受け止めてもらう。同じハルシネーションでも、影響の大きさで扱いを分けている。先の5つの手順のうち「見極める」と「扱いを決める」が、そのまま形になった例だ。誤りを技術で消し切ろうとするのではなく、お客さまとのやり取りの中で許される範囲をつくる。接客を生業とする会社らしい発想だと思う。

藤本氏によれば、「この状態ならお客さまに出せる」というガードレール（AI の発言や動きにはめる安全柵）を自分たちで決めて出し、お客さまの反応を見たりログを確かめたりして、言ってはいけないことが見つかればその都度調整する。そうやって品質を担保してきた。スライドによれば、品質管理、営業、総務も評価に加わり、「品質と安全を同じ改善サイクルで高める」という。

「お客様に出す生成 AI｜リスクの扱いを決める（Co店長）」のスライド

人の接客を支える AI は「先に説明してから始める」

もう1つの例は、人の接客を支える AI、池田氏が紹介した「いらあり」である。スライドの目的の欄には、挨拶の実施状況を AI で見える化するのは「監視ではなく、良い接客を増やすコーチングのため」だと書かれている。取るのは、「いらっしゃいませ」「ありがとうございました」の前後の短い区間の音声だけだ。それでも、店の音を取れば、お客さまの声が入るおそれがある。得る情報が大きくなるぶん、扱い方のルールを自分たちで決めて運用する。スライドの見出しは「扱うデータが深くなるほど、確認を厚くする」だ。

手順は4つある。まず、何を取り、いつ消すかを先に決める。スライドによれば、音声は2か月で削除し、学習用の短い抜粋は別に管理する。次に、それが世の中で許されるものかを専門部門と確かめる。法務と総務の確認を経てから始める。そして、お客さまに何をして何をしないかをはっきり示す。店内の掲示と Web で、どんな情報を取り、いつ消すか、お客さま同士の会話は分析しないことを伝えている。最後に、音声には従業員の声も入るため、従業員にも先に説明する。スライドには、人事評価には使わないこと、「AI が検出できなくても、未実施とは断定しない」ことが書かれていた。

この最後の一行がいい。先に見たとおり、「いらあり」の判定の精度は95％以上だ。裏を返せば、取りこぼしは残る。その分を従業員のせいにしないと先に約束しているから、現場はこの仕組みを「見張り」ではなく「コーチ」として受け取れるのだろう。

「人の接客を支える AI｜先に説明してから始める（いらあり）」のスライド

この先、カメラで映像が取れるようになれば、お客さまの情報をさらに多く扱うことになる。スライドには「次の段階」として、「顔の特徴データを扱う実証は、さらにお客様の理解が必要になると想定される」とある。藤本氏は、そのぶんガードレールを敷いていかなければならないと話した。

つながった力を、より良い接客へ

最後に藤本氏がまとめた。スライドの題は「つながった力を、お客様の心地よさへ」。データがつながり、人がつながり、技術がつながる。店の中では、人と AI とロボットが協力し、必要な対応をお客さまに届ける。店の中だけでなく、本部と店舗も部門を越えて情報と知識を使い、「お客様の一皿を支える」。結びの言葉は「つながった力を、より良い接客へ。」。その下には「気持ちよく迎えられ、必要なときに対応が届くお店へ。」とあった。冒頭で藤本氏が描いた「心地よいお店」の姿に、最後の一行で戻ってきた。

取材を終えて

すかいらーくの話は、派手な AI の話からは始まらなかった。最初の段階は、注文端末や呼び出しの通知板、配膳ロボットを Firestore でつなぎ、店で起きることをリアルタイムで共有することだった。ミルク切れの知らせは呼び出しの通知板に届き、マルチエージェントの協調基盤も Firestore を土台に組まれている。エージェントに店全体を理解させるには、まず店の出来事がデータとしてつながっていなければならない。地味な一段目を先に固めていることが、この会社の強みだと感じた。

後半のリスクの話も、先に土台を決めておく点で同じだった。アレルギーには答えさせず、ないメニューは「見習い中」のキャラクターで受け止めてもらう。挨拶の検知は人事評価に使わず、検出できなくても未実施とは決めつけない。どれも、AI を入れる前に、お客さまや従業員とのあいだの約束を決めている。

筆者なら、AI をお客さまや従業員の前に出す前に、まず「これだけは絶対に AI にさせない」ことを1つ書き出してみる。すかいらーくにとってのアレルギー回答にあたるものだ。それが決まれば、残りの誤りをどこまで受け入れるかも話し合える。

開催概要

出典：Agentic AI Summit '26 Fall 公式ページ