エージェントの準備: サイトをエージェント Web 用に準備する方法

AI エージェントはページを読むことをやめました。ユーザーに代わって、フライトの予約、部品の注文、チェックアウトの実行、API へのサインインを行います。適切なシグナルを公開するサイトが利用されます。スキップされないサイト。新しいエージェント プロトコル準備状況チェッカーは、URL をスキャンして、エージェントが現在探している正確な信号を探します。

  • AIエージェント
  • MCP
  • エージェントコマース
  • テクニカル SEO
によって PageChecks 読了目安 3 分

エージェントの準備自体が今問題になっている理由

長年にわたり、デザインしなければならない訪問者は、ブラウザを使用する人間だけでした。その後、Google の crawler が現れ、SEO が規律になりました。その後、LLM crawlers が到着し、次に心配しなければならないのは Answer Engine Optimization になりました。

さて、第三の種類の訪問者がここに来ました。 OpenAI、Anthropic、および Google モデルに基づいて構築されたエージェントは、意図を持ってサイトを閲覧します。製品ページを読み、フォームに記入し、価格を交渉し、API を呼び出します。また、最初の 1 ～ 2 秒で、あなたのサイトが往復する価値があるかどうかも判断します。

エージェントは、crawlers のように動作するのではなく、せっかちなパワー ユーザーのように動作します。彼らはあなたの HTML に触れる前に /.well-known/ パスをチェックします。彼らは、ナビゲーションをスキップするために Accept: text/markdown を送信します。彼らは、ドキュメントではなくツールとしてアプリと通信できるように、MCP サーバー カードを探します。これらのシグナルが見つからない場合、エージェントは HTML スクレイピングに戻るか (遅くて損失が多い)、その言語を話す競合他社に移ります。

これは、測定するために Agent Protocol Readiness Checker を構築したものです。これは SEO 監査ではありません。それはプロトコル監査です。サイトが人間によって読まれるのではなく、エージェントによって使用される準備ができているかどうかを確認します。

エージェント プロトコル準備状況チェッカーの機能

ツールに URL を与えます。オリジンに対して 20 以上のプローブを実行し、結果を 5 つのスコア付けされたカテゴリにグループ化します。

  • 発見可能性 エージェントは robots.txt、sitemap、およびリンク ヘッダーを見つけることができますか?
  • コンテンツ アクセシビリティ あなたのサーバーは、acceptmarkdown.com 仕様に記載されている方法で Accept: text/markdown を尊重していますか?
  • ボット アクセス制御 GPTBot、ClaudeBot、Google-Extended、および PerplexityBot の明示的なポリシーを作成しましたか? Web Bot Auth キー ディレクトリを公開しましたか?
  • プロトコル ディスカバリ。 MCP サーバー カード、エージェント スキル マニフェスト、RFC 9727 API カタログ、OAuth ディスカバリ メタデータ、および WebMCP ツール アノテーションを公開しますか?
  • エージェントコマース エージェントはあなたに支払いをすることができますか?チェッカーは、x402、ACP、UCP、および MPP 信号を探します。

各チェックは、判定の背後にあるサーバー証拠とともに、合格、警告、または失敗を返します。失敗は優先順位付きの推奨リストにまとめられ、カテゴリは A から F までの重み付けされたグレードに結合されます。目標は別の虚栄心スコアではありません。目標は、エージェントによるサイトの扱い方を大きく変える 6 つの修正を提供することです。

各カテゴリが実際に何を測定するのか、そしてそれがなぜ重要なのかを見ていきましょう。

1. 発見可能性: すべてを決定する基本

エージェントがより高度なものを使用する前に、オリジンに何が存在するかを知る必要があります。それは 3 つのプレーン ファイルから始まります。

robots.txt

チェッカーは /robots.txt をフェッチし、有効な応答が返されたことを確認します。 RFC 9309 は 2022 年から正式な標準となっており、ロボット ファイルを読み取れないエージェントは、マシン アクセスについてまったく考えていないという最悪の事態を想定します。この投稿から 1 つのことだけを実行する場合は、有効な robots.txt を公開してください。私たちの Robots.txt Validator は、よくある間違い (迷走 BOM、ワイルドカード トラップ、引用符で囲まれていない Sitemap ディレクティブ) を検出します。

Sitemap宣言

/sitemap.xmlのsitemapはいいですね。エージェントが最初にロボット ファイルを解決するため、それを指す robots.txt 内の Sitemap: 行の方が優れています。チェッカーは両方を実行するサイトに報酬を与えます。

リンク応答ヘッダー

最新のエージェントは、ホームページの Link ヘッダーも読み、/.well-known/* のリソースに関するヒントを確認します。たとえば、Link: </.well-known/mcp/server-card.json>; rel="mcp-server-card" にサービスを提供するサイトは、2 回目の往復を行わずにエージェントに次のステップを提供します。オリジンが今日送信するヘッダーを確認したい場合は、HTTP Header Checker を通じて実行してください。

発見可能性は小さなカテゴリー (最終成績の 15%) ですが、ここでの失敗は連鎖します。ロボットが壊れている場合、ボット アクセス カテゴリを検証できません。 Link ヘッダーが欠落している場合、下流のカテゴリは推測する必要があります。

2. コンテンツのアクセシビリティ: マークダウン ネゴシエーション チェックこれは、ほとんどのサイトが失敗するカテゴリです。また、修正するのが最も簡単です。

acceptmarkdown.com の提案は単純です。クライアントが Accept: text/markdown を送信すると、サーバーは HTML ではなく Markdown として同じコンテンツを返す必要があります。 HTML はノイズが多いため、エージェントはこれを気に入っています。ページからクロム、ナビゲーション、JavaScript を削除すると、トークンが消費され、エラーが発生します。記事の Markdown 表現はサイズが半分になり、解析が 10 倍簡単になります。

チェッカーは、URL に対して 4 つのプローブを実行します。

  1. Accept: text/markdown が受け入れられます。 サーバーは Content-Type: text/markdown; charset=utf-8 を返す必要があります。エージェントはエンコーディングを想定したトークナイザーに本文をフィードするため、UTF-8 宣言は重要です。
  2. Vary: Accept が設定されています。 このヘッダーがないと、HTML 応答をキャッシュした CDN は、マークダウンを要求する次のエージェントにその HTML を提供します。 1 つのヘッダーが欠落していると、同じ CDN の背後にあるすべての AI クライアントのオリジン全体が破損します。
  3. サポートされていない Accept タイプは 406 を返します。 エージェントが Accept: application/x-weird-type を送信した場合、正しい答えは 406 Not Acceptable であり、サイレント HTML フォールバックではありません。 406 を返すと、エージェントの再試行ロジックに、間違ったものを要求したことが通知されます。
  4. q 値が尊重されます。 Accept: text/html;q=0.1, text/markdown;q=1.0 を送信するエージェントは、「必要に応じて HTML も使用しますが、Markdown の方が断然好きです。」と言っています。サーバーはその重み付けを尊重する必要があります。

ほとんどのオリジンは、このカテゴリで 4 つ中 0 を獲得します。オンデマンドで HTML を Markdown に変換する CDN ワーカーは、午後に 4 つすべてを修正します。その見返りはさらに複雑になります。その時点以降、サイトにアクセスするすべてのエージェントは、コンテンツのクリーンなトークン化された表現を取得します。エージェントが AI 対応コンテンツをどのように読み取るかについて詳しくは、AI Readiness Checker をご覧ください。

3. ボットのアクセス制御: 明確に「はい」と言うデフォルトの robots.txt は AI エージェントについては何も示しません。沈黙はエージェントに応じて 2 通りに解釈されます。沈黙は「大丈夫、続けてください」という意味だと考える人もいます。沈黙は「このサイトはオプトインしていない」ことを意味すると考える人もいます。どちらの解釈もあなたが実際に望むものと一致しないため、あなたは傷つきます。

Agent Protocol Readiness Checker は 3 つの明示的なシグナルを探します。

robots.txt の AI ボット ユーザー エージェント

チェッカーは、今日重要な crawl をターゲットとするルールを robots.txt で検索します: GPTBot、ChatGPT-User、OAI-SearchBot、ClaudeBot、Claude-Web、anthropic-ai、Google-Extended、PerplexityBot、 Perplexity-ユーザー、メタ外部エージェント、Applebot-Extended、Bytespider、CCBot、cohere-ai、DuckAssistBot、Amazonbot、MistralAI-ユーザー。 3 人以上の指名されたエージェントがパスを獲得します。リストが短い場合は警告が表示されます。ゼロは失敗となります。その時点では AI ポリシーがまったくないからです。

User-agent: GPTBot の後に Allow: / を書くことは、何も言わないことと同じではありません。特定の企業の代理人が特定のルールに基づいてサイトを閲覧できるという公約です。エージェントのポリシー エンジンがあなたを呼び出すかどうかを決定するとき、そのコミットメントには負荷がかかります。

特定の AI ボットがパスの 1 つに対して現在どのように動作しているかを調べたい場合、AI Bot Path Tester はライブ robots.txt のルールに対してリクエストをシミュレートします。

Cloudflare コンテンツシグナル

Cloudflareは、2025年後半にContent Signalsを提案しました。 robots.txt内にある3つのディレクティブ（search、ai-input、ai-train）で、crawling、応答の取得、トレーニングの個別のポリシーを宣言します。チェッカーはロボット ファイルをスキャンして、Content-Signal: ディレクティブがないか調べます。 1つあれば合格できます。

コンテンツ 「ブロック GPTBot」は鈍器であるため、信号が重要です。トレーニング、検索、根拠のある答えを一度に得ることができなくなります。コンテンツ シグナルを使用すると、トレーニングをブロックしながら (コンテンツがモデルの重みに圧縮されないように)、根拠のある回答 (ChatGPT の引用にブランドが表示されるように) を許可できます。

Web ボット認証

Web Bot Auth は、このカテゴリの最新作です。エージェントは、Ed25519 キーペアを使用してリクエストに署名します。公開キーは、/.well-known/http-message-signature-directory で JWKS として検出できます。エージェントがサーバーに到達すると、公開されたキーと照合して署名を検証し、どのエージェントがリクエストを送信したかを確実に知ることができます。

チェッカーはそのディレクトリを調査し、JSON が返されることを確認します。公開していない場合、正規のエージェントとそのユーザー エージェントを身に着けているスクレイパーを区別することはできません。セキュリティケースだけでも魅力的です。実際のケースはさらに大きくなります。Web Bot Auth をサポートするエージェントはレート制限が低くなり、より多くのサイトにアクセスできるようになります。公開されたキーはすぐに返金されます。

4. プロトコルディスカバリー: よく知られたエンドポイントこれはツールの核心であり、最も重要視されるカテゴリ (最終スコアの 25%) です。これは毎月変更されるエージェント スタックの一部でもあるため、チェッカーはベンダー固有のトリックではなく、適切に指定されたエンドポイントに依存します。

MCP サーバー カード

Model Context Protocol は、クロード、ChatGPT、および増え続けるエージェントのリストがリモート サーバー上の呼び出し可能なツールを検出する方法です。 /.well-known/mcp/server-card.json の MCP サーバー カードは、サーバーの名前、機能、トランスポート、および認証モデルをアドバタイズします。チェッカーはそのパスを調査し、パスが見つからない場合は /.well-known/mcp.json にフォールバックします。

製品に何らかの API がある場合、MCP サーバー カードはサイトをドキュメントからツールに変えるものです。サーバー カードを見つけたエージェントはスクレイピングを停止し、呼び出しを開始します。それはユーザーにとってより良いエクスペリエンスであり、あなたにとってはより安価なインタラクションです。

エージェントのスキル

Agent Skills は、/.well-known/agent-skills/index.json にある新しいマニフェスト形式です。これは、「出荷の作成」、「返金の申請」、「予約の検索」などのツールだけでなく、エージェントが使用できるワークフローを説明することで MCP を補完します。チェッカーはそのパスを調査し、有効な応答を探します。

サイトがすでに OpenAPI 仕様または MCP サーバー カードを公開している場合、エージェント スキル マニフェストの生成はほとんどが翻訳作業になります。 ROI は、Claude Code と同様のクライアントがあなたのスキルを名前でユーザーに明らかにすることです。

WebMCP

WebMCP は、MCP のブラウザ側のいとこです。 /.well-known/ URL を通じてツールを宣伝する代わりに、HTML 内の <form> 要素に toolname および tooldescription 属性で直接注釈を付けるか、<meta name="webmcp" ...> タグを介してツールを宣言します。チェッカーはホームページの HTML をスキャンして、どちらかのパターンを探します。

利点は、ブラウザでページを使用しているエージェントが、タブを離れることなくこれらのツールを検出して呼び出すことができることです。 WebMCP は、エージェントの流暢性を高めるための少量のマークアップです。

API カタログ (RFC 9727)

RFC 9727 は、オリジンが公開するすべての API へのポインターとして /.well-known/api-catalog を定義し、application/linkset+json として機能します。チェッカーは、エンドポイントが存在すること、およびそのコンテンツ タイプが正しいことを確認します。多くのオリジンはここで警告を受けます。パスは提供されますが、application/linkset+json ではなく application/json が使用されます。コンテンツ タイプの修正は、1 つのルート上の 1 つのヘッダーです。

OAuth ディスカバリー

ここでは 2 つの仕様が重要です。

  • RFC 8414 では、/.well-known/oauth-authorization-server で OAuth Authorization Server メタデータについて説明しています。これにより、発行者に対して OAuth フローを開始する方法がエージェントに指示されます。
  • RFC 9728 は、/.well-known/oauth-protected-resource の OAuth 保護リソース メタデータについて説明します。これにより、エージェントが API から 401 を受信したときに、どの発行者に対して認証するか、どのスコープをリクエストするかをエージェントに伝えます。

OAuth 検出を実行できないエージェントは、人間の介入なしにサイトでのサインイン操作を自動化できません。製品にユーザー アカウントがある場合は、両方を公開します。

5. エージェントコマース: エージェントは支払いを行うことができますか?これは最新のカテゴリであり、懐疑論者から最も反発を受けているカテゴリです。その根底にある質問は単純明快です。エージェントがユーザーに代わってあなたから何かを購入したいとき、その取引はどのようなものになるでしょうか?

チェッカーは 4 つの競合する答えを測定します。

x402

x402 は、HTTP ステータス コード 402 (「支払いが必要」) を復活させ、機械読み取り可能なオファー (価格、通貨、承認された支払いレール、決済エンドポイント) を含む PAYMENT-REQUIRED ヘッダーを追加します。 402 を受け取ったエージェントは支払いに署名し、リクエストを再送信してリソースを取得します。チェッカーは、ホームページおよびプローブするエンドポイントで 402 ステータスまたは PAYMENT-REQUIRED ヘッダーを探します。

x402 はコミットメントが最も低いオプションです。有料エンドポイントを 1 つ選択し、条件付きで 402 を返すだけで完了です。現在、Stripe、Coinbase、およびいくつかの暗号決済プロバイダーがこのフローをサポートしています。

ACP (エージェントコマースプロトコル)

ACP は OpenAI の標準です。これは /.well-known/agentic-commerce にあり、製品カタログ、価格設定、税金、配送、返品など、より充実したチェックアウト画面について説明しています。物理的な商品やデジタル商品を販売していて、ChatGPT がストアと直接取引したい場合は、ACP が最適です。

UCP (ユニバーサルコマースプロトコル)

UCP は OAuth に便乗します。 OAuth Authorization Server メタデータ内で ucp:scopes:checkout_session のようなコマース スコープを宣言します。チェッカーは OAuth AS ドキュメントをフェッチし、ucp:scopes:* 値を検索します。 1 試合でパスが得られます。

UCP は、既存の OAuth レイヤーを再利用するため、4 つのコマース プロトコルの中で最も軽量です。何らかの目的でトークンを発送すれば、半分達成できたことになります。

MPP (マシンペイメントプロトコル)

/.well-known/machine-payments で宣伝されている MPP が最も一般的です。それはチェックアウトのフローというよりも、サービスが受け入れるマシン間の支払いの種類 (ステーブルコイン、口座間の銀行レール、トークンごとの計量など) を宣伝することに重点が置かれています。

商業の合格点には 4 つすべてが必要というわけではありません。 「エージェントが支払いを行うことができる」は 4 つの標準がそれを所有するために競合する 1 つの機能であるため、少なくとも 1 つは必要です。あなたのビジネスに合ったものを選んで出荷してください。

最終スコアが実際に意味するもの

このツールは、5 つのカテゴリ スコアを結合して、重み付けされた全体のグレードを作成します。

カテゴリー重量
見つけやすさ15%
コンテンツのアクセシビリティ20%
ボットアクセス制御15%
プロトコルディスカバリー25%
エージェントコマース25%

85 を超えるスコアは A となります。70 ～ 84 の間は B となります。低い成績は急速に低下しますが、これは意図的なものです。 D 範囲のスコアを持つサイトは、エージェントにとって不完全であるだけではありません。それは機能的には見えません。ツールを宣伝したり、Markdown を提供したり、ボット ポリシーを宣言したり、エージェントによる支払いをサポートしたりしません。すでにエージェント主導のトラフィックの一部については、そのサイトはパーク ドメインとして認識されます。

私たちが監査したほとんどのサイトは、最初の実行時に 10 ～ 30 のスコアを獲得しました。それでいいのです。このツールは、現在の状況に応じて、最も影響力の高い 6 つの変更を明らかにするように設計されています。そのうち 3 つを修正すると、通常 1 日以内にサイトが F から C に移動します。

チェックの実行方法

Agent Protocol Readiness Checker に移動し、URL を貼り付けて、約 10 秒待ちます。結果ページには次の内容が含まれます。

  • あなたの総合スコアとレターグレード。
  • チェックごとに色分けされたステータスを持つ 5 つのカテゴリのスコア。
  • 各チェックの背後にある生の証拠 (ヘッダー、ステータス コード、一致した部分文字列)。これにより、ツールの読み取りを独自のログと照合して検証できます。
  • 上位の修正の優先順位付けされた推奨リスト。

ステージング ドメイン、内部起点、および運用環境に対してチェックを実行できます。これは、送信 URL 安全ルールを尊重し、本文の読み取りを 512 KB に制限するため、設定が間違っているサーバーによってレート制限が消費されることはありません。

問題を解決するための実際的な命令高速にリフトしたい場合は、次の手順を順番に実行してください。

  1. GPTBot、ClaudeBot、Google-Extended、および PerplexityBot の明示的な User-agent: ルールと、Sitemap: ディレクティブを含む有効な robots.txt を公開します。 Robots.txt Validator で検証してください。
  2. CDN エッジで Markdown コンテンツ ネゴシエーションを追加します。 Accept ヘッダーを確認し、その場で HTML を Markdown に変換し、Content-Type: text/markdown; charset=utf-8 と Vary: Accept を設定します。サポートされていないタイプの場合は 406 を返します。
  3. エージェントに最も引用してもらいたいページへのポインタを含む llms.txt をルートで公開します。 LLMs.txt Generator and Validator を使用して生成し、検証します。
  4. /.well-known/mcp/server-card.json で MCP サーバー カードを公開します。最小限のカード (名前、説明、バージョン、トランスポート) だけでも、エージェント検出のロックが解除されます。
  5. コンテンツ信号を追加 robots.txt。 ai-input: yes, ai-train: no を宣言する 1 行でチェックに合格し、実際のポリシーを公開するのに十分です。
  6. Web Bot Auth JWKS を公開して、正規のエージェントがオリジンに対するリクエストに署名できるようにします。

このリストは、通常の CDN と通常の認証サーバーを備えたチームの場合、およそ 2 エンジニア日分の作業に相当します。サイトを F から B に移動し、来年のエージェント プロトコルの変動に対してオリジンを将来も保証します。

エージェントの 1 年間の準備状況はどのようになるか

このツールが現在実行するチェックの正確なリストは、12 か月後に実行されるリストではありません。 MCP は、正式な機能ネゴシエーション仕様を承認します。エージェント スキルは、OpenAPI の一部とマージまたは置き換えられます。 ACP、UCP、および MPP は、より少数の強力な標準に統合される予定です。プローブが着陸したら追加し、デフォルトになったらプローブを廃止します。

変わらないのは問題の形です。エージェントは最初の数回のリクエストで、サイトを使用する価値があるかどうかを判断します。あなたの仕事は、サイトで何ができるのか、どのように使用するのかを迅速かつ明確に公開することです。チェッカーが探すすべてのシグナルは、エージェントがオリジンをあきらめるのではなくコミットできるようにするショートカットです。

ホームページに対して Agent Protocol Readiness Checker を実行します。上位 3 つの推奨事項を修正します。もう一度実行してください。これら 3 つの変更が適用された後、エージェントがサイトをどのように扱うかに注目してください。

関連書籍