AIエージェント対応とは？サイト側でやること・やらなくていいこと【2026】

AIエージェント対応とは、利用者に代わって調べて手続きまで進めるAIが自社サイトへ来たときに、入って・見つけて・読んで・申し込みまで進める状態にしておくことです。この言葉は「社内でエージェントを使う」話と混ざって流通していますが、この記事が扱うのはサイト側の話だけです。Googleは公式に、AI機能へ出るためにAI専用のファイルやマークアップを作る必要はないと書いています。やることは新しく作ることではなく、いまのサイトのどこで止まるかを確かめることです。

この記事でわかること

• 作るものはありません： Googleは「新しい機械可読ファイル、AI用テキストファイル、マークアップを作る必要はありません」と公式に明記しています。llms.txtも、有効なファイルを持つ約38,000ドメインの97%が2026年5月に一度も取得されていません（Ahrefs調査）。
• 見るのは4か所です： 入れるか（アクセス）・見つかるか（発見）・読めるか（可読）・渡せるか（操作）の4関門に分かれ、落ちる場所ごとに直す相手が変わります。
• 当社サイトも半分は通っていませんでした： 6種類のUA文字列で取得したところ全て200が返りましたが、同じトップページのフォームは、labelと入力欄の紐づけが33個中10個、autocomplete属性は1個だけでした（2026年9月5日実測）。

結論：新しく作るファイルは無い。見るのは4か所だけ

AIエージェント対応で新しく作るファイルはありません。いまのサイトが4つの関門のどこで止まるかを測るだけです。

「AIエージェント対応」で検索すると、MCP・llms.txt・ARD・Web Bot Authといった規格名が並びます。しかし中小企業のサイトで先にやることは、規格を1つ選ぶことではありません。順番はこうです。

この順番にしているのは、1と2が費用ゼロで終わるからです。当社が確認したサイトでも、関門1で止まっていた例があります。専用ファイルを作る話は、4つを通してからで間に合います。

「AIエージェント対応」は3つの意味に割れている

「AIエージェント対応」という言葉は、社内で使う話・サイトが使われる話・エージェントを止める話の3つに割れています。

検索結果が噛み合わないと感じる原因はここにあります。同じ言葉で呼ばれている3つを先に分けます。

意味1：社内でエージェントを使う（この記事の対象外）

「AIエージェント」で語られている話の大半は、社内で使う側です。サイト側の話ではありません。

日本語のX（旧Twitter）で2026年6月から9月のポストを調べたところ、話題の中心は開発支援エージェント、業務自動化、ツール比較でした。公開サイトをエージェント向けに作り変えるという話は、情報システム部門からはほとんど出ていません。出ているのは社内のAPIをつなぐという内側の話です（Grokによる調査、2026年9月5日）。

つまり、社内の担当者が「AIエージェント対応を進めています」と言うとき、多くの場合それはサイトの話ではありません。会議で噛み合わないときは、まずどちらの意味かを確認してください。

意味2：自社サイトがエージェントに使われる側になる（この記事の対象）

自社サイトへ来たAIが、情報を読んで申し込みまで進められるかどうか。この記事が扱うのはこれです。

たとえば利用者がAIに「この条件で見積もりを取って」と頼み、AIが複数のサイトを回って比較し、フォームを埋めるところまで進む使われ方です。このとき自社サイトが途中で止まれば、候補から外れる可能性があります。人が見れば分かるページでも、機械には読めないことがあります。

なお、この用法は世の中では少数派です。「エージェント対応」という言葉は、サイト改修ではなく「自社のソフトやAPIがエージェントから呼べるようになった」という意味で使われることのほうが多くなっています。

意味3：エージェントを止める・課金する（「対策」と呼ばれる側）

同じ言葉が、通す側と止める側で反対の意味になります。「AIエージェント対策」は多くの場合、止める側です。

コンテンツを大量に持つメディアが「学習に使われたくない」と考えるとき、対策とはブロックや課金のことです。一方、問い合わせを増やしたい会社にとっての対応とは、通すことです。目的が逆なので、同じ記事を読んでも噛み合いません。

この記事は通す側の立場で書きます。ただし止める側の判断も1点だけ決めておく必要があるため、後半で触れます。

先に消す｜AIエージェント対応でやらなくていいこと

AI専用のファイルもAI専用のマークアップも要りません。Googleが公式にそう書いています。

規格名が並ぶ記事を読むと「全部やらないといけないのか」と身構えますが、公式情報と実測を突き合わせると、いま優先度が低いものははっきりしています。

AI専用ファイル・AI専用マークアップは要らない（Google公式）

GoogleはAI機能に出る条件を「インデックスされ、スニペット表示が許可されていること」だけだと書いています。

Google検索セントラルの公式ドキュメントには「新しい機械可読ファイル、AI用テキストファイル、マークアップを作る必要はありません」「追加すべき特別なschema.org構造化データもありません」と書かれています。AI Overviewsにも AIモードにも、追加要件は無いという説明です。

これは「構造化データが無駄」という意味ではありません。既存の構造化データが表示内容と一致していることは引き続き求められます。新設が不要だという話です。

llms.txtは97%が読まれていない（他社の実測）

llms.txtを置いた約38,000ドメインの97%は、2026年5月に一度も読まれていません（Ahrefs調査）。

同じ調査によると、llms.txtを取りに来たボットの77%はAIツールではなく、最も多かったのはSEO監査ツールで21.7%でした。

日本語のXでも、llms.txtを置いて効果があったという自社実測の報告は見つかりませんでした（Grokによる調査、2026年9月5日）。当社としては、置くこと自体を止める理由はないものの、優先順位は関門1から4のあとだと考えています。詳しくはllms.txtの書き方と、意味があるのかの判断で扱っています。

「エージェントフレンドリー」は専用対応ではなく、土台が読めること

エージェントフレンドリーとは、AI向けの何かを追加した状態ではなく、料金と条件と申し込み導線が機械にも読める状態のことです。

この言葉は「専用の対応をした状態」という意味で使われがちですが、当社が実際に見てきたサイトで詰まっていたのは、価格が画像に埋まっている、条件がPDFの中にある、フォームの入力欄に意味が付いていない、といった土台の側でした（当社の事例では）。追加ではなく整理が中身になります。

やること｜サイト側の対応は4つの関門に分かれる

サイト側の対応は、入れる・見つかる・読める・渡せるの4段に分かれ、落ちた場所ごとに直す相手が変わります。

上から順に見ます。前の関門で止まっていると、後ろをいくら直しても届きません。

関門1：そもそも入れているか（1分で測れる）

エージェントのUAで自分のトップページを取得して、返り値が200でなければ、そこで止まっています。

コマンドは1行です。ターミナルで実行して、数字が200以外なら塞いでいます。

UAの部分を GPTBot、OAI-SearchBot、ClaudeBot、PerplexityBot に差し替えて、同じことを繰り返します。403や503が返るものがあれば、そのエージェントからは自社サイトが存在しないのと同じです。

当社サイトで実際に測った結果は次のとおりです。

当社サイトの実測です（2026年9月5日）。指定したUA文字列を付けたHTTPリクエストに対して、6種類とも200と同じサイズを返しました。robots.txtに書いているのは管理画面の除外だけです。

これで分かるのは「そのUA文字列を名乗るリクエストを拒んでいない」ことまでで、実際のエージェントが最後まで通ったことの証明ではありません。それでも、塞いでいる場合はここで確実に分かります。

表に Google-Extended が無いのは、これがrobots.txtに書くためのトークンで、独立したUA文字列を持たないためです。Googleの公式ドキュメントに「Google-Extendedは独立したHTTPリクエストのユーザーエージェント文字列を持たない」と明記されています。UAを名乗らせて試しても意味がないので、代わりに利用者の指示で動くGoogle-Agentで測っています。

robots.txtでは止まらないエージェントがある（公式仕様）

利用者の指示で動くChatGPT-Userには、robots.txtが適用されない場合があるとOpenAIが明記しています。

OpenAIの公式ドキュメントでは、クローラーが4種類に分けられています。

理由は用途の違いです。OpenAIは「これらの動作は利用者が起点なので、robots.txtのルールが適用されない場合がある」と説明しています。自動で巡回しているのではなく、人が指示した取得の代行だからという整理です。

Googleも同じ立場を明記しています。利用者の指示で動くフェッチャーの一覧に Google-Agent を挙げ、「取得が利用者から要求されたものであるため、これらのフェッチャーは原則としてrobots.txtのルールを無視する」と書いています。

したがって、robots.txtに書けば来なくなるという前提で運用設計をすると外れます。訪問そのものを止めたい場合はサーバー側やCDN側のアクセス制御になります。

CDNの既定でブロックされていることがある（2026年9月15日から変わる）

Cloudflareを使っている場合、自分では何も設定していなくてもAIの通信が既定でブロックされていることがあります。

Cloudflareは2025年7月1日に、新規ドメインでAIクローラーを既定ブロックする方針を発表しました。さらに2026年7月1日の発表で、AIの通信を3つに分けて扱う方式へ変えています。

注意すべきなのは、複数の役割を兼ねるクローラーの扱いです。Cloudflareは、SearchとTrainingを兼ねるクローラーはその全ての振る舞いに応じて扱うと説明しており、Trainingをブロックする設定にした利用者では Googlebot・Applebot・Bingbot もブロックされる対象に挙がっています。既定のままにしたくない場合は、9月15日までにセキュリティ設定で意思表示しておく必要があります。

つまり、関門1で403が返る原因は自社の設定ミスとは限りません。CDNの管理画面で、どの区分を通す設定になっているかを確認してください。

関門2から関門4は、落ちる場所ごとに直す相手が変わる

関門2は検索、関門3は本文の書き方、関門4はフォームの実装で、担当が別々です。

関門2（見つかるか）は、AI専用の仕組みより先に、検索で見つかるかが土台になります。Googleが「AI機能に出る条件はインデックスとスニペット許可だけ」と書いているとおりです。仕組みの側の話はエージェントに発見される仕組みで扱っています。

関門3（読めるか）で当社がよく見つけるのは、料金ページの詰まりです。価格が画像になっている、条件がPDFの中にある、「要問い合わせ」しか書いていない、というページは、書いてある内容を機械が取り出せません。その結果、比較や判断の材料として使われにくくなると当社は見ています。直し方は機械可読性でつまずく場所にまとめています。

関門4（渡せるか）は、フォームの入力欄に意味が付いているかどうかです。次の章で当社の実測を出します。手順の詳細は申し込みが完了しない8つの原因にあります。

当社サイトを測ったら、通っていたのは半分だった

当社サイトはアクセスの関門を6種類すべて通りましたが、フォームの関門は通っていませんでした。

自分のサイトで測って、そのまま公開します。2026年9月5日のトップページの実測です。

入り口は開いているのに、最後の受け渡しで詰まっている状態です。SEOを本業にしている当社のサイトでもこうなっています。理由は単純で、フォームはプラグインが自動生成したまま運用され、人間が入力できていれば誰も困らなかったからです。

これは特別な失敗ではありません。人が使う分には支障が無いので、測らなければ気づけない種類の不備です。

従来のSEOと決定的に分かれる4か所

エージェントは、人間や検索エンジンなら補ってくれた曖昧さを補いません。分かれるのはこの4か所です。

「結局いつもの内部対策と同じでは」と感じた方に向けて、違いだけを取り出します。人やGooglebotが通れても、エージェントが落ちるのはここです。

内部対策の延長線上にあるのは事実ですが、判定が厳しくなる場所が決まっています。曖昧なまま人の判断で埋められていた箇所が、そのまま離脱になります。

いま着手すべき会社と、基礎SEOだけでいい会社

申し込みや予約がサイト上で完結する会社は関門4まで、資料請求だけの会社は関門3までで十分です。

4つ全部をいますぐやる必要はありません。業態で優先順位が変わります。

通すか止めるかだけは、先に決めておく

止める判断をする場合も、学習・検索・利用者起点の3つは分けて決めてください。まとめて塞ぐと検索の露出まで落ちます。

学習に使われたくないという理由でGPTBotを止めても、ChatGPTの検索結果に出したいならOAI-SearchBotは通す、という選び方ができます。逆に、全部まとめてブロックすると、AI検索経由の露出も同時に失います。

止めている会社がどのくらいあるかの目安として、Ahrefsが約1億4千万サイトを調べた2025年5月公開の調査では、GPTBot 5.89%、ClaudeBot 5.74%、Google-Extended 5.71%、ChatGPT-User 5.64%がブロックされていました。ただしこれは2025年5月時点の数字です。その後CDN側の既定が変わっているため、現在値としては使えません。

なお、正規のエージェントかどうかを署名で確かめるWeb Bot Authという仕組みが進んでいます。RFC 9421のHTTPメッセージ署名を使うもので、2026年8月時点でIETFでは個人提出のドラフトのままですが、Cloudflareなどは本番で運用しています。中小企業のサイトで自前の対応が必要になる段階ではありません。

【当社の見立て】エージェント化が進むほど、打ち手は従来のSEOに戻る

エージェントが増えるほど、有効な打ち手は従来のSEOに近づくと当社は見ています。

ここから先は当社の見立てで、確定した事実ではありません。

理由は置かれる場所です。AIの性能そのものは横並びに近づく一方で、どのAIが人の目の前に置かれているかという配布網の差は残ります。ブラウザやOSやオフィスソフトを持つ側に配布網があり、そこで機械が読む土台はGoogleとBingの索引です。つまり、エージェント対応として有効な投資は、結局のところ検索で読める状態を作ることに戻ります。

反証も書いておきます。2026年9月時点でサイトへの参照元シェアはChatGPTが大きく、当社サイトの実測でもCopilot経由は90日で12セッション（AI経由の1.9%）にとどまります。いますぐ配布網の側へ振り切れば足元の流入を落とします。順序として先にやるのは土台を固めることで、それが結果としてどのAIにも効く、という話です。詳しくはAI検索エンジンの比較に書いています。

AIエージェント対応のよくある質問

サイトのどこで止まっているかを実際に測ってほしい場合は、アイダイムのSEO・サイト改善のご相談から状況をお知らせください。関門1から4のどこで落ちているかを実物のページで確認します。

参考情報

• OpenAI公式：Overview of OpenAI Crawlers
• Google検索セントラル：AI features and your website
• Google検索セントラル：user-triggered fetchers
• Cloudflare公式ブログ：Content Independence Day
• Cloudflare公式ブログ：Your site, your rules（Search・Agent・Trainingの3区分と2026年9月15日の既定変更）
• Google検索セントラル：Googleの共通クローラー（Google-ExtendedはUA文字列を持たない）
• Ahrefs：We Analyzed 137K Sites: 97% of llms.txt Files Never Get Read
• Ahrefs：The AI Bots That ~140 Million Websites Block the Most

最終確認日：2026年9月5日／自社実測：2026年9月5日（aidaim.co.jp トップページ）