ストア検索が無限スクロールに変わっても大丈夫 — 商品取得の自動化を維持する方法

どんな依頼があって進めているか

とあるECサイトのストア検索ページで、商品一覧の表示方式がページネーションから無限スクロール方式に変更されました。これに伴い、従来の「URL パラメータ（b=1, b=31 など）で次のページへ遷移する」仕組みが使えなくなり、商品一覧から商品コードを取得する処理が動作しなくなったというご相談をいただきました。

ストアごとに指定件数まで商品データを安定して取得し、その後の価格・レビュー分析に活用するため、新しいページ構成に対応した改修が必要という背景です。

何の目的でやっているか

この取り組みでは、次の2点を主なゴールとしています。

これにより、ストア検索ページの仕様変更後も、これまでと同様に商品データの収集・分析を続けていただけるようにすることが目的です。

どういう手段であって、どう解決しているか

1. 無限スクロール対応の基本フロー

従来の「ページ URL を切り替えて次のページを表示する」方式をやめ、1回だけストア検索ページを表示したうえで、末尾までスクロール → 待機 → 表示中の商品リンクから商品コードを抽出するループに変更しました。スクロールのたびに追加読み込みされる商品を、順次取り込んでいきます。

2. 商品リンク取得の汎用化

旧来の XPathに依存すると、DOM の変更で取得できなくなるため、「商品ページのURL が ストアID/商品ID.html のような指定の形式となっているもの」を対象とするようにしました。これで、レイアウトが変わっても商品詳細リンクだけを確実に拾えます。

3. 「続きを見る」「次へ」ボタンでの追加読み込み

スクロールだけでは新規アイテムが増えない場合、稀にページネーションが発生している場合もあります。そういったケースに備え、「続きを見る」「次へ」ボタンのクリックを試行する処理を追加しました。

これをやることでどう応用できそうか

今回の仕組みは、他モールや他サイトで「一覧が無限スクロール＋ページネーションボタン」の組み合わせになっている場合にも、同様のパターンで応用できます。

「スクロール → 件数チェック → 新規がなければボタンクリック試行 → 再取得」という流れは共通です。また、aria-label や data-direction で「次へ」を特定する方式は、DOM 構造が変わってもラベルが維持されていれば安定しやすいため、他の一覧ページの自動化にも活かせます。

ストア商品データの取得・自動化について、お気軽にご相談ください

ECサイトの商品一覧取得・データ分析の自動化でお困りの際は、お気軽にご連絡ください。