Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

プロローグ — 「CMSはもはや単一カテゴリではない」

2010年代初頭、「CMS」という言葉は事実上WordPress一つを指していました。2026年現在、CMSは少なくとも5つの異なるカテゴリに分かれています。

1. **伝統的CMS（Traditional / Monolithic）** — コンテンツ + プレゼンテーションが一体。WordPress、Drupal、Joomla。

2. **ヘッドレスCMS（Headless）** — コンテンツはAPIのみ、フロントは自由。Strapi、Directus、Contentful。

3. **ハイブリッド / ビジュアルCMS** — ビジュアルエディター + ヘッドレスAPI。Storyblok、Builder.io、Plasmic。

4. **git-backed CMS** — コンテンツがマークダウンファイルとしてリポジトリにコミットされる。TinaCMS、Decap CMS、Outstatic。

5. **マークダウン + コードベースCMS** — コードと同じワークフロー。Contentlayer、Velite、Astro Content Collections、Nuxt Content。

本記事では、2026年5月時点でオープンソース陣営のヘッドレスCMS 12候補を整理し、マネージド（SaaS）陣営のSanity · Contentful · Hygraph · Storyblok · DatoCMS · ButterCMS · microCMS · Newtを比較軸として持ち込み、最後に「マーケティングサイト / ドキュメント / EC / モバイルアプリ」という4つのドメインに対する意思決定マトリクスを提示します。

核心の結論を先に — **2026年には「単一CMSで全てを扱う」時代が終わりました。** チームサイズ、データモデルの複雑度、コンテンツ編集者数、セルフホストの可否によって選択肢が5方向に分岐します。

1. ヘッドレス vs 伝統的CMS — 何が違うのか

伝統的CMSとヘッドレスCMSの本質的な違いはシンプルです。

| 軸 | 伝統的CMS（WordPress、Drupal） | ヘッドレスCMS（Strapi、Sanity） |

| --- | --- | --- |

| コンテンツ + 表現 | 一つのシステムで処理 | 分離。CMSはAPIのみ提供 |

| フロント自由度 | テーマシステムに依存 | あらゆるフレームワーク可能 |

| マルチチャネル | 基本Webのみ、モバイルは別 | 同一データでWeb/アプリ/サイネージ |

| SEO | サーバレンダリング標準 | SSG/SSRを自前構成 |

| 学習曲線 | 非エンジニアに親しみやすい | 開発者向け |

| パフォーマンス | プラグイン蓄積で重くなる | API駆動で軽く始められる |

2026年時点のトレンドは明確です。

- **WordPressは依然として全世界のウェブの約43%を占有**。W3Techsのデータはほぼ変わらず。

- しかし**新規マーケティング/プロダクトサイトの70%以上**がヘッドレスまたはgit-backedを選択。

- ヘッドレス市場自体は2022年比で約3倍に成長、2026年も二桁成長中。

要点は「WordPressが死んだ」ではなく**新規プロジェクトのデフォルトが変わった**ことです。WordPress自身でさえWP-API + Faust.js + ACF構成で**部分的にヘッドレス化**される流れがあります。

2. Strapi 5 — Node.jsヘッドレスの事実上の標準

Strapiは**Node.jsベースのオープンソースヘッドレスCMSの事実上の標準**です。GitHubスター65k以上、累計ダウンロード1億回以上。2024年末リリースのStrapi 5は**Document基盤のコンテンツモデル**へとパラダイムを乗り換えました。

コアコンセプト

- **Content-Type Builder** — 管理画面UIでデータモデル定義。マイグレーション自動生成。

- **Documentモデル（v5）** — 各コンテンツがDocument、その中に複数の言語/バージョンLocaleを持つ。

- **Draft & Publish** — 下書きと公開版を分離、ワークフロー対応。

- **Plugins** — 認証、i18n、メディアライブラリ、GraphQLなどをプラグインシステムで拡張。

強み

- セルフホスティングが無料（MITライセンスのCommunity Edition）。

- REST + GraphQLを同時提供。

- TypeScript優先 — v5で型安全性が大幅に強化。

- 豊富なプラグインマーケットプレイス。

- 日本語・韓国語など多言語サポートが堅牢。

弱み

- セルフホスト時の運用負担 — DB、Redis、メディアストレージを自前管理。

- 大規模コンテンツ（数十万件以上）で管理画面UIが遅くなる事例。

- Enterprise機能（SSO、細粒度RBAC）の一部は有料。

Strapi Cloud

2023年リリースのマネージドオプション。**インフラ運用を望まないチーム**向けの有料SaaS。セルフホストオプションが常に併存する点がContentful · Sanityとの本質的違いです。

いつ選ぶか

- Node.js / TypeScriptスタックを好むチーム。

- セルフホストを希望しつつ、管理画面UIを持つCMSが必要な場合。

- マーケティングサイト + 多言語 + メディアが混ざる中規模プロジェクト。

3. Directus 11 — 「あらゆるSQL DBを即座にAPI化」

Directusは他のヘッドレスCMSと出発点が異なります。**コンテンツ専用のデータベースを持ちません**。既存のPostgreSQL · MySQL · SQLiteの上に管理画面UIと自動生成されたREST/GraphQL APIを載せる構造です。

コアコンセプト

- **Instant API** — DBスキーマを読み取りREST + GraphQLを自動生成。

- **Schema-on-DB** — 管理画面で作成したコレクションが即実DBテーブル。

- **Flows** — ノーコード自動化。データ変更時にSlack/Webhook/メールなどをトリガー。

- **Insights** — 管理画面内でダッシュボード作成。

- **Files** — S3/GCS/Cloudflare R2など多様なストレージ対応。

強み

- **データ主権** — DBがユーザー所有のインフラに留まる。

- **レガシーDB再利用** — 既存のERP/社内システムDB上に管理画面を載せられる。

- BSL → MIT（2024年ライセンス簡素化）。

- ユーザー上限なしのセルフホスト無料オプション。

弱み

- 「Headless CMS」カテゴリ内ではやや異種。コンテンツワークフロー（Draft/Publish、レビュー）はStrapi比でシンプル。

- メディアライブラリは基本機能だが高度な資産管理（DAM）は別。

Directus Cloud

マネージドオプションあり。**セルフホスト0円 vs Cloud**両方が公式製品として運営されます。

いつ選ぶか

- 既にPostgreSQL/MySQLなどSQL DBがコアインフラの組織。

- 社内バックオフィス + 外部APIを一つのシステムで処理したいチーム。

- 「データは自社インフラに留まる必要がある」というコンプライアンス要件がある環境。

4. Payload 3 — Next.jsネイティブのフルスタックCMS

Payloadは**TypeScriptフルスタック**を掲げる新世代ヘッドレスCMSです。2024年11月正式リリースのPayload 3は決定的な一手を打ちました — **Next.js App Routerの内部で直接動作します**。別途サーバープロセスなく、Next.jsアプリと同一コードベースに管理画面UIとAPIが共存します。

コアコンセプト

- **Code-firstスキーマ** — コンテンツモデルをTypeScriptコードで定義。UIで定義してコードexportする方式ではない。

- **Local API** — DBを経由せず関数呼び出しで直接データアクセス。SSR/SSGで非常に高速。

- **アクセスコントロール** — 関数型の権限ポリシー。行単位・フィールド単位の制御。

- **Lexical Rich Text** — MetaのLexicalエディター採用。

- **Drafts & Versions** — 全コレクションでバージョン管理が標準。

強み

- **MITライセンス** + ユーザー上限なし + セルフホスト無料。

- **Next.jsと同一プロジェクト** — 別途デプロイパイプライン不要。

- TypeScript型がコンテンツモデルから自動生成。

- MongoDB · PostgreSQL · SQLiteすべて対応（Adapterパターン）。

弱み

- コード優先のため**非エンジニアがコンテンツモデルを変更しにくい**。

- Strapi · Directus比でコミュニティ規模がまだ小さい（成長中）。

- モバイルアプリのようにNext.jsと無関係のフロントでは強みが半減。

Payload Cloud

マネージドホスティングオプション。Vercel親和的なデプロイがデフォルト。

いつ選ぶか

- Next.jsフルスタックチームが一プロジェクト内で全て処理したいとき。

- TypeScript型安全性をコンテンツまで拡張したいチーム。

- 管理画面カスタマイズが深く必要なプロジェクト（PayloadはReactコンポーネントによる管理画面拡張が直感的）。

5. KeystoneJS 6 — GraphQL-first、Thinkmillの選択

KeystoneJSはオーストラリアのThinkmillが主導する**GraphQL-first**ヘッドレスCMSです。2022年KeystoneJS 6正式リリース後安定軌道。2026年も着実な保守と漸進的機能追加が続いています。

コアコンセプト

- **Code-firstスキーマ** — TypeScriptでデータモデル定義。

- **Prisma ORMベース** — DB接続およびマイグレーションをPrismaが担当。

- **自動生成GraphQL** — モデルからCRUDクエリ/ミューテーションを自動生成。

- **管理画面UI** — Reactベース、強力なフィールドカスタマイズ。

強み

- **GraphQLが第一級市民** — RESTは別途構成が必要。

- Prismaベースのためマイグレーションワークフローが堅牢。

- TypeScript型安全性。

弱み

- コミュニティ規模はStrapi · Directus比で小さい。

- セルフホスト以外の公式Cloudがない（Thinkmillの事業モデルはCMS自体の製品化よりコンサルティング寄り）。

- GraphQLを使わないチームには魅力が半減。

いつ選ぶか

- GraphQLを積極的に使うプロダクトチーム。

- Prismaベースのフルスタック一貫性を求めるチーム。

- Strapiの多様なプラグインより安定性と単純さを優先するとき。

6. Sanity — GROQとリアルタイムコラボのマネージドチャンピオン

Sanityはノルウェー拠点の企業が運営する**マネージド（SaaS）ヘッドレスCMS**です。コンテンツスタジオ自体はオープンソース（MIT）ですが、データセットとCDNはSanity Cloudで運用されます。

コアコンセプト

- **GROQ（Graph-Relational Object Queries）** — Sanity独自のクエリ言語。GraphQL/SQLと異なるグラフ型トラバース構文。

- **Real-time Collaboration** — コンテンツ編集がGoogle Docs級のリアルタイム同期。

- **Portable Text** — JSONベースのリッチテキスト形式。ヘッドレスに最も適合。

- **Studio Customization** — Reactベースのスタジオを自由にカスタム。

強み

- リアルタイムコラボが最も滑らか。

- コンテンツモデルの柔軟性（GROQで任意トラバース）。

- 無料ティアが寛大（3ユーザー、10kドキュメントまで）。

- Image Pipeline（自動変換、CDN）が標準提供。

弱み

- **コンテンツデータがSanityインフラに居住** — セルフホストオプションなし。

- GROQは学習が必要（GraphQLとは異なる）。

- 大量ユーザー/ドキュメント時に価格が急速に上昇。

いつ選ぶか

- コンテンツエディターが多数でリアルタイムコラボが核心。

- セルフホスト運用人員がいない、または希望しないチーム。

- コンテンツモデルが複雑で頻繁に変更されるプロダクト。

7. Storyblok — Visual Editorの強者

Storyblokはオーストリア拠点企業のマネージドヘッドレスCMS。差別化ポイントは一つに集約されます — **Visual Editorが最も優れている**。

コアコンセプト

- **Visual Editor** — 実際のフロントエンドサイトを管理画面内でプレビューしながら編集。

- **Blocks** — 再利用可能なコンテンツブロック（Hero、Feature、CTAなど）。

- **Stories** — ページ単位。ブロックツリーで構成。

- **Field Plugins** — 管理画面フィールドをカスタムReactコンポーネントで拡張。

強み

- マーケター/コンテンツエディターがページを直接組み立て。

- 多言語（Spaces単位分離）が堅牢。

- 100以上の統合（EC、分析、自動化）。

弱み

- マネージド専用（セルフホストオプションなし）。

- 価格がユーザー/スペース単位で急速に増加。

- Visual Editorに強く結合 — フロントエンドもその構造に従う必要。

いつ選ぶか

- マーケティングサイトがメインワークロード。

- 非エンジニアがページレイアウトを直接調整する必要のある環境。

- Builder.io · Plasmicと同じビジュアルページビルダーカテゴリで最も成熟。

8. TinaCMS — git-backed、マークダウン中心

TinaCMSはgitをバックエンドとして使うヘッドレスCMSです。コンテンツが**データベースではなくマークダウン/MDXファイルとしてリポジトリに保存**されます。

コアコンセプト

- **git-backed** — 保存はリポジトリへのcommit。コンテンツ履歴がそのままgit履歴。

- **Visual Editing** — Next.js · Hugo · Astroなどのフロントエンドを管理画面で編集。

- **TinaCMS Cloud** — gitブランチワークフローを管理するマネージドオプション。

強み

- コンテンツが**開発者ワークフロー内にある** — PR/レビューが自然。

- 静的サイトジェネレータと相性良好（Hugo、Astro、Next.js）。

- コンテンツがインフラにロックインされない。

弱み

- コンテンツエディターがgitを理解する必要（Cloudが隠してくれるが）。

- 大規模コンテンツ（数万件）でビルド速度がボトルネック。

- 権限モデルがgit権限と強く結合。

いつ選ぶか

- 開発者中心のドキュメントサイト（例：技術ブログ、製品ドキュメント）。

- コンテンツ変更量が少なく履歴が重要な環境。

- マークダウン/MDX優先ワークフロー。

9. Decap CMS — 旧Netlify CMSの後継

Decap CMSは2022年にNetlify CMSから分離した後継プロジェクトです。TinaCMSと同じカテゴリ（git-backed）ですが出自が異なります — **Jamstack初期からの正統git-backed CMS**。

コアコンセプト

- **git-backed** — GitHub · GitLab · Bitbucket上で動作。

- **単一HTML + JS管理画面** — 静的サイトの`/admin`パスに管理画面が配置。

- **Open Authoring** — 外部コントリビューターがfork → PRでコンテンツ貢献。

強み

- 本当に軽量（管理画面が単一の静的アセット）。

- Jamstackサイト（Hugo、Eleventy、Jekyll）と自然に結合。

- コスト0円（ホスティングが静的なのでほぼ無料）。

弱み

- コミュニティがNetlify CMS時代より小さい。

- 機能発展がやや停滞。

- 大規模コンテンツ / 複雑ワークフローには不向き。

いつ選ぶか

- 小さな静的サイト、個人ブログ、OSSプロジェクトドキュメント。

- 外部コントリビューターを受け入れるOSSサイト。

- 最も軽量なCMSが必要なとき。

10. Webiny · Apostrophe · Plone · Drupal — その他の候補

Webiny

- サーバレス（AWS Lambda · DynamoDB · S3 · CloudFront）上で動作するオープンソースヘッドレス。

- マルチテナンシーが強み。大規模SaaS運用事例あり。

- AWSコストが使用量とともに変動。

Apostrophe

- Node.jsベース、ページ編集UXが強み。

- 「In-context editing」 — サイトを見ながらそのまま編集。

- マーケティング/広報サイトが主ターゲット。

Plone CMS

- Python（Zope）ベースの老舗エンタープライズCMS。

- セキュリティ、権限モデル、多言語が堅牢。

- 政府 · 大学 · 非営利などで現役。

Drupal 10/11

- PHPベース。2025年Drupal 11リリース。

- 複雑なコンテンツモデル、多言語、権限が強み。

- JSON:API · GraphQLモジュールで**セミヘッドレス**運用可能。

- 伝統的CMSとヘッドレスの境界に位置。

11. WordPressのヘッドレス陣営 — WP-API + Faust.js + ACF

WordPress自体は伝統的CMSですが、2026年には**ヘッドレスとして使う流れが安定化**しました。

コアツール

- **WP REST API** — WordPressコアに内蔵のRESTエンドポイント。

- **WPGraphQL** — コミュニティプラグイン。GraphQLエンドポイント提供。

- **ACF（Advanced Custom Fields）** — カスタムフィールド定義。ヘッドレスでも核心。

- **Faust.js** — WP Engineが作ったNext.jsフレームワーク。WordPressをバックエンドとするSSR/SSG。

強み

- 既存のWordPressコンテンツ/プラグイン資産をそのまま活用。

- コンテンツエディターが慣れたWordPress管理画面を使う。

- 無料 + 広範なホスティングオプション。

弱み

- WordPressコアの重さがそのまま残る。

- プラグイン互換性（ヘッドレスで動作しないプラグインが多数）。

- PHP運用負担。

いつ選ぶか

- 既に巨大なWordPressコンテンツ資産があるメディア/出版。

- コンテンツエディターがWordPress以外の学習を拒否するとき。

- 段階的マイグレーション戦略。

12. マネージドヘッドレス市場 — Contentful · Hygraph · DatoCMS · ButterCMS · Cosmic

マネージド（SaaS）ヘッドレスCMSはオープンソースと異なるゲームをします。**インフラ運用を買わない**ことが核心価値。

| 製品 | 特徴 | 適合チーム |

| --- | --- | --- |

| Contentful | マネージドヘッドレスの事実上のリーダー。エンタープライズ価格。 | 大企業、グローバルマーケティングサイト |

| Hygraph（旧GraphCMS） | GraphQL優先。Content Federation。 | GraphQL優先チーム |

| DatoCMS | 画像/メディアパイプラインが強み。 | デザイン重視サイト |

| ButterCMS | 最もシンプルなSaaSヘッドレス。素早く開始。 | ブログ/マーケティング中心の小規模 |

| Cosmic | マルチテナント親和。コンテンツAPI + CLI。 | 高速プロトタイプ |

新興/中間カテゴリ

- **Caisy** — ドイツ系新興、マルチプロジェクトコンソール。

- **Prepr CMS** — パーソナライゼーション + A/Bテスト統合。

- **Magnolia** — エンタープライズ専用。ヘッドレス + 伝統的ハイブリッド。

- **Crystallize** — EC親和ヘッドレス。

Builder.io · Plasmic — ビジュアルページビルダー

- **Builder.io** — ビジュアルエディター + ヘッドレスAPI + A/Bテスト + AIページ生成。

- **Plasmic** — Figma → コードに近い表現力。デザイナー親和。

この2製品は**「ビジュアルページビルダー + ヘッドレスCMS」**というハイブリッドカテゴリで最も目立ちます。Storyblokと直接競合。

13. 日本のヘッドレスCMS — microCMS · Newt · a-blog cms

日本市場には独自のヘッドレスCMS陣営が堅固に存在します。

microCMS

- 日本ヘッドレスCMSの事実上のリーダー。

- 日本語UI · 日本IPデータセンター · 日本企業のEC契約互換性。

- 価格が明確で無料ティアが寛大。

- 日本国内大型メディア、ECサイト多数が使用。

Newt

- 日本の新世代ヘッドレスCMS。microCMSよりフルスタック親和。

- SanityスタイルのコンテンツモデリングとGROQ類似クエリ。

- 日本のスタートアップ中心に急成長中。

a-blog cms

- 日本のアップルップル社の伝統的CMS。PHPベース。

- 日本国内の企業サイトでシェアが高い。

- ヘッドレスモードもサポートするが伝統的モードが主。

Movable Type

- シックス・アパート日本が引き継ぎ、日本の企業サイトで強い。

- 静的出力 + CMSの元祖格。

Sanity · Contentfulの日本進出

- Sanityは日本進出が速く、microCMSと直接競合。

- Contentfulの日本ユーザーも着実に増加。

14. 韓国市場のCMS — 何が違うか

韓国市場は日本ともまた異なる特殊性があります。

- **NAVER カフェ · ブログ** — 事実上CMSの役割を一部代替。コンテンツ生産者の多くが依然としてNAVERエコシステム内。

- **自社開発CMS** — 大型メディア/EC（NAVER、Kakao、Coupang、Woowa Brothers）は自社CMSを持つ。

- **Strapi · WordPressがSMBで優勢** — 韓国語ホスティング + ハングル入力互換性で検証済み。

- **microCMSは韓国進出が薄い** — 日本語インターフェース以外、韓国市場への直接対応が乏しい。

- **国産CMSの試み** — Treasure Korea、Modusなどの試みはあったが、グローバル陣営対比でシェア低調。

核心観察：韓国市場でオープンソースヘッドレスCMS導入は**Strapi · Payload · TinaCMS**の順に多く、マネージドは**Contentful · Sanity · Storyblok**が主な検討対象となります。

15. マークダウン/MDXベース — Contentlayer · Velite · Astro · Nuxt Content

「CMS」を広く定義すると**マークダウンファイル + 静的サイトジェネレータ**もCMSの一形態です。2026年にはこのカテゴリが開発者ブログ/ドキュメント市場のデフォルトです。

Contentlayer 2

- マークダウン/MDXファイルから型安全なデータ生成。

- Next.jsと最も相性が良い。

- **2024年から公式開発が中断（paused）** — コミュニティフォーク（Contentlayer 2）が保守継続。

Velite

- Contentlayerの事実上の後継。型安全 + スキーマ検証（Zod）。

- ビルド速度が優秀。

- 2025年以降の新規プロジェクトのデフォルト選択。

Astro Content Collections

- Astroフレームワークに内蔵のコンテンツシステム。

- スキーマ検証、型生成、自動ルーティングすべて内蔵。

- ドキュメントサイト（Starlight）とともに使用。

Nuxt Content

- Nuxt（Vue）陣営のコンテンツシステム。

- マークダウン + コンポーネント埋め込み + 検索まで内蔵。

Outstatic

- Next.jsネイティブgit-backed CMS。

- TinaCMSと類似だがより軽量。

- 開発者ブログ/ポートフォリオに適合。

MDXの位相

- マークダウン + JSX = MDX。2026年すべての主要静的サイトジェネレータの第一級市民。

- コードブロック内にReactコンポーネント埋め込み → インタラクティブドキュメント。

- 短所：ビルド時のJSX検証が厳格で、コンテンツ作成者がミスしやすい（このブログの`mdxValidation.ts`のような検証器が必要になった理由）。

16. データモデル — Document vs Collection vs Block

ヘッドレスCMSの本質はデータモデルです。2026年時点の標準パターン。

Documentモデル（Sanity、Strapi 5）

- 各コンテンツ = 一つのDocument。

- Document内に任意のフィールド構造。

- 多言語/バージョンがDocumentに付属。

Collectionモデル（Directus、Payload、KeystoneJS）

- コンテンツ = Collection（テーブル）+ Row（項目）。

- SQL親和。JOINが自然。

- 関係型データモデリングが明瞭。

Blockモデル（Storyblok、Builder.io）

- コンテンツ = Page + Blockツリー。

- ビジュアルエディター親和。

- マーケティングサイトに最適。

Portable Text（Sanity）

- リッチテキストがJSONツリー。

- 任意のカスタムブロック挿入可能。

- 最もヘッドレス親和的なリッチテキスト表現。

どのモデルを選ぶべきか

- コンテンツが比較的シンプル + 多言語 = Document。

- 関係型 + バックオフィス = Collection。

- ページビルダー = Block。

- 任意構造の長文 = Portable TextまたはMDX。

17. API — REST vs GraphQL vs GROQ

ヘッドレスCMSはAPIの形で差別化します。

| API | 強み | 弱み | 代表製品 |

| --- | --- | --- | --- |

**2026年のデフォルトは「REST + GraphQL同時提供」**。クライアントが二者択一します。

CDNとキャッシュ

ヘッドレスの真の価値は**API応答がCDNでキャッシュされること**。SanityのCDN、ContentfulのEdge Cache、Strapi Cloudのキャッシュ。セルフホストの場合はCloudflare/Fastlyで直接構成。

18. ヘッドレスEC — Medusa · Saleor · Crystallize

CMSとECの境界が曖昧になっています。ヘッドレスEC陣営の簡単な地図。

Medusa

- Node.jsベースのオープンソースECバックエンド。

- ヘッドレス + モジュラーアーキテクチャ。

- Shopifyのオープンソース代替として浮上。

Saleor

- Python · GraphQLベース。

- エンタープライズ親和。

- マルチチャネル、多言語に強い。

Crystallize

- ヘッドレスCMS + ECハイブリッド。

- コンテンツと商品データを同一モデルで扱う。

Shopifyのヘッドレス陣営

- **Hydrogen** + **Oxygen** — Shopifyが作ったRemixベースのヘッドレスフレームワーク。

- コンテンツ部分はSanity/Contentfulと頻繁に結合。

次の記事候補

ヘッドレスECは単独で一本の記事になります。**Medusa vs Saleor vs Hydrogen比較 + コンテンツCMS結合パターン**を続編として扱います。

19. ユースケース別推奨 — 決定マトリクス

ここから4つのドメインに対して率直な推奨をします。

マーケティングサイト

- **小規模（1-3ページ）**：TinaCMSまたはDecap CMS — git-backedの軽さ。

- **中規模（10-50ページ、多言語）**：Strapi 5またはSanity — コンテンツモデル柔軟性。

- **大規模（ブロックビルダー、非エンジニア多数）**：StoryblokまたはBuilder.io — ビジュアルエディター。

技術ドキュメント

- **開発者中心ドキュメント**：Contentlayer/Velite + MDX、またはAstro Starlight。

- **大規模ドキュメント（検索、多言語）**：TinaCMS + 自前検索、またはNextra。

- **多様なコントリビューター**：Decap CMS（Open Authoring）。

モバイルアプリバックエンド

- **単一バックエンドでWeb + アプリ + IoT**：Strapi 5またはDirectus。

- **TypeScript一貫性優先**：Payload 3。

- **リアルタイム同期が必要**：SanityまたはFirebaseの結合。

EC + コンテンツ

- **Shopifyユーザー**：Hydrogen + Sanity/Contentful。

- **オープンソース**：Medusa + StrapiまたはPayload。

- **コンテンツと商品統合**：Crystallize。

社内バックオフィス + 外部API

- **第一選択**：Directus 11 — 既存DBをそのまま使用。

- **フルスタック統合**：Payload 3 — Next.jsと同一コードベース。

20. 意思決定チェックリスト

次の5つの質問に順に答えるとヘッドレスCMS選択が80%絞られます。

1. **セルフホスト vs マネージド** — インフラ運用人員がいるか、データ主権が必須か？

- セルフホスト：Strapi、Directus、Payload、KeystoneJS。

- マネージド：Sanity、Contentful、Storyblok、Hygraph。

2. **コンテンツエディター数** — 非エンジニアが日常的にコンテンツを扱うか？

- 多い：Sanity、Storyblok、Strapi。

- 少ない / 開発者のみ：TinaCMS、Payload、Velite。

3. **データモデル複雑度** — 関係型/JOINが多いか、ページビルダー型か？

- 関係型：Directus、KeystoneJS、Payload。

- ページビルダー型：Storyblok、Builder.io。

- 長文中心：Sanity、Strapi。

4. **フロントエンドスタック** — Next.jsにロックインされるか、マルチチャネルか？

- Next.js優先：Payload（Local API）、Sanity、Contentlayer/Velite。

- マルチチャネル（Web + アプリ + サイネージ）：Strapi、Sanity、Contentful。

5. **予算 / ライセンス** — 無料セルフホストが必須か？

- 無料必須：Strapi（CE）、Directus、Payload、KeystoneJS、TinaCMS、Decap。

- 有料可：Sanity（Free → 有料）、Contentful、Storyblok。

21. よくある7つの間違い

1. **「WordPressは終わった」と仮定** — シェア43%は依然として事実。マイグレーションコストを過小評価してはいけない。

2. **データモデルをコードと分離しない** — コンテンツモデルがコードPRフローに入らないと運用負担が大きい。

3. **セルフホストの運用コストを0円と仮定** — Strapi Communityでもデータベース · Redis · S3 · モニタリングは必要。

4. **GraphQLが常に正しいと仮定** — キャッシュが重要なマーケティングサイトはREST + CDNがより速いケースが多い。

5. **画像パイプラインを自前で作る** — Sanity · Contentful · DatoCMSのようなマネージドのimage transformが圧倒的に速く安い。

6. **Visual Editorが万能と信じる** — デザインシステムが不在な状態でVisual Editorを導入するとページ一貫性が壊れる。

7. **多言語を後から追加** — i18nはデータモデル初期決定。後から追加するとマイグレーションが地獄。

22. 2026年トレンド — AI · コラボ · Edge

最後に2026年の3つの大きな流れ。

AIコンテンツアシスタント

- Sanity、Contentful、Storyblokすべてが**AIコンテンツ生成/要約/翻訳**を管理画面に統合。

- Builder.ioは**AIページ生成**（プロンプト → ページツリー）を正式機能化。

- Strapiはプラグイン形態でAIワークフローをサポート。

リアルタイムコラボの一般化

- Sanityが始めたリアルタイムコラボがStoryblok · Contentfulに拡散。

- Strapi · Directusもマルチユーザーロック/マージモデルを強化。

Edgeデプロイ + コンテンツ

- Cloudflare Workers · Vercel Edge · Netlify EdgeからCMS APIを直接呼ぶ。

- SanityのGROQはEdge親和的。

- Contentful · HygraphはGraphQL CDNを提供。

次の記事候補

- **ヘッドレスEC深掘り - Medusa · Saleor · Hydrogen実戦比較**

- **MDXコンテンツパイプライン - Contentlayer終了後のVelite/Astro Contentへの移行**

- **Visual Editorの終わり - Storyblok · Builder.io · Plasmicの実際の運用ノウハウ**

> 「CMSはもはや単一の製品カテゴリではない。チームのデータモデル、コンテンツエディター数、セルフホストの可否によって異なる答えが出る。一つの道具で全てを扱おうとする試みはほぼ常に失敗する。」

— オープンソースヘッドレスCMS 2026、終わり。

参考文献

- [Strapi 公式ドキュメント](https://docs.strapi.io/)

- [Strapi GitHub - strapi/strapi](https://github.com/strapi/strapi)

- [Strapi 5 Document Service API](https://docs.strapi.io/dev-docs/api/document-service)

- [Directus 公式ドキュメント](https://docs.directus.io/)

- [Directus GitHub - directus/directus](https://github.com/directus/directus)

- [Payload CMS 公式ドキュメント](https://payloadcms.com/docs)

- [Payload GitHub - payloadcms/payload](https://github.com/payloadcms/payload)

- [KeystoneJS 公式ドキュメント](https://keystonejs.com/docs)

- [Keystone GitHub - keystonejs/keystone](https://github.com/keystonejs/keystone)

- [Sanity 公式ドキュメント](https://www.sanity.io/docs)

- [Sanity GROQ Reference](https://www.sanity.io/docs/groq)

- [Storyblok 公式ドキュメント](https://www.storyblok.com/docs)

- [TinaCMS 公式ドキュメント](https://tina.io/docs)

- [TinaCMS GitHub - tinacms/tinacms](https://github.com/tinacms/tinacms)

- [Decap CMS 公式サイト](https://decapcms.org/)

- [Decap CMS GitHub - decaporg/decap-cms](https://github.com/decaporg/decap-cms)

- [Webiny 公式ドキュメント](https://www.webiny.com/docs)

- [Apostrophe CMS](https://apostrophecms.com/)

- [Plone CMS](https://plone.org/)

- [Drupal 11 Release Notes](https://www.drupal.org/about/11)

- [WPGraphQL](https://www.wpgraphql.com/)

- [Faust.js by WP Engine](https://faustjs.org/)

- [Advanced Custom Fields](https://www.advancedcustomfields.com/)

- [Contentful 公式ドキュメント](https://www.contentful.com/developers/docs/)

- [Hygraph 公式サイト](https://hygraph.com/)

- [DatoCMS](https://www.datocms.com/)

- [ButterCMS](https://buttercms.com/)

- [Cosmic](https://www.cosmicjs.com/)

- [Builder.io](https://www.builder.io/)

- [Plasmic](https://www.plasmic.app/)

- [microCMS (Japan)](https://microcms.io/)

- [Newt (Japan)](https://www.newt.so/)

- [Movable Type](https://www.movabletype.jp/)

- [a-blog cms](https://www.a-blogcms.jp/)

- [Contentlayer GitHub - contentlayerdev/contentlayer](https://github.com/contentlayerdev/contentlayer)

- [Velite](https://velite.js.org/)

- [Astro Content Collections](https://docs.astro.build/en/guides/content-collections/)

- [Nuxt Content](https://content.nuxt.com/)

- [Outstatic](https://outstatic.com/)

- [Medusa](https://medusajs.com/)

- [Saleor](https://saleor.io/)

- [Crystallize](https://crystallize.com/)

- [Shopify Hydrogen](https://hydrogen.shopify.dev/)

- [W3Techs - CMS Usage Statistics](https://w3techs.com/technologies/overview/content_management)

- [Jamstack.org](https://jamstack.org/)

- [Headless CMS Comparison - headlesscms.org](https://headlesscms.org/)