UrlEdge
ブログに戻る
2026年5月17日 UrlEdge Editorial3 min read

検証ファイルをEdgeで配信する：ads.txt、security.txt、AASA、assetlinks.json

root や /.well-known/ に置く必要がある小さなファイルは、CMS や site builder で詰まりがちです。Edge response なら正しい path、status、Content-Type で直接返せます。

root と .well-known の検証ファイルを edge response layer から直接配信する構成

検証ファイルで面倒なのは、ファイルの中身ではなく path です。

ads.txt は root に必要です。security.txt は /.well-known/ が期待されます。iOS には apple-app-site-association が必要です。Android には assetlinks.json が必要です。CMS、EC platform、site builder は通常ページには強くても、こうした特定 path では詰まりがちです。

その結果、小さなファイルが広告、security disclosure、app link、migration の launch blocker になります。

Universal Links や Android App Links も扱うなら、Firebase終了後のUniversal Links / App Links設定方法 も合わせて確認してください。ここではファイル配信そのものに絞ります。

root と .well-known の問題

ファイルは小さいですが、検証する側はかなり厳密です。

よくある失敗:

  • CMS が root file を許可しない
  • /.well-known/ が app router に拾われる
  • file の前に redirect が入る
  • Content-Type が違う
  • launch 後に owner がいない

Edge が役立つのは、サイト全体を作り替えずに、指定 path へ直接応答できるからです。

Edge response map for root and .well-known verification files

ファイルごとに役割が違う

ads.txt と app-ads.txt

広告在庫の透明性と認可に使われます。読み取りやすさが重要です。

  • direct path
  • 200 response
  • plain text
  • owner が明確

login、redirect、CMS fallback の後ろに置くと、検証が失敗することがあります。

security.txt

security.txt は vulnerability report の窓口を示すファイルです。Web、security、legal、platform の間で責任が曖昧になりやすいファイルでもあります。

Edge response にすると、path、body、Content-Type、owner をルールとして持てます。

apple-app-site-association

Apple Universal Links は AASA file が正しい場所にあることに依存します。ここが崩れると、app 側を debug しても原因が見つからないことがあります。

assetlinks.json

Android App Links には有効な assetlinks.json が必要です。ファイルが無い、古い、site builder に書き換えられる、というだけで domain verification が不安定になります。

Edge response が外してはいけないこと

賢くなくて構いません。正確である必要があります。

Verification file requirements for path, status code, content type, and owner

FileTypical path必要なことよくある失敗
ads.txt/ads.txt200, text, stable contentredirect や login の後ろに置く
app-ads.txt/app-ads.txt200, text, app inventoryapp inventory を忘れる
security.txt/.well-known/security.txt or /security.txt200, text, current contactroot path の owner がいない
apple-app-site-association/.well-known/apple-app-site-association or /apple-app-site-association200, JSON, exact bodyContent-Type や path が違う
assetlinks.json/.well-known/assetlinks.json200, JSON, exact bodyCMS に route を書き換えられる

platform が別の exact path を要求するなら、その仕様に合わせます。重要なのは、検証側が読める契約にすることです。

検証ファイルを redirect の後ろに置かない

こうしたファイルは、直接返すほうが安全です。

追加 hop は failure point になります。昨日は通った検証が今日落ちる、という調査も難しくなります。

consumer が redirect を許容すると明記している場合だけ使い、それ以外は direct response を基本にします。

owner を決める

この種のファイルは、launch 後に誰も持たなくなると壊れます。

実務では次のように分けると扱いやすいです。

  • ad ops が ads.txt と app-ads.txt
  • mobile engineering が AASA と assetlinks.json
  • security または platform が security.txt
  • web/platform が path、status、Content-Type

CMS 変更、rebrand、app update のとき、この owner が効きます。

運用手順

  1. 各ファイルの exact path を決める
  2. body と Content-Type を定義する
  3. edge から直接返す
  4. owner と review date を残す
  5. browser だけでなく実際の consumer でテストする

root file のためだけに origin deploy を増やしたくないチームに向いています。

UrlEdge が向いている場面

UrlEdge の Custom Response Tool は、text や JSON の小さな response を edge から返せます。

向いているケース:

  • origin が root や .well-known を扱いにくい
  • direct 200 response が必要
  • Content-Type と body を管理したい
  • その domain が既に redirect や routing に UrlEdge を使っている

deep link stack 全体を置き換えるものではありません。検証ファイルの hosting friction を取り除くための仕組みです。

FAQ

origin に置く必要がありますか？

いいえ。期待される path で正しく読める必要があります。origin が難しいなら edge delivery が現実的です。

redirect してもよいですか？

検証側が許容している場合だけです。多くの場合、direct response のほうが安定します。

CMS に任せればよいのでは？

通常ページには強い CMS でも、root や /.well-known/ は苦手なことがあります。

mobile app だけの話ですか？

いいえ。AASA と assetlinks.json は app 関連ですが、ads.txt、app-ads.txt、security.txt は広告と security の話です。

参考

origin を触らず検証ファイルを配信する

root と .well-known のファイルを edge から返し、status、Content-Type、owner を明確に保ちます。

Edge responsesを見る

関連記事

すべて見る