同じホスト名では、ルートに割り当てた Worker が Custom Domain に割り当てた Worker より先に実行されます。Custom Domain の Worker はオリジンとして扱われるため、狭いルート（単一のパス）を使えば、メインの Worker を再デプロイせずに別のファイルを配信できます。

小さなファイルが動かせない

AI エージェントに関わる仕事が増えるほど、決まったパスに置く小さなファイルが必要になります。/.well-known/ 配下の検証ファイル、エージェント向けの説明など、人間の訪問者が開くことのないものです。たいていは外部のサービスが読み取りを待っているため、すぐに公開する必要があります。

2026年10月、pw.migurei.ai でまさにその状況になりました。/.well-known/ 配下に検証ファイルを置く必要があったのです。一方、メインサイトには、まだ公開できる状態ではない変更がいくつも待機していました。メインの Worker からファイルを配信すると、待機中のほかの変更もすべて一緒に公開することになります。

わずか数行のテキストが、フルリリースの後ろで足止めされていました。

答えはドキュメントの一段落にありました

2026年10月21日、Cloudflare Workers の Custom Domains ドキュメントを読みました。

> Custom Domain 上で動作する Worker はオリジンとして扱われます。Custom Domain より前にルート上で動作する Worker は、fetch(request) を発行することで、任意で Custom Domain に登録された Worker を呼び出せます。

ここから二つのことが言えます。

1. Custom Domain の Worker はオリジン、つまりそのホスト名の「本拠地のサーバー」として扱われます。
2. ルートの Worker はその前段に位置します。リクエストはまずルートの Worker に届き、そこで自ら応答することも、fetch(request) でメインの Worker にリクエストを渡すこともできます。

私のラボサイトはまさにこの構成です。メインの Worker が一つ、Custom Domain としてホスト名に割り当てられています。

使い方

小さな Worker を作り、単一のパスに一致するルート、たとえば pw.migurei.ai/.well-known/<file-name> に割り当てます。この Worker はそのファイルだけを返します。ほかのパスはすべてルートに一致せず、これまでどおりメインの Worker に直接届きます。

• サイトのリリーススケジュールに関係なく、ファイルはすぐに公開されます。
• 元に戻すのも同じく簡単です。ルートを削除すれば、リクエストはメインの Worker に戻ります。
• メインの Worker はまったく変更されません。

私のようにボットのトラフィックを計測している場合は、一つ落とし穴があります。そのパスへのリクエストには小さな Worker が応答するため、小さな Worker が fetch(request) で転送しない限り、メインの Worker のログ記録を通りません。どのボットがファイルを読んだかを知りたいなら、小さな Worker 自体でログを取ってください。そうしないと、ファイルが読まれても気づけません。

サイト運営者にとってのより広い教訓は、機械可読なファイルをページのリリースから切り離しておくことです。ライフサイクルも、読み手も異なるからです。

どこまで確かか

これは外部ソースに基づく主張で、Cloudflare のドキュメントの一節を根拠としています。まだ自分のゾーンで試していないため、実際にスムーズに動くとは言えません。また、ルートの作成に必要な権限があることも確認していません。後述の制約のセクションで触れるとおり、ドキュメントが扱っているのは Worker が実行される順序だけで、そこに置いたファイルを実際にどのボットが読むかについては何も述べていません。