あるファミレスの注文をCLIからできるようにしたOSS開発者の話題を見ました。賛否はありましたが、私には「レストラン注文が人間向けUIから少しだけ外へ出た」出来事に見えました。

注文が機械に読める形になれば、そこにはエージェントが入れます。スマホの個人エージェントでもよいし、卓上にいるｽﾀｯｸﾁｬﾝのようなコンパニオンロボットでもよい。メニューを読み、好みや制約をふまえて相談し、最後に安全な形で注文へつなぐ。これはエージェンティックコマースの、かなり日常的な派生形になりそうです。

エージェンティックコマースとは

ここでいうエージェンティックコマースは、人間がECサイトや注文アプリを直接操作する代わりに、AIエージェントへ目的や条件を伝え、商品選定、注文案の作成、支払い手続きの一部を任せる商取引を指します。

Agent Payments Protocol / AP2 の overview では、agent commerce の変化を次のように説明しています。

AI agents are rapidly becoming primary actors, capable of understanding complex user requests and executing multi-step tasks autonomously. In commerce, this translates into a paradigm shift where agents will manage everything from routine purchases and subscription management to complex product research, price negotiation, and dynamic order bundling across multiple vendors.

人間が「これを食べたい」「この条件で探してほしい」と伝え、エージェントが複数の手順を進める。レストラン注文は、その小さくて日常的な例として考えられます。

注文がアクセシブルになるとは何か

レストランの注文は、見た目より複雑です。メニュー、価格、売り切れ、サイズ、トッピング、アレルゲン、注文可能時間、席番号、支払い、提供ステータス。いまのモバイルオーダーは人間が画面を押す前提ですが、エージェントに開くなら、これらを機械可読なスキーマとして扱う必要があります。

たとえば、ユーザーはこう言います。

今日は軽めにしたい。小麦は避けたい。1000円以内で、ドリンクバーはいらない。

この言葉を、エージェントはメニューAPIと個人の食プロファイルに照らして、候補へ落とします。過去に頼んでよかったもの、避けたい食材、辛さや量の好み、同席者の制約も見ます。視覚障害のある人には音声で、聴覚障害のある人にはテキストと振動で、外国語話者には母語で説明できます。

自動化だけでは、注文前の迷いや不安はあまり減りません。何を頼むとよさそうかを一緒に考えられると、注文ボタンを押す前の体験が変わります。その相談の入口として、スマホやｽﾀｯｸﾁｬﾝは自然な位置にいます。

三つのレイヤーで考える

この構想は、三つのレイヤーに分けると見通しがよくなります。

体験レイヤー
  個人エージェント / ｽﾀｯｸﾁｬﾝ
  相談、読み上げ、同席者調整、最終確認

注文レイヤー
  レストランのメニュースキーマ / 注文API / POS・厨房連携
  在庫、価格、アレルゲン、席番号、提供ステータス

信頼・決済レイヤー
  AP2 のようなエージェント決済プロトコル
  本人承認、限定された支払い権限、監査、責任分界

ｽﾀｯｸﾁｬﾝを置くなら、私は「財布そのもの」ではなく、場に同席する注文コンパニオンとして置きたいです。メニューを読み上げ、候補を一緒に選び、同席者の注文をまとめ、最後に「これで注文していい？」と確認する。カード利用や本人確認のような高リスクの処理は、スマホ、OS、カード会社側の認証フローに任せます。

AP2的な決済プロトコルとの接続

この話は、Google 系の Agent Payments Protocol / AP2 のような動きともつながります。AP2 の概要では、既存の決済インフラは人間が信頼されたUIを直接操作する前提で作られており、AIエージェントがユーザーの代理で支払うには、権限、意図、監査、責任の扱いが足りないと説明されています。

レストラン注文に当てはめると、流れはこうなります。

1. ユーザーが「軽めに食べたい」と言う
2. エージェントがメニューと好みから注文案を作る
3. 店舗が注文内容、価格、提供条件を確定する
4. ユーザーが信頼された画面や物理操作で承認する
5. その注文だけに使える支払い権限が発行される
6. 店舗、決済代行、カード会社が検証して処理する

エージェントには、カード番号や広い購買権限を渡さない方が安全です。「この店舗の、この注文の、この金額まで」という狭い権限にする。そうすれば、エージェントの誤解や暴走、店舗側の不正、ユーザーの意図とのズレを扱いやすくなります。

レストラン側に残る仕事

決済プロトコルが整っても、レストラン注文そのものがすぐ完成するわけではありません。

店舗側には、メニューの構造化、アレルゲン情報、売り切れ、注文変更、キャンセル、席番号、POS、厨房、店員へのエスカレーションが必要です。家族やグループで注文するなら、同席者ごとの制約や会計分けもあります。

ここは AP2 だけではなく、レストラン注文プロトコルの領域です。Schema.org の飲食店注文版のような共通語彙があり、店舗ごとの事情を吸収できるAPIがあり、必要なときには人間の店員へ渡せること。アクセシビリティのためにも、完全自動より「安全に止まれる」設計が向いています。

ｽﾀｯｸﾁｬﾝは場のホストになれる

この構想では、ｽﾀｯｸﾁｬﾝが物理的にその場にいる点に意味があります。

スマホの個人エージェントは、本人確認、支払い手段、食プロファイルを持つ。店舗APIは、メニューと注文を受け持つ。ｽﾀｯｸﾁｬﾝは、その間で会話を進めます。

• 「今日は軽めにする？」
• 「このメニューは小麦が入っているみたい」
• 「みんなの注文をまとめるね」
• 「合計はこの金額。スマホで承認してね」
• 「注文できたよ。番号は42番です」

こういうふるまいは、単なる注文端末よりもやわらかい。人間の店員を置き換えるというより、注文までの迷いや摩擦を減らす小さな同席者です。

小さなCLIから見えた入口

ファミレス注文CLIの話題は、実用システムとして正しいかどうかだけでなく、注文体験がどこまで開けるかを考えるきっかけになりました。

機械可読なメニュー、個人の食プロファイル、会話できるコンパニオン、限定された決済権限、店舗オペレーションへの接続。これらがそろうと、レストラン注文はかなりアクセシブルになります。

そして、これは遠い未来の話だけではありません。まずは注文案を作る。次に人間が明示承認する。決済権限は狭く渡す。危ない場面では人間へエスカレーションする。そうやって小さく切れば、日常の中に置けるエージェントコマースとして育てられそうです。