ads.txt バリデーター
ads.txtの内容を貼り付けるだけで構文エラーを検出。DOMAIN・PUBLISHER_ID・RELATIONSHIP（DIRECT/RESELLER）の各フィールドを行ごとに検証し、広告枠の不正な転売（ドメインスプーフィング）対策に必須のファイルを正しく設置できているか確認できます。
Tips
- DOMAIN・PUBLISHER_ID・RELATIONSHIPの3フィールドが基本形で、4つ目のフィールド（認証機関ID）は省略可能です。カンマの数を数えて過不足がないか確認しましょう。
- RELATIONSHIPは
DIRECT（サイト運営者が直接契約している）かRESELLER（再販業者経由）のいずれかのみが有効です。大文字・小文字は区別されませんが、慣例的に大文字で記述します。 - 行頭が
#で始まる行はコメントとして無視されます。CONTACT=やOWNERDOMAIN=のような変数ディレクティブも合わせて記述しておくと、広告システム側での照合に役立ちます。 - ads.txtはドメインのルート（
https://example.com/ads.txt）に設置する必要があります。サブディレクトリに置いても検索・広告システムには認識されません。 - アプリ向けには
app-ads.txtという別ファイルの仕様も存在します。Webサイトとモバイルアプリの両方で広告枠を販売している場合は両方の設置が必要です。
よくある質問
DIRECTはサイト運営者が広告システムと直接契約し、広告枠の販売権限を持っていることを示します。RESELLERは運営者から権限を委譲された再販業者（アドネットワーク等）が広告枠を販売する場合に使います。1つの広告枠を複数の広告システム経由で販売する場合、それぞれの関係性を正しく区別して記載する必要があります。SUBDOMAIN=ディレクティブがあり、特定のサブドメインについて別ファイルの参照先を指定することも可能です。
余談ですが ― ads.txtが生まれた理由 ― 広告枠の「なりすまし転売」を防ぐための業界標準
ads.txt（Authorized Digital Sellers）は2017年、広告業界団体IAB Tech Labが策定した仕様です。当時プログラマティック広告の世界では、正規の広告枠を第三者が無断で複製・転売する「ドメインスプーフィング」と呼ばれる広告詐欺が横行していました。広告主が特定の優良サイト向けに入札したつもりが、実際には無関係な低品質サイトに表示されてしまうケースが多発し、広告主・パブリッシャー双方の信頼を損なっていました。
ads.txtの仕組みは単純です。パブリッシャーが自サイトのドメイン直下に、自社の広告枠を販売する権限を持つ広告システムの一覧をテキストファイルとして公開します。広告主側のシステムはこのファイルを参照し、入札対象の広告枠が本当にそのドメインから正式に許可された取引経路かどうかを検証できます。仕組みがシンプルであるがゆえに導入コストが低く、公開から数年で主要な広告システム・パブリッシャーの大半に採用される業界標準となりました。
Google AdSenseも2019年からads.txtの導入を推進しており、正しく設置されていないサイトは広告配信の一部が制限される場合があります。広告収益で運営するサイトにとって、ads.txtは単なる推奨事項ではなく収益を守るための実質的な必須設定と言えます。
ads.txtの姉妹仕様として、モバイルアプリ向けのapp-ads.txtや、広告システム側の販売者情報を公開するsellers.jsonもIAB Tech Labにより策定されています。これらを組み合わせることで、広告主は「誰が」「どの広告枠を」「どのような関係で」販売しているかをサプライチェーン全体で検証できるようになりました。