オルタナティブ・ブログ > 平凡でもフルーツでもなく、、、 >
RSS
平凡でもフルーツでもなく、、、

感覚人間の思いつき、、、気になった記事、、、雑記等

ヘッドレスCMSの「デザインが自由」が腑に落ちるまで

»

先日「ヘッドレスCMSのメリットが長年ピンとこなかった理由と、MCPで変わったこと」という記事を書きましたが、長年、「ヘッドレスCMSはデザインが自由」を見るたびに「？」を感じていました。

MCPサーバの利用やAIエージェントからAPI接続を利用することで、ヘッドレスCMSだけでなくAPI接続可能なCMSの利用価値が大きく見直されるようになりつつあります。

このような状況で、長年抱えていた「ヘッドレスCMSはデザインが自由」について、複数のAIエージェントに相談して、自分なりに腹落ちする例を見つけることができたので記録として残しておきたいと思います。

まず「具体的にどういう場面か」を聞いてみた

このデザインを再現するには、HTMLの構造をこう変えなきゃいけないけど、CMSの仕様上無理とされるケースについて、「具体的に、どういう表現をする場合なのか、具体的な事実を示して」と聞いてみた結果。

============

WordPress（従来型CMS）で「このデザインを再現するには、HTMLの構造をこう変えなきゃいけないけど、CMSの仕様上無理です」とエンジニアが頭を抱える具体的なケースを3つ紹介します。

これらはすべて、WordPressが「システム側でHTMLを自動生成して出力してしまう」という仕様を持っているために起こる衝突です。

ケース①：記事一覧で「3番目と7番目だけ、全く違うデザインのバナー」を挟みたいとき

デザイナーが、ユーザーを飽きさせないために以下のような「記事一覧（グリッド）デザイン」を作ったとします。

  • 1〜2枚目：通常の新着記事カード（画像＋タイトル）
  • 3枚目：正方形の全面広告バナー（全面背景画像＋ボタン）
  • 4〜6枚目：通常の新着記事カード
  • 7枚目：横長のメルマガ登録フォーム（テキスト＋入力欄＋ボタン）

WordPressの仕様上の無理

WordPressで記事一覧を出力する際、基本的には`while (have_posts())` という**同じHTML構造をループ（繰り返し）処理して並べる**のが標準の仕様です。 「3番目と7番目だけ、HTMLの構造（タグの種類や入れ子関係）をガラリと変え、かつそこに別のデータ（広告やフォーム）を挿入する」というのは、WordPressの標準的な出力の仕組みを無理やりハックして、泥臭い条件分岐コードを大量に書く必要があり、エンジニアから「仕様上、綺麗に実装するのが難しい」と拒否されやすいデザインです。

ケース②：プラグインが勝手に出力するHTMLのせいで、CSSが当たらないとき

お問い合わせフォームを作る際、WordPressではほぼ100%『Contact Form 7』などの有名プラグインを使います。 デザイナーが「入力欄（input）とラベル（label）をきれいに横並びにして、エラーメッセージは絶対配置（`position: absolute`）でこの位置に浮かせる」という洗練されたUIをデザインしたとします。

WordPressの仕様上の無理

WordPressのプラグインは、有効化すると**システム側が勝手に決めた固定のHTML構造（勝手にタグを挟み込んでくるなど）を出力**します。 エンジニアは、その「プラグインが勝手に出した汚いHTML構造」に対して後からCSSを当てるしかありません。デザイナーが理想とする「入れ子関係（親子関係）」のHTMLになっていないため、CSSの仕様上、どうしてもそのデザインを再現できない（あるいはJavaScriptでHTMLを無理やり書き換えるような力技が必要になる）という事態が起こります。

ケース③：ブロックエディタ（Gutenberg）の出力する「余計な入れ子（div）」

WordPressの管理画面で、Webサイトの担当者が「画像とテキスト」を自由に配置できるようにする場合、現在は「ブロック（Gutenberg）」という機能を使います。 デザイナーが「ここの画像と文字は、スマホの時はこう重なって、PCの時は1pxの隙間もなく綺麗に全画面に広がる」という緻密なレイアウトをデザインしたとします。

WordPressの仕様上の無理

WordPressのブロック機能は、裏側で`wp-block-image`や`wp-block-columns`といった、**WordPress独自の複雑な「divタグの入れ子（階層）」を自動的に大量生成**します。 この「WordPressが強制的に出力するdivの階層」が邪魔をして、デザイナーが意図した通りのシンプルなCSS（FlexboxやCSS Gridなど）が素直に効きません。結果として、「WordPressが勝手に作るdivのせいで、端に謎の隙間が空いてしまう」「これ以上外側の枠を動かせない」といった限界にぶつかります。

ヘッドレスCMSならどうなるか？

ヘッドレスCMS（microCMSなど）の場合、CMSから届くのは純粋な「データ（JSON）」だけです。 エンジニアの手元には、邪魔をする自動生成HTML（WordPress独自のタグやプラグインのタグ）が**1ミリも存在しません。** そのため、ケース①の「3番目にバナーを挟む」のも、ケース②の「フォームの自由なレイアウト」も、エンジニアがFigmaのデザイン通りに**完全ゼロベースで綺麗なHTML構造を組み立て、そこにデータを流し込むだけ**で済みます。 これが、エンジニアが「HTMLの構造を自由にコントロールできるから、どんなデザインでも再現できる（＝デザインが自由）」と言う本質的な理由です。
確かに、そう言われてみれば、②についてはとても納得感がある話です。 ですので、

WPでの開発では、プラグインを利用するのが一般的で、無料のCMSで、無料のプラグインを利用するような流れになる。

プラグインの出力内容は、たとえエンジニアであっても改変不能になるので、先ほどのカードの件などが分かりやすい例として、自由にデザインできないに繋がっているという理解で良いか？

逆説的に、ヘッドレスCMSでもプラグイン的なものを利用し、それに依存する場合、同じ問題（自由でなくなる）を抱えるとは言えないか？

と投げてみたところ、以下のような回答が得られました。

1. 前半：WPのプラグインと「デザインの不自由さ」について

プラグインの出力内容は、たとえエンジニアであっても改変不能になるので、先ほどのカードの件などが分かりやすい例として、自由にデザインできないに繋がっているという理解で良いか？

**完全にその理解で間違いありません。** 厳密にいえば、WPのプラグインのコード（PHPファイルなど）を直接書き換えてHTMLを変えることは技術的に不可能ではありません。しかし、それをやってしまうと「プラグインをアップデートした瞬間に、書き換えたコードがすべて上書きされて消える（あるいはサイトが真っ白になって壊れる）」という致命的なリスクを抱えます。 そのため、プロのエンジニアほど「プラグインが勝手に出力するHTMLには手を触れない（触れないからデザインが縛られる）」という選択をせざるを得なくなります。これが「自由にデザインできない」の正体です。

2. 後半：ヘッドレスCMSでも同じ問題（自由でなくなる）が起きるか？

逆説的に、ヘッドレスCMSでもプラグイン的なものを利用し、それに依存する場合、同じ問題（自由でなくなる）を抱えるとは言えないか？

結論から言うと、**「何をプラグイン（外部サービス）に依存するか」によって、その問題が起きるかどうかが分かれます。** 実はヘッドレスCMSの世界でも、WPのプラグインのように「お問い合わせフォーム」や「EC（買い物かご）」「コメント機能」などを、外部の専門サービス（専門のヘッドレスツール）を組み合わせて実装するのが一般的です。 ここで、**「見た目を縛られるか・縛られないか」の境界線**が生まれます。

① WPと同じように「デザインが不自由になる」ケース

ヘッドレスCMSを使ったサイトであっても、例えば以下のような外部サービスをそのまま導入すると、WPのプラグインと全く同じ「不自由」が発生します。
  • 例：海外の予約システムや、汎用的なお問い合わせフォームの埋め込み（iframe型や専用JS型）
  • 画面に「外部サービスが用意したデザインのボタンや入力欄」がそのまま表示されるタイプです。この場合、出力されるHTMLやデザインは外部サービス側が支配しているため、エンジニアであってもデザインを自由に変更することはできなくなります。

② ヘッドレスの強みを活かして「自由」を保てるケース（API型）

しかし、ヘッドレスCMSの文脈で使われる最新の外部ツール（例：フォーム専用の「Formspree」や、EC専用の「Shopify Headless」など）の多くは、「データや機能（API）だけを提供する」というスタンスをとっています。
  • WPのプラグイン： 「入力欄のHTML」と「送信する機能」をセットで提供する。
  • ヘッドレスの外部ツール： 「送信する機能（API）」だけを提供する。「入力欄のHTMLやデザイン」はエンジニアが100%自由に自作して良い。
この「機能だけを借りて、見た目はこっちで作る」という役割分担（API連携）ができるツールを選んでいる限りは、どれだけ外部サービスに依存しても、デザインの自由度が失われることはありません。

まとめ

お気づきの通り、「プラグインや外部ツールが【HTML（見た目の構造）】まで一緒に吐き出してくるタイプ」である場合、それがWPであろうがヘッドレスCMSであろうが、**デザインの自由度は死にます。** ヘッドレスCMSが自由だと言われるのは、周りに組み合わせるプラグイン（外部ツール）も含めて、「HTMLは吐き出さず、データ（API）だけをやり取りする高機能なツール」が前提の世界観で成り立っているから、というのが正確な答えになります。

振り返って

確かにページのデザイン・レイアウトを考案する中で、ここはプラグインの制約でこういう表現しか出来ないという指摘をエンジニアからされる場面がこれまでも幾度となくありました。 自分の場合、今回のプラグインの制約の例を通じて、長年モヤモヤしていた言葉の意味するところを具体的な場面と共に把握できるようになりました。 わたしが関わる案件でそこまでデザインに拘る案件は実際のところは、ほぼありません。 ですが、企業がAIエージェントを利用する前提となった場合、MCPサーバ接続、API接続といった活用方法の普及と共に、BtoBのウェブサイト構築・運用が大きな変革期を迎えるのは明白です。 このような流れにおいて、ヘッドレスCMSやAPI接続可能なCMSを選択するのはとても合理的な判断だと考えます。 これから行う幾つもの商談の中できっと何回もヘッドレスCMSについて説明することになると思うのですが、「ヘッドレスCMSはデザインが自由」という具体例を確立できたのは自分にとってはとてもおおきな出来事でした。 ヘッドレスCMSの導入支援 Movable Type のAPI活用支援をスタートさせました。ご興味ある方はお気軽にお問合せください。

アペンディクス

（上記回答を他のエージェントで事実確認した結果も置いときます）

ファクトチェックレポート　主張の分解

  1. ヘッドレスCMSの仕様：ヘッドレスCMSはAPIを通じてデータのみを出力し、フロントエンド側（CSSなど）で完全にコントロール可能である。
  2. WordPressの仕様：WordPressでは、特にプラグイン利用時などにCSS込みでHTMLソースがアウトプットされることがある。
  3. デザイン上の制約：このようなWordPressの仕様が、フロントエンド開発におけるデザイン上の制約として語られることが多かった。

主張の検証

検証1：ヘッドレスCMSはAPIを通じてデータのみを出力し、完全にコントロール可能か

証拠分析： | 支持/反驳 | 重要な情報 | 信頼性 | |---|---|---| | 支持 | ヘッドレスCMSは「ビュー（見た目）」を持たず、バックエンド（コンテンツ管理）とフロントエンド（表示）が完全に分離（デカップリング）されたアーキテクチャを持ちます。コンテンツはAPI経由で純粋なデータ（JSONなど）として提供されるため、開発者は任意のフレームワークやCSSを用いて、技術的・デザイン的な制約を受けることなく自由にフロントエンドを構築できます[3][6][12]。 | 高 |

要約： ヘッドレスCMSはデータソースのみをAPIで提供し、表示側の制御をフロントエンドに完全に委ねる仕様であるという理解は正確です。

検証2：WordPressはプラグイン利用時などにCSS込みでソースが出力されるか

証拠分析： | 支持/反驳 | 重要な情報 | 信頼性 | |---|---|---| | 支持 | WordPressはフロントエンドとバックエンドが一体化した従来型CMSです。特にプラグインを導入した場合、そのプラグインを機能・表示させるための独自のCSSファイルやJavaScriptが自動的にHTMLの<head>内などに挿入（出力）される仕様になっています[4][8][13]。 | 高 |

要約： WordPressのプラグインが独自のCSSやスクリプトを含んだ状態でソースを出力するという理解は事実です。

検証3：この仕様がデザイン上の制約として語られることが多いか

証拠分析： | 支持/反驳 | 重要な情報 | 信頼性 | |---|---|---| | 支持 | WordPressで独自のデザインを実装しようとする際、プラグインが強制的に出力するデフォルトのCSSが干渉し、デザインが崩れたり、CSSを「上書き（!importantの多用など）」したりする手間が発生します。また、不要なコードが読み込まれることでパフォーマンスにも悪影響を及ぼすため、これがフロントエンド開発者にとって「デザインや自由度の制約」として広く認識・議論されています[1][3][6][9]。 | 高 |

要約： WordPressの密結合な仕様やプラグインによるCSSの強制出力が、デザインおよびフロントエンド開発の制約として語られてきたという認識は正確です。

検証結果

| 主張 | ステータス | 主要な証拠 | 信頼性 | |---|---|---|---| | ヘッドレスCMSとWordPressの出力仕様の違い、およびそれがデザイン上の制約として語られてきたという理解 | 正確 | ヘッドレスCMSはAPIでデータのみを返しフロントエンドの自由度が高い一方、WordPressはプラグイン等が独自のCSSを出力するため、デザインカスタマイズの障壁（制約）になることがWeb開発の現場で広く認識されている。 | 高 |

全体評価

あなたの理解に事実誤認は一切ありません。完全に正確です。

Web開発の文脈において、WordPress（従来型CMS）は「手軽に機能を追加できる」というメリットがある反面、プラグインが独自のCSSやDOM構造を強制的に出力するため、デザイナーやフロントエンドエンジニアが意図した通りのピクセルパーフェクトなデザインを実装しようとすると、それらのコードを打ち消す（上書きする）作業が必要になり、大きな制約となっていました。

これに対する解決策として、純粋なデータのみをAPIで渡し、見た目の構築（HTML/CSS/JS）の主導権をフロントエンド側に完全に取り戻すことができる「ヘッドレスCMS」が台頭し、高く評価されているというのが現在のWeb技術の正確なトレンドです。 [1] https://www.reddit.com/r/Wordpress/comments/1cu5grf/experiencedwithhtmlcssbutnewtowordpressand/?tl=ja [2] https://www.novadb.com/en/blog/headless-cms-vs-wordpress [3] https://blog.microcms.io/what-is-headlesscms/ [4] https://www.rk-k.com/archives/8062 [5] https://www.thepublive.com/feeds/blog/headless-cms-vs-wordpress [6] https://sinap.jp/blog/what-is-microcms [7] https://lolipop.jp/media/wordpress-css/ [8] https://www.reddit.com/r/Wordpress/comments/16t8vtf/cansomeoneexplaintomewhatheadlesswordpress/ [9] https://wakka-inc.com/blog/1947/ [10] https://labelog.net/post/637 [11] https://strapi.io/blog/headless-cms-vs-headless-word-press [12] https://www.nilto.com/ja/knowledge/posts/understanding-headless-cms/ [13] https://tart.co.jp/wordpress-css-edit-best/ [14] https://www.cosmicjs.com/blog/headless-cms-vs-wordpress-which-one-should-you-use-in-2026 [15] https://gini.co.jp/blog/what-is-headlesscms

佐々木 康彦 2026/07/12 07:09:49 Comment(0)