2026年のデータ収集戦略は「取得できる/できない」の二択ではなく、誰が・何を・どの頻度で・どの経路で取得するかを、計測→分類→制御→合意の順で運用設計し直すのが現実解です。TollBitはAI訪問が短期間で相対的に4倍（1/200→1/50）まで増えたこと、robots.txtの無視が約13%まで上がったことを示しており、AkamaiもAIボット起点の自動化トラフィック増を問題提起しています。こうした状況では、robots.txtだけに依存したガードは不十分で、API提供、レート制御、ボット課金/契約、ログ設計を含めた総合戦が必要です。 TollBitの「State of the Bots」では、2025年の四半期推移として次の傾向が示されています。 つまり、「学習データ用に一括で取りに来る」だけではなく、日々の回答生成のための“参照取得”が、広く・継続的に発生しやすい構造に変わっています。これは価格/在庫、ニュース、企業情報、FAQなど“鮮度”が重要な領域ほど影響が出ます。 （要旨）TollBitは、AI訪問の相対比が「1/200→1/50」へ上昇し、robots.txtを無視する比率が13%前後に増加したと報告しています。
結論
指標で見る急増
TollBitの観測
Akamaiの観測
Akamaiは2025年11月4日付の発表で、AIボットが自動化トラフィックを押し上げ、事業モデルや分析指標を毀損し得る点を強く問題提起しています。特に、公開コンテンツのスクレイピングが「価値を持ち去る」形で起きると、広告やサブスクなど既存収益モデルが揺らぐ、という文脈です。
Akamaiは、AIボット由来の活動が大きく増え、サイト運用・分析・収益に影響し得ることを示しています。運用側は「アクセス増＝成長」と短絡しない指標設計が必要です。
補助データの位置付け
周辺データとして、CloudflareがAIボット関連の大量リクエストをブロックした旨を公表した事例もあり、CDN/セキュリティ事業者側でも「量として無視できない」局面に入っています。個社の条件差はありますが、トレンド判断の補助線になります。
指標の比較表
ここまでの要点を「何を測っているか」の観点で整理します。数値は各社公表の範囲で、定義・観測母集団が異なる点は押さえてください。
| 指標提供者 | 見ているもの | 示唆 | 実務への落とし所 |
|---|---|---|---|
| TollBit | 出版社ネットワーク上のAIスクレイピング/訪問動向 | AI訪問比率の上昇、robots.txt無視の増加、RAG寄りへ | アクセス分類・課金/契約・参照用APIの設計 |
| Akamai | 広範な顧客基盤上の自動化/不正・ボット動向 | AIボット増が事業モデルや分析の前提を崩す | ボット対策を「セキュリティ」だけでなく「収益/分析」でも設計 |
なぜ2026年？
AIボット増加が「2026年の設計変更」につながる理由は、主に3つです。
- 取得目的の変化：学習用の一括取得より、RAG等の参照取得が増えると、取得が“継続的”になりやすい。
- ログ上の見え方：ブラウザ偽装や人間に近い振る舞いで、単純なUser-Agent判定が効きにくい。
- 価値移転の加速：要約/回答で完結すると、元サイトへの送客が減り、広告/課金モデルが揺らぐ。
「ブロックすれば終わり」ではありません。過剰遮断は正規ユーザーのUXを落とし、検索エンジンや提携先のクローラまで巻き込むリスクがあります。まずは計測と分類が先です。
webメディア側の見直し
計測を作り替える
最初にやるべきは「AIボットを前提とした計測」です。具体的には、アクセスログと分析基盤に、少なくとも以下を持たせます。
- UA/ASN/IPレンジ/JA3など複数シグナルでの疑似スコア
- HTML取得かAPI取得か、経路の区別
- エンドポイント別の負荷（検索・商品・画像・API）
- robots.txt遵守の有無（該当パスに対するアクセスの実測）
制御は段階的に
制御は「全面ブロック」より、段階を設けたほうが運用が安定します。
- レート制限（IP/セッション/トークン単位）
- 高コストパスの隔離（検索結果・大量ページング）
- 課金/契約導線（ボット向けの利用条件提示、APIキー発行）
- 疑わしいアクセスにだけ追加チャレンジ（JS/Proof of Work等）
robots.txtの限界
robots.txtは、守る相手には有効ですが、守らない相手には効きません。TollBitの報告でも、robots.txtを無視する比率が増えている点が示されています。
robots.txtは「方針表示」であり、強制力はありません。強制するなら、アプリ/エッジで制御する設計に寄せる必要があります。
一方で、robots.txt自体は検索エンジン等の正規クローラの調整にも使うため、廃止ではなく“併用”が基本です。
公式仕様の引用
robots.txtの位置付けを誤解しないために、仕様を短く確認します。Robots Exclusion Protocol（REP）の仕様では、robots.txtはクローラ向けにアクセス可否を示す仕組みとして定義されており、技術的強制ではなく「クローラの実装が解釈して従う」前提です。
（要旨）Robots Exclusion Protocolは、クローラがrobots.txtを取得・解釈し、アクセス可否を判断するための仕組みを定めています。
2026年の設計図
4層で考える
実務では、次の4層に分けると整理しやすいです。
- ポリシー：何を許可し、何を禁止するか（用途別）
- 提供手段：HTML、API、フィード、提携（ライセンス）
- 制御：レート制限、認証、WAF/ボット管理、課金
- 計測：AI/非AIの分類、コスト、収益/送客への影響
判断のチェック
「ブロック/許可/課金」の判断を、感覚ではなくチェック項目で揃えます。
- 対象データは更新頻度が高いか（高いほどAPI化が有利）
- 取得がビジネス価値を奪うか、送客を生むか
- 負荷がどこに集中しているか（検索・一覧・画像・API）
- 契約で解決できる相手か（連絡可能性、実体の有無）
よくある質問
AIボットは違法？
法的評価は国・契約・取得方法・対象コンテンツで変わります。少なくとも実務では、まず利用規約、認証回避の有無、過大負荷、個人情報、著作権・データベースの観点でリスクを棚卸しし、必要なら弁護士に確認してください。
AIか人間か判別できる？
単発の指標（UAだけ等）では難易度が上がっています。複数シグナル（挙動、アクセスパターン、ヘッダ、ASN、cookie、JS実行）でスコアリングし、誤検知を前提に運用ループを回す設計が現実的です。
一番コスパが良い対策は？
多くのケースでは、(1)高負荷パスのレート制限、(2)キャッシュ最適化、(3)API提供（必要最小限）を組み合わせるのが費用対効果が出やすいです。全面的な高度対策は、被害額が大きい領域から段階的に導入します。
