Bot ／ Agent は 「Web Bot Auth」で自己申告しないと レート制限が一番キツくなる

図解 ： Bot / Agent は Web Bot Auth で自己申告すべし Action Required ／ Platform Bot ／ Agent は 「Web Bot Auth」で自己申告しないと レート制限が一番キツくなる Storefront API ／ Shopify ホスティングのオンラインストアにアクセスする bot ・ agent に対して、Shopify が厳しいレート制限を適用開始。署名なしリクエストは最も厳しい枠に押し込まれる。高い枠が欲しければ Web Bot Auth でリクエストに署名する。 このページの構成 何が起きたのか（30秒で理解） 仕組み図解 ： 署名あり／なしの分岐 対象になるトラフィック 署名あり vs 署名なし 比較 アクセス階層（Tier） 対応すべきアクション（3ステップ） マーチャント向け ： 自社ストアをクロールしたい場合 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 何が起きたのか Shopify が、Storefront API と Shopify ホスト型オンラインストアページにアクセスする bot ／ agent に対して、 より厳しいレート制限 を適用開始。 署名なし のリクエストは「最も厳しい枠」に固定される。 Web Bot Auth で署名 すると、より高いレート枠の対象になる。 署名なしの bot ： 強い制限 名乗らない bot は誰のものか判別できないため、最厳格枠に入る。爆撃に近いアクセスはここで止まる。 Web Bot Auth で署名 ： 高い枠 自分が誰の bot かを暗号署名で名乗ることで、Shopify 側がより寛容なレート制限を適用する。 2 仕組み図解 ： 署名あり／なしの分岐 Web Bot Auth ： bot ／ agent が「自分が誰か」を暗号鍵で署名して名乗るための仕組み。Shopify はこの署名で正体を識別し、信頼できる相手にはレート枠を広げる。Cloudflare の実装ガイドが参考資料として案内されている（ Cloudflare への登録は不要 、あくまで仕様理解のための参照）。 3 対象になるトラフィック Storefront API 商品・コレクション・在庫情報などを GraphQL で叩く全クライアント。bot や agent からのアクセスはここで識別される。 Shopify ホスト型オンラインストアページ テーマでレンダリングされる公開ページ。クローラー・スクレイパー・LLM の取得対象になる HTML 全般。 Bot ／ Agent 全般 クローラー・サーチエージェント・LLM ベースの取得エージェント等、人間以外がストアに来るトラフィックすべて。 4 署名あり vs 署名なし 比較 項目 署名なし（無対応のまま） Web Bot Auth で署名済み レート制限 最厳格 最も厳しい枠 高めの枠 緩和される 身元の識別 できない（誰の bot か不明） 署名鍵で識別される 運用安定性 429 で止まりやすい 安定して回せる 追加コスト — 記載なし さらに高い枠が必要 — 専用フォームから Shopify に申請可能 5 アクセス階層（Tier） L1 無署名 最も厳しい制限。名乗らない bot のデフォルト。 L2 Web Bot Auth 署名済み 標準的な高めの枠。ほとんどの真っ当な bot はここを目指す。 L3 高階層（申請制） L2 でも足りない場合、専用フォームで Shopify に相談。 各 Tier の具体的な req/秒 や数値レンジは記事に記載なし。詳細は「Storefront rate limits」のドキュメントで確認すること。 6 対応すべきアクション（3ステップ） 1 Web Bot Auth のアーキテクチャを確認 仕様の全体像（鍵・署名ヘッダ・検証フロー）を理解する。 2 Cloudflare の実装ガイドを参考に組み込み あくまで参照用。Cloudflare に登録する必要はない。 3 自分の bot で署名付きリクエストを送る Storefront API ／ オンラインストアへのアクセス時に署名を必ず付与する。 もし L2 でも枠が足りない場合は、 記事内に案内されている「専用フォーム」から Shopify に直接連絡 して L3 相当の高階層アクセスを相談する。 7 マーチャント向け ： 自社ストアをクロールしたい場合 Shopify 管理画面に「すぐ使える Web Bot Auth 署名」が用意されている 自分のストアをクロールしたい Shopify マーチャントは、Shopify admin から ready-to-use な Web Bot Auth 署名を取得できる。自前で鍵生成・実装フローを組まずに、自社クローラーに即適用可能。 8 技術者が押さえるべき5つのポイント 1. これは「Action Required」案件 Shopify が告知タグに Action Required を明示している。bot や agent を運用している側の能動的対応が前提。放置すると最厳格枠に固定される。 2. 認証ではなく「自己申告」モデル Web Bot Auth は API キーで権限を取る仕組みではなく、bot が「自分は誰か」を暗号署名で名乗るための仕組み。Shopify はそれを根拠にレート枠を配分する。 3. 対象は API だけでなく公開ページも Storefront API（プログラム的アクセス）に加えて、Shopify ホスト型オンラインストアの HTML ページも対象。LLM 系のクローラーが取りに来るルートも含まれる。 4. Cloudflare 登録は不要 参考実装として Cloudflare の guide が案内されるが、Shopify は「for context only ／ enroll する必要はない」と明示。Web Bot Auth は標準仕様ベースで自前実装すればよい。 5. L2 で足りなければ申請ルートが用意されている Web Bot Auth で署名しても枠が足りない場合、Shopify に対して個別フォームから高階層アクセスを申請可能。 マーチャント直営の正当な bot や、大規模商品同期ジョブなどでは、まず L2 を満たしたうえで L3 を交渉する のが現実的な戦略になる。 9 業務に活かせる3つのユースケース USE CASE 1 競合価格・在庫モニタリング bot の安定運用 課題 Shopify ストア群を巡回する価格・在庫モニタリング bot が、署名なしのまま放置されており、いずれ最厳格レート制限に当たって 429 連発で停止しかねない。 打ち手 bot に Web Bot Auth 署名を組み込み、Storefront API ／ HTML 取得の両方に署名ヘッダを付与する。 効果 レート枠が緩和され、巡回が安定。ジョブの失敗・リトライ回数が減り、データ鮮度も維持される。 技術メモ L2 でも足りない場合は専用フォームで L3 相当を申請。Cloudflare ガイドは参考のみ、登録不要。 USE CASE 2 自社運用 LLM ／ AI エージェントの商品データ取得を「公式に名乗らせる」 課題 自社で運用している RAG ／ AI エージェントが Shopify 公開ページや Storefront API を匿名で叩いている状態。今後の制限強化で取得失敗が顕在化するリスク。 打ち手 AI 取得層のリクエスト送出箇所に Web Bot Auth 署名を実装。鍵管理・署名生成はサーバ側プロキシに集約する。 効果 取得安定性向上に加え、Shopify 側から見て「素性のはっきりした bot」になり、将来のさらなる制限強化にも先行対応できる。 技術メモ 署名はリクエスト単位。LLM の生応答からの直接コール（ブラウザ to ストア）ではなく、自社プロキシ経由にして署名する設計が現実的。 USE CASE 3 マーチャント支援 ： 自社ストア向けクローラーの即時セットアップ 課題 Shopify マーチャントが自社サイトのコンテンツ取得・サイトマップ生成・社内検索用クローリングを動かしたいが、自分の bot まで最厳格レート制限に当たるのは避けたい。 打ち手 Shopify admin に用意されている ready-to-use な Web Bot Auth 署名を取得し、自社クローラーに組み込ませる。 効果 マーチャント自身のクローラーが「自分の店のものだ」と Shopify に名乗れるため、レート枠を確保したまま運用可能。 技術メモ 署名情報の取得元 ／ admin 内の正確な画面パスは記事に記載なし。Shopify admin 内を実機で確認する必要あり。 10 提案で使える1行サマリ 「Shopify ストアにアクセスする bot ／ agent は Web Bot Auth で署名して名乗らないと最厳格レート制限 。 署名すれば高い枠、足りなければ専用フォームで申請可能。 マーチャントは admin に用意済みの署名を使うだけで自社クローラーを救える。 」 source ： shopify.dev / changelog / bots-and-agents-should-identify-themselves-via-web-bot-auth generated 2026-05-23