なぜあなたの資料アナリティクスは間違っているのか：メールセキュリティボットが閲覧数を水増しする仕組み

見込み客に提案書のリンクを送ります。2分後、トラッキングツールが「相手がリンクを開き、6ページをスクロールし、各ページに30秒ずつ滞在した」と表示します。

すぐにフォローアップメールを送ります。しかし相手は何のことか全くわかりません——まだリンクを開いてすらいなかったのです。

何が起きたか：相手の会社のメールセキュリティスキャナーが、相手より先にあなたのリンクを開いたのです。その「閲覧」はボットでした。そしてアナリティクスプラットフォームがこれを明確に処理しない限り、本物との違いを見分けることはできません。

これは稀なエッジケースではありません。Microsoft 365やGoogle Workspaceを使用するエンタープライズの受信者に送られるメールのほぼすべてで発生しています。

アナリティクスを水増しするボットたち

共有された資料リンクにアクセスする自動トラフィックには3つのカテゴリーがあります：

リンクプレビューボット

Slack、LinkedIn、Twitter、iMessageにリンクを貼ると、ボットがすぐにページを取得してプレビューカードを生成します。これらのリクエストは識別可能なUser Agentを使用しています——Slackbot-LinkExpanding、LinkedInBot、Twitterbotなど。検出とフィルタリングは容易です。ほとんどのトラッキングツールはこれらを正しく処理しています。

検索エンジンクローラー

Googlebot、Bingbot、およびそれらの派生版は、公開コンテンツを定期的にインデックスしています。これらも自らを公然と識別しており、フィルタリングは簡単です。共有リンクが認証で保護されているか、ユニークなslugを使用していれば、クローラーがそれらを見つけることはほとんどありません。

メールセキュリティスキャナー

これがアナリティクスを壊すカテゴリーです。

Microsoft Defender SafeLinks、Proofpoint URL Defense、Mimecast、Google Safe Browsingは、受信者がメールを見る前に、受信メール内のすべてのリンクをスキャンします。フィッシングページやマルウェアを検出するのが目的です。実際にリンクを開き、ページを読み込み、多くの場合コンテンツ内を遷移することでこれを行います。

実際のユーザーとほぼ見分けがつかない理由：

• 偽装されたUser Agent。 SafeLinksは自らをボットとして名乗りません。本物のブラウザUser Agent——「Chrome 120 on Windows 11」のようなものや、「itel A27 Android」のようなモバイルデバイスの文字列さえ使用します。サーバーからは正当なブラウザアクセスにしか見えません。
• ページ遷移。 SafeLinksは最初のページを読み込むだけではありません。総ページ数に関係なく、資料の約6ページにわたって遷移します。Proofpointも同様の複数ページスキャンを行います。
• リアルなタイミング。 これらのセッションは22〜48秒続きます。粗雑なスクレイパーのように瞬時に通過するわけではなく——素早い閲覧としてもっともらしいタイミングです。
• 合成DOMイベント。 一部のスキャナーはJavaScriptイベント——プログラムによるスクロール、タッチのシミュレーション、さらにはクリックイベント——を発火させ、ユーザーインタラクションの背後に隠された悪意のあるスクリプトをトリガーします。

つまり：Microsoft 365を使用している企業（エンタープライズの見込み客のほとんどが該当）の誰かに資料リンクをメールで送るたびに、本物そっくりの偽の「閲覧」が記録されます。場合によっては2つ——送信者側のセキュリティスタックからのものと、受信者側からのもの。

SafeLinksボットのセッションと実際の人間の閲覧者を並べて比較すると次のようになります：

URLの書き換えが問題をさらに悪化させる

一部のセキュリティツールはリンクを事前スキャンするだけでなく、完全に書き換えます。SafeLinksはメール本文内のすべてのURLをMicrosoft独自のサーバーを経由するリダイレクトに置き換えます（https://nam02.safelinks.protection.outlook.com/...）。ProofpointもURL Defenseの書き換えで同様のことを行います（https://urldefense.proofpoint.com/v2/...）。

受信者が最終的にメール内のリンクをクリックすると、あなたのオリジナルURLを直接開くのではありません。書き換えられたSafeLinksのURLをクリックし、まずMicrosoftのプロキシを経由します——そしてMicrosoftのプロキシはその時点であなたのページを開いて再スキャンします。その後、ユーザーのブラウザをあなたの実際のページにリダイレクトします。

結果：ボットのスキャンと実際のアクセスが同時に発生します。セキュリティスキャナーがデータセンターのIPからあなたの資料を開くのと、実際のユーザーがオフィスからアクセスするのがまったく同じ秒に起こります。ボットと人間の2つの同時セッションが、ほぼ同一のタイムスタンプで生成されます。アナリティクスがそれらを区別できなければ、両方をカウントするか（水増し）、本物をフィルタリングしてしまうリスクがあります（過少カウント）。

これは正しく処理するのが最も難しいシナリオです。配信前のスキャンは単独では容易に識別できます——誰かがクリックする数分前に到着するからです。しかしクリック時の再スキャンは実際のユーザーと同時に到着し、異なるIPから、異なるUser Agentで、正当なセッションと重複する別のセッションを作成します。

なぜ標準的なボット検出では対応できないのか

標準的なアプローチ——既知のボットリストに対するUser Agentのチェック——はリンクプレビューボットやクローラーを検出できますが、メールセキュリティスキャナーは完全に見逃します。SafeLinksは意図的に本物らしいUser Agentを使用しています。フィッシングページがボットを検出すると、実際のユーザーとは異なるコンテンツを表示するため、まさにフィンガープリンティングを避ける目的でそうしているのです。

IPベースのレート制限も役に立ちません。SafeLinksはAzureデータセンターのIPプールをローテーションするため、各スキャンは異なるアドレスから来ます。企業VPN上の正当なユーザーをブロックせずにIPでブロックすることはできません。

ブラウザフィンガープリンティング（canvas、WebGL、フォント列挙）も機能しません。SafeLinksは完全なChromiumベースのブラウザを実行するため、そのフィンガープリントは実際のChromeインストールと区別がつきません。

私たちの解決策：3層の検出システム

私たちは、企業VPNやプロキシを使用する正当なユーザーをブロックすることなく、メールセキュリティスキャナーを検出するシステムを構築しました。

トラフィックが3つの層をどのように通過するかを示します。任意のノードにカーソルを合わせると、その経路を追跡できます：

第1層：User Agentマッチング

シンプルな部分です。受信リクエストを60以上の既知のボットパターン——リンクプレビューボット、検索クローラー、ヘッドレスブラウザ、HTTPクライアントライブラリ——と照合します。リクエストがSlackbotやpython-requestsと名乗れば、即座に拒否します。セッションは作成されません。

これでボットトラフィックの約40%を検出します。簡単な40%です。

第2層：データセンターIP検出

メールセキュリティスキャナーはUser Agentを偽装しますが、どこから実行されているかを隠すことはできません。SafeLinksはAzureデータセンターで稼働しています。ProofpointはAWS上で動いています。これらは既知のホスティングプロバイダーのIP範囲です。

閲覧者が共有リンクを開くと、IPをジオロケーションサービスで確認し、そのIPがホスティングプロバイダーに属しているかどうかを判定します。属している場合、そのセッションはボットとしてフラグが立てられます。

これでメールセキュリティスキャナーのトラフィックの大部分を検出します。午前2時にMicrosoft AzureのIPで「Quincy, Washington」から接続している閲覧者は、あなたの提案書を読んでいる見込み客ではほぼ間違いなくありません。

ここで重要なポイントがあります：これらのセッションをブロックするわけではありません。閲覧記録は作成しますが、ボットとしてフラグを立て、アナリティクスから除外し、通知は送りません。これにより偽陽性の監査が可能になり、ユーザーが調査したい場合にボットセッションを確認するオプションを提供します。

第3層：ジェスチャーベースの人間確認

これが最も重要な層です。シンプルな観察に基づいています：実際の人間はページと物理的にインタラクションします。ボットはしません——あるいは、インタラクションする場合でも、その動作には独特のシグネチャがあります。

セッションが最初にボットとしてフラグ付けされると（第2層により）、それを実際の閲覧としてカウントしません。代わりに、本物の人間の入力を監視します：

監視するもの： マウスの動き、タッチイベント、キーボード入力、スクロール操作。

無視するもの： ページ遷移、リンククリック、ダウンロード。これは直感に反するように思えます——これらは人間の行動を示す強いシグナルのように見えるからです。しかしSafeLinksはスキャンするすべての資料の6ページ以上を遷移します。Puppeteerのようなヘッドレスブラウザはプログラムでボタンをクリックし、ダウンロードをトリガーできます。これらのアクションは容易に偽装できます。低レベルの入力デバイスイベントは、説得力を持って合成するのがはるかに困難です。

3秒間のウィンドウ： ページ読み込み後の最初の3秒間のすべてのジェスチャーを無視します。SafeLinksとProofpointは合成イベントをほぼ即座に——ページ読み込みから500ミリ秒以内に——発火させます。実際の人間は、状況を把握してインタラクションを開始するのに少なくとも3秒かかります。この単一の時間閾値だけで、合成イベントのノイズの大部分を排除します。

マウス移動の分析： 3秒のウィンドウ後にマウスの動きを検出すると、軌跡——最大20回の移動イベントの座標とタイムスタンプ——を記録します。ボットが生成するマウスの動きは幾何学的な経路（完全に直線的な動き、正確な円）をたどるか、単一のイベントを発火させます。人間のマウスの動きには、有機的な加速と減速、わずかなカーブ、微細な補正があります。

本物のジェスチャーが検出されると、セッションはボットからリアルへアトミックに「昇格」されます。その瞬間——その瞬間のみ——閲覧カウントが増加し、通知が送信されます。

タイミングの重要性

システム全体は、特定のレースコンディションを考慮して設計されています：実際のユーザーがリンクを開き、マウスを一度動かし、すぐにタブを閉じた場合、何が起きるか？

確認リクエストはタブが閉じられる前に完了しない可能性があります。ブラウザはナビゲーション時に実行中のfetch()リクエストをキャンセルします。そのため、バックアップとしてsendBeacon()——ページのアンロードを超えて存続する「送りっぱなし」リクエスト用に特別に設計されたブラウザAPI——を使用します。最終的なbeaconは、セッションのエンゲージメント指標とともに確認データを運びます。

サーバー側では、昇格はアトミックです：セッションがまだ昇格されていない場合にのみ成功する単一のSQL更新クエリです。これにより、通常の確認とバックアップのbeaconの両方が到着した場合の二重カウントを防ぎます。

アナリティクスへの影響

実際の影響は大きいものです。エンタープライズ向けの営業チームでのテストでは、資料の見かけ上の閲覧の15〜40%がボットセッションでした——主にSafeLinksとProofpointからのものです。厳格なメールセキュリティポリシーを持つ大企業向けに販売しているチームでは、この割合はさらに高くなりました。

フィルタリングなしの場合：

• 閲覧数が15〜40%水増しされる
• 「最もエンゲージメントの高い」見込み客は、最も強力なメールセキュリティを持つ見込み客かもしれない
• 閲覧タイミングが信頼できない——見込み客が午後2時に資料を見たと思っていたのに、実際はセキュリティスキャナーが午後1時58分に開いていた
• フォローアップのシグナルはノイズである

フィルタリングありの場合：

• すべての閲覧が、実際にあなたのコンテンツを見た実在の人間を表す
• エンゲージメント指標（滞在時間、閲覧ページ数、完了率）が本物の関心を反映する
• 閲覧通知は、ボットが事前スキャンしたときではなく、人間がアクティブにコンテンツに関わっているときにトリガーされる

より広い教訓

メールのセキュリティスキャンはなくなりません——むしろより徹底的になっています。フィッシング攻撃がより巧妙になるにつれ、MicrosoftとGoogleは自動リンクスキャンを拡大しています。ページの読み込みを人間の閲覧の指標として使用するアナリティクスプラットフォームは、ますます不正確になっていきます。

必要なシグナルは「リンクが開かれたかどうか」ではありません。「人間がコンテンツに関わったかどうか」です。そのためには違いを検出する必要があり——その違いはページの読み込みではなく、ジェスチャーにあるのです。