next.js

開発モードでは、Next.js の Fast Refresh が保存のたびにモジュールを再評価するため、トップレベルの new DatabaseConnection(...)（または postgres()、PrismaClient など）は、PostgreSQL が remaining connection slots are reserved for non-replication superuser connections で失敗するまで、毎回新しい接続を作成してしまいます。これを修正するには、クライアントを globalThis にキャッシュし、リロード後も接続が維持されるようにします：

import postgres from 'postgres';

declare module globalThis {
  let postgresSqlClient: ReturnType<typeof postgres> | undefined;
}

function connectOnceToDatabase() {
  if (!globalThis.postgresSqlClient) globalThis.postgresSqlClient = postgres();
  return globalThis.postgresSqlClient;
}

export const sql = connectOnceToDatabase();

同じシングルトンパターンは、Prisma（globalThis.prisma ??= new PrismaClient()）やその他のドライバーにも適用できます。この問題が影響するのは開発環境のみです。本番ビルドではリクエストごとにモジュールが再評価されることはありません。

これは、Next.js 16.4.0 で #97664 によって導入された、既知の Turbopack 開発環境のリグレッションです。ページチャンクグループが _app の可用性データを再利用すると、ページモジュールがクライアントチャンクから除外される場合があり、その結果 SSR は成功するものの、ハイドレーションが module factory is not available というエラーで失敗します。

恒久的な修正：Pages Router の開発用クライアントモジュールグラフを連鎖させる PR #98823 を含む Next.js の canary/preview リリースにアップグレードしてください。この修正は next@16.5.0-preview-358550b2-20261009 で検証済みです。

npm install next@canary
rm -rf .next
npm run dev

アップグレードできない場合は、以下の回避策のいずれかを使用してください。

# 影響を受けない最後のリリースにダウングレード
npm install next@16.3.8
rm -rf .next
npm run dev

または、Turbopack の代わりに webpack を使用して開発サーバーを実行してください。

npx next dev --webpack -p 3456

プロダクションビルドは影響を受けないため、16.4.0 でも next build && next start は正常に動作します。

Next.js 16.4 では experimental.turbopackSharedRuntime がデフォルトで有効になります。cacheComponents: true の場合、Turbopack はチャンクグループのブートストラップを、リクエストノンスを追加せずにプリレンダリングされたシェルへインライン化します。script-src 'self' 'nonce-<random>' のような厳格な CSP はこのインラインの <script id="_R_"> をブロックするため、クライアントランタイムが起動せず、ハイドレーションが失敗します。

回避策: next.config.js で共有ランタイムを無効にします:

module.exports = {
  experimental: {
    turbopackSharedRuntime: false,
  },
};

その後、再ビルドして再起動します:

next build && next start

これにより、ブートストラップが 'self' で許可される外部スクリプトとして読み込まれる以前の動作に戻ります。この問題は、Turbopack、React 19.2、および cacheComponents: true を使用した Next.js 16.4.0 に影響します。ブートストラップはルートおよびビルドごとに変化するため、スクリプトハッシュを使用するのは現実的ではありません。

Next.js を **16.4.0 以降** にアップグレードしてください。この Windows のシンボリックリンクの問題は、このバージョンで修正されています:

pnpm add next@^16.4.0
# or
yarn add next@^16.4.0

次に、古いビルド出力を削除して再ビルドします:

rm -r .next
pnpm build

.next/standalone/node_modules 配下に生成されるシンボリックリンクは、ビルドマシンのルート node_modules や Windows の絶対パスではなく、.next/standalone/node_modules/.pnpm 内で解決されるようになります。このバグは、pnpm を使用した Windows 環境の Next.js 16.2.10 および 16.3.0 で再現され、yarn でも同様の絶対パスのシンボリックリンク動作が報告されています。すぐにアップグレードできない場合は、Linux で standalone 出力をビルドするか、ローカルの Windows コンテナビルドに webpack を使用するという回避策が報告されています。

Next.js はビルド前に distDir をクリアします。apps/web で distDir: "../../" と設定すると、解決されるパスはモノレポのルートになるため、Next.js はそのディレクトリを再帰的に削除します。distDir は Next.js プロジェクトのルート内に保持してください：

1. apps/web/next.config.ts を編集し、安全でない設定を削除するか、ローカルディレクトリを使用してください：

const nextConfig = {
  distDir: '.next',
}

2. distDir をリポジトリのルート、ホームディレクトリ、/、または他のプロジェクトに向けないでください。
3. Vercel のモノレポデプロイでは、.next をリポジトリのルートに移動する代わりに、**Project Settings → General → Root Directory** を開き、apps/web に設定してください。これにより、Vercel がビルド出力を自動的に検出します。
4. apps/web からビルドする前に、解決されるパスを確認してください：

node -e "console.log(require('path').resolve('../../'))"

モノレポのルートや、無関係なファイルを含む他のディレクトリが出力された場合、その設定は安全ではありません。
5. Next.js 16.3.5 から、カスタム distDir の安全性検証を含む新しいリリースにアップグレードしてください。

この削除は永続的であり、システムのゴミ箱は使用されません。影響を受けたファイルは Git または他のバックアップから復元してください。