課題
消費者向けブランドを運営しているとします。リセラーポリシーでは、主力製品の販売価格を179ドル未満にしてはならないと定めています。そこへ顧客からメールが届きます。先週末、Amazonで何者かが144ドルで出品していたというのです。確認したときにはすでに出品が取り下げられていました。出品者は目標の販売数を達成した瞬間に適正価格で再出品したのです。被害はすでに発生しており、さらにWalmart、eBay、TikTok Shop、Google Shoppingの確認も残っています。
これが2026年におけるMAP（最低広告価格）運用の実態です。偽造品や海賊版の市場規模だけでも世界で4670億ドルに達し（OECDおよびEUIPOのデータ、Red Points経由）、これにはグレーマーケットのアービトラージやリセラーポリシー違反は含まれていません。マーケットプレイス側がブランドに代わって価格を取り締まることはありません。さらに偽造品押収件数の79%が小口配送によるものであり、個々の出品者が大規模に税関をすり抜けていることを意味します。
これを迅速に検知しているブランドは、スプレッドシートの管理を改善しているわけではありません。販売展開しているすべての地域で、すべてのマーケットプレイスの全商品ページに対して毎時アクセスする監視インフラを稼働させています。
FourAのアプローチ
単純な構成は、マーケットプレイスごとに1つのスクレイパー、1つのcronジョブ、1つのアラートを用意することです。しかし、Amazonがレイアウトを変更すればスクレイパーは停止し、単一のASNから同一製品に大量アクセスすればIPがブロックされ、価格抽出処理は実際の販売価格ではなく打ち消し線の入ったMSRPを暗黙のうちに取得してしまいます。
実用的なパイプラインは4つの要素で構成されます。
検出（Discovery） SKUリストから開始し、各マーケットプレイス上のすべてのアクティブな出品を特定します。Amazon ASIN、Walmart item ID、eBay listing ID、TikTok Shop商品URLなどです。これは主にカタログスクレイピングであり、カテゴリーページ、検索結果ページ、PDPバリアントへのアクセスを含みます。
ページ収集（Page collection） 各出品についてライブページを取得し、表示価格、出品者名、Buy Boxの獲得者、クーポンや定期おトク便（Subscribe & Save）の割引、タイムスタンプを抽出します。クリーンなHTMLを返すマーケットプレイスもあれば、TikTok ShopやGoogle Shoppingのように価格ロジックの大半をJavaScriptでレンダリングするため、HTTPリクエストライブラリではなく実ブラウザが必要となるマーケットプレイスもあります。
価格の再構築（Price reconstruction） 多くのチームがここで失敗します。Amazonには定価、5〜15%の定期おトク便割引、クーポン、マルチパックの個別価格などが存在します。顧客が実際に支払う価格は、ヘッドラインの数値と一致しないケースが多々あります。ヘッドラインのみを監視するシステムでは、割引が重複適用された違反を見逃してしまいます。
証拠収集とアラート（Evidence and alerts） 違反を検出した際、法務や運用チームには証拠が必要です。URL、スクリーンショット、正確な価格、タイムスタンプ、出品者、出品されていた期間が求められます。これらがなければ、マーケットプレイスの異議申し立て手続きは進みません。
FourAのようなプラットフォームは、複雑な処理を1つのAPIに集約します。クリーンなHTMLを返すマーケットプレイス向けのHTTP request、JavaScriptを多用するサイト向けのブラウザセッション、そして管理不要のproxyルーティングを提供します。ブラウザプロファイルを設定してAmazonの商品URLにrequestを送ると、Chromeと同等のheaderが送信され、ページが正常にレンダリングされます。US地域のproxy経由でAmazon USにリクエストを送り、同じSKUをDE地域のproxy経由でAmazon DEに送ることで、それぞれのローカルコンテキストに基づいた価格を取得できます。
curl -X POST "https://api.foura.ai/api/proxy" \
-H "x-api-key: YOUR_KEY" \
-H "Content-Type: application/json" \
-d '{
"maxTries": 5,
"timeout_ms": 30000,
"request": {
"method": "GET",
"url": "https://www.amazon.com/dp/B0EXAMPLE",
"unblocker": true,
"validate": {
"status": { "accept": [200] },
"data": { "fail": ["captcha", "Robot Check"] }
}
}
}'
呼び出しはこれですべてです。コード内で proxy ローテーションを処理する必要はありません。「このサイトが現在 JavaScript を実行しているか」を確認する必要もありません。ルーティングとリトライはインフラストラクチャが処理し、パイプラインは価格ロジックに集中できます。ブラウザプロファイルフラグがネットワーク上で実際にどのように動作するかについての詳細は、Web Unblocker の解説を参照してください。
地理的な要素は、一般に考えられている以上に重要です。米国、EU、英国で販売を行うブランドは、各地域の IP 空間からの価格の可視性が必要です。マーケットプレイスによっては地域別の価格を提示したり、対象外の地域の IP からのオファーを完全に隠したりするためです。地域ごとのルーティングを活用することで、「世界中へ発送」と宣伝しているセラーが、重要な市場で実際に MAP に違反しているかどうかを検証できます。
Results
500 SKU、6 つのマーケットプレイス、3 つの地域を持つ中規模ブランドの場合、監視対象の製品ページは約 9,000 件になります。毎時監視を行うと、1 日あたり約 216,000 リクエストになります（典型的な中規模ブランド保護のスコープに基づく例示的なシナリオ）。専用に設計された API にとってはこの程度の負荷は問題になりませんが、自前で構築する場合は専任のエンジニアリングチームが必要になります。しかし、重要なのは 1 日あたりのリクエスト数ではなく、違反が発生してから同じ時間内にどれだけ検知できるかです。
実際の現場での改善効果は次のようになります。
- Detection latency: 手動や週単位のスクレイピングによる数日から、毎時ポーリングによって 1 時間未満に短縮
- Coverage: 「対応可能な 3 つのマーケットプレイス」から、ブランドが実際に販売している 6 つすべてに拡大
- False positives: クーポン、定期おトク便（S&S）、マルチパックを価格再構築で適切に処理することで大幅に減少
- Evidence quality: 各検知結果にスクリーンショットとリクエストに紐づくタイムスタンプが付与され、証拠の質が向上
すでに大規模な不動産物件情報の集約に関する解説をお読みいただいている場合、パターンは同じです。大量のページ、混在するレンダリング方式、地理的な差異が存在します。対象となる製品は変わっても、インフラストラクチャの構造は変わりません。
Key Takeaway
MAP 違反はデータ品質の問題ではありません。時間の問題です。違反を最初に発見した側が優位に立ちます。リスティングが購入につながる前に検知するブランドか、誰かが気付く前に利ざやを得て価格を変更するリセラーか、という構図です。監視スタックに追加する各レイヤー（地理的精度、JavaScript レンダリング、価格スタックの再構築）は、実質的にはその時間を取り戻すためのものです。
2026 年に優位性を保っているブランドは、MAP の取り締まりを四半期ごとの監査として扱うのをやめ、リアルタイムのインフラストラクチャとして運用し始めています。最も低コストで対処できる違反は、発生したその時間内に検知された違反です。