- プロローグ — 「CMSはもはや単一カテゴリではない」
- 1. ヘッドレス vs 伝統的CMS — 何が違うのか
- 2. Strapi 5 — Node.jsヘッドレスの事実上の標準
- 3. Directus 11 — 「あらゆるSQL DBを即座にAPI化」
- 4. Payload 3 — Next.jsネイティブのフルスタックCMS
- 5. KeystoneJS 6 — GraphQL-first、Thinkmillの選択
- 6. Sanity — GROQとリアルタイムコラボのマネージドチャンピオン
- 7. Storyblok — Visual Editorの強者
- 8. TinaCMS — git-backed、マークダウン中心
- 9. Decap CMS — 旧Netlify CMSの後継
- 10. Webiny · Apostrophe · Plone · Drupal — その他の候補
- 11. WordPressのヘッドレス陣営 — WP-API + Faust.js + ACF
- 12. マネージドヘッドレス市場 — Contentful · Hygraph · DatoCMS · ButterCMS · Cosmic
- 13. 日本のヘッドレスCMS — microCMS · Newt · a-blog cms
- 14. 韓国市場のCMS — 何が違うか
- 15. マークダウン/MDXベース — Contentlayer · Velite · Astro · Nuxt Content
- 16. データモデル — Document vs Collection vs Block
- 17. API — REST vs GraphQL vs GROQ
- 18. ヘッドレスEC — Medusa · Saleor · Crystallize
- 19. ユースケース別推奨 — 決定マトリクス
- 20. 意思決定チェックリスト
- 21. よくある7つの間違い
- 22. 2026年トレンド — AI · コラボ · Edge
- 参考文献
プロローグ — 「CMSはもはや単一カテゴリではない」
2010年代初頭、「CMS」という言葉は事実上WordPress一つを指していました。2026年現在、CMSは少なくとも5つの異なるカテゴリに分かれています。
- 伝統的CMS（Traditional / Monolithic） — コンテンツ + プレゼンテーションが一体。WordPress、Drupal、Joomla。
- ヘッドレスCMS（Headless） — コンテンツはAPIのみ、フロントは自由。Strapi、Directus、Contentful。
- ハイブリッド / ビジュアルCMS — ビジュアルエディター + ヘッドレスAPI。Storyblok、Builder.io、Plasmic。
- git-backed CMS — コンテンツがマークダウンファイルとしてリポジトリにコミットされる。TinaCMS、Decap CMS、Outstatic。
- マークダウン + コードベース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 | 強み | 弱み | 代表製品 |
|---|---|---|---|
| REST | シンプル、キャッシュ親和 | オーバー/アンダーフェッチ | Strapi、Directus、WordPress |
| GraphQL | クライアント主導クエリ | キャッシュ困難、学習曲線 | KeystoneJS、Hygraph、Contentful |
| GROQ | グラフトラバース、Sanity専用 | 学習必要、Sanity外で使用不可 | Sanity |
| OData / JSON:API | 標準仕様 | シェア低い | Drupal JSON: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%絞られます。
- セルフホスト vs マネージド — インフラ運用人員がいるか、データ主権が必須か？
- セルフホスト：Strapi、Directus、Payload、KeystoneJS。
- マネージド：Sanity、Contentful、Storyblok、Hygraph。
- コンテンツエディター数 — 非エンジニアが日常的にコンテンツを扱うか？
- 多い：Sanity、Storyblok、Strapi。
- 少ない / 開発者のみ：TinaCMS、Payload、Velite。
- データモデル複雑度 — 関係型/JOINが多いか、ページビルダー型か？
- 関係型：Directus、KeystoneJS、Payload。
- ページビルダー型：Storyblok、Builder.io。
- 長文中心：Sanity、Strapi。
- フロントエンドスタック — Next.jsにロックインされるか、マルチチャネルか？
- Next.js優先：Payload（Local API）、Sanity、Contentlayer/Velite。
- マルチチャネル（Web + アプリ + サイネージ）：Strapi、Sanity、Contentful。
- 予算 / ライセンス — 無料セルフホストが必須か？
- 無料必須：Strapi（CE）、Directus、Payload、KeystoneJS、TinaCMS、Decap。
- 有料可：Sanity（Free → 有料）、Contentful、Storyblok。
21. よくある7つの間違い
- 「WordPressは終わった」と仮定 — シェア43%は依然として事実。マイグレーションコストを過小評価してはいけない。
- データモデルをコードと分離しない — コンテンツモデルがコードPRフローに入らないと運用負担が大きい。
- セルフホストの運用コストを0円と仮定 — Strapi Communityでもデータベース · Redis · S3 · モニタリングは必要。
- GraphQLが常に正しいと仮定 — キャッシュが重要なマーケティングサイトはREST + CDNがより速いケースが多い。
- 画像パイプラインを自前で作る — Sanity · Contentful · DatoCMSのようなマネージドのimage transformが圧倒的に速く安い。
- Visual Editorが万能と信じる — デザインシステムが不在な状態でVisual Editorを導入するとページ一貫性が壊れる。
- 多言語を後から追加 — 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 公式ドキュメント
- Strapi GitHub - strapi/strapi
- Strapi 5 Document Service API
- Directus 公式ドキュメント
- Directus GitHub - directus/directus
- Payload CMS 公式ドキュメント
- Payload GitHub - payloadcms/payload
- KeystoneJS 公式ドキュメント
- Keystone GitHub - keystonejs/keystone
- Sanity 公式ドキュメント
- Sanity GROQ Reference
- Storyblok 公式ドキュメント
- TinaCMS 公式ドキュメント
- TinaCMS GitHub - tinacms/tinacms
- Decap CMS 公式サイト
- Decap CMS GitHub - decaporg/decap-cms
- Webiny 公式ドキュメント
- Apostrophe CMS
- Plone CMS
- Drupal 11 Release Notes
- WPGraphQL
- Faust.js by WP Engine
- Advanced Custom Fields
- Contentful 公式ドキュメント
- Hygraph 公式サイト
- DatoCMS
- ButterCMS
- Cosmic
- Builder.io
- Plasmic
- microCMS (Japan)
- Newt (Japan)
- Movable Type
- a-blog cms
- Contentlayer GitHub - contentlayerdev/contentlayer
- Velite
- Astro Content Collections
- Nuxt Content
- Outstatic
- Medusa
- Saleor
- Crystallize
- Shopify Hydrogen
- W3Techs - CMS Usage Statistics
- Jamstack.org
- Headless CMS Comparison - headlesscms.org