はじめに
さんすうおじさんをAdMobのストア情報に紐づけると、こう返ってきた。
アプリを確認できませんでした。app-ads.txt ファイルが設定されている可能性がありますが、お客様の詳細情報がAdMobアカウントの情報と一致しません。
「設定されている可能性がありますが」で始まる、歯切れの悪い文面だった。ファイルの中身が違うのか、それとも別の何かか。AIは文面を読んで判断しようとして、遠回りをした。
同じ文言が、ファイルが無いときにも出る
このエラー文は定型文だった。app-ads.txtが存在しないときも、存在して中身が合っているときも、同じ文言が出る。 文面からは何も判断できない。
さらに紛らわしいのが、似た名前の別ファイルの存在だった。
| ファイル | 用途 |
|---|---|
ads.txt |
ウェブサイトの広告（AdSense） |
app-ads.txt |
アプリの広告（AdMob） |
kuroto-blogにはads.txtだけがあり、app-ads.txtは無かった。名前が似ているだけの別物を、「設置済み」と思い込んでいた。
文面を読むのはやめ、直接測ることにした。
curl -sI https://kuroto-blog.pages.dev/app-ads.txt
404。 ここで原因の半分が確定した。
ファイルを置いても、まだ通らなかった
public/app-ads.txtを置いてpushし、Cloudflare Pagesのデプロイを確認する。
curl -sI https://kuroto-blog.pages.dev/app-ads.txt
# HTTP/2 200
# content-type: text/plain
200・text/plain。ファイル側は揃った。だが、AdMobの「アプリを確認できませんでした」は消えなかった。
見に行っているのは、別のURLだった
AdMobが照合しているのは、app-ads.txtの置き場所そのものではなく、App Store の「デベロッパーサイト」＝マーケティングURLのドメインだった。ファイルが200で返っていても、参照元のURLが空なら照合先が無く、永久に一致しない。
Appleの公開APIで確認できる。
curl -s "https://itunes.apple.com/lookup?id=<ASC App ID>&country=jp" \
| python3 -c "import json,sys; print(json.load(sys.stdin)['results'][0].get('sellerUrl','(なし)'))"
さんすうおじさんはsellerUrlが空だった。マーケティングURLを、初回提出のときに入れ忘れていた。
直そうとしても、直せない期間があった
気づいて直そうとしても、できなかった。App Store Connectでは、ステータスが**「配信準備完了」の間、メタデータがロックされて編集できない**。
8月17日にapp-ads.txtの404を確認してから、直せる状態になるまで4日かかった。次のバージョン1.0.2を審査に出すタイミングまで待つしかなく、8月21日のリリースでようやくマーケティングURLが入った。
同日中に測り直すと、sellerUrlは反映済み、app-ads.txtも200・text/plain・内容一致。条件は全部揃っていた。そして——
URLが製品ページに出たその日のうちに、確認が通った。 待っていたのはGoogleのクローラーの取得タイミングだけで、連打しても変わらないものだった。
教訓
「app-ads.txtファイルが設定されている可能性がありますが」という文面は、原因の在り処を教えてくれなかった。実際に効いていたのは、ファイルとは別の場所——初回提出時に埋めるはずだった1個のフィールドだ。
定型のエラー文は、文面で判断せず、実測できる部分から一つずつ潰す方が早い。「ファイルは200か」「参照先URLは入っているか」の2点さえ先に測っていれば、4日の足止めは要らなかった。
- 確認が通った次は、AdMob側の広告審査（通常2〜3日）が待つ。この間、操作できるものは無い。
- 完了画面がCMP（同意管理プラットフォーム）の設定を促すが、これはEEA・英国・スイス向けの要件で、日本のみの配信なら不要。
- app-ads.txtが無くても広告配信自体は止まらない。設置は広告詐欺対策の任意の仕組みで、単価の高い広告主が入りやすくなるだけだ。
ファイルの中身を何度も見直していた。
見るべきは、ファイルの外側に置き忘れた1個のURLだった。
記事に登場したアプリ: