はじめに
こんばんは！
GMOコネクトで執行役員CTOしている菅野哲（かんの さとる）です。
お元気ですか？ ワイは元気です。
今回は、2026年4月8日に-03版が公開されたばかりのInternet-Draftである draft-illyes-aipref-cbcp-03「Crawler best practices」 を取り上げます！
AI学習目的のWebクロールが社会問題化する中、IETFでクローラーの行動規範を標準化しようとする動きは注目に値します。本稿では、ドラフトの概要を解説したうえで、技術的な観点からレビューコメントを整理します。
参照先:
TL;DR
- Webクローラーが従うべき6つのベストプラクティスを定めるInformational I-D
- robots.txt（RFC 9309）の共著者であるGary Illyes氏が筆頭著者
- AIPREF WGの名前空間（
aipref）を使っているが、WG採用はされていない個人提出 - -03版時点でSecurity Considerationsが未記入（TODO）、誤字脱字も多く、初期段階
- AI学習クロールとリアルタイム検索クロールの区別がない点、REP（robots.txt）の限界への言及がない点など、スコープ面の課題が複数ある
1. 背景：なぜ今、クローラーのベストプラクティスが必要なのか
Webクローラーは、検索エンジンがWebページを発見・インデックスするための基盤技術として、インターネットの黎明期から存在してきました。GooglebotやBingbotに代表されるクローラーは、robots.txt（1994年に提案、2022年にRFC 9309として標準化）というシンプルな紳士協定のもとで30年近く運用されてきました。
この構図が大きく変わったのが、大規模言語モデル（LLM）の台頭です。AI時代におけるクローラーの役割は、従来の検索インデックス構築に加え、少なくとも以下の3つの用途に拡大しています。
- 学習データの収集: LLMの事前学習（pre-training）やファインチューニングのために、Web上の大量のテキストデータを収集する。Common Crawlのような大規模データセットの存在が示すように、Web全体がAIの学習素材となりうる状況です
- リアルタイム検索（RAG）: Retrieval-Augmented Generation（RAG）の仕組みにおいて、ユーザーの質問に回答するためにリアルタイムでWebページを取得・参照する。検索エンジンのインデックスとは異なり、取得したコンテンツがそのままLLMの回答生成に利用されます
- AIエージェントによるWeb操作: 自律的に行動するAIエージェントがWebサイトを巡回し、情報収集やタスク実行を行う。IETF 125でもAgentic AIに関するサイドミーティングが複数開催されるなど、標準化コミュニティでも関心が高まっている領域です
この多様化に伴い、コンテンツ制作者とAI事業者の間で深刻な摩擦が生じています。「検索エンジンにインデックスされるのは歓迎するが、AI学習に無断で使われるのは困る」という声は、ニュースメディアやクリエイターコミュニティで広く共有されています。一方で、既存のrobots.txtは用途別のアクセス制御に対応しておらず、「クロール全体を許可するか拒否するか」という粗い粒度の制御しかできません。
こうした状況を踏まえ、IETFでは2025年1月にAIPREF（AI Preferences）WGがcharterされ、コンテンツの収集・処理に関するプリファレンスの標準化が進められています。
本稿で取り上げるdraft-illyes-aipref-cbcp-03は、クローラー運用者が従うべき行動規範を定めるものですが、これはクロールされる側にとっても重要な文書です。なぜなら、「行儀のよいクローラーとは何か」が標準文書として定義されることで、Webサイト運営者は自サイトにアクセスしてくるクローラーの振る舞いを評価する基準を手にすることになるからです。IPレンジの公開義務（BP5）はクローラーの身元確認を可能にし、データ用途の説明義務（BP6）はコンテンツがどう使われるかの透明性を担保します。クロールされる側の方が圧倒的に多い以上、「自分のサイトを守るために、クローラーに何を要求できるのか」を知っておくことには実務的な価値があります。
2. ドラフトの基本情報
| 項目 | 内容 |
|---|---|
| ドラフト名 | draft-illyes-aipref-cbcp-03 |
| タイトル | Crawler best practices |
| ステータス | Active Internet-Draft（個人提出） |
| Intended status | Informational |
| RFC stream | (None) |
| 最終更新 | 2026-04-08 |
| 著者 | Gary Illyes (Independent), Mirja Kühlewind (Ericsson), AJ Kohn (Blind Five Year Old) |
著者について
- Gary Illyes: robots.txt のRFC 9309（Robots Exclusion Protocol）の共著者。IETFのAIPREF関連ドラフトを複数執筆しています。本I-Dでは「Independent」と記載されていますが、Illyes氏の個人サイト（2025年9月時点）ではGoogle Search チームのAnalystと記載されており、所属変更の時期は【要確認】です。
- Mirja Kühlewind: Ericsson所属。IETFのTransport Area Director（AD）を歴任し、IETF標準化プロセスに深く関与してきた人物です。
- AJ Kohn: SEO/サーチ業界の専門家。Blind Five Year Oldの創設者。
3. ドラフトの概要：6つのベストプラクティス
本ドラフトは、Webクローラーの運用者が従うべき6つのベストプラクティスを定めています。
BP1: Robots Exclusion Protocol（REP）の遵守
RFC 9309で定義されたREPをサポートし、サイトオーナーがクロールをオプトアウトできるようにすることを求めています。robots.txtを使用しないサイトについては、HTTPヘッダーの X-Robots-Tag を尊重する必要があるとしています。
BP2: User-Agent文字列による容易な識別
HTTPリクエストヘッダーの User-Agent でクローラーを明確に識別できるようにし、クローラーの説明ページへのURLを含めることを求めています。
例: User-Agent: Mozilla/5.0 (compatible; ExampleBot/0.1; +https://www.example.com/bot.html)
BP3: サイトの通常運用を妨げない
RFC 9110（HTTP Semantics）Section 15.6 で定義されたHTTPステータスコードに基づくバックオフロジックの実装を求めています。加えて、以下の事項を推奨しています。
- 同一リソースへの同時リクエストを避ける
- クロール速度を制限する
- 認証・CAPTCHA・ペイウォールのバイパスを禁止
- HTTP GETを基本とし、JavaScriptの実行負荷を慎重に考慮する
BP4: キャッシュディレクティブのサポート
RFC 9111（HTTP Caching）に従い、同一URLへの繰り返しアクセスを削減することを求めています。
BP5: クロール用IPレンジの公開
クローラー運用者は、クロールに割り当てたIPレンジをJAFAR形式（draft-illyes-aipref-jafar-00）で公開し、クローラー説明ページから <link rel="help"> でリンクすることを求めています。
BP6: データ使用目的とブロック方法の説明
収集データの用途説明、ブロック用REPファイルの例示、連絡先の掲載をクローラーのドキュメントページに含めることを求めています。
4. AIPREF WGとの関係
ドラフト名に aipref が含まれていますが、これはAIPREF WGに採用されたWGドラフトではなく、個人提出のI-Dです。
AIPREF（AI Preferences）WGは2025年1月にcharterされた正式WGで、AIモデル開発・展開・利用に関するコンテンツの収集・処理についてのプリファレンス表現を標準化することを目的としています。Chair は Suresh Krishnan 氏と Mark Nottingham 氏です。
本CBCPドラフトは、AIPREF WGの成果物群を補完する位置づけにあると考えられますが、WGのcharterで定義されたdeliverableには含まれていません。今後WG adoptionされるかどうかは注目ポイントです。
5. 技術的なレビューコメント
以下、本ドラフトの完成度向上に向けた技術的な指摘事項をまとめます。これらはIETFのレビュー文化に沿った建設的なコメントとして整理したものです。
5-1. 文書品質の問題
-03版にしては誤字脱字が目立ちます。Abstractの "pratices"、Section 1の "artifical"、Section 2.3の "JavaScrt"（2箇所）など、本文全体で10箇所近くの綴りミスやテキスト重複が確認できます。Security Considerationsが「TODO Security」、Acknowledgementsが「TODO acknowledge」のままである点も含め、レビューを求める文書としての体裁が整っていない印象です。
5-2. 規範言語（Normative Language）の混乱
Section 3でBCP 14（RFC 2119 / RFC 8174）を引用し、大文字キーワードに特別な意味を持たせると宣言していますが、本文中に大文字の MUST / SHOULD / MAY がほぼ出てきません。
セクション見出しには小文字の "must" が頻出し、本文では "should" と "must" が小文字で混在しています。この結果、各推奨事項の規範レベル（遵守義務なのか推奨なのか）が曖昧になっています。
文書設計として、以下のいずれかを明確にすべきです。
- BCP的な規範文書を目指す → 大文字 MUST / SHOULD を適切に使い、Intended statusをBCPに設定する
- Informationalなガイダンスに留める → BCP 14の引用自体を削除するか、注記レベルに留める
5-3. スコープの不明確さ：「crawler」の定義がない
本文では「automatic clients, such as crawlers and bots」と述べていますが、以下のような用途の区別が議論されていません。
- 検索エンジンのインデックスクローラー
- AI学習データ収集クローラー
- LLMのリアルタイム検索（RAG）用クローラー
- 価格比較・スクレイピング用ボット
特にAI学習用クロールとリアルタイム検索用クロールでは、サイトオーナーの許容度が大きく異なる可能性があり、これはAIPREF WG全体の議論とも関連する重要な論点です。
5-4. REPの限界への言及がない
REP（RFC 9309）への準拠を第一のベストプラクティスとしていますが、REP自体の限界が議論されていません。
- robots.txtは認証なしのプロトコルであり、User-Agentの詐称に対する防御がない
- 用途別の制御ができない（「検索インデックスは許可するがAI学習は禁止」というニーズに対応できない）
- X-Robots-Tagへの言及がある（Section 2.1）が、これはRFCで定義されていない仕様であり、Normative Referenceなしに遵守を求めるのは標準文書として不適切
5-5. Section 2.3の過負荷
Section 2.3（「サイトの通常運用を妨げない」）に、性質の異なる複数の要件が詰め込まれています。
- レート制限・バックオフロジック（負荷制御）
- URL重複排除・クロールスケジューリング（効率化）
- 認証・CAPTCHAバイパスの禁止（セキュリティ）
- HTTPメソッドの制限（プロトコル制約）
- JavaScript実行の考慮（リソース消費）
特に認証バイパスの禁止やHTTPメソッドの制限は、運用負荷の問題というよりセキュリティ・プロトコルの問題であり、独立セクションまたはSecurity Considerationsに移すべきです。
5-6. IPレンジ公開（Section 2.5）の実装上の問題
IPレンジのJAFAR形式での公開を求めていますが、いくつかの問題があります。
- JAFAR自体がまだ-00版であり、Normative Referenceとしての安定性に欠ける
- クラウドインフラ（AWS、GCP等）のIPレンジは頻繁に変動し、「reasonably up-to-date」の基準が不明
-
<link rel="help">の使用について、helpリンク関係型は IANA Link Relations Registry に HTML 仕様への参照として登録されており、その意味は「コンテキストに対するヘルプ（context-sensitive help）」とされています。IPレンジファイルへのリンクはこの定義と意味的に一致しません。新しいlink relationを登録するか、別の既存relationの使用を検討すべきです
5-7. データ用途説明（Section 2.6）の不十分さ
「収集データの用途を説明せよ」とあるだけで、以下が欠けています。
- 説明の粒度・形式が未定義（「AI学習に使用」で十分なのか、モデル名・保持期間まで求めるのか）
- 機械可読な用途表明の仕組みがない（人間向けのドキュメントページだけでは大規模な自動化に対応できない）
この点はAIPREF WGが取り組んでいるAI preferences vocabularyとの連携で解決できる可能性がありますが、本ドラフトでその関係性に触れていません。
5-8. 研究クローラーの免除規定の範囲が広すぎる
Introductionで「self-declared research crawlers ... may exempt themselves from any of the Crawler Best Practices with a rationale」と述べていますが、自己申告ですべてのベストプラクティスを免除できる規定は抜け穴になりうるリスクがあります。
少なくともREP遵守（BP1）やIPレンジ公開（BP5）は免除不可とするか、免除の条件をより具体的に定めることが考えられます。
5-9. 既存の取り組みとの関係整理が欠落
以下の既存仕様・取り組みとの関係が議論されていません。
- TDMRep（W3C）: Text and Data Mining Reservation Protocol。EU DSM Directive対応のオプトアウト仕組み
- ai.txt: 業界で普及しつつある非標準的なAIクローラー制御手法
- AIPREF WGの他のドラフト: AI preferences vocabularyやHTTPヘッダーでの表明方式との整合性
IETFの文書として法的議論を深掘りする必要はありませんが、Related Workとして言及し、スコープの境界を明確にすることで、本ドラフトの位置づけがより明確になります。
6. まとめ
draft-illyes-aipref-cbcp-03は、Webクローラーの行動規範をIETF文書として明文化しようとする意欲的な試みです。robots.txt（RFC 9309）の共著者であるGary Illyes氏が筆頭著者であり、業界での実務経験に基づいた内容である点は評価できます。
一方で、-03版時点では以下の課題が残っています。
- 文書品質（誤字脱字、TODO残存）
- 規範言語の整理（BCP 14キーワードの使い方）
- crawlerの定義とスコープ（用途別の区別）
- X-Robots-Tagの参照根拠（非標準仕様への依存）
- 研究クローラーの免除範囲の限定
- AIPREF WGの他の成果物や既存の取り組み（TDMRep等）との関係整理
AIクローラーによるコンテンツ収集の透明性・制御可能性は、各国の規制当局（EU AI Act、日本の著作権法30条の4との交差領域等）でも議論が進んでおり、IETFレベルでの技術的規範の策定は今後ますます重要になると考えられます。
AIPREF WGの今後の動向とあわせて引き続きウォッチしていきたいと思います。
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。