Skip to content
Published on

オープンソース ヘッドレスCMS 2026 完全ガイド - Strapi 5 · Directus 11 · Payload 3 · KeystoneJS · Sanity · Storyblok · TinaCMS · Decap CMS 深掘り分析

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 「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強み弱み代表製品
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%絞られます。

  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、終わり。

参考文献

Discuss on Twitter • View on GitHub