話題の「ads.txt」とは？設置方法やアドセンスの仕組みを解説

広告主・メディア・プラットフォームそれぞれの立場で違うads.txtへの対応

筆者が所属するDataSignが調査したところ、国内でads.txtを設置しているインターネットメディアは、2017年の12月12日時点で約20％でした。

2017年10月に大手のブログシステム提供会社が誤ってads.txtを設定したため、そのブログシステムを使っているメディアに対しGoogle AdSenseから警告が出て話題になるなど、運用に関しても混乱が起きるという出来事がありました。

ここでは、オンライン広告におけるRTBの仕組みからads.txtについて解説しますが、後半は技術的な話も含みます。全員が技術的な記述方法を身に付ける必要はありません。

• 広告主アドフラウドに対してads.txtを正しく使って対策している媒体・プラットフォームを選ぶ
• 媒体社メディアレップやプラットフォーム、その他中間業者から言われたままではなく、ads.txtチェックツールなどを用いて確認を行う
• プラットフォームSSPはads.txtの設置方法・内容についての正しい情報提供を行い、DSPはads.txtへの対応方法や対応状況を公開する

以降は見出しに対象者を表すマーカーを表示しています。自分に必要な部分を読んでください。

広告主媒体社プラットフォーム
ads.txtの前提： プログラマティック広告の現状と経緯

ads.txtはなぜ必要なのかを解説する前に、現状のオンライン広告（プログラマティック広告）がどのような経緯・仕組みで成り立っているのかを簡単に説明します。

オンライン広告は、オンラインメディアの広告枠を広告主が買うことで成り立っています。基本的な構造はテレビや雑誌等の他の広告媒体と変わりません。

たとえば最も古くから行われているオンライン広告のひとつとして「トップページの一番上に表示されるバナーを1週間掲載するためには1000万円」といった広告メニューがあります。

このような伝統的な期間保証型の広告の場合は、メディア自身が広告枠を管理しているので、「どの広告案件のどんな広告素材がどこの枠にいつ掲載されているのか」が明確で、広告主も掲載を直接確認でき、広告費の支払先も明確です。このような広告取引は現在も行われており「純広告」と呼ばれています。

しかし、この仕組みだけではメディア自身で広告案件を獲得してくるだけでは限界があります。マネタイズのためにメディアのトップ、右上、右下、記事内、記事下など広告枠の場所もどんどん増えていくため、次第にメディアレップやアドネットワーク業者が間に入って広告取引を仲介する仕組みに変わっていきました。

すると、成果を上げるためによりターゲティングしようとする動きが出てきます。広告主側も、広告効果を最大化するためのメディアの選定やコンテンツの内容に合わせた広告、訪れた人の属性（性別・年齢・趣味嗜好など）に合わせた広告を掲載しようとすると、とても人の手では運用しきれません。そこでより適切にターゲティングした広告の自動取引（オークション）をリアルタイムに行うプログラマティック広告が誕生しました。

RTB（Open Auction）の仕組み

プログラマティック広告では、さまざまな広告の取引形態を組み合わせて最適に運用することを目指しています。広告主が予算やターゲティングを指定し、メディアが自分の販売したい広告枠を指定するだけで、SSPやAd Exchange、DSPといった業者がそのメディアに訪れた読者に合った広告を自動的に選別してリアルタイムに掲載してくれます。この仕組みをRTB（Real-Time Bidding）と呼びます。

RTBの基本的な仕組みを図1に示しました。

図1：RTBの仕組み。ユーザーの訪問をきっかけにSSPがDSPに広告をリクエストする

1. オンラインメディアに読者が訪れる
2. SSP/Ad Exchangeを介して、どのページに読者が訪れたかという情報が各DSPに送信される
3. それぞれのDSPで、ページのURL／枠の位置／ページのコンテンツ／訪れた読者の過去の行動履歴／属性情報（性別・年齢・趣味嗜好など）などをもとに各社独自のアルゴリズムを用いて、いくらで広告を出したいかを決定する
4. SSP/Ad Exchangeが最も入札額の高いDSPからの広告で落札する
5. 落札した広告主の広告をメディアに掲載する

RTBでは、ユーザーがアクセスするごとにこうした処理が瞬時に行われています。このような仕組みで、効率的に広告枠のマネタイズを行いたいメディアのニーズ、広告の掲載を効率的に行いたい広告主のニーズを満たし、急速に広がっていきました。

RTBを悪用したアドフラウド（広告詐欺）の出現

しかしそんなRTBにも良くない一面がありました。いわゆる広告詐欺（アドフロード、アドフラウド）です。

RTBではSSPやAd Exchange、DSPといった業者が自動的に広告と広告枠をマッチングします。そのため広告主側で実際に広告がメディアに掲載されていることを確認するのは難しく、メディア側もどんな広告が掲載されているかをすべて把握することはできません。

そのため、実際に広告が掲載されているかのように装って、広告費をだましとる詐欺が横行しています。

その手法を表したのが図2です。

図2：RTBの仕組みを悪用したアドフラウドの例。赤文字が、悪人がウソをついている部分

先ほどの図1と見比べてみてください。悪意を持った第三者が、広告枠を販売するメディアになりすましています。

図2の例では、悪意を持った第三者が、「自分がWeb担当者Forumだ」と偽り、②の情報を改ざんして、広告のリクエストを送信します。DSPはその情報を信じて入札し、広告がニセのサイトに掲載されます（③④⑤）。

悪意のある第三者は嘘だとばれないように、その広告をたまにクリックしたり、動画を再生したりという偽装も行います。DSPは成果に応じて広告費をSSPに支払い、SSPはアカウントIDの情報に従って、お金をメディアに分配します。

このSSPのアカウントIDが悪意を持った第三者のものであることから、不正な収入を得られるという構造です。

「メスボット」と呼ばれるアドフラウドボットは、この手法で1日に300～500万ドル（3.27億～5.45億円）稼いでいたという調査結果があります。

広告主媒体社プラットフォーム
ads.txtはどうやってアドフラウドを防ぐのか

SSPはアカウントIDの情報に従って収入を分配するので、「このSSPのアカウントIDが適切なものかどうか」を確認できれば、前項のような不正は防げます。SSPのアカウントIDが適切なものかを確認するための仕組みがads.txtです。

図3：ads.txtによるアドフラウドの防止

図3に示すように、Web担当者Forumがあらかじめ、自社メディアにads.txtを設置して、使っているSSP/Ad ExchangeとそれぞれのアカウントIDをそこに記載しておくことで、悪意を持った第三者が「自分はWeb担当者Forumだ」と偽ったとしても（②）、DSPがWeb担当者Forumのads.txtを確認すれば（③）、アカウントIDが一致しないために偽物であることがわかります（④）。結果として入札も行われないため、不正に収入を得ることもできなくなります。

仮に、悪意を持った第三者が図3 ②のSSP1 アカウントIDを正式なads.txtに書かれているアカウントIDと同じものにして広告のリクエストを送信したとしても、その収益は第三者のものにはならず本来のメディアに分配されるため、広告詐欺を行う金銭的なインセンティブがなくなります。

このように簡単な仕組みでアドフラウドを防止できることから、いま、ads.txtは世界中で実装が進んでいます。

媒体社プラットフォーム
ads.txtの設置方法（※2018年1月時点のads.txt Version 1.0.1）

ads.txtは簡単に設置できますが、その設置方法や内容の書き方に細かい決まりがあるため、その決まりに添って運用していくことが必要です。ここからは、ads.txtの設置にかかわる媒体社・プラットフォーム向けに解説していきます。

ads.txtにもバージョンがありますが、ここでは2018年1月時点の「ads.txt バージョン1.0.1」の仕様に沿って解説します（公式文書はこちら）。

DSPは決まりに従ってads.txtを確認するので、設置方法や内容が誤っていると、広告枠に広告が出なくなり、広告収入が得られなくなるリスクがあります。そのため、ads.txtの作成やアップロードはよく注意して行う必要があります。

ads.txtはルートドメインに設置する

まず、一番多いのは設置場所の誤りです。以下、Web担当者Forum（https://webtan.impress.co.jp/）を例にして説明します。

ads.txt の設置場所は以下のとおりです。上が正しい設置場所、下が誤った設置場所です。なお、ads.txtのファイル名は必ず小文字で「ads.txt」とします。

メディアをサブドメインで運用している場合、「https://webtan.impress.co.jp/ads.txt」のみに設置してしまう間違いが多くありますが、ads.txtは正しくは「ルートドメイン」と呼ばれる、サブドメインを含まない「impress.co.jp」に設置する必要があります。

なお「https://www.impress.co.jp/」などの「www」もサブドメインと同じ扱いです。「www」が付かないルートドメインにads.txtを設置する必要があります。

サブドメインでメディアを分けて運営していない場合は、設置場所については以上です。サブドメインで別メディアを運営しており、それぞれでads.txtの内容を変えたい場合の説明については、後ほど説明します。

ads.txtの記述方法

次に、具体的なads.txtのサンプルを示します（図4）。ads.txtでは次の3つの情報を示すことができます。

1. どのSSP/Ad Exchangeに許可を与えるかという情報（必須）
2. ads.txtに関する問い合わせ窓口の情報（任意）
3. サブドメインに関する情報（任意）

図4：ads.txtの記述サンプル（全体）

行内の「#（シャープ）」以降に続く文字列はコメントとみなされます。わかりやすいようにどの行が何を示しているのかのメモを書いておきましょう。行内の半角スペースやタブは無視する仕様になっているため、見やすくするために半角スペースやタブを入れても構いません。

①どのSSP/Ad Exchangeに許可を与えるかという情報（必須）

まずは一番重要な①「どのSSP/Exchangeに許可を与えるか」という情報の記載方法について説明します。

図5：ads.txtの記述サンプル（上部）

1行に最大4つの情報（コメント除く）を記載でき、1～3つ目は必須項目で、4つ目は任意の項目です。それぞれの情報を「,（カンマ）」区切りで記載します。これらの情報のセットを、SSPのアカウントごとに1行ずつ記述します。

②ads.txtに関する問い合わせ窓口の情報（任意）

「ads.txtに関する問い合わせ窓口の情報」は、書かなくてもいい任意の項目です。

図6：ads.txtの記述サンプル（中部）

ads.txtに関する問い合わせ窓口がある場合は、問い合わせ先を記載してください。この項目には、メールアドレス、電話番号、ウェブ問い合わせフォームのURLなどを記載します。なお、URLに半角スペースが入る場合は「%20」などURLエンコードした値を記入する必要があります。

図6では問い合わせフォームのURLを記載していますが、メールアドレスの場合は次のように記載します。

③サブドメインに関する情報（任意）

最後のサブドメインに関する情報は、前述した「サブドメインで別メディアを運営しており、それぞれでads.txtの内容を変えたい場合」に必要になる項目です。

図7：ads.txtの記述サンプル（下部）

インプレスの場合がこの「サブドメインで別メディアを運営しており、それぞれでads.txt の内容を変えたい場合」に該当しますので、実際にどのように用いるか解説します。

まず、正しい設置場所である、「https://impress.co.jp/ads.txt」に次のような内容を記載します。

そして、それぞれのメディアのサブドメインのルートにもads.txtを設置します。

この場合、ルートドメインである「https://impress.co.jp/ads.txt」にはサブドメイン情報のみを記述し、各サブドメインのads.txtにはそれぞれのSSP情報を記述します。

ルートドメインの「https://impress.co.jp/ads.txt」にもSSP情報が必要な場合は、サブドメイン情報に加えて「https://impress.co.jp/ads.txt」用のSSP情報も記述します。

このように、サブドメインで分かれている場合に、DSPに対して「サブドメインでSSPのアカウントが分かれているから、ちゃんとこっちの情報も見てくださいね」と示すためには、ルートドメインのads.txt内で「subdomain=」を記述して明示的に設定する必要があります。

媒体社プラットフォーム
ads.txtのチェック方法

ここまで説明してきたように、ads.txtはチェックポイントがいくつかあります。すべてのチェックポイントを手作業で調べることは、意外と手間がかかります。そのため筆者の所属するDataSignではads.txtチェッカーを提供しています。

上記サイトにads.txtのURLを入力するだけで、設置場所、文字コード、構文のチェックを自動的に行います。

現状ではチェック機能のみですが、今後は、自動的にads.txtを生成できるように進化させていく予定です。