AIエージェント対応度とは？無料診断で自社サイトを実測し、レベル1から2へ上げた記録

AIエージェント対応度とは、AIアシスタントやAIエージェントがそのサイトを正しく発見・理解・利用できる状態にあるかを、機械可読な仕様への準拠で採点した指標です。 Cloudflareが公開している無料診断(isitagentready.com)では、5つの次元・21項目を自動で検査し、サイトを5段階のレベルで格付けします。LLM側から見て「読める・使える」かを測るもので、検索順位を測るSEOの指標とは別物です。この記事は、当サイトを実際に診断してレベル1と判定された状態から、2つの実装でレベル2へ上げるまでの実測データをもとに、項目の意味・優先順位・企業サイトが無視してよい項目までを整理します。

診断の受け方

URLを入力するだけです。ログインも登録も不要で、CloudflareのURL Scannerにも同じ診断のタブがあります。定点観測したい場合はAPIが使えます。

curl -s -X POST https://isitagentready.com/api/scan \
  -H "content-type: application/json" \
  -d '{"url":"https://example.com"}'

返ってくるJSONには合否だけでなく、どのリクエストを送ってどう応答したかという根拠(evidence)が項目ごとに入っています。「なぜ不合格なのか」を推測せずに済むため、画面よりAPIのほうが実務では便利です。不合格の項目には、修正内容をそのままコーディングエージェントに渡せる短いプロンプトも添えられます。

5次元21項目の全体像と実測結果

次元は発見可能性(Discoverability)・コンテンツ(Content Accessibility)・ボット制御(Bot Access Control)・機能提供(Discovery)・コマース(Commerce)の5つです。当サイト(Cloudflare無料プラン・静的サイト・APIなし・ログインなし)の実測結果を、次元ごとに略記して並べます。2026年8月15日時点、対応前の状態です。

判定は レベル1「Basic Web Presence」。21項目のうち合格は4項目でした。なお不合格の多くは「やっていない」ではなく「該当しない」ものです。この診断は全項目の合格を目指す性質のものではありません。

llms.txtに単独の検査項目がない点は、AEO対策を進めてきたサイトほど戸惑うところです。これは仕様どおりで、Cloudflareは既定ではllms.txtを検査せずMarkdownのコンテンツネゴシエーションだけを見ると明記しています(スキャンをカスタマイズすれば追加できます)。llms.txtを置いている場合は、Linkヘッダーで rel="describedby" として所在を示しておくと発見可能性の項目に効きます。

なお、画面版では0〜100のスコアとレベルが併記されますが、APIのJSONにスコアの数値は入っていません(返るのはレベルと項目ごとの合否・根拠です)。定点観測を自動化するなら、点数ではなくレベルと合否項目を記録することになります。

レベルの意味と上げ方

診断はレベルで格付けし、次のレベルに必要な項目を名指しで返します。はしごは5段階です。各レベルのゲートは公開されていないため、当サイトに加えて上位レベルのサイト3件をスキャンし、合否の組み合わせと突き合わせました。

レベル1〜3のゲートは、当サイトのスキャン結果から確定できました。レベル2の要件として返ってきたのはContent Signalsだけ、それを実装した後にレベル3の要件として返ってきたのはMarkdown配信だけです。

一方、レベル4・5のゲートは公開されておらず、実測しても単一の条件には還元できませんでした。 当サイトを含む4サイトを測った結果です。

Stripeのドキュメントは機能提供の項目でAgent Skillsだけが合格の状態でレベル4です。ところが最上位のvercel.comはそのAgent Skillsが不合格のままレベル5で、代わりにAPIカタログとOAuth検出が合格しています。つまり上位レベルへの道は1本ではなく、「この項目を満たせばレベル4」と言える単一のゲートは、この4件のデータからは特定できません。

もう1つ注意点があります。要件の欄には未達の項目しか返りません。すでに合格している項目は出てこないため、返ってきた一覧をそのレベルの全条件と読むことはできません(レベル4だった2サイトに返ってきたレベル5の要件は、docs.stripe.comがauth.md・MCPサーバーカード・A2A・APIカタログの4件、developers.cloudflare.comがauth.md・A2Aの2件と、既存の合格状況によって中身が違います)。

実務上の結論はシンプルです。レベル3までは条件が明快なので狙って上げられる。レベル4以降は、APIや認証を提供しているかどうかという事業の形の問題であり、情報サイトが小手先で到達する対象ではありません。

レベル1からレベル2への条件はContent Signalsの1項目だけでした。「AIボットを個別に許可・拒否しているか」と「AIに使われ方の希望を宣言しているか」は別項目として採点されるという設計です。前者はアクセスの可否、後者は利用目的の意思表示なので、両方が要ります。

レベル4以降で問われるのは、この記事の後半で「見送り」と仕分ける項目群です。APIもログインも持たない情報サイトにとっては、現実的な上限がレベル3ということになります。上限に達していることと、対応が不足していることは違います。

実際にレベル2へ上げた2つの実装

やったのは2つです。所要時間は実装と検証を含めて半日でした。レベル2のゲートになったのは①だけで、②は同じタイミングで入れたものです(②はレベル4以降に効きます)。

① robots.txtにContent Signalsを1行足す。 User-agent: * のブロックに、AI利用の希望を宣言する行を追加しました。当サイトは引用と露出を優先する方針なので3カテゴリすべて yes です。

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

判断の考え方(どのサイトがどれを no にすべきか、複合クローラーの罠、2026年9月15日のCloudflareの既定変更)はAIクローラーは許可か拒否かにまとめています。

② WebMCPでエージェント向けツールを2本公開する。 サイト内検索とツール一覧を、AIエージェントが直接呼び出せる形で登録しました。実装はJavaScriptだけで、サーバーは不要です。手順とコードはWebMCPの実装方法で解説しています。

再診断の結果です。

WebMCPの合格記録には、登録したツール名・タイトル・説明文・入力スキーマの有無まで外部から読み取られた内容がそのまま入っていました。エージェント向けに書く説明文は、社内メモではなく公開文書として書く必要がある、という実務上の含意があります。

どの項目に手を付け、どれを無視するか

不合格が並ぶと全部やりたくなりますが、大半の企業サイトには該当しない項目が含まれます。当サイトでの仕分けです。

診断結果を経営やクライアントに報告するときは、「不合格n件」ではなく「該当する項目のうちn件が未対応」と読み替えて伝えるのが誠実です。APIもログインも持たないコーポレートサイトが半分以上の項目で不合格になるのは、設計上あたりまえだからです。

実測して分かった落とし穴

独自のrel値は認識されない。 当サイトは以前、Linkヘッダーでllms.txtの所在を示すために独自の rel="llms-txt" を使っていました。診断は「agent-useful な relation type がない」として不合格を返します。スキャナーが照合するのは仕様で定義された「エージェントに有用な」rel値(describedby・sitemap など)だけで、rel="describedby" に変更したところ合格になりました。仕様上正しい値を使うこと自体が採点対象という、地味ですが重要な性質です。

Link: <https://example.com/llms.txt>; rel="describedby"; type="text/markdown",
      <https://example.com/sitemap-index.xml>; rel="sitemap"

WebMCPの検査はトップページ1枚しか見ない。 診断全体はrobots.txtや /.well-known/ 配下、DNSまで取りにいきますが、WebMCPだけはトップページを読み込んで登録済みツールを数える方式です。個別ページにだけ実装しても検出されません。

CDNが配信内容を書き換えていることがある。 当サイトでは、CloudflareのAI関連設定を触った時期に管理robots.txtが有効になり、リポジトリのファイルを変更していないのに本番のrobots.txtへAIクローラー拒否のブロックが注入されていたことがあります。診断はあくまで配信されている実物を見るため、リポジトリの内容と食い違っていれば当然結果も食い違います。ダッシュボード操作の後は curl で実物を確認してください。

ベータ機能の反映は遅れる。 CloudflareのダッシュボードでWebMCPを有効化した際、HTMLへのスクリプト挿入は確認できたのに、診断のWebMCP項目は数日たっても不合格のままでした。診断の表示だけで「動いていない」と判断せず、実物のHTMLで確かめるのが確実です。

よくある失敗

• 全項目の合格を目標にする: APIもログインもないサイトには構造的に該当しない項目が半分近くある
• 独自仕様で書く: rel値もシグナル名も、登録済み・仕様準拠のものしか認識されない
• リポジトリの内容だけ見て判断する: CDNが書き換えることがある。実物を curl で確認する
• 一度測って終わりにする: 検査項目そのものが増えていく領域。四半期ごとに測り直して差分を見る
• 診断のスコアを検索順位の指標と混同する: 別物。SEOの点検は別途セルフSEO評価チェッカーなどで行い、AI検索側の打ち手はLLMOの文脈で考える

まとめ

• AIエージェント対応度は、発見可能性・コンテンツ・ボット制御・機能提供・コマースの5次元21項目で採点される。isitagentready.comで無料・登録不要、APIでも取得できる(APIにスコアの数値は入らない)
• レベルは5段階(Basic Web Presence / Bot-Aware / Agent-Readable / Agent-Integrated / Agent-Native)
• 当サイトの初回判定はレベル1。Content Signalsの1行でレベル2「Bot-Aware」に到達した(WebMCPのツール2本は同時に実装したがレベル2の条件ではない)
• レベル3の条件は Accept: text/markdown でのMarkdown配信。ここから実装コストが上がる
• レベル4・5のゲートは非公開で、実測しても単一条件には還元できなかった(Agent Skills不合格のままレベル5のサイトがある)。APIや認証を提供しているかどうかの領域で、情報サイトが到達しないのは不足ではない
• rel値・シグナル名は仕様準拠のものだけが認識される。独自命名は不合格になる

AI検索に引用されるための土台はAEO(回答エンジン最適化)とは、AIに読ませるサイト概要ファイルはllms.txt、プロトコルとしての位置づけはMCPで解説しています。