AI 可視性のモニタリングを作っている、あるいは購入しているなら、最も直接的に影響する変更がこれです。私たち自身も含みます。
エージェント面へのアクセスが、身元によって階層化されました。ツール一覧は公開のままです。それを呼び出す権利は公開ではありません。
要点
- UCP は 3 つの信頼階層を定義します。Anonymous、Signed、Token。購入完了と注文の読み取りができるのは Token だけです。
tools/listは匿名で呼び出せます。到達できないプロファイル URL でsearch_catalogを呼ぶと 422profile_unreachableが返ります。- Shopify は 2026 年 5 月 30 日から Storefront API とホスト型ページのボットレート制限を強化し、未署名リクエストには最も厳しい階層が適用されます。
- 事業者は自社ストアをクロールするための署名情報を管理画面から取得できます。
- 認証済みの Global Catalog リクエストは既定でクライアントあたり毎秒 5 リクエスト。各階層の絶対値は公開されていません。
3 つの階層
階層 | 証明した内容 | 呼び出せるもの |
|---|---|---|
Anonymous | 何も証明していない |
|
Signed | Web Bot Auth 署名 | カタログの検索と取得。カートとチェックアウトは部分的 |
Token | 署名に加えて認可 |
|
設計意図はこの非対称性に表れています。ツール一覧の公開はコストがゼロでエコシステムに資する一方、身元不明の呼び出し元に取引させるのは代償が大きい。だから能力のカタログは開かれ、能力の行使は制御されます。
それを具体にした実測
実在ストアに対して search_catalog を呼び、解決できないエージェントプロファイル URL を渡しました。応答はこうです。
HTTP 422—{"error":{"code":-32001,"message":"UCP discovery failed","data":{"code":"profile_unreachable","content":"Unable to fetch agent profile: Http error"}}}
レート制限でも権限メッセージでもなく、探索の失敗です。サーバーは私たちのプロファイルを取得しようとし、できず、そこで止めました。公開到達可能なエージェントプロファイルは、読み取りですら必須条件です。
同じストアは tools/list には匿名で応答し、15 ツールを記述した 207KB を返しました。カタログは公開、実行は制御——設計どおりです。
さらに 2 つの強い制約
Web Bot Auth はもはや礼儀ではなく門です。 2026 年 5 月 30 日以降、Shopify は Storefront API と Shopify ホスト型ストアフロントページのボットレート制限を強化し、未署名リクエストには最も厳しい制限を適用しています。事業者は自社ストアのクロール用署名情報を管理画面から取得できます。これが自社モニタリングのサポートされた経路であり、最初に整えるべき設定です。
公開されている制限は相対値であって絶対値ではありません。 ドキュメントが示すのは順序——Token > Signed > Anonymous——と具体値 1 つ、認証済み Global Catalog リクエストの既定クライアントあたり毎秒 5 件です。キャパシティ設計でこれを全体上限として扱わないでください。
GEO 実務への影響
モニタリングのコストが上がる。 エージェントが実際に何を見ているかを観測したいツールは、スクレイパーではなく身元のあるエージェントになる必要があります。プロファイルのホスティング、署名、鍵のローテーションという実コストが発生し、粗いスクレイピング型ツールはこの面から締め出されます。
AI 可視性が部分的に身元の問題になる。 コンテンツが優れていても、呼び出し元の信頼階層が足りなければ呼べない機能があります。complete_checkout は Token 限定であり、Token に到達しない監視システムは、プロンプトがどれほど良くてもファネル末端を観測できません。
ベンチマークには階層のラベルが必要。 同じブランドについて異なるエージェント可視性を報告する 2 つのツールは、どちらも正しいことがあり得ます。呼び出した階層が違うからです。真面目な比較には、計測した階層の明示が不可欠です。
事業者が実際にやるべき 3 点
大半はプラットフォーム側の話ですが、3 つはあなたの担当です。
- 自社ストアのクロールを社内・代理店のいずれに依頼する場合も、先に自社の署名情報を取得する。
- レート制限と正面から戦わない。 パートナーがスロットルされるなら、答えは署名であってリトライループではありません。未署名トラフィックは設計上最下層です。
- ベンダーにどの階層で計測しているか尋ねる。 妥当な質問であり、その答えでレポートが発見までなのか取引経路全体なのかが分かります。
スタック内での位置
信頼階層はプロトコル層にあり、その大半はプラットフォームがホストします。これは安心であり罠でもあります。安心なのは自分で作らなくてよいから、罠なのは自社ストアで壊れていても気づけないからです。プロトコル層の健全性はコマンド 1 本で確認できます——10 分の自己診断と、層の依存関係については6 層スタックを参照してください。
よくある質問
エージェントはもう自社サイトをスクレイピングできないということですか。 未署名リクエストが全面的にブロックされるわけではありません。最も厳しい制限が適用され、制御されたツールには到達できません。同時に公式の指示はエージェントにスクリプトでのフォーム入力への後退を禁じています。両者が合わさり、行儀の良いエージェントはツール経路へ誘導されます。
エージェントのトラフィックを完全に遮断できますか。 通常の手段でクロールを制限でき、チャネル参加には管理画面に個別のスイッチがあります。そうすべきかは別問題です。アトリビューションの断絶が、遮断の代償が守るものより大きくなりがちな理由を説明しています。
どのエージェントがどの階層を使ったか分かりますか。 現状、事業者側から詳細に知ることはほぼできません。これは未解決の空白の 1 つです。信頼階層は呼び出し元に対しては明確に規定され、事業者に対してはほとんど可視化されていません。