ヘッドレスCMSとWordPressを比較：企業サイトに合うのはどちらか
ヘッドレスCMSと従来型WordPressの違い、それぞれが向いているケース、ヘッドレスWordPressでセキュリティや運用がどう変わるかを、判断用チェックリスト付きで解説します。
この記事のポイント
- W3Techsによると、2026年10月時点でWordPressは全Webサイトの39.5%、CMS市場の58.2%を占めます。CMSが判明している.jpドメインのサイトでは78.8%です。
- Patchstackの集計では、2025年にWordPressエコシステムで11,334件の脆弱性が新たに見つかり、その91%がプラグインで、46%は公表時点でパッチがありませんでした。
- ヘッドレスWordPressはWordPressの管理画面を残し、REST APIやWPGraphQLで別のフロントエンドにコンテンツを渡します。公開側のテーマやプラグインが攻撃対象から外れます。
- ヘッドレス化すると作業は開発者側に移ります。プレビュー、キャッシュの更新、フォーム、SEOのメタデータはすべてフロントエンドで作り直す必要があります。
ヘッドレスCMSとWordPressの違いとは
従来型のWordPressは一体型（モノリス）です。1つのアプリケーションがコンテンツを保存し、編集者が使う管理画面を動かし、テーマを通じて公開ページを表示します。プラグインはこの3つの層すべてに手を加えられるため、お問い合わせフォームやSEOツール、ページビルダーを開発者なしで数分で追加できます。
ヘッドレスCMSが持つのは最初の2つの層だけです。編集者は管理画面でコンテンツを書いて整理しますが、CMSには公開用のテーマがありません。コンテンツはAPIを通じてデータとして配信され、Next.jsなどのフレームワークで作った別のフロントエンドがそのデータを取得してページを表示します。取り除かれた「ヘッド」とは、この表示層のことです。
この分離こそがトレードオフのすべてです。フロントエンドを自由に作れ、同じコンテンツを複数の場所で再利用できるようになります。その代わり、訪問者に見える部分をプラグインで変えることはできなくなり、これまでプラグインが担っていた機能は開発作業になります。
WordPressはどれくらい使われているか（日本の状況も含めて）
多くのチームにとって、比較の基準になるのはWordPressです。W3Techsの2026年10月の調査では、全Webサイトの39.5%がWordPressを使っており、CMSを特定できるサイトに占める割合は58.2%です。次に続くShopify（全サイトの5.3%）やWix（同4.2%）を大きく引き離しています。
日本ではその傾向がさらに強く、W3TechsがCMSを把握している.jpドメインのサイトのうち、WordPressの割合は78.8%です。これは実務に直結します。日本のマーケティング担当者や制作会社、フリーランスの多くはすでにWordPressの管理画面に慣れているため、別のCMSを選ぶなら、操作を覚え直すコストに見合う理由が必要です。
従来型のWordPressが向いているケース
ヘッドレス構成は、それだけで上位の選択肢というわけではありません。多くの企業サイトでは、価値を生まずにコストだけが増えます。次のような状況では、従来型のWordPressが適していることがほとんどです。
- サイトは1つのコーポレートサイトで、コンテンツをアプリやEC、他のチャネルで再利用しない。
- マーケティング担当者がブロックエディターやページビルダーで自らランディングページを作り、公開される見た目をそのまま確認したい。
- フォーム、多言語化、イベント、会員機能など主要な機能をプラグインに頼っており、それらを作り直す予算がない。
- 公開後に対応できる開発者がいない。ヘッドレスのフロントエンドはアプリケーションなので、依存パッケージの更新やCMS側の変更への対応を誰かが担う必要があります。
ヘッドレスCMSが効果を発揮するケース
ヘッドレスがコストに見合うのは、フロントエンド自体がプロダクトの一部である場合や、コンテンツを複数の場所で使う必要がある場合です。WordPress自身のREST APIハンドブックもこの使い方を説明しており、WordPressのコンテンツを完全に別のアプリケーションに取り込み、アプリ側はJSONでデータを送受信できるとしています。専用のヘッドレスCMSは、最初からこの考え方で作られています。
- 同じコンテンツをWebサイト、モバイルアプリ、EC、プロダクト内ヘルプなどに配信し、編集は1か所で済ませたい。
- 料金シミュレーター、会員エリア、製品コンフィギュレーターなど、テーマの中では作りにくいインタラクティブな機能がある。
- 表示速度の目標が厳しく、ブラウザに送るJavaScriptやHTMLを完全に管理したい。
- サイトの運用期間を通じてフロントエンドを担当する開発チームがいる、または採用予定である。
ヘッドレスWordPressという中間の選択肢
WordPressかヘッドレスかの二択である必要はありません。ヘッドレスWordPressでは、編集者は引き続きWordPressの管理画面を使い、別のフロントエンドが標準のREST API、またはGraphQL APIを追加する無料プラグインWPGraphQLを通じてコンテンツを読み込みます。WordPress.orgのWPGraphQLのページには、同プラグインがCanonical Plugin（公式に近い位置づけのプラグイン）になりつつあると記載されており、WordPressプロジェクトによる長期的なサポートが期待できます。
社内がすでにWordPressに慣れている企業にとって、これは最も現実的な道であることが多く、前述の.jpの数字を考えると、日本の多くの組織が当てはまります。編集体験はほとんど変わらず、コンテンツ構造やURLは段階的に移行でき、投資は再教育ではなくフロントエンドに向けられます。代償として、SEOのメタタグ、構造化データ、フォーム、スライダーなど公開側に何かを出力するプラグインは自動では動かなくなり、フロントエンドがそのデータを読み取って表示する必要があります。
ヘッドレスはWordPressより安全か
企業がヘッドレスに関心を持つ理由として多いのがセキュリティで、その背景は数字に表れています。Patchstackの「State of WordPress Security in 2026」によると、2025年にWordPressエコシステムで新たに見つかった脆弱性は11,334件で、2024年比42%増でした。91%がプラグイン、9%がテーマで、WordPress本体はわずか6件。さらに46%の脆弱性は、公表時点でパッチが提供されていませんでした。
ヘッドレス化はこの問題の一部に効きます。訪問者が別のフロントエンドにしかアクセスしなければ、WordPressのテーマやフロント向けプラグインのコードは公開サイトに露出しなくなり、管理画面を別ドメインやIP制限、シングルサインオンの背後に置くこともできます。ただし、それだけでバックエンドが安全になるわけではありません。残したプラグインは管理画面側で動き続け、APIにはアクセス制御が必要で、WordPress本体とプラグインの更新も引き続き欠かせません。どちらの構成でも、プラグインを少なく保ち、きちんと保守することが重要です。
ヘッドレスサイトで見落とされがちな作業
期待外れに終わるヘッドレス案件の多くは、CMSのせいではなく、誰も見積もりに入れていなかった機能が原因です。ヘッドレス構成の見積もりを出す前に、私たちは次の項目を洗い出しています。
- プレビュー：編集者は「プレビュー」ボタンを期待します。Next.jsではDraft Modeを使い、編集者に対してだけキャッシュを回避し、他の訪問者には公開済みページを見せ続けます。CMSのプレビューURLから、共有シークレットで保護したルートを呼び出す必要があります。
- 公開の反映：ページは通常キャッシュされるため、コンテンツが変わったときにCMSからフロントエンドへ通知する仕組みが必要です。一般的にはWebhookでオンデマンド再検証を実行します。これがないと更新の反映が遅れ、編集者の信頼を失います。
- SEO関連の出力：タイトル、メタディスクリプション、canonical、hreflang、サイトマップ、リダイレクト、構造化データは、CMSのフィールドをもとにフロントエンドで生成する必要があります。
- フォームと外部連携：プラグインが担っていたお問い合わせフォーム、メルマガ登録、CRM連携には、それぞれ専用のエンドポイントが必要です。
- ホスティングと監視が2系統に：CMSとフロントエンドのそれぞれに稼働監視、バックアップまたはデプロイのロールバック、そして担当者が必要です。
ヘッドレスCMSかWordPressか：判断チェックリスト
自社サイトについて次の質問に答えてみてください。WordPress寄りの答えが多ければ、そのまま使い続け、プラグインを絞り込み、高速なテーマに投資します。ヘッドレス寄りの答えが多く、編集者がWordPressに慣れているなら、新しいCMSを検討する前にまずヘッドレスWordPressから始めます。
- コンテンツをWebサイト以外（アプリ、EC、プロダクト）でも使うか？ はいならヘッドレス寄り。
- マーケティング担当者が開発者なしで新しいページを視覚的に作る必要があるか？ はいならWordPress寄り。
- 今後少なくとも2年間、フロントエンドを担当する開発者がいるか？ はいならヘッドレス寄り、いいえならWordPress寄り。
- 現在のサイトは、表示に関わる機能をいくつのプラグインに頼っているか？ 多いほど作り直しの範囲は大きくなります。
- 公開サイトのセキュリティリスクが経営層や顧客にとっての懸念事項か？ はいなら、フロントエンドと管理画面の分離を検討します。
- 編集者や日本の制作会社が日常的にWordPressを使っているか？ はいなら、ヘッドレスにするかどうかにかかわらずWordPressの管理画面を残す方向です。
著者
Jayson Hao
Innovation Trigger Lab創業者。トロント大学コンピュータサイエンス（AI/ML）出身。RAG、AIチャットボット、Web・モバイルプロダクトの設計と本番導入に携わっています。
プロフィールを見るよくある質問
WordPressはヘッドレスCMSですか？
標準ではテーマでページを表示するため、ヘッドレスCMSではありません。ただし標準のREST APIやWPGraphQLプラグインを使い、別のフロントエンドでコンテンツを表示すればヘッドレスとして利用できます。
ヘッドレスCMSはSEOに有利ですか？
自動的に有利になるわけではありません。適切に作ったヘッドレスのフロントエンドは非常に高速にできますが、WordPressのSEOプラグインが担っていたタイトル、メタデータ、サイトマップ、リダイレクトを作り直す必要があり、そこに漏れがあると速度向上以上に順位を落とします。
ヘッドレス構成でも編集者はページをプレビューできますか？
実装すれば可能です。Next.jsでは、CMSのプレビューボタンから保護されたルートを開いてDraft Modeを有効にし、編集者には未公開のコンテンツを、他の訪問者にはキャッシュされたページを表示します。
ヘッドレスにすればWordPressのセキュリティリスクはなくなりますか？
公開サイトで露出する範囲は減りますが、管理画面側のプラグインは引き続き更新が必要です。Patchstackによると2025年に見つかったWordPressエコシステムの新しい脆弱性の91%はプラグインによるもので、どちらの構成でもプラグインの管理が重要です。
出典・参考資料
- 1.CMSの利用状況統計W3Techs, 2026年10月30日
- 2..jpドメインのWebサイトにおけるCMSの分布W3Techs, 2026年10月30日
- 3.State of WordPress Security in 2026（2026年版WordPressセキュリティ実態レポート）Patchstack, 2026年2月25日
- 4.REST APIハンドブックWordPress Developer Resources, 2026年10月14日
- 5.WPGraphQLWordPress.org Plugin Directory, 2026年10月29日
- 6.Next.jsのDraft Modeでコンテンツをプレビューする方法Next.js Docs, 2026年6月2日