2026年最高のNext.js App Router向けCMS: 本番環境で6つをテスト
Next.js App Router向けの最高のCMS 2026年版：本番環境で6つをテスト
Pages Router時代からNext.jsサイトをリリースしてきた私は、「最高のCMS」という記事が、明らかに一度インストールして、クイックスタートチュートリアルに従って、レビューだと言い張っている人によって書かれているのを何度見かけたか数えられません。これはそういう記事ではありません。
Social Animalでは、複数のCMSアーキテクチャ全体で本番サイトを運用しています。ヘルスケアアプリを動かすPayload CMSから、3つの異なるプラットフォーム全体で253,000ページ以上を提供するSupabaseまで。実際のクライアントプロジェクトのためにStrapi 5、Sanity、Contentfulを評価しました。そしてあなたが今読んでいるこのサイト？これはGitリポジトリにコミットされたMDXファイルで構築されています。
つまり「本番環境で6つをテストした」と言う時、それはマイグレーションの頭痛、ビルド時間の驚き、コンテンツが公開されないことについての午前3時のSlackメッセージに対処してきたということです。2026年にNext.js App Routerに適した正しいCMSを選択することについて、私たちが学んだすべてをここに紹介します。
目次
- App Routerが式を変える理由
- テストした6つのCMS（そしてどのようにテストしたか）
- 1. Payload CMS 3 -- Next.js向けベストオーバーオール
- 2. Supabase-as-CMS -- スケール向けベスト（10K+ページ）
- 3. Strapi 5 -- 非技術的なチーム向けベスト
- 4. Sanity -- リアルタイムコラボレーション向けベスト
- 5. Contentful -- エンタープライズ向けベスト（予算がある場合）
- 6. Markdown/MDX -- 開発者ブログ向けベスト
- 本番環境メトリクス比較
- 決定フレームワーク：CMSを選択する方法
- 違う方法で対応する方法
- FAQ
App Routerが式を変える理由
Pages Routerで行っていたのと同じ方法でCMS選択について考えている場合、パフォーマンスを残しています。App Routerは、Next.jsアプリケーションを通じたデータフローの方法を根本的に変え、それはどのCMSが最適に適合するかに直接的な影響があります。
今、重要なのはここです：
サーバーコンポーネントがデフォルトです。 CMSデータフェッチングはサーバー上で発生し、クライアントにJavaScriptを何も送信しません。これは、ネイティブNode.js SDKを持つCMS、またはさらに良い場合はネットワーク全体をスキップするローカルAPIを持つCMSが大きな利点を持つということを意味します。
React Server Components + fetchキャッシング。 App Routerの組み込みフェッチ重複排除とキャッシングは、CMSの統合パターンが完全に異なることを意味します。getStaticPropsやgetServerSidePropsに到達していません。CMSを直接呼び出す非同期コンポーネントを書いています。
並列ルートと傍受ルート。 これらのパターンは、以前は構築するのが苦痛だったCMS駆動レイアウトをアンロックします。柔軟なコンテンツモデリング（ブログ投稿とページだけではなく）をサポートするCMSはここで輝きます。
部分的な事前レンダリング（PPR）。 Next.js 15の時点で、PPRは動的穴を持つ静的シェルを提供させます。これはISR対SSR論全体を変え、CMSの再検証戦略がこれまで以上に重要であることを意味します。
そのすべてのコンテキストで、実際のテストに進みましょう。
テストした6つのCMS（そしてどのようにテストしたか）
私たちの評価は理論的ではありませんでした。各CMSについて、本番ページをシップするか、実際のクライアントプロジェクトのための深い技術評価を行いました。私たちは以下を測定しました：
- App Router固有の開発者体験
- さまざまなページ数でのビルド時間
- 非開発者チームメンバーのためのコンテンツエディタUX
- スケール時の価格（無料層だけではなく）
- TypeScript統合品質
- 再検証パターン（ISR、オンデマンド、ウェブフック）
それぞれを見てみましょう。
1. Payload CMS 3 -- Next.js向けベストオーバーオール
私たちの判決：Next.js App Router向けの最高の開発者体験、句読点。
Payload CMS 3は、CMSが何であるかについて私に再考させたものです。これは呼び出すHTTP上の別のサービスではありません。これはあなたのNext.jsアプリケーションの内部に存在します。同じリポジトリ、同じデプロイメント、同じTypeScriptタイプ。
SleepDrはヘルスケアプラットフォームで、228ページ、複数レベルのアクセス制御、正確である必要があるコンテンツ（これはヘルス関連であるため、間違ったコンテンツは単なる悪い見た目ではなく、責任問題です）で本番環境でPayload 3を実行しています。
App Routerに特別なPayloadの内容
ローカルAPIはキラー機能です。CMSにHTTPリクエストを作成する代わりに、関数をインポートして直接呼び出します：
// app/blog/[slug]/page.tsx
import { getPayload } from 'payload'
import config from '@payload-config'
export default async function BlogPost({ params }: { params: { slug: string } }) {
const payload = await getPayload({ config })
const posts = await payload.find({
collection: 'posts',
where: {
slug: { equals: params.slug },
status: { equals: 'published' },
},
})
const post = posts.docs[0]
if (!post) notFound()
return <Article post={post} />
}
ネットワークホップはありません。REST またはGraphQL のオーバーヘッドはありません。インストールするSDKはありません。関数呼び出しは完全に型付けされます。Payloadはコレクション構成からTypeScriptインターフェースを生成するためです。フィールド名をリファクタリングすると、IDEは即座にすべての破損した参照をキャッチします。
App Routerでのライブプレビュー
Payload 3のライブプレビューはサーバーコンポーネントで機能します。コンテンツエディタは、実際のサイトレイアウト上で変更をリアルタイムで確認します。管理パネルでの近似ではなく。SleepDrの場合、これを設定したところ、編集チームは「これをチェックしてもらう開発者が必要です」から1週間以内に自給自足の公開に進みました。
実際に機能するアクセス制御
Payloadのフィールドレベルとコレクションレベルのアクセス制御はコードで定義されます：
const Posts: CollectionConfig = {
slug: 'posts',
access: {
read: () => true,
create: ({ req: { user } }) => user?.role === 'editor' || user?.role === 'admin',
update: ({ req: { user } }) => user?.role === 'admin',
delete: ({ req: { user } }) => user?.role === 'admin',
},
fields: [
// ...
],
}
ヘルスケアアプリの場合、この細かさはオプションではありません。それは要件です。
トレードオフ
Payloadはあなたのインフラストラクチャ上で実行されます。完全にマネージドSaaS体験を望む場合、Payload Cloud が存在します（本番環境で月額約$35から始まります）。しかし、それでもデプロイメントを理解する責任があります。また、Node.js実行時の依存関係でもあります。つまり、ホスティングはそれをサポートする必要があります（Vercelは機能しますが、コストは永続的なデータベース接続に伴って増加します）。
私たちのNext.js開発作業では、Payload 3は5,000ページ未満のコンテンツが豊富なサイトのデフォルトの推奨事項です。
2. Supabase-as-CMS -- スケール向けベスト（10K+ページ）
私たちの判決：技術的にはCMSではありませんが、大規模な構造化されたデータセットには何も近づきません。
これは慣例的ではない選択であり、私が最も興奮しているものです。Supabaseはヘッドレスcmsとしてマーケティングされていません。これはauth、storage、Edge Functionsを備えたPostgreSQLプラットフォームです。ただし、あなたの「コンテンツ」が本当に構造化されたデータの場合—セレブリティプロファイル、ビジネスリスティング、製品データベース—従来のCMSはスケールで崩れ落ちます。Supabaseは汗をかきません。
我々は本番環境でSupabase-as-CMSを実行している3つのサイトを実行しています：
- DA -- 30言語にわたる91,000ページ以上のセレブリティデータ
- NAS -- 137,000以上のビジネスリスティング
- HostList -- 25,000以上のホスティングプロバイダリスティング
それは253,000ページ以上です。従来のヘッドレスCMSに91,000エントリを入れようとするときに何が起こるか教えてください：管理パネルは使用できなくなり、ビルド時間は無限に進みます。あなたの請求額は天文学的に上昇します。
アーキテクチャ
253Kページに対してgenerateStaticParamsを使用しません。積極的なキャッシング付きの完全に動的なレンダリングを使用します：
// app/[locale]/celebrity/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server'
export default async function CelebrityPage({ params }: Props) {
const supabase = await createClient()
const { data: celebrity } = await supabase
.from('celebrities')
.select('*, social_profiles(*), net_worth_history(*)')
.eq('slug', params.slug)
.eq('locale', params.locale)
.single()
if (!celebrity) notFound()
return <CelebrityProfile data={celebrity} />
}
export const revalidate = 86400 // Revalidate daily
ビルド時間？約10秒。ページはオンデマンドでレンダリングされ、エッジでキャッシュされます。誰かが最近提供していないセレブリティを検索すると、最初のリクエストがSupabaseにヒット（エッジから通常20-50ms）し、ページをレンダリングし、キャッシュします。その後のすべての訪問者がキャッシュされたバージョンを取得します。
アクセス制御としての行レベルセキュリティ
SupabaseのRLSポリシーは、CMSの管理に通常構築するものを置き換えます：
CREATE POLICY "Public read access" ON celebrities
FOR SELECT USING (status = 'published' AND locale = current_setting('app.locale'));
CREATE POLICY "Editor update access" ON celebrities
FOR UPDATE USING (auth.role() = 'editor');
コンテンツ編集の問題
ここが正直な欠点です：Supabaseのテーブルエディタは開発者にとって問題ありませんが、コンテンツ編集体験ではありません。Supabaseのクライアントライブラリを使用して、編集チーム向けのカスタム管理インターフェースを構築しました。独自の管理UIを構築したくない場合、このアプローチはあなたのために機能しません。
Supabase Proは月額$25で実行されます。253Kページでも、計算またはストレージの制限からは程遠いです。これを同様のスケールでContentfulまたはSanityの価格と比較してください。
私たちのヘッドレスCMS開発ソリューションでは、10,000を超える構造化されたコンテンツページがあるプロジェクトにこのアプローチを推奨しています。
3. Strapi 5 -- 非技術的なチーム向けベスト
私たちの判決：最高の視覚的コンテンツモデリング体験。エディタが開発者でない場合に理想的です。
私たちはクライアントプロジェクトのためにStrapi 5を深く評価し、広範なPayload vs Strapi比較を書きました（これは1ページにランク付けされるため、明らかに他の人は同じ質問をしています）。私たちは最終的にそのプロジェクトのためにPayloadを選択しましたが、Strapiは明確なユースケースを持っています。
Strapi 5のContent-Type Builderにより、非技術的なチームメンバーがドラッグアンドドロップGUIを通じてコンテンツ構造を作成および変更できます。コードなし。設定ファイルなし。デプロイメントなし。あなたのマーケティングマネージャーは、Jiraチケットを提出することなく、引用、著者、会社、および評価のフィールドを使用して「推奨事項」コンテンツタイプを追加できます。
App Routerの統合
Strapi 5はRESTとGraphQL APIの両方を公開しています。App Routerとの統合は単純ですが、ネットワークリクエストが必要です：
// lib/strapi.ts
export async function getArticles() {
const res = await fetch(
`${process.env.STRAPI_URL}/api/articles?populate=*`,
{
headers: { Authorization: `Bearer ${process.env.STRAPI_TOKEN}` },
next: { revalidate: 60 },
}
)
return res.json()
}
それは機能します。しかし、PayloadのローカルAPIと比較すると、インピーダンスミスマッチを感じます。プロセス内にとどまる可能性があるデータをシリアル化および逆シリアル化しています。TypeScriptタイプは別々に生成する必要があります（Strapiにはこのためのcliがあります。v5で改善されています）。
Strapi 5価格（2026）
| プラン | 価格 | シート | アセット |
|---|---|---|---|
| コミュニティ | 無料（自己ホスト） | 無制限 | 無制限 |
| チーム | $29/月/シート | 5-20 | 100GB |
| ビジネス | $99/月/シート | カスタム | 500GB |
| エンタープライズ | カスタム | カスタム | カスタム |
Strapiのセルフホストは本当に無料で、よく機能しています。クラウドプランはマネージドホストとプレミアムサポートを追加します。
4. Sanity -- リアルタイムコラボレーション向けベスト
私たちの判決：最高のリアルタイム編集体験ですが、GROQは好きか嫌いかのコミットメントです。
DAプロジェクト（91Kセレブリティページ）のためにSanityを真剣に評価しました。その後、Supabaseに向かいました。Sanity Studioは本当に印象的です。これはフィールドレベルまで下にカスタマイズできるReactアプリケーションです。リアルタイムコラボレーションは完全に機能します。2人のエディタが同じドキュメント上で同時に作業できます。Google Docsスタイル。
GROQ：強力ですが二極化
Sanityは独自のクエリ言語であるGROQを使用します：
*[_type == "article" && slug.current == $slug][0] {
title,
body,
"author": author->{ name, image },
"categories": categories[]->{ title, slug },
publishedAt
}
GROQは、一度学習すると実際にエレガントです。参照を解決するための投影構文（->）はGraphQLの多くのユースケースよりも優れています。しかし、それはあなたのチームが学習および保守する必要があるもう1つのクエリ言語です。そして、エッジケースにヒットするとき、ドキュメントは薄く感じることができます。
Sanityがダを選択しなかった理由
91,000ドキュメントで、Sanityの価格が重要になります。成長プラン（月額ユーザーあたり$15）には1M APIのCDNリクエストが含まれます。たくさんのように聞こえるまで、まともなトラフィックを生成するサイトが91Kページで速く進むことに気づきます。DAだけのための月額Sanity請求は月額$300-500と推定しました。Supabase Proは月額$25でした。
Sanityは、複数のエディタが協力する必要がある50-5,000のコンテンツアイテムを持つサイトに優れています。メディア企業の編集チームはそれを愛しています。
5. Contentful -- エンタープライズ向けベスト（予算がある場合）
私たちの判決：最も成熟したヘッドレスCMSですが、その成熟度に対して支払うことになります。
Contentfulは2013年以来存在しています。エンタープライズチームが既定値を示すヘッドレスCMSであり、理由があります：コンテンツモデリングは優れています。API は堅牢です（プレミアムで99.99% SLA）。統合のエコシステムは比類のないものです。
複数のエンタープライズクライアントプロジェクトのためにContentfulを評価してきました。コンテンツモデルビルダーは磨かれています。webアプリ内のAPIエクスプローラーはデバッグに本当に役立ちます。ウェブフックシステムはNext.jsのオンデマンド再検証とクリーンに統合します。
価格タグ
| プラン | 価格（2026） | コンテンツタイプ | ロケール | APIコール |
|---|---|---|---|---|
| 無料 | $0 | 48 | 2 | 1M/月 |
| 基本 | $300/月 | 48 | 6 | 2M/月 |
| プレミアム | カスタム（通常$3,000+/月） | 無制限 | 無制限 | カスタム |
無料から基本への跳躍は急です。基本からプレミアムへの跳躍は崖です。$50K+/年のSaaS予算を持つエンタープライズの場合、Contentfulは安全な賭けです。燃焼率を低く保とうとしているスタートアップの場合は、別の場所を見てください。
App Routerの統合
ContentfulのJavaScript SDKはサーバーコンポーネントでよく機能します：
import { createClient } from 'contentful'
const client = createClient({
space: process.env.CONTENTFUL_SPACE_ID!,
accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!,
})
export async function getPage(slug: string) {
const entries = await client.getEntries({
content_type: 'page',
'fields.slug': slug,
include: 3,
})
return entries.items[0]
}
SDKは適切に保守されており、contentful-typescript-codegenで完全に型付けされています。DXの前に苦情はありません。
6. Markdown/MDX -- 開発者ブログ向けベスト
私たちの判決：ゼロオーバーヘッド、最大制御、Gitネイティブワークフロー。
このサイト— socialanimal.dev —はMDXで実行されます。すべての記事は、フロントマターメタデータを含むリポジトリ内のファイルです：
---
title: "Best CMS for Next.js App Router 2026"
slug: "best-cms-nextjs-app-router-2026"
category: "Resources"
tags: ["nextjs", "cms", "payload", "supabase"]
publishedAt: "2026-01-15"
---
Pages Router時代からNext.jsサイトをリリースしてきた私は...
@next/mdxまたはcontentlayer2（コミュニティフォーク）を使用して、MDXはApp Routerとネイティブに統合されます。あなたのコンテンツはあなたのコードベースです。バージョン管理、ブランチング、プルリクエストレビュー—すべてのワークフロー、あなたはすでに知っています。
MDXが崩れるとき
非開発者はそれを使用できません。期間。あなたのマーケティングチームがブログ投稿を公開する必要がある場合、MDXは彼らがGitを学んでいるか、あなたが彼らに編集インターフェースを構築していることを意味します（その時点で、単にPayloadを使用してください）。
MDXも数千ページまでスケーラブルではありません。500以上のMDXファイルの周りで、ビルド時間はドラッグし始め、IDEが遅くなります。会社のブログまたはドキュメンテーションサイトの場合、それは完璧です。コンテンツプラットフォームの場合、それはそうではありません。
私たちのAstro開発作業では、Astroのコンテンツコレクションがマークダウン/MDXコンテンツに優れたタイプセーフティを提供するため、MDXをさらに広く使用しています。
本番環境メトリクス比較
ここは実際の本番環境のデプロイメントと評価からのデータです：
| CMS | 本番環境のページ | 言語 | ビルド時間 | 月額費用 | 私たちの判決 |
|---|---|---|---|---|---|
| Payload 3 | 228（SleepDr） | 1 | ~45秒 | $35（Payload Cloud） | Next.js向けベストDX |
| Supabase | 253K（DA+NAS+HostList） | 30 | ~10秒 | $25（Proプラン） | スケール向けベスト |
| Strapi 5 | 0（評価） | N/A | N/A | 無料（自己ホスト） | GUIエディタ向けベスト |
| Sanity | 0（評価） | N/A | N/A | ~$300-500 est. | コラボレーション向けベスト |
| Contentful | 0（評価） | N/A | N/A | $300+（基本） | エンタープライズ向けベスト |
| MDX | ~60（このサイト） | 1 | ~30秒 | $0 | 開発者ブログ向けベスト |
ビルド時間の列は説明が必要です。228個の静定的なページを生成するPayloadで45秒。Supabaseで10秒は、253Kページを静的に生成しないため、動的レンダリングとISRを使用しています。構文強調表示と画像最適化を使用した〜60記事のMDXで約30秒。
決定フレームワーク：CMSを選択する方法
機能チェックリストを忘れてください。これら4つの質問に答えてください：
1. 誰がコンテンツを編集していますか？
- 開発者のみ→MDXまたはPayload
- 開発者+技術的なエディタ→PayloadまたはSanity
- 非技術的なマーケティングチーム→StrapiまたはContentful
2. ページ数はいくつですか？
- 500未満→任意のCMSが機能します。エディタUXに基づいて選択します。
- 500-5,000→PayloadまたはSanity。どちらもこの範囲をよく処理します。
- 5,000-50,000→SupabaseまたはContentful（予算付き）。
- 50,000+→Supabase。他に経済的意味をなすものはありません。
3. あなたの月額CMS予算はいくつですか？
- $0→自己ホストPayload、自己ホストStrapi、またはMDX
- $25-50→Supabase ProまたはPayload Cloud
- $100-500→Sanity GrowthまたはStrapi Cloud
- $500+→ContentfulまたはSanity Enterprise
4. リアルタイムコラボレーションが必要ですか？
- はい、重要→Sanity（業界トップクラス）
- あると良い→Payload（ライブプレビューが近い）
- 気にしない→他のもの
違う方法で対応する方法
後知恵は価値があります。ここで私たちが変えることは次の通りです：
Payload に早く開始していたはずです。 Payload 3が成熟する前にカスタム管理パネルを使用して初期プロジェクトをいくつか構築しました。5K未満のページのサイトの場合、Payloadは管理UIの開発時間を大幅に短縮していたはずです。
Supabase-as-CMSパターンをもっと早く標準化していたはずです。 3つのSupabaseプロジェクトのそれぞれに、コンテンツモデリング、キャッシング、および再検証についてはわずかに異なる規約があります。その後、すべての新しい高容量プロジェクトに使用する内部テンプレートを作成しました。
非エンタープライズクライアント向けのContentful評価をスキップしていたはずです。 価格の崖は実際のもので、2回、複数週間の評価を経ていったのは、クライアントの予算がContentfulの価格と一致していないことに気づきました。最初に予算を尋ねるべきでした。
Next.jsプロジェクトの同様のCMS決定に直面している場合、私たちは私たちの経験についてもっと詳しく共有することに熱心です。価格ページを確認するか、直接連絡してください—私たちは毎日これを行っています。
FAQ
2026年のNext.js向けの最高のヘッドレスCMSは何ですか？
253K以上のページに対する本番環境の経験に基づいて、Payload CMS 3はNext.js App Routerのベストオーバーオール選択肢です。その Local API はネットワークオーバーヘッドを排除し、TypeScript型は自動的に生成されます。管理パネルはあなたのNext.jsアプリの内部に住んでいます。10,000ページを超えるサイトについて、カスタム管理インターフェースを備えたSupabaseをCMSレイヤーとしてお勧めします。
Payload CMSは本当に無料ですか？
Payload CMSはオープンソースであり、機能制限なく自己ホストするのは無料です。独自のホスティングとデータベース（MongoDBまたはPostgreSQL）を提供する必要があります。Payload Cloud は、それらのマネージドホスティングサービスは、2026年の本番環境での使用量あたり月額約$35から始まります。セルフホスト版には1シートあたりの料金はありません。
Supabaseを Next.js のCMSとして使用できますか？
はい、そしてスケーションで行います。253,000以上のページを合計する3つの本番環境サイトをSupabaseで実行しています。構造化されたデータ（プロファイル、リスティング、製品カタログ）ではなく、長文の編集コンテンツの場合に特に良く機能します。主なトレードオフは、独自のコンテンツ編集インターフェースを構築する必要があります—Supabaseのテーブルエディタは編集ワークフロー向けに設計されていません。
Strapi 5はNext.jsのためのPayload CMS 3とどのように比較されますか？
Strapi 5は、視覚的なContent-Type Builderを使用して非技術的なコンテンツ編集に優れています。Payload 3は、ローカルAPIとTypeScriptネイティブアプローチを使用して開発者体験に優れています。エディタが開発者の場合はPayloadを選択してください。エディタがマーケターの場合は、Strapiを選択してください。これのトピックをカバーする詳細なPayload vs Strapi比較を書きました。
Next.js向けの最も安いヘッドレスCMSは何ですか？
セルフホストPayload CMSとセルフホストStrapiの両方は本当に無料です。Gitリポジトリ内のMDXファイルはホスティング以外に何もコストがかかりません。マネージドサービスの場合、Supabase Proは月額$25で、スケールで最高の価値を提供します—253Kページを単一のProプランで提供しています。Sanityの無料層も小さなプロジェクト（最大3ユーザー、500K API リクエスト/月）に大いに適しています。
Next.jsプロジェクトのContentfulは価値がありますか？
Contentfulは、99.99% SLAが必要なエンタープライズチーム、Commercetoolsやそのようなツールの確立された統合が必要な場合、Salesforceがあり、$300+/月のBasic、Premium向けに$3,000+/月の予算がある場合に価値があります。スタートアップと中堅企業の場合、PayloadまたはSanityは比較可能な機能をコストの一部で提供します。
Next.js App RouterでヘッドレスCMSを使用する場合、ISRまたはSSRを使用する必要があります。
ページ数とコンテンツ更新頻度によります。5,000ページ未満のサイトの場合、ウェブフック経由のオンデマンド再検証を使用した静的生成が理想的です。5,000ページ以上の場合、動的レンダリングとISR（revalidate = 3600または同様）がより実用的です—すべてのデプロイで50Kページを構築することはできません。Payloadのローカル APIを使用すると、どちらの方法でも区別が重要です。ネットワークオーバーヘッドはありません。
WordPressからNext.js向けのヘッドレスCMSに移行できますか？
絶対に。複数のWordPress移行を完了しました。典型的なパスは：REST APIまたはWP-CLI経由のWordPressコンテンツをエクスポート、ターゲットCMSに変換およびインポート、そしてNext.jsでフロントエンドを再構築。Payload CMSはこれを特に円滑にします。既存のWordPressの投稿タイプと一致するようにコレクションをモデル化できるため。このプロセスの詳細については、ヘッドレスCMS開発ソリューションを参照してください。