はじめに
Netkeibaの通信制限の内部処理が変わったような挙動を確認しました。
今までは、時間単位でのアクセス回数の上限を設けて通信制限を行っている、と推測できました。
2025年10月時点で、今までの推測される通信制限のルールが、変わっている挙動を確認しました。
確認できた通信制限のルールと対応案ついて整理しました。
スクレイピングを行う際には、利用規約を遵守し、サービス運営に支障をきたさないよう心掛けることが重要です。
推測されるNetkeibaのアクセス制限ルール
単純なアクセス回数による制限だけではなく、ボット特有の振る舞いを検知してアクセス制限を設けている可能性があります。
推測されるアクセス制限ルールは下記となります。
アクセス制限ルール１：高頻度アクセスに対するレスポンス遅延
事象：スクレイピング中に処理時間が大幅に増加する
スクレイピングでデータを取得していると、不定期に処理時間が大幅に増加することを確認しました。おそらくIPアドレスごとにアクセスパターンを監視し、アクセスパターンがスクレイピング(＝短時間で複数回アクセス)と判断されると、サーバ側(netkeiba.com)で意図的に応答を遅くしている、と思われます。
単純なブロックではなく、スクレイピングの異常終了あるいはスクレイピング処理の大幅に低下させるのが狙いだと考えられます。
アクセス制限ルール２：スクレイピングへの応答に対してコンテンツ提供の阻害
事象：スクレイピング中にコンテンツの一部が想定通りに表示されない
競走馬の血統情報などはJavaScriptで描画されています。重要なコンテンツを送信しない、あるいは極端に遅れて送信している挙動を確認しました。
アクセス制限ルール３：IPアドレスによるアクセス制限
事象：Netkeibaのレース詳細ページにアクセスできない
短時間でスクレイピングによるアクセスを繰り返すとIPアドレスによるアクセス制限が発動するのを確認しました。
アクセス制限は24時間で解除されるようです。
本事象が発生した際のhttpのレスポンスステータスコードは400でした。400はBad Request(ヘッダやパラメータが異常)を示す内容です。レスポンスステータスコードが、Too Many Requestsの429ではなく400なのは、おそらくスクレイピングやボットによるアクセスの妨害・混乱が目的だと思われます。
アクセス制限への対応案
確認できたアクセス制限の挙動への対応は、下記３つが考えられます。
- 同時接続数を減らす
- Seleniumではなく、Playwrightを用いる
- 人間らしい操作を模倣する
Playwrightと合わせて、playwright-stealthライブラリを用いることで、スクレイピングやボットの挙動を検知されにくくすることは可能です。
以上です。
コメント