同一ドメインでWordPressとVercelを共存させる｜Cloudflare Workerによるパス振り分け設計【AI活用検証vol.62】

「WordPressで動いているサイトの /blog だけを別のホスティングに向けたい」——この要件は、DNSの設定だけでは実現できません。

理由は単純です。DNSはIPアドレスまでしか届けられず、パスを見ないからです。この検証では、Cloudflare Workerを使って同一ドメイン上にWordPressとVercelを共存させる構成を作りました。

この検証の概要

結論：DNSはIPまでしか届けられない

この検証で最も重要な概念がこれです。

example.com/blog と example.com/ のどちらも、DNS解決の結果は同じIPです。パスによる振り分けはLayer7（アプリケーション層）での処理が必要になります。

DNSレコードにはAレコード、CNAME、MX、TXT、NS、CAAといった種類がありますが、どれもパスを見る仕組みを持ちません。「ドメイン名 → IPアドレス」の対応表だからです。

ここを理解していないと、よくある事故が起きます。Aレコードを新しいホスティング先に向けた結果、WordPress全体が飛ぶというものです。パスだけ変えたつもりが、ドメイン全体の向き先を変えてしまっています。

パス振り分けはWorkerの仕事。この一言が構成の全体像を決めます。

サブパスとサブドメイン、どちらを選ぶか

今回サブパス方式を採用したのは、要件が「同一ドメインでVercelを表示したい」だったためです。CNAMEを使うサブドメイン方式では要件を満たせません。

技術的な難易度はサブドメイン方式のほうが低いため、要件がURLの見た目にこだわらないなら、そちらを選ぶほうが早いという判断もあり得ます。

「踏み台Pages」は不要だった

設計変更の記録として残しておきたい点です。

当初はドメインの受け口としてCloudflare Pagesを挟む「踏み台Pages」構成を想定していました。しかし検証の過程で、Cloudflare Workers の Settings → Domains & Routes → Custom Domain でカスタムドメインをWorkerに直接紐づけられることが判明しました。

Pagesは不要になり、手順がシンプルになります。これはCloudflareを使ったプロキシ戦略の中でも最もシンプルな構成です。

あわせてCustom DomainとRouteの違いも整理しました。

• Custom Domain — ドメインまるごと紐づけ（シンプル）
• Route — パターンマッチング（example.com/blog*）で細かく制御可能

CSSが崩れる原因：/_next/ がWorkerを素通りしていた

実装で最も詰まったのがここです。

ページ自体は表示されるのに、CSSが崩れるという状態になりました。原因は、Next.jsの静的アセットが example.com/_next/static/... から取得されるため、/blog の条件だけではWorkerを素通りして404になっていたことです。

対応は、isVercelPath 関数に /_next/ と /favicon の条件を追加して再デプロイすることでした。

サブパスでフレームワークをホストする場合、ページのパスだけを転送しても足りません。そのフレームワークがどこからアセットを取りに行くかを確認する必要があります。

DNS移行時のMXレコードリスク

この構成に入る前段として、Cloudflareへのネームサーバー移管があります。

移管時、MXレコードが自動スキャンで取り込まれない場合があるため、移管前のスクリーンショット保管が重要です。MXが欠けたまま切り替わると、メールが止まります。

あわせて、Cloudflareの「オレンジクラウド」のオン/オフはプロキシのオン/オフを意味します。多くのエンジニアが混同しやすいポイントですが、「DNSはIPまでしか届けられない」という前提を置くと理解しやすくなります。

ドキュメントで詰まった点

技術以外の記録も残しています。

• 初版の手順書に「踏み台Pages」が含まれており、実際の構成と乖離していた — 手順書の初版作成前に「踏み台Pagesは本当に必要か」を先に検証すべきだった
• 構成図の日本語フォント問題 — DejaVu Sansでは日本語が欠落し、2回作り直しが発生。plt.rcParams['font.family'] = 'IPAGothic' を明示的に指定して解決

構成図の生成はPython（matplotlib）で行っています。日本語を含む図を生成するなら、フォント指定をデフォルトの手順に組み込んでおくと作り直しが減ります。

残っている課題

• Vercel側のNext.jsプロジェクトで basePath: '/blog' の設定が必要なケースがある（フレームワーク依存）
• 他ドメインでの汎用性検証は未実施

よくある質問

なぜDNSだけでパスの振り分けができないのですか？

DNSはドメイン名をIPアドレスに変換する仕組みで、パスを見ないためです。example.com/blog も example.com/ も、DNS解決の結果は同じIPになります。パス振り分けはLayer7での処理が必要です。

Cloudflare Pagesを踏み台にする必要はありますか？

不要です。Workers の Settings → Domains & Routes → Custom Domain でカスタムドメインをWorkerに直接紐づけられます。この方式が最もシンプルです。

CSSが崩れるのはなぜですか？

Next.jsの静的アセットが /_next/static/... から取得されるためです。Workerのルーティング条件に /blog だけでなく /_next/ も含める必要があります。

ネームサーバー移管で注意することは？

MXレコードが自動スキャンで取り込まれない場合があります。移管前にDNSレコードのスクリーンショットを保管しておくことを推奨します。

まとめ

• DNSはIPまでしか届けられない。パス振り分けはWorkerの仕事——これが構成の出発点
• サブパス方式（example.com/blog）はDNSでは実現できず、Cloudflare Workerによるルーティングが必要
• Custom DomainをWorkerに直接紐づけられるため「踏み台Pages」は不要。最もシンプルな構成になる
• CSSが崩れる原因は/_next/ パスがWorkerを素通りしていたこと。アセットのパスも転送条件に含める
• ネームサーバー移管時はMXレコードが自動スキャンで漏れることがある。移管前の記録が重要
• Workerコードは約30行、ホスティングコストは$0（Cloudflare Free + Vercel Free）

同一ドメインで複数のサービスを共存させる構成は、既存サイトを残したまま新しい仕組みを足したいときに有効です。どのレイヤーで振り分けるかを最初に決めておくと、事故を避けられます。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のWeb・インフラ構築を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。