会社情報
採用情報
お問い合わせ
Article

アドフラウド対策は万全？広告詐欺から予算を守る方法

高田晃太郎
アドフラウド対策は万全？広告詐欺から予算を守る方法

複数の調査では、デジタル広告損失に占めるアドフラウドの規模が年次で数十億〜1,000億ドルに達しうると推計されています¹。無効トラフィック（IVT: Invalid Traffic）の割合は媒体や国、買付手法によってばらつきがあり、数％から二桁台に乗るケースが継続的に報告されています²³。例えば日本国内では、2024年の推定アドフラウド被害額が1,510億円、広告トラフィック全体における平均アドフラウド発生率が5.12％と報道されています²。配信の自動化とサプライチェーンの多層化が進んだ結果、広告主は入札の瞬間に相手の真正性を完全には把握できません⁴。実務の報告でも、同一のクリエイティブとターゲティング条件で媒体を跨いだ際、コンバージョンレートの揺らぎをIVTの揺らぎが説明しうるケースが指摘されています³。CTOやエンジニアリーダーができることは明確です。定義を押さえ、データで疑い、プロトコルを機械検証し、運用と契約を設計し直すことです。本稿では、分類と実態、検知の実装、運用・契約の手当、そしてROIの可視化までを一気通貫で解説し、アドフラウド対策の要点を実務に接続します。

なぜアドフラウドは起きるのか：分類と実態

アドフラウドは技術だけの問題ではなく、インセンティブと情報の非対称性から生まれます。入札はミリ秒単位で成立しますが、広告主が受け取る情報は断片的で、かつ複数の仲介事業者を経由します。ここに悪意の介在余地が生まれます。IABやMRCの枠組みでは、不正を大きく**GIVT（一般無効トラフィック）とSIVT（洗練された無効トラフィック）**に分けます⁵。GIVTはクローラーのように判別しやすいトラフィックで、適切にフィルタすべき対象です。SIVTは人間らしさを装うボットやマルウェア、クリックインジェクション、ドメインスプーフィングなど、検知をすり抜ける高度な手口を指します³。ここでの要点は、GIVTは技術的・ルール的に除外しやすい一方、SIVTはシグナルの組み合わせと継続監視が不可欠だということです。

しばしば混同されるのが、**Made-for-Advertising（MFA）**と詐欺の違いです。MFAは人間の閲覧もあるが広告表示最適化のために設計されたサイト群で、詐欺とは言い切れなくても無駄打ちの温床になりやすい領域です。近年の調査では、プログラマティックの支出の相当割合がMFAに流入し、ビューワビリティや有効な到達に劣る報告が出ています⁶⁷。ここから分かるのは、完全な詐欺に限らず「検証が難しい在庫」全体がパフォーマンスを毀損しうるという現実です。

モバイル特有の手口：クリックインジェクションとスパミング

アプリ計測の世界では、クリックとインストールの帰属が金銭と直結します。クリックインジェクションはインストール完了直前に偽のクリックを差し込んで成果を奪うもの、クリックスパミングは大量の無意味なクリックをばらまき偶然のインストールを横取りする手口です⁸⁹。これらはTime-to-Install（TTI: クリックからインストールまでの所要時間）の分布が不自然に短時間側へ偏る、あるいはディープリンクの初回起動率が低い、初日残存（D1）が極端に悪いといった形で表面化します⁸。Webでも、ドメインスプーフィングやピクセルスタッフィング、アドスタッキングといった古典的手口が依然として観測されます¹⁰³。

技術で守る：検知シグナルと実装の勘所

検知の中心は、入札・配信・計測ログを共通キーで連結し、時間・デバイス・供給経路の軸で期待値からの逸脱を見つけることです。入札やインプレッションのID、supply chain（schain）、sellerやpublisherの識別子、ユーザーエージェント、IP、広告スロット、そしてコンバージョン側の計測IDやTTI・リテンションを同一タイムゾーンで正規化し、欠損や重複を取り除きます。**変化点検知（時系列の構造変化を捉える統計手法）やロバストな外れ値検出（極値の影響を受けにくい手法）は有効ですが、その前提として媒体ごとの健全な基準線（ベースライン）**を手に入れることが不可欠です。具体的には、IVT率、ビューワビリティ、CTR、CVR、TTI、コンバージョンラグ、D1/D7残存、LTVなどを媒体・供給経路ごとに平常時で把握しておきます。

例えば、モバイル計測データと配信ログを結合し、短時間のクリック→インストール集中と低い初日残存が同時に出ていないかを確認します。以下はBigQueryでの一例です。データ構造は環境に合わせて置き換えてください。

-- 短TTIかつ低D1残存が集中するサプライソースの検知例
WITH installs AS (
  SELECT
    i.install_id,
    i.device_id,
    i.supply_partner,
    i.publisher_id,
    TIMESTAMP_DIFF(i.install_time, c.click_time, MINUTE) AS tti_min,
    u.retention_d1
  FROM `project.app.installs` i
  JOIN `project.app.clicks` c
    ON i.click_id = c.click_id
  JOIN `project.app.user_retention` u
    ON i.device_id = u.device_id
  WHERE DATE(i.install_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 14 DAY) AND CURRENT_DATE()
), agg AS (
  SELECT
    supply_partner,
    publisher_id,
    COUNTIF(tti_min BETWEEN 0 AND 2) AS short_tti,
    COUNT(*) AS installs,
    AVG(CASE WHEN retention_d1 IS NULL THEN 0 ELSE retention_d1 END) AS avg_d1
  FROM installs
  GROUP BY 1,2
)
SELECT
  supply_partner,
  publisher_id,
  short_tti / installs AS short_tti_ratio,
  avg_d1
FROM agg
WHERE short_tti / installs > 0.35 AND avg_d1 < 0.15
ORDER BY short_tti_ratio DESC;

Webの配信では、ドメインやアプリIDの正当性とサプライチェーンの透明性を機械的に照合することが防波堤になります。ads.txtやapp-ads.txtに買付先が記載されているか、sellers.jsonに事業者情報があるか、**OpenRTBのsupplychain object（schain）**が期待通りの経路を示しているかを定期的にクロールし、差分を監視します¹¹⁴。次のPython例は、候補ドメインのads.txtを取得し、許可されていない取引所経由が混じっていないかを最小限のロジックでチェックするものです。

import requests
from urllib.parse import urljoin

ALLOWED_EXCHANGES = {"exampleexchange.com", "anotherex.com"}

def fetch_ads_txt(domain: str) -> list[str]:
    url = urljoin(f"https://{domain}", "/ads.txt")
    r = requests.get(url, timeout=10)
    r.raise_for_status()
    lines = []
    for raw in r.text.splitlines():
        line = raw.split("#", 1)[0].strip()
        if line:
            parts = [p.strip() for p in line.split(",")]
            if len(parts) >= 3:
                lines.append(parts)
    return lines

def find_unexpected_exchanges(domain: str) -> set[str]:
    entries = fetch_ads_txt(domain)
    exchanges = {e[0] for e in entries}
    return exchanges - ALLOWED_EXCHANGES

if __name__ == "__main__":
    domain = "publisher.example"
    suspicious = find_unexpected_exchanges(domain)
    if suspicious:
        print(f"Unexpected exchanges for {domain}: {', '.join(sorted(suspicious))}")
    else:
        print("OK: exchanges are within allowed set")

なお、ユーザーエージェントの不整合やIPのASN（自律システム）分布の偏り、深夜帯のクリック活性化、ビューワビリティが極端に高いのにコンバージョンが伴わない在庫なども定番のシグナルです。特にASNについてはデータセンター（ホスティング）由来のトラフィック比率が唐突に上がると、ボットオペレーションが疑われます³。これらは単一のシグナルで断定するのではなく、複数シグナルの合意形成で措置に踏み切るのが安全です。

運用で減らす：プレビッド、SPO、契約設計

検知だけでは損失は止まりません。事前ブロック（プレビッド: 入札前に不正やブランド毀損リスクを除外）とサプライパス最適化（SPO: より短く透明な仕入れ経路を選別）、そして契約のリスク移転が効きます。プレビッドでは、**IASやDoubleVerify、HUMAN（旧White Ops）**などの検証ベンダーを入れ、IVTやブランドセーフティの閾値を媒体別に設定して常時ブロックします。ドメイン・アプリIDのアロウリスト運用は手間がかかりますが、MFAや疑義在庫を構造的に遠ざけます⁶。ビューアビリティのフロアやフロードスコアのしきい値は、前章で得たベースラインを起点に、配信量を確保できるぎりぎりの水準から詰めていくと、パフォーマンスの落ち込みを避けつつIVTを圧縮できます。

SPOでは、同一の在庫に複数SSP経由でアクセスしないよう経路を整理します。supplychain objectに基づく重複経路の棚卸しと、sellers.jsonでの再販売者（reseller）比率の縮小が第一歩です¹¹⁴。経路が短いほど、テイクレートの透明性が上がり、偽装の余地が減ります。あわせて、SSPの評価指標をIVT率・有効到達・収益効率で並立させ、一定期間で改善しないパートナーは凍結するルールを設けます。媒体の掲載面では、インビュー実測やアテンション指標を併用し、単純なクリックレートだけで優遇しない仕組みにすると、不正クリックの誘因が削がれます。

契約では、MRC準拠のIVT定義に沿ってポストビッド精査による控除（make-good: 不正在庫分の返金・補填）を明文化し、返金・差し替え・バリュークレジットの優先順位と期間を取り決めます⁵。監査に必要なログ項目（リクエストID、タイムスタンプ、IP、UA、publisher、seller、schain、実測ビューワビリティなど）を保存期間と粒度まで含めて契約要件にすると、後追いの証明が容易になります。アフィリエイトやCPI型のモバイルでは、TTI分布とD1残存をもとにしたクリア条件を追加し、不自然な集中が見られる配信は自動停止と遡及控除の対象とするのが実務的です。

ベンダー評価と継続モニタリングの型

月次の媒体評価は、単一のKPIに寄りかかると歪みます。IVT率の低下、純CV（IVT除外後）単価の改善、D1/D7残存の維持、ブランドセーフティインシデントの減少という複合で判断します。変化点検知で異常を捉えたら、まずは限定的にアロウリストを絞り、プレビッドの閾値を上げ、供給経路を1本に集約して挙動を再観測します。これで改善が続くなら常設化し、効果が薄ければ別因を疑います。改善サイクルを回すたびに契約の控除条項とログ提供要件を強化すると、再発確率が下がっていきます。

いくら守れたか：ROIを数式で可視化する

経営判断に持ち込むには、削減効果を定量で示すことが重要です。単純化したモデルでも、節減額 = 総媒体費 × 現状IVT率 × 改善率と表せます。たとえば年間の媒体費が5億円、監査でIVT率が8％と観測され、対策でその半分を削減できたとすると、5億円 × 0.08 × 0.5 = 2,000万円の直接節減が見込めます。さらに、IVTの圧縮により純CVの比率が上がれば、同予算での有効獲得数の増加、あるいは目標獲得数を維持したままの予算圧縮が可能になります。LTVモデルに接続すれば、有効顧客獲得の増分LTVも上乗せできます。

実務では、対策の前後でIVT除外後のCPA/ROAS、リテンション/ARPU、ファネルの歩留まりを同一期間・同一アトリビューション設定で比較します。媒体別・供給経路別に差分を出し、節減額と増分利益の合算から、検証ベンダー費用や実装・運用の人件費を差し引くと、純効果が算出できます。ここまで数式とログで示せれば、経営は次の投資判断を下しやすくなります。

90日で整える改善ロードマップ

最初の30日間は、ログ定義の統一とデータ配管の健全化に集中します。アドサーバ、DSP、SSP、MMPから必要なフィールドを取り込み、IDとタイムゾーンの整合を取り、ベースラインを測ります。次の30日間で、プレビッド検証とアロウリストの導入、SPOによる経路の短縮、契約条項の更新に踏み込みます。最後の30日間で、異常検知の自動アラートを運用に組み込み、媒体評価の定例会を立ち上げ、改善の効果をROIとして四半期報告に組み込みます。段取りを時間軸で刻むと、組織の合意が進み、摩擦なく恒常運用へ移行できます。

より詳しい実装の背景や関連テーマは、ads.txt / sellers.json 実装ガイド、MFAサイトを見分ける技術観点、マーケデータ基盤の設計原則も参考になります。

まとめ：疑う勇気を仕組みに変える

アドフラウドはゼロにはできませんが、仕組みで限りなく近づけることはできます。定義を押さえ、シグナルを設計し、プロトコルを機械検証し、プレビッドとSPO、契約で出口を塞ぐ。これらをデータ基盤の上で回し続ければ、予算は守れます。大事なのは一度の監査ではなく、ベースラインと例外の差を毎日測り続ける習慣です。

いまの配信ログと計測データで、すぐに検証できる箇所はどこでしょうか。最初の小さな改善は、TTI分布の確認かもしれませんし、ads.txtの差分監視かもしれません。あなたのチームが今日着手できる一手を選び、次の四半期にROIとして可視化してみてください。仕組み化の第一歩が、広告の生産性を恒常的に底上げします。

参考文献

  1. Business of Apps. Ad fraud statistics. https://www.businessofapps.com/ads/ad-fraud/research/ad-fraud-statistics/
  2. FNNプライムオンライン. 2024年、日本国内の推定アドフラウド被害額は1,510億円、平均発生率は5.12％（報道記事）. https://www.fnn.jp/articles/-/871540
  3. DoubleVerify. The fight against ad fraud: A breakdown for publishers. https://pub.doubleverify.com/blog/the-fight-against-ad-fraud-a-breakdown-for-publishers/
  4. Index Exchange. Understanding supply chain transparency (ads.txt, sellers.json, SupplyChain). https://www.indexexchange.com/uk/index-explains/understanding-supply-chain-transparency/
  5. Integral Ad Science. GIVT vs SIVT: What’s the difference? https://integralads.com/insider/givt-vs-sivt-invalid-traffic/
  6. Search Engine Land. Brands are wasting ad dollars on made-for-advertising sites: Adalytics. https://searchengineland.com/brands-ad-dollars-made-for-advertising-adalytics-438298
  7. Pixalate. Q2 2024 Regional Made for Advertising (MFA) Websites Ad Spend Report. https://www.pixalate.com/blog/q2-2024-regional-made-for-advertising-mfa-websites-ad-spend-report
  8. AppsFlyer. Click injection. https://www.appsflyer.com/glossary/click-injection/
  9. Singular. Click spamming. https://www.singular.net/glossary/click-spamming/
  10. Pixalate. Ad fraud/IVT detection: App and domain spoofing. https://www.pixalate.com/blog/ad-fraud-ivt-detection-app-domain-spoofing
  11. Google Ad Manager Help. SupplyChain object (schain) overview. https://support.google.com/admanager/answer/10368261?hl=en