株式会社シノン 社内向けサービス群 / 現状：Next.js（App Router・Pages Router）、React SPA + Node API、その他が混在
cf-internal-app-starter がまさにこの形で、方向性は正しい。
vinext を実験中）。いま大量の Next.js を Workers に移すと、2027年にもう一度移行コストを払うことになる。
技術選定の前提が1年前の記事と大きく変わっている。まずここを揃える。以下はすべて2026年8月20日に一次情報で確認した値で、二次情報のブログ記事は採用していない。
| 項目 | 事実（2026-08-20 時点） |
|---|---|
| Hono 安定 | 最新 v4.13.3（2026-08-18 公開）。v5 は未リリース。npm 週間ダウンロード 48,340,633（2026-08-12〜18、npm 公式 API 実測）。GitHub ★約31.7k。Cloudflare 公式フレームワークガイドに専用ページあり |
| TanStack Start RC 継続 | いまだ Release Candidate。公式 overview に「TanStack Start is currently in the Release Candidate stage!」のバナー継続。npm @tanstack/react-start の latest は 1.168.48（2026-08-19）だが、これは monorepo 共通の連番であり v1.0.0 到達を意味しない。安定版の日程は未公表（Discussion #5999 は2025年12月起票・いまだ未回答） |
| React Router v8 が現行 | v7 ではなく v8 が現行。v8.0.0 が2026-06-17、v8.3.0 が2026-07-22。Node ≥22.22.0 / React ≥19.2.7 / Vite ≥7 が必須、CommonJS 廃止・ESM 専用、react-router-dom パッケージ廃止、ミドルウェアが標準機能に昇格 |
| Next.js | 最新 16.3.1 LTS（2026-08-13）。14 は EOL 済み、15 は2026-10-21 に EOL 予定 |
| @opennextjs/ cloudflare | 最新 1.20.2。peerDeps は next: >=15.5.21 <16 || >=16.2.11。Edge Runtime は未サポート（export const runtime = "edge" は削除必須）、Node Middleware（15.2〜）も未サポート |
| HonoX alpha | 依然 alpha（v0.1.61 / 2026-08-18）。README に「Breaking changes are introduced within the same major version」と明記 |
| Remix 3 Beta | React Router に吸収されて終わり、ではなく React に依存しない別フレームワークとして再出発。2026-04-30 に Beta Preview 発表。Cloudflare Workers 向け公式ガイドは未確認 |
| 項目 | 事実 |
|---|---|
| Cloudflare Vite plugin GA | v1 系が GA（GA 告知 2025-04-08、npm の v1.0.0 は2025-04-04）。最新 1.52.1。workerd 上で Vite dev サーバーを動かし、HMR を保ったまま D1/R2/DO にアクセスできる。これが現在の Workers フロントエンド開発の中心 |
| nodejs_compat が デフォルト有効に | compatibility_date が 2026-08-04 以降の Worker では nodejs_compat / nodejs_compat_v2 が自動で有効。既存の明示指定は削除不要 |
| Cloudflare Containers GA | 2026-04-13 に GA（Sandboxes と同時）。Workers Paid で利用可。lite / basic / standard-1〜4 のインスタンスタイプ |
| Workers VPC Beta | まだ Beta（「Features and APIs may change before general availability」と明記）。AWS VPC 内リソースへの接続。ベータ期間中は無料 |
| vinext 実験 | Cloudflare が2026-02-24 に発表した実験的プロジェクト。OpenNext のような「ビルド出力の変換」ではなく、Vite 上で Next.js の API 面を再実装する方式。カバー率94%、ただし 🚧 Experimental |
| Next.js Deployment Adapters API | Next.js 16.2（2026年3月）で安定版に。OpenNext の各アダプタはこの統一 API へ移行予定で、リリースは2026年末見込み |
| Wrangler | v4 系継続（最新 4.124.0）。v5 は未確認 |
技術選定で一番効いたのはこの一点なので、先に立てておく。
Next.js / TanStack Start / React Router v8 はいずれもサーバーサイドレンダリング（SSR）を中心に据えたメタフレームワークである。SSR が価値を持つのは主に次の3つのケースだ。
社内向けサービスは、この3つがすべて該当しない。さらに決定的なのが、当社の社内システムはすでに Cloudflare Access（Zero Trust）+ WARP の背後に置く方針が確定していることだ（2026-08-17 に Google Workspace SSO で決定済み）。この構成では：
| レイヤ | 採用 | 理由 |
|---|---|---|
| フロント | React + Vite + TypeScript（SPA） React 19 / Vite 7 | 既存の React 資産をそのまま活かせる。SSR 境界の複雑さがない |
| 配信 | Workers Static Assets | Worker に同梱でき API と同一オリジン。リクエスト課金なし・ストレージ課金なし。CORS も不要 |
| 開発 | @cloudflare/vite-plugin 1.52.x（GA） | 開発時も本番と同じ workerd 上で動く。ローカルからバインディングにアクセスできる |
| API | Hono 4.13.x | 週間 DL 4,830万、Cloudflare 公式ガイドあり、Workers ネイティブ。バンドルが極小 |
| DB | D1 | SQLite 互換。既存が SQLite なら移行コストが最小 |
| ファイル | R2 | egress 完全無料。添付ファイル・帳票 PDF |
| キャッシュ/設定 | KV | マスタキャッシュ・機能フラグ。業務データの正には使わない |
| ORM | Drizzle ORM 0.45.x | Cloudflare 公式ドキュメントに D1 接続手順あり。生成は drizzle-kit、適用は wrangler d1 migrations（migrations_pattern の設定が必要） |
| 入力検証 | Zod + @hono/zod-validator | 外部に API を公開するなら @hono/zod-openapi（1.6.1、v1 到達済み） |
| 認証（境界） | Cloudflare Access JWTjose で検証 | 公式の専用 SDK は存在せず、jose による手動検証が2026年8月時点でも定石。@hono/cloudflare-access ミドルウェアも利用可 |
| 認可（アプリ内） | D1 のロールテーブル | Access は「入れるか」まで。「何ができるか」はアプリの責務（§5.5） |
| テスト | @cloudflare/vitest-pool-workers 0.21.x | D1 / R2 / KV をテストファイル単位で分離してローカル実行できる |
| CI/CD | GitHub Actions（主） Workers Builds（小規模） | 既存の deploy.yml 資産を活かす |
| 監視 | Workers Logs + Logpush→R2 + Sentry | Workers Logs の保持は有料でも7日。長期保全は Logpush 必須 |
社内システムの標準。既存スターターの構成そのまま。
SEO / OGP が必要な公開系のみ。v8 の ESM 専用化・Node 22 要件を見積もること。
書き換え不能な既存 Next.js の退避。2027年の再移行を計画に明記する。
RC が11か月継続。Vite plugin 併用の不具合が未解決。技術的な筋は良い。
| 不採用 | 理由 |
|---|---|
| TanStack Start | ① 2025-09 の RC から11か月、2026-08-20 現在も公式に RC バナー継続、安定版日程は未公表。② @cloudflare/vite-plugin と TanStack の Vite プラグインを併用すると SSR ランナーで __vite_ssr_import_11__.u is not a function が出る不具合（workers-sdk #13952、2026-05-18 起票・Open）。③ RSC は「v1 初期も experimental を継続」と公式が明言。④ RC 期間中に createStartHandler のシグネチャ変更で外部連携が壊れた実績。受託開発の武器として個人・実験プロジェクトで習熟しておくことは推奨する。社内基幹に先に入れる理由が無い、というだけ。 |
| HonoX | v0.1.61、README に alpha と明記。社内基幹に載せる段階ではない |
| Next.js を新規標準に | §4.3 参照。デプロイ基盤が2026年内に作り替わる |
| Remix 3 | React 非依存の別物。Beta。既存 React 資産と接続しない |
| Prisma | Workers のサイズ上限（有料 gzip 10 MB）との相性が構造的に悪く、D1 driver adapter の GA 明言も確認できなかった。Drizzle で足りる |
| Durable Objects を 業務データの正に | 公式ガイダンス上、DO は「ユーザー単位／リアルタイム協調」向け。単一組織の申請ワークフローでは複雑性が増えるだけ |
| KV に業務データ | 結果整合。承認ステータスのような即時整合が要る値を置いてはいけない |
| Better Auth / Auth.js | Access が前段にいる社内システムでは、パスワード管理・MFA・セッションを二重に持つ意味がない。@better-auth/cloudflare という公式パッケージは存在しない（コミュニティ製のみ）。社外公開アプリを作るときだけ再検討 |
方針：SPA + Hono API へ書き換える。ただし全面同時ではなく、画面単位で切る。
| Next.js の要素 | 移行先 | 難度 |
|---|---|---|
app/**/page.tsx（クライアント寄り） | React コンポーネント + TanStack Query | 低 |
app/**/page.tsx（Server Component で DB 直叩き） | Hono のルートハンドラ + fetch に分解 | 中 |
app/api/**/route.ts | Hono のルートへ移す。Request/Response ベースなのでロジックはほぼ流用可能 | 低 |
| Server Actions | Hono の POST エンドポイント + フォーム送信 | 中 |
next/image | 素の <img>（社内なら十分）または Cloudflare Images | 低 |
middleware.ts（認証） | 不要になる — Cloudflare Access が前段で担う | — |
next/link / useRouter | React Router をライブラリとして使う（framework mode ではない） | 低 |
| ISR / SSG | 社内システムでは通常不要。必要なら KV / R2 キャッシュ | — |
app/api/**/route.ts）は Web 標準の Request/Response なので、Hono へほぼコピーで移る。社内システムの実装の大半はここに集まっているはずで、実際の書き換えは「画面のデータ取得を props 渡しから fetch に変える」ことが中心になる。
社内向けではないものが混じっていて SSR が要るなら、React Router v8 を選ぶ。TanStack Start ではない。
context.cloudflare.env から D1 / R2 / KV に直接触れるreact-router-dom パッケージ廃止。旧 @react-router/dev/vite/cloudflare（Cloudflare dev proxy）が廃止され Vite plugin への移行が必要。「暫定」と明示した上で使う。恒久的な標準にはしない。理由は基盤が2026年内に作り替わるためだ。
export const runtime = "edge" はデプロイ前に全削除。実質すべて nodejs_compat 前提handler.mjs が 未圧縮 20.68 MB / gzip 3.42 MB に膨張し上限超過。原因は AWS SDK・TanStack Query/Table・Radix UI・Drizzle・better-auth などサーバー側依存の丸ごとバンドル。gzip 後のサイズだけが上限判定に使われる（Free 3 MiB / Paid 10 MiB）フロントはそのまま Workers Static Assets へ、API を Hono に移すだけ。ここから着手する。
req/res → Hono の c.req/c.json() への機械的な置換が中心nodejs_compat は compat date 2026-08-04 以降デフォルト有効なので、Buffer / crypto / stream / path などは基本そのまま動くnode:http2 / node:vm / node:cluster はインポートできるがスタブ。ネイティブアドオン（sharp、node-canvas 等）は不可。ファイルシステムへの書き込み前提の処理も不可すべて Cloudflare 公式ドキュメントの2026-08-20 時点の値。Free プランでは業務アプリは成立しないという結論が先に出るので、そこから読んでほしい。
| 項目 | Free | Workers Paid |
|---|---|---|
| DB 最大サイズ | 500 MB | 10 GB |
| アカウント合計ストレージ | 5 GB | 1 TB |
| アカウント最大 DB 数 | 10 | 50,000 |
| Time Travel 保持 | 7日 | 30日 |
| 1 Worker 呼び出しあたりクエリ数 | 50 | 1,000 |
| 行読み取り | 500万/日 | 250億/月込み + $0.001/百万行 |
| 行書き込み | 10万/日 | 5,000万/月込み + $1.00/百万行 |
| ストレージ | 5 GB | 5 GB込み + $0.75/GB-月 |
共通の上限：テーブル最大100カラム、行 / BLOB 最大 2 MB、SQL 文最大 100,000 バイト、バインドパラメータ100個、クエリ最大実行時間30秒、1 Worker 呼び出しあたり同時接続6。
batch() は SQL トランザクション。各文を逐次実行し、途中失敗で全体ロールバックする。複数往復にまたがる対話的トランザクション（BEGIN…COMMIT を挟んでアプリのロジックを走らせる形）は使えないと考えて設計するPRAGMA optimize(-1) は非対応INSERT を wrangler d1 execute --file で流し込めば済むことが多い。ただし 1行 2 MB 上限とBLOB を D1 に入れない（→ R2 へ）の2点だけは事前に洗うこと。
GetBucketVersioning / PutBucketVersioning は未実装と公式に明記req/{id}/{uuid}/{filename}）」。上書き保存という概念を作らない。この2点をテンプレートに強制する。
| 項目 | Free | Paid |
|---|---|---|
| CPU 時間 | 10 ms | 既定30秒・limits.cpu_ms で最大5分（300,000） |
| メモリ | 128 MB | 128 MB |
| Worker サイズ（gzip 後） | 3 MB | 10 MB |
| サブリクエスト | 50/req | 10,000/req |
| 同時オープン接続 | 6 | 6 |
| 静的アセット | 20,000ファイル | 100,000ファイル（1ファイル最大 25 MiB） |
| リクエスト | 10万/日 | 1,000万/月込み + $0.30/百万 |
| CPU 課金 | — | 3,000万 ms/月込み + $0.02/百万 ms |
compatibility_date を 2026-08-04 以降にすると nodejs_compat / nodejs_compat_v2 が自動有効になる。既存の明示指定は消さなくてよい。
| 対応度 | モジュール |
|---|---|
| フルサポート | Buffer, Crypto, Events, HTTP/HTTPS, Net, Path, Process, Stream, String decoder, Timers, URL, Utilities, Web Crypto, Web Streams, Zlib |
| 部分対応 | Console, DNS, Module, OS, Performance hooks, Test runner, TLS/SSL |
| スタブのみ（動かない） | node:http2, node:vm, node:cluster ほか。ネイティブアドオン（sharp / node-canvas 等）も不可 |
当社はすでに Cloudflare Access + Google Workspace SSO で認証基盤を決めている（2026-08-17 決定）。アプリ側の設計はこれを前提にする。まずレイヤの分担を固定する。
jose ベース。既存スターターの src/worker/lib/access.ts の方針で正しい。Hono を使うなら @hono/cloudflare-access ミドルウェアも選択肢。/cdn-cgi/access/get-identity を叩く。ただし毎リクエストは重いので、アプリのロールは D1 に持ち、Access のグループは「初回プロビジョニング時の判定材料」として使う設計を推奨する。CF-Access-Client-Id / CF-Access-Client-Secret ヘッダー方式。なお名前の似た Cloudflare API の「Service Key authentication」は別物で、2026-03-19 に非推奨化・2026-09-30 に停止予定。混同しないこと。@better-auth/cloudflare という公式パッケージは存在せず（コミュニティ製 better-auth-cloudflare のみ）、Auth.js は @auth/d1-adapter があるが、社内システムでは複雑性が増すだけ。社外公開アプリを作るときだけ再検討する。| 領域 | 採用 | 根拠・注意 |
|---|---|---|
| ユニット/統合 | @cloudflare/vitest-pool-workers（0.21.x） | Miniflare 上で D1/R2/KV をテストファイル単位で分離して実行できる。実質、Cloudflare 公式の主力テスト手段 |
| E2E | Playwright（通常の test runner を CI から本番/プレビュー URL へ） | @cloudflare/playwright は「Workers 上で動く Playwright」で用途が違う。混同しない |
| CI/CD（主） | GitHub Actions | 既存資産（deploy.yml）があり、ビルド環境を自由に組める |
| CI/CD（小規模） | Workers Builds | Free 3,000分/月・Paid 6,000分/月込み、超過 $0.005/分。ビルドタイムアウト20分。Durable Objects / Containers を持つ Worker には Preview URL が生成されない、API トークンはユーザートークンのみという制約あり |
| プレビュー | Preview URLs + Versions | PR ごとに検証 URL。Preview URL にも Access を必ずかける |
| 段階リリース | Gradual Deployments | 新バージョンに数%だけ流して様子を見る |
| ローカル開発 | Vite plugin + Miniflare | D1/R2/KV はローカルエミュレート。Vectorize / Workers AI / Browser Rendering は remote: true が必要（既存スターターの設定は正しい）。DO / Workflows / 環境変数 / 静的アセット / Hyperdrive は remote: true 非対応でエラーになる |
| ログ | Workers Logs | Free 20万/日・保持3日／Paid 2,000万/月込み・保持7日、超過 $0.60/百万。単一ログ最大256 KB |
| ログ長期保全 | Logpush → R2 | 7日では監査に足りない。Phase 1 完了までに必ず稼働させる（移行の完了条件に含める） |
| APM | @sentry/cloudflare（10.x） | withSentry() でラップ。instrumentD1WithSentry で D1 計装、withMonitor で Cron 監視 |
| 状況 | 逃げ道 | 状態・コスト |
|---|---|---|
| ネイティブ依存（sharp / puppeteer / ImageMagick 等）、長時間バッチ、Rails / PHP | Cloudflare Containers GA | 2026-04-13 GA。lite(1/16 vCPU・256 MiB) 〜 standard-4(4 vCPU・12 GiB)。メモリ 25 GiB-h/月込み + $0.0000025/GiB秒、CPU 375 vCPU分/月込み + $0.000020/vCPU秒（アクティブ実行時間のみ課金）。Egress は北米/欧州 $0.025/GB（1TB/月無料枠） |
| 既存 PostgreSQL / MySQL を残したい | Hyperdrive | 追加料金なし。接続プーリング + クエリキャッシュ。Free 10万クエリ/日、Paid 無制限。制約：キャッシュ応答最大50 MB、オリジン接続 Free約20 / Paid約100、クエリ最大60秒 |
| AWS VPC 内のリソースに直接届きたい | Workers VPC Beta | まだ Beta。ベータ期間中は無料。本番の前提にしない |
| そもそも動かない / 移行の費用対効果が薄い | EC2 のまま + Tunnel + Access | すでに移行計画で決まっている構成。これで十分な業務システムは無理に動かさない |
| Phase | 期間目安 | 内容 | 完了条件 |
|---|---|---|---|
| 0. 基準の確定 | 2週 | 標準スタックを社内標準として文書化。cf-internal-app-starter を「社内テンプレート」として整備（Drizzle 導入、Sentry 導入、Logpush 設定を追加）。移行対象システムの棚卸しと分類（§7.2） | テンプレートから新規案件が立ち上がる状態 |
| 1. パイロット1本 | 4週 | 最も小さく・最も業務影響が少ないシステムを1本だけ完全移行。ここで詰まった点をテンプレートに還流する | 旧システムと並行稼働 → 2週間の実運用で問題なし |
| 2. 横展開 | 8〜12週 | 分類ごとに順次移行。SPA + Node API のもの（A）から着手（最短ルート） | 各システムで並行稼働 → 切替 |
| 3. Next.js 群の判断 | Phase 2 と並行 | 書き換え / OpenNext 暫定 / 据え置き の三分類を確定。OpenNext を選んだものは2027年の再移行を計画に明記 | 分類表が承認されている |
| 4. 旧環境の撤去 | 4週 | EC2 上の該当プロセス停止、リソース削除、コスト確認 | 切り戻し経路を1か月維持してから削除 |
| # | システム名 | 現状スタック | 利用者 | DB | 添付 | 分類 | 移行方式 | 優先度 |
|---|---|---|---|---|---|---|---|---|
| 1 | A/B/C/D | |||||||
| 2 | ||||||||
| 3 | ||||||||
| 4 | ||||||||
| 5 |
Hono へ API 移植のみ。最優先・最短。ここでチームが Workers に慣れる。
SPA + Hono へ書き換え。Route Handlers はほぼコピーで移る。
OpenNext で暫定退避。2027年の再移行を計画に明記する。
Containers または EC2 据え置き。無理に動かさない。
cf-internal-app-starter から新規リポジトリを作るmigrations/0001_init.sql に写す（BLOB カラムは R2 へ分離、2 MB 超の行がないか確認）wrangler d1 execute DB --remote --file= で本番データを流し込む（先に staging で通す）src/worker/routes/*.ts に移す（Express なら req/res → c.req/c.json()）src/client/ に移す。データ取得を api.ts 経由に統一wrangler.jsonc に設定前提：社内システム3本、利用者100名、営業日20日/月、1人1日あたり API 300リクエスト。
| 項目 | 使用量見込み | 込み枠 | 追加費用 |
|---|---|---|---|
| Workers リクエスト | 60万/月（静的アセットは課金対象外） | 1,000万/月 | $0 |
| Workers CPU | 約600万 ms/月（平均10 ms/req 想定） | 3,000万 ms/月 | $0 |
| D1 行読み取り | 約3,000万行/月 | 250億/月 | $0 |
| D1 行書き込み | 約3万行/月 | 5,000万/月 | $0 |
| D1 ストレージ | 〜1 GB | 5 GB | $0 |
| R2 ストレージ | 初年度 24 GB / 3年後 72 GB | 10 GB | $0.21 → $0.93/月 |
| R2 オペレーション | Class A 数千/月 | 100万/月 | $0 |
| Workers Logs | 数百万イベント/月 | 2,000万/月 | $0 |
| Workers Paid 基本料 | — | — | $5/月 |
| 合計 | 月 $5〜6（3年後でも $6程度） | ||
| # | リスク | 兆候 | 対応・撤退基準 |
|---|---|---|---|
| R1 | D1 が 10 GB 上限に近づく | 単一 DB が 6 GB 超 | 古い年度データを R2 へアーカイブ。それでも足りなければ Hyperdrive + 外部 PostgreSQL へ。8 GB を超えたら即着手 |
| R2 | メモリ 128 MB / CPU に当たる | 帳票生成でタイムアウト・OOM | ① ストリーミング化 ② Containers へ切り出し ③ クライアント生成。3回試して解決しなければ Containers に移す |
| R3 | Cloudflare の全面障害 | 2025-11-18 に約6時間の全面障害（Access 認証もダッシュボードも不通）の実績 | 業務停止許容度を業務ごとに事前に決める。「半日止まると業務が止まる」システム（給与・受発注・勤怠締め）は Workers 単独に載せない、または AWS 側にコールドスタンバイを残す |
| R4 | SLA もテクニカルサポートも無い | — | Workers Paid では有償サポートも別。基幹に載せる前にサポート契約の要否を経営判断として上げる |
| R5 | OpenNext 経由の Next.js が2027年に再移行を強いられる | Adapters API への移行が2026年末 | Phase 3 で C 分類にしたシステムは「2027年 再移行」を最初から計画に書く。書かずに済ませると技術的負債として不可視化する |
| R6 | TanStack Start を待ってしまう | 「もうすぐ stable が出るはず」で着手が遅れる | 2027年3月時点で stable でなければ、以後の再評価をやめる。判断日を先にカレンダーに入れる |
| R7 | Access の JWT 検証を各アプリが独自実装して劣化する | アプリごとに access.ts が微妙に違う | 検証ロジックは1本に固定し、テンプレート経由でしか配らない。既存スターターの CLAUDE.md の「ここは触らない」方針を全リポジトリで維持 |
| R8 | R2 のバージョニング非対応による添付ファイル事故 | 誤削除・誤上書きの報告 | 物理削除を実装しない（D1 で論理削除）、オブジェクトキーに UUID を含める。この2点をテンプレートに強制 |
| R9 | Workers Logs 7日で監査要件を満たせない | 監査・インシデント調査でログが無い | Phase 1 完了までに Logpush → R2 を必ず稼働させる。これを移行の完了条件に含める |
cf-internal-app-starter に Drizzle ORM を導入する（生成 drizzle-kit / 適用 wrangler d1 migrations、migrations_pattern の設定を含む）@sentry/cloudflare を導入し、instrumentD1WithSentry と withMonitor を組み込むcompatibility_date を 2026-08-04 以降に更新し、nodejs_compat の明示指定の要否を確認する@cloudflare/vitest-pool-workers のサンプルテストを充実させるCLAUDE.md に追記するその通りで、それが採用理由である。Hono はルーティング・データ取得・フォームといったフロント側の仕組みを持たない。社内システムでは、それらは React 側（React Router をライブラリとして + TanStack Query）で十分に賄える。フレームワークが持つ範囲が狭いほど、フレームワークの更新に振り回される面積が小さい。
一方で、Hono に DB プロビジョニング・分散トレーシング・バックグラウンドジョブといったインフラ機能を期待してはいけない。それらは Cloudflare のバインディング・Logpush・Cron / Queues が担う。
hc）で型を共有すれば最強では？」小〜中規模では強力だが、大規模化すると型推論が TypeScript のコンパイル時間を直撃する。
unknown に壊れる回帰が報告されている公式の文言は「feature-complete かつ API は stable とみなす。ただしバグが無い・問題が無いという意味ではない」であり、後半が重要。実際に RC 期間中に createStartHandler のシグネチャ変更で外部連携が壊れており、Cloudflare Vite plugin との併用不具合も未解決のまま残っている。
受託開発の武器として個人・実験プロジェクトで習熟しておくことは推奨する。社内基幹に先に入れる理由が無い、というだけ。
Next.js の知識は無駄にならない。SPA + Hono へ移す場合、Route Handlers（app/api/**/route.ts）はほぼそのまま Hono に移り、React コンポーネントもそのまま使える。捨てるのは Server Component / Server Actions / ISR という「Next.js 固有のサーバー機構」であり、そこはそもそも Workers 上で完全には再現できていない部分でもある。むしろ「Workers に載っている Next.js が今どこまで動くのか」を追い続けるコストの方が高い。
既存 DB が PostgreSQL / MySQL で大きい場合はその通りで、Hyperdrive は追加料金なしの正しい選択肢。ただし今回は既存が SQLite / 小規模 DBと確認しているため、D1 への移行が最もコスト・運用ともに軽い。RDS を維持すると、Workers 化しても AWS 側の固定費（RDS インスタンス + NAT Gateway）が残り、コスト削減という移行目的の大半が失われる。
判断に影響しうるが、一次情報で裏が取れなかった項目をあえて明記しておく。この一覧を残しておくことが、次回の再評価の起点になる。
| 項目 | 状況 |
|---|---|
| TanStack Start の stable 予定日 | 公式に一切の言及なし。Discussion #5999 は9か月間未回答 |
| Next.js on Workers のコールドスタート・CPU 時間の実測値 | 信頼できるベンチマークが見つからず。「サブミリ秒」等の主張はすべて第三者 SEO 記事の定性的表現で、数値の裏付けなし |
| Cloudflare がどのフレームワークを推奨しているか | 公式に推奨表示は存在しない（フレームワークガイド一覧はすべて対等） |
| D1 の TRIGGER 対応の可否 | 公式ドキュメントに明示的記述を発見できず。使う前に staging で実地確認すること |
| D1 の書き込みが単一リージョンに限定されるかの公式明言 | read replication の仕組み上そう読めるが、断定する一次記述は特定できず |
| Prisma の D1 driver adapter が Preview から GA になったかの明言 | 確認できず（Drizzle を採用するため実害なし） |
| Remix 3 の Cloudflare Workers 対応 | 公式ガイド類は未発見 |