エージェント導入準備度スコアのご紹介。Webサイトのエージェント対応状況

ウェブは、常に新しい基準に適応しなければなりません。Webブラウザと対話できるようになり、その後、検索エンジンと対話できるようになりました。現在は、AIエージェントとの対話も必要です。

本日、サイト所有者がエージェントの認証方法、エージェントが閲覧できるコンテンツの制御方法、受信フォーマット、支払い方法などを理解し、エージェント向けにサイトを最適化できるよう支援する新しいツールisitagentready.comを発表いたします。また、インターネット全体の各エージェント基準の導入全般を追跡するために、Cloudflare Radarに新たなデータセットを導入しました。

当社は、模範的な取り組みを目指したいと考えています。そこで同時に、最もエージェントフレンドリーなドキュメントサイトにするため、最近Cloudflareの「開発者向けドキュメント」を全面改訂したこともご紹介します。これにより、AIツールがより迅速かつ大幅に低コストで質問に回答できるようになりました。

簡単に答えると、あまり良くありません。これは予想通りである一方で、基準が導入された場合、エージェントが現在よりもさらに効果を発揮できることを示しています。

Cloudflare Radarはこれを分析するために、インターネット上にある20万件の最も多く訪問されたドメインを取得し、エージェントによる対応が重要ではないカテゴリ（リダイレクト、アドサーバー、トンネリングサービスなど）を除外して、AIエージェントが現実的にインタラクトする必要があると考えられる企業、パブリッシャー、プラットフォームに焦点を絞り、当社の新しいツールでスキャンしました。

その結果、多数のドメインカテゴリを対象に各基準の導入状況を測定できる新しい「AIエージェント向け基準の採用状況」チャートが、Cloudflare Radar AIのインサイトページでご覧いただけるようになりました。

個別のチェックを確認してみると、次のような点が明らかになりました。

• robots.txtはほぼ普遍的であり、78%のサイトが導入しています。しかし、その大半はAIエージェント向けではなく、従来の検索エンジンクローラー向けに書かれています。

• コンテンツシグナル：サイトの4%がrobots.txtでAI利用の設定を宣言済みです。これは普及しつつある新しいスタンダードです。

• Markdownコンテンツネゴシエーション（Accept: text/markdownでtext/markdownを配信）は、3.9%のサイトで対応しています。

• MCP Server CardsやAPIカタログ（RFC 9727）など、新たに登場している基準は、データセット全体で15件未満のサイトでしか見られません。新しい基準をいち早く導入し、エージェントとうまく機能させることで、他と差別化を図れるチャンスと言えるのではないでしょうか。

このチャートは毎週更新されます。データはData ExplorerやRadar APIからもアクセスできます。

isitagentready.com にアクセスし、サイトのURLを入力することで、ご自身のWebサイトのエージェント導入準備度スコアを取得できます。

行動につながるフィードバックを提供するスコアや監査は、以前から、新しい基準の採用を促進させるのに役立ってきました。たとえば、Google Lighthouseは、パフォーマンスとセキュリティのベストプラクティスを基準にWebサイトにスコアを付け、サイト所有者が最新のWebプラットフォーム基準を採用するように案内します。同様の手段により、サイト所有者がAIエージェントのベストプラクティスを導入できるようにすべきだと考えています。

サイトを入力すると、Cloudflareはどの基準に対応しているかを確認するためにリクエストを送信し、以下の4つの次元に基づいてスコアを提供します。

• 発見可能性：robots.txt、sitemap.xml、Linkヘッダ（RFC 8288）

• コンテンツ：エージェント向けマークダウン

• ボットアクセス制御：コンテンツシグナル、robots.txt上のAIボットルール、Web Bot Auth

• 機能：Agent Skills、APIカタログ（RFC 9727）、RFC 8414およびRFC 9728経由のOAuthサーバーの検出、MCPサーバーカード、およびWebMCP

^{サンプルWebサイトを対象としたエージェント導入準備度チェックの結果のスクリーンショット。}

さらに、当社はサイトがエージェンティックコマーススタンダード（x402、Universal Commerce Protocol、Agentic Commerce Protocolなど）に対応しているかをチェックします。ただし、現在のところスコアには反映されません。

合格しなかった各チェックに対し、コーディングエージェントに渡してサポートを実装できるプロンプトを提供します。

また、当サイトそのものも、エージェント対応可能であり、自ら実践しています。公開しているステートレスのMCPサーバー（https://isitagentready.com/.well-known/mcp.json）において、Streamable HTTP経由のscan_siteツールのおかげで、Webインターフェースを使うことなく、あらゆるMCP対応エージェントがプログラムでWebサイトをスキャンできます。また、チェック対象となるすべての基準に対応するスキルドキュメントを含むAgent Skillsインデックス（https://isitagentready.com/.well-known/agent-skills/index.json）も公開されており、エージェントは何を修正すべきかだけでなく、その修正方法も把握できます。

各カテゴリーのチェック項目と、その項目がエージェントにとって重要な理由を探っていきましょう。

robots.txtは1994年から存在し、大半のサイトに設置されています。エージェントにとって2つの目的があります。クロールルール（誰が何にアクセスできるか）を定義することと、サイトマップを指し示すことです。サイトマップとは、Webサイト上のすべてのパスを列挙したXMLファイルのことで、エージェントがすべてのリンクをクロールすることなく、すべてのコンテンツを見つけられる地図のようなものです。robots.txtは、エージェントが最初に目を付ける場所です。

サイトマップに加えて、エージェントはHTTP応答ヘッダーから直接重要なリソースを検出することもできます。特に、Link応答ヘッダー（RFC 8288）を利用します。HTML内に埋もれているリンクとは異なり、LinkヘッダーはHTTP応答の一部であるため、エージェントがマークアップを解析することなくリソースへのリンクを見つけることができます。

HTTP/1.1 200 OK
Link: </.well-known/api-catalog>; rel="api-catalog"

自サイトにエージェントを導入することと、実際にコンテンツを読み取れるようにすることは別物です。

AIの進展スピードを考慮すると一昔前にも思える2024年9月に、Webサイトの表現を大規模言語モデル（LLM）対応させ、モデルのコンテキストウィンドウ内に収める方法として、llms.txtが提案されました。llms.txtは、サイトのルートにあるプレーンテキストファイルで、このサイトは何か、その上に何があるのか、重要なコンテンツがどこにあるのかといった構造化された読み取りリストをエージェントに提供します。クローラーがインデックスを作成するためのものではなく、LLMが読むためのサイトマップだとお考えください。

# My Site
> A developer platform for building on the edge.
## Documentation
- [Getting Started](https://example.com/docs/start.md)
- [API Reference](https://example.com/docs/api.md)
## Changelog
- [Release Notes](https://example.com/changelog.md)

Markdownコンテンツネゴシエーション はさらに一歩進んでいます。エージェントが任意のページをフェッチしてAccept: text/markdownヘッダーを送信すると、サーバーはHTMLの代わりにクリーンなMarkdownバージョンで応答します。Markdownバージョンではトークン数が大幅に減り（ケースによっては最大80%のトークン削減を計測）、ほとんどのエージェントツールがデフォルトでコンテキストウィンドウに制限を設けているため、応答が高速化され、安価になり、最後まで読まれる可能性が高まります。

デフォルトでは、サイトが正しくMarkdownのコンテンツネゴシエーションを処理しているかのみを確認し、llms.txtについては確認しません。スキャンをカスタマイズしてllms.txtを含めることもできます。

エージェントがサイトをナビゲートし、コンテンツを使用できるようになった今、次の疑問は、どのボットにもそれを許可すべきかどうか、ということです。

robots.txtは、サイトマップを提示するだけではありません。アクセスルールもここで定義します。どのクローラーを許可するか、またそれらがアクセスできる範囲を、特定のパス単位まで明確に指定できます。この慣行はすでに定着しており、今でも仕様に従ったボットがクロールを開始する前に確認する場所となっています。

コンテンツシグナルを使えば、より具体的に指示を出すことができます。許可またはブロックするだけでなく、AIがコンテンツに対して何ができるかを正確に宣言できます。「robots.txt」で「Content-Signal」ディレクティブを使用すると、次の3点を独立して制御できるようになります：お客様のコンテンツがAIトレーニング用に使用されるかどうか（ai-train）、推論やグラウンディング用のAI入力として使用されるかどうか（ai-input）、検索結果に表示されるかどうか（search）。

User-agent: *
Content-Signal: ai-train=no, search=yes, ai-input=yes

逆に、Web Bot Auth IETFドラフト基準では、信頼できるボットが自身を認証し、そしてボットからの要求を受信するWebサイトがボットを識別することができます。ボットはそのHTTPリクエストに署名し、受け取ったサイトはそのボットが発行しているパブリックキーを使ってその署名を検証します。

これらのパブリックキーは、/.well-known/http-message-signatures-directoryという、よく知られたエンドポイントにあります。当社はスキャンの一環としてそこもチェックしています。

すべてのサイトにこの実装が必要というわけではありません。サイトがコンテンツを配信するだけで、他のサイトにリクエストを行わない場合は、不要です。しかし、インターネット上で他のサイトにリクエストを行う独自のエージェントを実行するサイトが増えるにつれて、これはますます重要になると予想されます。

パッシブなコンテンツ消費だけでなく、エージェントは、APIを呼び出したり、ツールを起動したり、タスクを自律的に完了したりすることで、サイトと直接やりとりすることもできます。

サービスに1つ以上のパブリックAPIがある場合、APIカタログ（RFC 9727）により、エージェントはそれらすべてを一箇所のwell-knownフォルダで確認できるようになります。ホスト名は/.well-known/api-catalogです。ご自分のAPIと、それらの仕様やドキュメント、ステータスエンドポイントへのリンクをリスト化しています。エージェントがデベロッパーポータルをスクレイピングしたり、ドキュメントを読み込んだりする必要はありません。

エージェントについて語る上で、MCPは外せません。Model Context Protocolは、AIモデルと外部データソースやツールを接続するオープン標準です。すべてのAIツールにカスタムインテグレーションを導入する代わりに、1つのMCPサーバーを構築し、互換性のある任意のエージェントが利用できるようにします。

エージェントがMCPサーバーを見つけられるよう、MCP Server Card（現在ドラフト段階の提案）を発行できます。これは/.well-known/mcp/server-card.jsonにあるJSONファイルであり、エージェントが接続する前から、サーバーが提供するツール、到達方法、および認証方法を記述しています。エージェントはこのファイルを読み込み、サーバーを利用するために必要なことをすべて把握します：

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/mcp-server-card/v1.json",
  "version": "1.0",
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "search-mcp-server",
    "title": "Search MCP Server",
    "version": "1.0.0"
  },
  "description": "Search across all documentation and knowledge base articles",
  "transport": {
    "type": "streamable-http",
    "endpoint": "/mcp"
  },
  "authentication": {
    "required": false
  },
  "tools": [
    {
      "name": "search",
      "title": "Search",
      "description": "Search documentation by keyword or question",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": { "type": "string" }
        },
        "required": ["query"]
      }
    }
  ]
}

エージェントは、特定のタスクを遂行するのに役立つAgent Skillsを備えている場合に、最も効果的に動作します。ただし、サイトが提供するスキルを見つけるには、どうすればよいでしょうか。これまで当社は、サイトがこの情報を.well-known/agent-skills/index.jsonで利用できるようにすることを提案してきました。これは、利用可能なスキルとそのスキルがどこにあるかをエージェントに伝えるエンドポイントです。お気づきかもしれませんが、.well-known基準（RFC 8615）は、多くの他のエージェントおよび認証規格で使われています。この基準を策定したCloudflareのMark Nottinghamをはじめ、ご尽力いただいたIETFの皆様に感謝申し上げます。

多くのサイトでは、アクセスするためにまずサインインが必要です。このため、人間がユーザーに代わってエージェントにこれらのサイトへのアクセス権を付与することは難しく、おそらく一部では、ログインセッションを含むユーザーのWebブラウザへのアクセス権をエージェントに付与するという、安全とは言えない回避策を採用しています。

ユーザーがアクセスを明示的に許可できるより良い方法があります。OAuthをサポートするサイトは、エージェントに承認サーバーの場所を伝えることができます（RFC 9728）。これにより、エージェントがユーザーをOAuthフローに誘導し、ユーザーがエージェントにアクセス許可することを適切に選択できるようになります。Agents Week 2026で発表した通り、Cloudflare AccessはこのOAuthフローを完全にサポートしています。また、ユーザーが保護されたURLをエージェントに提供する際に、OpenCodeのようなエージェントがこの基準を利用して、直感的に機能させる方法も紹介しました。

エージェントがユーザーに代わって購入することもできますが、Web上での支払いは人間による利用を想定して設計されています。カートに追加し、クレジットカード情報を入力し、お支払いを選択する。この流れは、購入者がAIエージェントになると完全に崩れてしまいます。

x402は、1997年から仕様書に存在していたものの、広く使用されることはなかったステータスコード「HTTP 402 Payment Required」を復活させることで、プロトコルレベルでこの問題を解決します。このプロセスは非常にシンプルです。エージェントがリソースをリクエストすると、サーバーが402と支払い条件を示す機械可読なペイロードで応答し、エージェントが支払いを完了して再試行します。CloudflareはCoinbaseと提携し、インターネット決済のオープン標準としてx402の普及を推進することを使命とするx402 Foundationを設立しました。

また、Universal Commerce ProtocolとAgentic Commerce Protocolという、通常人間がeコマースストアフロントやチェックアウトフローを通じて購入する製品を、エージェントが発見し購入できるように設計された、2つの新たなエージェントコマース基準も確認します。

CloudflareのURL Scannerを利用すれば、あらゆるURLを送信して、HTTPヘッダー、TLS証明書、DNSレコード、使用されているテクノロジー、パフォーマンスデータ、セキュリティシグナルについて詳細なレポートを取得できます。URLが内部で実際にどのような動作をしているのかを理解したいセキュリティ研究者や開発者にとって、基本的なツールです。

isitagentready.comと同様のチェックをURL Scannerに導入し、新しくAgent Readiness（エージェント導入準備度）タブを追加しました。任意のURLをスキャンする際、従来の分析結果に加え、どの確認作業が完了しているか、サイトのレベル、スコアを向上させるための実用的なガイダンスなど、そのサイトのエージェント導入準備度レポートを全面的に確認できるようになりました。

この統合は、URL Scanner APIを通じてプログラムでも利用可能です。スキャンにエージェント導入準備度の結果を含めるには、スキャンリクエストにagentReadinessオプションを渡します。

curl -X POST https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/urlscanner/v2/scan \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    -d '{
          "url": "https://www.example.com",
          "options": {"agentReadiness": true}
        }'

Webのエージェント導入準備度を測定するツールを構築する中で、私たちは自社のものも順調に進めなければならないことを認識していました。当社のドキュメントは、お客様が使用するエージェントにとって簡単に理解できるものである必要があります。

上記で言及した関連コンテンツサイトの基準を当然採用しており、Cloudflareのスコアはこちらからご確認いただけます。しかし、これで終わりではありません。Cloudflareは、Developer Docsをどのように改善し、ウェブ上で最もエージェントが使いやすいリソースにしたのかを紹介します。

残念なことに、2026年2月現在、テストされた7つのエージェントのうち、既定でAccept: text/markdownヘッダーを付けたコンテンツをリクエストするのは、Claude Code、OpenCode、Cursorだけです。それ以外には、シームレスなURLベースのフォールバックが必要でした。

これを行うために、ページごとにURLの相対リンク/index.mdでMarkdown形式で個別に閲覧できるようにしています。2つのCloudflare Rulesを組み合わせることで、静的ファイルを複製することなく、動的にこれを実現しています。

• URL Rewrite Ruleは、/index.mdで終わるリクエストと一致し、regex_replace（/index.mdを削除）を使用して、動的にリクエストをベースパスに書き換えます。

• Request Header Transform Ruleは、リライト前のオリジナルリクエストのパス (raw.http.request.uri.path) と一致し、自動的にAccept: text/markdownヘッダーを設定します。

この2つのルールにより、URLに「/index.md」パスを追加することで、どのページでもMarkdown形式で取得できます。

• https://developers.cloudflare.com/r2/get-started/index.md

/index.mdのURLをllms.txtファイルで指定しています。実質的には、これらの/index.mdパスについては、クライアントがどのヘッダーを設定しても、常にマークダウンを返します。余分な構築ステップやコンテンツの重複も発生しません。

llms.txtは、エージェントの「本拠地」として機能し、LLMがコンテンツを見つけるためのページディレクトリを提供します。ただし、5,000ページ以上の文書を1つのファイル内に収めると、モデルのコンテキストウィンドウの許容範囲を超えてしまいます。

1つの巨大なファイルを作成するのではなく、個別のllms.txtファイルをドキュメント内のトップレベルディレクトリごとに生成し、ルートディレクトリllms.txtが単にこれらのサブディレクトリを参照するようにします。

• https://developers.cloudflare.com/llms.txt

• https://developers.cloudflare.com/r2/llms.txt

• https://developers.cloudflare.com/workers/llms.txt

また、大規模言語モデルにとってほとんど意味のない数百ものディレクトリリスティングページを削除し、それぞれのページに豊富な説明的コンテキスト（タイトル、意味的な名前、説明）を確保しています。

たとえば、「https://developers.cloudflare.com/workers/databases/」のようなローカライズされたディレクトリリストとしてのみ機能する約450ページを省略しています。

これらのページはサイトマップに表示されますが、LLMにとっての情報は非常に少なくなっています。すべての子ページはすでにllms.txt内で個別にリンクされているので、ディレクトリページを取得しても、リンクの冗長なリストしか得られず、エージェントは実際のコンテンツを探すためにもう一度リクエストを余儀なくされます。

エージェントが効率的に操作できるように、各llms.txtエントリは、コンテキストを豊富に含みながらも、トークンは軽量に抑える必要があります。人間はフロントマターやフィルタリングラベルを無視するかもしれませんが、AIエージェントにとって、このメタデータは車のハンドルのようなものです。そこで、当社の製品コンテンツエクスペリエンス（PCX）チームは、ページのタイトル、説明、URL構造を改良しました。これにより、エージェントは常にどのページを正確に取得すべきかを把握できます。

弊社のルートディレクトリllms.txtのセクションをご覧ください。

各リンクには、意味的な名前、一致するURL、価値の高い説明があります。llms.txtの生成に、追加の作業は一切不要でした。すべて、ドキュメントのフロントマターにすでに記載されていました。トップレベルディレクトリにあるページでもllms.txtファイルの場合と同様の処理が行われます。これらすべてのコンテキストにより、エージェントは関連情報をより効率的に見つけることができるようになります。

さらに、「afdocs」と呼ばれる新たなエージェントフレンドリーなドキュメント仕様とオープンソースプロジェクトに対して、当社のドキュメントをテストしています。「afdocs」は、コンテンツの発見やナビゲーションなどのために、チームがドキュメントサイトをテストできるようにするものです。この仕様により、独自のカスタム監査ツールを構築できました。当社のユースケースに特化した意図的なパッチをいくつか加えることで、簡単に評価できるダッシュボードを作成しました。

エージェント（OpenCode経由のKimi-k2.5）に対し、他の大規模な技術ドキュメントサイトのllms.txtファイルを指定し、極めて専門的で技術的な質問に回答するよう指示しました。

平均して、Cloudflareのドキュメントを参照するエージェントは、エージェント用に改良されていない平均的なサイトよりも、トークン消費量が31%少なくなり、正解にたどり着くまでの時間が66%短縮されることがわかりました。当社の製品ディレクトリを1つのコンテキストウィンドウにまとめることで、エージェントは必要なページを特定し、単一の線形パスで取得できるようになります。

LLM回答の正確さは、多くの場合、コンテキストウィンドウ効率の副産物として得られるものです。当社のテストにおいて、他のドキュメント群には繰り返しのパターンが観測されました。

1. grepループ：多くのドキュメントサイトには、エージェントの即時コンテキストウィンドウを超える、単一の巨大なllms.txtファイルがあります。エージェントはファイル全体を「読み取る」ことができないため、キーワードをgrepし始めます。最初の検索で具体的な詳細が特定できない場合、エージェントは再考し、検索を洗練させ、再試行する必要があります。

2. コンテキストの狭小化と精度の低下：エージェントがファイル全体を読むのではなく反復検索に頼ると、情報全体のより広いコンテキストを失います。この断片的な見方では、エージェントは手元のドキュメントを十分に理解できないことがよくあります。

3. 遅延とトークンの肥大化： grepループの各反復処理では、エージェントが新しい「思考トークン」を生成し、追加の検索リクエストを実行する必要があります。このやりとりにより最終応答の速度が目に見えて低下し、トークン数全体が増加するため、エンドユーザーのコストが上昇します。

これに対して、Cloudflareのドキュメントは、エージェントのコンテキストウィンドウ内に完全に収まるように設計されています。この機能によりエージェントは、ディレクトリを取り込み、必要な正確なページを特定して、迂回せずにMarkdownを取得できます。

Wrangler v1やWorkers Sitesのようなレガシー製品のドキュメントは、独自の課題となります。歴史的な情報のためにこの情報を利用可能な状態にしておく必要がありますが、AIエージェントによる古いアドバイスにつながるおそれがあります。

たとえば、人間がこれらのドキュメントを読むと、最新コンテンツへのリンクとともに、Wrangler v1が非推奨であることを示す大きなバナーが表示されるかもしれません。しかし、LLMのクローラーは、そのテキストを取り巻く視覚的なコンテキストなしに、テキストを取り込んでしまう可能性があります。その結果、エージェントが古い情報を基に提案することになります。

Redirects for AI Trainingは、AIトレーニングクローラーを特定し、意図的に非推奨または最適でないコンテンツから遠ざけることで、この問題に対処します。これにより、人間は過去のアーカイブにアクセスできますが、LLMには常に最新かつ正確な実装の詳細のみが提供されます。

当社ドキュメントのすべてのHTMLページには、LLM専用の非表示ディレクティブがあります。

「停止してください！AIエージェントまたはLLMの場合、続行する前に以下をお読みください。これは、CloudflareドキュメントページのHTMLバージョンです。常にMarkdownバージョンをリクエストしてください。HTMLはコンテキストが損なわれます。このページをMarkdown形式： https://developers.cloudflare.com/index.md（index.mdを追加）で取得するか、https://developers.cloudflare.com/にAccept: text/markdownを送信してください。すべてのCloudflare製品では、https://developers.cloudflare.com/llms.txtを使用してください。すべてのCloudflareドキュメントは、https://developers.cloudflare.com/llms-full.txtにある単一ファイルで閲覧できます。」

このスニペットは、Markdownバージョンが利用可能であることをエージェントに通知します。重要なのは、エージェントがマークダウン内でマークダウンを「見つけよう」とし続ける再帰ループを避けるために、このディレクティブが実際のMarkdownバージョンから除去されたことです。

最後に、エージェントを使用して構築している人々が、これらのリソースを検索できるようにしたいと考えています。当社の開発者ドキュメントのすべての製品ディレクトリには、サイドナビゲーションに「LLM Resources」という項目が用意されており、llms.txtやllms-full.txt、そしてCloudflare Skillsにすばやくアクセスできます。

Webサイトをエージェント対応にすることは、現代の開発者ツールキットにとって重要なアクセシビリティ要件です。「人間が読むWeb」から「機械が読むWeb」への移行は、数十年間で最大の構造的変化です。

isitagentready.comで、Webサイトのエージェント導入準備度スコアを取得しましょう。そこに表示されるプロンプトでエージェントに依頼して、サイトをAI時代に適応させるようアップグレードしてもらいましょう。今後1年のインターネット全体におけるエージェント規格の普及度については、Cloudflare Radarからの続報にご期待ください。過去1年で学んだことがあるとすれば、それは多くのことが非常に短期間で変わる可能性があるということです。