なぜ日本のECスクレイピングに日本IPが不可欠なのか
日本のEC市場は世界第3位の規模を誇り、楽天市場だけで年間5兆円以上の取引が行われています。しかし、海外からこの市場のデータを収集しようとすると、想像以上の壁にぶつかります。日本の主要ECサイトの多くは、海外IPからのアクセスに対して厳格な制限をかけているからです。
具体的には以下のような問題が頻発します：
- 楽天市場は、非日本IPに対してリダイレクトやレート制限を適用し、日本向けカタログの代わりに簡易版の国際ページを表示
- Yahoo! Japan Auctionsは、海外IPからの入札機能を制限し、商品ページの表示内容自体が変わる
- メルカリは、APIアクセスに地域ベースのフィルタリングを実施
- 食べログは、海外からのスクレイピングをWAFレベルで遮断
このような状況下で、日本レジデンシャルプロキシの利用は選択肢ではなく前提条件です。データセンタープロキシでも日本IPは取得できますが、日本のECサイトはデータセンターIPの検出精度が極めて高く、レジデンシャルIPの代替性は低いと言えます。Webスクレイピングのユースケースについて詳しくはこちらを参照してください。
日本の主要ECサイト：スクレイピング比較
日本市場でデータ収集の対象となる6つの主要プラットフォームを、スクレイピングの観点から比較します。
| プラットフォーム | IP厳格度 | エンコーディング | ジオ影響 | 主な用途 |
|---|---|---|---|---|
| 楽天市場 | 高 | UTF-8 | 中（都道府県別価格あり） | 商品価格・在庫・レビュー |
| メルカリ | 高 | UTF-8 | 低 | C2C価格動向・出品監視 |
| ヤフオク! | 中〜高 | UTF-8 | 中 | オークション価格・落札履歴 |
| 価格.com | 中 | Shift-JIS（一部） | 低 | 最安値比較・レビュー |
| 食べログ | 高 | UTF-8 | 高（地域別ランキング） | 店舗情報・評価・レビュー |
| SUUMO | 中 | UTF-8 | 高（沿線・エリア別） | 賃料・空室・沿線データ |
楽天市場（Rakuten）
日本最大のECモールである楽天市場は、約3万店舗が出店する巨大マーケットプレイスです。楽天をスクレイピングする際の最大の課題は、非日本IPへの対応と、店舗ごとに異なるHTML構造です。楽天は海外IPを検出すると、日本向けの商品カタログの代わりに簡易版の国際ページを表示することがあり、価格・在庫データが本来のものと異なります。
また、楽天は都道府県ごとに異なる送料や配送条件を設定できるため、ジオターゲティングによる正確な価格取得が重要になります。SERPトラッキングと組み合わせることで、検索順位と価格の相関分析も可能です。
メルカリ（Mercari）
月間2,000万ダウンロードを超えるC2Cアプリのメルカリは、レア商品の転売価格監視に不可欠です。メルカリのWeb版はSPA（Single Page Application）構造を持ち、JavaScriptレンダリングが必要な場面が多い点に注意が必要です。また、出品者の評価スコアや過去の取引履歴は、価格予測モデルの貴重な特徴量になります。
ヤフオク！（Yahoo! Japan Auctions）
日本最大のオークションサイトで、コレクターズアイテムや中古品の価格相場データの宝庫です。入札履歴や落札価格の推移を追うことで、マーケットトレンドを把握できます。海外IPからは入札ページの構造が制限されるため、日本IPでのアクセスが必須です。特に限定商品のオークション監視では、スティッキーセッションによる継続的な追跡が効果的です。
価格.com（Kakaku.com）
家電・PC用品の最安値比較サイトとして圧倒的なシェアを持ちます。スクレイピング時の注意点として、一部ページがShift-JISエンコーディングを使用している点が挙げられます。これは後述する文字コード問題の典型的な例です。価格.comのレビューデータは、競合分析の観点で非常に価値が高いですが、取得頻度には注意が必要です。
食べログ（Tabelog）
日本最大の飲食店レビューサイトで、地域別のランキングデータが高価値です。食べログはWAF（Web Application Firewall）によるスクレイピング対策が非常に厳格で、データセンターIPはほぼ確実にブロックされます。レジデンシャルプロキシのローテーションが必須です。また、食べログのスコアは3.5点満点ではなく5点満点で分布が極めて狭く（3.0〜3.8が大半）、独自の正規化ロジックを設計する必要があります。
SUUMO
不動産・賃貸情報の最大ポータルで、沿線・エリア別の賃料データを収集できます。SUUMOは地域密着型のデータ構造を持つため、東京と大阪で全く異なるデータセットが返されます。都市レベルのジオターゲティングが効果を発揮する典型例です。不動産データは頻繁に更新されるため、スケジュールベースのスクレイピングが推奨されます。
日本語テキスト処理の落とし穴
日本のECサイトをスクレイピングする際、英語圏のサイトでは遭遇しない文字コード問題が頻発します。この問題を軽視すると、取得したデータが全く使えないものになります。
Shift-JIS vs UTF-8
日本のWebサイトには、依然としてShift-JIS（Windows-31J）エンコーディングを使用するページが存在します。価格.comの一部ページや、古いECサイトのモバイル版が典型例です。PythonのrequestsライブラリはデフォルトでUTF-8を想定するため、明示的なエンコーディング指定がなければ文字化けします。
import requests
from bs4 import BeautifulSoup
proxies = {
"http": "http://user-country-JP:PASSWORD@gate.proxyhat.com:8080",
"https": "http://user-country-JP:PASSWORD@gate.proxyhat.com:8080",
}
response = requests.get("https://kakaku.com/item/XXXX/", proxies=proxies)
# Shift-JISの場合は明示的にデコード
if "shift_jis" in response.encoding.lower() or "shift_jis" in response.headers.get("Content-Type", "").lower():
response.encoding = "cp932" # Windows-31J
else:
response.encoding = response.apparent_encoding
soup = BeautifulSoup(response.text, "html.parser")
print(soup.title.string)
cp932（Windows-31J）を指定する理由は、標準のShift-JISにはNEC特殊文字やIBM拡張文字が含まれておらず、日本のECサイトで頻出する①や㈱などの文字が化けるためです。
CJKトークナイゼーション
日本語は単語間にスペースがないため、検索キーワードの処理に形態素解析（MeCab、Janome等）が必要です。例えば「東京都心の賃貸マンション」という文字列は、「東京都」「心」「の」「賃貸」「マンション」のように分割しなければ、検索インデックスとして機能しません。スクレイピングしたデータを検索可能にする場合、この前処理が不可欠です。
特に楽天の検索APIは、入力クエリの形態素解析結果に依存して商品を返すため、スクレイピング側でも同じトークナイゼーションを再現しないと、期待した検索結果が得られません。
APPI（個人情報保護法）とスクレイピング
日本にはEUのGDPRに相当する個人情報保護法（APPI：Act on the Protection of Personal Information）があります。2022年の改正で、データ越境移転の規制が強化され、海外企業にとって遵守がより重要になりました。
スクレイピングにおけるAPPIの要点は以下の通りです：
- 個人情報の定義：生存する個人に関する情報で、氏名・生年月日等により特定の個人を識別できるもの。ただし、企業の公開連絡先や、店舗のレビュー内容そのものは個人情報に該当しない場合が多い
- 公開情報の取り扱い：公開されている情報であっても、それを組み合わせて個人を特定可能になればAPPIの対象となる
- 利用目的の制限：収集目的を超える利用は制限される。価格比較目的のスクレイピングは「正当な事業活動」と解釈される余地が大きい
- 第三者提供の制限：オプトアウト方式（日本ではGDPRのような明示的同意は不要）だが、利用目的の通知・公表は必要
- 越境移転：日本国内の個人データを海外サーバーに転送する場合、相当な保護措置を講じる義務がある
実務上のガイドライン：価格・在庫・店舗情報など、企業が公開している非個人データのスクレイピングは、APPI上のリスクが低いと言えます。ただし、レビュー投稿者のユーザー名や購入履歴など、個人に紐づくデータの収集・蓄積には慎重な判断が必要です。特にユーザーIDと購買履歴を組み合わせたプロファイリングは、APPI違反のリスクが高まります。
コンビニ決済が在庫判定に与える影響
日本のEC決済の特徴として、コンビニ決済（コンビニ支払い）の存在が挙げられます。楽天やYahoo!ショッピングでは、商品の「注文可否」ステータスにコンビニ決済の受付状況が影響します。これは海外のスクレイパーが最も見落としやすいポイントです。
なぜ重要なのでしょうか？
- コンビニ決済の場合、支払い期限（通常3〜7日）があるため、在庫表示が「注文可能」でも実質的に在庫を押さえている状態になる
- スクレイピングで「在庫あり」と検出しても、コンビニ決済の未決済分が含まれている可能性がある
- 特に楽天の「あす楽」対象商品では、決済方法ごとに配送可能エリアが異なり、ジオターゲティングと組み合わせないと正確な在庫判定ができない
- コンビニ決済のキャンセル率は約15%と言われており、在庫予測モデルにこの補正を入れる必要がある
したがって、在庫監視の精度を高めるには、決済方法の選択画面までスクレイピングするか、コンビニ決済の未決済猶予期間を考慮したロジックを実装する必要があります。
東京・大阪のジオターゲティング実装
ProxyHatでは、ユーザー名にジオターゲティングフラグを含めることで、特定の都市のIPアドレスを取得できます。東京と大阪は、日本のECデータ収集において最も需要の高い2都市です。対応ロケーション一覧でその他の地域も確認できます。
curlによる実装例
# 東京IPで楽天市場にアクセス
curl -x "http://user-country-JP-city-tokyo:PASSWORD@gate.proxyhat.com:8080" \
"https://search.rakuten.co.jp/search/mall/%E3%83%AF%E3%82%A4%E3%83%B3/"
# 大阪IPでSUUMOの賃貸情報にアクセス
curl -x "http://user-country-JP-city-osaka:PASSWORD@gate.proxyhat.com:8080" \
"https://suumo.jp/chintai/osaka/"
Pythonによるセッションベースの実装
複数のリクエストにわたって同じIPを維持したい場合（例：ログイン後のスクレイピングやページネーション）、スティッキーセッションを使用します。
import requests
# 東京IPでスティッキーセッションを確立
proxy_url = "http://user-country-JP-city-tokyo-session-mysearch01:PASSWORD@gate.proxyhat.com:8080"
proxies = {"http": proxy_url, "https": proxy_url}
session = requests.Session()
session.proxies = proxies
# 同一セッションで複数ページを巡回（IPが維持される）
for page in range(1, 6):
url = f"https://search.rakuten.co.jp/search/mall/%E3%83%AF%E3%82%A4%E3%83%B3/?p={page}"
response = session.get(url)
print(f"Page {page}: {response.status_code}, IP維持確認")
スティッキーセッションのsession-mysearch01部分は任意の文字列です。同じセッションIDを指定すれば同じIPが割り当てられ、異なるIDを指定すれば新しいIPが割り当てられます。これにより、ログイン状態を維持しながらのスクレイピングや、CAPTCHA回避のためのIP一貫性確保が可能です。
日本プロキシ選定のベストプラクティス
- レジデンシャルIPを優先：日本のECサイトはデータセンターIPの検出精度が高い。モバイルIPはさらに信頼性が高いが、コストとのバランスを考慮
- ローテーション戦略を使い分ける：価格監視はリクエストごとのIPローテーション、ログイン後のデータ収集はスティッキーセッション
- 文字コードを自動検出：
chardetやapparent_encodingを活用し、Shift-JISの文字化けを防止 - APPIを遵守：個人を特定可能なデータの収集は最小限にし、公開価格・在庫データに焦点を当てる
- コンビニ決済を考慮：在庫判定ロジックに決済方法の影響を組み込む
- 都市レベルのジオターゲティング：配送料や地域限定価格の正確な取得には、東京・大阪レベルのIP指定が有効
ProxyHatの料金プランでは、日本レジデンシャルプロキシを含む複数のオプションを提供しています。データ収集の規模と要件に応じて、最適なプランを選択できます。
キーテイクアウト
日本のECスクレイピング成功の5つの前提：
① 日本レジデンシャルプロキシは選択肢ではなく前提条件 — データセンターIPは高確率でブロックされる
② Shift-JISエンコーディングへの対応を忘れない —
cp932指定でNEC拡張文字に対応③ APPIに準拠したデータ収集範囲の設計 — 公開価格・在庫データは低リスク、個人データは慎重に
④ コンビニ決済が在庫判定に与える影響をロジックに組み込む — 未決済猶予期間の補正が必須
⑤ 東京・大阪のジオターゲティングで地域差を正確にキャプチャ — 都市レベルIPが配送料・在庫表示の正確性を担保する
