1. はじめに
Google広告の品質審査や、なりすまし広告防止に欠かせない ads.txt と app-ads.txt。
「名前が似ているから、とりあえずルートドメインに置けばいい」と思っていませんか？
実は、Googleの広告品質クローラーである AdsBot にとって、この2つはスキャンする場所も、エラー時の挙動も、そして収益へのダメージも大きく異なります。本記事では、エンジニアがハマりやすいポイントを中心に徹底解説します。
2. AdsBotが「どこを見に行くか」の違い
ここがエンジニアリング的に最も重要な違いです。
ads.txt の場合：直球勝負
AdsBotは、広告が表示されるWebページのドメインを元に、機械的に以下のパスを確認します。
app-ads.txt の場合：ストア経由の2ステップ
アプリには「ドメイン」という概念が直接紐付いていないため、AdsBotは以下の手順を踏みます。
ストア情報の確認: アプリストア（Google PlayやApp Store）に登録されている 「デベロッパーウェブサイト」 のURLを取得。
ルートへのアクセス: そのURLのルートディレクトリにファイルを挿しに行きます。
3. AdSenseとAdMob(Ad Manager)で異なる「エラー時の末路」
ここが本記事の核心です。AdsBotがファイルを読み取れなかった場合、プロダクトによってダメージの性質が異なります。
Web (AdSense)：収益性は落ちるが「沈黙」はしない
Web向けのads.txtにおいて、AdsBotがファイルを読み取れなかったり、IDが不一致だったりする場合：
挙動: 認定されていない販売者経由の広告リクエストとして処理されます。
結果: ブランド広告主が入札を控えるため、入札単価（CPM）が激減します。
ポイント: ただし、認定を問わないネットワークにより広告自体は出続けることが多いため、即座に「枠が真っ白」になることは稀です。
App (AdMob / Ad Manager)：Open Biddingによる「沈黙」
一方で、モバイルアプリや Open Bidding（旧EBDA）を利用している場合、状況は一変します。
メカニズム: アプリ広告はWeb以上に透明性が厳格です。Open Biddingに関わる多くのアドエクスチェンジは、app-ads.txt による認証を配信の必須条件としています。
結果: AdsBotがファイルをホスト（確認）できない場合、ビッダーが一人も現れず、フィル率が0%になり広告が一切出なくなる（沈黙する) 状態に陥ります。
ポイント: これは「単価下落」ではなく、「在庫そのものの死」 を意味します。
4. 【要注意】Google サイトで完結させようとすると「詰む」理由
エンジニアが「手軽だから」と Google サイト（Google Workspace）でアプリの公式サイトを作ろうとすると、技術的な壁にぶつかります。
ネイキッドドメインの制約:
Google サイトは、example.com のようなルートドメイン直下に 任意のテキストファイルをホストする機能がありません。
AdsBotとの相性: Google サイトでは /app-ads.txt というパスでレスポンスを返せないため、AdsBotは404を返し、結果としてAdMobの広告配信が止まります。
回避策：外部ホスティングの併用
これを回避するには、Google サイト単体での運用を諦め、以下のような構成を組む必要があります。
GitHub Pages や Cloudflare Pages の利用: app-ads.txt をホストするためだけに、これら静的サイトホスティングを別途用意する。
DNSの制御: ネイキッドドメインのAレコードやCNAMEをこれらに向け、リダイレクトやサブドメイン運用で Google サイトと共存させる設計が必須です。
5. まとめ
Web (AdSense): ads.txt ミス ＝ 「収益の出血」（単価下落）
App (AdMob/GAM): app-ads.txt ミス ＝ 「収益の心停止」（配信停止）
AdsBotに正しく情報を伝えることは、単なるポリシー遵守ではなく、収益のライフラインを守ることと同義です。
特にアプリ開発者は、デベロッパーURLのホスティング環境が「テキストファイルをルートに置けるか」を必ず確認しましょう。