Googleで優先する情報源に追加
現在、ウェブトラフィックに占めるボットの割合は人間を上回っています。その上で今注目したいのは、どのような種類のボットがアクセスしているのかという点です。また、そうしたボットがサイトを訪れた後に何をしているのかを把握することにも価値があります。
AIトラフィックというと、一般的にはモデルのトレーニングを目的にコンテンツを収集し、サイトのリソースを消費するクローラーが注目されがちです。しかしそれとは別に、ユーザーに代わってサイトを訪れ、コンテンツを読んだり、顧客のようにサイト上で操作したりするAIエージェントも存在します。
こうしたAIエージェントは収益につながる可能性もありますが、現在の技術では、設定を調整しない限り、リソースを大量に消費するボットだけでなく、どちらの種類のボットもまとめてブロックしてしまいます。
クローラーのように読み、顧客のように購入する新たな訪問者
これまで長い間、WordPressサイトへの訪問者は、「人間」「クローラー」「決まったタスクを繰り返し実行するスクリプト」の3種類に大きく分けられてきました。
そこに今、AIエージェントが加わりつつあります。AIエージェントは、クローラーのようにページの構造を読み取る一方、人間のようにサイトを操作します。商品の価格を確認して比較し、そのまま購入手続きを完了することも、AIエージェントにとってそれほど難しいことではありません。
こうした背景から、エージェント型ボットの動向にも目を向けなければなりません。Cloudflareのトラフィックデータでは、自動化されたリクエストが初めて人間によるリクエストを上回りました。さらに、HUMAN Securityの「State of AI Traffic」調査によると、その自動トラフィックの中でも、AIエージェントやエージェント型ブラウザからのトラフィックは、ほかのカテゴリを大きく上回るペースで増加しています。
実際、AIエージェントはすでに身近な製品にも組み込まれ始めています。
- Chromeに組み込まれた自動ブラウジング機能：ユーザーが訪れる複数のサイトを横断し、情報収集や比較、購入手続きなどの複数ステップからなるタスクを実行
- OpenAIのブラウジングエージェント：ChatGPTアプリやChrome拡張機能から利用でき、ユーザーに代わって、ページを移動してタスクを実行
- PerplexityのCometブラウザ：ユーザーが開いている複数のタブから情報を収集し、ユーザーに代わって操作を実行（無料でダウンロード可能）
- Claude for Chrome（Anthropicのブラウザ拡張機能）：ユーザーに代わってページの移動やクリック、フォーム入力を実行
このようなAIエージェントはほかにも数多く登場し、すでに実際のサイトへのアクセスを発生させています。しかし、トレーニング用クローラーをブロックするための従来の設定は、こうしたAIエージェントを想定して設計されたものではありません。
AI経由のトラフィックは人間によるトラフィックよりもコンバージョン率が高い
米国の小売サイトへの1兆回を超える訪問データをもとにしたAdobeの2026年第1四半期の調査からは、わずか1年前には予想できなかった変化が見えてきます。
2025年3月時点では、AI経由のトラフィックのコンバージョン率は、有料検索やメールなどの一般的な流入経路と比べて38%低い水準でした。ところが2026年3月には、逆に42%高くなっています。わずか12か月で、大きく状況が逆転したことになります。また、AI経由の訪問者は、AI以外からの訪問者と比べて1回の訪問あたりの収益が37%高く、サイト滞在時間も48%長く、閲覧ページ数も13%多いという結果が出ています。さらに2026年第1四半期だけでも、AI経由のトラフィック量は前年同期比393%増加しました。
この違いは、訪問者の行動にあります。自然検索からサイトを訪れる人は、購入を検討し始めたばかりの場合もあれば、購入直前の場合もあります。一方、サイトにアクセスするAIエージェントには、すでに具体的なタスクが与えられています。
WooCommerceサイト、会員制サイト、見積もりや予約フォームなどにとって、まさに取り込みたいのがこうしたトラフィックです。
- プラグインを検討する場合：AIエージェントが料金を確認し、比較したうえでおすすめを提示
- サービスの提供エリアを確認する場合：AIエージェントが見積もりフォームに入力し、回答を待つ
- サブスクリプションプランを比較する場合：AIエージェントが各プランを比較し、そのまま申し込みまで完了
サイト側で許可されていれば、現在ではこうした一連のタスクをAIエージェントだけで最初から最後まで完了できます。
CloudflareはAIボットのブロックを3つのカテゴリに分類
インフラ側でも、こうしたAIトラフィックへの対応が進み始めています。Cloudflareでは、従来1つだったAIボットの設定が、「Search」「Training」「Agent」という3つのカテゴリに分けられ、すべての顧客がそれぞれ個別に制御できるようになりました。
- Search（検索）：コンテンツをインデックスし、後にAIが生成する回答に表示できるようにするクローラー。通常は、そこからサイトへのアクセスも期待できます。
- Training（トレーニング）：モデルの構築やファインチューニングを目的にコンテンツを収集するクローラー。サイトへのアクセスや購入などにつながることはありません。
- Agent（エージェント）：特定のユーザーに代わってリアルタイムでサイトを訪れ、操作を行うトラフィック。購入手続きを完了するケースなども含まれます。
Cloudflareでは、広告が掲載されているページでTrainingとAgentがデフォルトでブロックされる一方、Searchは許可されます。既存サイトについては、変更しない限り現在の設定が維持されます。ただし、Googlebotをはじめ、複数の目的を持つクローラーには、該当するルールのうち最も厳しいものが適用されます。そのため、Trainingを一律にブロックすると、検索での露出まで影響を受ける可能性があります。
Kinstaのボット対策機能では、このような判断をKinsta側で行います。現時点では、Cloudflareの管理画面のように3つのカテゴリに分けるのではなく、AIクローラーを1つの設定にまとめて制御する仕組みです。そのため、AIエージェントからのアクセスも考慮しながら、現在利用できる設定をうまく活用していくことがポイントになります。
AIエージェントが購入手続きを完了できるかを左右する3つの要素
AIエージェントがサイト上でタスクを最後まで完了できるかどうかは、コンテンツではなくインフラ側の3つの要素に左右されます。その多くにおいて、Kinstaの機能やインフラが役立ちます。
価格や在庫情報はHTMLに含める
AIエージェントは、ページの見た目ではなく、その基盤となる構造を読み取ります。そのため、クリックして初めて価格が表示されたり、ページのレンダリング後にAJAXで在庫数を読み込んだりする場合、アクセシビリティツリーをもとに動作するAIエージェントには、その情報が見えない可能性があります。
ただし、AIエージェントがどこまでサイトを操作できるかには差があります。実際のウェブ上のタスクをAIエージェントに実行させたある調査では、約80%のケースでタスクを完了できました。一方、スクリーンリーダーを利用するユーザーの操作を再現したキーボードのみの操作では、成功率が42%まで低下しています。
原因になりやすいのは、次のような要素です。
- アコーディオン形式のFAQ：回答を表示するにはクリックが必要なため、AIエージェントが内容を取得できない可能性がある。
- タブ形式の料金表：最初に表示されるタブの内容しか、ページの初期HTMLに含まれていないことがある。
- 在庫表示：JavaScriptで読み込まれる場合、AIエージェントがページを読み取る時点では情報がまだ存在しない可能性がある。
Googleが提案するWebMCP標準は、この問題をブラウザ側で解決しようとする取り組みの一つです。AIエージェントがページの内容から機能を推測するのではなく、サイト側から購入手続きや料金に関する機能を直接利用できるようにする仕組みです。ただし、まだ初期段階の試験的な技術であるため、現時点ではセマンティックHTMLを使用するのが確実な対策です。
AIエージェントがタイムアウトする前にページを表示する
複数のステップからなるタスクを実行するAIエージェントは、人間のように表示の遅いページを待ってはくれません。ページの応答が遅ければ、そのまま処理を中断し、コンバージョンを逃す可能性があります。
Core Web Vitalsの基準は、本来は人間のページ体験を評価するためのものですが、AIエージェントが許容できる表示速度を判断する目安にもなります。Largest Contentful Paint（LCP）を2.5秒未満に抑えることで、人間にもAIエージェントにも、一度のセッションでタスクを完了できる十分な余裕が生まれます。
また、ページが遅い原因を推測しながら対策していては、かえって時間を費やしてしまいます。Kinsta APMを使って購入手続きや商品ページを分析すれば、遅延の原因となっているプラグイン、データベースクエリ、外部サービスへのリクエストなどを特定できます。
監視を開始すると、「トランザクション」画面で、どのページやエンドポイントの処理が遅いのかを確認可能です。さらに、その原因となっているプラグインやクエリを特定して適切に対処できるため、原因を推測する手間を省き、AIエージェントがタスクを完了しやすい環境を整えることができます。
コンバージョンにつながるアクセスをボット対策機能でブロックしない
すべての自動化されたアクセスをトレーニング用クローラーとして扱う設定では、本来受け入れたいボットまでサイトに到達できない可能性があります。両者を区別できないシステムから見ると、どちらも同じボットによるアクセスに見えるためです。
そこでKinstaのボット対策機能では、トラフィックを適切に制御できるよう、以下の4つの設定を用意しています。
- 4段階の対策レベル：「悪意のあるトラフィックをブロック」から「すべてのトラフィックを検証」まで、サイト全体で未分類のトラフィックやボットの可能性があるトラフィックをどの程度厳しく検証するかを設定できます。
- AIクローラーのブロック：AIクローラーからのアクセスをまとめてブロックします。購入手続きを行うAgentセッションやTrainingクローラーも対象になります。
- 通常のWordPress自動処理を許可：厳しい対策レベルを使用している場合でも、REST API、プラグイン連携、バックグラウンドタスクを引き続き実行できます。購入手続きやAPIエンドポイントにアクセスするAIエージェントにとっても重要な設定です。
- 例外：IPアドレス、パス、ユーザーエージェントを条件に、対策レベルにかかわらずブロックや検証の対象外にするトラフィックを指定できます。
WooCommerceサイトや予約サイトでは、「通常のWordPress自動処理を許可」を有効にして、購入手続きやREST APIへのアクセスが厳しい対策レベルによって妨げられないようにするのが現実的な落としどころです。また、「AIクローラーのブロック」は常時有効にするのではなく、問題の切り分けなど必要なときに一時的に使用するのが適しています。
AIエージェント経由の購入を妨げず、トレーニング用クローラーだけをブロックしたい場合は、既知のAIエージェントのユーザーエージェントを例外に追加することで、「AIクローラーのブロック」だけを使用するよりも細かくトラフィックを制御できます。
MyKinstaでサイトのトラフィック状況を確認する
設定を変更する前に、AIエージェントからのアクセスを適切に処理できていると思い込まず、まずは実際にどのようなトラフィックがサイトに届いているのかを確認しておくことをおすすめします。MyKinstaでは、いくつかの場所から確認できます。
まず、「サイト」＞（サイト名）＞「ボット対策」画面では、2種類のデータを1つのグラフで確認できます。「リクエストの内訳」には、過去24時間にサイトに届いたすべてのリクエストが分類別に表示され、どのようなトラフィックがどの程度の割合を占めているのかを把握できます。
「ボット対策状況」では、それらのトラフィックがどのように処理されたかを「許可」「検証」「ブロック」の3つに分けて確認できます。
「リクエストの内訳」では、各分類の関係も確認可能です。たとえば、自動トラフィックの一部が検証またはブロックされている場合、それらが「AIクローラー」カテゴリにどの程度含まれているかを見ることができます。ただし、それがトレーニング用クローラーなのか、コンバージョンにつながるAIエージェントからのアクセスなのかまでは判別できません。
そこで、ブロックされたトラフィックが急増した時間帯と、同じ期間の注文数やリード数を照らし合わせてみます。ブロックが増えるのと同時に注文やリードが減っている場合は、正当なAIエージェントからのアクセスまでブロックされている可能性があります。
JavaScriptを無効にして購入手続きをテストする
ページの基盤となる構造をもとに操作するAIエージェントは、スクリーンリーダーを使用するユーザーと似た方法でサイトを利用します。購入までの流れがどこで止まってしまうのかは、2つの簡単なテストで確認できます。
まず、ブラウザでDevToolsを開き、右上の設定アイコンをクリックします。右側のセクションを下にスクロールして、「デバッガ」の「JavaScriptを無効にする」にチェックを入れます。その後ページを再読み込みし、商品をカートに追加したり、購入手続きに進んだりできるか試してみてください。
不具合やエラーが発生した場合、その操作がJavaScriptに依存しており、AIエージェントでは正常に実行されない可能性があります。たとえば、「カートに追加」ボタンがクリック可能な<div>として実装されている場合、JavaScriptが実行されなければ代替の操作方法がないことがあります。
同じ購入手続きの流れを、axeやWAVEなどのアクセシビリティチェックツールで確認することもできます。ラベルのない項目、非表示のフィールド、操作できないボタンなどは、AIエージェントからも認識できない可能性があります。この2つのテストを行うことで、修正が必要な要素を具体的に洗い出すことができます。
同時アクセス時の応答時間を確認する
AIエージェントが複数のタブを開いたり、短時間に複数の商品ページを確認したりすると、小規模ながら同時にアクセスが集中したような状態になります。一般的なパフォーマンステストでは、このような負荷のかかり方を検出できないことがあり、単一のリクエストを使ったテストでは問題が見つからない可能性があります。
MyKinstaの「分析」画面の「パフォーマンス」タブで、「PHP＋MySQLの平均応答時間」を確認します。画面下部の詳細な一覧とあわせて確認することで、サイト全体の平均値だけでは見えにくい、特に応答の遅いパスを特定できます。
続いてKinsta APMを実行し、カートや検索のエンドポイントに対して複数のセッションから同時にアクセスします。これにより、どの処理から応答時間が長くなっているのかを追跡できます。
「分析」画面の「パフォーマンス」タブにある「PHPスレッド上限」チャートで上限に達していることがわかった場合は、対処が可能です。「サイト」＞（サイト名）＞「情報」の「PHPパフォーマンス」セクションの「変更する」からPHPスレッド数を増やすことで、複数のAIエージェントから同時にアクセスがあった場合にも対応できる余裕を持たせることができます。
AIエージェントからのアクセスは、単なるボットではなく新たな流入経路に
トレーニング用クローラーについては、これまでどおりブロックしてリソースの消費を抑えるのが有効です。一方、購入手続きを完了するAIエージェントまで同じようにブロックするのは適切ではありません。そのため、利用できる機能を活用し、ボットの種類に応じて適切にトラフィックを制御する必要があります。
まずは、価格や在庫情報がページの初期HTMLに含まれているかを確認します。さらに、応答の遅いページを特定し、ボット対策機能の設定を見直すことで、現在サイトに届いているトラフィックをより細かく制御しながら、サーバーリソースを効率よく利用できます。
Kinstaでは、ボット対策機能、Kinsta APM、Cloudflare統合により、人間とAIエージェントの両方からのアクセスに対応できる環境を実現します。WordPress専用マネージドクラウドサーバーの詳細はこちらをご覧ください。
