従来型CMSとヘッドレスCMS
このページで学ぶこと
Section titled “このページで学ぶこと”- 従来型CMSとヘッドレスCMSの構造上の違い
- WordPress型の一体構成と、APIで分離する構成
- ヘッドレスCMSで自由になる部分と、自前で用意する部分
- プレビュー、フォーム、検索、公開、保守の違い
- 案件条件に応じて両方式を比較する方法
従来型CMSは、コンテンツ管理とWebページ表示を一つの製品・環境で扱う構成が中心です。
ヘッドレスCMSは、コンテンツ管理を行うCMSと、Webページを表示するフロントエンドを分離し、APIでデータを渡します。
flowchart LR
subgraph 従来型CMS
E1[編集者] --> C1[CMS]
C1 --> D1[コンテンツ・DB]
C1 --> T1[テーマ・テンプレート]
T1 --> W1[Webサイト]
end
subgraph ヘッドレスCMS
E2[編集者] --> C2[CMS]
C2 --> D2[コンテンツ]
D2 -->|API| F2[別のフロントエンド]
F2 --> W2[Webサイト]
end
ヘッドレスの「ヘッド」は、利用者に見せる画面・表示層を指します。
CMSに表示層がまったくないというより、公開サイトの表示をCMS本体から切り離していると考えると分かりやすくなります。
従来型CMSの構成
Section titled “従来型CMSの構成”WordPressを典型例として考えると、同じシステム内に次が含まれます。
- 管理画面
- コンテンツ
- データベース
- テーマ・テンプレート
- プラグイン
- 公開ページ
- メディア管理
- 利用者・権限
flowchart TD
CMS[WordPress等]
CMS --> ADMIN[管理画面]
CMS --> CONTENT[記事・固定ページ]
CMS --> THEME[テーマ]
CMS --> PLUGIN[プラグイン]
CMS --> PAGE[公開ページ]
編集者が管理画面で更新すると、同じCMSがテンプレートを使ってWebページを生成します。
- 管理と表示が一体で理解しやすい
- テーマ・プラグイン等の既存機能が多い
- プレビューを作りやすい
- 小規模サイトを比較的短期間で構築できる
- フォーム、検索、会員等を追加できる場合がある
- 運用経験者や情報を見つけやすい
- CMS本体、テーマ、プラグイン、実行環境の更新が必要
- 表示と管理が同じ基盤に依存する
- プラグイン同士の競合・更新停止がある
- 高度なフロントエンド表現では制約が出る場合がある
- CMS障害が公開サイトへ影響する構成が多い
- 権限・セキュリティ・バックアップを継続管理する
WordPressが常に危険・古いということではありません。適切な更新・権限・構成・保守を行えば、現在も多くの案件で利用できます。
ヘッドレスCMSの構成
Section titled “ヘッドレスCMSの構成”ヘッドレスCMSは、管理画面とコンテンツAPIを提供し、公開サイトを別の技術で作ります。
flowchart LR
E[編集者] --> C[ヘッドレスCMS]
C -->|API| F[Astro・Next.js等]
F --> H[ホスティング・CDN]
H --> U[利用者]
- 表示技術を比較的自由に選べる
- CMSと公開サイトを別々に更新できる
- 同じコンテンツをWeb、アプリ等へ配信しやすい
- 静的生成・CDN配信と組み合わせやすい
- CMSサーバー管理をSaaS事業者へ任せやすい
- CMS管理画面を公開サイトの実行環境から分離できる
- 公開サイトのフロントエンドを別途開発する
- プレビューを連携実装する
- フォーム、検索、会員等を別に用意する
- CMS更新後のビルド・キャッシュを設計する
- API制限・障害・料金を管理する
- 管理画面だけでは完成ページを把握しにくい場合がある
- CMSとフロントの両方を保守する
ヘッドレスCMSを導入すると、開発が不要になるわけではありません。
CMSが担当しない表示・配信・動的機能を、フロントエンドと外部サービスで作ります。
「モノリシック」と「分離」
Section titled “「モノリシック」と「分離」”従来型CMSは、コンテンツ管理、表示、プラグイン等が一つのシステムにまとまるため、モノリシックな構成と呼ばれることがあります。
ヘッドレスCMSは、CMS、フロントエンド、検索、フォーム、認証等を分けて組み合わせる、コンポーザブルな構成を取りやすくなります。
flowchart TD
subgraph 一体型
A[CMS・表示・機能]
end
subgraph 分離型
C[CMS]
F[フロント]
S[検索]
M[フォーム]
A2[認証]
C --> F
S --> F
M --> F
A2 --> F
end
一体型は管理対象がまとまりやすい一方、一部分だけ交換しにくいことがあります。
分離型は機能ごとに選びやすい一方、サービス数、契約、API、障害点、責任分界が増えます。
表示の自由度
Section titled “表示の自由度”従来型CMS
Section titled “従来型CMS”テーマ・テンプレートの仕組みの中で表示を作ります。
既存テーマを使えば早く構築できますが、独自デザインやモダンなフロントエンド構成では、テーマ開発や追加実装が必要です。
ヘッドレスCMS
Section titled “ヘッドレスCMS”CMSは主にデータを提供し、表示はAstro、Next.js、Nuxt等で作れます。
- 静的生成
- SSR
- CSR
- CDN
- アプリ
- サイネージ
等へ展開できます。
ただし、自由度が高いことは、設計・実装・テスト対象が増えることでもあります。
コンテンツとレイアウト
Section titled “コンテンツとレイアウト”従来型CMSでは、ページ単位でレイアウトを編集できる機能が豊富な場合があります。
ヘッドレスCMSでは、タイトル、本文、画像等の構造化コンテンツ管理が中心です。
ページビルダーのように自由なページ制作を実現するには、次の方法があります。
- ブロック型フィールド
- セクションの繰り返し
- ページテンプレート選択
- 外部ビジュアルエディター
- 固定テンプレートと構造化項目
自由度を上げるほど、CMSのスキーマとフロントエンド部品の連携が複雑になります。
従来型CMS
Section titled “従来型CMS”sequenceDiagram
participant E as 編集者
participant C as CMS
participant U as 利用者
E->>C: コンテンツを公開
U->>C: ページへアクセス
C-->>U: テンプレートでページを返す
更新が比較的すぐ反映されます。
ただし、ページキャッシュやCDNを使うと、キャッシュ更新が必要です。
ヘッドレスCMS＋SSG
Section titled “ヘッドレスCMS＋SSG”sequenceDiagram
participant E as 編集者
participant C as CMS
participant B as ビルド
participant H as ホスティング
participant U as 利用者
E->>C: コンテンツを公開
C->>B: Webhook
B->>C: APIでコンテンツ取得
B->>H: HTMLを配置
U->>H: ページへアクセス
H-->>U: 生成済みHTML
CMS公開だけではWebサイトが変わらず、ビルド・デプロイ・キャッシュ更新を経る場合があります。
更新反映時間、ビルド失敗、緊急修正を運用要件へ含めます。
ヘッドレスCMS＋SSR・CSR
Section titled “ヘッドレスCMS＋SSR・CSR”アクセス時またはブラウザでAPIから取得するため、ビルドなしで反映できる場合があります。
一方、CMS APIの遅延・障害・利用制限が表示へ影響します。
従来型CMS
Section titled “従来型CMS”CMS自身がテンプレートを持つため、下書きを同じ環境で表示しやすい構成です。
ただし、CDN、外部API、別システムを含むと本番と完全に同じとは限りません。
ヘッドレスCMS
Section titled “ヘッドレスCMS”フロントエンドが別のため、次を連携します。
- 下書き取得用の識別子
- プレビューURL
- 認証
- キャッシュ回避
- プレビュー終了
- 関連コンテンツ
- 本番データとの混在防止
プレビュー実装を後回しにすると、編集者がCMSのJSONや入力欄だけで判断することになります。
CMS選定時から要件化します。
フォーム・検索・会員機能
Section titled “フォーム・検索・会員機能”従来型CMS
Section titled “従来型CMS”プラグインやCMS拡張で追加できる場合があります。
利点は一体管理しやすいことですが、プラグイン選定、更新、脆弱性、データ保存、メール送信、スパム対策を確認します。
ヘッドレスCMS
Section titled “ヘッドレスCMS”通常、フォーム・検索・会員は別のサービス・API・サーバー処理で用意します。
flowchart LR
W[Webサイト] --> C[ヘッドレスCMS]
W --> S[検索サービス]
W --> F[フォーム処理]
W --> A[認証・会員API]
各サービスを適切に選べますが、契約・監視・障害・個人情報の管理が分散します。
| 対象 | 従来型CMS | SaaS型ヘッドレスCMS |
|---|---|---|
| CMS本体更新 | 利用側対応が多い | 事業者が対応 |
| OS・実行環境 | 利用側対応が多い | CMS部分は事業者が対応 |
| テーマ・フロント | 利用側 | 利用側 |
| プラグイン | 利用側 | 別サービス・連携として利用側 |
| API連携 | 必要に応じる | 基本的に必要 |
| ビルド | 構成による | SSG等では必要 |
| アカウント・権限 | 利用側 | 利用側 |
| コンテンツ | 利用側 | 利用側 |
| サービス料金 | サーバー等 | CMS、ホスティング、外部機能 |
| 移行 | DB・テーマ・プラグイン | APIデータ・フロント・サービス設定 |
ヘッドレスCMSは保守をなくすのではなく、CMS基盤保守をサービス事業者へ移し、フロント・API・外部サービスの保守へ置き換えます。
セキュリティ
Section titled “セキュリティ”従来型CMS
Section titled “従来型CMS”公開サイトとCMSが同じ環境で動く場合、CMSの脆弱性・管理画面・プラグインが公開サイトへ影響します。
- 更新
- WAF
- 管理画面制限
- 多要素認証
- バックアップ
- 不正ログイン監視
- プラグイン精査
が必要です。
ヘッドレスCMS
Section titled “ヘッドレスCMS”CMS管理画面と公開サイトを分離でき、静的配信なら公開側の攻撃対象を減らせます。
一方、次は必要です。
- APIキーの権限
- ブラウザ公開可否
- 管理者権限
- Webhook認証
- フロントエンドライブラリ更新
- 外部サービス
- 個人情報
- APIの利用制限
「ヘッドレスだから安全」と一律に判断しません。
従来型CMS
Section titled “従来型CMS”- サーバー
- 構築
- テーマ・プラグイン
- 更新・保守
- バックアップ
- セキュリティ
- 障害対応
ヘッドレスCMS
Section titled “ヘッドレスCMS”- CMS利用料
- フロントエンド開発
- ホスティング・ビルド
- 検索・フォーム等の外部サービス
- API・連携保守
- プレビュー
- バージョン更新
- データ移行
初期費用だけではなく、5年程度の運用費と体制で比較します。
小規模・低頻度更新のサイトでは、分離型が過剰になる場合があります。
一方、多サイト・多チャネル・高度なフロントエンドでは、コンテンツと表示を分ける価値が高まります。
向きやすい案件
Section titled “向きやすい案件”従来型CMSが向きやすい例
Section titled “従来型CMSが向きやすい例”- 比較的小規模
- Webサイトだけで利用
- 既存テーマ・機能を活用したい
- 一つの管理画面で完結したい
- 制作・運用チームがCMS保守に慣れている
- ページ編集の自由度を重視
- 短期間・限られた予算
ヘッドレスCMSが向きやすい例
Section titled “ヘッドレスCMSが向きやすい例”- 独自フロントエンド
- 高速な静的配信
- Web・アプリ等の複数チャネル
- 多サイトでコンテンツ共有
- CMS基盤保守を減らしたい
- API中心のシステム連携
- 表示技術を独立して更新したい
- 構造化コンテンツを重視
これは絶対条件ではありません。
ハイブリッドな構成
Section titled “ハイブリッドな構成”WordPressもREST APIを持ち、ヘッドレスCMSのように利用できます。
一方、ヘッドレスCMS側にページ編集・ビジュアルプレビュー等が追加されることもあります。
「WordPressかヘッドレスCMSか」という製品名だけではなく、実際に次を確認します。
- コンテンツ管理
- 公開ページ生成
- API
- プレビュー
- フォーム
- 検索
- サーバー
- 保守責任
製品の境界は固定ではありません。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”WordPressをヘッドレスCMSへ移行する
Section titled “WordPressをヘッドレスCMSへ移行する”現在WordPressが担当している機能を一覧化します。
- 記事・固定ページ
- フォーム
- 検索
- リダイレクト
- SEO設定
- 多言語
- 会員
- プレビュー
- 予約公開
- サイトマップ
- 画像加工
ヘッドレスCMSへ移すのはコンテンツ管理部分であり、他機能はフロントや外部サービスで再構築する場合があります。
会社の保守体制上、WordPressを持てない
Section titled “会社の保守体制上、WordPressを持てない”CMS本体・プラグイン・PHP等の継続更新を引き受けられない場合、SaaS型ヘッドレスCMSは有力です。
ただし、フロントエンドと外部サービスの保守は残ります。
「保守不要」ではなく「自社で保守できない領域を事業者へ移す」と説明します。
複数ブランドでコンテンツを共有する
Section titled “複数ブランドでコンテンツを共有する”商品・店舗・FAQ等を構造化してAPI配信すると、複数サイト・アプリで共通利用しやすくなります。
ブランドごとの文言・画像・公開範囲、変更時の影響をコンテンツモデルで設計します。
PMチェックリスト
Section titled “PMチェックリスト”- CMS管理と公開表示の担当範囲を図示している
- 現在のCMSが担当する機能を分解している
- 従来型・ヘッドレス型を初期費用だけで比較していない
- CMS更新から公開反映までの手順を確認している
- プレビューの利用者・対象画面・認証を設計している
- フォーム・検索・会員・SEO機能の実現方法を決めている
- CMS本体、フロント、ホスティング、外部サービスの保守を分けている
- APIキーとWebhookの権限・秘密管理を確認している
- 多サイト・アプリへのコンテンツ再利用要件を整理している
- 5年程度の費用・アップデート・人材を比較している
- 契約終了時のデータ・メディア・設定移行を確認している
- 採用しない方式の理由も文書化している
よくある誤解・失敗
Section titled “よくある誤解・失敗”「ヘッドレスCMSならフロントエンド開発が不要」
Section titled “「ヘッドレスCMSならフロントエンド開発が不要」”CMSは主にコンテンツとAPIを提供します。公開サイトの表示、検索、フォーム、プレビュー等は別途必要です。
「WordPressは古く、ヘッドレスCMSは新しいので優れている」
Section titled “「WordPressは古く、ヘッドレスCMSは新しいので優れている」”案件の規模、機能、運用、体制、予算により適性が異なります。新旧ではなく責任分界で比較します。
「ヘッドレスCMSなら更新が即時反映される」
Section titled “「ヘッドレスCMSなら更新が即時反映される」”SSGではビルド・デプロイ・キャッシュ更新が必要です。SSR・CSRでもAPIキャッシュ等があります。
「SaaSなので障害対応は事業者だけが行う」
Section titled “「SaaSなので障害対応は事業者だけが行う」”CMS事業者の復旧を待つ間の表示、告知、ビルド再実行、影響確認は利用側で必要です。
「WordPressからコンテンツを移せば移行完了」
Section titled “「WordPressからコンテンツを移せば移行完了」”テーマ・プラグイン・フォーム・SEO・リダイレクト・プレビュー等の機能を別途再構築する場合があります。
理解度チェック
Section titled “理解度チェック”Q1. 従来型CMSとヘッドレスCMSの構造上の違いを説明してください。
Section titled “Q1. 従来型CMSとヘッドレスCMSの構造上の違いを説明してください。”回答と解説
従来型CMSはコンテンツ管理と公開表示が一体になりやすく、ヘッドレスCMSは管理と表示を分離し、APIでコンテンツを渡します。Q2. ヘッドレスCMSを採用すると、新たに用意する可能性が高いものは何ですか。
Section titled “Q2. ヘッドレスCMSを採用すると、新たに用意する可能性が高いものは何ですか。”回答と解説
フロントエンド、ホスティング、ビルド、プレビュー、フォーム、検索、認証等です。案件要件に応じて組み合わせます。Q3. WordPressからヘッドレスCMSへ移行すると、保守はすべてなくなるでしょうか。
Section titled “Q3. WordPressからヘッドレスCMSへ移行すると、保守はすべてなくなるでしょうか。”回答と解説
なくなりません。CMS基盤・プラグイン保守は減らせても、フロント、API、外部サービス、アカウント、料金、障害対応は残ります。Q4. ヘッドレスCMS＋SSGで、記事公開後にサイトが更新されない場合、何を確認しますか。
Section titled “Q4. ヘッドレスCMS＋SSGで、記事公開後にサイトが更新されない場合、何を確認しますか。”回答と解説
CMSの公開状態、Webhook、ビルド、デプロイ、API、CDNキャッシュ、ブラウザキャッシュ等を確認します。Q5. 小規模サイトで従来型CMSが合理的な場合を挙げてください。
Section titled “Q5. 小規模サイトで従来型CMSが合理的な場合を挙げてください。”回答と解説
Webだけで利用し、一体管理と既存機能を重視し、CMS更新を継続できる体制があり、分離開発の価値が小さい場合です。- microCMS「ヘッドレスCMSとは？」
https://blog.microcms.io/what-is-headlesscms/
表示層を持たずAPIでコンテンツを配信する構造と、従来型CMSとの違いを確認する公式解説。 - microCMS「ヘッドレスCMSとWordPressの違い」
https://blog.microcms.io/vs-wordpress/
両方式の構成とメリット・注意点を比較する参考資料。 - Contentful「Headless CMS explained」
https://www.contentful.com/headless-cms/
コンテンツ管理と表示層を分離する一般的な定義。 - WordPress Developer Resources「REST API Handbook」
https://developer.wordpress.org/rest-api/
WordPressもAPI経由でコンテンツを利用できることを確認する公式資料。