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 機能・保守・パフォーマンス比較表

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サイトのモダン化は切り離せません。例えば、経理業務の効率化については、以下の記事が参考になります。

freee会計導入マニュアル｜旧ソフト移行ガイド

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側のビルドを動かすための設定です。

1. Vercelで「Deploy Hook URL」を発行する。
2. microCMSの管理画面にある「Webhook設定」にそのURLを貼り付ける。
3. 記事の更新をトリガーに、自動的にサイトが最新状態に書き換わることを確認する。

このように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戦略を「モダンなデータ活用」へとシフトさせる一歩となります。自社の開発リソースと運用体制を見極め、最適なアーキテクチャを選択してください。