Next.js

Reactベースのフルスタックフレームワーク。BenriWorksの各アプリと本サイトの基盤に使っています。静的生成中心の構成、Metadata APIによるSEO設定の一元管理、basePathでのパス配信への追従が選定理由です。

Next.jsは、Reactをベースとしたフルスタックフレームワークです。BenriWorksでは、「移動式クレーン安全シミュレーター」「地球地下シミュレータ」「wavelane」をはじめとする各アプリの基盤として使用しているほか、本サイトBenriWorks Lab自体もNext.jsのApp RouterとMDXで構築しています。

なぜほぼ全アプリでNext.jsなのか

個人規模で10を超えるアプリを並行運用するうえで、技術スタックを揃えることは省力化の柱です。フレームワークを1つに絞ると、あるアプリで解決した問題（メタデータの組み立て方、サイトマップの生成、画像の最適化）が、そのまま他のアプリへ持ち越せます。

そのうえでNext.jsを選んでいる実質的な理由は3つあります。ひとつは静的生成（SSG）を中心に据えられること。BenriWorksのアプリの多くは計算やシミュレーションがブラウザ内で完結するため、サーバーを常時動かす必要がなく、静的生成とCDN配信だけで成立します。CMSもデータベースも持たない構成は、個人運用での保守コストを大きく下げます。

ふたつめはApp RouterのMetadata APIです。canonical・OGP・Twitterカード・サイトマップ・robotsをコードで一元管理でき、sitemap.ts や robots.ts をファイルとして置くだけで配信されます。SEO設定の抜け漏れをレビューで発見しやすいのは、設定がコードとして差分に現れるからです。

みっつめは配信構成の変更に強いことです。本サイトはサブドメイン運用からbenriwork.jp/blog配下のパス配信へ移行しましたが、basePath の設定とURL生成ヘルパーの変更だけで、リンク・画像・サイトマップまで一括で追従できました。

実際に踏んだ注意点

運用のなかで得た教訓も記録しています。たとえばtrailingSlash の設定は配信層（Vercel側の設定）とアプリ側で必ず揃える必要があります。片方だけが末尾スラッシュを強制すると、互いに308リダイレクトし合うループが起きます。また、next/link や next/image は basePath を自動で付けますが、MDX内の素の <img> には付かないため、パス配信への移行時には自前で接頭辞を補う必要がありました。

こうしたApp Routerでの設計判断と検証の記録は、開発記事として発信していきます。