Next.jsで16,422件の人物DBと20,000件規模の作品DBを扱うサイトをCloudflare Pagesへ配備した。顔照合はONNX Runtime Webを使い、ブラウザ内で実行する。
実装中に別々に見えた3つの制約が、実際には配信方式を通じて相互に影響した。
- 1ファイルのサイズ
- 1デプロイのファイル数
- Workerのバンドルサイズ
この記事では、2026年8月の無料プラン環境で採用した構成と、なぜ単純な全SSG／全SSRを選ばなかったかを説明する。
Cloudflareは2026年8月現在、新規のNext.jsアプリでは vinext を推奨している。本稿は、すでに @cloudflare/next-on-pages で動いていた既存サイトを制約内へ収めた記録であり、新規案件で同じアダプターを選ぶことを推奨するものではない。
検証環境はNext.js 16.2.4、React 19.2.4、@cloudflare/next-on-pages 1.13.16。
問題1: ONNX Runtime WebのWASMが大きい
ビルド成果物には ort-wasm-simd-threaded.jsep.wasm が入り、1ファイル上限25MiBを超えた。
ただし実装では、WASMの読み込み先をCDNへ明示していた。
const ort = await import('onnxruntime-web');
ort.env.wasm.numThreads = 1;
ort.env.wasm.wasmPaths =
`https://cdn.jsdelivr.net/npm/onnxruntime-web@${ort.env.versions.web}/dist/`;
ビルド成果物側のWASMは実行時に使われない重複物だった。そこでビルド後に24MiBを超えるファイルを走査し、配備対象から除外した。
const LIMIT = 24 * 1024 * 1024;
if (statSync(file).size > LIMIT) {
unlinkSync(file);
}
ポイントは「大きいから削除」ではなく、実行時にどこからロードされるかを先に固定したことだ。ローカルWASMを使う構成なら、この削除は実行時障害になる。
問題2: すべて静的生成するとファイル数が増える
人物詳細をすべて静的生成すると、HTMLだけでなくRSCなど複数ファイルがURLごとに生成される。16,422 URLをそのままSSGすると、Freeプランの1デプロイ20,000ファイル上限に収まらなかった。
最初は生成件数を8,000、100、1,500と変えたが、これは本質的な解決ではない。未生成URLが404になるか、サイトマップと公開ページが食い違うからだ。
そこで大量の詳細ページをSSRへ移した。
/actress/[id]/item/[id]
一方、検索、ランキング、ガイド、かな索引などURL数が限定されたページは静的生成のままにした。
問題3: すべてSSRにするとWorkerが大きくなる
大量ページを動的にしたあと、今度は静的ページまでEdge Runtimeへ寄せるとWorkerのバンドルサイズが増えた。Workers Freeの圧縮後Workerサイズ上限は3MBだった。
静的ページで使うJSONは、ビルド時にローカルファイルから読む。
import fs from 'fs';
import path from 'path';
const DATA_DIR = path.join(process.cwd(), 'public', 'data');
export function readData(...segments) {
return JSON.parse(
fs.readFileSync(path.join(DATA_DIR, ...segments), 'utf8')
);
}
これにより、静的化できるページはWorkerへデータ読み込みコードを持ち込まない。
_routes.json をビルド後に限定する
next-on-pages が生成した _routes.json は、当時の構成では全URLをWorkerへ通す設定になった。大きなモデルやベクトルもWorkerを経由すると、不要な呼び出しが増える。
動的処理が必要なURLだけに限定した。
{
"version": 1,
"include": [
"/actress/*",
"/item/*",
"/api/*"
],
"exclude": []
}
このJSONはビルド後スクリプトで毎回書き換え、手作業による反映漏れを防いだ。
最終的な分担
| 対象 | 配信方法 | 理由 |
|---|---|---|
| 人物・作品の詳細 | SSR | URL数が多く、全SSGではファイル数が増える |
| 検索・ランキング・ガイド | 静的 | URL数が限定され、Workerを使う必要がない |
| JSON・ベクトル・モデル | 静的アセット | 大容量データをWorkerへ載せない |
| 顔照合 | ブラウザ | 利用者画像をサーバーへ送らない |
| ONNX RuntimeのWASM | CDN | 重複する大容量WASMを配備物から外す |
ビルド後に確認すること
デプロイ成功だけではなく、次をsmoke testへ入れた。
- 主要URLが200を返す
- 動的な人物・作品URLが開く
- ベクトル件数とメタデータ件数が一致する
- ベクトルが正規化されている
- 日本語名、読み仮名、ローマ字、誤字の検索例が通る
- サイトマップに公開対象だけが載る
_routes.json の内容と25MiB超ファイルの不在も、デプロイ前にread-backする。
まとめ
今回の構成は、単一の最適化ではなく3制約の折衷だった。
- 大量URLだけ動的にする
- それ以外は静的にする
- 大きなデータは静的アセットとして配る
- ブラウザ推論用の実行ファイルは読み込み先を明示する
- 生成物をビルド後に検査・補正する
DBサイトでは、ページ数、バンドル、モデルサイズを別々に考えると設計が行き詰まる。URL、実行環境、データ転送を一つの配信設計として決める必要があった。
公式資料
この構成は、ブラウザ内顔検索を行うAI AV MATCH（18歳以上向け）の開発で使用した。