1つのドメインの下に Cloudflare Pages・Cloudflare Workers・Vercel の3つの配信基盤を合流させる、本番構成のフィジビリティ検証環境です。

メイン部分（このページ）を Cloudflare Pages が配信し、特定のパスだけを Workers ルートが横取りして別の基盤から配信します。どのパスがどこから配信されているかは、各ページの背景色とレスポンスヘッダで確認できます。

パスと配信基盤

リクエストの流れ ブラウザ junction.liberogic.org Workers ルートで振り分け Cloudflare / /sub1/* /sub2/* Cloudflare Pages junction-main（Astro） Cloudflare Workers junction-sub1（静的アセット） Cloudflare Workers junction-sub2-proxy Vercel junction-sub2-origin デプロイの流れ junction-main GitHub Git 連携（push で自動） Cloudflare Pages junction-main junction-sub1 GitHub release → Workers Builds Cloudflare Workers junction-sub1 その他ブランチ → Git 連携（自動） Vercel（preview） junction-sub1 junction-sub2-origin GitHub Git 連携 Vercel junction-sub2-origin
/
Astro + Cloudflare Pages（このサイト）。メインサイト相当で、Git 連携により自動デプロイされる。
/sub1/
別リポジトリで管理する Cloudflare Workers（静的アセット配信）。release ブランチへの昇格だけが本番デプロイの経路で、Workers Builds が自動ビルドする。それ以外のブランチは Vercel でプレビュー配信される。→ 方式①
/sub2/
Worker によるリバースプロキシ。Vercel 上のオリジンをそのまま表示し、リダイレクトの書き換えとヘッダの調整を行いながら中継する。→ 方式②

① 開発は Vercel、本番は Cloudflare

ポイントは、Vercel を開発のための環境として割り切ることです。プレビューや確認は使い慣れた Vercel の仕組みをそのまま使い、本番配信だけを Cloudflare が受け持ちます。本番公開の唯一の経路は release ブランチで、Cloudflare の Git 連携（Workers Builds）がこのブランチだけを監視しています。

  1. ブランチを push すると、Vercel の Git 連携がプレビューを自動デプロイする（release のみ除外）。確認・レビューはすべて Vercel 上で行う
  2. 確認が済んだら、承認ゲート付きのワークフローで release ブランチを進める（直 push は保護ルールで禁止）
  3. release への push を Cloudflare の Git 連携が検知し、自動ビルドして本番配信する

Vercel 環境: junction-sub1.vercel.app/sub1/ （新しいタブで開く） （Basic 認証あり ID: sub1 / Pass: preview）

メリット

  • 本番の契約・配信を Cloudflare に一元化できる（コンプライアンス・管理面）
  • Cloudflare の API トークンを外部に配布しなくてよい（Git 連携はリポジトリ単位で閉じる）
  • 開発チームは Vercel のプレビュー体験と既存ワークフローをそのまま維持できる
  • 本番公開の経路が「保護ブランチ + 承認」に一本化され、監査しやすい

デメリット

  • プレビューと本番で配信基盤が異なるため、Vercel 固有の設定（リダイレクトやヘッダなど）は Cloudflare 側での再現が必要
  • 2 つの基盤の設定を保守する二重管理になる
  • 「本番だけで起きる差異」を潰すための事前検証（この junction のような環境）が必須

② Vercel をそのまま活かして proxy 配信

Vercel の環境には一切手を入れず、Cloudflare の Worker がリバースプロキシとしてドメイン配下に取り込む方式です。オリジン側から見るとこれまで通り Vercel に公開しているだけなので、システムとして完全に切り分けられるのが特徴です。

Vercel 環境（オリジン直接）: junction-sub2-origin.vercel.app/sub2/ （新しいタブで開く） （認証なし・noindex 付き）

メリット

  • オリジン側（Vercel）の構成・運用を一切変えずに導入でき、関係者間の調整が最小で済む
  • 導入が最速（小さな Worker を 1 つ置くだけ）
  • プレビューも本番も同じ Vercel 配信のため、環境差異が原理的に生じない

デメリット

  • 本番配信にも Vercel を利用し続けるため、アクセス数の増加で Vercel 側の課金・帯域制限の問題が起きやすい
  • Vercel の障害やメンテナンスがそのまま本番障害になる（依存が残る）
  • 本番の実体が Vercel にあることになり、契約・データ取り扱いの一元化にはならない
  • リダイレクトの書き換え・ヘッダ調整・Deployment Protection との干渉など、proxy 特有の調整が必要

検証していること

  • Pages のカスタムドメインと Workers ルートの同一ホスト同居（パス単位の振り分け）
  • サブパス配信（クリーンURL・トレイリングスラッシュ・404 の境界）
  • API トークンを配布しない本番デプロイ経路（保護ブランチ + Workers Builds）
  • プロキシ越しのリダイレクト・ヘッダ・キャッシュの挙動
/sub1/ を見る /sub2/ を見る

なぜすべて Cloudflare Workers で実現しないのか

プレビューも本番も Cloudflare に寄せてしまう方が、一見シンプルに見えます。しかし「メインサイトはアカウント管理者（リベロジック）、サブパスは外部の開発チーム」という体制では、権限の切り方に無理が出ます。参考として受け取った Vercel 前提の GitHub Actionsをそのまま Cloudflare に向け替える案を検討した結果、見送った理由は次の通りです。

  • Cloudflare の API トークンは Workers の編集権限をアカウント単位でしか発行できない（特定の Worker だけに絞れない。2026年8月時点）。外部チームのリポジトリの GitHub Actions にトークンを渡すと、同じアカウント上のすべての Worker の編集権限を渡すことになり、責任分界点が曖昧になる
  • プレビュー環境まで Cloudflare で組もうとすると、Workers Builds の接続・ルート・トークン管理などアカウント側の設定が絡み、本番前のワークフロー構築のたびにアカウント管理者（リベロジック）の関与が必要になる。開発チームが自走できない
  • そこで本番だけを「Git 連携 + release ブランチ」で Cloudflare に接続し、トークンを一切配布せずリポジトリ単位で権限を閉じる構成（①の方式）にした

Vercel だからこそできること

  • 開発チーム自身の契約・アカウントで完結する権限モデル。プレビュー環境をいくら作り込んでも、こちらの Cloudflare アカウント（他サイトの本番資産）には一切触れない
  • ブランチを push するだけの自動プレビュー URL 発行が標準機能で、PR ごとの確認フローを開発チームだけで回せる
  • Edge Middleware による Basic 認証（sub1 で実証。数行のベタ書きで済む）や Deployment Protection、プレビューの自動 noindex など、「確認用の非公開環境」を守る機能が揃っている
  • Issue 起票 → AI 修正 → PR → プレビューのような実験的な開発ワークフローも、本番資産から隔離されたまま Vercel 側で自由に構築できる

なお、Cloudflare は個別リソース単位のロール（resource-scoped roles）を Zero Trust 系から順次展開しており、将来「特定の Worker だけに絞った API トークン」が発行できるようになれば、この判断は見直す余地があります。