ads.txt チェッカー
ads.txtの内容を貼り付けるだけで構文エラーを検出。DOMAIN・PUBLISHER_ID・RELATIONSHIP（DIRECT/RESELLER）の各フィールドを行ごとに検証し、広告枠の不正な転売（ドメインスプーフィング）対策に必須のファイルを正しく設置できているか確認できます。
ads.txtとは
ads.txt（Authorized Digital Sellers）は、サイト運営者が「自サイトの広告枠を販売する権限を持つ広告システム」を宣言するためのテキストファイルです。IAB Tech Labが策定した業界標準で、ドメインのルート（https://example.com/ads.txt）に設置します。各行はDOMAIN（広告システムのドメイン）・PUBLISHER_ID（アカウントID）・RELATIONSHIP（DIRECTまたはRESELLER）の3〜4フィールドをカンマ区切りで記述する仕様になっており、構文が1文字でも崩れると広告システム側の照合に失敗し、正規の広告枠が「未認証」として扱われてしまいます。
このチェッカーは、貼り付けたads.txtの内容を1行ずつ解析し、フィールド数の過不足・空フィールド・DOMAIN形式の誤り・RELATIONSHIPの誤記（DIRECT/RESELLER以外の値）を検出します。コメント行（#始まり）やCONTACT=・SUBDOMAIN=・OWNERDOMAIN=などの変数ディレクティブも正しく識別し、レコード行とは区別して表示します。URLを指定して既存サイトのads.txtを直接取得し検証することもできます。
ads.txtチェッカーの使い方
- ads.txtの内容を用意する 自サイトの現行ファイル、またはこれから公開する予定の内容をテキストとして手元に用意します。
- 入力欄に貼り付ける、またはURLから取得する テキストエリアに直接貼り付けるか、「URLから取得」欄にドメインを入力して既存のads.txtを読み込みます。
- 検証結果を確認する 各行が正常・エラー・変数・コメントのどれに分類されたかを一覧で確認します。
- エラー行を修正する 備考欄に表示される具体的な理由（フィールド数不足、DOMAIN形式の誤りなど）に沿って該当行を書き直します。
-
修正後、ドメインのルートに設置する
すべて正常と表示されたら、
https://yourdomain.com/ads.txtとしてサーバーに公開します。
使いこなすためのヒント
- DOMAIN・PUBLISHER_ID・RELATIONSHIPの3フィールドが基本形で、4つ目のフィールド（認証機関ID）は省略可能です。カンマの数を数えて過不足がないか確認しましょう。
- RELATIONSHIPは
DIRECT（サイト運営者が直接契約している）かRESELLER（再販業者経由）のいずれかのみが有効です。大文字・小文字は区別されませんが、慣例的に大文字で記述します。 - 行頭が
#で始まる行はコメントとして無視されます。CONTACT=やOWNERDOMAIN=のような変数ディレクティブも合わせて記述しておくと、広告システム側での照合に役立ちます。 - ads.txtはドメインのルート（
https://example.com/ads.txt）に設置する必要があります。サブディレクトリに置いても検索・広告システムには認識されません。 - アプリ向けには
app-ads.txtという別ファイルの仕様も存在します。Webサイトとモバイルアプリの両方で広告枠を販売している場合は両方の設置が必要です。
こんなときに使えます
Google AdSense審査前の点検
AdSenseの審査や広告配信の警告解消のため、設置済みのads.txtに構文ミスがないかを事前にチェックします。
新しい広告システム（SSP）の追加時
新たなSSPやアドネットワークから提供された1行を追記する際、カンマの数や表記ミスがないかをその場で確認できます。
CMS移行・サイトリニューアル後の確認
WordPressの移行やサーバー移設でads.txtが文字化け・改行崩れを起こしていないか、URL取得機能で本番環境を直接検証します。
複数ドメイン・複数拠点の運用チェック
広告代理店やメディア運営者が、管理する複数サイトのads.txtをまとめて棚卸しする際の検証ステップとして利用します。
外部から提供されたスニペットの検証
アドネットワークから送られてきたads.txt追記用スニペットを、自サイトに反映する前に単体で構文チェックします。
用語集
- ads.txt
- IAB Tech Labが策定した、広告枠の正規販売者を宣言するためのテキストファイル仕様。ドメインのルートに設置します。
- DIRECT
- サイト運営者が広告システムと直接契約し、広告枠の販売権限を自ら保有していることを示すRELATIONSHIPの値です。
- RESELLER
- 運営者から権限を委譲された再販業者（アドネットワークなど）が広告枠を販売する場合に使うRELATIONSHIPの値です。
- 認証機関ID（Certification Authority ID）
- 4番目の任意フィールドで、TAG（Trustworthy Accountability Group）などが発行する広告システムの識別子を指します。
- ドメインスプーフィング
- 正規の広告枠を第三者が無断で複製・転売し、広告主に別サイトへ配信させる不正行為です。ads.txtはこれを防ぐために作られました。
- Authorized Digital Sellers
- ads.txtの正式名称。「認証済みのデジタル販売者」を意味し、仕様全体の理念を表しています。
- PUBLISHER_ID
- 各広告システムがアカウントごとに発行する識別子です。AdSenseでは「pub-」から始まる文字列が使われます。
- SSP（Supply-Side Platform）
- パブリッシャー側の広告枠を広告主の入札システムへ卸す仲介プラットフォームです。ads.txtのDOMAINフィールドにはSSPのドメインを記載します。
よくある質問
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により策定されています。これらを組み合わせることで、広告主は「誰が」「どの広告枠を」「どのような関係で」販売しているかをサプライチェーン全体で検証できるようになりました。