ヘッドレスCMSとは？

コンテンツを表示する画面「ビュー」が無いCMS

ヘッドレスの「ヘッド」は、ビュー（表示する画面）を指します。ヘッドレスなので、ビューの無いCMSということになります。ビューがないとは具体的にどのような意味でしょうか？

そもそもCMSとはContent Management Systemの略で、つまりはコンテンツ管理システムを指します。従来のCMSはコンテンツを入稿するシステムとコンテンツを表示するビューが合わさったものでした。最も代表的な例としてはWordPressが挙げられます。また、はてなブログやQiita、NoteなどもCMSです。

CMSのビュー（見た目）には主に以下の三種類があります。

• サービス固有の画面（Qiita、Note、Mediumなど）
• テンプレートを選択できるもの（WordPress、はてなブログなど）
• 自由に作成可能なもの（WordPress）

※ はてなブログ等もCSSの範囲であれば自由に見た目を変更可能
※ WordPressはHTMLの骨組みから自由に作成可能

このビューに当たる部分が無いのがヘッドレスCMSです。

「ビュー」はCMS外で自作する必要がある

ヘッドレスCMSの場合、ビューはCMS外で自作する必要があります。ヘッドレスCMSは入稿したコンテンツをAPIを経由して取得し、表示させたい場所に表示させます。
ここで、ヘッドレスCMSによってコンテンツの入稿システムとビューが切り離されていることのメリット・デメリットを考察してみましょう。

ヘッドレスCMSのメリット

マルチデバイスに対応できる

ヘッドレスCMSの紹介でよく言われることですが、コンテンツをWeb、iOSアプリ、Androidアプリなど複数のデバイスに表示することが可能です。

例えばアプリ内にWebと同様のお知らせを配信したい場合、現状では専用のWebViewを作りアプリ内に表示しているケースが多いです。WebViewは一部のケースでパフォーマンスが低下することがあるため、画面を表示するのに時間がかかりユーザーの行動を阻害します。スマホゲームをやっていて、「お知らせ」を表示するときだけ時間がかかり、不満を持った経験がある人は多いはずです。

ヘッドレスCMSを使う場合はAPI経由でコンテンツを取得できるので、アプリのネイティブ機能でコンテンツを表示することができます。これにより画面表示でユーザーを無駄に待たせることは最小限に抑えられるでしょう。

サイトを部分的にCMS化できる

厳密にはCMS化とは言えないかもしれませんが、概念を伝えるためにあえてこの表現を使用しています。

通常、サイトの一部分のみに入稿機能をつけたいと思っても、それを実装するのはなかなか骨が折れる工数になります。例えば、会社のホームページをHTML・CSSで静的ページとして作成していたとします。そこで後から「お知らせ」機能を追加し、マーケティング担当が自由に入稿できるようにして欲しいという要望があった場合、WordPressなどの従来型のCMSではサイト全体を作り直す必要があります。
しかしヘッドレスCMSを使えば、「お知らせ」部分のみをAPIから取得し、サイトに表示することができます。最小限の開発で部分的に入稿機能を付けることが可能というわけです。

ブログやお知らせなどに限らず、編集頻度が高いサイトトップの文言だったり、設定ファイル的なものを返すAPIとして利用することもできます。

フロントエンドの自由度が高まる

ヘッドレスCMSにはビューが無い ＝ フロントエンドと分離されていると言えます。そのためフロントエンドはシングルページアプリケーションやサーバサイドレンダリング、ネイティブアプリなど、多彩な選択肢を取ることができます。これにより、サイトのパフォーマンスも最大限に高められますし、デザインの自由度も高まります。

スキーマが完全に自由

基本的にCMSはメディア向けに作られているものがほとんどで、それ以外の形式のコンテンツの入出力に対しては最適化されていません。しかし、ヘッドレスCMSの場合は入稿フォーム自体をサービス上で作成します。入稿するものごとにリッチエディタや画像選択、URL入力フォームなど、最適なUIを用意することができます。

ヘッドレスCMSのデメリット

プレビュー表示の仕組みが複雑になる場合がある

例えばmicroCMSの下書き取得のためのパラメータのように、多くのヘッドレスCMSでは下書き情報を取得する機能自体は備わっています。一方でビューは完全に自作することから、こうしたパラメータをビュー側で受け取りプレビュー確認する方法を用意する必要があります。

（現在ではそのために必要な実装は数行で済む場合が多く一度実装してしまえば良いだけなので、エンジニアにとっても負担が少なくなる場合が多いです。）

エンジニアと非エンジニアが扱う難しさ

一定規模以上の会社の場合、コンテンツを入稿するのはエンジニアではありません。しかし、サイトを作る段階ではAPIのスキーマ設定などはエンジニアが行う必要があります。
エンジニアが触る部分とコンテンツ入稿者が触る部分が混在していて、非エンジニアにとっては「操作方法がよく分からない」となりがちです。

この点に関しては、各ヘッドレスCMSサービスがユーザーの使いやすさを向上させるためにさまざまな機能を提供しています。
ちなみにmicroCMSでは権限管理機能を使って非エンジニアの管理画面からエンジニア向けメニューを全て非表示にでき、シンプルな使い心地を実現しています。

技術的な学習コストが必要である

フロントエンドの自由度が高まるというメリットとの裏返しになってしまいますが、ヘッドレスCMSの導入にはある程度の技術的難易度が存在します。
例えばウェブでの利用であればAPI経由で取得できるデータを、サーバサイドならHTMLの構築・クライアントサイドならJavaScriptを使ったDOM構築などで利用する必要があります。

（一方でNext.jsやAstroといったモダンフレームワークを習得していると、ヘッドレスCMSをより効果的に扱うことができるでしょう。）

実際の導入例

それでは日本製のヘッドレスCMSであるmicroCMSを使って試してみましょう。

お知らせ欄をヘッドレスCMSに置き換える例を考えてみます。
お知らせなので、次のような情報が必要になります。

• タイトル
• 本文
• 投稿時刻

次に、これらの項目を入力するにはどんなフォームが適切なのかを考えてみましょう。

• タイトルはテキストフィールド（1行テキスト入力）
• 本文はテキストエリア（複数行のリッチエディタ）
• 投稿時刻はカレンダー選択

とすると、下記のような入力フォームが出来上がります。

この入力フォームに入力したデータはすぐさまAPIから取得することができます。
APIからは以下のようなレスポンスを得られます。

{
    "id": "4uhmyaezg",
    "createdAt": "2024-05-01T03:11:08.606Z",
    "updatedAt": "2024-05-01T03:11:08.606Z",
    "publishedAt": "2024-05-01T03:11:08.606Z",
    "revisedAt": "2024-05-01T03:11:08.606Z",
    "title": "タイトルのサンプル",
    "body": "<h1 id=\"ha879678dfe\">見出し1</h1><p>本文のサンプルです。</p><ul><li>リスト1</li><li>リスト2</li><li>リスト3</li></ul>",
    "image": {
        "url": "https://images.microcms-assets.io/assets/6fc32287866446db88a03cea77cf60cd/a43dc2861071496abcdd1e1231dbda53/what-is-headless-cms-ogp.png",
        "height": 630,
        "width": 1200
    }
}

このAPIをサーバサイドで呼び出し、HTMLを構築してクライアントに返しても良いですし、クライアントから呼び出してDOM操作をして表示しても良いでしょう。

まとめ

ヘッドレスCMSのイメージは掴めましたでしょうか？ここまでヘッドレスCMSとはビューの無いCMSであると説明してきましたが、入稿画面つきのAPI作成ツールと言った方がしっくり来るかもしれません。そう考えると使える幅もグッと広がりますよね。

気になった方は是非ヘッドレスCMSを試してみてください。（本ブログもmicroCMSで作られています）

▼ microCMSのサービス紹介資料
ヘッドレスCMSの特徴（メリット・デメリット）やご利用ニーズを解説した資料です。

▼ WordPress、Movable Typeとの比較資料
microCMS / WordPress / Movable Type の3つを比較した資料です。 使いやすさ、拡張性、外部サービスとの連携、セキュリティ、サポート、運用保守コストの6点で比較しています。