📜 ads.txt ジェネレーター

Google AdSense / Ad Manager / Amazon / Index Exchange / Rubicon / OpenX / PubMatic / Sovrn / Criteo など主要 SSP・アドネットワークのプリセット付きで IAB 準拠 ads.txt を生成。DIRECT / RESELLER 区分対応。

完全無料登録不要ブラウザ完結 5 言語対応ダークモード

🔒 プライバシーについて

・パブリッシャー ID はサーバーに送信されません
・すべての処理はブラウザ内で完結します
・登録・ログイン・課金は一切不要です

🏷️ パブリッシャー ID

Google AdSense / Ad Manager (例: pub-1234567890123456)

Amazon Publisher ID

🌐 ネットワーク選択

➕ カスタム行追加

形式: domain, publisher-id, DIRECT|RESELLER, [TAG-ID]

📄 ads.txt

このファイルをドメインルート (https://example.com/ads.txt) に配置してください。

📚 ads.txt について

ads.txt (Authorized Digital Sellers) は IAB Tech Lab が策定した広告詐欺防止規格。広告枠を販売する権限を持つ業者をテキストファイルで公開し、ドメインなりすましを防止します。Google AdSense / Ad Manager 利用時は配置がほぼ必須です。

📖 つまずきやすいポイント

パブリッシャー ID とアドネットワークの選択から、domain, publisher-id, DIRECT|RESELLER, TAG-ID という 4 列の ads.txt を組み立てます。処理はブラウザ内で完結し、ID がサーバーに送られることはありません。このツールが保証できるのは書式だけです — ID が正しいか、そのネットワークと実際に契約があるかは検証できません。そして ads.txt は「ここに書いていない売り手からの在庫は買うな」と宣言するファイルなので、書式が完璧でも ID が 1 文字違えば、その売り手経由の入札が静かに全部止まります。

ケース	何が起きるか	どうする
置き場所が違うと、無いのと同じ扱いになる	クローラーが読むのはドメインのルート直下だけ、つまり `https://example.com/ads.txt` です。`/blog/ads.txt` も `/ads.txt.html` も見に行きません。よくある失敗が 3 つあります。ひとつは SPA や静的ホスティングが未知のパスに `index.html` を 200 で返すケースで、クローラーは HTML を受け取り、そこに広告システムの行が無いので「全部未許可」と解釈します。ふたつめはサブドメイン — `blog.example.com` の在庫は `blog.example.com/ads.txt` が参照され、ルートのファイルは自動では適用されません。みっつめはリダイレクトで、仕様上たどれるのは限られた回数だけです。	ブラウザで開いて確認するのは不十分です。`curl -I https://example.com/ads.txt` を実行し、ステータスが 200 であること、`Content-Type` が `text/plain` であること、リダイレクトしていないことの 3 点を見てください。`text/html` が返っていたら、それは `ads.txt` ではなくアプリのフォールバックページです。サブドメインで配信しているなら、ルートのファイルに `subdomain=blog.example.com` の行を足すか、そのサブドメインにも実体を置きます。www の有無も別ホスト扱いなので、両方で `curl` して確かめてください。
DIRECT と RESELLER を実態と違えて書く	DIRECT は「その広告システムと直接契約していて、そこから直接支払いを受けている」という意味です。MCM や仲介パートナー経由で AdSense を運用している場合、正しい行はそのパートナーから指定されたもので、多くは `RESELLER` の行を含みます。DIRECT と書いたほうが有利、ということはありません — 買い手側の照合は `sellers.json` と突き合わせて行われるため、実態と食い違えば逆に信用を落とします。もうひとつの定番がドメイン欄の書き間違いで、ここに入れるのは広告システムの正規ドメイン (`google.com`) であって、管理画面の URL (`adsense.google.com`) ではありません。	行は自分で考えず、各パートナーの管理画面に書いてある文字列をそのままコピーしてください。主要なアドネットワークは必ず「ads.txt に追加する行」を公開しています。パブリッシャー ID は支払い先アカウントの表示と 1 文字ずつ照合し、Google なら `pub-` の接頭辞まで含めて完全一致させます。第 4 列の TAG-ID は任意ですが、書けるなら書いてください — 買い手側のフィルタで加点されることがあります。仕上げに、できあがったファイルを Google Ad Manager や AdSense の ads.txt ステータス画面で読ませ、警告が消えることを確認します。書式検証はそこが最終的な権威です。
作り直したときに、以前あった行が消える	`ads.txt` の変更は即座には反映されず、また即座には取り消せません。クローラーは取得結果をおおむね 1 日程度キャッシュするので、新しいネットワークを足してもその日のうちには配信が始まりません。問題は逆方向です — 以前は載っていた行を落としたファイルを公開すると、その売り手経由の需要が 1 日ほどで止まります。ジェネレーターでゼロから作り直して上書きする運用をしていると、数か月前に追加したパートナーの行を忘れて落とす事故が起きます。しかも収益が減っただけでは原因が分からないため、気付くまでに時間がかかります。	生成したファイルを直接アップロードせず、必ず現在公開中のファイルと差分を取ってください。 `curl -s https://example.com/ads.txt > live.txt` で現物を落とし、`diff live.txt new.txt` で「消える行」が意図したものだけかを見ます。運用としては、`ads.txt` を Git で管理し、変更を必ずレビュー経由にするのが確実です。あわせて、広告収益の日次推移をパートナー別に見られるようにしておくと、事故が起きたときに切り分けられます。行を追加した日付をコメント (`# 行頭`) で残しておくと、後任者が消してよい行かを判断できます。

ads.txt は公開ファイルであり、それが仕様です。誰でも取得できるので、あなたがどのネットワークと組んでいるかは競合にも丸見えになります。これは避けようがなく、隠す仕組みもありません — 広告システムを秘密にする運用は、そもそも ads.txt と両立しません。範囲についても誤解が多いので整理しておきます。このファイルが守るのは Web の広告枠だけです。アプリの在庫は app-ads.txt という別のファイルで、しかも置き場所はアプリストアの登録情報に書いた開発者サイトの URL であって、アプリのドメインではありません。動画には ads.cert など別の仕組みがあります。そして最後に — ads.txt は「なりすまし在庫を買わせない」ための宣言であって、収益を増やす設定ではありません。置いたことで単価が上がるのではなく、置いていないと買い手に敬遠されるという性質のものです。

📖 使い方

1

パブリッシャー ID を入力

Google AdSense や Amazon の ID を入力。
2

ネットワークを選択

利用している SSP / アドネットワークにチェック。
3

配置

生成された ads.txt をドメインルートに配置 (https://example.com/ads.txt)。

❓ よくある質問

DIRECT と RESELLER の違いは？

DIRECT はパブリッシャーが直接契約しているネットワーク、RESELLER は仲介業者経由。直接契約は DIRECT を選びます。

TAG-ID (認証ID) は必須ですか？

IAB Tech Lab 認証 ID。任意ですが推奨。空欄でも有効。

ads.txt はどのくらいで反映されますか？

Google は通常 24 時間以内にクロールしますが、最大 1 週間かかる場合があります。Search Ads Center で確認可能。

🔗 関連ツール

🐛 このツールで問題が発生しましたか？

完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。