フォーム前の来訪を98.5%特定｜WithSecureのAIエージェント運用

BtoBのサイトを見に来た人の多くは、問い合わせフォームを埋めません。埋める前に比較を終えていて、しかもその調べ物はAIアシスタントを経由していることがあります。この前提に合わせて、マーケティングから営業への受け渡しを作り替えた2社の話が、Salesforceの公式ブログに出ました（2026年10月27日）。

1社は、Salesforce環境のセキュリティを手がける Cloud Protection by WithSecure。もう1社は、BPOサービスの TaskUs です。前者の数字がいちばん具体的で、サイトを訪れた組織の98.5%を、社名で、実時間で特定していると書かれています。誰かがフォームに何かを入力する前に、です。作ったのはフルタイムの従業員2人、期間は6か月とあります。

先に断っておきます。これはプラットフォーム側が自社製品の使われ方として公表した事例で、第三者の検証は入っていません。測定の期間も、かかった費用も書かれていません。それでも持ち帰れるものが2つあります。計測する地点をフォームより前へ移すという設計、そして人が合流する場所を決めてから自動化を広げるという順序です。確認日は2026年10月28日、原文は英語です。

フォームの前に計測点を移す

原文が最初に崩している前提は「リードフォームが無ければ可視化できない」というものです。買い手は手を挙げるよりずっと早い段階から調べていて、その調べ物はAIアシスタントを通ることがあり、フォームにはまったく触れないまま検討が進む。この状態を、原文は「見えない閲覧」と呼んでいます。

Cloud Protection by WithSecure の答えは、来訪者の突き合わせ（visitor-matching）の仕組みでした。サイトのアクセスログを Data 360 と ZoomInfo に通し、来訪した組織の98.5%を社名で、実時間で言い当てる。そうして「見えない閲覧を、マーケティングと営業の両方が手を打てるパイプラインに変えた」と書かれています。

数字の意味は正確に受け取ってください。98.5%は、来訪した組織のうち社名を言い当てられた割合です。見込み客になった割合でも、商談につながった割合でもありません。パイプラインの入口の歩留まりを示す値で、成果の指標ではない、という読み方になります。

もう1つ見ておきたいのが体制です。この仕組みを作って動かしたのは、フルタイムの従業員2人、期間は6か月と明記されています。全社を巻き込んだ基盤刷新の話ではなく、マーケティング運用の側で完結する規模の工事として書かれているところが、日本の中堅チームにとっては読みどころです。あわせて、記事には使ったデータの取得方法や同意の扱いは書かれていません。同じことを日本で試すなら、どのログをどこまで保持し、企業データベースと突き合わせてよいかは自社の基準で確認する必要があります。

スコアは「いまの値」でなければ使われない

2つめは、リードスコアの作り替えです。原文は、静的なスコアをB2Bで最も古い罠だと書いています。3か月前に「ホット」と付いたリードが、今日は冷え切っているかもしれない。そして営業には、それを知る手段がない。

同社はスコアを300以上のシグナルで組み直しました。ページの閲覧、メールの開封、意図の強い行動。これらが継続的に再計算され、動きが止まれば値が減衰します。だからスコアは常に「いま」を映し、「前の四半期の評価」を映さない、という説明です。

技術的には小さな変更で、効きかたは大きい、と原文は評しています。営業が追う相手が「幽霊」から「実際の意図」に変わる、という言い方です。真似るときに力を入れる場所もここで決まります。点数の配分を細かく設計するより先に、減衰の設計を決めるほうが効きます。何日動きがなければ何点下げるのかを決めない限り、シグナルを300種類に増やしても、古い点数が居座ったままになります。

スコアを誰が見て誰が動くのかは、道具の分担の話にもつながります。顧客情報と商談情報をどちらの画面で持つかで受け渡しの形が変わるため、CRMとSFAの違いを整えてから着手するほうが、作り直しが少なくなります。

自動化するのは最初の一通ではなく、返信のほう

3つめが、この事例でいちばん転用しやすい部分です。原文はこう書きます。アウトバウンドは誰でも自動化する。その後（follow-through）を自動化するチームは少ない。

同社が足したのは、双方向のエージェント型メールでした。すべての返信を読み、意図を判定し、営業に渡せる状態のアカウントを担当者へ割り振るエージェントです。渡すときには、元のキャンペーン、返信のスレッド、補完した企業データを添える。冷たい接触も、途切れたスレッドも、「この案件は誰のものか」という揉め事も起きない、と説明されています。

言い換えると、自動化の順番が逆になっています。多くのチームは送る側（一斉配信、シーケンス、初回の接触）から自動化しますが、ここで自動化されているのは受け取る側です。返信は数が少ないかわりに、1件あたりの価値が高く、しかも人手の遅れがそのまま機会損失になります。手をつける順番を決めるときの判断材料になります。

エージェントをどの作業に置くかという考え方そのものは、AIエージェントをマーケティングに置くときの整理にまとめています。

人が合流する場所を決めてから広げる

4つめは TaskUs の話です。同社はAIのSDR（見込み客を開拓する担当）「Liz」を広げる過程で学んだ、と書かれています。営業は最初、AIのSDRが仕事をこなせるとは信じていなかった。そこでチームは小さく始めた。担当1人、カバーできていない領域1つ。それが動くと分かると、営業の側から広げてほしいと言い出した。

Salesforceのブログには、TaskUs のデマンドジェネレーションとマーケティングオペレーションを担当するシニアディレクター、Tina Katic-Michalos 氏の発言が載っています。営業はAIのSDRが本当に仕事をこなせるとは思っていなかった、だから担当1人・領域1つで小さく始めた、そしてそれが動いたとき、営業が Liz をあらゆる場面に入れてほしいと言い始めた、という内容です。

結果として挙げられているのは、すべてのリードに対する追跡率100%。人のチームでは規模を保てない水準だとされ、人のBDRと営業担当は、購入に近い案件へ回れるようになったと書かれています。思想は「エージェントが提案し、人がマージする」（agents propose, humans merge）。人を輪の外へ出すことが目的ではない、という整理です。

この型は、権限と確認の線を先に引く運用と相性がいいものです。承認の設計を先に作った例としてはState Farmのガバナンス付きエージェントが、成果の内訳まで公表した例としてはAI SDRが有料チケットの一部を売ったSaaStrが参考になります。

公表された数字は、主語が2社に分かれている

ここで数字の整理をします。原文には5つの数値が出てきますが、主語が2社に分かれていて、効く先も同じではありません。

いちばん混ざりやすいのが、最後の「約3倍」です。これはスプリントあたりに出荷した機能の本数で、エージェントを使う前が5、エージェントのチームで18、実装にかけた時間を含めてもその差だった、という記述です。集客や受注の数字ではありません。社内へ持ち込むときに「マーケティングが3倍」と書き換えてしまうと、検証できない目標が残ります。

TaskUs 側の「約40%」も中身を見ておきます。ニュースレターの制作が16〜20日から10〜12日程度に縮んだ、という値です。Marketing Cloud Next と Agentforce へ載せ替えた結果とされ、Account Engagement での制作工程は2〜3日から1日程度になったと書かれています。つまり制作の所要日数の話で、配信の成果の話ではありません。

5つめの指標として、Cloud Protection by WithSecure は統合的なヘルススコアを作っている途中だとあります。マーケティングの反応、サポートの対応履歴、製品の利用状況という、これまで同じ場所に置かれてこなかった3つを混ぜる設計です。報告するだけでなく、危ない状態のアカウントをアップセルの連絡対象から自動で外すところまで動かすとされています。ここも同じ「エージェントが提案し、人がマージする」運用です。構想の段階である点は、そのまま受け取ってください。

公表されているものと、されていないもの

自社の判断に使う前に、どこまでが書かれているのかを分けておきます。

項目	原文の記載
来訪組織の特定率	98.5%（社名・実時間）
その仕組みの構築体制	フルタイム従業員2人・6か月
スコアに使うシグナル	300以上（閲覧・開封・高意図の行動）
リードの追跡率	100%（TaskUs のAI SDR）
制作期間の短縮	16〜20日 → 10〜12日程度（約40%）
測定した期間	記載なし
比較の相手（対照群）	記載なし
費用・投資額	記載なし
商談数・受注への影響	記載なし
両社の組織規模	記載なし

下半分が空いているのは、この種の記事では正常です。導入事例は監査された報告書ではありません。書かれている範囲を設計の参考にし、書かれていない範囲を自社の目標値にしないという扱い方になります。

この事例が効いた条件

転用の前に、条件をそろえて見ておきます。Cloud Protection by WithSecure は、Salesforce環境を守る製品を売っている会社です。公式プレスリリースによれば、2026年9月1日に WithSecure から分離して独立した企業になり、本社はヘルシンキ、北米・EMEA・APACに体制を持ち、Salesforce の AgentExchange 経由でも提供されています。製品はファイル、リンク、ID、そして Agentforce のワークフローを実時間で検査し、マルウェアやフィッシングを止めるものだと説明されています。

つまり買い手が「Salesforceを使っている企業」にほぼ限られます。来訪した組織を社名で特定できれば、それがそのまま営業の優先順位に変わる商売です。個人向けの商品や、法人名を特定しても打ち手が変わらない商材では、同じ仕組みを置いても同じようには効きません。この条件を外して「来訪企業を特定すれば成果が出る」と読むと、投資の判断を誤ります。

もう1つの条件は、データ基盤を先に置いていることです。原文は結びで、2社とも古い業務にAIを後付けしたのではなく、共通のデータ基盤（Data 360、Agentforce、Marketing Cloud Next）の上に作り直したと書いています。基盤を整える順序そのものは、WPPが公表したデータ基盤の作り方のほうが詳しく書かれています。

日本のチームが試すときの順序

公表値ではなく設計を借りる前提で、着手の順番を4つに整理します。

第一に、集めてよいデータの範囲を先に決めることです。この事例の土台は、自社サイトのアクセスログと外部の企業データベースの突き合わせです。どのログをどれだけ保持し、どこまで突き合わせてよいかを、法務とともに自社の基準で確定させてから作り始めてください。特定率を測るのはそのあとです。原文にはこの点の記載がありません。

第二に、減衰から設計することです。シグナルの種類を増やすより、動きが止まった値を下げる規則を決めるほうが先です。これを決めないスコアは、作った日から古くなっていきます。

第三に、返信側を自動化することです。送る側の自動化はすでに手元にあるはずです。返ってきたものを読んで意図を判定し、文脈ごと担当へ渡す部分に、人の時間がどれだけ残っているかを見てください。

第四に、人が合流する場所を1つ決めることです。TaskUs は担当1人・領域1つから広げました。提案はエージェント、統合は人。この線を先に引いておくと、広げるときに社内の反対が小さくなります。

まとめ

Salesforceが公表した2社の事例で、いちばん具体的な数字は Cloud Protection by WithSecure の「来訪した組織の98.5%を社名で、実時間で特定する」でした。サイトのログを Data 360 と ZoomInfo に通す仕組みで、フルタイム2人・6か月で作られています。スコアは300以上のシグナルで継続的に再計算され、動きが止まれば減衰します。返信を読むエージェントが、文脈を添えて担当へ渡します。

TaskUs 側は、AIのSDRを担当1人・領域1つから広げ、すべてのリードへの追跡率100%を挙げています。制作の所要日数は16〜20日から10〜12日程度へ。約3倍という数字は開発の出荷速度で、マーケティングの成果ではありません。

測定の期間、比較の相手、費用はいずれも公表されていません。そして効いた条件もはっきりしています。買い手がSalesforceを使う企業に限られる商売だからこそ、社名の特定が営業の打ち手に直結しました。自社に当てはめるときは、まず「法人名が分かったら打ち手が変わるか」を確かめてください。変わらないのであれば、この事例で先に真似る価値があるのは、来訪企業の特定ではなく、返信を読む側の自動化です。