コラム

ヘッドレスCMSとは？

 

ヘッドレスCMSの本質を一言で説明すると「管理画面から登録したデータを json 形式で配信できるAPI」ということになります。ただ、いきなりこの説明をしてもわかりにくいので順を追って説明していきます。

管理機能は従来のCMSと同じ

ヘッドレスCMSが目に見える機能として持っているのが、情報の登録・編集のための管理画面です。これは従来のどのCMSも持っているもので、インターフェイスの仕様は若干異なれど、予め情報入力のためのテンプレートを作成して記事や画像などを登録していくということでは、どんなCMSも変わりません。

情報の出力先を管理しない

ここで従来型のCMSであれば、先程の管理画面で登録したデータの出力先として、実際のWEBサイトのテンプレートもCMS内で作成、管理することになるのですが、ヘッドレスCMSの場合はこの出力先テンプレートを管理するということはありません。

ヘッドレスCMSに初めて触れるユーザーが戸惑うのがまさにこの部分なのです。
ヘッドレスCMSの本質は登録データ配信のAPIですので、配信したデータの出力先は別途用意する必要があります。これは、一見すると、最初から出力先テンプレートを用意してくれているCMSと比較してデメリットに感じるかもしれません。しかし、CMSが出力先テンプレートを管理しているかしていないかに関わらず、予め用意されたテンプレート以外を使いたい場合は出力先テンプレートの作り込みという作業は必ず発生しますし、テンプレート内にデータを出力するためのプログラムの記述も必ず必要です。従来型のCMSとヘッドレスCMSの差は、この作業をCMS内の仕様として行うか、それともCMSとは切り離された場所で行うか、ということになります。

実装コストの低さ

よくヘッドレスCMSは実装工数が高く、小規模なWEBサイトには向かないという記事を目にすることもありますが、実際はむしろその逆で、小規模なWEBサイトに最速でCMSを実装するにはヘッドレスCMSが最適です。

少し POSTEASE のPHPでの実装コードを見てみましょう。
POSTEASE のAPIに接続してニュース投稿を最新の10件取得するコードです。

<?php 

require_once '/postease/api/local.php';

$config = [
  'posttype' => 'news', 
  'limit' => 10,
  'orderby' => 'desc',
];

$posts = get_posts($config);

 

上記のわずかなコードで POSTEASE からデータが取得できます。あとは $posts にあるデータをHTMLにレンダリングするだけです。実際に POSTEASE をサーバにインストールするところから実装までに30分もかからないのを考えると、実装コストは非常に低いと言えます。

<?php foreach ($posts['list'] as $row):?>
<h3><?=$row['title']?></h3>
<time><?=$row['publish_date']?></time>
<img src="<?=$row['eyecatch']?>">
<?php endforeach?>

 

CMSのプラグイン

ヘッドレスCMSはAPIによる実装になりますので、多少のプログラミングの知識は必要です。全くプラグラミングの知識がない人が実装することは難しいですが、それは従来型のCMSであっても同じです。あらかじめすべての機能を用意してくれているように見えるCMSでも、要件に応じてカスタマイズしていくと必ずプログラムの知識は必要になります。そして、仕様が複雑になればなるほどCMSの仕様を紐解いて理解する必要が出てきますので、要件によっては予想外の工数がかかることもあります。
具体的にヘッドレスCMSの実装とは、WEBサイトからヘッドレスCMSのAPIにAjaxなどを利用して接続し、json 形式の情報を取得してHTMLとしてレンダリングする、ということになりますが、CMSの個別仕様に依存しない一般的な技術で実装ができますので、初めてヘッドレスCMSを実装する場合でもCMSごとの独自仕様の学習というムダな工数を削減することができます。抽象的に言うと、情報の箱にプラグを挿し、中の情報を取り出して利用するイメージです。実際の工数としては、たとえばWEBサイトのトップページに画像のスライダーを実装するのに jQuery のプラグインを使うことがあると思いますが、こういったプラグインを導入するのとほぼ同じです。ヘッドレスCMSは、WEBサイトをCMS化するためのプラグインと考えてもいいでしょう。

02 

保証された自由

従来のCMSはシステム内にユーザ画面としての出力テンプレートも含むということは既に説明しました。出力テンプレートがあらかじめ用意されているということは、導入してすぐにWEBサイトを公開できるというメリットもありますが、実際のビジネスユースではよほど予算が限られた場合でない限り、あらかじめ用意されたテンプレートを使うことはまずありません。実際にはクライアントの要望により１からテンプレートを作成していくことになります。そして、CMS全体の仕様や設定とユーザ画面は密接に関連しているため、個々のCMSの独自ルールに従ってユーザ画面を構築していくことになり、以下のような問題が出てきます。

  • コーディング担当者もある程度CMSの仕様を理解する必要がある（学習コストの問題）
  • 仕様やデザインがCMSの仕様によって制限されることがある（仕様制限の問題）
  • CMSの都合で勝手に無駄なHTMLが組まれる（構築整合性の問題）
  • サイト全体の不要なCMS化（パフォーマンスの問題）

ヘッドレスCMSはHTMLを生成するわけではありません。あくまでもデータを json などの生データとして配信し、ページごとの要件にしたがってHTMLのレンダリングをさせるだけですので、ユーザ画面側はCMSの仕様に縛られることは一切ありません。これは仕様やデザインにおいて完全な自由が確保された状態といえます。

部分的なCMS化

もうひとつ、従来型CMSの問題点として、サイト全体をCMS化してしまう、ということがあります。これはWEBサイトが完全にCMS側に依存していることになりますので、ちょっとした文言変更、スタイルの変更をしたいだけてもCMSの仕様によっては結構な手間がかかることもあります。また、特に動的なCMSの問題ですが、会社概要など、本来動的化が不要なページでも内部的には動的にレンダリングすることになり、静的なファイルの状態と比較して表示パフォーマンスで不利になります。さらに動的なCMSの場合、CMSが何らかの不具合を起こしてシステムにエラーが出てしまうと、出力先であるユーザ画面としてのWEBサイト全体が閲覧できない状態になってしまいます。

これに対して、ヘッドレスCMSであれば、ユーザ画面を管理しているわけではないので、文言やスタイルの変更で特に困ることはありません。動的化にしても、サイト全体ではなく、必要な部分だけ動的化できますので、そもそも動的化が不要なページは静的なままにしておいて表示パフォーマンスを保つこともできますし、最悪のケースとしてCMSがなんらかの理由で止まってしまっても、ユーザ画面側はCMSから配信されるデータが部分的に表示されなくなるだけで、サイト全体への影響を最小限にとどめることができます。

 

CMSの後付け

今まではWEBサイトにCMSを導入するためには、デザインを変更する必要がなくても実質的に「作り直し」になることがほとんどでした。これは従来のCMSがユーザ画面と密に結合しているためです。

しかし、プラグインのように導入できるヘッドレスCMSの場合は、今あるWEBサイトに後付けでCMSを導入することができます。たとえばトップページのお知らせだけを動的にしたい、といった場合、従来のCMSでは下手をすると作り直しになっていましたが、ヘッドレスCMSなら非常に簡単に、低コストで導入することができます。

 

CMSからDMSへ

従来のCMSがWEBサイトそのものを管理する“コンテンツマネジメントシステム”だったのに対して、ヘッドレスCMSはWEBサイトではなくデータを管理するDMS＝“データマネジメントシステム”という位置づけになります。今後、クロスプラットフォームで情報の２次利用が必須になりますので、時代は必然的にヘッドレスCMSを導入する流れになっていきます。

 

なぜヘッドレスCMSなのか？

 

戻る