ヘッドレスCMS比較｜ヘッドレスWordPress・Contentful・Strapi・microCMSの選び方

ヘッドレスCMSを選ぶときは、「誰がどこでコンテンツを書くか」と「API・ホスティングを誰が管理するか」の2点で候補がほぼ絞れます。編集者がWordPressに慣れていて既存記事も多いならヘッドレスWordPress、運用の手間を減らしたいならContentfulやmicroCMSのようなSaaS型、データ構造やサーバーを自分たちで握りたいならStrapiのようなセルフホスト型が候補です。この記事では、それぞれの仕組みの違い、向いている案件、移行やロックインの考え方を比較し、自分のプロジェクトに合うものを判断できるようにします。

ヘッドレスCMSとは何か、通常のWordPressと何が違うか

通常のWordPressは、管理画面（コンテンツの入力・保存）とテーマ（HTMLの出力）が1つのアプリケーションにまとまっています。ヘッドレスCMSは表示側（ヘッド）を切り離し、コンテンツをAPIで配信するだけの役割に絞った構成です。表示はNext.jsやNuxtなどのフロントエンドフレームワーク、スマートフォンアプリ、デジタルサイネージなど、APIを読めるものなら何でも担当できます。

切り離すことで得られるのは、フロントエンドの技術選択の自由、静的生成やCDN配信による表示速度、複数チャネルへの同じコンテンツの配信です。一方で、WordPressならテーマを入れるだけで済んでいたプレビュー、検索、問い合わせフォーム、サイトマップ、OGP画像などを、フロントエンド側で自前で用意する必要があります。ヘッドレス化は「速くなる魔法」ではなく、表示側の開発と運用を引き受ける代わりに自由度を得る選択だと考えてください。

比較する4つの選択肢

ここでは性格の異なる代表的な4つを取り上げます。いずれも（2026年10月現在）開発・提供が続いている製品ですが、料金体系や無料枠の範囲は頻繁に変わるため、契約前に各公式サイトで最新の条件を確認してください。

ヘッドレスWordPress

WordPressをコンテンツ管理だけに使い、標準のREST API（/wp-json/wp/v2/ 以下）でデータを取り出す構成です。REST APIはWordPress 4.7からコアに含まれているため、追加のプラグインなしで投稿・固定ページ・カテゴリー・メディアを取得できます。GraphQLで取得したい場合はWPGraphQLプラグインを使う方法が広く知られています。

強みは、編集者が見慣れた管理画面とブロックエディターをそのまま使えること、既存サイトの記事資産を移行せずに活かせること、カスタム投稿タイプやカスタムフィールドで柔軟にデータ構造を作れることです。弱みは、WordPress本体のサーバー運用（更新・バックアップ・セキュリティ対策）が残ること、ブロックエディターの出力がHTMLの塊になりやすく、フロントエンドで細かく制御しにくいことです。

Contentful

海外発のSaaS型ヘッドレスCMSです。サーバーの管理は不要で、コンテンツモデル（項目の定義）を管理画面で設計し、REST APIやGraphQL APIで配信します。多言語や複数環境（開発用・本番用）の切り替えなど、大規模・多チャネル運用を想定した機能がそろっています。

管理画面は英語が中心で、料金も規模に応じて上がる傾向があります。小さなサイトでは機能を持て余しやすく、企業の複数ブランドや多言語サイトなど、コンテンツを組織で横断管理したいケースで力を発揮します。

Strapi

Node.jsで動くオープンソースのヘッドレスCMSで、自分のサーバーやクラウドに設置して使います。管理画面からコンテンツタイプを定義すると、対応するREST APIが自動で用意され、GraphQLもプラグインで追加できます。公式のホスティングサービス（Strapi Cloud）もあります。

データベースとコードを自分たちで持てるため、データ構造や権限、APIの挙動をコードで細かくカスタマイズできるのが強みです。その分、Node.jsアプリケーションの運用、メジャーバージョンアップ時の移行作業は自分たちの責任になります。開発チームにNode.jsの経験者がいるかどうかが選定の分かれ目です。

microCMS

日本発のSaaS型ヘッドレスCMSです。管理画面・ドキュメント・サポートが日本語で、APIスキーマを画面上で作り、REST APIで配信します。リッチエディターや画像配信、プレビュー連携など、国内のコーポレートサイトやメディアでよく求められる機能が用意されています。

非エンジニアの担当者が更新する国内案件では、日本語の管理画面であることが大きな利点です。一方、SaaSである以上、APIの呼び出し回数やメンバー数などはプランの範囲内で使うことになります。

比較表

細かい機能や料金ではなく、変わりにくい構造的な違いでまとめます。

この他にも Sanity、Directus など有力な選択肢があります。比較の軸は同じで、「SaaSかセルフホストか」「編集画面が担当者に合うか」を見れば整理できます。

ロックインと移行のしやすさ

ヘッドレスCMSは表示側と切り離されているため、CMSを乗り換えてもフロントエンドの大部分は流用できます。ただし、コンテンツそのものの移行は別問題です。

• SaaS型（Contentful、microCMS）は、データが事業者のクラウドにあります。APIやエクスポート機能で取り出せますが、リッチテキストの内部形式やコンテンツモデルの構造は製品ごとに異なるため、乗り換え時には変換スクリプトが必要になるのが普通です。
• セルフホスト型（WordPress、Strapi）は、データベースを丸ごと自分で持っているので取り出しやすい反面、フォーマットの独自性はやはり残ります。WordPressの場合、本文がブロックのコメント付きHTMLで保存されている点に注意が必要です。

どの製品を選んでも、フロントエンドでAPIのレスポンスを直接画面に流し込まず、自分たちの型（記事・カテゴリー・著者など）に変換する層を1枚挟んでおくと、将来の乗り換えコストを抑えられます。

失敗しない選び方

次の順に質問していくと、候補が自然に絞れます。

1. 既存のWordPressサイトがあり、記事資産が多いか。 多いなら、まずヘッドレスWordPressを検討します。記事の移行コストとリスクは想像以上に大きく、管理画面を変えないことで編集者の再教育も不要になります。
2. サーバーの運用を担当できる人がいるか。 いなければSaaS型が現実的です。WordPressやStrapiをセルフホストする場合、更新とバックアップを継続できる体制が前提になります。
3. 更新担当者は誰か。 非エンジニアの日本語話者が中心ならmicroCMSや日本語化されたWordPressの管理画面が扱いやすく、英語に抵抗のない開発チーム中心ならContentfulやStrapiも選択肢に入ります。
4. プレビューと公開フローをどう作るか。 ヘッドレス構成で最もつまずきやすいのが下書きのプレビューです。候補ごとに、フロントエンドとのプレビュー連携の方法が用意されているかを事前に確認してください。
5. そもそもヘッドレスが必要か。 ブログやコーポレートサイトで、表示速度が目的なら、通常のWordPressにキャッシュとCDNを組み合わせる方が安く速く済む場合があります。複数チャネル配信やフロントエンドの技術的な要件がはっきりしているときに、ヘッドレス化の価値が出ます。

導入前に確かめておきたいこと

候補が決まったら、本番の設計に入る前に小さな検証用プロジェクトを作り、次の点を実際に試すと判断を誤りにくくなります。

• 想定する記事数・画像数でAPIの応答速度と取得方法（ページ送り・絞り込み）に問題がないか
• 下書きプレビュー、予約公開、公開時のキャッシュ再生成（Webhook連携）が組めるか
• 編集担当者に管理画面を触ってもらい、入力しにくい項目がないか

ヘッドレスWordPressを選ぶ場合は、APIで公開したくない情報（ユーザー一覧など）がエンドポイントから見えていないかも確認してください。認証が必要な操作には、WordPress 5.6で追加されたアプリケーションパスワードなどの仕組みを使い、管理者のパスワードをフロントエンドのコードに埋め込まないことが大切です。

まとめ

• ヘッドレスCMSは、表示側を自分で作る代わりに、フロントエンドの自由度と多チャネル配信を得る構成です。
• 既存のWordPress資産を活かすならヘッドレスWordPress、運用の手間を減らすならContentfulやmicroCMS、データ構造とサーバーを自分で握るならStrapiが候補になります。
• 選定の軸は「既存資産」「サーバー運用の体制」「更新担当者」「プレビューの作りやすさ」の4つです。
• 料金や無料枠は変わりやすいため、契約前に公式サイトで最新の条件を確認し、小さな検証で使い勝手を試してから決めてください。

• ヘッドレスWordPressとNext.jsのISRで静的生成する方法
• ACFとREST APIでWordPressをヘッドレスCMSとして使う方法