← すべての記事
ユースケース 読了時間 1 分

大規模な感情分析に向けた商品レビューの集約

レビューはJSレンダリング、ページネーション、アンチボットの壁の向こう側に存在します。感情分析モデルに価値あるデータを供給するために、集約パイプラインに必要な要素を解説します。

product-reviewssentiment-analysisbrowser-renderingweb-scrapingbrand-monitoring

課題

消費者向けブランドは、もはや単一のマーケットプレイスのレビューダッシュボードだけに頼ることはできません。同じSKUであっても、Amazonで1つのレビュースコアを持ち、Walmartで別のスコアを持ち、Best Buyで3つ目のスコアを持ち、さらにTrustpilotやブランド独自のShopifyストアでもまた別のスコアを持ちます。プロダクトチーム、感情分析モデル、またはCX（顧客体験）運用キューがそのうちの1つしか見ていない場合、壊れたミラーを見ながら運転しているようなものです。

これが、レビューに関する日常的な問題である「断片化」です。レビューは存在しますが、10の異なるログイン、10の異なるレンダリングスタック、および10の異なるアンチボット対策の背後に隠れています。感情分析の分類器に毎週データを供給するため（または、上位の出品に低評価のレビューが投稿されたときにアラートをトリガーするため）には、それらすべてを最新の状態で1箇所に集める必要があります。

それらを集約することは、データの課題である前に、レンダリングの課題です。そして、ほとんどのチームがこの前者の課題の大きさを過小評価しています。

困難な理由

2026年のレビューページは、2018年のレビューページとはまったく異なります。重要な情報はすべて、初期のHTMLの後にロードされます。

  • レビューリスト自体は、ブラウザがシェルを描画した後にJSON経由で取得されます。
  • より深いページ（「さらにレビューを表示」、ページネーション）では、セッションが適切なcookieを保持している必要があり、多くの場合、スクロール操作も必要になります。
  • ソートフィルター（最新順、購入者限定など）はrequestのシグネチャを変更します。1つでも間違えると、マーケットプレイスはデフォルトのビューを返し、さらに目立たない形でrate limitを適用します。
  • ページ全体が、User-Agentを確認する前に、requestの低レベルシグネチャ、headerの順序、およびタイミングを検査するボット防御の背後に配置されています。

通常のHTTP requestでそのページを取得すると、空のシェル（レビューも判定結果もなし）しか得られません。自分でセットアップしたheadlessブラウザで取得する場合、そのブラウザのメンテナンス、プロキシ出口のローテーション、そしてマーケットプレイスがアンチボットのアップデートをリリースするたびに新しい検出ルールへパッチを適用し続けるという、継続的なコストを背負うことになります。

解決策

有効なパターンは、単一のAPI endpointとして呼び出すことができるブラウザベースのフェッチです。レビューのURLを渡すと、ページをレンダリングし、JavaScriptを実行し、レビューのペイロードがハイドレートされるのを待ってから、DOMを返します。セッションの詳細はresponseとともに返されるため、次のページネーションのフェッチでそれらを再利用できます。

FourAのBrowser製品を使用すると、Pythonでは次のようになります。

import requests

def fetch_reviews(url, api_key, sticky_proxy=None):
    body = {
        "url": url,
        "unblocker": True,
    }
    if sticky_proxy:
        body["proxy"] = sticky_proxy

    r = requests.post(
        "https://api.foura.ai/api/browser",
        headers={"Authorization": f"Bearer {api_key}"},
        json=body,
        timeout=60,
    ).json()

    return {
        "status": r.get("status"),
        "html": r.get("body"),
        "cookies": r.get("cookies"),
        "sticky_proxy": r.get("proxy"),
        "defense_solved": r.get("defenseSolved"),
    }

レビューのスクレイピングにおいて、2つの詳細が重要になります。

1つ目は、unblocker: trueが、ほとんどのマーケットプレイスのレビューページが採用している通信レベルの防御を処理することです。これがないと、レビューの代わりにチャレンジページが表示されます。

2つ目は、返されるproxy値が、レンダリングに成功した出口のbase36 IDであることです。同じ製品に対する次の呼び出しでこれを再度渡すことで、ページネーションはあなたを同一の訪問者として扱います。そのため、1ページ目が正常にロードされる一方で、3ページ目が静かに何も返さないという違いは、多くの場合、セッションを固定したかどうかに起因します。

上位20件のレビューの最新スナップショットを週に1回取得するだけでよい製品については、セッション固定をスキップし、各呼び出しに独自の出口を選択させてください。ピン留めは、深いページネーションが実際に重要となるSKUのために残しておきましょう。

期待できる成果

このパターンでレビュー集約を実行するチームは、以下のように考えるべきです。

  • カバレッジ: 販売しているすべてのマーケットプレイスにおけるすべての製品のレビューを、下流のプロセスが必要とする任意の頻度（CXアラート用の毎日から、トレンド分析用の毎週まで）で更新します。
  • 深度: マーケットプレイスごとのSKUあたり最初の3〜5ページのレビュー。ここに対策可能なシグナルが存在します。5ページ目以降のロングテールは、感情分析の目的においてはほとんどがノイズです。
  • 鮮度: 新しいレビューは、月次のエクスポートが実行される2週間後ではなく、投稿されてから1日以内に感情分析パイプラインに届きます。
  • コストの予測可能性: レンダリングされたフェッチごとに支払うため、予算はブラウザを維持するために必要なチームの規模ではなく、対象となるSKUの数に応じてスケールします。

これらは魔法の数字ではありません。レンダリングという課題の半分がチームの手から離れたときに得られる結果です。

これを完全なマーケットプレイス監視スタックと比較する場合、レビュー集約は感情分析に特化した親戚のようなものです。同じレンダリング能力を使いながら、下流のプロセスが異なります。

主なまとめ

ブランドが目にするすべてのダッシュボードは、最終的にチャートに行き着きます。しかし、チャートは下流にすぎません。上流のコスト（ほとんどのブランドがこれをうまく実行できない理由）は、レンダリングフリートです。つまり、あなたを排除するために構築された防御に対抗して15のマーケットプレイスのインターフェースへのアクセスを維持し、それを3人のエンジニアとプロキシ契約のコストを下回る価格で存続させることです。

もしレンダリングの半分がレビュー集約プロジェクトを阻んでいるのであれば、それこそが購入すべきピースです。感情分析モデル、ダッシュボード、アラート機能、これらは最新のレビューが届き始めれば、チームが午後の数時間で構築できる部分です。