技術記事ぎじゅつの きじ

Next.js 16互換のvinextで、コーポレートサイトをCloudflare Workersで動かす構成

Quantum Boxのコーポレートサイトは、Next.js App Router互換のvinextをCloudflare Workers上で動かしています。構成ファイル、ビルドと配信、効かないAPIへの対処をまとめます。

公開こうかい

更新こうしん

約3分で読めますやく 3ぷんで よめます

このサイト(quantum-box.com)は、Next.js 16のApp Router互換フレームワークであるvinextをCloudflare Workersで動かしています。Node.jsサーバーを持たず、Workersの1つのスクリプトと静的アセットだけで配信する構成です。ここでは実際の設定ファイルを見ながら、何がそのまま効いて、何を回避したかを書きます。

構成ファイル

vinextはViteのプラグインとして動きます。vite.config.tsでvinextとCloudflareのプラグインを組み合わせ、ビルド時だけCloudflare側の環境(rscssr)を有効にしています。

import { cloudflare } from '@cloudflare/vite-plugin';
import { defineConfig } from 'vite';
import vinext from 'vinext';

export default defineConfig(({ command }) => {
  const plugins = [vinext()];
  if (command === 'build') {
    plugins.push(cloudflare({ viteEnvironment: { name: 'rsc', childEnvironments: ['ssr'] } }));
  }
  return { plugins };
});

Workers側の入口はwrangler.tomlで指定します。mainにvinextが用意するApp Routerのエントリを書き、静的アセットはdist/clientをアセットバインディングとして配信します。

name = "corporate-site-v3"
compatibility_date = "2026-06-22"
compatibility_flags = ["nodejs_compat"]
main = "vinext/server/app-router-entry"

[assets]
directory = "dist/client"
not_found_handling = "none"
binding = "ASSETS"

nodejs_compatを付けているのは、node:processなど一部のNode.js互換APIを使うためです。環境変数はprocess.envではなくimport { env } from 'node:process'で読んでいます。

ビルドと配信

ビルドはvinext buildの1コマンドです。出力はdist/client(静的アセット)と、Workersにバンドルされたサーバーコードに分かれます。

npm ci
npm run build      # vinext build
npm run deploy     # wrangler deploy

配信の流れは次のとおりです。

  1. リクエストはWorkersのスクリプトに入る。
  2. 静的アセットに一致すればアセットバインディングから返す。
  3. 一致しなければApp Routerのサーバーコンポーネントを描画して返す。

効くもの、効かないもの

Next.jsの機能がすべて動くわけではありません。このサイトで確認できた範囲を表にします。

機能状態対処
App Router、サーバーコンポーネント動くそのまま使う
generateMetadatasitemap.tsrobots.ts動く非同期のsitemap()も待ってくれる
Route Handler(route.ts動くフォーム送信とRSSに使用
next/imageの最適化効かない<img>に幅と高さを明記する
ISRのデータキャッシュ前提にしない外部APIには短いタイムアウトを付ける

静的アセットは1ファイル25MiBまでという制限があります。紹介動画は2〜3MBに収め、ポスター画像を別に置いています。

ローカル開発

開発サーバーはvinext devです。ポートを固定しておくと、検証スクリプトから同じURLを叩けます。

npx vinext dev --port 3001

ローカルだけの設定は.dev.varsに置き、本番ではWranglerのシークレットに入れます。.dev.varsはGitに含めません。

この構成を選んだ理由

理由は3つです。

  • 不動産向けの物件CMSやゴルフ場向けの会員SaaSなど、受託案件の配信基盤をCloudflare Workersに揃えていること。
  • サーバーを常時起動しないので、コーポレートサイト程度のトラフィックなら運用コストがほぼ固定費にならないこと。
  • Next.jsの書き方を保てるので、案件で書いたコンポーネントや知見をそのまま持ち込めること。

同じ構成で業務システムを作る場合の設計判断は、Cloudflare受託開発のページにまとめています。

この記事の本文は、当社が開発・運用する文書管理サービスLibraryで管理しています。この きじの ぶんは、わたしたちが つくっている Library という ぶんしょの サービスで かんりしています。 Libraryの原文を開くLibraryの もとの ぶんを みる

相談そうだん

この記事のテーマで、開発を相談する。この きじの テーマで、かいはつを そうだんする。

記事で扱った構成や設計は、ソリューション事業部が実際の案件で使っているものです。同じ課題をお持ちでしたら、業務整理から一緒に進めます。きじに かいた つくりかたは、じっさいの しごとで つかっている ものです。おなじ こまりごとが あれば、いっしょに すすめます。

関連記事かんれんする きじ

同じテーマの記事。おなじ テーマの きじ。

技術記事一覧へ戻るきじの いちらんへ もどる