ヘッドレスCMSとは？導入したあとの運用で決まる、選ぶ前の3つの判断

アーム代表の伊藤です。
ヘッドレスCMSは「速いCMS」ではなく、更新1回に挟まる人を減らすCMSです（アーム自身、microCMSで自社サイトのコラム70本・サービス詳細17ページを運用中。2026年8月12日時点）。だから向き不向きは表示速度ではなく更新フローで決まります。この記事では、ヘッドレスCMSを選ぶ前に済ませておく3つの判断までを整理します。

こんな方におすすめのコラムです

• 「保守費を毎月払っているのに、お知らせ1本の差し替えに3営業日かかる」という方
• 「ヘッドレスCMSは速いと聞いたが、うちに開発者はいない。入れたあと自分の手に負えるのか分からない」という方
• 「WordPressとヘッドレスCMSの機能比較表を見比べたが、どちらが自社向きか結局決められない」という方
• 「制作会社にヘッドレスCMSを提案されたが、その会社自身が使っているのか疑わしい」という方
• 「次の保守契約の更新までに、移すか残るかを根拠つきで決めたい」という方

ヘッドレスCMSとは、表示画面（ヘッド）を持たないCMSのこと

ヘッドレスCMSとは、コンテンツの管理機能だけを持ち、表示画面（ヘッド）を持たないCMSを指します。英語では headless CMS と表記し、コンテンツをAPI（※API…システム同士がデータをやり取りする窓口のこと。CMSに入れた本文を、サイト側が取りに行くための口だと考えてください）で配信することから「API型CMS」とも呼ばれます。表示画面を持たないぶん、同じ本文をWebサイト・アプリ・デジタルサイネージなど複数の届け先へ同時に配信できることが、ヘッドレスCMSが注目される理由です。

たとえるなら、従来型CMSは売り場と倉庫が一体になった店舗です。商品（コンテンツ）の置き場所と見せ方が同じ建物に固定されています。ヘッドレスCMSは倉庫だけを持つセンター倉庫で、店頭にもECにもカタログにも、同じ在庫を出せます。そのかわり、売り場（表示画面）は別に建てる必要があります。

ヘッドフルCMS（従来型CMS）とヘッドレスCMSは何が違うのか

ヘッドフルCMSとは、管理画面と表示画面が一体になった従来型のCMSを指します。代表はWordPressで、W3Techsの調査「Usage statistics of content management systems」（2026年8月12日時点）によれば、WordPressは全Webサイトの41.0%、CMS利用サイトの59.0%で使われています。世の中のCMSの標準はいまもヘッドフル側です。

両者の違いは次の表のとおりです。

機能の差に見えますが、あとで詳しく述べるとおり、実際に効いてくるのは「更新1回に誰が挟まるか」という運用の差です。

なぜヘッドレスCMSは速いと言われるのか

ヘッドレスCMSが速いと言われるのは、あらかじめ全ページを生成しておき、CDN（※CDN…世界中に分散した配信サーバー網。閲覧者に近い場所からページを返す仕組み）から静的ファイルとして配信する構成を取りやすいからです。アクセスのたびにサーバーがページを組み立てる従来型の構成と比べ、表示までの時間を短くしやすくなります。

表示速度が語られる背景には検索順位への関心もあります。Googleは公式ドキュメント「ページエクスペリエンスの解説」（Google検索セントラル）で、ランキングシステムがCore Web Vitals（表示速度などの指標群）を使用していると明言しています。ただし同じドキュメントで、順位を決める単一のシグナルは存在せず、関連性の高いコンテンツが優先されるとも明言されています。速くすれば順位が上がる、という単純な話ではない点は押さえておいてください。

そして大事なのは、速さはCMSの性質ではなく構成の結果だということです。この点はメリットの章で詳しく扱います。

ヘッドレスCMSを選ぶ前の3つの判断。向き不向きは表示速度ではなく更新フローで決まる

ここからがこの記事の本題です。ヘッドレスCMSを入れるかどうかは、表示速度ではなく、次の3つの判断で決まります。

判断1から見ていきます。お知らせ1本を差し替えるとき、あなたの会社では何人が動いているでしょうか。外注保守のサイトでよくあるのは、Web担当者が制作会社の窓口へ依頼メールを送り、窓口が実装者へ渡し、実装者が反映し、確認を戻し、公開される流れです。人が4〜5人、日数で2〜3営業日。伝言ゲームの人数だけ、時間とお金と、伝わらないリスクが増えます。

ヘッドレスCMSを内製運用に組み合わせると、この流れはWeb担当者が管理画面に入力して公開する、の2工程になります。アームの自社サイトでは、コラム1本の公開に挟まる人は0人です。代表の伊藤が原稿を入稿し、その日のうちに公開されます。ヘッドレスCMSの価値はこの構造にあります。速さは副産物です。

逆に言えば、いまの更新フローに誰も挟まっていないなら、ヘッドレスCMSに移しても得られるものは小さくなります。挟まっている人数を数えることが、カタログ比較より先にやるべき判断です。

WordPressとヘッドレスCMSの違いは、機能ではなく「運用の手離れ」で見る

判断2の話に入ります。WordPressとヘッドレスCMSを比べるとき、機能表を見比べても答えは出ません。差が出るのは「運用の手離れ」、つまり導入したあとに誰がどこまで自分で更新できるかです。

機能表で並べても差が出ない理由

機能の一覧で比べると、両者はほとんど同じことができてしまいます。記事の投稿、下書き、予約公開、画像の管理、権限の設定。どれも両方にあります。機能表はカタログ上の「できる」を並べたもので、あなたの会社の担当者が「実際にやれるか」を教えてくれません。比較表を何度眺めても決められないのは、見る場所がずれているからです。

手離れで比べると差が出る4つの場面

運用の手離れは、次の4つの場面で差が出ます。

注意してほしいのは、ヘッドレスCMSにしても外注が消えるわけではないことです。デザイン改修や構造変更では開発者が要ります。消えるのは日常更新の外注だけです。逆に、日常更新こそが依頼の大半を占める会社にとっては、そこが消えるだけで毎月の保守費と待ち時間の意味が変わります。毎月の保守費で実際に何が行われているかは、別記事「ホームページの保守費用の相場」で分解しています。

なお、いまのWordPressを残したまま表示側だけを分離する「WordPressのヘッドレスCMS化（ヘッドレス化）」という選択肢もあります。WordPressをAPIサーバーとして使い、フロントを別に建てる構成です。使い慣れた管理画面を残せる一方、WordPress本体の保守は残り続けるため、保守の手離れという観点では中間解になります。

ヘッドレスCMSのメリットと、そのメリットが効かなくなる条件

ヘッドレスCMSのメリットを、効かなくなる条件とセットで見ていきます。メリットの列挙はどの解説記事にもありますが、実際の判断で要るのは「それが自社で効くか」だからです。

よくある誤解にも触れておきます。「ヘッドレスCMSに移せばサイトは必ず速くなる」は誤解です。実際の表示速度はフロント側の実装で決まります。ヘッドレスCMSはヘッドを外しただけの箱で、遅い実装を載せれば遅いサイトができあがります。速さを目的に導入を検討しているなら、まず現状の遅さの原因を特定するほうが先です。

ヘッドレスCMSのデメリットは3つ。ただし本当に効くのは、その先の「運用の罠」のほう

ヘッドレスCMSのデメリットとしてよく挙がるのは次の3つです。

• フロント開発が別途必要になる（初期費用が増え、開発の依頼先が要る）
• 記事のプレビュー環境の構築に手間がかかる（表示画面が別システムのため）
• 検索やフォームなどの動的機能は外部サービスで補う必要がある

どれも事実ですし、見積もりにも表れるので導入前に気づけます。問題は、この3つが解説記事の定番になっている一方で、導入後の運用で実際につまずくポイントは別の場所にあることです。次の章で、アームが自社運用で実際に踏んだ罠を共有します。

アームがヘッドレスCMS（microCMS）の運用で実際に踏んだ4つの罠

ここからは、アームがヘッドレスCMSのmicroCMSで自社サイト（コラム70本・サービス詳細17ページ）を運用するなかで、実際に踏んだ罠を4つ共有します。先に断っておくと、これはmicroCMSという製品の欠陥の話ではありません。API型CMS全般で誰でも踏みうる運用の落とし穴で、いずれもアームの運用で確認した挙動（2026年8月時点）です。回避策とセットで書きます。

罠1: リッチエディタの本文は、全文検索が効かない

microCMSのリッチエディタ形式のフィールドでは、本文を対象にしたAPIの絞り込み検索が効きません（アームの運用で確認した挙動・2026年8月時点）。記事が70本を超えたあたりで「あの説明をどの記事に書いたか」をAPIで探せないことに気づきました。運用が長くなるほど、過去記事の横断確認は増えます。表記の統一、重複テーマの確認、リンクの張り替え。どれも本文を検索できることが前提の作業です。

回避策は2つです。全件を取得して手元で検索する仕組みを先に作っておくこと。そして、あとから検索・分類に使いたい情報は、本文に埋めず最初から別フィールドに分けておくことです。これはスキーマ設計（※スキーマ…CMSにどんな入力欄を持たせるかの設計のこと）の問題なので、構築後に直すには全記事の移し替えが要ります。発注者としては、構築前に「公開後、過去記事の横断検索はどうやるのか」を確認してください。

罠2: 本文の「見えない目印」を消すと、ページの部品が消える

アームのサイトでは、本文の途中に挿入されるCTAバナーなどの部品を、本文中に埋めた目印をアプリ側が置き換える方式で実現しています。この構成で一度、公開ページからコピーした本文を整えて入稿し直したところ、目印ごと上書きされてバナーが静かに消えました。エラーは出ません。見た目も本文としては正常です。消えたことに気づいたのは後日でした。

回避策は、本文の正本はCMS側にしかないと決めることです。書き直しは必ずAPIから取得した原稿をベースに行い、公開ページからの逆流入稿を禁止する。加えて、本文中にアプリ側だけが解釈する記法があるなら、それを仕様書に残してもらってください。制作会社の頭の中にしかない仕様は、担当が替わった瞬間に事故になります。

罠3: 下書きのつもりのAPI更新が、公開中の本文を書き換える

API経由で記事を更新するとき、下書き指定のパラメータの渡し方を誤ると、下書きにならずに公開中の本文がその場で書き換わります。アームはこれを本番の記事で踏みました。「下書きに保存したはず」の変更が、その瞬間からお客様の目に触れていたわけです。

回避策は、更新経路ごとに「本当に下書きになるか」をテスト記事で検証してから運用に載せること、そして更新前に現行の本文を取得して控えを残すことです。管理画面から手で更新するだけなら起きにくい事故ですが、後述するAI活用のように、APIから本文を触る運用を少しでも考えているなら、下書き更新の手順が確立されているかを必ず確認してください。

罠4: AIに長文を書き戻させると、1文字単位の誤変換が静かに混ざる

AIに本文の修正を任せ、API経由で長文を書き戻す運用では、文字化けのような分かりやすい壊れ方ではなく、1文字単位の誤変換が本文に混ざることがあります。アームの運用でも確認しました。数万字の本文に数文字ですから、目視の校正ではまず見つかりません。

回避策は、書き戻しのあとに元原稿との差分照合を機械的に行う工程を、運用の標準に組み込むことです。人の注意力に頼る校正では確率の問題になります。照合を道具に任せれば、混入はその場で検出できます。

罠は注意ではなく道具で潰す。アームが自社用MCPサーバーを作った理由

前章の4つの罠に共通するのは、「気をつけましょう」では防げないことです。運用ルールは、忙しい日に必ず破られます。だからアームは、ルールではなく道具の側で事故を封じることにしました。具体的には、Cloudflare Workers上に自社用のMCPサーバー（※MCP…Model Context Protocol。AIが外部の道具を呼び出すための共通規格）を実装し、AIがCMSの本文を操作するときに、前章の罠を構造的に踏めないようにしています。公開中の記事を直接書き換える操作を通さない、書き戻したら照合を自動で行う、という設計です。

これはヘッドレスCMSだから取れた選択でもあります。すべての操作がAPIで行える構造は、AIに運用を手伝わせる前提と相性がよい。ただし、罠も同じAPIから入ってきます。AI活用を見込んでヘッドレスCMSを検討しているなら、「AIに何をさせ、何をさせないかを、道具のレベルで制御できるか」までを設計の範囲に含めることをおすすめします。ここを運用ルールの紙切れで済ませると、前章の罠3と罠4がいつか現実になります。

ヘッドレスCMSの費用は「CMSの月額」ではなく3年の総額で見る

判断3、ヘッドレスCMSの費用の話に入ります。この記事を含め解説記事の多くが費用を曖昧にしますが、判断には数字が要ります。確認できた公式の数字と、単純計算でどこまで言えるかを書きます。

microCMSの料金（2026年8月12日時点）

アームが利用しているmicroCMSの料金は、microCMS公式の料金ページで次のように公開されています（2026年8月12日に確認。いずれも税抜）。

小規模なコーポレートサイトなら、CMS利用料そのものは月0〜4,900円の範囲に収まるケースが多い価格構造です。料金は変わるため、検討時には必ず公式ページで最新の金額を確認してください。

WordPressの保守費と並べると、何が消えて何が増えるか

費用の判断は、CMSの月額ではなく3年の総額で行います。項目を並べると次のようになります。

仮にいま月4万円の保守費を払っているなら、3年で144万円です（単純計算）。そのうち日常更新の代行にあたる部分は、ヘッドレスCMSの内製運用に移すと消えます。かわりに、フロント開発と移行の初期費用が新たに発生します。この初期費用はサイトの規模と移行するコンテンツの量で大きく変わるため、この記事では相場の数字を出しません。業界共通の定価も公的統計も存在しない領域だからです。リニューアル費用の考え方は「サイトリニューアルの費用相場」に、アーム自身の料金は「料金ガイド」にまとめてあります。

そのうえで、費用の比較には金額に出ない項目が1つあります。更新1回が3営業日から当日になることの価値です。キャンペーンの開始が3日早まる、採用情報の誤りが即日直せる、価格改定を全ページ同日に反映できる。ヘッドレスCMSの損得は、CMS利用料の差ではなく、この機会損失を含めた3年総額で決まります。月々の保守費と初期費用と機会損失を1枚の表に並べれば、移すべきかどうかは自動的に答えが出ます。

ヘッドレスCMSに移すべきか、いまの保守契約のままでよいか。この表を自社の数字で埋めるところからで構いません。アームは判断の材料集めの段階からご一緒しています。ヘッドレスCMS移行の判断材料づくりを相談する

ヘッドレスCMSが向く会社・向かない会社

ここまでの3つの判断を、ヘッドレスCMSが向く会社・向かない会社の形に畳みます。

右の列に多く当てはまる会社は、ヘッドレスCMSに移さないほうが合理的です。WordPressやノーコードツールで困っていないなら、それが答えです。CMSの乗り換え自体には1円の売上も立ちません。私たちは制作を受ける側ですが、ここは正直に書いておきます。

左の列に当てはまった会社が次に整えるべきなのは、ツール選定ではなく「自社で更新を回せる体制」の設計です。その全体像は「自社で更新できるホームページ運用体制のつくり方」に分けてまとめています。

自社がどちら側なのか判断がつかない場合は、いまの更新フローに挟まっている人と工程を書き出すところからで十分です。更新フローの棚卸しから相談する

ヘッドレスCMS導入・移行の進め方は4ステップ

ヘッドレスCMSの導入・移行は、次の4ステップで進めます。

1. 判断: 前章までの3つの判断で、移す価値があるかを先に確定させる
2. スキーマ設計: どんな入力欄を持たせ、何を本文に入れ、何を分けるかを決める
3. 移行: 既存コンテンツを移し替え、照合の工程で欠落と化けを検出する
4. 運用: 下書きフロー・書き戻しの照合・権限を、ルールではなく道具に落とす

この中で最も重要なのはステップ2のスキーマ設計です。運用の罠の章で書いたとおり、検索・分類・再利用の要件はスキーマで決まり、あとから直すには全コンテンツの移し替えが要ります。デザインの前に、更新する人の作業を1画面ずつ想像しながら入力欄を設計できるか。ヘッドレスCMSの構築を依頼するとき、依頼先を見極めるポイントはここに表れます。

主要なヘッドレスCMSサービス（国産・海外・OSS）

参考までに、名前の挙がることが多いヘッドレスCMSを分類だけ載せます。ヘッドレスCMSは大きく、ベンダーが運用まで提供するSaaS型と、自社サーバーに設置するセルフホスト型（オープンソース）に分かれます。この記事の主題は選定の判断軸なので、機能比較には踏み込みません。

各サービスの料金・仕様は頻繁に変わります。本記事で金額を確認したのはmicroCMSのみ（2026年8月12日時点）なので、比較検討の際は必ず各社の公式サイトで最新情報を確認してください。そして機能表を見比べる前に、この記事の3つの判断を先に済ませることをおすすめします。判断より先にツールを選ぶと、選定理由が「なんとなく有名だから」になります。

ヘッドレスCMSに関するよくある質問

まとめ｜ヘッドレスCMSは「速いから」で選ばない

ヘッドレスCMSとは、表示画面を持たずAPIでコンテンツを配信するCMSです。ただし、ヘッドレスCMSの導入判断を表示速度でしてはいけません。判断の軸は3つ。更新1回にいま何人挟まっているか、導入後に誰がどこまで更新できるか、そして3年の総額で割に合うか。この3つに答えが出れば、ヘッドレスCMSが自社に向くかどうかは機能表を見なくても決まります。

なお、いまの体制で困っていないなら、無理にヘッドレスCMSへ移す必要はありません。CMSはあくまで手段で、乗り換え自体は成果を生まないからです。一方、更新のたびに人が挟まり、日数と保守費が積み上がっているなら、次の保守契約の更新は見直しの好機です。

アームはmicroCMSで自社サイトを構築し、運用まで自分たちで回している当事者です。この記事の罠も回避策も、すべて自社で踏んで確かめたものです。microCMSでの構築から、公開後にお客様自身が更新を回せる体制づくりまで、判断の段階からご相談いただけます。ヘッドレスCMSの導入と運用体制づくりを相談する