「AIエージェントが問い合わせフォームを送信したらしい。これは新しい商談チャネルだ」
この報告を受けた事業責任者は、期待する一方で、すぐに次の質問をしたくなるはずです。
- 本当にエージェントが一連の操作を完了したのか
- 途中で人が引き継いだのではないか
- フォーム送信があっても、相談内容は自社の対象顧客に合っているのか
僕は、この3つを分けずに「AI経由のリード」とまとめると、サイト改善の判断を誤ると考えています。新しい計測機能の価値は、派手な来訪数を増やすことではありません。顧客の代わりに動くエージェントが、どこまで理解し、どこで止まり、どの時点から人へ渡すべきかを確かめられることにあります。
この記事では、Microsoft Clarityの新しい公式発表を起点に、BtoBサイトで使える「3段階・証拠シート」へ翻訳します。
変わったのは流入元ではなく「行動する主体」
Microsoftは2026年11月4日、ClarityでAIエージェントのサイト内行動を把握するAgent Activity、AI経由の発見を支えるBrand Agents、セッション証拠に基づいて質問できるAsk Clarityを発表しました。Agent Activityでは、検索、フォーム送信、ログイン、ダウンロード、予約、チェックアウトなどの行動を確認できると説明しています。
その背景にある同社調査は、2026年8月13日から9月9日まで、230,511プロジェクトにおける約523万件の「エージェントが関与したと分類されたセッション」を分析したものです。対象として検知されたのはOpenAI、Google、Anthropicのオペレーター群でした。
ここで重要なのは件数より、公式調査が書いている留保です。
エージェント関与セッションには、人への引継ぎが含まれる場合があります。また、記録されたイベントは互いに排他的ではなく、連続したファネルや、エージェント単独によるタスク完了を証明するものではありません。
つまり、フォーム送信イベントが見えても、それだけで「AIエージェントが有効商談を作った」とは言えません。
1件のイベントを、3段階の証拠に分ける
僕なら、AIエージェントの来訪を次の3段階に分けます。順番は「検知→完了→商談価値」です。
| 段階 | 確かめる問い | 残す証拠 | まだ言えないこと |
|---|---|---|---|
| 1. 来訪・探索 | どのエージェントが、何を探して、どのページへ来たか | 検知したオペレーター、参照元、閲覧ページ、検索・クリック | 顧客本人の意図、購入意欲 |
| 2. タスク完了 | 資料取得や予約など、指定タスクを最後まで終えたか | 完了イベント、確認画面、受付UUID、所要時間、途中離脱 | 人の介入がなかったこと、有効商談であること |
| 3. 商談価値 | 自社が支援できる課題で、営業が次へ進めるか | 対象条件、課題、時期、担当者確認、営業判定、失注理由 | 受注、増分効果、広告の因果 |
この表のポイントは、イベントの有無と、営業判断を同じ列に置かないことです。計測担当は「送信された」を確認できても、営業担当が「支援対象に合う」と判断するまで、商談価値は未確定です。
仮例：製造業向けSaaSを比較するエージェント
以下は説明用の仮例です。実在企業の実績ではありません。
ある製造業の担当者がAIエージェントへ、「3拠点で使える設備保全SaaSを比較し、セキュリティ要件を満たす会社の資料を取り寄せて」と依頼したとします。
サイト側が見たいのは、資料請求数だけではありません。
| エージェントの仕事 | サイト側の必要情報 | 合格条件 | 失敗時に直す場所 |
|---|---|---|---|
| 候補を見つける | 対象業種、拠点規模、提供地域 | 対象条件が本文で明示されている | ファーストビュー、サービス概要 |
| 条件を比較する | セキュリティ、連携、導入条件、非対応範囲 | 比較に必要な事実へ到達できる | FAQ、仕様表、構造化された見出し |
| 資料を取得する | 資料名、用途、個人情報の扱い | 正しい資料と確認画面に到達する | フォーム、同意文、エラー表示 |
| 人へ渡す | 質問、会社条件、希望時期、連絡方法 | 担当者が文脈を読める状態で受付される | CRM項目、通知文、営業SLA |
もしエージェントが資料請求まで進めても、希望時期や対象設備が欠けていれば、営業は最初から聞き直すことになります。反対に、条件を構造的に示しておけば、対象外の問い合わせを無理に増やさず、適切な相談だけを人へ渡しやすくなります。
実装前に書く「AIエージェント・タスクカード」
計測ツールを入れてから考えるのではなく、先に1枚のタスクカードを書きます。これが今回の実行資産です。
| 記入欄 | 記入例（仮） |
|---|---|
| 顧客がエージェントへ頼むこと | 3拠点対応の設備保全SaaSを比較し、条件に合う資料を取得する |
| サイトで完了してほしい1タスク | セキュリティ資料の請求完了 |
| 必ず読んでほしい事実 | 対象規模、提供地域、連携条件、非対応事項 |
| 完了の機械的証拠 | 確認画面表示＋受付UUID発行（解析にはPIIを送らない） |
| 有効相談の人による条件 | 対象業種、課題の一致、導入時期、担当者の連絡確認 |
| 人へ切り替える条件 | 個別見積り、契約条件、セキュリティ例外、判断に必要な情報不足 |
| 失敗時に直す変数 | 見出し、FAQ、フォーム項目、エラー文のうち1つ |
一度に全部を改修すると、何が効いたか分からなくなります。最初は一つのタスクと一つの主要変数に絞ります。
計測は「本番リード」と「テスト」を混ぜない
AIエージェント対応を試すとき、内部テストやシミュレーションを実際の問い合わせに数えると、最初の数字から判断が歪みます。
最低限、次を分けて記録します。
| 記録項目 | 本番 | 内部テスト／シミュレーション |
|---|---|---|
| 受付UUID | 発行 | 発行するがtestフラグを付ける |
| 解析イベント | generate_lead等、保存成功後に1回 | 専用testイベント |
| 個人情報 | 解析へ送らない | 解析へ送らない |
| 営業実績 | 人が有効性を判定後に記録 | 0件としてではなく対象外として除外 |
| 失敗ログ | 入力・送信・保存・通知を分離 | 再現条件と修正箇所を記録 |
送信ボタンのクリックではなく、受付APIの保存成功後に完了イベントを発火させる。さらに、同じ受付UUIDで二重発火させない。これは人のフォームでもエージェント経由でも共通する基本です。
結果別に、次の一手を変える
来訪はあるが、必要情報へ着けない
ページのタイトルと見出しが、顧客の比較条件を表しているかを見直します。社内用語や抽象語ではなく、対象・条件・非対応範囲を本文で明示します。
情報は読めるが、フォームで止まる
必須項目、同意文、エラー表示、確認画面を一つずつ点検します。エージェントのために本人確認や同意を弱めるのではなく、入力条件と人への切替点を明確にします。
フォームは完了するが、有効相談にならない
流入数より、フォーム前の期待調整と営業引継ぎを直します。対象顧客、相談できる範囲、準備してほしい情報を明示し、CRMへ「何を比較していたか」を残します。
対象セッションがほとんどない
専用機能を増やしすぎない判断も必要です。まず人の顧客が同じページで迷っていないかを確認し、共通の情報設計を優先します。未取得をゼロと扱わず、観測期間と母数を記録します。
この方法の適用限界
Microsoftの2026年11月4日時点の案内では、Agentic Analyticsが対応するオペレーターはGoogle、OpenAI、Anthropicです。すべてのAIエージェントを識別できるわけではありません。また、シミュレーションは当初、コマースと旅行のシナリオから開始すると説明されています。BtoBの複雑な稟議や見積りを、そのまま自動検証できるとは限りません。
さらに、セッション記録を使うなら、同意、マスキング、個人情報、社内の閲覧権限を先に確認します。Clarityの公式FAQでは入力欄のテキストはマスクされ、同意が必要な地域では適切な同意がないと連続したユーザージャーニーなど一部機能が制限されると説明されています。法務判断は地域・業種・実装で変わるため、必要に応じて専門家へ確認してください。
この設計は、AIエージェント経由の受注や増分効果を保証するものではありません。検索順位やAI回答での引用も保証しません。
最後に：新しい流入を、古いKPIへ押し込まない
AIエージェントの来訪が増えても、「フォーム送信数」という一つの数字だけでは、顧客理解は深まりません。
僕なら、まず一つの顧客タスクを選び、来訪・完了・商談価値の証拠を分けます。そこで見つかった詰まりを、見出し、FAQ、フォーム、営業引継ぎのどこに戻すか決めます。AIに作業を任せるほど、人は「何を商談と呼ぶのか」「どこで人が責任を持つのか」を考える必要があります。
もしAIエージェントの母数がまだ小さいなら、同じ顧客の疑問とLPの判断材料を、人の見込み客に対する広告で検証する方法もあります。約1週間を目安にLP・動画広告・計測等を準備し、広告配信30日で運用・分析・改善する30-DAY AD TESTは、そのための選択肢です。成果や受注を保証するものではなく、あなたの事業で確かめるべき条件を整理するところから始めます。
参照した一次資料
- Microsoft Clarity Blog, “Agents act, LLMs recommend, and people browse. Microsoft Clarity connects all three journeys.” 発表日：2026-11-04、確認日：2026-11-08、https://clarity.microsoft.com/blog/clarity-connects-agents-llms-people/
- Microsoft Clarity Blog, “What AI Agents Do on Websites: Insights From 5.2 Million Sessions.” 発表日：2026-10-29、確認日：2026-11-08、https://clarity.microsoft.com/blog/agentic-analytics-what-agents-do-on-websites/
- Microsoft Learn, “Frequently asked questions | Microsoft Clarity.” 確認日：2026-11-08、https://learn.microsoft.com/en-us/clarity/faq/
- Google Search Central, “Creating helpful, reliable, people-first content.” 確認日：2026-11-08、https://developers.google.com/search/docs/fundamentals/creating-helpful-content
※本文の製造業向けSaaSの場面・数値を伴わない記入例は、手順を説明するための仮例です。当社または顧客の実績ではありません。
