モダンWeb開発の構成判断：Next.jsとヘッドレスCMSをどう組み合わせるか

Next.jsとヘッドレスCMSを使うかどうかは、技術の新しさではなく、誰がどのように更新するか、どんな機能が必要か、公開後に誰が保守するかで決めます。会社案内のように更新が少ないサイトなら、CMSを使わずに静的なファイルを配信する構成や、今使っているWordPressなどのCMSを続ける構成も候補です。社内の担当者が記事を頻繁に更新する、会員向けの機能がある、といった条件が加わると、CMSや動的な処理を組み合わせる理由が生まれます。

この記事でいう「モダンWeb開発」は、表示、コンテンツの管理、配信、動的な処理の役割を分けて考える設計の考え方です。分けるほど良いわけではなく、分けた部分ごとに保守の担当と費用が増えます。DXの進め方と同じく、まず要件と体制を確かめます。

次の確認票で、自社の条件を整理します。分からない項目は「未確認」として、次に調べることを決めます。

フレームワークの総合的な順位を比べる必要はありません。Next.jsもAstroも、ビルド時に静的なページを作る使い方と、実行環境に合わせた要求時の処理の両方に対応しています（Astro：On-demand rendering）。確認票の条件に合い、社内や委託先が保守を続けられるかで選びます。

Next.jsでは、ページごとにHTMLを作るタイミングを選べます。違いは、CMSなどで内容を変えたときに、いつ公開ページへ反映されるかと、どんな実行環境が必要かに表れます。

ISRは、時計で一定の間隔ごとに作り直す仕組みではありません。Next.jsの公式ドキュメントでは、期間を過ぎた後のアクセスにはいったん古いページを返し、裏で新しいページを作り、成功したら次のアクセスから新しいページを返す動きが説明されています。作り直しに失敗したときは、最後に成功したページが返り続けます（Next.js：ISR）。「CMSで公開してから何分以内に反映する」と約束するなら、この条件を前提に確かめます。

Next.jsを静的に書き出す構成（静的export）では、ISR、下書きを確認するDraft Mode、Server Actionsなど、サーバーが必要な機能はそのままでは動きません（Next.js：Static Exports）。フォームの送信や会員向けの機能が必要なら、静的なページとは別に、APIやサーバーレスの関数などの処理を置きます。静的なページに認証付きのAPIを組み合わせることはできますが、権限の確認はAPI側で行います。ブラウザで表示を隠すだけでは、データを守れません（Next.js：Data Security）。

SSRやISRを使う場合は、使いたい機能が、配信先の実行環境やアダプター、Next.jsの版で動くかを、採用する前に確認します。

ヘッドレスCMSにも、記事を書いて公開する編集画面があります。違いは、公開サイトの見た目を作る部分を持たず、APIなどで内容を渡して、別に作った表示部分（Next.jsなど）が画面を作る点です。WordPressのような一体型のCMSも、APIで内容を渡す使い方ができるため、製品名だけで構成は決まりません。

WordPressには、管理者・編集者・投稿者・寄稿者などの標準の権限があり、寄稿者は記事を書けても公開はできません（WordPress：Roles and Capabilities）。ヘッドレスCMSの権限は製品やプランで異なり、例えばmicroCMSのロール機能は特定のプランで提供されています（microCMS：ロール）。必要な承認の段階を、製品の機能と照らし合わせて確認します。

ヘッドレスの構成では、公開サイトから管理画面やデータベースを切り離せるため、攻撃を受ける入口を減らせる場合があります。一方で、APIキー、編集の権限、表示側のアプリ、連携の保守は残ります。下書きの取得や書き込みの権限を持つAPIキーをブラウザに渡すと、下書きの公開や外部からの書き込みにつながります（microCMS：APIキー）。デザインを刷新するときも、項目の定義やURLの変更が伴えば、表示側の改修だけでは終わりません。

CMSの製品ごとの編集・承認・多言語などの比べ方は、ヘッドレスCMSの選び方で扱っています。今のWordPressを続けるか移行するかは、WordPressからの移行手順を参照してください。

会社の規模や無料プランから構成を決めるのではなく、更新の方法と必要な機能から考えます。次の3つは、要件ごとの構成例です。

• 例A：更新が少ない会社案内
  CMSを使わない構成や、今のCMSを続ける構成も候補です。静的に生成したHTMLなどをCDNから配信し、問い合わせフォームは別の受付先やAPIで処理します。フォームの実装は問い合わせフォームをWorkersで実装する方法で扱っています。
• 例B：社内の担当者が記事を更新するサイト
  CMSで記事を書き、公開をきっかけにビルドして配信するか、対応する実行環境で再検証します。下書きのプレビュー、反映に失敗したときの通知と担当まで決めます。
• 例C：会員向けの機能や業務アプリ
  利用者ごとのデータを扱うため、要求時の処理に対応した実行環境、認証と認可、データベース、キャッシュ、監視を設計します。すべてのページを動的にする必要はなく、会社案内や記事は静的に配信し、会員向けの画面だけを動的にする組み合わせもあります。

ECや予約は、専用のSaaSの標準機能や、別のサイトとして連携する方法も候補です。ヘッドレスの構成で作り込むかは、必要な画面と運用の担当から判断します。

Cloudflareを使う場合、静的exportしたNext.jsはCloudflare Pagesで配信でき、サーバーの機能を使うNext.jsはCloudflare Workersで動かす構成が案内されています（Cloudflare：Next.js on Pages）。2026年10月時点の公式ドキュメントでは、Workersでの実行にvinextを推奨しつつ、ベータ版のため互換性の確認を求めており、既存のOpenNextの構成向けの案内もあります（Cloudflare：Next.js on Workers）。新しく静的なサイトを作る場合は、WorkersのStatic Assetsも候補です（Cloudflare：Workers Static Assets）。使う機能が実行環境で動くかを公式ドキュメントで確かめてから選びます。PagesとWorkersの選び方はCloudflare PagesとWorkersの違い、維持費の考え方はホームページ維持費の記事で扱っています。

Core Web Vitalsは、読み込み（LCP）、応答性（INP）、表示の安定性（CLS）を測る指標で、Googleの検索順位の仕組みでも使われています。ただし、指標が良いだけで上位に表示されるとは限らず、内容の関連性がより重視されます（Google：ページエクスペリエンス）。

評価は、実際の利用者のデータの75パーセンタイルで、モバイルとデスクトップを分けて確認します（web.dev：Web Vitals）。開発中のPCでの測定やLighthouseの点数は改善の手がかりになりますが、それだけでは、実際の利用者のデータで目標を満たしているかや、順位が上がるかを判断できません。

画像は、画面の外にある画像だけを遅延読み込みにします。LCPになる画像を遅延読み込みにすると、表示が遅れます。優先して読み込む指定も、多くの画像に付けると効果がなくなるため、LCPの画像などに絞ります（web.dev：Optimize LCP）。

Webサイトは公開した後も、更新の反映、フォーム、権限、依存するライブラリの更新が続きます。次の確認票で、決めることと担当、失敗したときの対応を整理します。担当の欄は役割の例で、自社の体制に合わせて決めます。

下書きを実際の見た目で確認するプレビューは、構成によって必要な仕組みが変わります。静的exportではNext.jsのDraft Modeは使えないため、別のプレビュー環境などを用意します。プレビュー環境にnoindexを付けても、URLを知っている人は閲覧できるため、非公開の情報は認証などで守ります。

Webhookでビルドを自動化しても、反映までの時間は保証されません。依存ライブラリの更新を知らせるツールは、更新の通知や提案を助けるものです。テスト、公開の判断、不具合のときの戻し方は、別に決めておきます。

APIキーなどの秘密情報や、下書き・書き込みの権限は、ブラウザに渡しません。Next.jsでは、NEXT_PUBLIC_で始まる環境変数はブラウザ向けのコードに含まれます（Next.js：Data Security）。ビルドで使った秘密情報や非公開のデータが、生成したHTMLやJavaScriptに残っていないかも確認します。環境変数に置けば常に安全、というわけではありません。

監視の通知や迷惑送信の対策を入れても、誰が確認して対応するかを決めなければ運用は続きません。データの保全では、ソースコード、CMSのデータ、公開した版の戻し方を分けて確認します。

検索やAIの回答で内容を伝えるために大切なのは、構成の名前ではなく、読者の疑問に答える本文が検索エンジンに届くことです。Next.jsやSSGを使うだけで検索に有利になるわけではありません。次の点を確認します。

• 本文がHTMLで読めること：重要な本文を、ブラウザでの処理だけに頼らずHTMLとして返す。静的な生成やSSRは、これを満たしやすい方法の一つ
• 役に立つ回答と条件：結論だけでなく、どんな条件でその判断になるかを書く
• ページ固有の情報：ページごとに固有のタイトル、説明、canonicalを設定する
• 内部リンク：関連する記事を、疑問が生まれる箇所から案内する
• 公開と下書きの扱い：公開ページはリンクとサイトマップからたどれるようにし、下書きや検証環境は公開しない。同じ内容のページが重複していないかも確かめる

GoogleのAI Overviewsなどの機能にも通常のSEOの基本が当てはまり、表示されるための特別な対応や、専用の構造化データ、AI向けのファイルは不要だと案内されています（Google：AI features and your website）。これはGoogleの案内で、他のAI検索サービスの仕組みまで示すものではありません。ArticleやFAQの構造化データを使う場合は、画面に表示している内容と一致させます。構造化データを入れても、リッチリザルトやAIの回答への採用は保証されません。

確認票で未確認のまま残った項目や、今の構成の更新・保守で困っている点は、要件の整理、試作、実装、運用の相談の材料になります。