ヘッドレスCMSの選び方：microCMS・Contentful・Sanityの比較軸

ヘッドレスCMSは、記事やページなどのコンテンツを管理し、API経由で表示側へ渡すCMSです。編集する部分と表示する部分を分けて設計したい場合や、同じ情報を複数のサイト・アプリへ渡したい場合に検討します。表示側は別に作るため、デザインや配信の方法を選びやすくなる一方で、表示側の実装、プレビュー、公開の反映、保守を別に用意する必要があります。

次のような場合は、ほかの選択肢と比べてから決めます。

• 更新が年に数回で、コードやファイルの更新で足りる。CMSを置かない構成も候補になります。
• 今のCMSで困っているのが、プラグインや権限の運用など、設定や体制で直せる点である。CMSの入れ替えより運用の見直しが先です。
• 編集画面で見た目を整えながら作る運用が中心で、表示側を開発・保守する担当がいない。編集と表示が一体のCMSの方が合う場合があります。

従来型のCMSでもAPIは使えます。たとえばWordPressには、JSONでデータをやり取りするREST APIがあり、別のアプリや独立した表示側へコンテンツを渡せます（WordPress REST API Handbook、確認日：2026年10月21日）。「従来型は密結合で危険、ヘッドレスなら安全」と二分せず、必要な分け方と運用の担当から選びます。WordPressを続けるか移すかの判断はWordPress移行の記事、サイト全体の構成はモダンWeb開発の構成判断で扱っています。

提供の形態は、サービス提供者が基盤を運用するSaaS型と、自社や委託先が設置・運用する自社設置型に分かれます。違いは運用の責任の範囲で、SaaSでも設定・権限・連携の保守は残り、オープンソースの製品にも事業者が運用するクラウド版があります。また、管理画面だけを自社で配置することと、コンテンツの保存・配信の基盤まで自社で持つことは別です。たとえばSanity Studioは自社で配置できますが、コンテンツはSanityのAPIとContent Lakeに保存されます（Sanity：Studio Hosting and deployment、確認日：2026年10月21日）。

CMSを比べる前に、誰が何を編集・承認・公開するか、どの言語で出すか、公開前にどう確認するか、既存のデータをどう移すかを決めます。次の表は要件整理票の例です。公式資料で確認できたことと、採用前に操作して確かめることを分けて記録します。

表は横にスクロールできます →

未確認の項目は、対応していない・対応済みのどちらとも決めず、確認する人と期限を付けて残します。人数の枠が足りることと、権限を分けられることは別の確認です。表示側とCMSの間で、APIの項目の変更を合意しながら進める方法は、APIファースト開発の記事で扱っています。

主な3製品とStrapi・Storyblokは、得意な編集のしかたと、プランごとの権限・言語・利用量の条件、実装と保守の分担で比べます。次の表は、公式資料をもとに、比べる入口と確認する条件を整理したものです（確認日：2026年10月21日）。プランの条件は変わるため、採用時に対象プランの最新の資料と契約で照合します。料金額や上限の一覧は載せていません。

表は横にスクロールできます →

表の主な根拠は、microCMSの料金プラン・ロール・CSVエクスポート・日本語と英語のフィールドの例、Contentfulの料金プラン・Localization strategies、Sanityの料金プラン・Localization、StrapiのCMSの料金・Cloudの料金、Storyblokの料金です（いずれも確認日：2026年10月21日）。料金表の空欄やアイコンだけの欄からは、機能の有無を判断していません。会社の規模や知名度だけで製品を決めず、要件整理票の条件で比べ、採用前に実際の編集者が試用版などで操作を確かめます。

CMSで「公開」を押すことと、読者に新しいページが表示されることは別の段階です。構成を選ぶときは、公開の反映、公開前のプレビュー、検索やフォームを分けて考えます。次の図は、本番を静的配信にする場合の構成例です。

• 静的配信（静的書き出し）：ビルドの時点でCMSの公開データからHTMLを作り、配信します。記事を更新するたびに再生成と配信が必要です。Next.jsの静的書き出し（output: 'export'）では、ISR（一定時間ごとの再生成）、Draft Mode、Cookieなど、サーバーで動く機能は使えません（Next.js：Static Exports）。
• 実行環境を使う構成：ISRやサーバーでの描画、Draft Modeが必要な場合は、その機能と版に対応したホスティングや実行環境を確認します。Cloudflareは、静的に書き出したNext.jsはPagesへ、サーバーの機能を使うNext.jsはWorkersへ配置する案内をしています（Cloudflare：Next.js）。本番は静的配信のままにして、プレビューだけを別の環境で動かす組み合わせもあります。

プレビューは、CMS側の設定と表示側の実装に分かれます。microCMSでは、管理画面でプレビューURLを設定したうえで、表示側で下書きのコンテンツを取得して描画する仕組みを実装する必要があります（microCMS：画面プレビュー）。Next.jsのDraft Modeは、Route HandlerでCookieを設定し、下書きを取得して表示する手段の1つですが、静的書き出しでは使えません（Next.js：Draft Mode、いずれも確認日：2026年10月21日）。公開用のビルドに下書きや認証情報を含めず、プレビューを見られる人の範囲も決めておきます。

公開の通知（Webhook）が届いたこと、CMSで公開済みになったこと、本番への反映が終わったことも、それぞれ別に確認します。ビルドや配信が失敗したときに誰へ通知し、誰が再実行するか、前の版を表示し続けるか戻すかを決めます。予約公開の時刻どおりに表示が切り替わったかも、配信の結果で確かめます。

サイト内の検索は、公開済みのHTMLから静的な検索用データを作る方法（Pagefindなど、確認日：2026年10月21日）、CMSの取得・検索のAPI、検索サービスなどから、対象・件数・権限・更新の頻度で選びます。公開記事の検索に、外部の検索サービスが常に必要なわけではありません。非公開や認証が必要な内容は、公開の検索データに入れません。お問い合わせフォームも、CMSとは別に受付・通知・迷惑送信の対策を用意します（実装の例はCloudflareで問い合わせフォームを作る記事）。

選定の記録には、要件、未確認の点、確認する担当と次の行動を残します。以下は説明のために想定した企業サイトの例で、製品の操作や移行の試験は行っていません。執筆者2名と承認・公開の担当1名の計3名で更新し、日本語と英語のコンテンツを持ち、既存のニュース記事を移したいという前提です。

表は横にスクロールできます →

この例では、権限の分離、言語ごとの公開、プレビュー、移行の確認が残るため、製品とプランの決定を保留し、確認する人と期限を決めます。公式資料で機能を確認できたことだけで採用を決めず、操作の確認と見積もりがそろってから比べます。

CMSの費用は、利用料に加えて、公開の基盤、プレビューや検索などの周辺機能、初期構築と移行、保守、将来の取り出しまで含め、同じ期間・人数・機能でそろえて比べます。CMSの利用料が無料でも、周辺の構築や運用まで無料になるわけではありません。金額が分からない項目は0円とせず、確認できた小計と分けて記録します。Webサイト全体の維持費は、中小企業のWebサイトの構成と維持費の記事で扱っています。

表は横にスクロールできます →

CSVやAPIでコンテンツを取り出せても、画像・参照・履歴・権限・ワークフローまで同じ状態で移せるとは限りません。たとえばmicroCMSのCSVエクスポートは、表示中の絞り込みの条件に沿ってコンテンツを出力する機能です（microCMS：CSVエクスポート）。ContentfulのCLIでも、版の履歴、スペースのメンバー、予約公開やワークフローは移されず、作成者の記録は実行した人に置き換わるとされています（Contentful：Import and export、いずれも確認日：2026年10月21日）。CMSの変更履歴と、ソースコードの版の管理やバックアップは用途が異なるため、別に確認します。URLの引き継ぎと検索評価への配慮はWordPress移行の記事で扱っていますが、転送を設定しただけで順位が保たれるとは限りません。

導入や入れ替えを始める前に、分かる範囲で次の点を確認します。すべてに当てはまっても、運用がうまくいくことが保証されるわけではありません。未確認の項目は、担当と確認の時期を決めて残します。

社内や外部に相談するときは、更新する人と承認する人、公開したい内容、今のCMSと困っている作業、必要な言語と時期、保守の体制について、分かる範囲をまとめておくと整理を進めやすくなります。資料がそろっていなくてもご相談いただけます。管理画面のパスワードや非公開の原稿を、相談フォームに書く必要はありません。