アドフラウド（広告詐欺）はいたるところに存在します。最近のレポートによると、2022年だけでもデジタル広告詐欺によって680億ドルが失われると予測されています。
詐欺師の懐に多額の資金を流し込んでいることに未だ気づいていない企業がある一方で、この詐欺問題に対処するための解決策に取り組んでいる企業もあります。その1つが、2017年にIABが発表した「ads.txt（アズテキスト）」ファイルです。
この記事では、ads.txtとは何か、その仕組み、そしてなぜデジタル広告詐欺の最大の問題をこれだけでは解決できないのかについて解説します。
ads.txtとは？
2017年5月にIAB Tech Labが発表した「Authorized Digital Sellers（認定デジタル販売者）」プロジェクトは、ドメインなりすましや不正なインベントリ（広告枠）のアービトラージなど、様々なアドフラウドへの対策を目的としています。
ads.txtは、特定のドメインにおいて、どの企業がデジタル広告枠を販売することを許可されているかという情報を含むシンプルなテキストファイルです。ドメインのウェブマスターのみが作成・修正できるため、このファイルの情報は有効かつ信頼できるものとみなされます。
また、不透明になりがちなプログラマティック広告のエコシステムにおいて、透明性を高める役割も果たします。パブリッシャー（媒体社）が自社に代わって広告枠を販売することを許可した企業を公に宣言できる柔軟な手段を提供することで、広告枠のサプライチェーンを可視化し、他人の広告枠を勝手に販売する詐欺師から広告主を守ります。
ads.txtが解決する課題
ads.txtは、主に次の2つの問題に対処します。
ドメインなりすまし：被害者のデバイスにインストールされたマルウェアや、悪意のあるオンサイトスクリプトを使用して、広告タグ内のURLを偽装する手法です。その結果、広告取引所などのプログラマティックプラットフォームは、ユーザーが正規のURLにアクセスしたと誤認しますが、実際には広告は別の信頼性の低いWebサイトに表示され、そのほとんどがボットによってのみ閲覧・クリックされます。
インベントリ・アービトラージ：パブリッシャーからインプレッションを購入し、第三者がそれをパッケージ化してより高い価格で転売する手法です。
詐欺師は、コンテンツが全くないか、またはニューヨーク・タイムズのような信頼性の高い大手パブリッシャーからコンテンツを無断でコピーした偽のWebサイトを作成し、そこに偽のボットトラフィックを送り込んで広告の閲覧数を増やし、さらには広告をクリックさせます。そして、広告タグ内のURLを変更して、あたかもニューヨーク・タイムズのドメイン上で広告が配信されたかのように見せかけます。詐欺師は偽サイトに広告を掲載することで広告プラットフォームから報酬を受け取り、広告主はニューヨーク・タイムズのサイトに広告が表示されたと信じ込まされます。
明確にしておきますが、ads.txtはボットによる詐欺を解決するものではありません。主にドメインのなりすましや偽の広告リクエストを減らすことを目的としています。
ads.txtの仕組み
パブリッシャーは「ads.txt」という名前のファイルを作成し、ルートドメインの直下に配置します。このファイルには、パブリッシャーが提携し、広告枠を管理する可能性のあるサプライサイドプラットフォーム（SSP）、アドエクスチェンジ、アドネットワークなどの認定デジタル販売者に関する情報が記載されています。
これが具体的に何を意味するのか、nytimes.comのads.txtを例に見てみましょう。
各行は、nytimes.comの広告枠を管理することを許可されたパートナーを表しており、最大4つのフィールドで構成されています。例えば、20行目には次のように記載されています。
google.com, pub-1793726897772453, DIRECT, f08c47fec0942fa0
google.com → 広告システムのドメイン名（必須）
このフィールドは、パブリッシャーが広告枠を販売するために使用するプラットフォームのドメインを示します。ニューヨーク・タイムズは、Google、Amazon、Yahoo、AppNexusを含む少数のパートナーのみを使用していることがわかります。
pub-1793726897772453 → パブリッシャーのアカウントID（必須）
パブリッシャーアカウントIDは、特定のパートナー（この場合はGoogle）に対するパブリッシャーのアカウントIDであり、RTB（リアルタイム入札）での入札時に広告枠の真実性を検証するために使用されます。
DIRECT / RESELLER → 関係のタイプ（必須）
このフィールドには、「DIRECT（直接）」または「RESELLER（販売代理店）」のいずれかの値が入ります。パブリッシャーが広告枠を販売するためにベンダーと直接取引しているのか、あるいは他の企業（アドネットワークやデジタル広告代理店など）に自社に代わって広告枠の管理を委託しているのかを示します。
f08c47fec0942fa0 → TAG ID（任意）
このオプションのフィールドは、業界団体「Trustworthy Accountability Group（TAG）」の認証局内でパートナーを識別するTAG IDを示します。TAG IDは、グローバルにユニークな大文字小文字を区別しない16文字の16進数文字列で、パートナーにリクエストして取得できます。
# comment → コメント（任意）
パブリッシャーによっては、ハッシュタグの後にコメントを追加することもあります。ハッシュタグ以降の情報はクローラーには使用されず、ファイルが大きくなったときにパブリッシャーやウェブマスターが管理しやすくするためのものです。例として、businessinsider.com/ads.txtをご覧ください。一部の行に、パートナーが管理する広告フォーマットがコメントとして追加されています。
パブリッシャーが自社ドメインでの広告枠販売を許可するパートナーの一覧を公開すると、デマンドサイドプラットフォーム（DSP）はドメインとads.txtファイルをクロール（巡回）します。アドエクスチェンジからDSPにOpenRTB入札リクエストが送信されるたびに、DSPはドメインとパブリッシャーIDをads.txtの情報と照合します。情報が一致すれば入札が行われ、一致しなければ入札は行われません。
技術的な仕様や具体的な事例については、IAB TechLabによる公式のads.txt仕様書、またはads.txt関連リソースの概要をご覧ください。
ads.txtファイルの作成方法
ads.txtファイルの作成は非常にシンプルで簡単です。必要なのは、.txtファイルを作成できるテキストエディタと、パートナーやネットワークからの情報だけです。
ステップ 1: 必要な情報をすべて集める
実際のファイルを作成する前に、提携しているすべてのベンダー、アドエクスチェンジ、アドネットワークから情報を集める必要があります。これには、ドメイン名、そのパートナーにおける自社のパブリッシャーID、そして直接契約（DIRECT）か代理販売（RESELLER）かという関係性が含まれます。
より厳密に管理したい場合は、各パートナーからTAG IDを請求することもできます。パートナーを検証するには、TAGレジストリを使用して提供されたTAG IDを検索します。TAGレジストリでは、提供されたTAG IDが企業名と紐づいているか、その企業がレジストリに登録されているかをリアルタイムで確認できます。
ステップ 2: .txtファイルを作成し、「ads.txt」と命名する
情報をすべて集めたら、テキストエディタを開き、指定のフォーマットで情報を貼り付けます。各フィールドはカンマ（,）で区切り、パートナーごとに改行してください。ファイルを保存する際は、必ず「ads.txt」という名前の.txtドキュメントとして保存します。
無料のテキストエディタの例：
メモ帳（Windowsに標準搭載）
テキストエディット（macOSに標準搭載）
ステップ 3: ads.txtを検証する
ファイルをWebサーバーにアップロードする前に、内容、読みやすさ、構文に誤りがないか検証することをお勧めします。手動で行うこともできますが、以下のツールを使用すると簡単です。
どちらのツールも、スペルミス、無効なドメイン名、誤った正規ドメイン名などの潜在的なエラーがないかをチェックしてくれます。
ステップ 4: ads.txtファイルをルートドメインにアップロードする
最後のステップは、ファイルをルートドメインにアップロードすることです。ads.txtはルートドメインでのみ機能し、サブドメインやフォルダ配下では機能しないためご注意ください。
アップロード後、自社ドメインの末尾に「/ads.txt」を付けてアクセスし（例: yourdomain.com/ads.txt）、ファイルの内容が正しく表示されれば設置完了です。
パブリッシャーと広告主におけるads.txtのメリット
パブリッシャーがドメインにads.txtを導入する最大のメリットは、不正な広告枠の購入や偽の広告リクエストを大幅に防止できる点です。
また、広告主にとっても、販売者を検証し、偽の広告リクエストへの無駄な予算消化を防ぐことができるというメリットがあります。
さらに、広告システム全体の透明性が高まることも大きなメリットです。ads.txtにより、どの企業がどのドメインで広告枠を販売する権限を持っているかがオープンになります。
パブリッシャーにおけるads.txtの普及状況
2017年の公開当初、ads.txtの普及は非常に緩やかでした。しかし、Googleが新しい基準をサポートし、DoubleClick Ad ExchangeとAdSenseにおいて未認定の広告枠をオークションから除外することを発表したことで、多くのパブリッシャーが自社ドメイン用のads.txtファイル作成に踏み切りました。
現在では、大手1,000ドメインの45%以上がこの基準を導入しています。
モバイルアプリ向け「app-ads.txt」
2017年の最初のads.txtはWebサイト上の広告を対象としていましたが、モバイル広告詐欺も増加し続けました。これを受けて、IAB TechLabは2019年に「app-ads.txt」を公開しました。これは、モバイルアプリ内のアドフラウド対策にも対応できるように既存の仕様をアップデートしたものです。
この新しい基準もGoogleやAdMobによって迅速に採用され、現在ではWebサイト向けのads.txtよりも高い導入率を誇っています。Google Playのトップ1,000アプリの68%がapp-ads.txtを導入していますが、AppleのApp Storeのトップ1,000アプリでは42%にとどまっています。
app-ads.txtについては、別の記事で詳しく解説する予定です。それまでは、IAB公式ウェブサイトの最新の仕様書およびアプリへの実装手順をご参照ください。
ads.txtの脆弱性・懸念点
ads.txtファイルの狙いとメリットを見てきましたが、同時にその潜在的な脆弱性にも目を向ける必要があります。このシステムには詐欺師に悪用される可能性のある隙があり、また、多くのシステムと同様に「人為的ミス」が最大の懸念材料となっています。
パブリッシャーによる管理・運用の不足
ads.txtファイルは、一度作成すれば終わりというものではありません。パブリッシャーはリストを積極的に把握し、定期的に更新・確認する必要があります。
代理で広告を販売する権限を持つパートナーが増えるにつれて、ads.txtファイルは肥大化していきます。これは管理を困難にするだけでなく、誰が実際に販売を許可されているのかを正確に把握できなくなる原因になります。
新しいパートナーと契約するたびにその情報をファイルに追加しなければならず、同様に契約が終了したパートナーの情報は削除しなければなりません。そうしないと、とっくに契約が切れたパートナーが（ads.txtの記述上は）依然として広告枠へのアクセス権を持ち続けることになります。この状況は悪意のあるパートナーに悪用されやすく、偽の広告リクエスト問題へと逆戻りしてしまいます。
先ほどのニューヨーク・タイムズの例では、現在（2021年6月時点）21社の認定パートナーが登録されています。すべてのパートナーと直接の取引関係（DIRECT）を結んでいるため、第三者が無断で広告枠を転売することはできません。
一方で、ESPN.comを見てみると驚くほどの規模です。なんと460社ものパートナーがリストアップされており、その半分以上がリセラー（販売代理店）となっています。
404Bot — リセラーの監視不足を突く手口
2019年の初め、新たな詐欺手法である404Botが世間を騒がせました。詐欺師たちは、大手パブリッシャーのads.txtで「認定リセラー」として登録されているアドネットワークにアカウントを開設し、ads.txtの仕組みを悪用しました。
肥大化したads.txtファイルが十分に管理されていない隙を突かれ、詐欺師たちは数ヶ月間で1,500万ドルから8,000万ドルをだまし取ったと推定されています。
その手法は非常にシンプルでした：
詐欺師は、大手パブリッシャーの認定リセラーとなっているアドネットワークにアカウントを作成する。
次に、パブリッシャーのサイト上に存在しない架空のURL宛てにボットトラフィックを送信する。このURLは404エラー（ページ未検出）を返すため、「404Bot」と名付けられました。HTTPステータスコード404は、サーバーとの通信は確立されたものの、要求されたファイルが見つからなかったことを示します。
しかし、これらの架空のURLには広告コードが埋め込まれており、通常通りに実行される仕様になっていました。
結果として詐欺師は、プレミアムパブリッシャーの広告枠を正常に販売したとして、アドネットワークから報酬を受け取っていました。
この手法の大きな特徴は、すべてのレポートにおいてURLが正常であるかのように見える点でした。実際にそのURLにアクセスしても「ページが見つかりません」と表示されるだけであり、「記事が削除されたのだろう」と思われるため、詐欺の発覚を遅らせる完璧な隠れ蓑となっていました。
パブリッシャーとしては、ads.txtファイルの内容を厳しく監視し、リセラーの登録を極力避けることが不可欠です。404Botの被害に遭ったドメインに共通していたのは、ads.txtファイルが膨大で、多数のリセラーが含まれていた点です。リセラーが多いほど、詐欺の被害に遭う確率は高くなります。
ads.txtへの登録を狙うソーシャルエンジニアリング
ads.txtの登場に伴い、パブリッシャーのもとには、デジタルマーケティング代理店を装って認定リセラーとしての登録を求める詐欺師からのリクエストが増加しました。その手口は以下のようなものです。
詐欺師は大手パブリッシャーに連絡を取り、彼らのads.txtへの登録を要求します。その際、「過去にリセラーとして貴社の広告枠を販売した実績がある」などと偽ります。ある詐欺業者は短期間のうちに60以上のパブリッシャーのリストに入り込むことに成功しました。パブリッシャー側が申請内容を適切に検証せず、特に初期段階において「収益を失いたくない」という懸念から、簡単に許可を出してしまったためです。
結末は容易に想像がつくでしょう。リストに入り込んだ詐欺師は、プレミアムパブリッシャーの広告枠を高値で販売し、ボットトラフィックを使って不正に利益を上げました。
このケースはads.txt自体の技術的な脆弱性ではなく、人間の心理的な隙を突く「ソーシャルエンジニアリング」が悪用された例です。
ads.txtは無効なトラフィックやクリック詐欺を防げない
この記事では、ads.txtとは何か、その仕組み、そして脆弱性について解説してきました。ドメインのなりすましを防ぐという点において、ads.txtは確かに正しい方向への大きな一歩ですが、一つ重要な点を見落としてはなりません。それは、**ads.txtは無効なトラフィック（IVT）やクリック詐欺から広告予算を守ることはできない**ということです。
広告が正規のWebサイトに正しく表示されたとしても、それを本物の人間が見ているか、クリックしているかまでは保証されません。ads.txtは「認定されたパートナーを通じて広告が表示されていること」を保証するものであり、「本物の人間が広告に反応していること」を保証するものではありません。
そのため、広告がプレミアムなWebサイトに配信されていたとしても、依然としてボットによる無効なトラフィックや不正クリックが発生し、広告予算が浪費されるリスクは残ります。
これを裏付ける懸念すべきデータとして、2019年末のレポートでは、ads.txtを導入しているWebサイトは、導入していないサイトに比べて無効トラフィック（IVT）が約10%多いという結果が示されています。
この課題を解決するためには、不正なボットを検知し、広告予算を消耗させる無駄なクリックを防止する「アドフラウド対策ツール」の導入が必要です。
今すぐ「fraud0」の7日間無料トライアルに登録し、その効果をご自身でお確かめください。契約の縛りはなく、クレジットカードの登録も不要です。
