2025 年 3 月 28 日（金曜日）
Robots Exclusion Protocol（REP）に関する以前の投稿では、そのさまざまなコンポーネント（robots.txt や URI レベル制御など）を使用して何ができるかを解説してきました。今回の投稿では、自動クライアントとヒューマン ウェブの関係が常に進化を続ける中で、REP がどのようなサポート的役割を果たすことができるかについてご紹介します。
REP（特に robots.txt）は、2022 年に RFC9309 として標準規格となりました。しかし、REP 普及の大部分は、すでに標準規格化の前に達成されていました。REP は、1994 年から 2022 年という長い年月をかけて、何十億ものホストや事実上すべての主要なクローラー オペレーター（マルウェア スキャナなどの検知対策型クローラーを除く）に採用されるほど普及しました。REP は、シンプルでありながら多用途なシンタックスを使用して設定を表現することができる、簡潔かつエレガントなソリューションです。その 25 年の歴史の中で、元の形態から進化する必要がほとんどありませんでした。クローラーが普遍的にサポートしているルールに絞って見ると、導入されたのは allow ルールだけです。
これは、他にルールがないということではありません。クローラー オペレーターは、独自のルールを策定できます。たとえば、「clean-param」や「crawl-delay」などのルールは RFC9309 に含まれませんが、一部の検索エンジンではサポートされています（ただし、Google 検索ではサポートされていません）。「sitemap」ルールも RFC9309 には含まれませんが、すべての主要な検索エンジンでサポートされています。十分なサポートが得られれば、REP の正式なルールになる可能性があります。
なぜなら、REP は実際には「更新」できるからです。RFP は広くサポートされているプロトコルであり、インターネットとともに成長していくでしょう。変更を加えることは不可能ではありませんが、容易ではありません。REP が広くサポートされているため、変更は容易であってはならないのです。標準規格に対するあらゆる変更と同様に、パブリッシャー側とクローラー オペレーター側の双方で、変更がプロトコルの大多数のユーザーに利益をもたらすというコンセンサスが得られなければなりません。
RFP はシンプルで幅広く採用されているため、新しいクロール設定を実装するのに最適です。たとえば、非常に多くのパブリッシャーはすでに robots.txt とそのシンタックスに精通しているため、robots.txt に変更を加えることは比較的自然なことです。その一方で、クローラー オペレーターはすでに堅牢かつ十分にテストされたパーサーとマッチャーを備えており（Google も独自のrobots.txt パーサーをオープンソース化しています）、新しいルールで解析の問題が発生する可能性は低いと考えられます。
REP URI レベルの拡張機能、X-robots-tag HTTP ヘッダー、およびそのメタタグの対応部分についても同様です。オプトアウトの設定を行うための新しいルールが必要な場合は、簡単に拡張できます。しかし、どのように行えばいいでしょうか？
読者である皆さんができる最も重要なことは、自分のアイデアを公に語り、そのアイデアを支持してくれる人を集めることです。REP は一般に公開されている標準規格であるため、特定の組織が一方的に変更を加えることはできません。もちろん、その組織が独自に新しいものへのサポートを実装することはできますが、それが標準規格になることはありません。しかし、その変更について発信し、それがエコシステム（クローラー オペレーターとサイト運営エコシステムの両方）の全体に利益をもたらすことを示すことで、コンセンサスが促進され、標準規格の更新への道が開かれるでしょう。
同様に、プロトコルに何かが欠けている場合も、そのことを公に発信してください。sitemap はコンテンツ制作者と検索エンジンの双方にとって有用であったため、robots.txt で広くサポートされるルールとなり、拡張機能の採用への道が開かれました。ルールに関する新しいアイデアがある場合は、robot.txt の利用者や作成者に意見を求め、そうした人たちが提起する可能性のある（そして起こり得る）問題を協力して洗い出し、提案をまとめてください。
公益に資するものであれば、価値ある提案となるでしょう。