---
title: "同一ドメインでWordPressとVercelを共存させる｜Cloudflare Workerによるパス振り分け設計"
excerpt: "「WordPressのドメインの/blogだけをVercelに向けたい」という要件を、Cloudflare Workerのルーティングで実現しました。DNSはIPまでしか届けられずパスを見ないという前提、踏み台Pagesが不要になった設計変更、/_next/がWorkerを素通りしてCSSが崩れた原因までをまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-04-07T00:00:00+00:00
verified_at: 2026-04-07T00:00:00+00:00
tools: ["Cloudflare", "Vercel"]
tasks: ["開発・エンジニアリング", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/cloudflare-dns-worker-proxy
---
# 同一ドメインでWordPressとVercelを共存させる｜Cloudflare Workerによるパス振り分け設計

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2026年4月7日〜（検証中） |
| 使用ツール | Cloudflare Workers / Cloudflare DNS / Vercel（Next.js）/ WordPress（レンタルサーバー） |
| やりたかったこと | WordPressで動いているドメインの `/blog` パスだけをVercelの静的サイトに向ける |
| 成果 | `/blog/` でVercelのコンテンツが表示されることを確認。**手順書（Step1〜6、約200行のMarkdown）と全体構成図を整備** |
| Workerコード | **約30行**（`isVercelPath` 関数 + fetch転送ロジック） |
| コスト | Cloudflare Free：$0／Vercel Free：$0（Workersも個人用途はFreeで対応可） |

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

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

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

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

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

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

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

| 方式 | 例 | 実現方法 |
| --- | --- | --- |
| サブドメイン方式 | `app.example.com` | CNAMEで実現できる（簡単） |
| **サブパス方式** | `example.com/blog` | **DNSでは不可。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・インフラ構築を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。