WEB制作

KNOWLEDGE

ヘッドレスCMSは導入すべきか|WordPressで足りる条件と、分けたときに失うもの

  • #WEB制作

SHARE

ヘッドレスCMSの相談は、ほとんどが同じ形で来ます。「WordPressは重いと聞いた」「セキュリティが心配だ」「最近はヘッドレスらしい」。いずれも導入の理由としては弱く、そのまま進めると運用が止まります。

検索して出てくる記事は、仕組みの図解、メリット・デメリットの列挙、おすすめツール15選、という構成でほぼ一致します。書いているのはCMSを提供している会社か、その導入を請け負う制作会社です。当然ながら「検討したうえで決めましょう」で終わり、どういう会社なら見送るべきかは書かれていません。

判断を分けるのは機能の比較ではありません。配信先がいくつあるか、そして公開後に誰が何を更新するかの2点です。配信先が自社サイト1つなら、ヘッドレスCMSの主要な利点は構造上ほとんど効きません。加えて、社内の担当者が自分で変更できる範囲は、WordPressより確実に狭くなります。

この記事では、何と何を分けた仕組みなのか、分けて得るものと失うもの、費目がどう変わるか、セキュリティを動機にしたときに順序が誤っている理由、SEOへの影響の実体、そして導入して成立する条件を整理します。CMS全般の選定と更新体制の作り方は更新しやすい企業サイトの作り方|CMS選定と運用設計のポイントで扱っています。

この記事でわかること

・ヘッドレスCMSは、原稿の管理と表示の生成を分けた仕組み。配信先が複数あるときに効く

・配信先が自社サイト1つなら、分けることで得られる利点の大半は発生しない

・失うのは「見たまま編集」と、担当者がレイアウトを自分で変えられる範囲

・費用は安くならない。制作費が減る代わりに、月額利用料と表示側の改修費が乗る

・セキュリティが動機なら順序が違う。2025年の脆弱性11,334件のうち91%はプラグイン、コア本体は6件

・SEOへの影響はヘッドレスか否かではなく、表示をどこで生成するか(SSG/SSR/CSR)で決まる

ヘッドレスCMSが向く条件
ヘッドレスCMSが向く条件

ヘッドレスCMSは、何と何を分けた仕組みか

CMSは本来、2つの仕事を1つのソフトウェアで担っています。原稿を保存・管理する仕事と、その原稿を読者に見えるページの形に組み立てる仕事です。WordPressはこの両方を持っています。管理画面で記事を書くと、同じサーバ上のテーマ(表示の型)がHTMLを組み立てて返します。

ヘッドレスCMSは、このうち後者を切り離したものです。「ヘッド(表示部分)が無いCMS」という意味で、原稿を保存してAPIで渡すところまでを担当します。受け取った原稿をどう組み立てて表示するかは、別に用意したフロントエンド側の役目になります。

観点 従来型CMS(WordPressなど) ヘッドレスCMS
原稿の管理 CMSが担当 CMSが担当
表示の生成 CMSが担当(テーマ) 別に用意した実装が担当
公開サーバ CMSと表示が同じ場所 配信環境とCMSが別の場所
更新できる範囲 文章・画像・並び順・一部レイアウト 登録した項目の中身のみ
表示を変えるとき テーマ設定やブロック編集で担当者が変えられる場合がある 原則として開発の作業
配信先 そのサイト サイト、アプリ、店頭端末など複数に同じ原稿を渡せる

表の下2行が、実務でいちばん効いてくる差です。ヘッドレスCMSの管理画面には、ページの見た目がありません。「タイトル」「本文」「サムネイル」「公開日」といった項目に値を入れる画面であり、それがページ上でどう並ぶかは表示側の実装で決まっています。

この構造は、原稿を複数の出し先に配るときに強く働きます。同じ「お知らせ」を自社サイトとスマートフォンアプリと店頭のサイネージに出すなら、原稿は1か所で管理し、それぞれの表示側が受け取って組み立てればよい。逆に、出し先が自社サイト1つしかないなら、分けたことによる利点はここでは発生しません。

ヘッドレスCMSは、原稿の管理と表示の生成を分け、前者だけを担う仕組み。

管理画面に見た目は無く、担当者が触れるのは登録された項目の中身だけになる。

分けることで得られるもの

利点は確かにあります。ただし、それぞれ成立するための前提条件があります。前提が無い会社が導入しても、利点だけが抜け落ちます。

配信先が複数あるとき、原稿の管理が1か所で済む

これがヘッドレスCMSの本来の存在理由です。Webサイト、スマートフォンアプリ、店頭端末、デジタルサイネージ、外部のポータルへの提供。同じ内容を複数の場所に出している事業では、更新の手間がそのまま出し先の数だけ増えています。原稿を1か所に集約すれば、更新漏れによる表示の食い違いも消えます。

前提条件は明快です。配信先が2つ以上あること。「将来アプリを作るかもしれない」は前提として弱く、その時点で作り直す判断のほうが安く済むことが多くなります。

表示側の実装が自由になり、速度と体験を作り込める

表示の生成が切り離されるため、フロントエンドの実装に制約がなくなります。あらかじめHTMLを生成しておく方式(静的生成)を取れば、閲覧者のリクエストに対してファイルを返すだけになり、表示は速くなります。

ただし「ヘッドレスにすれば速くなる」ではありません。速いのは静的生成やキャッシュの効果であり、それらはWordPressでも実現できます。表示速度が動機なら、改善の順序を確認してからのほうが確実です。何から手をつけるかはサイトの表示速度を改善する優先順位|何から手をつけるかで整理しています。

公開サーバ上に管理画面が存在しない

WordPressは管理画面(ログインページ)が公開サーバ上にあります。ヘッドレス構成では、原稿はCMS提供事業者側にあり、公開されている配信環境には静的なファイルやAPIの応答しか置かれません。公開側に対する攻撃で、原稿と管理権限が同時に奪われる形にはなりません。

これは実質的な利点です。ただし、後述するとおりこれを主目的にして構成を変えるのは、費用対効果として最も悪い選択になります。

利点は「配信先が複数」「表示を作り込む要件がある」ときに成立する。

速度はヘッドレスの効果ではなく生成方式の効果で、従来型でも取れる。

分けることで失うもの

導入の相談で最も説明が抜けているのがここです。ヘッドレスCMSにすると、社内の担当者が自分でできることは確実に減ります。減った分は制作会社への依頼に変わります。

「見たまま」の編集ができなくなる

WordPressの編集画面は、公開後の見た目に近い形で本文を確認しながら書けます。ヘッドレスCMSの編集画面は、項目に値を入れるフォームです。プレビュー機能は多くのサービスで用意されていますが、それは表示側に別途プレビュー用の実装をした場合に動くものです。制作の見積りに入っているかどうかを、契約前に確認してください。

レイアウトの変更が、その都度の開発案件になる

「このセクションに写真を2枚並べたい」「今回だけ表を入れたい」。WordPressのブロックエディタなら担当者が自分でできることが、ヘッドレス構成では表示側の改修になります。あらかじめ登録した項目にない形は、出せません。

これは設計次第で緩和できます。柔軟な繰り返し項目を用意しておけば、ある程度の組み替えは管理画面から可能になります。ただし柔軟にするほど実装費は上がり、入力の難易度も上がります。どこまで自由に組めるようにするかが、そのまま初期費用の見積りに乗ります。

プラグインで足りていた機能を、個別に用意することになる

見落とされやすく、しかも公開直前に問題化するのがこれです。WordPressで無償のプラグインを入れるだけで済んでいた機能が、ヘッドレス構成では別のサービス契約か個別実装になります。

機能 WordPressでの一般的な扱い ヘッドレス構成での扱い
問い合わせフォーム プラグインを導入して設置 フォーム専用サービスの契約、または個別実装
サイト内検索 標準機能またはプラグイン 検索サービスの契約、または個別実装
リダイレクト設定 プラグインで担当者が設定 配信環境側の設定ファイルを編集
title・meta descriptionの個別設定 SEO系プラグインで入力欄が出る CMSに項目を作り、表示側で出力する実装
多言語対応 プラグインまたはマルチサイト コンテンツ設計の段階から言語を持つ設計が必要
会員機能・権限による出し分け プラグイン 認証の仕組みを別途用意

1つひとつは大きな金額ではありません。ただし合計すると、月額の固定費と初期の実装費の両方が積み上がります。見積りを比較するときは、この表の行が制作会社の提案に含まれているかを確認してください。含まれていない提案は安く見えます。

制作会社を変えにくくなる

WordPressは利用が広く、引き継げる制作会社を探しやすいという実務上の利点があります。W3Techsの集計では、CMSが判明しているサイトの58.9%がWordPressで、全ウェブサイトに対しては40.7%です(2026年8月28日時点)。

ヘッドレス構成は、CMSの選定、フロントエンドの実装、配信環境の設定がそれぞれ独立しており、組み合わせは会社ごとに違います。引き継ぐ側は前任者の実装を読むところから始めることになり、見積りは高くなり、対応できる会社の数も減ります。特定の制作会社への依存度は、従来型より上がると考えてください。

失うのは、担当者が自分でできる範囲。減った分は依頼に変わる。

プラグインで賄っていた機能は、契約か個別実装として費用に戻ってくる。

費用は安くならない。費目が変わる

「ヘッドレスなら保守が軽くなって安くなる」という説明を受けることがあります。正確には、費目の構成が変わります。減るものと増えるものが両方あるため、金額の増減は更新の頻度と種類で決まります。

費目 従来型CMS ヘッドレスCMS
初期の実装費 テーマ制作 表示側の実装。項目設計の分だけ工程が増える
CMSの利用料 無料(WordPress本体) 月額の利用料が発生する
サーバ・配信環境 レンタルサーバ 配信サービス。無料枠で始まり、規模に応じて課金
更新作業(文章・画像) 社内で対応可能 社内で対応可能
更新作業(並び・レイアウト) 社内で対応できる場合がある 開発への依頼
保守(本体・プラグインの更新) 毎月必要 CMS側は事業者が対応。表示側の依存関係は必要

国内で採用例の多いmicroCMSの料金を例に取ると、無料のHobbyプラン、月額4,900円からのTeamプラン、月額75,000円からのBusinessプランという構成です(2026年8月時点・税抜、公式の料金ページ)。プランはメンバー数、API数、コンテンツ数、データ転送量の上限で分かれます。

注意すべきはプランを分けている基準が「使う人数」と「入れ物の数」であることです。編集に関わる人が増えるほど、また扱うコンテンツの種類が増えるほど、上のプランが必要になります。企業サイトで部署ごとに更新者を置く運用を想定しているなら、無料枠や下位プランでは収まりません。

そのうえで、増減の分かれ目は次のように考えられます。

  • 更新が原稿の差し替え中心(お知らせ、実績、記事の追加):ヘッドレスでも社内で完結する。月額利用料の分だけ増える
  • 更新にレイアウトの変更が混じる(キャンペーンごとに見せ方を変える):都度の開発費が積み上がり、確実に高くなる
  • 配信先が2つ以上ある:出し先ごとの更新作業が消えるため、運用の人件費で回収できる可能性がある

制作費が減る代わりに、月額利用料と表示側の改修費が乗る。

分かれ目は更新の種類。原稿の差し替えだけなら成立し、レイアウト変更が混じると高くつく。

セキュリティが動機なら、着手する順序が違う

「WordPressは危ないと聞いた」という理由でヘッドレス化を検討している場合、先に確認すべきことがあります。危険なのはWordPress本体ではないためです。

Patchstackの年次レポート「State of WordPress Security in 2026」(2025年のデータを集計)によると、2025年にWordPressのエコシステムで新たに判明した脆弱性は11,334件で、前年から42%増加しました。内訳は次のとおりです。

対象 2025年に判明した脆弱性
プラグイン 全体の91%
テーマ 全体の9%
WordPressコア本体 6件(優先度の低い問題として扱われている)
高い深刻度と評価されたもの 1,966件(全体の17%)

コア本体の6件に対して、プラグインが91%です。侵害の入口は、入れたプラグインと、その更新を止めていることにあります。ヘッドレス化はこの構造に対して、最も工事が重い対処法です。同じ動機なら、先に効く手が4つあります。

  1. プラグインの棚卸し:使っていないもの、開発が止まっているものを削除する。数を減らすことが最も効く
  2. 本体とプラグインの更新を運用に組み込む:更新しない前提で作られたサイトが最も危険な状態にある
  3. 管理画面のログイン保護:二要素認証、ログイン試行の制限、URLの変更
  4. 権限の見直し:全員が管理者になっている状態を解消する

これらは数万円から十数万円の範囲で着手でき、リスクの大半を下げられます。ヘッドレス化はサイトを作り直す判断であり、セキュリティを理由に選ぶには費用が釣り合いません。そしてCMSを乗り換えても、更新を止める体制が同じであれば、同じ状態が数年かけて再現します。

2025年の脆弱性11,334件のうち91%はプラグイン、コア本体は6件。

セキュリティが動機なら、プラグインの整理と更新体制の方が費用対効果で先に来る。

SEOへの影響は、ヘッドレスかどうかでは決まらない

「ヘッドレスにするとSEOに弱い」という説明も、「速くなるからSEOに強い」という説明も、どちらも不正確です。影響するのはCMSの構造ではなく、HTMLをどこで組み立てるかです。

Googleは、JavaScriptを使ったページの処理をクロール・レンダリング・インデックスの3段階に分けて説明しています。取得したページのHTMLにコンテンツが含まれていない場合、JavaScriptを実行して表示を組み立てる工程(レンダリング)が必要になり、その処理は順番待ちの列に入ります。公式ドキュメントは、この待ち時間について「数秒で済むこともあるが、それより長くかかることもある」と記しています。

表示の生成方式 何が返るか インデックスへの影響
静的生成(SSG) あらかじめ作られたHTML 従来型CMSと同じ。追加の懸念はない
サーバーサイドレンダリング(SSR) リクエストごとに組み立てたHTML 同上。応答速度の設計は必要
クライアントサイドのみ(CSR) ほぼ空のHTMLとJavaScript レンダリング待ちが発生し、反映が遅れうる

つまり、ヘッドレスCMSでも静的生成またはSSRで構成すれば、検索エンジンから見た条件はWordPressと変わりません。問題が起きるのは、閲覧者のブラウザ側だけで本文を組み立てる構成を選んだ場合です。制作会社の提案書に生成方式が書かれていないなら、必ず確認してください。

あわせて、公開後にページが検索結果に出ない状態が起きたときの切り分けはページがインデックスされない原因と確認の順序|検索に出ない状態を切り分けるに手順をまとめています。

Googleの処理はクロール・レンダリング・インデックスの3段階。待ち時間は数秒とは限らない。

SSGまたはSSRなら従来型と同条件。CSRのみの構成だけが不利になる。

導入して成立する条件と、見送るべき条件

ここまでを、判断に使える形に落とします。次の5つの質問に答えてください。

確認する項目 ヘッドレスが成立する 見送るべき
原稿の配信先はいくつか 2つ以上ある 自社サイト1つだけ
公開後の更新は何が多いか 原稿・画像の差し替えが中心 見せ方やレイアウトも変えたい
公開後に開発を頼めるか 継続的な依頼先と予算がある 公開後は予算を確保していない
表示側に固有の要件があるか 既存テーマでは実現できない体験がある 一般的な企業サイトの構成で足りる
検討の動機は何か 配信先の集約、表示の作り込み セキュリティ、速度、流行

右側の列に1つでも当てはまるなら、まず従来型CMSで作り、更新が回る状態を確認してから検討することを勧めます。特に「動機がセキュリティ」「動機が速度」の2つは、前の章のとおり別の手段のほうが安く確実です。

見送る判断は、後戻りできない判断ではありません。配信先が増えた時点、あるいは表示側の要件が固まった時点で移行すればよく、そのときには何を管理すべきかが実運用から分かっています。項目設計は、更新の実績があるほど精度が上がります。

移行するなら、何から決めるか

導入すると決めた場合、着手の順序を誤ると公開後に直せなくなります。次の5つを、実装の前に決めてください。

  1. コンテンツの項目設計:ページ単位ではなく、情報の種類ごとに項目を定義する。ここが実質的な設計の中心で、後から変えると入力済みのデータに影響する
  2. 更新者が触る画面の確認:実際に更新を担当する人に管理画面の試作を触ってもらう。項目名が社内の呼び方と違うだけで、更新は止まる
  3. プレビューの範囲:どの画面で、どこまで公開後の見た目を確認できるようにするかを見積りに含める
  4. 既存URLの扱い:現行サイトのURLを維持するか、変えるならリダイレクトをどう設定するかを先に決める。手順はURLを変えるときのリダイレクト|評価を落とさない手順と、やってはいけない転送を参照
  5. 撤退時のデータの持ち出し:CMSの契約を終了するとき、蓄積した原稿と画像をどの形式で取り出せるかを契約前に確認する

5つ目は特に軽視されがちです。ヘッドレスCMSは外部のサービスであり、料金改定も、提供終了もあり得ます。取り出せる形式(JSONでのエクスポート、APIでの全件取得)を確認しないまま数年分の原稿を蓄積すると、乗り換えの選択肢そのものが失われます。

よくある失敗

導入そのものが失敗するというより、公開の直前か、公開して数か月後に問題が表面化します。実務で繰り返し起きるものを4つ挙げます。

更新担当者が管理画面を初めて見るのが、公開の直前になる

項目設計は制作会社と決裁者の間で進み、実際に毎日更新する人が試すのは納品前になりがちです。そこで「この項目に何を入れるのか分からない」「いつも入れている情報を入れる場所がない」が出てくると、設計のやり直しになります。試作の段階で、担当者に実際の原稿を1本入れてもらってください。

プレビューが見積りに入っていない

ヘッドレス構成のプレビューは、表示側に別途の実装が必要です。含まれていないまま公開すると、担当者は公開してから見た目を確認することになります。修正のたびに本番へ反映することになり、更新そのものが避けられるようになります。

フォームを最後に検討する

問い合わせフォームはプラグインで済むものだと考えたまま進み、実装の終盤で別サービスの契約か個別実装が必要だと判明します。フォームは問い合わせの入口であり、後から急いで用意すると、確認画面や自動返信、迷惑メール対策が抜けた状態で公開されます。

配信先が増える前提で導入したが、増えなかった

「来年アプリを出す」を前提に構成を決めたものの、その計画が動かないまま数年が経つ例です。この場合、費用と制約だけが残ります。配信先の集約を理由にするなら、2つ目の出し先が具体的な計画として存在してから着手してください。

よくある質問

WordPressはもう古いのでしょうか

技術的な選択肢としては現役です。W3Techsの集計では、CMSが判明しているサイトの58.9%、全ウェブサイトの40.7%がWordPressです(2026年8月28日時点)。古いのはWordPress自体ではなく、更新もされずプラグインが積み上がったまま放置されている個別のサイトの状態です。その状態はCMSを乗り換えても、体制が同じであれば再び発生します。

ヘッドレスCMSにすると表示は速くなりますか

速くなるのは、あらかじめHTMLを生成しておく方式を採用した場合です。ヘッドレスにしたこと自体の効果ではありません。同じ手法はWordPressでもキャッシュや静的化で実現できます。速度が目的なら、まず現状のどこで時間がかかっているかを計測してください。多くの場合、画像の容量とサードパーティのタグが上位に来ます。

担当者が自分で更新できなくなるのですか

原稿と画像の差し替えは、これまでどおり社内でできます。できなくなるのは、レイアウトや構成そのものの変更です。あらかじめ用意した項目の外に出る変更は、表示側の改修になります。更新の内容が毎回「文章を差し替える」で収まるなら支障はありません。

費用はWordPressと比べてどのくらい変わりますか

初期の実装費は、項目設計と表示側の作り込みが加わるぶん高くなるのが一般的です。加えてCMSの月額利用料と配信環境の費用が継続して発生します。一方でプラグインの更新に伴う保守は軽くなります。最終的な差は、公開後にレイアウト変更をどれだけ依頼するかで決まるため、その頻度を見積りの前提として制作会社に伝えてください。

既存のWordPressサイトを部分的にヘッドレス化できますか

できます。WordPressをAPIとして使い、表示側だけを別に実装する構成です。管理画面の使い勝手を残したまま表示を作り込めるため、移行の中間的な選択肢になります。ただし、WordPress側の保守は引き続き必要で、構成が二重になるぶん引き継ぎの説明は増えます。

提案を受けています。何を確認すればよいですか

4点あります。第一に表示の生成方式(SSG/SSR/CSRのどれか)。第二にフォーム・サイト内検索・多言語といったプラグインで賄っていた機能が見積りに含まれているか。第三にプレビューの範囲。第四に公開後の改修を、どの単位でいくらで依頼できるか。この4点が書かれていない見積りは、比較の対象になりません。

まとめ

ヘッドレスCMSの導入判断で見るべきは、機能の一覧ではありません。原稿の配信先がいくつあるか、そして公開後に誰が何を更新するかの2点です。配信先が自社サイト1つだけなら、原稿を集約するという最大の利点は発生しません。

分けることで失うものは明確です。「見たまま」の編集ができなくなり、レイアウトの変更はその都度の開発案件になります。プラグインで無償に済んでいたフォーム、サイト内検索、多言語、リダイレクト設定は、別のサービス契約か個別実装として費用に戻ってきます。見積りが安く見える提案は、この行が抜けている可能性を疑ってください。

費用は安くなるのではなく、費目が変わります。制作費の内訳が変わり、CMSの月額利用料と配信環境の費用が継続して乗ります。分かれ目は更新の種類です。原稿の差し替えが中心なら社内で完結しますが、見せ方の変更が毎回混じる運用では、依頼の回数だけ費用が積み上がります。

動機がセキュリティなら、順序が誤っています。2025年に判明した11,334件の脆弱性のうち91%はプラグインで、コア本体は6件でした。入口はプラグインの積み上げと更新の放置にあり、棚卸しと更新体制の整備のほうが、はるかに少ない費用で同じリスクを下げられます。

SEOについては、ヘッドレスかどうかでは決まりません。静的生成かサーバーサイドレンダリングで構成すれば、検索エンジンから見た条件は従来型と変わりません。不利になるのは、閲覧者のブラウザ側だけで本文を組み立てる構成を選んだ場合です。提案書に生成方式が書かれていないなら、契約前に確認してください。

そして、見送る判断は取り返しのつくものです。配信先が増えた時点、表示側の要件が固まった時点で移行すればよく、そのときには実際の運用から「何を項目として持つべきか」が分かっています。先に構造を変えるより、更新が回る状態を作るほうが先です。CMSの選定や既存サイトの見直しでご相談があればお問い合わせからご連絡ください。これまでに手がけたサイトは制作実績でご覧いただけます。

SHARE