AIクローラーのトラフィックは一様ではない：Webサイトはアクセス範囲をどう決めるか

Webサイトは、ユーザーに見つけてもらいたい一方で、コンテンツを無制限にスクレイピングされたくはありません。この2つの目的は矛盾しません。問題は、自動化された訪問をすべて「AIクローラー」とひとくくりにすると、選択肢が全面的な開放か全面的なブロックかの二択になりがちなことです。

より有用なのは、そのアクセスが、検索インデックスを構築するためのものか、モデルを学習させるためのものか、ユーザーに代わってタスクを実行するためのものかで区別することです。目的が違えば、得られる見返りも、かかる負荷も、必要な制御も異なります。本記事では、Cloudflareが公開している変更を取り上げ、コンテンツサイトやプロダクトのホームページがこの判断をどう行えるかを考えます。事実確認は2026-9-5時点のもので、いずれのWebサイトの実際の設定も変更していません。

2026-9-8のレビュー時点でも、Cloudflareの発表と設定ドキュメントでは、9-15のデフォルト変更は今後の予定として記載されていました。本記事では、初回公開時の予定と当時の文脈をそのまま残しています。その日付を迎えた時点で変更が予定どおり反映されるかどうかは、公式ドキュメントを改めて確認する必要があり、ここで先回りして断定することはできません。

AIのオン・オフからアクセス目的へ

Cloudflareは2026-7の発表で、AI関連のトラフィックをSearch、Agent、Trainingにさらに分類しています。Searchは後のクエリに備えてコンテンツを収集またはインデックス化するためのもの、Agentはユーザーに代わって即時のタスクを実行するもの、Trainingはモデルの学習やファインチューニングに使われるものです。これはCloudflareの製品上の分類であり、インターネット全体で一律に適用されている標準ではありません。

この区別に注目すべきなのは、1つの公開ドキュメントが複数の役割を担いうるからです。検索システムは、後からユーザーが答えを見つけられるようにそのドキュメントを読みます。アシスタントは、ユーザーがAPIをデバッグしている最中に、その場で読みます。一方、学習用の収集は、その時点の訪問者によるクエリとはまったく無関係な場合もあります。

プロダクトのホームページにとって、2つ目の種類の訪問に本質的に価値がないわけではありません。開発者がアシスタントにパラメータの意味を尋ねたとき、アシスタントがバージョンに即した正確なドキュメントにアクセスできるかどうかは、ユーザーが連携作業を進められるかどうかに影響します。この価値は、必ずしもブラウザでのクリックとしてすぐに表れるとは限りません。

ただし、すべてのエージェントにアクセスを許可すべきだという意味ではありません。訪問が許可された用途に沿っているか、認証が必要か、異常な負荷をかけていないかは、引き続き個別に評価する必要があります。名前に「AI」が付くトラフィックをすべて顧客獲得の機会とみなすのは、すべてを価値のないトラフィックとみなすのと同じくらい乱暴です。

9-15の予定は、すべてのWebサイトで適用済みとは言えない

Cloudflareの設定ドキュメントによると、2026-9-15に一部のデフォルト動作を変更する予定です。新たにCloudflareへ追加されたドメインでは、検索は維持したまま、学習とエージェントのトラフィックをデフォルトでブロックします。あわせて、学習トラフィックのブロックポリシーが検索と学習を兼ねるクローラーにどう適用されるかも更新されます。

この記述には、予定日、新たに追加されたドメイン、対象となるページ、複数目的の訪問に関するルールという、省略できない前提条件がいくつも含まれています。確認時点の日付は依然として9-5であり、「Cloudflareがすべてのウェブサイトに対してAIのアクセスをブロックした」と言い換えることはできません。ウェブサイトの最終的な動作は、実際の設定と今後の製品アップデートによって決まります。

関連サービスを利用している場合、確認すべきなのは、まとめ記事の見出しの表現の強さではなく、現在のアカウントポリシー、ページ分類、実際のアクセスログです。サイト全体に適用される設定の切り替えは、用途の異なる複数のページに同時に影響する可能性があります。また、複数目的と分類された訪問者が、その名前だけを根拠に許可されていると判断することはできません。

私たちの見解では、こうした変更は、感情に任せてサイト全体の設定を切り替えるきっかけではなく、対象範囲を見直すきっかけにすべきです。まず、見つけてもらうことを目的としたコンテンツを洗い出し、現在のポリシーがその目的と矛盾していないかを確認します。本記事は特定の設定をそのまま真似ることを推奨するものではなく、お客様のアカウントを監査したことを示唆するものでもありません。

Robots.txt、利用意向、実際のブロック――それぞれ異なるレイヤー

RFC 9309は、robotsの除外ルールがアクセス認可の仕組みではないことを明記しています。これらのルールは準拠するクローラーにサイトへのアクセス方法を指示するものであり、ログイン認証情報、権限チェック、サーバー側のアクセス制御の代わりにはなりません。

つまり、機密性が求められるドキュメントを、robots.txtだけに頼って隠すべきではありません。逆に、公開を意図した説明ページは、robots.txtでクロールが許可されていても、ネットワークやアプリケーションの別のルールによってブロックされる場合があります。アクセスできるかどうかは、単一のファイルに頼らず、実際のレスポンスを確認して判断する必要があります。

Cloudflareの関連するお知らせでは、現在テスト中のコンテンツ利用意向のシグナルも紹介されており、意向を表明しても直接ブロックが発動するわけではないとされています。ウェブサイト運営者は、「自分がどのような意向を表明したか」「サービスがどのようなルールを適用したか」「訪問者が実際にどのような行動をとったか」を分けて記録すべきです。シグナルを送信しても、コンテンツが学習に使われたり再現されたりしなくなることが保証されるわけではありません。

本記事が扱うのは技術面とプロダクト面の範囲であり、アクセス設定だけでコンテンツの権利や利用許諾が完全に決まるとはみなしません。制限が必要な非公開情報は適切な認証と権限の仕組みで保護する必要があり、公開資料ではバージョン、出典表示、利用範囲を明確にする必要があります。

読まれることと引用されることは別物

GoogleのAI検索機能に関するドキュメントでは、引き続きSEOの基本が重視されています。具体的には、クロール可能であること、内部リンクから発見できること、主要なコンテンツがテキストで提供されていること、構造化データがページ本文と一致していることです。関連するAI検索機能で補足リンクとして表示される対象となるには、ページがインデックス登録とスニペット表示の要件を満たす必要があります。ただし、要件を満たしてもクロール、インデックス登録、表示のいずれも保証されません。

したがって、サーバーログにクローラーのリクエストが記録されていても、それはアクセスが発生したことを示すにすぎません。ページが検索インデックスに登録されたことの証明にはならず、まして特定のAIの回答がそのコンテンツを利用したことの証明にもなりません。回答の中でブランドが言及されていても、出典リストがそのページを引用したとは限りません。

コンテンツチームにとって、この区別によって日々の評価方法も変わります。記事を新たに公開したら、まず公開状態でアクセスできるか、リンク、内容の正確さを確認し、その後で検索システムでのインデックス登録と表示を確認できます。最初から「AIに引用されたかどうか」を唯一の合格基準にすると、早すぎる段階で失敗と判断したり、偶発的な言及を長期的な成長と取り違えたりするおそれがあります。

呼び出し側にも同様の問題があります。検索でのマッチング、本文の読み取り、結論の検証はそれぞれ別のステップです。当社のエージェント向け検索ツール選定ガイドではこの違いを利用者の視点から説明しています。一方、本記事はコンテンツ所有者の視点からアクセスと配信を考察しており、両者を単一の指標にまとめることは避けています。

AIへの姿勢ではなくページの目的に基づく判断

アクセスの目的を議論する前に、ページを分類することをおすすめします。公開されているプロダクトドキュメントは通常、ユーザーが内容を理解して統合を完了できるよう支援することが主眼です。独自の調査記事では、出典表示、引用、継続的なメンテナンスを優先する場合があります。ログイン後の顧客データは、可視性を高めるために公開するのではなく、ユーザー権限による制限を維持する必要があります。

ページの分類ごとに、次の4つの具体的な問いを立てることができます。

1. 誰がどのような状況で読むことを想定しているか。プロダクトを知ろうとしている見込みユーザーか、トラブルシューティング中の既存ユーザーか。
2. 自動アクセスはこのタスクの完了に役立つか。また、それを裏付ける確認可能な根拠は何か。
3. どのアクセスパターンが想定範囲外か。それには意向の表明、トラフィック制御、厳格な認証のいずれが必要か。
4. ポリシーを調整した場合、対象ユーザーに悪影響がないこと、元の設定に戻せることをどのように確認するか。

これは個々のクローラーごとに複雑なポリシーを書くことを求めるものではなく、ルールの変更に明確な根拠を持たせることを意味します。たとえば、APIドキュメントがユーザーのトラブルシューティングを支援するためのものであれば、ユーザーが通常の操作で読み込んだときに本文が正しく返されるかを確認します。データがログインユーザーに限定されているなら、権限のないリクエストが適切に拒否されるかをテストします。それぞれの成功基準はまったく異なります。

ルールの変更はデータのサンプルにも影響します。公開ソースが一時的にアクセスできなくなると、観測システムが受け取るコンテンツは減りますが、それは外部での議論が実際に減ったことを意味しません。複数ソースを横断して分析する際は、欠損データをゼロとして扱わず、カバレッジの欠落をそのまま記録しておく必要があります。当社のマルチプラットフォーム評判モニタリングのブループリントでは、収集状況とビジネス上の結論を切り分けることを、実際に顧客で確認された障害事例ではなく、方法論上の注意点として取り上げています。

効果の評価と通常利用への影響の回避

ポリシーを調整した後は、条件をそろえた観測期間で次の指標を追跡します。自動化トラフィックの量とエラー率、重要ページのアクセス可否、検索での表示回数とクリック数、検証可能な引用リンク、ドキュメントの閲覧や統合の完了につながるユーザーのコンバージョン行動です。これらの数値を曖昧な「AIトラフィック」という指標にまとめないでください。

効果の一部は、一時的に要因を特定できないままになる場合があります。たとえば、ユーザーがアシスタントを通じてプロダクトを知り、その後ホームページに直接アクセスした場合、通常の参照元トラッキングでは一連の経路を完全に把握できないことがあります。正しい対応は、ポリシーの効果を証明するために推定値を補うのではなく、この不明な部分を不明なまま残しておくことです。

AIによるアクセスの管理はより細かくなっており、ウェブサイトのガバナンスもそれに合わせる必要があります。まずどのコンテンツが誰のためのものかを明確にし、次にアクセスの目的、実際のルール、利用結果を確認します。発見されることが必要なホームページでは、自動化ボットのログ件数を最大化することが目標ではありません。保護されたコンテンツでは、すべての自動化リクエストを失敗させることが目標ではありません。目指すのは、許可された範囲内で、適切な人やツールがタスクを完了するのに十分な信頼できる情報を得られるようにすることです。