Next.js 15 時代の、コーポレートサイト設計指針
async request APIs、Turbopack GA、キャッシュのデフォルト変更 ── Next.js 15 の変更点を踏まえ、Xiora が自社コーポレートサイトで採用している設計判断を実装目線で整理します。
Introduction — Next.js 15 で何が変わったか
Next.js 15 は 2024 年 10 月に GA された、フレームワーク側の内部モデルを大きく更新したリリースです。コーポレートサイトのようにアクセスの多くが静的な用途でも、影響が出る変更点がいくつかあります。
主な変更点は次の 3 つと考えられます。
- Request APIs が async 化:
cookies()/headers()/draftMode()/params/searchParamsが Promise を返すようになり、コード上はawaitが必要になりました。従来の同期アクセスは非推奨扱いです。 - Turbopack for dev が Stable:
next dev --turboが本番安定版として利用可能になり、開発時の HMR が高速化する構成が公式サポートに入りました。 fetch/ Route Handler のデフォルトキャッシュ挙動が変更: これまで暗黙にキャッシュされていたリクエストが、既定では都度実行 (non-cached) になりました。キャッシュしたい場合は明示的に指定します。
いずれも「知らずに 14 → 15 に上げると挙動が変わる」ものです。特に 3 つ目は、コーポレートサイトの CDN 費用や API コール数に直結し得る変更です。
コーポレートサイトの要件を先に決める
Next.js のどの機能を使うかを決める前に、コーポレートサイトの要件を分けて整理するのが実務的です。私たちは通常、次の 3 つで判断しています。
- 更新頻度: トップページやサービス紹介は月に数回、ニュースやインサイトは週次、というのが典型です。
- SEO の重み: 検索流入を狙うページは、Server Component + 静的生成 (SSG) が原則です。
- 動的要素の有無: フォーム、Live 情報、認証を持つ管理画面などが混ざるかどうか。
これらを混ぜて設計すると、「静的でよいはずのページに毎回サーバー処理が走る」「動的にすべきページが古いままキャッシュされる」という状況が起きます。ページごとに最適なレンダリング戦略を選ぶことが、Next.js 15 でも変わらない原則です。
私たちの設計判断 6 つ
Xiora のコーポレートサイトで採用している設計判断を、Next.js 15 に置き換えた場合の指針として 6 つに整理します。
- 1. デフォルトは Server Component + SSG:
app/配下のページは、明示的に必要がなければ Server Component のままにします。JS バンドルが増えないため、初回描画とコアウェブバイタルに素直に効きます。 - 2. ニュース / インサイトは ISR (revalidate):
revalidateを秒単位で指定し、更新のたびにビルドし直さなくても新しい記事が配信される構成にします。 - 3.
generateMetadataで OGP を集中管理: タイトル、description、OGP 画像、canonical、JSON-LD をページごとにgenerateMetadataに集約します。手書き HTML の重複を避けられます。 - 4. 動的要素は Streaming + Suspense: 問い合わせフォームの初期化や、外部 API を叩く部分は
<Suspense>で囲み、静的部分を先に返してから動的部分を追いつかせます。 - 5.
fetchのキャッシュは明示指定: Next.js 15 ではfetchのデフォルトが no-store 相当になったため、キャッシュしたい呼び出しでは{ next: { revalidate: N } }などを明示します。「なんとなく速い」に依存しない構成にします。 - 6. Server Actions は限定的に: フォーム送信など「ユーザー操作を伴い、副作用が伴う」箇所に限って使用します。表示専用ページで安易に使うと、キャッシュ戦略が複雑になります。
Xiora HP の現状 ── build.py + hand-crafted HTML
正直に書くと、この Xiora コーポレートサイトはまだ Next.js 15 には移行していません。現状は次の構成です。
- 静的 HTML を手で書き、
content/updates.jsonを Single Source of Truth として扱う scripts/build.pyが JSON からニュース、インサイト、サイトマップの領域を自動生成 (マーカー<!-- BUILD:start ... -->で差し替え)- ホスティングは VPS 上の静的配信
依存を最小化して、ビルドが素直に通る状態を優先した構成です。長期的には Next.js 15 移行を検討しており、その場合の想定 spec は次の通りです。
- App Router + Server Component ベースに移行
content/*.jsonをgenerateStaticParamsに渡し、記事ページを SSG- ニュースやインサイトは ISR、動的な問い合わせフォームは Server Actions
- 画像は
next/image、フォントはnext/font
「フレームワーク移行そのものを目的にしない」を運用ルールにしており、移行のコストと得られる価値を都度秤にかけて判断しています。
導入時に気をつけている落とし穴
Next.js 15 を採用するとき、私たちが実装レビューで見ている観点は次のあたりです。
- async request APIs の未対応: 14 系向けのライブラリを持ち込むと、
cookies()を同期で呼んで警告や実行時エラーになることがあります。upgrade codemod で拾える箇所と、拾えない箇所があります。 - キャッシュ挙動の変化: 14 では暗黙にキャッシュされていた API 呼び出しが、15 では毎回走る想定に変わります。呼び出し回数と外部 API の rate limit を見直しておく必要があります。
- Turbopack と一部プラグイン: dev で Turbopack を使う場合、Webpack 前提のプラグインが動かないケースがあります。プロダクションビルドは今も Webpack が既定です。
- React 19 との組み合わせ: Next.js 15 は React 19 サポートを含みます。UI ライブラリ側の対応状況を事前確認しておくと安全です。
免責
本記事は Next.js 15 の公式ドキュメントおよび Vercel の一次情報を参照して執筆していますが、フレームワークの仕様は継続的に更新されます。実装時は最新の公式ドキュメントを確認したうえで判断してください。また、コーポレートサイトの設計は業種、更新頻度、運用体制によって最適解が異なるため、本記事は判断材料の一例としてご活用ください。
参考リンク
- Next.js 15 リリースブログ (Vercel): https://nextjs.org/blog/next-15
- Next.js Docs — Upgrading to Version 15: https://nextjs.org/docs/app/guides/upgrading/version-15
- Next.js Docs — Caching: https://nextjs.org/docs/app/deep-dive/caching
- Next.js Docs — Turbopack: https://nextjs.org/docs/app/api-reference/turbopack
- MDN — HTTP caching: https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching
筆者: Xiora Engineering
連絡: info@xiora-official.com
関連 Xiora プロダクト
本記事のトピックに直接関わる Xiora 自社プロダクトです。 いずれも公開情報、¥0 で概要確認できます。
- Content Engine — AI コンテンツ生成 — 本 HP 自体が Content Engine 出力
関連ツール (提携リンク)
本記事の内容を実装するにあたり、Xiora が業務で採用しているツール群です。 リンクは提携リンク (advertisement) を含み、経由でお申込みの場合は Xiora に紹介料が入る場合があります。 記事内容の中立性は維持しています。
- Notion — SMB のドキュメント / ナレッジ管理 SaaS
- Vercel — Next.js を最速で公開する PaaS
- Railway — コンテナ / DB を 1 分で立てる PaaS
- Cloudflare — エッジ CDN + Zero Trust
※ Reo Absolute Gate (KYC) 承認待ちの placeholder URL。 承認後、代理人が sed で real referral ID に一括置換します。
← Insights 一覧へ