AIエージェントの来訪｜受付方針を決める
顧客の代わりに訪れるAIエージェントを、自社サイトでどう受け付けるか。Cloudflareの11月4日の発表を手がかりに、アクセスの把握、許可する範囲、本人の権限、誤遮断の確認を分けて整理します。
顧客がAIエージェントに「この会社のサービスを調べて」と頼んだとき、自社サイトはどのように応答するでしょうか。ページを読めるのか、途中で止まるのか。それを、サイトの担当者は把握できているでしょうか。
AIらしいアクセスを見つけても、すべてを歓迎するか、すべてを止めるかだけで決める必要はありません。どの訪問者が、どのページへ、何をしに来たかを確かめ、業務に合わせて受付方針を決めることが出発点になります。
本記事は、顧客の代理として外から訪れるAIを受け付ける、企業サイト側の運用を扱います。自社のAIが他社の画面を操作する手順や、検索順位を上げるための解説とは対象が異なります。
11月4日、Cloudflareが来訪状況とアクセス制御を発表
Cloudflareは2026年11月4日、個人向けAIエージェントの来訪を把握する分析機能と、対応するエージェントごとのアクセス方針を発表しました。Security Analyticsの「Personal Assistants」という分類で、訪問先のパスや応答状況などを確認する考え方が示されています。Cloudflare公式発表
同社の発表は、エージェントを識別することと、その背後の利用者の契約・依頼内容などを把握することを区別しています。後者の文脈を引き継ぐ仕組みは、今後取り組む目標として説明されています。今回の発表だけで、顧客の権限や依頼内容まで自動的に確認できると解釈しないことが大切です。
以下はこの動向を踏まえたIvyLeapの運用提案です。特定プランでの提供範囲や自社環境への適用状況は別途確認する必要があり、当社サイトで同機能を設定・検証したという意味ではありません。
最初に、来訪の種類と困っている場面を分ける
サイトのアクセス記録を確認するときは、「AIから来た」という大きなくくりだけで業務への影響を判断しないようにします。公開ページを探す利用、顧客が依頼した比較、ログイン後の情報照会では、受け付けたい範囲が違うからです。
まずサイト担当者と営業・窓口担当者で、次の項目を一枚に整理します。
- 対象ページ：会社案内、サービス、よくある質問、会員ページなど、どこへ来ているか。
- 応答状況：正常に読めているか、拒否やエラーが続いているか。
- 業務との関係：情報収集、相談、受付内容の照会のどれにつながる場面か。
- 判断できない部分：訪問者の種類や目的を、手元の記録で確かめられるか。
例えば、サービスページを読む途中で止まっている場合と、存在しないURLへのアクセスが続く場合を、同じ「失敗件数」としてまとめると判断を誤りやすくなります。分類できない記録は不明のまま残し、見た目や名乗りだけで特定の製品からの訪問と断定しません。
AIの訪問件数を、そのまま顧客数や商談数へ置き換えることも避けます。サービスを比較した後、本人が別の端末から相談する場合など、結び付けられない範囲があります。
公開情報と、顧客ごとの操作を分けて方針を書く
受付方針は、「どのエージェントを受け入れるか」と「その先で何を許すか」を分けて決めます。公開中のサービス紹介を読めることが、契約内容の閲覧や登録変更まで許す根拠にはなりません。
業務ごとに、対象ページ、許可する行動、必要な本人確認、判断する担当者を記載します。仮に、公開FAQは参照してよい一方、個別の申込内容はログインした顧客が確認する設計なら、その境界をアクセス対策の変更後も守れているか確かめます。
また、アクセスを受け付ける設定と、申込・問い合わせを業務として受理した状態も別です。ページへ到達できただけで、窓口に相談が届いたと数えないようにします。送信結果や受付番号など、実際の処理と照合できる記録を基準にします。
この段階で会社側が決めるのは業務上の方針です。製品の設定項目でどこまで実現できるかは、保守担当者と対応付けて確認してください。サイト全体の制御一つで、細かな業務権限まで実装できると考えないことが要点です。
変更前に、取りこぼしたくない顧客の動きを確認する
アクセス対策を見直す場合は、先に期待する動きを書き出します。例えば、公開サービスを調べる、関連する説明へ進む、相談窓口を確認する、という流れです。実在する顧客や本番の営業窓口へ、繰り返しテスト送信する必要はありません。
保守担当者が用意した検証環境や、許可されたテスト範囲で、次の四つを確認すると整理しやすくなります。
- 受け入れたいAIが公開ページを読む。 対象の説明とリンクへ到達できるか。
- 通常の人が同じ流れを使う。 AI向けの変更で、人の閲覧や問い合わせが妨げられていないか。
- 許可のない状態で個別情報を要求する。 公開情報への許可が、会員情報の閲覧へ広がっていないか。
- 途中で拒否やエラーになる。 担当者が、発生箇所と影響する利用を記録から確認できるか。
確認結果には、日時、対象ページ、期待した動き、実際の応答、変更内容を残します。検証のために保護機能を一括で無効にする方法を前提にせず、必要な範囲と戻し方を保守担当者が確認してから進めます。
訪問数と、業務への影響を別々に見直す
方針を変えた後は、AIらしいアクセスの増減だけで成功を決めないようにします。見たいのは、必要な説明へ到達できること、不要なアクセスを抑えること、通常の顧客が困らないことの組み合わせです。
計測できる範囲で、対象ページの応答状況、相談窓口までの到達、実際の受付を分けて比較します。比較期間や集計条件が異なる場合は、その違いも記録します。アクセスの分類がない期間を、後から推測で埋めて効果を作ってはいけません。
最初の一歩は、よく見られるサービスページを一つ選び、誰のどの利用を受け付けたいか合意することです。営業・窓口担当者は顧客の動きを説明し、保守担当者は記録と設定の対応を確認する。この役割分担で、受付方針を具体的にできます。
情報の示し方はAIエージェントに伝わる企業サイト、AIが業務画面を操作する側の確認はブラウザー操作の設計で解説しています。IvyLeapのAIエージェント構築支援とあわせて、自社の業務やサイトの相談はお問い合わせください。
※発表日は2026年11月4日、出典の確認日は11月5日です。上記の検証場面は運用設計の例であり、IvyLeapの導入実績や計測済みの効果を示すものではありません。