Cloudflare WorkersのCustom Domainでエラー100117：既存DNSレコードを確認して復旧する

Astroで生成した静的サイトをCloudflare Workers Static Assetsへ配置し、wrangler.jsoncでCustom Domainを設定したところ、デプロイ時にエラーコード100117で処理が失敗しました。

調査すると、対象ホスト名に以前の仮ページ用Aレコードが残っていました。このレコードの用途を確認してから削除し、再度デプロイすることでCustom Domainを作成できました。

この記事では、単に「DNSレコードを削除する」のではなく、次の順序で安全に切り分けます。

1. Worker本体の配置とCustom Domainの作成を分けて確認する
2. 対象ホスト名の既存レコードを棚卸しする
3. Web用レコードだけを変更し、メール用DNSを触らない
4. 再デプロイ後にHTTPとDNSの両方を確認する

対象読者

• Workers Static Assetsを独自ドメインで公開したい方
• WranglerのデプロイでCustom Domainの作成だけが失敗している方
• 同じドメインでWebサイトとGoogle Workspaceなどのメールを運用している方

前提環境

今回確認した構成は次のとおりです。

• Node.js 22
• Astro 7系
• Wrangler 4系
• Cloudflare Workers Static Assets
• GitHub Actions
• Cloudflareで管理している独自ドメイン

Astroは静的出力とし、SSR用アダプターや独自のWorkerスクリプトは追加していません。dist/をそのままStatic Assetsとして配信します。

Custom Domainの設定

実環境の名前は使わず、example.comへ置き換えた最小例です。

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "example-site",
  "compatibility_date": "2026-10-01",
  "assets": {
    "directory": "./dist",
    "html_handling": "auto-trailing-slash",
    "not_found_handling": "404-page"
  },
  "routes": [
    {
      "pattern": "example.com",
      "custom_domain": true
    }
  ]
}

Cloudflareの公式資料では、Worker自身をオリジンとして使う場合にCustom Domainが適しています。既存のオリジンサーバーの前段でWorkerを動かす場合はRoutesが想定されており、用途が異なります。

発生した問題

GitHub Actionsでは、先に次の検証を行っていました。

npm ci
npm run check
npm run build
npx wrangler deploy --dry-run

型検査、Astroのビルド、Wranglerのdry-runは成功しました。しかし、認証情報を設定して実際にwrangler deployを実行すると、Workerの配置後にCustom Domainの作成でエラー100117となりました。

ここで重要なのは、dry-runの成功がDNS変更やCustom Domain作成の成功まで保証するわけではないことです。また、デプロイコマンド全体が失敗していても、Worker本体の配置が終わっている場合があります。

そのため、次の2項目を分けて確認しました。

確認対象	確認方法
Worker本体	Workers & Pagesのデプロイ履歴、または有効にしている場合はworkers.devで確認
Custom Domain	WorkersのDomains & Routesと、対象ホスト名のDNSレコードで確認

調査手順

1. 対象ホスト名のDNSを確認する

まず、Custom Domainに指定したホスト名だけを調べます。

dig +noall +answer example.com A
dig +noall +answer example.com AAAA
dig +noall +answer example.com CNAME

今回の対象はルートドメインで、以前の仮ページへ向けるAレコードが残っていました。

CloudflareのCustom Domainは、対象ホスト名のDNSレコードと証明書をCloudflare側で管理します。公式の移行手順でも、既存CNAMEを削除してからcustom_domain: trueを設定し、wrangler deployを実行する流れが案内されています。

エラーコードだけを見てレコードを削除せず、少なくとも次を記録します。

• レコード種別
• ホスト名
• 接続先
• Proxy status
• TTL
• 何のサービスが使っているか
• 元に戻す場合の値

2. メール用レコードを別に確認する

同じドメインでメールを使っている場合、Web用レコードとメール用レコードを混同しないようにします。

dig +noall +answer example.com MX
dig +noall +answer example.com TXT
dig +noall +answer _dmarc.example.com TXT

DKIMのホスト名はメールサービスごとに異なるため、管理画面に表示されたセレクターも確認します。

今回変更対象にしたのは、Custom Domainと同じホスト名にあったWeb用Aレコード1件だけです。MX、SPF、DKIM、DMARC、ドメイン所有権確認用TXTは変更しませんでした。

原因

原因は、Custom Domainとして使うホスト名と、以前のWeb公開先に向けたAレコードが競合していたことでした。

Wranglerの設定自体やAstroのビルド成果物に問題があったわけではありません。そのため、設定ファイルを何度も変更するより、次の3層に分けて確認する方が早く原因へ到達できました。

1. 静的サイトのビルド
2. WorkerへのStatic Assets配置
3. Custom DomainのDNS・証明書設定

解決方法

1. 既存レコードの用途と戻し方を確認する

対象Aレコードが取得サービスの仮ページ用であり、今後は使わないことを確認しました。値を記録し、削除による影響範囲を確認してから変更します。

本番サイトや他システムが利用しているレコードを、エラー解消だけを目的に削除してはいけません。用途が判断できない場合は、そこで作業を止めます。

2. 競合するWeb用レコードだけを削除する

CloudflareのDNS管理画面から、Custom Domainと同じホスト名にある既存Aレコードを削除しました。

削除対象は1件に限定し、メール用のMX・TXTは残します。DNSの一括削除やゾーンの作り直しは行いません。

3. 再度デプロイする

npm run build
npx wrangler deploy

GitHub Actionsを使う場合も、検証済みのmainからだけデプロイするようにします。認証情報はRepository SecretsまたはEnvironment Secretsに保存し、設定ファイルやログへ出力しません。

今回のワークフローでは、PRでビルドとdry-runを行い、main更新時だけデプロイジョブを実行しました。再実行後はビルドジョブとデプロイジョブの両方が成功しました。

動作確認

Custom Domain作成後は、デプロイ成功の表示だけで終わらせず、実際の配信を確認しました。

HTTPステータス

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/not-found-check

確認結果は次のとおりです。

• トップページ：200
• 存在しないURL：404

not_found_handlingに404-pageを指定すると、Static Assetsに一致しないリクエストへ最も近い404.htmlを返し、HTTPステータスも404になります。

配信HTMLとローカル成果物

curl -fsS https://example.com/ > /tmp/remote-index.html
cmp --silent dist/index.html /tmp/remote-index.html
echo $?

今回の確認では終了コード0となり、配信HTMLとローカルのdist/index.htmlが一致しました。ブラウザーでもPC表示と幅375pxの表示を確認し、横方向のはみ出しがないことを確認しました。

DNSレコード

切り替え後に、次を再確認しました。

• Custom DomainがActiveになっている
• HTTPSでアクセスできる
• Web用の競合レコードが残っていない
• MX、SPF、DKIM、DMARC、ドメイン確認用TXTが維持されている

注意点

Custom DomainとRoutesを混同しない

WorkerがオリジンならCustom Domain、既存オリジンの前段でWorkerを実行するならRoutesが基本です。Routesでは事前に対象ホスト名のCloudflare Proxied DNSレコードが必要です。Custom Domainの競合を、Routesの手順で解消しようとすると判断を誤ります。

DNS変更とデプロイを別々に記録する

デプロイコマンドの終了結果だけでは、どこまで反映されたか分かりません。少なくとも次を別々に記録します。

• ビルドの成功
• Workerバージョンの配置
• Custom Domainの作成
• 証明書の有効化
• 公開URLのHTTP確認
• メール用DNSの維持

変更前の値を残す

DNSレコードを削除する前に、元の値と用途を控えます。復旧が必要になった場合に、推測でレコードを作り直さないためです。

まとめ

Cloudflare WorkersのCustom Domain作成でエラー100117が発生した今回の原因は、対象ホスト名に残っていたWeb用Aレコードでした。

解決で効果があったのは、エラーの再実行を繰り返すことではなく、処理を「Workerの配置」と「Custom Domainの作成」に分け、対象ホスト名のDNSを棚卸ししたことです。

特に同じドメインでメールを運用している場合は、競合するWeb用レコードだけを変更し、MXやTXTを対象外にすることが重要です。最後にHTTPS、404、配信内容、DNSを確認すると、単なるデプロイ成功ではなく、利用者がアクセスできる状態まで検証できます。

参考資料

• Cloudflare Workers：Custom Domains
• Cloudflare Workers：Routes and domains
• Cloudflare Workers：Static Assets
• Cloudflare Workers：Static Site Generation and custom 404 pages
• Cloudflare Workers：Wrangler configuration

公式資料の確認日：2026年10月2日。