ヘッドレスCMS、うちには向いてないと判断した話

「ヘッドレスCMSって結局何が良いんだっけ」

ふと素朴な疑問が浮かびました。
ちゃんと調べたことがなかったなと気づきました。

名前は前から知っていたし、microCMSやContentfulといったサービス名も見かけたことがありました。
でも実際にうちのブログに導入したら何が変わるのか、説明できるほどは分かっていませんでした。

なので今回は、仕組みを整理しながら、実際にうちのケースに当てはめて考えてみることにしました。

ヘッドレスCMSってそもそも何なのか
誰に向いているのか
逆に、うちには向いてなかった理由
技術の優劣じゃなくて、要件で決まる
まとめ

ヘッドレスCMSってそもそも何なのか

普通のCMS(WordPressもそうです)は、コンテンツの管理画面と、実際に表示する画面(テーマ)が一体になっています。

一方ヘッドレスCMSは、コンテンツを管理する「頭(ヘッド)のない」バックエンドだけを持っていて、表示側は完全に別で作ります。
コンテンツはAPI経由で取り出して、Next.jsのような別のフレームワークで自由に表示する、という構成です。

表示側が独立しているぶん、同じコンテンツをWebサイトだけじゃなくアプリやデジタルサイネージなど、複数の場所に配信しやすいのが最大の特徴だと分かりました。

💡 Tips: ヘッドレスCMSとは

コンテンツの管理機能だけを持ち、表示側(フロントエンド)を持たないCMSのことです。取り出したコンテンツをどう見せるかは、Next.jsなど別のフレームワークで自由に組み立てます。WordPressのように管理画面と見た目が一体になっている「従来型CMS」と対になる考え方です。

誰に向いているのか

調べていくと、向いているケースはかなりはっきりしていました。

いちばん分かりやすいのは、同じコンテンツを複数のチャネルに配信したいケースです。
Webサイトとアプリ、さらにデジタルサイネージの画面まで、同じ記事を一元管理して配信するような使い方です。

あとは、表示速度を極限まで詰めたい超大規模サイトにも向いています。
フロントエンドを完全に静的化してCDNで配信すれば、体感できるレベルで表示が速くなる規模のサイトです。

それから、チームにPHPよりJavaScript・Reactが得意なメンバーが多い場合も相性がいいはずです。
フロントエンドの技術選定を自由にできるので、使い慣れた道具で作れます。

実際に「headless CMS 比較」で検索すると、microCMS・Contentful・newtあたりが定番として挙がってきます。
いずれも管理画面はシンプルで、コンテンツをAPIとして配信することに特化している印象でした。

逆にデメリット側も調べてみると、フロントエンドを自分たちで作る前提になるぶん、初期の導入コストが高くなりやすいこと、プレビュー機能が従来型CMSほど直感的じゃないことが多いこと、といった点が挙げられていました。向いている企業の条件やデメリットは、こちらの解説記事でも整理されています。

逆に、うちには向いてなかった理由

ここまで調べて、じゃあうちはどうなんだろうと当てはめてみました。
4つの理由で、「今は要らない」という判断になりました。

1つ目は、配信するチャネルが1つしかないことです。
うちはブログサイト1本だけで、アプリもサイネージも予定がありません。
複数チャネル配信の旨みを、そもそも使う場面がありませんでした。

2つ目は、Cocoon(使っているWordPressテーマ)の資産を全部自作し直すことになる点です。
関連記事の表示、目次、SEO設定、セキュリティ対策。
今当たり前に使えているこれらの機能を、ヘッドレス化すると全部イチから実装し直すことになります。
さっき見つけたデメリット(導入コストの高さ)が、まさにここで効いてきます。

3つ目は、今の規模だと表示速度の差が体感できるレベルじゃないことです。
うちの月間ユーザー数は数十〜数百くらいで、正直なところ今のWordPress+レンタルサーバーの速度でも困っていません。

4つ目は、運用がむしろ複雑になることです。
今はXserver1本で、サーバー・DB・表示まで全部完結しています。
ヘッドレス化するとフロント用のホスティングが別に必要になって、管理する場所が増えてしまいます。

技術の優劣じゃなくて、要件で決まる

今回調べて分かったのは、ヘッドレスCMSが「優れている・劣っている」という話じゃないということでした。
複数チャネル配信・超大規模・JSチームという条件が揃ったときに輝く技術で、その条件がなければ、むしろ運用が複雑になるだけの選択肢になる、ということです。

うちの場合は、配信先が1つ、規模もまだ小さい、PHPベースの資産もある、という条件がことごとく「向いていない」側に当てはまっていました。

新しい技術を見るたびに「うちに合うか」を一度立ち止まって考える、というのは今後も続けていきたい習慣です。
以前検討したCloudflareのサーバーレスCMS(EmDash)を見送ったときも、派手なCSS演出を受託案件に入れるか判断したときも、軸はいつも同じでした。
「新しいから使う」ではなく「この案件に必要か」で決める、という考え方です。