Googleマップにメールを読ませる前に
帰り道に「これを食べたい」と伝えるだけで、Google MapsのAsk Mapsが店を探してカートに入れてくれます。8月6日の発表で、食事の注文からホテル予約まで代行するエージェントになりました。
読む限り、便利になった話のように見えます。ただ、私の端末にはまだ来ていない機能でもあります。
リリースノートを読んで、実装が動く前に設計を確認しておきます。エンジニアがいつもやっていることを、今回はGoogleの発表に対して、Gmail連携の権限設計を軸にやってみます。
帰り道に注文が届くまで
会社を出る前に、辛さや使う食材まで指定して注文を頼みます。Ask Mapsは帰り道にある、条件に合う開いている店を探し、選んだ店の品をカートに入れてくれます。決済とピックアップの確定は、そこから先は人の操作です。対応する決済基盤はSquareとToastが先行し、Uber Eatsは追って加わるようです。
一見、秘書を雇ったように便利に見えます。だが「カートに入れる」で止まっているところに、設計者の迷いのようなものを感じます。全自動にできたはずなのに、あえて最後の一手を人に残しているのです。
食べられないものがある人には、もう一つ気になる点があります。発表文には「特定の食事制限を考慮する」とあるだけで、どこまで正確に汲み取るのかは書かれていません。
カートで止まる設計
自動化の設計をするとき、最後の一押しを人に残すかどうかはいつも悩みます。承認なしの自動デプロイは気持ちがいいものです。だが一度組んでしまうと、しばらくは緊張してログを見るのに、そのうち見なくなります。障害が起きて初めて履歴を遡り、いつからこうだったのかと青ざめます。銀行の口座振替を止め忘れるのと同じ構造です。
Ask Mapsが決済の直前で止めているのは、たぶん同じ理由からでしょう。注文までは自動化の範囲に入れても、支払いのボタンは人に押させます。ここを越えた瞬間に、失敗の責任の所在が変わることを、Google側もわかっているのだと思います。
Gmail連携はオフから始まる
Ask Mapsをもう一段賢くしているのが、Personal Intelligenceという仕組みです。Gmailの中身を見て、今度の出張や夜の予約を先読みしたうえで返事を組み立てます。今のところ対応するのはGmailだけで、カレンダーは追って加わる予定のようです。
肝心なのは、この連携が既定では切ってあるという一文でした。オンにするかどうかは選べます。当たり前のようですが、この一文があるかないかで、私の警戒度はだいぶ変わります。
読んだメールの中身がその後Google側に保存されたり、何らかの学習に使われたりする可能性があるのかどうかは、発表文のどこにも書かれていません。オンにするかどうかを決める材料が、また一つ足りないままです。
対象国の広がり方にも差があります。食事の注文やホテル検索、会話型の位置情報投稿はアメリカ先行で、リアルタイムの交通情報とPersonal Intelligenceによる人格化された応答は、今回の発表で日本を含む6か国に先に広がりました。同じ発表の中でも、機能によって足並みが揃っていません。
会話型の位置情報投稿も、店舗の外観を撮って送るだけの手軽さです。ただ、写真から抽出されるのが店舗の情報だけにとどまるのか、投稿を重ねるうちに自宅の近所や普段の行動範囲まで透けて見えるようになるのかは、発表文には書かれていません。手軽さの裏側にある線引きは、まだ見えていません。
権限を渡す瞬間の感覚
新しく入ったメンバーに本番のAPIキーと会社のカードを渡して、「いい感じにやっといて」と送り出す場面を想像してみます。信頼はしています。仕事も速いはずです。それでも画面から目を離した数分だけ、少し落ち着きません。Gmail連携をオンにするのは、たぶんこの感覚に近いのでしょう。
厄介なのは、渡した相手が学習する側でもあることです。レビューボットに何度も指摘をやり直させていたら、過去のコメントの癖まで拾って、こちらの好みに勝手に「気が利く」方向へ寄せてくるようになったことがあります。当たっているだけに、少し怖くなりました。
出張のホテル探しも、同じ理屈で楽になるはずです。ただし会社が契約しているホテルチェーンや、予算の上限まで汲み取ってくれるとは発表文のどこにも書かれていません。踏み外した提案をそのまま予約してしまえば、経費精算で規定外として突き返されるのは、たぶんAIではなく私の方です。
誤発注の後始末は誰がするのか
自動でカートに入った商品を、確認せずにそのまま確定してしまったらどうなるでしょうか。頼んでもいない量や辛さのものが届いたとき、取り消しや返金の手順がどうなるのかは、発表文のどこにも書かれていません。
決済の基盤はSquareとToastが担うとありますが、そこで入力したクレジットカード情報がその後どこに、どう保存されるのかについても、発表文のどこにも書かれていません。
似た構図を扱った記事を、少し前にnote内で見かけました。ChatGPTのヨシダさんが書いた一本で、VisaとOpenAIが組んだ「AI代理決済」を扱っています。
子どもが385万円分を無断で課金してしまった事例を軸に、支払いの主体を人からAIへずらすことの危うさを指摘した内容でした。金額の桁は全然違います。だが失敗の種類は同じ列に並びます。決済の主体をAIにずらした瞬間、いくら小さな注文でも「取り消せるのか」と「誰の責任か」という同じ問いが立ちます。Ask Mapsのピックアップ注文はせいぜい数千円でしょうが、問いの形そのものは385万円の事故と変わりません。
agentic Geminiという号砲
今回の強化を、単発の機能追加として読むと見誤る気がします。Google Gemini公式のnoteに、今年のGoogle I/Oでピチャイ氏が語った話がまとまっています。
日常を一日中支える個人向けエージェントという構想を、Googleが掲げていたという記録です。構想を語ってから数ヶ月で、決済の導線まで実際に動くものが出てきました。ロードマップの言葉と出荷されたコードの距離を測るなら、これは一つの実例になります。
地図の上に、もう一つの自動化が重なっていた
同じ日に、店舗向けの自動化を紹介するnoteも目に入りました。Masaさんが書いた記事で、GoogleマップとSNSから自動で客を呼び込む仕組みを扱っています。
需要側ではAsk Mapsが注文を自動化し、供給側では店舗が集客を自動化しています。同じMapsという基盤の上に、別々の思惑で組まれた自動化が二枚重なっている状態です。エンジニアの感覚で言うと、一つのAPIサーフェスに複数の自動化レイヤーが乗っている状態に近いものがあります。片方の変更がもう片方に伝わらないまま、想定していない組み合わせで動く余地がどうしても残ります。
もし確認という工程が消えたら
ここから先は、確定した未来の話ではありません。今のところGoogleが発表した仕組みには、決済の直前で人の操作を挟む設計が残っています。それを踏まえたうえで、あえてその一線を外して考えてみます。
食事の注文もホテルの予約も決済も、Gmailに眠る出張やディナーの予定を踏まえて、確認なしで確定するようになったとします。位置情報の投稿も、写真をアップロードした時点で自動的に公開されるとします。朝起きたときには、その日の食事も宿泊先も、すでに手配が終わっています。
このとき人に残る仕事は、実行の結果を確かめることと、何か間違っていたときの後始末だけになります。店を選ぶ、予算を意識する、相手の好みに気を配る。そういう判断の束が、丸ごとAIの側に移ります。人の役割は、実行する側から、実行された結果を監督する側へと変わります。
監視するならこの一点だけ
私がもし今日からAsk Mapsを使えるとして、食事の注文機能はおそらくオンにします。カートに入るところで止まる設計なら、失敗しても被害は小さくて済みます。頼んでいないものが届いても、受け取りをやめれば済む話です。
Gmail連携は、当分オフのままにしておきます。読まれて困るメールがあるからではありません。オンにしたあと、その連携の存在を忘れてしまうことの方が怖いのです。銀行の口座振替と同じで、設定した瞬間の緊張は長くは続きません。
もし監視するなら、見る場所は一つに絞ります。決済の直前で、Ask Mapsが本当に止まっているかどうかだけを見ます。この一点が守られている限り、被害は「頼んでいないものが届く」で止まります。この一点が崩れた瞬間、被害の桁が変わります。
