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

claudejamodel: claude-haiku-4-5

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

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

ウェブは常に新しい標準に適応してきました。ウェブブラウザと通信する方法を学び、その後検索エンジンと通信する方法を学びました。今、AIエージェントと通信する必要があります。

本日、私たちは isitagentready.com の立ち上げを発表できることを嬉しく思います。これはサイト所有者がサイトをエージェント向けに最適化する方法を理解するのに役立つ新しいツールです。エージェントに認証方法を指示することから、エージェントが見ることができるコンテンツ、受け取る形式、およびそれに対して支払う方法を制御することまで、すべてをカバーしています。

また、Cloudflare Radarに新しいデータセットを導入し、インターネット全体での各エージェント標準の採用状況を追跡します。

私たちは率先して行動したいと考えています。そのため、Cloudflareの開発者ドキュメントを最近大幅に改装し、最もエージェント対応のドキュメントサイトにした方法も共有しています。これにより、AIツールがより速く、大幅に安い価格で質問に答えることができます。

ウェブは現在どの程度エージェント対応ですか？

短い答え：あまり対応していません。これは予想されることですが、標準が採用されれば、エージェントが今日よりもはるかに効果的になる可能性があることを示しています。

これを分析するために、Cloudflare Radarはインターネット上で最も訪問されている200,000のドメインを取得し、エージェント対応性が重要でないカテゴリ（リダイレクト、広告サーバー、トンネリングサービスなど）を除外して、AIエージェントが現実的に相互作用する必要があるビジネス、パブリッシャー、プラットフォームに焦点を当て、新しいツールを使用してスキャンしました。

結果は、Cloudflare Radar AI Insightsページに見られる新しい「AI エージェント標準の採用」チャートです。ここで複数のドメインカテゴリ全体での各標準の採用を測定できます。

個別のチェックを見ると、いくつかのことが目立ちました：

robots.txt はほぼ普遍的 — 78% のサイトが持っています — しかし、大多数は従来の検索エンジンクローラー向けに書かれており、AIエージェント向けではありません。
Content Signals : 4% のサイトが robots.txt で AI 使用設定を宣言しています。これは勢いを増している新しい標準です。
Markdown コンテンツネゴシエーション (Accept: text/markdown で text/markdown を提供) は 3.9% のサイトで機能します。
MCP Server Cards と API Catalogs (RFC 9727) などの新しい新興標準は、データセット全体で 15 未満のサイトに表示されます。

まだ初期段階です — 新しい標準を採用し、エージェントとうまく機能する最初のサイトの1つになることで目立つ大きな機会があります。

このチャートは毎週更新され、データは Data Explorer または Radar API を通じてアクセスすることもできます。

あなたのサイトのエージェント対応スコアを取得する

isitagentready.com にアクセスしてサイトのURLを入力することで、自分のウェブサイトのエージェント対応スコアを取得できます。

スコアと実行可能なフィードバックを提供する監査は、以前に新しい標準の採用を促進するのに役立っています。例えば、Google Lighthouse はウェブサイトのパフォーマンスとセキュリティのベストプラクティスをスコアリングし、サイト所有者に最新のウェブプラットフォーム標準を採用するよう指導します。エージェント向けのベストプラクティスを採用するのに役立つ同様のものが存在すべきだと考えています。

サイトを入力すると、Cloudflare はそれへのリクエストを行ってどの標準をサポートしているかをチェックし、4つの側面に基づいてスコアを提供します：

発見可能性 (Discoverability)

robots.txt
sitemap.xml
Link Headers (RFC 8288)

コンテンツ (Content)

Markdown for Agents

ボットアクセス制御 (Bot Access Control)

Content Signals
robots.txt の AI ボットルール
Web Bot Auth

機能 (Capabilities)

Agent Skills
API Catalog (RFC 9727)
RFC 8414 および RFC 9728 経由の OAuth サーバー検出
MCP Server Card
WebMCP

さらに、サイトが x402、Universal Commerce Protocol、Agentic Commerce Protocol などのエージェント型コマース標準をサポートしているかどうかをチェックしますが、これらは現在スコアにはカウントされません。

失敗した各チェックについて、コーディングエージェントに与えて、その代わりにサポートを実装させることができるプロンプトを提供します。

サイト自体もエージェント対応であり、その言葉を実践しています。Streamable HTTP 経由で scan_site ツールを備えたステートレス MCP サーバー (https://isitagentready.com/.well-known/mcp.json) を公開しているため、MCP 互換のエージェントはウェブインターフェイスを使用せずにプログラムでウェブサイトをスキャンできます。また、Agent Skills インデックス (https://isitagentready.com/.well-known/agent-skills/index.json) を公開しており、チェックするすべての標準のスキルドキュメントが含まれているため、エージェントは何を修正するかだけでなく、どのように修正するかも知っています。

各カテゴリのチェックを詳しく見てみましょう

発見可能性 (Discoverability)

robots.txt は 1994 年から存在し、ほとんどのサイトが持っています。エージェントにとって 2 つの目的があります：クロールルール (誰が何にアクセスできるか) を定義し、サイトマップを指します。

サイトマップは、ウェブサイト上のすべてのパスをリストする 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)

エージェントをサイトに乗せることは1つのことです。実際にコンテンツを読むことができることを確認することは別のことです。

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 コンテンツネゴシエーションはさらに進みます。エージェントがページを取得して Accept: text/markdown ヘッダーを送信すると、サーバーは HTML の代わりにクリーンな markdown バージョンで応答します。markdown バージョンには必要なトークンがはるかに少なくなります — 場合によっては最大 80% のトークン削減を測定しました — これにより、応答がより速く、より安く、ほとんどのエージェントツールがデフォルトで持つコンテキストウィンドウの制限を考えると、その全体が消費される可能性が高くなります。

デフォルトでは、サイトが Markdown コンテンツネゴシエーションを正しく処理しているかどうかのみをチェックし、llms.txt はチェックしません。必要に応じてスキャンをカスタマイズして llms.txt を含めることができます。

ボットアクセス制御 (Bot Access Control)

エージェントがサイトをナビゲートしてコンテンツを消費できるようになったので、次の質問は：任意のボットにそれを許可したいですか？

robots.txt はサイトマップを指すだけではありません。アクセスルールを定義する場所でもあります。どのクローラーが許可されているか、特定のパスまでアクセスできるかを明示的に宣言できます。この慣例はよく確立されており、依然として、クローリングを開始する前に、行儀の良いボットが最初に見る場所です。

Content Signals はより具体的にすることができます。許可または拒否するだけでなく、AI が正確に何ができるかを宣言できます。robots.txt で Content-Signal ディレクティブを使用して、3つのことを独立して制御できます：コンテンツを AI トレーニング (ai-train) に使用できるかどうか、AI 推論とグラウンディング (ai-input) の AI 入力として使用できるかどうか、および検索結果に表示されるべきかどうか (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 を呼び出し、ツールを呼び出し、タスクを自律的に完了することで、サイトと直接相互作用することもできます。

サービスに 1 つ以上のパブリック API がある場合、API Catalog (RFC 9727) はエージェントがすべてを発見するための単一のウェルノウンロケーションを提供します。/.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 貢献者に感謝します！

OAuth と認可 (OAuth and Authorization)

多くのサイトでは、アクセスする前にサインインする必要があります。これにより、人間がエージェントにこれらのサイトへのアクセスを代わりに与えることが難しくなり、一部の人々は、ログインしたセッションでユーザーのウェブブラウザへのアクセスをエージェントに与えるという、議論の余地のある安全でない回避策を採用しています。

人間が明示的にアクセスを許可できるより良い方法があります：OAuth をサポートするサイトは、エージェントに認可サーバーを見つける場所を伝えることができます (RFC 9728)。これにより、エージェントは人間を OAuth フローを通じて送信でき、そこで人間はエージェントへのアクセスを適切に許可することを選択できます。

Agents Week 2026 で発表された Cloudflare Access は現在このOAuth フローを完全にサポートしており、OpenCode のようなエージェントがこの標準を利用して、ユーザーがエージェントに保護された URL を与えるときに物事をうまく機能させる方法を示しました。

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

要約

Summary

Key Points

翻訳

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

ウェブは現在どの程度エージェント対応ですか？

あなたのサイトのエージェント対応スコアを取得する

発見可能性 (Discoverability)

コンテンツ (Content)

ボットアクセス制御 (Bot Access Control)

機能 (Capabilities)

各カテゴリのチェックを詳しく見てみましょう

発見可能性 (Discoverability)

コンテンツアクセシビリティ (Content Accessibility)

ボットアクセス制御 (Bot Access Control)

プロトコル検出 (Protocol Discovery)

OAuth と認可 (OAuth and Authorization)