DocsDigest
Back to listLanguage: JA
OpenAICloudflareApr 17, 2026, 1:05 PM

Introducing the Agent Readiness score. Is your site agent-ready?

A condensed section focused on the key takeaways first.

Original Post
OpenAIClaude

Quick Digest

Summary

A condensed section focused on the key takeaways first.

openaienmodel: gpt-5-mini-2025-08-07

Agent Readiness score: Is your site agent-ready?

agent-readinessrobots.txtmarkdownmcpapi-catalogcontent-signalsoauth

Key Points

  • isitagentready.com site scanner and MCP endpoint
  • Scores across discoverability, content, access control, capabilities
  • Adoption is low — implement a few well-known endpoints to stand out

Summary

Cloudflare launched isitagentready.com and a weekly Cloudflare Radar dataset to score how well sites support AI agents. The tool runs automated checks and gives a single agent-readiness score across four dimensions (Discoverability, Content, Bot Access Control, Capabilities), plus actionable remediation prompts you can hand to a coding agent. Adoption of new agent standards is currently low, so implementing a few well-defined endpoints can make a site immediately more useful to agents.

Key Points

  • What it does: scan a site and score it on Discoverability, Content, Bot Access Control, and Capabilities; results include failing checks and implementation prompts.
  • Core checks: robots.txt, sitemap.xml, Link headers, Markdown content negotiation (Accept: text/markdown), Content Signals, AI bot rules, Web Bot Auth discovery, API Catalog (RFC 9727), MCP Server Card, Agent Skills index, OAuth server discovery (RFC 8414/9728).
  • Current adoption: robots.txt ~78% but agent-specific directives are rare (Content Signals ~4%; markdown negotiation ~3.9%); MCP and API Catalog are almost nonexistent in the top 200k domains.
  • Tooling: isitagentready.com exposes a stateless MCP server and an Agent Skills index for programmatic scans; Cloudflare Radar publishes adoption charts and a Data Explorer/API for the dataset.
  • Commerce standards: agentic commerce protocols are checked but do not yet affect the score.

Actionable checklist for engineers

  • Publish or update robots.txt: include sitemaps and Content-Signal directives (ai-train, ai-input, search).
  • Add sitemap.xml and use Link response headers (RFC 8288) to point agents to well-known resources.
  • Support Markdown content negotiation (Accept: text/markdown) to reduce token costs.
  • Implement discovery endpoints: /.well-known/api-catalog, /.well-known/mcp/server-card.json, and /.well-known/agent-skills/index.json.
  • Enable Web Bot Auth (/.well-known/http-message-signatures-directory) if your services interact with agent-run bots.
  • Support OAuth server discovery (RFC 9728/8414) for safe agent-mediated access to protected resources.
  • Use the isitagentready scan and follow provided prompts to automate fixes via coding agents.

Where to start

  • Scan your site at https://isitagentready.com and review the audit and remediation prompts.
  • Track ecosystem adoption via Cloudflare Radar’s AI Insights and Data Explorer (weekly updates).

Full Translation

Translations

A translation section that keeps the flow of the original article.

openaijamodel: gpt-5-mini-2025-08-07

エージェント準備度スコアの紹介。あなたのサイトはエージェント対応ですか？

2026-04-17 — André Jesus Vance Morrison — 読了約13分

ウェブは常に新しい標準に適応してきました。最初はブラウザ向け、次に検索エンジン向けに振る舞いを学びました。これからは、AIエージェントと「会話」できるようになる必要があります。

本日、isitagentready.comを公開します — サイト所有者がエージェント向けにサイトを最適化する方法を理解するための新しいツールです。認証方法の案内、エージェントが閲覧できるコンテンツの制御、コンテンツの受け取り形式、支払い方法に至るまで、幅広くチェックします。また、Cloudflare Radar向けの新しいデータセットも導入し、インターネット全体で各エージェント標準の採用状況を追跡します。

私たちはまず自分たちで模範を示したいと考え、CloudflareのDeveloper Documentationをエージェントに最も親和性の高いドキュメントサイトに作り替えました。これにより、AIツールが質問に対してより速く、そして大幅に安価に答えられるようになっています。

現時点でウェブはどれだけ“エージェント対応”か？

短い回答：あまり対応できていません。これは予想どおりですが、標準が採用されればエージェントは現在よりずっと有効に機能する余地が大きいことを示しています。

Cloudflare Radarは、インターネットで最も訪問された20万ドメインを対象に、エージェント準備度が重要でないカテゴリ（リダイレクト、広告サーバ、トンネリングサービス等）を除外し、ビジネス、出版社、プラットフォームなどAIエージェントが現実的にやり取りするであろうサイトに焦点を絞って新ツールでスキャンしました。

その結果、Cloudflare RadarのAI Insightsページに「Adoption of AI agent standards」チャートが追加され、複数のドメインカテゴリにわたって各標準の採用状況を測定できるようになりました。

個々のチェックを見ると、いくつか注目すべき点があります：

  • robots.txtはほぼ普及しており、78%のサイトが持っていますが、その大部分は従来の検索エンジンクローラ向けに書かれており、AIエージェント向けではありません。
  • Content Signals：サイトの4%がrobots.txtでAI利用に関する優先度を宣言しています。これは勢いを増している新しい標準です。
  • Markdown content negotiation（Accept: text/markdownでtext/markdownを返す）が通るサイトは3.9%です。
  • MCP Server CardsやAPI Catalogs（RFC 9727）のような新興標準は、データセット全体でも15サイト未満にしか現れていません。

まだ初期段階です — 早期に新標準を採用することで目立つ大きな機会があります。このチャートは週次で更新され、データはData ExplorerやRadar APIからも取得できます。

サイトのエージェント準備度スコアを取得するには

isitagentready.comにアクセスしてサイトのURLを入力すると、自分のサイトのエージェント準備度スコアを取得できます。スコアと、採用を促すための実行可能なフィードバック付き監査は、新しい標準の普及を後押ししてきました。たとえば、Google Lighthouseはパフォーマンスやセキュリティのベストプラクティスをスコアリングし、サイト所有者が最新のWebプラットフォーム標準を採用するよう導きます。エージェント向けにも同様の存在があるべきだと私たちは考えています。

サイトを入力すると、Cloudflareはそのサイトに対してどの標準をサポートしているかを確認するリクエストを行い、次の4つの次元に基づいてスコアを算出します：

  • Discoverability: robots.txt、sitemap.xml、Link Headers (RFC 8288)
  • Content: Markdown for Agents
  • Bot Access Control: Content Signals、AI bot rules in robots.txt、Web Bot Auth
  • Capabilities: Agent Skills、API Catalog (RFC 9727)、OAuth server discovery via RFC 8414 and RFC 9728、MCP Server Card、WebMCP

注：サイトがエージェント商取引標準（x402、Universal Commerce Protocol、Agentic Commerce Protocol）をサポートしているかも確認しますが、これらは現在スコアには含まれていません。

各チェックで失敗した場合、そのチェックを実装するためにあなたのコーディングエージェントに渡せるプロンプトを提供します。

また、isitagentready.com自身も“自分の教えを実践”しています。ステートレスなMCPサーバをhttps://isitagentready.com/.well-known/mcp.jsonで公開し、Streamable HTTP経由のscan_siteツールを提供しているため、MCP互換の任意のエージェントがウェブインターフェースを使わずにプログラム的にサイトをスキャンできます。さらに、サイトは各チェック対象のスキルドキュメントを含むAgent Skillsインデックスをhttps://isitagentready.com/.well-known/agent-skills/index.jsonで公開しており、エージェントは「何を直すべきか」に加えて「どう直すか」も知ることができます。

以下では、各カテゴリのチェック内容と、なぜそれがエージェントにとって重要かを掘り下げます。

Discoverability

robots.txtは1994年からあり、ほとんどのサイトが持っています。エージェントにとって二つの目的があります：クロールルール（誰が何にアクセスできるか）を定義すること、そしてサイトマップへのリンクを示すことです。サイトマップはXMLファイルで、サイト上の全パスを列挙する地図のようなもので、エージェントがすべてのコンテンツをリンクを逐一クロールせずに発見できます。robots.txtがまず最初に見られる場所です。

サイトマップ以外にも、エージェントはHTTPレスポンスヘッダから直接重要なリソースを発見できます。具体的にはLinkレスポンスヘッダ（RFC 8288）を使います。HTML内部に埋め込まれたリンクとは異なり、LinkヘッダはHTTPレスポンス自体に含まれるため、エージェントはマークアップを解析せずにリソースへのリンクを見つけられます。例：

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

コンテンツのアクセス性（Content accessibility）

エージェントをあなたのサイトに来させることと、そのエージェントが実際にコンテンツを読めるようにすることは別の問題です。

2024年9月、llms.txtが提案されました。これはモデルのコンテキストウィンドウに収まるような、LLM向けに構造化されたサイトの読み取りリストを提供する方法です。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 content negotiationです。エージェントが任意のページを取得する際にAccept: text/markdownヘッダを送ると、サーバはHTMLの代わりにクリーンなMarkdownバージョンを返します。Markdownはトークン数が大幅に少なくなるため（場合によっては最大で約80%のトークン削減を計測）、応答が速く、安価になり、ほとんどのエージェントツールがデフォルトで持つコンテキストウィンドウの制限の下でも完全に消費されやすくなります。

デフォルトでは、私たちはサイトがMarkdown content negotiationを正しく処理するかのみをチェックし、llms.txtはオプションでスキャンに含めることができます。

Bot Access Control

エージェントがあなたのサイトをナビゲートしてコンテンツを取得できるようになったとして、次の疑問は「誰に許可するか」です。

robots.txtは単にサイトマップを指すだけでなく、アクセスルールを定義する場所でもあります。どのクローラが許可され、どのパスにアクセスできるかを明示できます。これはよく確立された慣習であり、エチカルなボットはクロールを始める前にまずここを参照します。

Content Signalsを使えば、単なる許可/ブロック以上のことが宣言できます。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ドラフト標準はフレンドリなボットが自身を認証できるようにし、サイト側はボットの公開鍵を使ってその署名を検証できるようにします。ボットはHTTPリクエストに署名し、受信側サイトは/.well-known/http-message-signatures-directoryに公開された公開鍵を使って署名を検証します。すべてのサイトがこれを実装する必要はありませんが、他サイトへリクエストを出すエージェントを自社で運用するサイトが増えるにつれて重要度は高まるでしょう。

Protocol Discovery（プロトコル発見）

受動的なコンテンツ消費に加え、エージェントはAPI呼び出しやツールの起動、タスクの自律的完了を通じてサイトと直接やり取りできます。あなたのサービスに公開APIがある場合、API Catalog（RFC 9727）はエージェントがそれらを発見するための単一のwell-knownロケーションを提供します。/.well-known/api-catalogにホストされ、APIの一覧やその仕様、ドキュメント、ステータスエンドポイントへのリンクを提供します。これによりエージェントは開発者ポータルをスクレイピングしたりドキュメントを読み込んだりする必要がなくなります。

MCP（Model Context Protocol）について語らないわけにはいきません。MCPはAIモデルが外部データソースやツールと接続するためのオープン標準です。エージェントごとにカスタム統合を作る代わりに、1つのMCPサーバを構築すれば、互換性のある任意のエージェントがそれを利用できます。

MCPサーバをエージェントが見つけやすくするために、MCP Server Card（現在ドラフト中）を/.well-known/mcp/server-card.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貢献者に感謝します。

多くのサイトはまずサインインを要求するため、人間がエージェントに代わってサイトにアクセス権を与えるのが難しく、結果としてユーザーのログイン済みブラウザセッションをエージェントに渡すという安全でない回避策が取られてきました。より良い方法として、OAuthに対応したサイトはエージェントに認可サーバの場所を示すことができ（RFC 9728）、エージェントはユーザーを正しいOAuthフローに送り、ユーザーが明示的にエージェントへアクセス権を付与できます。Agents Week 2026で発表されたように、Cloudflare AccessはこのOAuthフローを完全にサポートしており、OpenCodeのようなエージェントがユーザー提供の保護されたURLを扱う際にこの標準を利用してスムーズに動作させる実例を示しました。

まとめ

現状、エージェント向けの標準採用はまだ初期段階ですが、早期に取り組むことで競争上の優位になり得ます。isitagentready.comは、サイト所有者が自分のサイトの現在地を理解し、実行可能な改善案を得て、エージェント時代に適合するための手助けをするために作られました。Cloudflare Radarと併せて、採用状況のモニタリングとベストプラクティスの普及を進めていきます。