Junction

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 上のオリジンをそのまま表示し、リダイレクトの書き換えとヘッダの調整を行いながら中継する。

sub1 方式：開発は 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 のような環境）が必須

sub2 方式：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/ を見る