WordPress と headless CMS（Contentful / microCMS）｜コーポレートサイトの比較
目次 クリックで開く
企業の顔であるコーポレートサイトを構築・リニューアルする際、長らく標準だったWordPressに代わり、「Headless CMS（ヘッドレスCMS）」という選択肢が急速に普及しています。特に、表示速度の改善やセキュリティリスクの低減、そしてマルチデバイスへの対応を重視するプロジェクトにおいて、ContentfulやmicroCMSといったサービスの名前が挙がることは珍しくありません。
しかし、安易なモダン化は運用現場の混乱を招くリスクもあります。本記事では、実務担当者の視点から、WordPressと主要なHeadless CMSを徹底的に比較し、どのようなプロジェクトでどちらを採用すべきか、具体的な仕様や構築手順を交えて解説します。
1. WordPressとHeadless CMSの根本的な違い
比較を始める前に、それぞれのアーキテクチャの違いを正しく理解する必要があります。
1.1 WordPress（オールインワン型）の構造
WordPressは「モノリス（一枚岩）」型と呼ばれます。コンテンツを管理するバックエンド、それを表示するテンプレート（フロントエンド）、そしてデータを保存するデータベースがすべて一つのソフトウェアに統合されています。
- メリット: 管理画面からテーマを編集でき、プラグインで容易に機能追加が可能。非エンジニアでも運用が完結しやすい。
- デメリット: システムが肥大化しやすく、セキュリティの脆弱性を突きやすい。また、ページを表示するたびにサーバーサイドでHTMLを生成するため、アクセス集中時に重くなる傾向がある。
1.2 Headless CMS（コンテンツ管理特化型）の構造
Headless CMSは、その名の通り「頭（表示画面）」がないCMSです。CMS側はコンテンツの入稿とAPI（JSON形式など）による提供に特化し、表示部分は別途Next.jsやNuxt.jsなどのフロントエンド技術を用いて構築します。
- メリット: 表示速度が極めて速く、セキュリティリスクが低い。また、一つのコンテンツをWebサイト、アプリ、デジタルサイネージなど複数の媒体へ配信しやすい。
- デメリット: フロントエンドの開発に専門的な知識が必要。WordPressのような「プレビューボタン」や「フォーム機能」を実装するために追加の作り込みが必要。
2. 徹底比較：WordPress vs Contentful vs microCMS
ここでは、世界的にシェアの高い「Contentful」と、日本国内で圧倒的な支持を得ている「microCMS」を、WordPressと比較します。
2.1 機能・保守・パフォーマンス比較表
| 比較項目 | WordPress | Contentful | microCMS |
|---|---|---|---|
| タイプ | インストール型（PHP） | SaaS型（Headless） | SaaS型（Headless） |
| サーバー管理 | 自社（またはレンタル） | 不要（SaaS） | 不要（SaaS） |
| 表示速度 | △（プラグインに依存） | ◎（SSG/ISR活用） | ◎（SSG/ISR活用） |
| セキュリティ | △（脆弱性対策が必須） | ◎（APIのみ公開） | ◎（APIのみ公開） |
| 日本語対応 | 完全対応 | 管理画面は一部英語 | 完全対応（国産） |
| 料金体系 | ソフトウェアは無料 | 無料枠あり / 従量課金 | 無料枠あり / 従量課金 |
2.2 Contentfulの特徴と強み
Contentfulは、グローバルで最も成功しているHeadless CMSの一つです。
- 高い自由度: コンテンツの構造（スキーマ）を非常に細かく定義でき、大規模なプロジェクトに適しています。
- マーケットプレイス: 外部サービスとの連携プラグインが豊富で、Shopifyや画像最適化ツールなどと管理画面上でシームレスに繋がります。
- 参考URL: https://www.contentful.com/
2.3 microCMSの特徴と強み
microCMSは、日本製のHeadless CMSであり、日本の商習慣に合わせた機能が充実しています。
- 使いやすいUI: 日本語の管理画面が非常に直感的で、ITに詳しくない広報担当者などでも迷わず入稿できます。
- 日本向けの機能: 「公開予約」や「下書きプレビュー」の設定が、日本のWeb制作現場で求められる挙動に最適化されています。
- 参考URL: https://microcms.io/
企業のDX推進において、バックオフィス業務の自動化とWebサイトのモダン化は切り離せません。例えば、経理業務の効率化については、以下の記事が参考になります。
3. 実務から見たメリット・デメリット
3.1 運用の落とし穴：プレビューと公開予約
WordPressから移行した際、最も現場が戸惑うのが「反映までのタイムラグ」です。多くのHeadless CMS構成では、静的サイトジェネレーター（SSG）を使用します。
記事を公開してから実際にサイトに反映されるまで、数十秒〜数分の「ビルド時間」が発生します。これを解消するには、Vercelの「On-demand ISR」などを活用し、APIの更新をトリガーに特定のページだけを即時再生成する仕組みを構築する必要があります。
3.2 開発コストとランニングコストの逆転現象
WordPressは初期構築を安く抑えられますが、継続的なサーバー保守、プラグインのアップデート、そして何よりセキュリティ事故の対応コストが潜在的なリスクとして存在します。
対してHeadless CMSは、初期のフロントエンド開発コストは高くなりますが、インフラ管理から解放されるため、中長期的な運用工数は劇的に削減されます。これは、SaaSを組み合わせて業務の「負債」を剥がしていく考え方に似ています。
SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）
4. Headless CMS移行・構築のステップバイステップ
実際にmicroCMSを用いたコーポレートサイト構築の基本フローを解説します。
4.1 コンテンツモデルの設計（スキーマ定義）
まず、CMS側でどのようなデータを扱うか定義します。
- お知らせ（タイトル、日付、カテゴリ、本文）
- 会社概要（社名、所在地、代表者名）
- 事例紹介（案件名、クライアント名、メイン画像、詳細テキスト）
ここで重要なのは、テキストだけでなく「画像」や「カスタムフィールド」を適切に型定義することです。
4.2 フロントエンド（Next.js / Nuxt.js）の選定
ReactベースならNext.js、VueベースならNuxt.js（現在はNuxt 3が主流）を選定します。これにより、高速なページ遷移とSEOに強いHTML生成が可能になります。
4.3 ホスティング環境（Vercel / Netlify / AWS）の構築
構築したフロントエンドのソースコードをGitHubにプッシュし、VercelやNetlifyといったホスティングサービスと連携させます。これにより、コードを修正するだけで自動的にサイトが更新される「CI/CD」環境が整います。
4.4 Webhookによるビルド・デプロイ設定
CMS側で記事を「公開」した際に、Vercel側のビルドを動かすための設定です。
- Vercelで「Deploy Hook URL」を発行する。
- microCMSの管理画面にある「Webhook設定」にそのURLを貼り付ける。
- 記事の更新をトリガーに、自動的にサイトが最新状態に書き換わることを確認する。
このようにWebとデータの連携を最適化する考え方は、SFAやCRMのデータ統合においても非常に重要です。
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
5. よくあるトラブルと対処法
5.1 プレビュー画面が表示されない
原因: プレビュー用のシークレットトークンが環境変数に設定されていない、またはWebhookのURLが間違っている。
対処: 開発環境（.env.local）と本番環境（VercelのEnvironment Variables）の両方に正しくAPIキーが設定されているか確認してください。
5.2 APIのレートリミット（制限）に達してしまう
原因: ページ数が多いサイトで、ビルド時に一度に大量のAPIリクエストを送っている。
対処: リクエストの間にスリープを入れる、あるいはContentfulなどの上位プランへ移行する。静的なアセットはCDNを介して配信するよう構成を見直してください。
5.3 フォーム実装（お問い合わせ）をどうするか
課題: Headless CMSにはWordPressの「Contact Form 7」のような標準プラグインがありません。
対処: Google Formの埋め込み、もしくは「SSG Form」や「Newt」といったフォーム専用のSaaSを組み合わせて実装します。
6. まとめ：自社に最適な構成の選び方
最終的にどちらを選ぶべきかは、プロジェクトの性質によります。
- WordPressを選ぶべきケース:
- エンジニアが不在で、Web担当者がデザインの微調整や機能追加をすべて行いたい。
- 数千ページ規模のブログサイトで、プラグインによる管理が不可欠。
- 初期費用を極限まで抑えたい。
- Headless CMSを選ぶべきケース:
- 表示速度を改善し、Core Web Vitalsのスコアを最大化したい。
- 情報漏洩や改ざんのリスクを最小限に抑えたい（特に金融、医療、公的機関）。
- Webサイト以外のアプリなどにもコンテンツを配信する予定がある。
Headless CMSの導入は、単なるツールの変更ではなく、自社のWeb戦略を「モダンなデータ活用」へとシフトさせる一歩となります。自社の開発リソースと運用体制を見極め、最適なアーキテクチャを選択してください。
7. Headless CMS導入で見落としがちな「コストと拡張性」の盲点
WordPressからの移行を検討する際、単純な「月額費用」の比較だけでは不十分です。実務レベルで発生する以下のコストと拡張性の違いを、意思決定の材料に含めてください。
7.1 料金プランの「APIリクエスト数」と「資産性」
多くのHeadless CMSはSaaS形式のため、データ転送量やAPIリクエスト数に応じた従量課金が発生します。特に「画像配信」や「プレビューのリクエスト」が頻発する大規模サイトでは、無料枠を超えた際のコスト急増に注意が必要です。
| 検討項目 | WordPress | Contentful / microCMS |
|---|---|---|
| ストレージ費用 | サーバー容量に依存（定額） | プランごとの資産（画像等）数制限あり |
| データ利活用 | DBからの抽出にSQL知識が必要 | API経由で他システム（MA等）へ連携が容易 |
| バージョン管理 | プラグイン等で対応が必要 | 標準で履歴管理・ロールバックが可能な場合が多い |
※各サービスの料金は改定される頻度が高いため、必ず公式サイトの最新価格表をご確認ください。
7.2 周辺SaaSとの連携による「業務DX」の加速
Headless CMSを採用する最大のメリットは、Webサイトを単なる「表示板」ではなく、社内データ基盤の一部として組み込める点にあります。例えば、入稿データをGoogleスプレッドシートやAppSheetと連携させ、社内在庫管理とWeb上の在庫表示を同期させるといった柔軟な設計が可能です。
このような「データ連携による業務効率化」の視点については、以下の記事で詳しく解説しています。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド
8. 運用フェーズで役立つ公式リファレンス集
設計やトラブルシューティングの際に参照すべき、実務直結の公式リソースです。技術選定の最終確認にご活用ください。
- microCMS：料金プラン別機能一覧
（メンバー数やAPIプレビュー権限の制限を確認する際に必須です）
- Contentful：App Framework活用ガイド
https://www.contentful.com/developers/docs/extensibility/app-framework/
（外部SaaSとのUI連携を検討する場合の技術ドキュメントです）
- Next.js：ISR（Incremental Static Regeneration）の仕様
（「公開ボタンを押した直後の反映」をどう制御するか、エンジニアとの共通言語になります）
Headless CMSへの移行は、Webサイトを「情報資産」へと昇華させるプロセスです。まずはスモールステップとして、社内向けのマニュアルサイトや、一部の特設LPからモダンなアーキテクチャを試してみることをお勧めします。
ご相談・お問い合わせ
本記事の内容を自社の状況に当てはめたい場合や、導入・運用の設計を一緒に整理したい場合は、当社までお気軽にご相談ください。担当より折り返しご連絡いたします。