あなたのサイトはAIエージェントに対応していない(30秒でわかる確認方法)

AIエージェントはすでにあなたのサイトを訪れる現実の存在であり、多くのサイトはそれを無視している。isitagentready.comでドメインをスキャンし、その結果をコピペで使える改善プロンプトで実行可能なスペックに変換し、Superpowersのbrainstormingを使って何も壊さずに実装する方法を解説する。

目を持たない訪問者
「agent readiness」とは何か、SEOとの違い
isitagentready.comがチェックする項目
最初のスキャンの手順
レポートからスペックへ、コピペで使えるプロンプト
- プロンプト1 ― 監査と診断
- プロンプト2 ― 改善スペックを生成する
実行する前に、Superpowersのbrainstormingを使う
今日から実装できるクイックウィン
サイトをagent-readyにする際によくある失敗
よくある質問
まとめ
参考リンク

目を持たない訪問者

今日、あなたのビジネスに問い合わせが届くまでの流れを考えてみてほしい。もはや誰も検索エンジンに「ボゴタで一番良いデザイン会社」と打ち込んで10個のタブを開いたりはしない。代わりにこう頼む。「業者を3社探して、価格を比較して、一番良さそうなところに電話のアポを入れておいて」。

そのアシスタントは人間とはまったく違う振る舞いをする。

あなたのカルーセルもスクロールアニメーションも配色も見ていない。
可能な限り、JavaScriptのハイドレーションを待とうとしない。
消費するのは構造化されたテキストであり、それがクリーンであるほど都合が良い。
あなたのサイトで何ができるかを推測ではなく確実に知る必要がある。APIはあるか?予約用のエンドポイントはあるか?支払いはできるか?

もしあなたのサイトが、machine-readableな形であなたが何者で何を提供しているかを一切示さない、divだらけの重いHTMLしか返さないなら、エージェントが取る行動は単純だ。それを簡単にしてくれた競合の元へ行ってしまう。

これは未来の話ではない。Googleがモバイルファーストのサイトを優先し始めたときとまったく同じ転換だ。あのとき対応が遅れたサイトは何年も順位を落とし続けた。違うのは、今回は先手を打てる猶予がはるかに短いということだ。

「agent readiness」とは何か、SEOとの違い

**Agent readiness(エージェント対応度)**とは、自律的なエージェントがあなたのサイトを発見し、読み、その機能を理解し、実際に操作できる状態にどれだけ準備が整っているかを表す指標だ。

SEOの近い親戚のようなものだが、目指すものが違う。

	従来のSEO	Agent readiness
対象	検索エンジンのクローラー + 人間	自律エージェント(その背後のLLM)
目的	検索結果一覧に表示されること	エージェントに選ばれ、実行されること
鍵となる形式	セマンティックHTML、メタデータ、速度	クリーンなMarkdown、マニフェスト、プロトコル
成功の定義	ユーザーのクリック	摩擦なくタスクが完了すること
主なシグナル	被リンクとコンテンツ	発見可能性と明示された機能

GEO(Generative Engine Optimization)という言葉も目にするだろう。これはAIが生成する回答の中で引用されることを目指す考え方だ。Agent readinessはそのGEOを可能にするインフラ層にあたる。エージェントがあなたを正しく読めなければ、正しく引用されることもまずない。

そしてここに戦略上の核心がある。**賭かっているのはトラフィックではなく、意図(インテント)**だ。あなたのサイトに来るエージェントは、その背後にすでに購入・契約・予約という意思決定を抱えている。あなたが受け取る中で最も意図の強い訪問者でありながら、最も辛抱強くない訪問者でもある。

isitagentready.comがチェックする項目

Is Your Site Agent-Ready?は、Cloudflareが提供する無料ツールで、エージェント関連エコシステムで生まれつつある標準に照らしてあなたのドメインをスキャンする。URLを入力してScanを押すだけで、数秒後に何が揃っていて何が足りないかを示すスコアが返ってくる。

チェック項目は5つのカテゴリーに分かれている。

1. Discoverability(発見してもらえるか)

robots.txt、サイトマップ、HTTPレスポンスのLinkヘッダー、そしてDNS-AID(DNS for AI Discovery)。これは最も基本的な層であり、エージェントがそもそもあなたのリソースを発見できなければ、他のすべては意味を持たない。

2. Content Accessibility(読んでもらえるか)

中心となるのはMarkdown形式のコンテンツネゴシエーションだ。クライアントが適切なヘッダーを付けてリクエストしたとき、あなたのサーバーがページのプレーンテキスト/Markdown版を返せるかどうか。LLMにとって、HTMLではなくMarkdownを受け取れるかどうかは、本を直接読むか、装丁ごしに読むかほどの違いがある。

3. Bot Access Control(何を許可し、何を許可しないか)

robots.txtにおけるAIボット向けの個別ルール、Content Signals、そしてWeb Bot Auth。このカテゴリーは最も見過ごされがちであり、同時に最も痛手になりうる部分だ。あなたのコンテンツを学習に使わせるのか、検索に使わせるのか、リアルタイム推論に使わせるのか――それを決めるのはここだ。すべてブロックするのも、何も宣言しないのも、どちらも同じくらい得策ではない。

4. Protocol Discovery(エージェントのために何ができるか)

もっとも興味深いカテゴリー。MCP Server Card、Agent Skills、WebMCP、API Catalog、OAuthの発見、OAuth Protected Resource、Auth.md、A2A Agent Card、そしてARDマニフェスト。ここであなたのサイトは単なる文書であることをやめ、ツールへと変わる。

5. Commerce(取引ができるか)

x402、MPP、UCP、ACP――エージェント商取引のためのプロトコル群。何かを販売しているなら、このカテゴリーがエージェントが自力で購入を完了できるか、それとも人間に処理を戻すしかないかを決める。

正直な補足を一つ。これらの標準の多くはまだ若く、いくつかは生き残らないだろう。すべてを実装する必要はない。 このスキャンの価値は100点を取ることではなく、これまで無意識のうちに(何もしないことで)下していた判断の一覧を、初めてはっきりと手にできることにある。

最初のスキャンの手順

isitagentready.comにアクセスする。
https://を含む完全なドメインを貼り付ける。
細かく調整したい場合はCustomize scanを開き、該当しないカテゴリーのチェックを外す(オンラインで販売していないなら、最初の一回はCommerceを外してもよい)。
Scanを押して結果を待つ。
レポートの最後に、コード用エージェントに貼り付けるための指示ブロックが生成されており、Copy all instructionsボタンが付いている。

それをコピーしよう。ただしまだ実行してはいけない。

このブロックは出発点としては悪くないが、到達点としては最悪だ。AIが生成した汎用的な推奨事項であり、あなたのスタックにも実際のトラフィックにも、ビジネスの優先順位にも一切の文脈を持たない。そのままコード用エージェントに渡せば、中身の空っぽなllms.txtと、誰も参照しないマニフェストと、誰もメンテナンスしない3つの新規ファイルが出来上がって終わりだ。

ここからが、その生の出力を本当に効果のあるものへ変える工程になる。

レポートからスペックへ、コピペで使えるプロンプト

考え方はシンプルだ。まず分析、次にスペック、その次にコード。決して逆の順番にはしない。

プロンプト1 ― 監査と診断

これをClaude、ChatGPT、または使っているエージェントに貼り付ける。Web閲覧機能があるとより良い結果になる。

あなたはagent readinessとGEO(Generative Engine Optimization)の
シニアコンサルタントとして振る舞ってください。あなたの仕事は、人間の
視点ではなく、自律的なAIエージェントの視点からウェブサイトを監査
することです。

分析対象サイト: [ここにURLを貼る]
ビジネスの背景: [何を、誰に売っているか。サイト上で起きてほしい
最も価値の高いアクションは何か]
技術スタック: [例: Vercel上のNext.js、WordPress、Shopify、
Cloudflare上のAstro]
isitagentready.comのスキャン結果: [レポート全文をここに貼る]

以下を、この順番で実行してください。

1. 独立した検証
   以下のリソースに実際にアクセスを試み、本当に見つかったものを
   報告してください(存在する/存在しない/存在するが不備がある):
   - /robots.txt (AIボット向けの明示的なルールはあるか?あるなら
     どんな内容か)
   - /sitemap.xml
   - /llms.txt と /llms-full.txt
   - /.well-known/ (mcp、agent-card、oauth-authorization-server、
     ard)
   - トップページのHTTPヘッダー: Link、Content-Type、cache
   - Accept: text/markdown を指定した場合にMarkdownが返るか

2. エージェントとして読む
   トップページと最も重要な3ページを読んでください。忖度せず
   正直に答えてください。
   - 50語以内で、この会社は何をしているか説明できますか?
     曖昧さなく明確ですか?
   - 人間の介入なしに、エージェントが今日ここで実行できる
     具体的なアクションは何ですか?列挙してください。
   - 価格、在庫、対応エリア、連絡先、利用条件といった重要な情報の
     うち、JavaScript・画像・フォームの裏に隠れているものは
     何ですか?
   - あるユーザーがアシスタントに「Xの業者を見つけて、他の2社と
     比較して」と頼んだ場合、このサイトはその比較に勝てますか、
     負けますか?理由も含めて答えてください。

3. 優先順位付けした診断
   以下の列を持つ表を作成してください: 発見事項 | カテゴリー |
   インパクト(高/中/低) | 労力(高/中/低) | ビジネス上重要な理由。
   アルファベット順やカテゴリー順ではなく、インパクト/労力の比率
   順に並べてください。

4. やるべきではないこと
   このサイト固有の事情において、スキャン結果の推奨事項のうち
   意味を持たないものを明示的に挙げ、理由を説明してください。
   取捨選択してください。すべてを実装しようとするのは、問題を
   理解していない証拠です。

まだコードは書かないでください。まだ解決策も提案しないでください。
診断だけを行ってください。検証できなかったことがあれば、
推測せずにその旨を明示してください。

プロンプト2 ― 改善スペックを生成する

診断結果に納得できたら、同じ会話の中でこの2つ目のプロンプトを続けて投げる。

完璧です。それでは、これを実行可能な改善スペックに変換して
ください。

バラバラなタスクの一覧は求めていません。他の誰か――あるいは
コード用エージェント――が受け取り、私に何も聞き返すことなく
そのまま実行できる文書が欲しいのです。

正確な構成:

# Spec: Agent Readiness ― [サイト名]

## 1. 課題
agent-readyでないことで、このビジネスが今日失っているものは
何か。具体的に、誇張なしで。

## 2. 目標と成功指標
目標を一文で。そして検証可能な指標を3〜5個。各指標は、コマンド
一つ、HTTPリクエスト一つ、または再スキャンで確認できるもので
なければなりません。「可視性を高める」のようなものは指標では
ありません。

## 3. 範囲
### 対象に含めるもの
### 対象外にするもの(その理由も)

## 4. 実装フェーズ
インパクト/労力の比率で3つのフェーズに分けてください。
- フェーズ1 ― クイックウィン(1日未満)
- フェーズ2 ― 構造的な改善(1週間未満)
- フェーズ3 ― エージェント向け機能(フェーズ1・2の効果測定後に評価)

各タスクには以下を含めてください。
- IDとタイトル
- 作成・変更する正確なファイルまたはパス
- 提案する具体的な内容や変更(汎用的なプレースホルダーではなく
  実際の例を)
- 検証可能な受け入れ基準(curlコマンド、具体的なチェック、
  再スキャンなど)
- リスクとロールバック方法

## 5. 生成すべき具体的なコンテンツ
以下の実際のコンテンツをこの場で書いてください。
- このビジネスに合わせた /llms.txt
- robots.txtに追加するAIボット向けルール。明確な方針を含める
  こと(検索のために何を許可し、学習のために何を許可し、何を
  ブロックするか)
- どのAIに聞かれても繰り返してほしい、このブランドについての
  3文の要約

## 6. リスクと未決定事項
何が問題になりうるか、あなたではなく私が判断すべきビジネス上の
決定は何か。

## 7. 30日後の効果測定方法
何を再確認すべきか、何が見られると期待できるか。

ルール: チェックリストの網羅性ではなく、実際のビジネスインパクト
で優先順位をつけてください。具体的なメリットを説明できない
タスクは削除してください。あなたの推測にはすべて[前提]と
マークし、私が検証できるようにしてください。

この2つ目のプロンプトの成果物は、あなたのリポジトリでバージョン管理でき、チームと議論でき、コード用エージェントに信頼できる情報源として渡せる文書になる。本当の成果物はこれであって、ツールのスコアではない。

実行する前に、Superpowersのbrainstormingを使う

多くの人がつまずくのはここだ。せっかくの美しいスペックをエージェントに渡し、「やって」と言い、3時間後には新しいファイルが12個、誰も理解できないCloudflareの設定、そして何かが改善したのかどうかを確かめる方法が何もない、という状態に陥る。

解決策は、コードを書く前に意図的な摩擦のフェーズを挟むことだ。そのためにあるのが**Superpowers**――あなたのエージェントを予測不能なコード生成器ではなく、方法論的なエンジニアに変えるオープンソースのスキルフレームワークだ。

その最初のフェーズが、まさに必要としているものだ。

/brainstorm このagent readinessのスペックを自分のサイト[URL]に
実装したいです。スペック全文はこちらです: [プロンプト2のスペックを
貼る]

brainstormingが普通のプロンプトと違うのは何か。言われたことに従う前に、まず問い詰めてくるという点だ。前提を疑い、スペックと実際のスタックの間の矛盾を洗い出し、「完了」の基準を明確にさせ、一つのファイルにも触れる前に、絞り込んだ範囲を返してくれる。

そこからSuperpowersの残りのフローへとつなげていく。

/brainstorm ― 厄介な質問でスペックを磨き上げる。
Gitワークツリー ― 本番環境にリスクを与えない、隔離されたブランチで作業する。
/write-plan ― スペックを2〜5分で終わる検証可能なタスクに分割する。
/execute-plan ― レビュー機構を組み込んだサブエージェントに委任する。
検証 ― 何かを「完了」と宣言する前に、根拠を示す。

まだインストールしていなければ、1分もかからない。

/plugin install superpowers

インストールと使い方の完全ガイドは**Claude CoworkでSuperpowersスキルをインストールして使いこなす方法**にまとめてある。

一番時間を節約できたルール。スペックがbrainstormingを通過するまで、エージェントにコードを書かせない。 20分の質問攻めにかかるコストなど、間違った方向に進んだ実装を後から解体するコストに比べれば取るに足らない。

今日から実装できるクイックウィン

今週3つしかやらないとしたら、これにしてほしい。

見せかけではない、本物のllms.txt。 ドメインのルートに置くMarkdownファイルで、あなた自身が何者で、何を提供していて、主要なページへのリンクは何かを書く。重要なのはファイルが存在することではなく、モデルがそれを読んであなたのビジネスを正しく説明できることだ。試してみるといい。中身をAIに渡して、あなたの会社が何をしているか聞いてみよう。答えが気に入らなければ、そのファイルは書き方が間違っている。

robots.txtにAIボット向けの明示的なルールを書く。 沈黙は同意でも禁止でもなく、単なる曖昧さであり、その曖昧さをどう解釈するかはボットごとに勝手に決められてしまう。検索のために何を許可し、学習のために何を許可し、何をブロックするか、自分の立場をはっきり宣言しよう。

重要なコンテンツをJavaScriptの外に出す。 価格、在庫、対応エリア、利用条件、連絡先情報はクライアント側でレンダリングせず、サーバーから配信されるHTMLに含める。このリスト全体の中で労力対効果が最も良い改善であり、しかも従来のSEOにも効いてくる。

そこまでできて、効果測定を終えた後に初めて、より野心的な層――Markdownネゴシエーション、自社サービス向けのMCPサーバー、オンライン販売しているならエージェント商取引プロトコル――を検討しよう。

サイトをagent-readyにする際によくある失敗

スコアを追いかけてしまう。 ツールのスコアは診断であって、KPIではない。的確に選んだ40点のサイトは、無節操に実装した90点のサイトに勝る。

指示ブロックをそのままコピーして、盲目的に実行してしまう。 それはあなたのビジネスの文脈を持たないAI生成コンテンツだ。診断の材料として使うべきであって、作業計画として使ってはいけない。

怖くてAIボットを全部ブロックしてしまう。 その衝動は理解できるが、無差別なブロックは、顧客があなたを探しているまさにその生成AIの回答からあなたを締め出す結果になる。学習と検索・推論は分けて考えるべきで、同じ判断ではない。

誰もメンテナンスしないファイルを作ってしまう。 1年前の価格が載ったままのllms.txtは、何もないより悪い。AIに、あなたについて誤った情報を発信するための材料を与えているようなものだ。

自社のビジネスで使わないプロトコルを実装してしまう。 APIがないならAPI Catalogを公開する意味はない。オンライン販売をしていないなら、x402は何ももたらさない。

よくある質問

isitagentready.comは無料ですか?

はい。Cloudflareが提供する無料ツールで、登録も不要、公開されているどのドメインでもスキャンできます。最後に生成される推奨事項はAIによって生成されたものなので、実装する前に自分自身の判断を必ず加えてください。

これは従来のSEOに取って代わるものですか?

いいえ、補完するものです。agent readinessの改善の多く(サーバー配信のHTMLコンテンツ、クリーンなセマンティック構造、正しいサイトマップ)は、従来のSEOにも直接恩恵をもたらします。検索エンジンと人間向けの最適化は続けつつ、そこに第三の読者を加えるだけです。

WordPressやShopifyのサイトでも使えますか?

はい、ただし細かい制御はしにくくなります。クイックウィン――llms.txt、robots.txtのボットルール、HTML内の重要コンテンツ――はどのCMSでも十分実現可能です。MCPサーバーのようなプロトコル層は、より技術的な自由度か、それを解決してくれるプラグインが必要になります。

これを行うのにSuperpowersは必須ですか?

必須ではありません。スペックは手動でも、どんなエージェントを使っても実行できます。本当に必要なのはSuperpowersが自動化してくれる規律――コードを書く前に考える、小さなタスクに分割して計画する、根拠をもって検証する――です。Superpowersはそれを標準機能として無料で提供してくれます。それはまさに、急いでいるときほど人がやらないことです。

どのくらいの頻度で再スキャンすべきですか?

実装を進めている間は月1回、その後は四半期ごとが妥当です。エージェント関連の標準を取り巻くエコシステムは急速に動いています。今日はオプションでも、半年後には当たり前の要件になっているかもしれません。

まとめ

この20年間私たちが作ってきたウェブは、人間の目のために設計されていた。これから来るウェブは、目を持たず、待ってくれず、容赦もしないエージェントのためにも機能しなければならない。

良いニュースは、参入障壁が今も非常に低いということだ。ドメインのスキャンは30秒、本格的な診断は半日、クイックウィンはテキストファイル3つで済む。競争優位を生むのは技術的な難しさではなく、「これをやるべきだった」と誰の目にも明らかになる前に実行しておくことにある。

今週の具体的なおすすめアクションはこうだ。isitagentready.comであなたのサイトをスキャンし、プロンプト1で診断し、プロンプト2でスペックを生成し、一行もコードを書く前に/brainstormにかけてみてほしい。

あなたのサイトはスキャンで何点でしたか?creacosas.comのコメント欄で教えてください。

目を持たない人たちのためにも、これからも素晴らしいものを作っていきましょう!