つまり、単に”技術的に可能”という話ではなく、運営側が運用上の制限対象として扱う前提がある、ということです。「少量なら大丈夫」「個人利用だから問題ない」といった解釈は、規約上は根拠がありません。

利用規約第17条の該当箇所

netkeibaの利用規約では、以下の行為が禁止事項として挙げられています。スクレイピングはこれらに抵触する可能性があります。

• サーバーに過度の負荷をかける行為
• 自動化されたプログラムによるアクセス
• データの無断複製・再配布
• サービスの正常な運営を妨害する行為

規約違反と法的リスクの関係

「規約違反＝直ちに刑事罰」とは限りません。しかし、規約違反があると、以下のような実務上のリスクが現実化します。

• アカウント停止：プレミアム会員の場合、課金中でもアクセス遮断される可能性
• IP単位のアクセスブロック：同一IPからの全アクセスが制限対象に
• 損害賠償請求：大規模収集やサーバー負荷が発生した場合の民事リスク
• 不正アクセス禁止法：アクセス制御の回避（認証突破等）を伴う場合は刑事リスクにも発展

通信制限の仕組み——何がどう検知されるのか

netkeibaのボット検知シグナル

多くのWebサービスと同様に、netkeibaも単純な「秒間リクエスト数」だけでなく、複数のシグナルを組み合わせてボット判定を行っています。確認されている検知シグナルは以下の通りです。

• 同一IPからの短時間の大量アクセス：1時間あたりのリクエスト数が一定閾値を超えると制限
• User-Agentの異常：未設定、または一般的なブラウザと一致しないUA
• リファラの欠落：直接URLを叩いているパターン
• アクセスパターンの不自然さ：人間がブラウザで閲覧する場合のランダム性がない、機械的な等間隔アクセス
• Cookie/JavaScriptの不整合：ブラウザ前提の挙動が欠落している場合

通信制限がかかるとどうなるか

netkeibaで通信制限がかかった場合、以下のような挙動が報告されています。

• IPベースの一時ブロック：同一IPからのアクセスが一定時間遮断される。自動解除までの目安は24時間程度
• 特定パスのみ403/429：/db/配下（データベース系ページ）だけアクセスできなくなるケース
• HTTP 400エラー：User-Agent未設定時に返される（2024年11月以降の新仕様）
• CAPTCHAの要求：人間であることの確認画面が挟まる
• アカウント停止：ログイン前提のデータ取得でアカウントが凍結される

2024年11月の対策強化——何が変わったのか

主な変更点

2024年11月初旬、netkeibaでクローラー対策が大幅に強化されました。それまで動作していたスクレイピングコードが軒並み動かなくなり、多くの個人ブログや技術記事で対応方法が議論されています。確認されている主な変更は以下の通りです。

• User-Agent必須化：User-Agentヘッダーが未設定の場合、HTTP 400 Bad Requestが返されるように
• 一部ページの動的レンダリング化：以前は静的HTMLで取得できたページの一部が、JavaScriptによる動的レンダリングに変更
• レート制限の強化：1時間あたりのリクエスト上限が従来より厳しくなった可能性

影響を受けるデータ取得パターン

よくあるエラーと原因

HTTP 400 Bad Request

2024年11月以降、最も多く報告されているエラーです。原因はUser-Agentヘッダーの未設定です。

requestsライブラリのデフォルトUser-Agentはpython-requests/x.x.xとなるため、netkeibaのサーバー側でボットと判定されます。一般的なブラウザのUser-Agentを設定することで回避できますが、これは「ボットであることを隠す行為」であり、規約上のリスクをさらに高める点に注意が必要です。

HTTP 403 Forbidden

アクセスが明示的に拒否されている状態です。主な原因は以下の通りです。

• IPベースの通信制限がかかっている
• robots.txtでDisallowされたパスへのアクセス
• 認証が必要なページへの非認証アクセス

HTTP 429 Too Many Requests

レート制限に達した場合に返されるステータスコードです。短時間に大量のリクエストを送信した場合に発生します。

データが空で返ってくる

HTTPステータスは200（成功）だが、取得したHTMLにデータが含まれていないケースです。これは動的レンダリングページにrequestsでアクセスした場合に起こります。JavaScriptが実行されないため、データ部分が空のHTMLが返されます。この場合はSeleniumやPlaywrightなどを使う必要があります。

スクレイピング時の技術的な注意点

リクエスト間隔（sleep）の設定

スクレイピングにおけるリクエスト間隔は、サーバーへの負荷とブロック回避の両面で重要です。一般的なガイドラインとして、以下の考え方があります。

• 最低1秒以上のインターバルを設ける
• 一定間隔ではなく、ランダムな揺らぎ（例: 1〜3秒）を入れる。機械的な等間隔アクセスはボット検知のシグナルになる
• 大量データを取得する場合は、バッチ処理にして日をまたいで分割する
• 1時間あたりのリクエスト数に上限を設ける（自主的なレート制限）

netkeibaの通信制限は1時間単位で判定されているとの検証報告があり、短時間に集中させるより、長時間にわたって低頻度でアクセスする方が制限を受けにくいとされています。ただし、具体的な閾値は公開されていません。

静的ページと動的ページの見分け方

netkeibaのページは、静的にHTMLが生成されるものと、JavaScriptで動的にデータが描画されるものが混在しています。どちらかによって、使用するツール（requests vs Selenium）が変わります。

判別方法：ブラウザの開発者ツールで「JavaScriptを無効化」した状態でページを読み込み、データが表示されるかどうかを確認します。データが消える場合は動的ページです。Chrome拡張「JavaScript Switcher」を使うと手軽に切り替えできます。

robots.txtの確認

netkeibaのrobots.txt（https://db.netkeiba.com/robots.txt など）では、特定のパスへのクローラーアクセスが制限されている場合があります。robots.txt自体にはアクセスを制御する法的拘束力はありませんが、「無視してアクセスした」という事実は、紛争時に不利に働く可能性があります。

取得できる主なデータの種類

競馬データ入手の現実的な代替手段

なぜ代替手段を検討すべきか

netkeibaのスクレイピングが抱える根本的な問題は、「仕様変更で突然動かなくなる」「制限で途中からデータが取れなくなる」という不安定さです。機械学習のトレーニングデータとして使う場合、データの一貫性・再現性は最重要であり、途中でデータソースが遮断されると、学習データ全体の信頼性が崩れます。

代表的な取得ルート比較

JRA-VAN Data Lab.とは

JRA-VANは、JRA（日本中央競馬会）の公式データを提供するサービスです。Data Lab.では、1986年以降の全レース結果、血統情報、馬体重、調教データなど、netkeibaで取得できるデータの大半を、正規ルートで安定的に取得できます。

• 月額550円（税込）からの有料サービス
• Windows向けのSDKが提供されている
• データ形式が統一されており、パースの手間が少ない
• 商用利用には別途契約が必要

JRA-VAN Data Lab. 公式サイト

JRAのWebサイトは二次利用について注意喚起があり、「私的使用」や「引用」の範囲を超えた複製・転載等は著作権法等に違反し得る旨が示されています。用途が公開・配布・商用に近づくほど、正規の提供形態や契約ベースの手段へ寄せる必要があります。

法務で押さえる論点

著作権とデータベース保護

日本の著作権法では、「選択又は体系的な構成によって創作性を有するデータベース」は著作物として保護されます。netkeibaのデータベースは、レース結果・馬情報・血統を独自の体系で整理・構成しているため、データベースの著作物として保護される可能性があります。

ただし、個々のデータ（着順、タイムなど）そのものは事実情報であり、著作権の対象外です。問題になるのは、データの「選択・配列」を丸ごと複製するような利用態様です。

不正アクセス禁止法

通常のWebスクレイピング（公開ページへのHTTPリクエスト）は、不正アクセス禁止法の対象外です。しかし、以下の行為は抵触する可能性があります。

• 他人のアカウントを使ったアクセス
• 認証メカニズムを技術的に回避するアクセス
• アクセス制御機能を回避する行為

よくある質問

少量なら問題ない？

少量でも規約上NGになり得る点は変わりません。また、技術的には少量でも「機械的なアクセス」は検知されることがあります。とはいえ、数ページを手動で閲覧してデータを書き写す行為まで禁止されているわけではありません。問題になるのは「自動化」の度合いです。再現可能な収集パイプラインとして組む場合は、早めに正規ルートへ切り替えることを推奨します。

Seleniumやブラウザ自動化なら大丈夫？

ヘッドレスブラウザで人間の閲覧に似せても、「自動化」である限り規約・運用上のリスクは変わりません。むしろ、Seleniumはrequestsより1リクエストあたりの時間が長い（ブラウザ起動・レンダリングのオーバーヘッド）ため、大量データ取得には効率が悪い面もあります。また、対策回避に近い設計は、紛争時の説明がさらに難しくなります。

スプレッドシートに直接取り込める？

GoogleスプレッドシートのIMPORTHTML関数やIMPORTXML関数を使えば、コードを書かずにWebページのテーブルデータを取り込めます。ただし、netkeibaの一部ページは動的レンダリングのため、これらの関数では取得できない場合があります。また、定期的に自動取得を行うと、サーバー側からIPブロックされるリスクがあります。

APIが無いならどうする？

netkeibaは公式APIを提供していません。現実的な選択肢は以下の3つです。

1. 正規データ提供を利用する：JRA-VAN Data Lab.など、契約に基づくサービスを使う
2. 許諾を取る：netkeiba運営元に直接連絡し、データ利用の許諾を得る
3. 用途を限定する：「引用・私的使用」の範囲で、手作業中心にデータを収集する

「技術的に取れるから取る」は、長期運用ではほぼ破綻します。

過去のコードが動かなくなった（「できなくなった」）

2024年11月のクローラー対策強化により、User-Agent未設定のリクエストはHTTP 400エラーが返るようになりました。まずはUser-Agentの設定を確認してください。それでも動かない場合、対象ページが動的レンダリングに変わっている可能性があります。ブラウザの開発者ツールでJavaScriptを無効にして、データが表示されるか確認してください。

sleepは何秒に設定すべき？

「何秒なら安全」という明確な基準はありません。ただし、一般的なガイドラインとして、最低1秒以上のインターバルを設け、ランダムな揺らぎ（1〜3秒程度）を加えることが推奨されます。大量データの取得では、1時間あたりのリクエスト数に自主的な上限を設けることが重要です。