ゼロクリック時代、AIは本当に信頼できる顧客なのか？

Summary

• ユーザーがWebサイトを直接訪問する代わりに、AIが複数の情報を収集・要約して回答を提供する機会が増えたことで、「ゼロクリック」というキーワードが注目されるようになりました。

• 企業は、自社コンテンツがAI検索に表示されるよう検索クローラーのアクセスを許可する必要がありますが、すべてのAIベースの自動化トラフィックに同じ権限を与えるべきではありません。

• AIトラフィックは、検索、学習、比較、取引、攻撃など目的が異なるため、アクセス主体の身元、アクセス目的、リクエスト量、ビジネスへの影響を基準に分類する必要があります。

• 今後のボット管理は、単純に遮断するのではなく、自動化トラフィックの種類ごとに許可、速度制限、追加検証、遮断といったポリシーを設計する方向へ変化していく必要があります。

近年、AIマーケティング業界で繰り返し登場するキーワードの一つが、ゼロクリック（Zero-click）です。

従来、顧客は検索結果のリンクをクリックして企業のWebサイトを訪問し、複数のページを閲覧しながら製品やサービスを比較していました。しかし、生成AI検索では、AIが複数の情報源をもとに情報を要約して回答するため、ユーザーが元のWebサイトを訪問せずに情報収集を終えることがあります。

Bain & Companyの調査によると、消費者の約80％が、全検索のうち少なくとも40％でAIによる要約やゼロクリック検索結果を利用しており、これにより従来のオーガニックWebトラフィックは約15〜25％減少する可能性があると推定されています。

このような変化により、企業には新たな課題が生じています。

AIが自社のコンテンツを発見し、回答の中で引用できるようアクセスを許可する必要がある一方で、すべての自動化トラフィックにWebサイトやAPIを無制限に開放することはできません。

マーケターにとって、ゼロクリックは「AIの回答に自社ブランドをどのように含めるか」という課題です。

しかし、サービス運用担当者やセキュリティ担当者には、さらに複雑な問いが残されています。

顧客の代わりにWebサイトへアクセスするAIエージェントを、正常な顧客として扱うべきなのでしょうか。それとも、管理すべきボットとして扱うべきなのでしょうか。

ゼロクリックによってWebサイト訪問者は消えるのか？

ゼロクリックとは、ユーザーによるWebサイトへの直接訪問が減少する現象を指します。しかし、インターネット上で企業のコンテンツにアクセスするリクエスト自体が、すべてなくなるわけではありません。

ユーザーがAIに質問すると、AI検索サービスは必要な情報を探すためにWebページを探索したり、検索インデックスを参照したりします。

今後は、単なる情報検索にとどまらず、ユーザーの代わりに商品を比較し、在庫を確認し、予約や購入プロセスを支援するAIエージェントの活動も増えていく可能性があります。

従来のカスタマージャーニーと比較すると、次のようになります。

つまり、ゼロクリックは単に「Webサイトのトラフィックがなくなる現象」ではありません。

Webサイトへアクセスする主体が、人間中心の構造から、検索クローラーやAIエージェントへと拡大していく変化だと捉えることができます。

問題は、この過程で発生するすべての自動化リクエストが、企業に同じ価値をもたらすわけではないという点です。

AI検索クローラーとAIエージェントは何が違うのか？

これまで企業は、自動化トラフィックを主に次の2種類に分類してきました。

• 検索エンジンなど、有益な機能を提供するGood Bot

• スクレイピング、アカウント攻撃、マクロなどを実行するBad Bot

しかし、AI環境では、この2つの分類の間にさまざまな種類の自動化トラフィックが登場しています。

OpenAIも、検索結果への表示に使用される「OAI-SearchBot」と、モデル学習に利用される可能性がある「GPTBot」を別々に運用しています。

Webサイト運営者は、検索結果やAIの回答にコンテンツを表示させたい場合、OAI-SearchBotのアクセスを許可できます。一方、モデル学習を許可するかどうかは、GPTBotに対するポリシーとして別途設定できます。

Cloudflareも2026年7月から、AIによる自動化アクセスを一括して「AI Bot」として扱うのではなく、Search・Agent・Trainingという行動別に管理できるよう、分類体系を拡張しました。

つまり、AI技術を使用しているという理由だけで、そのアクセスが正常か悪性かを判断することはできません。

誰がアクセスしているのか、何をしようとしているのか、どの程度のシステムリソースを使用しているのか、実際のビジネスにどのような影響を与えているのかを、総合的に確認する必要があります。

すべてのAIエージェントを許可すると、どのような問題が発生するのか？

AI検索におけるブランド露出を拡大するためには、検索クローラーが企業のコンテンツを発見できる必要があります。

しかし、それを理由にすべての自動化リクエストを許可すると、WebサイトやAPIの運用に新たな負担が発生する可能性があります。

コンテンツやデータが過剰に収集される可能性があります

検索結果への表示を目的とした限定的なクローリングと、価格、商品、技術情報などを繰り返し収集するスクレイピングでは、アクセスの目的が異なります。

特に、商品価格、在庫、座席、プロモーション情報のようにリアルタイムで変化するデータは、短い間隔で繰り返しリクエストされる可能性があります。

このようなアクセスは、検索結果への表示に直接貢献しない一方で、サーバーやデータベースに継続的な負荷を与える可能性があります。

正常なAIエージェントでもシステム負荷を発生させる可能性があります

悪意のないAIエージェントであっても、複数のユーザーに代わって商品を同時に比較したり、価格や在庫を照会したりすると、人間よりもはるかに多くのリクエストを発生させる可能性があります。

例えば、1人のユーザーが確認できる商品は数点程度ですが、AIエージェントは短時間のうちに数十種類の商品、オプション、在庫状況を比較するため、複数のAPIを呼び出すことがあります。

情報照会を超えて、実際のビジネスフローに影響する可能性があります

AIエージェントがコンテンツを読むだけではなく、次のような領域にアクセスすると、リスクのレベルは変わります。

• ログインおよび会員登録

• 商品検索と在庫照会

• カートへの商品追加

• 座席や客室の確保

• 予約および決済

• 注文・予約内容の変更

これらは、正常な顧客にも提供されている機能です。

そのため、リクエストの形式が正常であるという理由だけで、安全だと判断することは困難です。

AIエージェントは、どのような基準で分類すべきか？

1. アクセス主体の身元を確認できるか？

最初の基準は、その自動化リクエストが誰によるものなのかを確認できるかどうかです。

• サービス名や運営主体が公開されているか

• 一貫したUser-Agentを使用しているか

• 公式のIPアドレスリストや認証方法を提供しているか

• robots.txtやクローリングガイドラインを遵守しているか

• 連絡先と利用目的を確認できるか

Cloudflareは、検証済みボットやエージェントの条件として、正確な自己識別、robots.txtの遵守、適切なリクエスト速度、Webサイト運営者のポリシーを回避しない行動などを挙げています。

ただし、身元が確認されたボットだからといって、すべてのURLやAPIに同じアクセス権限を与える必要があるわけではありません。

2. アクセスの目的は何か？

同じ企業が運営するAIであっても、目的によって適用すべきポリシーは異なります。

• 検索結果や回答を生成するためのアクセスか

• モデル学習用のデータを収集するためのアクセスか

• ユーザーの代わりに商品を比較するためのアクセスか

• 実際に予約や購入を行うためのアクセスか

• 価格や在庫情報を繰り返し収集するためのアクセスか

コンテンツページを読む検索クローラーと、決済APIを呼び出すAIエージェントを同じ基準で扱うことは困難です。

3. システムリソースをどの程度使用しているか？

自動化リクエストが正常かどうかは、目的だけでなくリクエスト方法からも判断する必要があります。

• 1秒あたりのリクエスト数

• 同時リクエスト数

• 同一URL・APIの反復呼び出し回数

• セッションの継続時間

• アクセスするページや機能の範囲

• 時間帯別のリクエストパターン

• 正常ユーザーと比較した探索速度

正常な検索クローラーであっても、システムが処理できる範囲を超えてアクセスする場合は、速度制限が必要になることがあります。

4. ビジネスの成果にどのような影響を与えるか？

最後に、そのリクエストが実際のサービス運用に与える影響を確認する必要があります。

• ブランド露出やコンテンツの発見に貢献しているか

• 正常な製品比較や購入コンバージョンを支援しているか

• 実際の座席や在庫を先に確保しているか

• 分析データや需要シグナルを歪めているか

• 正常な顧客のログイン・予約・決済を妨げているか

• インフラや外部APIの利用コストを増加させているか

ボットを技術的に識別するだけでは不十分です。

サービスやビジネスに与える影響を基準に、対応ポリシーを決定する必要があります。

許可・制限・検証・遮断ポリシーは、どのように分けるべきか？

企業は、自動化トラフィックを検知した後に一律の措置を適用するのではなく、リスクや目的に応じて段階的に対応できます。

ここで重要なのは、コンテンツへのアクセス権限と、取引機能へのアクセス権限を分けることです。

検索クローラーがブログや製品説明を読めるように許可したからといって、ログイン、カート、予約、決済APIまで同じように開放する必要はありません。

AIエージェント時代のボット管理は、単に遮断するかどうかを決める作業ではありません。
どの自動化トラフィックに、どのレベルのアクセス権限と処理速度を提供するかを設計する作業です。

AIエージェントトラフィックは、どのように管理すべきか？

実際の運用では、次のような段階で対応できます。

ステップ1. 現在流入している自動化トラフィックを把握する

まず、どのようなボットやエージェントが、どのページやAPIへアクセスしているのかを確認する必要があります。

単に全トラフィックに占めるボットの割合を確認するだけでなく、次の項目もあわせて確認します。

• アクセスしたURLとAPI

• リクエスト回数と速度

• セッションごとの閲覧・遷移フロー

• ログイン・カート・予約機能へのアクセス有無

• レスポンスタイムとサーバーリソースの使用量

• 正常ユーザーのコンバージョンプロセスに与えた影響

ステップ2. 自動化トラフィックを目的別に分類する

検索、学習、比較、取引、攻撃など、目的別にカテゴリーを分け、それぞれの種類に必要なアクセスレベルを定義します。

ステップ3. ページやAPIごとにポリシーを設定する

例えば、次のように分類できます。

• ブログ・ガイド：検索クローラーのアクセスを許可

• 製品・価格ページ：アクセス範囲とリクエスト量を制限

• 在庫・座席API：認証と速度制限を適用

• ログイン・会員登録：行動分析と追加検証を適用

• カート・予約・決済：セッション単位の分析と同時処理量を制御

ステップ4. 検知ポリシーとトラフィック制御を分ける

どのリクエストを許可するかを判断することと、許可されたリクエストをどの程度の速度で処理するかは、異なる問題です。

正常なAIエージェントであっても、システムの処理能力を超えるリクエストを送信すると、サービス障害が発生する可能性があります。

そのため、アクセス資格の判断と、アクセス速度の制御をあわせて行う必要があります。

ステップ5. ポリシーを継続的に調整する

新しいAI検索サービスやAIエージェントが登場すると、既存の分類やポリシーが適合しなくなる可能性があります。

• 新しいUser-AgentやAIエージェントの確認

• 許可したトラフィックによる実際の流入・コンバージョン貢献度の測定

• 過剰なAPIリクエストとリソース使用量の確認

• 誤検知やセキュリティ回避パターンの分析

• URL・APIごとのポリシー再調整

ゼロクリックやAIエージェントへの対応は、一度設定して完了する作業ではなく、継続的に管理すべき運用領域です。

ゼロクリック時代には、「発見可能性」と「アクセス制御」を同時に設計する必要があります

ゼロクリック時代において、企業はAIの回答に自社ブランドやコンテンツが含まれるよう準備する必要があります。

しかし、AIに発見してもらうためにすべての自動化アクセスを許可する方法や、セキュリティを優先してすべてのAIボットを遮断する方法は、持続可能な対応とは言えません。

今後のWebサイトやAPIには、さまざまな自動化主体がアクセスするようになります。

• 検索結果やAIの回答を生成するクローラー

• モデル学習用のデータを収集するボット

• 顧客の代わりに情報を比較するAIエージェント

• 予約や購入を支援する取引型AIエージェント

• 正常なAIエージェントを装ったスクレイパーや悪性ボット

そのため、企業は次の2つの質問に同時に答える必要があります。

AIは、自社のブランドやコンテンツを発見できるか？
自社を発見したAIは、サービス内で何を、どの範囲まで実行できるか？

AI検索時代における競争力は、単に多くのコンテンツを公開するだけでは完成しません。

AIに必要な情報を正確に提供しながら、自動化トラフィックのアクセス権限と処理速度を、サービスの目的に合わせて制御する運用体制が必要です。

FAQ

Q1. AI検索クローラーを遮断すると、GEOでの露出に不利になる可能性がありますか？

検索や回答生成に使用されるクローラーがコンテンツにアクセスできない場合、そのページがAI検索の要約や情報源として活用される可能性が低くなることがあります。

ただし、検索用クローラーとモデル学習用クローラーでは役割が異なるため、robots.txtでそれぞれ異なるポリシーを設定できます。

OpenAIの場合、OAI-SearchBotは検索結果への表示、GPTBotはモデル学習への利用可能性に関連するクローラーとして区分されています。

Q2. AIエージェントは、すべて正常なボットですか？

いいえ。

AI技術を使用しているという理由だけで、正常なトラフィックかどうかを判断することはできません。

アクセス主体の身元、目的、リクエスト頻度、アクセスするURLやAPI、取引やシステムに与える影響を総合的に分析する必要があります。

Q3. 正常なAIエージェントでも、サーバー障害を引き起こす可能性がありますか？

あります。

悪意がなくても、短時間に大量の商品、価格、在庫、予約APIを呼び出すと、サーバーやデータベースに負荷を与える可能性があります。

そのため、正常なAIエージェントに対しても、適切なリクエスト量の制限とトラフィック制御ポリシーが必要です。

Q4. robots.txtだけで、AIエージェントトラフィックをすべて管理できますか？

robots.txtは、クローラーに対してWebサイト運営者のアクセスポリシーを伝えるための手段ですが、すべての自動化ツールがその内容を遵守するわけではありません。

また、ログイン、カート、予約、決済など、実際のサービス機能で発生する自動化活動に対しては、行動ベースの検知やAPI保護もあわせて適用する必要があります。

Q5. BotManagerとNetFUNNELには、どのような違いがありますか？

BotManagerは、自動化トラフィックの行動やリスクを分析し、悪性ボットやマクロを検知して対応する役割を担います。

NetFUNNELは、正常なトラフィックとして許可されたリクエストがシステムの処理能力を超えないように、アクセス速度や同時処理量を制御します。

つまり、BotManagerが「誰をアクセスさせるのか」を判断するソリューションであるのに対し、NetFUNNELは「どの程度の速度でアクセスさせるのか」を管理するソリューションです。