---
title: "WordPressの/blogだけVercelで配信する方法｜Cloudflare Worker設定手順"
excerpt: "既存のWordPressサイトはそのままに、/blog のようなサブパスだけをVercelの静的サイトで配信する方法を解説します。Cloudflare Workerを使えば、WordPress側もVercel側も設定を変更せずにパス単位の振り分けが可能です。ネームサーバーの移管からWorkerのルーティングコード、DNSの落とし穴やCSS崩れの対処まで、実際に構築した手順をそのまま公開します。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-06-01T00:00:00+00:00
verified_at: 2026-06-01T00:00:00+00:00
tools: ["Cloudflare", "Vercel"]
tasks: ["開発・エンジニアリング", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/cloudflare-worker-vercel-subpath
---
# WordPressの/blogだけVercelで配信する方法｜Cloudflare Worker設定手順

「既存のWordPressサイトはそのまま残したい。でも、新しく作るブログやオウンドメディアだけはNext.jsで作ってVercelに置きたい」——このリクエストは実務で非常によく発生します。しかも**サブドメイン（blog.example.com）ではなく、サブパス（example.com/blog）で配信したい**というケースがほとんどです。

この記事では、Cloudflare Workerを使って**WordPress側もVercel側も設定を一切変更せずに**、URLのパス単位でリクエストを振り分ける方法を、実際に構築した手順そのままで解説します。ネームサーバーの移管からWorkerのルーティングコード、つまずきやすいDNSトラブルやCSS崩れの対処までを一通りカバーします。

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2026年6月 |
| 使用ツール | Cloudflare Workers / Vercel / WordPress |
| やりたかったこと | 既存のWordPressサイトを残したまま、`example.com/blog` だけをVercelの静的サイトで配信する |
| 結論 | Cloudflare Workerを1つ作るだけで実現できた。WordPress側・Vercel側の設定変更は不要 |
| 費用 | Cloudflareの無料プランの範囲内 |
| つまずいた点 | DNS移管時のMXレコード消失、Next.jsの `/_next/` アセットが404になりCSSが崩れる |

## 結論：Cloudflare Worker 1つでサブパス振り分けは完結する

先に結論を書きます。**example.com/blog だけをVercelに、それ以外をWordPressに振り分ける構成は、Cloudflare Workerを1つ作るだけで実現できます。**踏み台としてのCloudflare Pagesも、WordPress側のリバースプロキシ設定も、Vercel側のドメイン設定変更も必要ありません。

ポイントは次の2点です。

-   **DNSはIPアドレスまでしか届けられない**。「/blogだけ別サーバー」という*パス単位*の振り分けはDNSの守備範囲外で、これはCloudflare Workerの仕事になります
-   **Workerにはカスタムドメインを直接紐づけられる**。Settings → Domains & Routes から example.com をWorkerに割り当てれば、全リクエストがWorkerを経由します

> この構成は、WordPressで運用中の企業サイトに、Next.jsで作った高速なオウンドメディアを後から合流させたい場合の定番パターンです。

## なぜサブドメインではなくサブパスで配信するのか

**サブパス（example.com/blog）での配信が選ばれる最大の理由は、ドメインの評価を1つに集約できるからです。**

検索エンジンは blog.example.com と example.com を、原則として**別サイト**として扱います。せっかく本体サイトが積み上げた被リンクやドメインの評価は、サブドメインのメディアにはそのまま引き継がれません。一方サブパスであれば同一サイト内のコンテンツとして扱われるため、本体サイトの評価を土台にした状態でメディアを立ち上げられます。

| 構成 | URL例 | ドメイン評価 | 構築の難易度 |
| --- | --- | --- | --- |
| サブドメイン | blog.example.com | 本体と分離されやすい | 低（DNSのCNAME1本） |
| **サブパス** | **example.com/blog** | **本体に集約できる** | 中（プロキシが必要） |

サブパス構成は「やりたいけれど、技術的にどう実現するかで詰まる」典型例です。その解決策が、これから解説するCloudflare Workerによるプロキシです。

## 全体の構成イメージ

完成後の構成は次の図の通りです。ユーザーからのリクエストは必ずCloudflare Workerを通り、Workerがパスを見てWordPressとVercelのどちらに転送するかを決めます。

![Cloudflare WorkerがリクエストをWordPressサーバーとVercelにパス単位で振り分ける全体構成図](/assets/images/column/cloudflare-vercel-subpath-proxy.webp)

```
ユーザー
  ↓（DNS解決 → CloudflareのIPが返る）
Cloudflare Worker（example.com に直接紐づけ）
  ├── /blog, /blog/*, /_next/* → Vercel（静的サイト）
  └── それ以外                → WordPressサーバー（さくら / Xサーバー等）
```

設定は次の4ステップに整理できます。

1.  レジストラのネームサーバーをCloudflareに変更する
2.  Cloudflare DNSでA / MX / TXTレコードを確認・整備する
3.  Workerを作成し、Custom Domainで example.com を直接紐づける
4.  Workerにルーティングコードを書いてデプロイする

## Step1｜Cloudflareにドメインを追加する

### アカウントを作成する

[Cloudflare公式サイト](https://cloudflare.com)から「Sign Up」でメールアドレスとパスワードを登録します。**プランはFreeで問題ありません。**今回の構成に必要な機能はすべて無料枠で使えます。

### ドメインを追加する

1.  ダッシュボードから「Add a Site」を選択
2.  ドメイン名（例：`example.com`）を入力
3.  プランはFreeのまま続行
4.  CloudflareがDNSレコードを自動スキャンして取り込む

この自動スキャンで既存のレコードが引き継がれますが、**完全ではありません。**次のStepで必ず中身を確認します。

## Step2｜ネームサーバーをCloudflareに変更する

ドメイン追加後の画面に、Cloudflareが指定する2つのネームサーバーが表示されます。

```
xxx.ns.cloudflare.com
yyy.ns.cloudflare.com
```

この値を、ドメインを取得したサービス側の管理画面で設定します。

| サービス | 設定場所の目安 |
| --- | --- |
| お名前.com | ドメイン設定 → ネームサーバーの変更 |
| さくらインターネット | ドメインメニュー → ネームサーバー設定 |
| Xサーバー | サーバーパネル → ドメイン設定 |

> **反映には最大48時間かかります。**Cloudflareのダッシュボードに「有効化されました」と表示されれば完了です。作業は余裕を持ったスケジュールで進めてください。

## Step3｜DNSレコードを確認・整備する

**この記事で最も事故が起きやすいのがこのStepです。**ネームサーバーの移管が完了したら、Cloudflareのdns管理画面でレコードを1つずつ確認します。

| 種別 | 名前 | 値 | プロキシ（オレンジ雲） | 用途 |
| --- | --- | --- | --- | --- |
| A | `@`（ルート） | WordPressサーバーのIP | オン | WordPressへの通信 |
| A | `www` | WordPressサーバーのIP | オン | wwwアクセス |
| MX | `@` | メールサーバー | **オフ** | メール配送 |
| TXT | `@` | SPF / サーチコンソール等 | — | 各種認証 |

### 特に注意すべき2つのレコード

-   **MXレコード**：自動スキャンで取り込まれているか必ず確認してください。ここが消えていると**メールが一切届かなくなります**。またMXレコードはプロキシを**オフ**にする必要があります
-   **TXTレコード**：Google Search Consoleの所有権確認やSPF・DKIMの設定が引き継がれているか確認します。消えるとメールの到達率低下やSearch Consoleの計測断につながります

> **移管前に、現在のDNSレコード一覧のスクリーンショットを必ず撮っておいてください。**何かが消えたときに、元の値がわからないと復旧できません。

### WordPressサーバーのIPアドレスの調べ方

さくらインターネットやXサーバーなどのサーバー管理画面で、「サーバー情報」または「IPアドレス」の項目に記載されています。

## Step4｜Workerを作成しカスタムドメインを紐づける

**Cloudflare Workerとは、Cloudflareのエッジ（世界中の拠点）でリクエストを受け取り、任意のJavaScriptを実行できる仕組みです。**今回はこれを「リクエストの交通整理役」として使います。

### Workerを新規作成する

1.  Cloudflareダッシュボード → **Workers & Pages**
2.  「Create」→「Create Worker」
3.  名前をつける（例：`blog-proxy`）
4.  デフォルトのコードのまま、いったん「Deploy」

### カスタムドメインを直接紐づける

1.  作成したWorkerを開き、「Settings」タブへ
2.  「Domains & Routes」セクションの「+ Add」をクリック
3.  モーダルで **「Custom Domain」** を選択
4.  `example.com` を入力して追加

RouteとCustom Domainの2択が表示されますが、今回は**Custom Domainを選んでください。**違いは次の通りです。

| 方式 | 挙動 | 今回の適性 |
| --- | --- | --- |
| **Custom Domain** | ドメインまるごとWorkerに紐づける | **適する**（Worker内でパス判定するため） |
| Route | `example.com/blog*` のようにパターンで制御 | 今回は不要 |

追加後、CloudflareのDNS管理画面にWorker向けのレコードが自動で追加されているか確認しておきます。

## Step5｜振り分けロジックを実装する

Workerの「Edit Code」を開き、以下のコードを貼り付けます。

```
const BLOG_ORIGIN = 'https://your-app.vercel.app'; // ← VercelのURLに変更

function isVercelPath(path) {
  return path === '/blog'
    || path.startsWith('/blog/')
    || path.startsWith('/_next/')   // Next.jsのCSS・JS
    || path.startsWith('/favicon'); // ファビコン
}

export default {
  async fetch(request) {
    const url  = new URL(request.url);
    const path = url.pathname;

    if (isVercelPath(path)) {
      // /blog プレフィックスを除いてVercelに渡す
      const stripped = path.startsWith('/blog')
        ? (path.replace(/^\/blog/, '') || '/')
        : path;

      const target = new Request(
        BLOG_ORIGIN + stripped + url.search,
        request
      );
      target.headers.set('Host', 'your-app.vercel.app');      // ← Vercelのホスト名
      target.headers.set('X-Forwarded-Host', 'example.com');  // ← 自分のドメイン
      return fetch(target);
    }

    // /blog 以外はWordPressへ通常どおり転送
    return fetch(request);
  }
};
```

自分の環境に合わせて変更するのは、次の3か所だけです。

1.  `BLOG_ORIGIN` にVercelのデプロイURL
2.  `Host` ヘッダーにVercelのホスト名
3.  `X-Forwarded-Host` に自分のドメイン

`/_next/` の条件が入っている点が重要です。Next.jsはCSSやJavaScriptを `/_next/static/...` という**/blogを含まないパス**から読み込むため、この条件がないとアセットがWordPress側に流れて404になります。

書き換えたら「Deploy」して完了です。

## Step6｜動作確認とCSS崩れのチェック

デプロイ後、次の3つのURLを開いて期待どおりに表示されるか確認します。

| URL | 期待する結果 |
| --- | --- |
| `example.com/` | WordPressのトップページ |
| `example.com/blog` | Vercelの静的サイト |
| `example.com/blog/post-1` | Vercelの個別ページ |

ページは表示されるのにデザインが崩れている場合、原因はほぼ**Next.jsの静的アセットが404になっていること**です。ブラウザの開発者ツールのNetworkタブで `/_next/static/...` のリクエストを確認し、404になっていれば `isVercelPath` に `/_next/` の条件が入っているかを見直して再デプロイしてください。

## つまずきやすい5つのポイントと対処法

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| WordPressも含め全部Vercelに飛ぶ | AレコードをVercelのIPに向けてしまった | AレコードをWordPressサーバーのIPに戻す |
| `/blog` が404になる | Workerのパスマッチ、またはCustom Domain未設定 | `isVercelPath` の条件と Settings → Domains & Routes を確認 |
| CSSが崩れる | `/_next/` パスがVercelに流れていない | `isVercelPath` に条件を追加して再デプロイ |
| メールが届かなくなった | MXレコードが移管時に消えた | Cloudflare DNSにMXレコードを再追加 |
| 変更が反映されない | DNSのキャッシュ | 最大48時間待つ／ブラウザキャッシュをクリア |

## DNSレコード用語チートシート

DNS移管の作業中に迷わないよう、登場するレコードの役割を整理しておきます。

| レコード | 役割 | 今回の用途 |
| --- | --- | --- |
| **A** | ドメイン → IPv4アドレス | WordPressサーバーのIPを紐づける |
| **AAAA** | ドメイン → IPv6アドレス | IPv6対応時に使用（なければ不要） |
| **CNAME** | ドメイン → 別のドメイン名 | サブドメイン構成の場合に使用（今回は不使用） |
| **MX** | メール配送先サーバーの指定 | 移管後に消えていないか必ず確認 |
| **TXT** | 任意のテキスト情報 | SPF・DKIM・Search Console認証など |
| **NS** | 権威DNSサーバーの指定 | Cloudflareへの移管時にレジストラ側で変更 |

## よくある質問

### WordPress側の設定変更は必要ですか？

**不要です。**WordPressはこれまでどおり動き続けます。Cloudflare Workerがリクエストを受け取ってWordPressサーバーへ転送するだけなので、WordPress側からは通常のアクセスと同じに見えます。

### Vercel側でドメインを追加する必要はありますか？

**必須ではありません。**WorkerからVercelの `*.vercel.app` のURLへ転送する構成のため、Vercel側のドメイン設定は変更せずに動作します。

### Cloudflareの無料プランで足りますか？

足ります。Workersの無料枠は1日10万リクエストまで利用でき、通常のコーポレートサイトやオウンドメディアであれば十分な範囲です。

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

**不要です。**以前はWorkerにカスタムドメインを割り当てるためにPagesを経由する手法が紹介されることもありましたが、現在はWorkerのSettings → Domains & RoutesからCustom Domainを直接紐づけられます。

### ダウンタイムは発生しますか？

ネームサーバーの切り替えは段階的に反映されるため、Aレコードなど既存のレコードが正しく移行できていれば、原則としてサイトが落ちることはありません。ただし**レコードの設定漏れがあるとその機能だけが停止します**（MXレコードならメール）。移管前のスクリーンショットが最大の保険になります。

## まとめ

Cloudflare Workerを使えば、**WordPressとVercelを1つのドメイン上でパス単位に共存させる構成が、無料枠かつ既存環境の変更なしで実現できます。**要点を振り返ります。

-   パス単位の振り分けはDNSではできない。Cloudflare Workerの役割
-   WorkerにはCustom Domainを直接紐づけられる（Pagesの踏み台は不要）
-   最大のリスクはDNS移管時のMX・TXTレコードの消失。移管前のスクリーンショットが必須
-   CSS崩れの原因はほぼ `/_next/` パスの振り分け漏れ

サブパス構成は、既存サイトのドメイン評価を活かしたままモダンな技術スタックへ移行していくための、現実的な選択肢です。「WordPressは残したいが、新しいメディアは高速に作りたい」という状況であれば、まずこの構成を検討してみてください。

株式会社AI棒では、こうしたAI・Web技術の検証を日々行い、企業のAI活用と開発の内製化を支援しています。技術選定や構築についてのご相談は[お問い合わせフォーム](/contact)から、AI活用の伴走支援については[AI参謀](/ai-sanbo)をご覧ください。