ヘッドレスCMSがマッチするケース、マッチしないケース

2023/02/16

松田承一

ヘッドレスCMSという言葉をご存知でしょうか？
まず、CMSとはContent Management Systemの略でありウェブサイトのニュースや記事などを管理することの多いシステムです。代表的な製品としてWordPressがあげられます。
次に「ヘッドレス」ですがこれは「見た目を有していない」という意味です。
まとめるとヘッドレスCMSとは、WordPressなどの従来のCMSとは異なり、表示部分をなくしてAPIベースでコンテンツを取得することが特徴のコンテンツ管理システムです。
ヘッドレスCMSに関する詳しい解説は下記記事をご覧ください。

参考：今話題の「ヘッドレスCMS」とは？ Jamstack、マルチデバイスにも対応したCMSの新潮流
※弊社COOの寄稿記事です

このヘッドレスCMSは従来とは異なる仕組みであるため、向いているケース・向いていないケースが顕著に存在しています。
我々株式会社microCMSは日本最大規模のヘッドレスCMS「microCMS」を開発・運用しています。
そのためヘッドレスCMSの導入に関する知見が数多く得られているため本記事にてまとめてご紹介いたします。

ヘッドレスCMSが向いているケース

まずはヘッドレスCMSが向いているケースです。
これには大きく2つがあげられます。

利用する技術が決まっていて変えられない
ITをビジネスの拡大に活用する意図がある

1つずつ詳しい解説をしていきます。

1. 利用する技術が決まっていて変えられない

まずは技術的制約の中でこそヘッドレスCMSはおおいに活躍できますよ、というお話です。
インフラや表示部分など様々なレイヤーにおいて利用する技術が確定している案件が世の中には数多く存在しています。
実例として、弊社でよくいただく状況をいくつかご紹介します。

既存のウェブサイトにコンテンツを差し込みたい
Webアプリケーションで全ユーザーに出す「お知らせ」を用意したい
サーバー環境が指定されており、そこにしかウェブサイトをデプロイできない

それぞれについて更に掘り下げていきましょう。

既存のウェブサイトにコンテンツを差し込みたい

既にウェブサイトを運用していて、後からコンテンツの追加が必要になるケースです。
例えばコーポレートサイトにおける「採用のための社員インタビュー」「会社にとってのイチオシ情報を掲載するリリース欄」などがあるでしょう。

既にWordPressなど何らかのCMSが導入済みであればCMSを拡張して解決するのが低コストに済む解決策です。
※後述しますが、事業の拡大を考えるとこれが適切ではないシチュエーションも多数存在します

一方で、CMSが導入されておらず、いわゆる素のHTML/CSS/JavaScriptやRuby on Railsなどなんらかのウェブフレームワークによるフルスクラッチ実装だった場合はどうでしょうか？
仮にヘッドレスCMSを使わない場合は、入稿用の新たなサブシステムを作るか、「変更がある度にコードを変更できるエンジニアに依頼を出して修正する」という業務フローが必要になるでしょう。
前者では数ヶ月に渡る初期開発コスト、後者ではウェブサイトの編集の度にエンジニアに依頼するため数時間〜数日の待ち時間や貴重なエンジニアリソースを費やしてしまいます。

ここにヘッドレスCMSを導入すると状況は大きく改善します。
初期開発はフロントエンド部分だけで済み、早ければ数時間から長くても数日程度で新しいコンテンツを差し込む準備ができるでしょう。
入稿作業などは編集者やライターの方のみで完結できるため、エンジニアのリソースを借りる必要もなく、数分程度で新たなコンテンツを投稿できるでしょう。
ヘッドレスCMSの特性の一つであるどんな技術構成でも部分的にCMS化することができることを活用できるシチュエーションとなります。

microCMS事例：【小田急電鉄株式会社様】急なリモートワークの救世主に！Webの施策スピードも約3倍にUP

「CMSが入っていないが部分的に入稿可能にしたい」といった声が聞こえてきた場合はこの節の条件に当てはまりますので、ぜひヘッドレスCMSをご検討ください。

ウェブアプリケーションで社内用の管理画面を用意したい

次にウェブアプリケーションにおけるヘッドレスCMSについてです。
この記事内でのウェブアプリケーションの定義は、「ユーザーがログインでき、何らかのデータの投稿や閲覧行うシステム」とします。
先ほどと異なる点は対象が「ウェブサイト」なのか「ウェブアプリケーション」なのか、という点です。

ウェブアプリケーションの場合、システムの構成はウェブサイトとは比べるとはるかに複雑です。
ユーザー個別のデータを管理するデータベースや認証エンジン、ファイルストレージ、サーバーサイドロジックなど多くのシステムコンポーネントを持ちます。
こういったシステムで忘れてはいけないのが、メンテナンス情報やキャンペーン情報など「利用社全体」に情報を提供をする機会がほぼ必ずあることでしょう。

このような場合に「個人別データの管理を行う社内向け管理画面にキャンペーンなどの仕組みも自作する」といった選択肢を取りがちです。
アプリケーション開発と同様の範囲と考え、「ついで」にエンジニアの工数で社内向けの管理画面開発を進めてしまいます。

ですが率直に言ってこの選択はあまり良くないことがほとんどでしょう。
最初は良くてもアプリケーションそのものの開発ではないためメンテナンスがおろそかになって負債化していくことが多いことや、例えば最初はシンプルだった「キャンペーン」に画像表示が追加されたり、「注意事項」のような新たなコンテンツが後から追加される可能性も大きいためです。
こうした要求に全てエンジニアが答えているとリソースがいくらあっても足りません。

そこで登場するのがヘッドレスCMSです。
ウェブサイトの場合と同様に、ヘッドレスCMSであれば任意の箇所にコンテンツを差し込むことができ、管理画面の開発はmicroCMSのようなSaaSサービスが担います。
また、マーケターなどの入稿者はヘッドレスCMSの画面のみを触ってユーザーに情報提供が可能です。
要件の追加や変更時にもAPI構成を即座に変更できるヘッドレスCMSの特徴が活かされ、開発工数も大きく削減可能です。
今回紹介したような全体向けの案内コンテンツであればヘッドレスCMSであれば低コストで導入可能・運用も簡単&安い・仕様拡張も行いやすい、と良い条件の中でアプリケーション運用が可能となるでしょう。

microCMS事例：【SmartHR様】文言修正にかかる工数が1/10に！非エンジニアだけで修正できる仕組み作りに成功


※ちなみにmicroCMSの管理画面内に表示している「お知らせ」などもmicroCMS自身で管理しており、この部分を社内のエンジニアが普段直接触ることはありません。
※管理画面のもう一つの役割として「個別データの確認（読み取り）や調整（書き込み）」がありますが、こちらの場合もRetoolなどを使うことでエンジニア工数をほとんど割かずにデータ管理画面を用意が可能です。

顧客のサーバー環境が指定されており、そこにしかウェブサイトをデプロイできない

次のケースとして、特に大企業に多い事例として「サイトの公開環境が決まっている」ことがあります。
具体的には制作案件でクライアント企業側のオンプレミスサーバーやAWS S3・EC2が用意されていたり、FTPへのアップロードなどもあります。
（モダンな考え方であればVercelやNetlifyなどを利用したいところですが、こうした案件でこれらの新興サービスを選定するのは非常に難しいでしょう。）

このような場合にエンジニアが取る戦略は「静的サイト化」（Static Site Generate = SSG）であることが多いでしょう。
あらかじめコード群をビルドしておき、成果物であるウェブサイトを特定の箇所にアップロードすればサイト公開できるため、これを利用してサイト公開を行います。

SSGのような考え方を実践するモダンなウェブフレームワークは数多く存在します。
Next.jsやNuxt.js、Gatsby、最近ではAstro.jsなどもよく耳にするのではないでしょうか。
これらのフレームワークを使うと「サイト開発 → GitHub Actions等で自動ビルド → ビルドの成果物であるファイル群をアップロード」といった公開までの流れが考えられますが、これはサイトの公開環境の制約とエンジニアの開発体験のバランスを取れる良い方法となるでしょう。
静的サイトといえば従来はMovable Typeなども広く普及していましたが、Jamstackによってより進化を見せており技術の螺旋階段を一周回った状況になったと考えると良いと思います。

参考リンク

Jamstackとは何か？まずは基本を理解しよう！ ※SSGを中心とした狭義のJamstackを解説しています
AstroとmicroCMSでつくるブログサイト

こうした状況下でデータの入稿元として便利に使えるのがやはりヘッドレスCMSです。
フレームワークはあくまでウェブサイトを作ることに特化しており、コンテンツの運用に関する機能はほとんどありません。
こうした不足部分をヘッドレスCMSが補い、ウェブサイトに欠かせないコンテンツ運用をスムーズに行うことができます。

さて、ここまでで「技術的制約によるヘッドレスCMSの活用シーン」をご紹介してきました。
次は未来を見据えた状況下でのヘッドレスCMSの選定です。

2. ITをビジネスの拡大に活用する意図がある（マルチデバイスへの対応）

ウェブサイトやモバイルアプリなどのIT領域は現代において顧客とのコミュニケーションを行うための重要なチャネルの一つです。
例えばmicroCMSのある顧客は日本最大級の美容メディアを取り扱っていますが、このメディアコンテンツを美容室予約も可能なモバイルアプリ内にも表示し、予約の後押しを行うことで事業の成長を計画しています。
またある企業では、店舗や商品に関する情報をウェブサイトだけに配信していましたが、同様の情報を街や駅内のディスプレイでも表示することで来店客数・商品販売数の拡大を目論んでいます。

このように、ITが事業成長の重要なポジションを担う場合、そこに掲載されるコンテンツもまた非常に重要なものとなります。
こうしたニーズに対してヘッドレスCMSであればコンテンツは1箇所で管理・運用され、それをあらゆるサイトやデバイスから利用可能です。
コンテンツ運用戦略を確立したままITによる拡散を行うことで事業の拡大を計画することができます。またそこまでいかずとも、その前段階となる様々な検証をもスピーディに実現できます。

このように、ヘッドレスCMSを活用すると事業の将来展開が考えやすくなる利点が得られることでしょう。

ヘッドレスCMSが向いていないケース

一方でヘッドレスCMSが向いていないケースも当然あります。
一言で言うと「費用をとにかく安く抑えたい場合」です。

ヘッドレスCMSを導入する場合、APIというエンジニアが扱う技術に触れる必要があるため、初期導入においては技術に明るいエンジニアの存在が必須です。
また、運用を進めていく中でもコンテンツ構造の変化などがあった場合にはエンジニアの力を借りることとなり、そこでも費用や工数が発生します。
そのため初期費用、運用費用ともに月額数百円〜3,000円程度で済むレンタルサーバーでのWordPress運用などと比較するとコストは高くなるでしょう。
こうした特性上、「運用人件費をほぼゼロにしたい」といった費用の要件が最も重要である場合、ヘッドレスCMSを選定するべきではないでしょう。

こうした条件を満たす条件として、期間限定サイトであること、フロントエンド開発者をプロジェクトに全く割り当てないこと、などがあげられます。
これ以外に関しては技術的制約や事業の成長の観点を考慮し、ヘッドレスCMSを検討してみることもおすすめです。

なお費用第一ということでWordPressを選定することもありますが、セキュリティや各種ソフトウェアバージョンなど中長期的なメンテナンスが疎かになるケースも非常に多く見かけます。
これは不正ログインなどの危険性を招くことにもなりかねません。
メンテナンス費用・工数も捻出できない状況下ではWordPressも本来は選定すべきではないでしょう。
我々としては極力メンテナンスフリーかつ安い費用でウェブサイトを運用したい場合はSTUDIOやWixなどウェブサイトビルダーがおすすめしております。

従来のCMSからヘッドレスCMSに移行すべきか？
さて、ここまででヘッドレスCMSの導入に向いているケース、向いていないケースを整理していきました。
では今、目の前にWordPressなどのCMSがあるとして、ヘッドレスCMSをベースとした構成に変えるべきでしょうか？
その際に考えるべきことを整理しましょう。

まずはじめに考えるべきは技術的興味だけでヘッドレスCMSの導入および刷新は行わないようにすることです。
コストが最重要である場合は不適切であったり、後任エンジニアがいない場合はヘッドレスCMSやフロントエンドがメンテナンスできない状態になってしまい、デメリットが目立つ結果となってしまうでしょう。
※上記は案件導入に関する話題ですが、ヘッドレスCMS自体は昨今の企業の成長戦略と切り離せない以上、一度は触れておくことを強くオススメしております。

次に、目の前の課題が技術的制約が存在しているか、あるいはコンテンツを事業拡大に貢献させたいかを考えましょう。
いずれかに当てはまる場合、ヘッドレスCMSの特性はよく合うと考えられます。前向きな検討をしてみましょう。

一方で要件の広がりはほとんどなく、価格やメンテナンスコストを下げることだけを重視するのであればフルマネージドなウェブサイトビルダーであるSTUDIOやWixがオススメです。
これらであればサイトの用意にプログラミングスキルは要さず、セキュリティや各種ソフトウェアバージョンの更新についても基本的な責務はサービス側が担ってくれます。

WordPressのヘッドレス化はどうですか？

また、これらの間をとったような解決策である「WordPressのヘッドレスCMS化」も取り沙汰されることがあります。
しかし、我々microCMSとしてはこの方法はあまりオススメしていません。

WordPressにはサーバー提供をするwordpress.comとインストール型のwordpress.orgという2種類のサービス提供が存在しています。
ヘッドレスCMS化など比較的大きめのカスタマイズをする場合は wordpress.org を利用することになりますが、これにはサーバー管理という大きな仕事が付いてきてしまいます。
この仕事のほかにもWordPress本体やプラグインの更新などWordPress自体のメンテナンスにも多大なコストを払うことになるでしょう。

最近は安く済ませる＆メンテナンスも最小限なヘッドレスCMSの可能性も見えてきている

課題や事業の方向性をよく考えた上でヘッドレスCMSを選定するべきであり、かかる費用を抑えたいだけであれば選定はオススメしない、といったことをここまでで書いてきました。
一方で最近では費用を安く済ませたままヘッドレスCMSを導入し、エンジニアなしでも運用ができるという夢のような状態も作られつつあります。

その一例としてSTUDIOのmicroCMS連携機能があります。
待望のAPI連携機能が遂にリリース。 Notion、microCMSなどの外部サービスとの連携が可能に！

これはSTUDIOにおける新機能で、ヘッドレスCMSにおいて通常はエンジニアが作るべきだった見た目部分をNoCodeで作成できる素晴らしい機能です。
こういった機能を利用すれば、初期導入時も運用保守時もかなりコストをおさえた運用が可能です。さらにコンテンツをモバイルアプリなど更に多方面への展開を計画できるなど、将来を見越した状況を作っておくことができます。
上記機能は2022年11月1日時点ではベータ版リリースということですが、STUDIOに限らず各種のNoCodeツールがヘッドレスCMSとの繋ぎこみが実現していくことで、さらに安くかつ早く事業展開を目指していくことも可能でしょう。