最近目にする機会の増えた「ads.txt」というワードですが、実際にads.txtを導入されているパブリッシャーの方はまだまだ少ないのではと思います。「アズテキスト」と読むこのファイルは、一体どんな課題をどのように解決するものなのでしょうか。書き方やファイル設定、設置方法など詳しく解説していきたいと思います。

ads.txtとは

ads.txt（アズテキスト）とは、IAB（Interactive Advertising Bureau）の研究・開発組織IAB Tech Labが2017年5月に発表した「プログラマティック取引において、偽造された広告枠や不正なインプレッションの販売を防止するツール」です。ツールと言っても、ads.txt自体はその名の通りテキストファイルです。adsとはAuthorized Digital Sellers（認定されたデジタル販売者）の略で、このファイルにサイトの広告枠の販売を許可している広告システムの情報を記載し、公開することで、パブリッシャーは公式に販売を許可している広告システムを宣言することができます。そしてそこに記載された情報をDSPが参照し、リストされている広告システムを通して広告枠の買い付けを行うことができるという仕組みです。

ads.txtが考案された背景には、昨今のアドフラウドの蔓延や広告在庫（広告インベントリ）の再販による、サプライチェーンの透明性の欠如というデジタル広告業界全体の課題があります。パブリッシャーがads.txtで公式に販売許可をした事業者を宣言し、DSPがその宣言を元に買い付けを行うことにより、透明性の高い広告取引を実現しようというのがads.txtの目的です。

ads.txtを導入するとどうなるのか

「透明性の高い広告取引の実現」は広告主側に主眼を置いた表現なので、パブリッシャーにとってどういったメリットがあるのか、導入をしないとどういった問題が起こるのかが少し掴みづらいかもしれません。ここでは、パブリッシャーの観点から、ads.txtの導入について解説していきたいと思います。

A:ads.txtを導入しない場合

B:ads.txtを導入した場合

A、Bいずれも、悪質なパブリッシャーによる「ドメインなりすまし」にサイトが狙われた場合を想定しています。
Aの場合、DSPは買い付けた広告枠がなりすましによって偽造されたサイトのものだと気づくことができません。そして偽造サイトの広告枠の効果によって、本物のサイトのドメインの評価が下がってしまいます。パブリッシャーは、偽のサイトに広告料が支払われてしまうという直接的な被害に加え、なりすまされたドメインに悪評が付き、市場で適切な評価が得られられなくなってしまうという間接的な被害も受けます。また、ads.txtに準拠する方針のDSPから買い付けがされなくなるという可能性もあります。
Bの場合、DSPは本物のサイトのads.txtを参照することで、リクエスト元が偽のサイトかもしれないと疑いを持つことができるので、Aのような被害を未然に防ぐことができます。またads.txtが参照されることで、パブリッシャーはDSPに安心して買い付けしてもらえるというメリットがあります。さらに、ads.txt参照枠に関しては高単価で買い付けされる、と言った可能性も今後は出てくるかもしれません。

ads.txtの導入の仕方

では実際にどうすればads.txtを導入することができるのか、詳しく解説していきたいと思います。

ads.txtの書き方

ファイルに盛り込むのは①広告システムのドメイン（必須）、②広告システムから付与されているパブリッシャーのID（必須）、③広告システムとパブリッシャーの関係（必須）、④認証機関の ID（任意）の4つの情報です。①～④は「,（カンマ）」で区切り、販売を許可している経路ごとに行を分け記載します。#記号で始まる行はコメントとみなされます。

①FIELD #1 広告システムのドメイン（必須）

入札者が接続するSSP、エクスチェンジ、ヘッダービディングソリューションなどの広告システムの正規ドメイン名です。システムの運用ドメインが親会社のドメインと異なる場合は、運用ドメインを指定します。SSPやエクスチェンジからドメイン名が指定されていれば、そちらを参考にしてください。

②FIELD #2 広告システムから付与されているパブリッシャーのID（必須）

①の広告システムの委託者またはリセラーのアカウントから発行されているパブリッシャーを識別するためのIDです。ここには、OpenRTB入札リクエスト時にSSPやエクスチェンジが利用している、Publisherを識別するためのIDを記述します。OpenRTBの場合は publisher.idフィールド、OpenDirect（予約型広告在庫のプログラマティック取引など）の場合はパブリッシャーの組織IDになります。

③FIELD #3 アカウントタイプ（広告システムとパブリッシャーの関係）（必須）

ここには「DIRECT」か「RESELLER」と記載します。パブリッシャーが②のアカウントを直接管理している場合は「DIRECT」で、サイト運営者またはパブリッシャーが広告システムと直接のビジネス契約を結んでいることを意味します。管理を第三者に委託し、広告枠の再販を許可している場合は「RESELLER」とします。今後、「DIRECT」「RESELLER」以外のタイプも追加される可能性があります。

④FIELD #4 認証機関の ID（任意）

認証機関で広告システムを識別するIDを記載します。これは①の広告システムにマッピングされます。現在の認証局は、Trustworthy Accountability Group（TAG）で、TAGIDをここに記載します。

たとえば、ex1.com、ex2.com、ex3.comという3つの広告サービスを使用し、いずれもアカウントの管理をパブリッシャーが直接行っており、ex3.comのみ管理を第三者に委託しているアカウントも存在する場合は次のような内容になります。

#sample publisher ads.txt
ex1.com,pub-123,DIRECT
ex2.com,4567,DIRECT
ex3.com,p89012,DIRECT
ex3.com,p34567,RESELLER

この内容を記したテキストファイルを「ads.txt」という名前で保存します。

ファイル設定および配置場所

ファイル設定および配置場所については次のルールが敷かれています。

• 配置場所はサブドメインでなくルートドメイン直下、サーバホスト上の標準相対パス 「/ads.txt」で呼び出される場所に置く
• ウェブサイトからHTTPまたはHTTPSを介してアクセス可能な形で配置する
• Content-Typeは「text / plain」、charsetは「utf-8」の指定が推奨されている
• 公開状態で配置することも、パスワードなどで閲覧制限をかけることも可能（ただし閲覧制限をかける場合は閲覧許可のためにどこかでパスワードの提示が必要になる）

更に詳しい設置方法など詳細はIABから発表されている「Ads.txt Specification Version 1.0 」をご参照ください。

ads.txtに対する各社の対応

2017年5月に発表されて間もないads.txtですが、海外ではパブリッシャーやプラットフォーマーが徐々に対応を始めているようです。
The Washington PostやBUSINESS INSIDERなどのパブリッシャーが実際にads.txtを設置し、また、Google、AppNexus、The Trade Deskなどの広告事業者は、ads.txtのサポートを表明しています（2017年8月現在）。

しかし、多くのプレイヤーはまだ様子見といったところのようです。ads.txtは実装が簡単でシンプルな方法ですが、多くのパブリッシャーが導入し、買い手側もこれに準拠した買い付けを重視しなければ機能していきません。また、Rebel Al社 CEO　マニー・プエンタス氏は「ads.txtは透明性という感覚を向上させることにはなるが、課題の根本を解決するわけではなく、アドフラウドについても完璧に防ぐ手立てではない。またads.txtの仕様はリストに載っていないプラットフォームに対して意図的に圧力をかけようとするもので、結果的に彼らを排除するものだという論争を巻き起こすだろう」と述べています。ads.txtの有効性と、それによるあらゆる副作用を想定し、慎重にならざるを得ないといったところです。

しかし、いずれにしても、デジタル広告業界への信頼を高め、デジタル広告市場が更に成長するための地盤固めをしていかなければならないという意識は業界全体で高まっています。広告業界はまさに過渡期ではあるものの、重大な問題を解決するために一体となって前進しています。