Amazon 対 Meta のショッピングエージェント Muse：線を引くべきはエージェントの身元ではなく、セッションの管理権

私のエージェントは、デスクトップ上の本物の Chrome を操作しています。その Chrome は仕事用とクライアントのアカウントにログインしていて、エージェントがそこでページを開くと、相手側のサイトが受け取るのは私のブラウザ、私の Cookie、私のセッションです。通信のどこにも、エージェントが操作しているという表示はありません。私が自分でブラウズするときとまったく同じ情報を送っているだけです。

先週のニュースを考えるうえで、これが居心地の悪い出発点になります。Amazon が Meta の Muse を締め出し、その理由のひとつが「Muse はブラウズ中に名乗らない」だったからです。私のエージェントも名乗りません。Amazon が掲げた基準に従えば、私は自宅で Muse と同じものを動かしていることになります。

Amazon は Meta のエージェント Muse の何を問題にしたのか

The Register の 9 月 21 日の記事によれば、Amazon は GeekWire に対して問題を 3 つ挙げています。Meta は Muse を送り込むことを Amazon に伝えておらず、許可も得ていなかった。Muse はブラウズ中に名乗らない。そして Muse は顧客の認証情報を取得して保存しているとみられ、注文履歴などのアカウントデータにも手が届く。Muse で Amazon を使おうとしたユーザーにはエラーページが表示され、未承認の AI エージェントによるアクセスは Amazon の利用規約に違反すると告げられます。Meta の回答は認証情報についてだけでした。認証情報は安全なストレージに保管され、モデルに見せることなく認証に使われる、というものです。

Muse は 9 月 8 日にローンチし、TechCrunch が 25 日に確認した時点で、米国の両アプリストアで、それぞれ 18 日と 19 日から 1 位を保っていました。Amazon はすでに Google と OpenAI のショッピングエージェントをブロックし、Comet をめぐって Perplexity を提訴しています。自社のエージェント Buy for Me も運営しており、これは他の小売業者のサイトで買い物をし、名乗り、その小売業者がオプトアウトできるようにしています。The Register によれば Amazon の昨年の広告収入は 680 億ドルを超え、その収入は人々が Amazon のページを見ることに依存しています。

つまり、線の候補は 2 つあります。エージェントが名乗ること。あるいは、認証情報がユーザーの管理下から決して出ないこと。私の考えでは、前者はそもそも安全の線ではなく、後者は引く場所がずれています。

AI ショッピングエージェントが名乗ればユーザーは守られるのか

守られるのはサイトが判断する力で、ユーザーの安全とは別のものです。裁判記録がそれをはっきり示しています。第 9 巡回区控訴裁判所は 8 月に Amazon 対 Perplexity の判断を下した際、争いの核心を次のように述べました。

At the core of the dispute was Perplexity’s decision not
to use a “user-agent string,” a mechanism “that would
communicate that the user has activated an AI agent.” That
user-agent string would allow Amazon to block the
Assistant’s access to the Amazon store.

Amazon が求めた身元表示には明示された役割があり、その役割はブロックでした。Buy for Me は同じ仕組みを反対側から見せています。他の小売業者がオプトアウトできるように名乗るのです。これは設計どおりに働く拒否権であり、それを差し出しているのは、自分の入り口にも同じ拒否権を求める会社です。

単なる user-agent 文字列は、クライアントが自分について主張しているにすぎません。だから本気の方式は暗号によるものになります。RFC 9421 は HTTP Message Signatures を定義しており、IETF ワーキンググループのドラフト Web Bot Auth はこれを使って、自動化されたクライアントが運営者の公開する鍵でリクエストに署名できるようにします。サーバーは、リクエストが本当にその鍵の持ち主から来たことを確かめられます。その事実をサーバーがどう使うかはプロトコルがサイトに委ねる別の判断で、わかりやすい選択肢は許可、ブロック、課金です。検証された身元は、エージェントに責任を問えるようにし、課金できるようにします。けれども、エージェントがセッションの持ち主であるユーザーに対して何をするのかについては、何も教えてくれません。

少なくとも今のところ、法律も同じ方向を向いています。同じ判決は、提出された記録に基づけば、米連邦の反ハッキング法とそのカリフォルニア州版のもとで Amazon のコンピュータに「アクセス」しているのは Perplexity ではなくユーザーだと判断しました。Perplexity のサーバーは Amazon のサーバーに一切触れず、エージェントはユーザー自身のブラウザを通じて動くからです。これは仮差止命令に対する控訴で、差止命令は取り消されて事件は差し戻されました。裁判所は、提供者がどこまで制御しているかについて事実が異なれば結論も変わりうると明言しています。Amazon は大法廷での再審理を求めましたが、9 月 10 日、採決を求める判事が 1 人もいないまま、裁判所は申し立てを退けました。合議体は脚注で、この判断は Amazon がユーザー向けの私的な利用規約によって Amazon.com へのアクセスを規律する能力を損なうものではない、と付け加えています。あくまで私の読みですが、争いはその規約の側へ移っていくと思います。いま Muse のユーザーがエラーページで目にする、あの利用規約です。

「モデルはパスワードを見ない」は AI エージェントの境界線になるのか

この主張は、線の種類としては正しいのですが、引く場所が間違っています。Meta の主張は限定的です。パスワード文字列は安全なストレージにあり、モデルを経由せずに認証に使われる。それはそれで結構です。しかしセッションが開いてしまえば、エージェントはそのアカウントが表示できるものすべてに届きます。注文履歴、住所、保存された支払い情報（サイトが表示する形で）。そのうちどれだけが実際にモデルに渡るかは実装しだいです。パスワードは、最初からセッションの鍵にすぎませんでした。

これはブラウザではなく、自分のエージェントから学んだことです。私が動かしているエージェントがクライアントのメールをクライアントごとのフォルダに取り込んでいたのですが、フィルタリングが甘く、あるクライアントのスレッドが別のクライアントのフォルダに入りうる状態でした。それに気づいて、クライアントごとの厳格なラベル付けと、クライアント名の照合に切り替えました。この失敗には、認証情報の漏洩は必要ありませんでした。エージェントはすでに正当に中にいて、リスクはそこからどこまで届くかでした。以前、ツールが届く範囲と実際に触れるものは別の事実だと書きましたが、これは同じ切り分けを一段上で見たものです。セッションは到達範囲を与え、その範囲でエージェントが何をするかを改めて問う仕組みはありません。

だから、セッションを握るエージェントを評価するまっとうな基準は、ユーザーがその中でエージェントのしていることを確認でき、アクセスを取り消せるかどうかです。Muse について、どちらの会社の声明もそれに答えていません。Meta はパスワードの保管方法を説明し、Amazon は自分の懸念を説明しました。Muse のユーザーが何を確認でき、何を取り消せるのかは、どちらも語っていません。

個人のブラウザエージェントはなぜ Meta の Muse と同じではないのか

ネットワークの境界から見れば区別がつかないかもしれません。そして、まさにそこが要点です。誠実なエージェントと不注意なエージェントを分けるものは、エージェントが申告する内容の中にはありません。違いはセッションの管理権、つまりセッションを誰が握り、誰が止められるかであり、それは背後にある仕組みの質で決まります。

私の仕組みは、わざと地味にしてあります。ブラウザのプロファイルにあるのは仕事用とクライアントのアカウントだけで、個人的なものはありません。銀行も個人メールもないので、エージェントが触れる前の段階でセッション自体の範囲が絞られています。エージェントは自分用の新しいタブを開き、私がすでに開いているタブでは決してページを移動しません。私の開いているタブは稼働中のクライアントセッションで、それを乗っ取ったときの被害は表に出ないからです。大量検索はこのプロファイルを通さず、別の API を使います。そうしないとアカウントにフラグが立ちます。本物の API キーがある場合、エージェントはブラウザではなくキーを使い、書き込みができるキーでもポリシーで読み取り専用に留めているものがあります。エージェントがパスワードを入力することはありません。ログイン画面に当たったら、止まって私に聞きます。

正直に言えば、そのほとんどはルールであって、強制された分離ではありません。同じプロファイルで開いた新しいタブからも、そのプロファイルのすべてのアカウントに届きますし、ポリシー上の読み取り専用は読み取り専用の認証情報とは違います。私が実際に持っているのは、セッションが手元にあることと、いつでも取り消せることです。セッションは私のもので、私が開き、私のマシン上にあるので、どのセッションでも確認して止められます。ホスト型のエージェントも、別の手段で同じ基準を満たせます。セッション内で何をしたかをユーザーが読めるログ、ユーザーが決める範囲、実際に機能する取り消し。私のデスクトップは基準を満たす方法のひとつであって、基準そのものではありません。

これはつまり、この線はサイト側には引けないということでもあります。Amazon に見えるのは接続の自分の側だけで、そこからはセッションの管理権は見えません。線を引くのはユーザーと、エージェントを作る人たちです。サイトの線は別の場所にあります。

Amazon が Muse をブロックしたのはユーザーのためか、広告ビジネスのためか

両方です。第三者による認証情報の扱いは本物のリスクで、Amazon はこの正当な理由を、もう一方の理由、つまり広告ビジネスを守ることの正当化にも使っています。収益がページ上の注目、つまりスポンサー枠や広告オークションに支えられているなら、ページを読んで広告を飛ばすエージェントは訪問者ではありません。そのサイト自身のレジの列に並んでいる競合相手です。

私のサイトは壁の正反対ですが、それを Amazon が破っている原則だと言うつもりはありません。robots.txt は学習、検索、AI への入力のすべてを許可しており、エージェントが推測しなくて済むようにスキルファイルと API カタログも置いています。正直に言うと、これらはエージェント対応度を測るスキャナーで良いスコアを取るために用意した面もあります。ただ、何より費用がかかりません。このサイトは何も売らず、広告も出していないので、読みに来るエージェントはすべて、情報を広めてくれる存在になり、アシスタント経由でたどり着いた人もやはり読者です。ページの上に守るものが何もないサイトの経済学、というだけです。

AI エージェントのトラフィックにサイト運営者はどう向き合うべきか

ページそのものが商品でない限り、ポリシーを公開して、エージェントに公開ページを読ませましょう。何をしてよいか、API がどこにあるかを機械可読な形で示します。壁は操作のほうに置きます。チェックアウト、アカウントの変更、ユーザーのお金を使うものすべてです。個人データには、お金が動くかどうかに関係なく専用のスコープ制御が必要で、それがあのメールフォルダの件から得た教訓のすべてです。公開ページの閲覧を許すコストは小さく、お金の支出や情報の露出のコストはそうではありません。これは自分のエージェントに課しているのと同じルールです。機能するゲートは、その操作が何に届くかに合わせて置くものです。

このルールで見ると、Amazon の言い分が最も強いのは Muse がお金を使いアカウントに触れる場面で、最も弱いのは、それ以外のすべての前にまで壁を立てている点です。チェックアウトにゲートを置くなら、反論するのは難しいでしょう。Muse のユーザーが目にするエラーページは、店全体の前に立っています。

そして、守りたいのがページ上の広告枠なら、サイトはセキュリティ上の理由と並べてそう言うべきです。pay-per-crawl の仕組みがクローラーのリクエストごとに価格を付け始めているように、アクセスに課金すればいい。それにはエージェントが署名付きで名乗る必要がありますが、それで構いません。身元確認はまさにそのためのもの、つまり許可と課金のためのものです。安全を保証する仕組みだったことは一度もありません。

Amazon には注意深いエージェントと不注意なエージェントの区別がつかず、エージェントが名乗っても、それは変わりません。両者を分けるものは接続の私の側、Amazon が覗けない場所にあり、ユーザーが目を向けるべきなのもそこです。