ヘッドレスCMSは、記事を管理する画面とサイトの見た目を作る部分を切り離し、APIで中身だけを渡すCMSです。表示が速く見た目の自由度も高い一方、更新や確認の作業が開発者に寄ります。WordPressとの違いと、導入してよいサイトの条件がこの記事のテーマです。
この記事でわかること
- ヘッドレスCMSの仕組みと、WordPressのような従来型CMSとの違い
- メリット・デメリットを、公開後の運用まで含めて比べた結果
- CaaS型とセルフホスト型の違い、代表的なサービスの位置づけ
- 見積もりに出てこない「公開後に増える費用と作業」の中身
- 導入してよいサイト・避けたほうがよいサイトの見分け方と、発注前に決めておく項目
参照: WordPress Developer Resources「REST API Handbook」（参照）／Google検索セントラル「JavaScript SEO の基本」（参照）／microCMS 料金・ドキュメント（参照）
CMSそのものの基本から押さえたい方は、先にCMSとは？仕組みと主要ツールの比較を読むと、この記事の比較がすっと入ります。
先に結論
ヘッドレスCMSは、「見た目を自由に作りたい」「同じ中身を複数の場所に出したい」サイトで力を発揮する仕組みです。表示の速さや安全面の利点は、そこから自然についてきます。
ただし、公開後の更新・確認・修正の多くが開発者の手を通る形に変わります。社内の担当者だけで記事やページを直していきたいサイトでは、むしろ運用が重くなりがちです。
選ぶときは「技術として新しいか」より、公開後に誰がどこを直すのかを先に決めてください。そこが決まれば、ヘッドレスにするか、WordPressのままでよいかは自然に絞れます。
この記事の要点
- ヘッドレスCMSは管理画面（中身）と表示部分（見た目）を分けたCMS。中身はAPIで渡す
- 強みは見た目の自由度・複数媒体への配信・表示速度
- 弱みはプレビューや更新の反映に実装が要ること。公開後も開発者との付き合いが続く
- 向くのは開発体制があり、ページの型が決まっているサイト。社内だけで更新を回す小規模サイトは従来型が無難
ヘッドレスCMSとは｜「頭（見た目）」を持たないCMS
ヘッドレスCMSとは、コンテンツを管理する機能だけを持ち、Webページとして表示する機能を持たないCMSです。「ヘッド」は表示部分を指し、それが無いので「ヘッドレス」という名前です。
WordPressのような従来型CMSは、記事の入力画面とデザイン（テーマ）が1つのシステムにまとまっています。記事を保存すれば、そのままテーマの見た目でページが表示されます。
ヘッドレスCMSは、入力された記事やお知らせをAPI（システム同士がデータを受け渡す窓口）で外に渡すだけです。受け取ったデータをどう表示するかは、別に作るフロントエンド（表示側のプログラム）が決めます。
従来型CMSとヘッドレスCMSの違い
| 項目 | 従来型CMS（WordPressなど） | ヘッドレスCMS |
|---|---|---|
| 見た目 | テーマで決まる | 表示側を自由に作る |
| 中身の渡し方 | CMSがページを出力 | APIでデータだけ渡す |
| 公開先 | そのWebサイト | サイト・アプリ・店頭画面など |
| 更新の反映 | 保存すれば反映 | 表示側の仕組みしだい |
| 必要な人 | 担当者＋必要に応じて制作者 | 担当者＋開発者 |
従来型CMSとヘッドレスCMSの作り
- 入力画面
- CMSの管理画面
- 見た目
- テーマが決める
- 反映
- 保存すればページに出る
- 公開先
- そのWebサイト
- 入力画面
- CMSの管理画面
- 見た目
- 別に作った表示側が決める
- 反映
- 表示側がAPIで取りに来て反映
- 公開先
- サイト・アプリ・店頭画面など
図：入力と表示が一体か、APIで分かれているか
WordPressとヘッドレスCMSは何が違うのか
一番の違いは、「保存したら終わり」かどうかです。WordPressは入力と表示が一体なので、担当者が保存すればページに出ます。ヘッドレスCMSでは、保存した内容を表示側が取りに来て、はじめてページに反映される仕組みです。
WordPressもヘッドレスとして使える
WordPressにも、外部にデータを渡すREST APIが標準で入っています。WordPress 4.7（2016年12月公開）で、投稿・固定ページ・タグなどを外から読み取れる窓口が本体に加わりました。
そのため「WordPressをやめてヘッドレスへ」だけが選択肢ではありません。入力画面は慣れたWordPressのまま、表示だけを別に作る構成もとれます。社内の担当者がWordPressに慣れている場合は、有力な折衷案です。
表示の作り方で速さと検索への見え方が変わる
ヘッドレスCMSの表示側は、JavaScriptで画面を組み立てることが多くなります。Googleは検索セントラルで、サーバー側で組み立てておくか事前にページを生成しておく方法を勧めています。理由は、利用者と検索エンジンの両方にとって速く、JavaScriptを実行できないボットもあるためです。
つまり「ヘッドレスだからSEOに弱い」わけでも「強い」わけでもありません。決め手は表示側をどう作るかです。事前生成（静的生成）やサーバー側での生成を選べば、検索への見え方はむしろ安定します。
ヘッドレスCMSのメリット
メリットは、見た目と配信先の自由度に集約されます。速さや安全面の利点も、仕組みを分けた結果です。
- 見た目の自由度が高い: テーマの制約がなく、デザイン通りに組める
- 複数の場所に同じ中身を出せる: Webサイト・アプリ・店頭のサイネージに1回の入力で配信
- 表示が速くなりやすい: 事前に生成したページを配信すれば、アクセスごとの処理が減る
- 攻撃の入口を減らせる: 公開サイトに管理画面やデータベースを置かない構成にできる
- 表示側を作り直しやすい: デザインを刷新しても、記事データはそのまま使える
最後の点が効くのは、リニューアルの多い企業サイトです。従来型では、テーマを替えると記事内の装飾が崩れ、移し替えに手間がかかることがあります。中身と見た目が分かれていれば、中身を触らずに表示側だけを入れ替えられます。
ヘッドレスCMSのデメリット｜公開後に作業が増える
デメリットの多くは、公開後の運用で表に出てきます。導入前の比較表では見えにくいので、具体的に並べます。
プレビューや下書き確認に実装が要る
従来型CMSなら、公開前のプレビューは最初から付いています。ヘッドレスCMSでは、表示側に下書きを受け取って表示するページを作らないとプレビューできません。
たとえばmicroCMSの画面プレビューは、表示側で下書き状態のコンテンツを取得して表示する仕組みを実装する前提です。担当者が「公開前に見た目を確認したい」なら、その分の開発を最初の見積もりに入れておいてください。
更新の反映に「ビルド」が挟まることがある
事前にページを生成する構成では、記事を保存したあと、ページを作り直す処理（ビルド）が走ってから反映されます。microCMSのWebhook（変更を外部に知らせる仕組み）は、Vercel・Netlify・Cloudflare Pages・AWS Amplify・GitHub Actionsでのビルド開始に使える仕様です。
Next.jsのISR（Incremental Static Regeneration）のように、サイト全体を作り直さずに一部のページだけ更新する方法もあります。どの方式にするかで、更新から反映までの時間が変わります。
作ったことのない機能は、1つずつ作る
お問い合わせフォーム・サイト内検索・会員ログインなどは、従来型ならプラグインで足せることが多い機能です。ヘッドレス構成では、外部サービスを組み合わせるか、表示側で作る必要があります。
公開後に「誰が」対応するかの違い
| 作業 | 従来型CMS | ヘッドレスCMS |
|---|---|---|
| 記事・お知らせの更新 | 担当者 | 担当者 |
| 公開前プレビュー | 標準機能 | 実装済みなら担当者 |
| 新しいページの型を追加 | 担当者＋制作者 | 開発者 |
| フォーム・検索の追加 | プラグインで対応可 | 開発者（外部サービス連携） |
| 見た目の部分修正 | 担当者でも可能 | 開発者 |
CaaS型とセルフホスト型｜サービスの選び方
ヘッドレスCMSは、運営会社のクラウドを使う「CaaS型」と、自分でサーバーを用意する「セルフホスト型」に分かれます。
CaaS型：サーバー管理がいらない
CaaS（Content as a Service）型は、CMS本体の管理を運営会社が受け持つ型です。サーバーの保守やセキュリティ更新は任せられ、月額料金を払って使います。国産のmicroCMS、海外製のContentfulなどが代表例です。
microCMSの料金（2026年9月29日に公式ページで確認・税抜）は次の通りです。
microCMSの主なプラン（公式・税抜）
| プラン | 月額 | API数 | メンバー | データ転送量 |
|---|---|---|---|---|
| Hobby | 0円 | 5個 | 最大3名 | 20GB/月 |
| Team | 4,900円〜 | 10個（追加可） | 3名（追加可） | 200GB/月 |
| Business | 75,000円〜 | 30個（追加可） | 20名（追加可） | 1TB/月 |
小さく試すなら無料プランで始められます。ただし、この金額はCMS部分だけです。表示側のホスティング代と開発費は別にかかります。
セルフホスト型：自由度は高いが保守も自分で
セルフホスト型は、オープンソースのCMSを自社のサーバーに入れて使います。Strapiの公式ドキュメントでの自己紹介は「オープンソースのヘッドレスCMS」です。ライセンス費を抑えられる一方、サーバーの保守・更新・障害対応は自社か委託先の仕事になります。
ヘッドレスCMSの2つの型
- CMS本体をどこで動かすか
- CaaS型（運営会社のクラウド）microCMS・Contentfulなど。サーバー保守は任せ、月額で使う
- セルフホスト型（自社のサーバー）Strapiなどのオープンソース。ライセンス費は抑えられるが保守は自社
- WordPressをヘッドレスで使うREST APIで中身を渡し、表示だけ別に作る折衷案
図：CaaS型とセルフホスト型の位置づけ
見積もりに出てこない費用を先に数える
ヘッドレスCMSの費用は、CMSの月額・表示側の開発・表示側のホスティングの3つに分かれます。比較記事ではCMSの月額だけが並びがちですが、実際の差は残りの2つで出ます。
- CMSの月額: CaaS型の利用料。セルフホスト型ならサーバー代と保守の手間
- 表示側の開発: ページの型ごとの実装、プレビュー、フォームや検索の組み込み
- 表示側のホスティングと運用: 配信サービスの料金、ビルドの設定、公開後の改修
特に見落としやすいのが、公開後の改修です。「新しい種類のページを1つ足したい」という依頼も、ヘッドレス構成では開発案件になります。年に何回くらい新しいページの型を足しそうかを、発注前に一度数えておくと見積もりのズレが減ります。
保守費の内訳は、ホームページ保守費用の相場が詳しいです。
導入してよいサイト・避けるべきサイト
判断の軸は、開発体制が公開後も続くかと、ページの型が決まっているかの2つです。
ヘッドレスCMSが向くサイト
- 社内か委託先に、公開後も表示側を触れる開発者がいる
- Webサイトとアプリなど、同じ中身を複数の場所に出したい
- デザインの再現度や表示速度を最優先したい
- お知らせ・事例・製品情報など、ページの型がはっきり決まっている
従来型CMSのほうが無難なサイト
- 社内の担当者だけで、ページの追加や見た目の調整まで回したい
- フォーム・予約・会員機能などを、プラグインで早く足したい
- 公開後に開発者へ継続して依頼する予算を取りにくい
- 10ページ前後の会社案内サイトで、更新はお知らせ程度
小規模な会社案内サイトなら、WordPressやノーコードツールで十分なケースが大半でしょう。比較はノーコードツール比較とWordPressの始め方が参考になります。
ヘッドレスCMSを選ぶかの判断
- 公開後に「誰が、どこを直すか」から決めます
- 1公開後も表示側を触れる開発者がいるかいない場合は従来型CMSやノーコードが無難
- 2同じ中身を複数の場所に出すかサイトとアプリなどに配信するならヘッドレスの利点が大きい
- 3ページの型が決まっているか型が決まっていればヘッドレス向き。担当者がページを自由に増やすなら従来型
- 4プレビューと反映時間の要件を決める見積もりに実装費を入れておく
迷ったら、入力はWordPressのまま表示だけ分ける構成も検討できます
図：開発体制とページの型から判断する流れ
発注前に決めておく6つの項目
ヘッドレスCMSで作ると決めたら、制作会社に渡す前に次の項目を決めておくと、見積もりの比較がしやすくなります。
- 更新する人と頻度（誰が・月に何回・どの種類のページを）
- 公開前プレビューの要否（担当者が見た目を確認するか）
- 更新から反映までの許容時間（即時か、数分待てるか）
- フォーム・検索・会員などの機能と、使う外部サービス
- 公開後の改修の窓口と、月額の保守範囲
- 将来の移行（CMSを替えるときのデータの持ち出し方）
1と5が決まっていない見積もりは、公開後に追加費用が出やすくなります。サイトは公開してからが長いので、運用の分担を先に紙に書くことが一番の予防です。
ヘッドレスCMSに関するよくある質問
Q1. ヘッドレスCMSとは、わかりやすく言うと何ですか？
記事や画像などの「中身」だけを管理して、見た目は持たないCMSです。中身はAPIで渡し、ページの見た目は別に作った表示側が決めます。お店にたとえると、倉庫（中身の管理）と売り場（見た目）を別々に作るイメージです。
Q2. WordPressとヘッドレスCMSはどちらがよいですか？
社内の担当者だけでページを増やしたり直したりしたいならWordPress、開発体制があり見た目や配信先の自由度を優先するならヘッドレスCMSが向きます。WordPressにもREST APIがあるため、入力はWordPressのまま表示だけを別に作る方法もあります。
Q3. ヘッドレスCMSはSEOに不利ですか？
仕組みとして不利なわけではありません。Googleは、サーバー側で組み立てるか事前に生成したページを勧めています。表示側をその形で作れば、検索エンジンにも内容は伝わります。JavaScriptだけで画面を組み立てる作りにすると、確認の手間は増えるでしょう。
Q4. 無料で使えるヘッドレスCMSはありますか？
あります。microCMSには月額0円のHobbyプランがあり（2026年9月29日確認）、StrapiのようなオープンソースのCMSは自分のサーバーに入れて使えます。ただしCMSが無料でも、表示側の開発やホスティングに費用と手間がかかる点は変わりません。
Q5. 既存のWordPressサイトからヘッドレスに移るのは大変ですか？
記事データの移行そのものより、表示側の作り直しとプレビュー・フォームなどの再実装に手間がかかります。まずはWordPressを残したまま表示側だけを分ける方法を検討し、社内の更新のしかたが大きく変わらない形を探すのが、負担を抑える近道です。
まとめ｜ヘッドレスCMSは「公開後に誰が直すか」で選ぶ
ヘッドレスCMSは、中身と見た目を分けることで自由度と速さを得る仕組みです。その代わり、公開後の作業の一部が開発者に移ります。
この記事のまとめ
- ヘッドレスCMSは管理画面と表示部分を分け、APIで中身を渡すCMS
- メリットは見た目の自由度・複数媒体への配信・表示速度
- デメリットはプレビュー・反映・機能追加に実装が要ること
- 費用はCMSの月額・表示側の開発・ホスティングの3つで数える
- 判断は開発体制が続くか・ページの型が決まっているかで行う
迷ったら、公開後1年間に「どんな更新を、誰が、何回するか」を書き出してみてください。担当者だけで回す更新が多ければ従来型、開発者と組んで作り込む更新が多ければヘッドレスが合っています。
※本記事は各サービスの公式情報（2026年9月29日確認）をもとにした整理です。料金・機能・仕様は変更される場合があります。導入前にmicroCMS公式など各サービスの最新情報をご確認ください。
