ヘッドレスCMSとは何か、そして本当に必要になるのはいつか？
ヘッドレスCMSはコンテンツと表現を分離します——そして5ページのパンフレットサイトにとっては、それは誤った選択です。本当に報われるのはどんなときか、ここで解説します。
ヘッドレスCMSはコンテンツを保存し、それをAPI経由で提供します。ページのレンダリングは行いません。テーマもテンプレートもフロントエンドもありません——その部分はあなたが構築します。
定義はこれがすべてです。この記事の残りはすべて、それがあなたにとって良い取引かどうかについてのものであり、正直な答えの大部分は「フロントエンドをいくつ抱えているかによる」というものです。
「ヘッド」とはレンダリングを担う部分のこと
従来型のCMS——WordPress、Drupal、あなたがこれまで使ってきたものの大半——では、コンテンツの保存とページのレンダリングが同じシステムの中に同居しています。記事を書くと、CMSがそれをデータベースに格納し、同じCMSがテーマを使ってそれをHTMLに変換します。便利であり、そして分かちがたく結びついています。
「ヘッドレス」とは、そのレンダリングの側を取り除くことを意味します。残るのは次のものです。
- コンテンツタイプとそのフィールドを定義する場所
- 文章を書く人のためのエディター
- 構造化されたコンテンツを返すAPI——JSONであって、HTMLではない
この取引はきわめて明快です。無料のウェブサイトを失います。その代わりに、ウェブページの形をしていないコンテンツを手に入れ、そのおかげでウェブページではないものからも利用できるようになります。
ヘッドレスとデカップルドの違い
どちらの言葉も目にするでしょう。厳密には、デカップルド（分離型）CMSは利用するかどうかを選べるレンダリング層を依然として備えています。一方、ヘッドレスCMSにはそれがまったくありません。実務では両者は同じ意味で使われており、この区別が意思決定を左右することはめったにありません。
どの製品についても問う価値がある問いは、もっとシンプルです。そのページをレンダリングできるか？できるのであれば、それをヘッドレスとして使うということは、レンダラーを動かしたうえでその出力を無視するということです。
どんなときに報われるか
フロントエンドが複数ある。 ウェブサイト、iOSアプリ、キオスク端末、フィードを欲しがるパートナー。従来型のCMSでは、2つ目の利用者はスクレイピングの問題になります。ヘッドレスなら、それは2つ目のAPIクライアントにすぎません。
プロジェクトが複数ある。 10社のクライアントを抱えるエージェンシー、5つのブランドを持つグループ、顧客一人ひとりが自分専用のコンテンツを必要とするSaaS。ここが料金モデルの差が大きく開き始める場所です——プロジェクト単位、データセット単位、あるいはスペース単位で課金する製品もあり、3つ目のプロジェクトでそれを思い知ることになります。