Technical Brief

ボット検知ロジック仕様書

AdFraud Shield の検知エンジンの完全仕様。プロトコルレベルから行動分析まで、5 層 10 シグナル（うち 7 つが本番稼働）を構造的に開示します。

最終更新: 2026-Q2

1. 設計思想

従来のボット対策ツールの多くは User-Agent と IP ブラックリストに依存しています。これらは攻撃者にとって偽装が容易で、住宅プロキシ + 改造 UA を使えば素通りされます。

AdFraud Shield は「偽装が技術的に困難」なシグナルを優先します。例えばランダム化された Canvas/WebGL レンダラは headless Chrome を露呈させます。（エンジンは TLS JA4 や TCP TTL などエッジ由来シグナルも実装していますが、これらはネットワークエッジ層が必要で、現行のダイレクト Cloud Run 構成では非稼働です。）

本仕様書は、各シグナルが「なぜ偽装困難か」を技術的に説明します。検知の重み (weight) と閾値は競合対策のため非開示としますが、シグナル構造とロジックの「思想」は完全公開します。

2. 5 層 10 シグナル構造

受信したクリックは 5 層のフィルターを通過します。各層内のシグナルは独立に評価され、リスクスコアリング段階で重み付き合算されます。

完全な透明性のために開示します。これらのシグナルのうち 7 つが現在のデプロイで稼働しています。「エッジ依存」と記した 3 つ（TTL / TLS JA4 / HTTP/2）は、ネットワークエッジ層から得るデータを必要とします。当社のデプロイはエッジプロキシを挟まないダイレクトな Cloud Run 構成のため、この構成では収集していません。隠さず、ありのまま開示します。

Layer 1: ネットワーク (Network)

TCP/IP パケットが偽装する難度は最も高い層。OS カーネルの実装挙動から偽装を見抜きます。

UA/OS 矛盾検出

User-Agent の主張 OS と TCP TTL から推定する OS を照合。Windows UA + TTL=64 (Linux 系) は強い不一致シグナル。

TTL ホップ解析

エッジ依存

TCP TTL の初期値 (Windows=128, Unix 系=64, Cisco=255) からホップ数を推定。ホップ数 19 以上はプロキシ経由の可能性が高い。

Layer 2: プロトコル (Protocol)

TLS と HTTP/2 のハンドシェイクは実装ごとに固定順序を持つため、強力な指紋になります。

TLS JA4 フィンガープリント

エッジ依存

ClientHello の 暗号スイート・拡張・楕円曲線順序から JA4 ハッシュを生成。Puppeteer / Selenium / curl / Go / Node.js などの既知パターンと比較。

HTTP/2 SETTINGS フレーム

エッジ依存

HTTP/2 の SETTINGS パラメータ順序や WINDOW_UPDATE のタイミングは実装ごとに異なります。Go net/http や Python httpx は Chrome と異なる順序を送るため即時識別可能です。

Layer 3: ブラウザ (Browser)

JavaScript 経由で取得するクライアント環境のフィンガープリント。

Client Fingerprint 解析

navigator.webdriver === true は確定 bot シグナル。Canvas / WebGL レンダラー文字列が SwiftShader・Mesa OffScreen・llvmpipe (ヘッドレス GPU 実装) に一致すれば bot 確定。User-Agent と navigator.platform の OS 矛盾もチェック。

Layer 4: アイデンティティ (Identity)

IP の素性 (素人がデータセンターから出てくることはない) と地理的整合性。

データセンター IP 判定

AWS/GCP/Azure/DigitalOcean/Linode/Vultr/OVH/Hetzner 等の既知クラウド CIDR レンジ (約 140 ブロック) との照合。バイナリサーチで O(log n) 判定、外部 API 依存なし。

ジオマスキング検出

ブラウザの Intl.DateTimeFormat タイムゾーンと IP の国コードを比較。データセンター IP が「東京」を主張する瞬間に矛盾を検出。言語互換性チェックで旅行者・VPN 業務利用の偽陽性を軽減。

Layer 5: 行動・インタラクション (Behavior)

ページ滞在中の振る舞い。bot は人間的に振る舞う努力をしないことが多い。

重複クリック検知 (頻度)

IP + フィンガープリント複合キーで 5 分間アクセス数を Redis でカウント。CGNAT / 企業 NAT の偽陽性を避けるため IP 単体ではなく IP+FP で判定。

行動ハニーポット

DOM に不可視のリンク・フォーム要素を埋め込み、これに触れたセッションを誤検知ゼロで bot 確定。スクレイパーは構造から拾われます。

ユーザー行動分析

滞在時間・スクロール量・タッチ/マウス操作を visibilitychange イベントで送信。即離脱 (< 1 秒) や瞬間フルスクロール (< 2 秒で 100%) を検知。

3. 動的スコアリングとクロスレイヤー多重検証 (Convergence)

各シグナルは 0-100 のスコアを返し、リスクスコアリングモジュールが重み付きで合算します。重み (weight) と各シグナルの詳細スコア表は競合対策のため非開示としますが、判定の流れは以下の通りです。

総合スコアによる判定:

  • 0-30: human (除外しない)
  • 31-70: suspicious (除外候補)
  • 71-100: bot (Google Ads 除外リストへ自動追加)

Cross-Layer Convergence

単一のシグナルが高得点でも即座に bot 確定とはしません。複数の層 (例: ネットワーク層 + プロトコル層) で独立に矛盾が検出された場合に「Convergence」として確度を上げる仕組みを採用。これにより「単一シグナルだけ偽装してすり抜け」を阻止します。

4. Human-First Safeguards (誤検知ガード)

ボット検知の宿命として、誤検知 (False Positive) をゼロにすることは不可能です。AdFraud Shield は「誤って除外された IP」を能動的に検出・是正するシステムを内蔵しています。

24 時間 cooldown

一度 Google Ads 除外リストへ追加された IP は 24 時間後に自動再評価。動的 IP の再割り当て (キャリア NAT 等) を考慮した設計です。

7 日 human/bot 比率ガード

過去 7 日間で human 判定が bot 判定を上回る IP は、たとえ瞬間的に bot スコアを記録しても除外候補から自動排除。サンプル数 5 件以上で発動。

計測方法論 (Methodology)

FP rate は「除外された IP のうち、後続 7 日で human 判定が bot 判定を上回ったもの」を分子とし、除外総数を分母として算出します。

直近 30 日 (2026-Q2) の本番運用データ: 除外 IP 総数約 1,000 件、上記 FP 定義に該当するものは 1 件未満、率にして 0.1% 未満。本数値は四半期ごとに更新します。

事例: パイロット顧客での FP guard 自動是正 (2026-04-28)

某大型 EC ブランド (パイロット顧客) で、運用初期に Google Ads 除外リスト top 500 件中 11% (55 件) の汚染 (人間優位 IP) が発生しました。導入された 7 日 human/bot 比率ガードが 24 時間以内に汚染 IP を全件特定、自動是正により 0% へ復旧。手動運用では発見困難だったケースを、システム側の能動的検出で防いだ事例です。

5. コンプライアンスとパフォーマンス

個人情報保護法 (APPI) 準拠

個人を識別する情報 (氏名・メールアドレス・電話番号) は一切収集しません。フィンガープリント・IP・User-Agent は技術的識別子として 7 日間のみ保持し、自動削除します。

Cookieless 設計

JS タグは Cookie を一切セットしません。ファーストパーティ・サードパーティ Cookie 依存ゼロ。Apple ITP や Google プライバシーサンドボックスの将来の規制変更にも影響を受けません。

パフォーマンス

JS タグは 10.3 KiB minified (gzip 圧縮後 約 4 KB)、async 読み込みで LCP / FCP / TTI への影響は計測誤差レベル。Lighthouse スコアの差分ほぼゼロ。

データ保持期間

raw データ (visits / verdicts) は 7 日。集計データ (daily_site_stats / daily_signal_stats) は永続。除外 IP リストは最終検出から 30 日で TTL 失効。