プロダクト開発部アプリケーションエンジニアの有末と申します。
現在、「Reader Store（運営：株式会社ソニー・ミュージックエンタテインメント）」のシステム開発を主な業務として日々取り組んでいます。
Reader Storeでは段階的なサイトリニューアルを進行中です。一部のコンテンツ管理にCMSを利用していますが、リニューアルに伴いCMSの切り替えも行うこととなりました。そこで従来一般的だったフロントエンド一体型のCMS（以降、"従来型CMS"と呼びます。）ではなくheadlessCMSを導入することに。製品はSaaSとして提供されているmicroCMSを利用しました。
本記事では、headlessCMSの導入をした中で感じたことを中心にお伝えしていきます。現在CMSを利用している方や利用を検討している方の参考になれば幸いです。
headlessCMSとは
CMS(Contents Management System)とはWebサイトの構成要素（＝コンテンツ。具体的には画像、テキストなど）を管理・配信するシステムを指します。headlessCMSはその中の一種です。バックエンドの機能のみ提供しAPIでコンテンツを配信するCMSをheadlessCMSと呼びます。
パッケージとして提供されている"従来型CMS"と"headlessCMS"、スクラッチ開発するCMSを比較すると以下のようになります。
| 従来型CMS | headlessCMS | スクラッチ | |
|---|---|---|---|
| 概要 | コンテンツデータ、管理画面、Webサイトと総合的な機能を提供する。 | コンテンツデータ管理といったバックエンドに特化。Webサイト自体の機能は持たない | 0から開発をする |
| 開発コスト | 低い | バックエンド：低い フロントエンド：高い |
高い |
| 自由度 | 低い | バックエンド：低い フロントエンド：高い |
高い |
| サービス例 | WordPress Movable Type |
contentful microCMS |
- |
バックエンド・フロントエンドともに提供される従来型では、提供される範囲内では開発に時間をかけずサイトを提供できます。ただし、パッケージの提供範囲外のことを実現しようとするのは難しいです。
スクラッチ開発は全て自分たちの要件に合わせてバックエンド・フロントエンドともに提供できますが、その全てを開発しなければならないため、開発コストは高くなリます。
バックエンドのみを提供しているheadlessCMSでは、バックエンドの開発は提供されている機能で作成をするため、自由度は低いですが開発コストも低いです。フロントエンドはスクラッチ同様、要件に合わせて自由に開発が可能です。裏を返すと、フロントエンドやビューワーは自分たちで用意をしなければなりません。
もちろん一長一短あるので手放しにheadlessCMSが良い、とは言えません。しかし、スクラッチと従来型CMSの良いとこ取りをしたCMSと言えます。Reader Storeでは、バックエンドで独自機能を提供する必要性は薄く、お客さまに提供するフロントエンドへ集中したい、という意図もありheadlessCMSを選択しました。
headlessCMSを使って開発してみた
実際にサイトの1機能であるお知らせ機能をリニューアルした時のおおまかな開発の流れが以下です。
- PM・デザイナーからの要件受領
- 要件をもとにフロントエンドへ渡す項目を決定
- headlessCMSで項目を設定
- APIが出るので想定通りかテストを実施
- APIを利用してフロントエンドを開発
この工程の中でheadlessCMSを導入したことで特筆したいのは2点です。
バックエンドの開発工数の圧縮
まず特筆すべきは項番3"headlessCMSで項目を設定"の工程です。
今回お知らせ機能を作る際に必要なものは"お知らせを入稿する管理画面"と"画面を出すために利用するAPI"でした。これらを作る際に、項番3で行ったことといえば、"2で決まった項目を、画面から設定していく"ことのみです。実際にはCMS上で設定をした後に、"運用は回るのか"、 "フロントで要件を満たしているのか"などの調整をしていたためやりとりや修正の時間は数日かかっています。しかし、その叩き台となるドラフト版を作るだけなら1～2時間もあれば作成は完了していました。
もしスクラッチで開発をしようとしていた場合はどうだったでしょうか。 headlessCMSで必要だったものは"お知らせを入稿する管理画面"と"画面を出すために利用するAPI"でした。スクラッチであればさらにデータを保管するDBの設計なども必要になります。これらを自前で開発しようとした場合、1～2時間ではとても収まらなかったはずです。
短期間で管理画面がすぐ見える形になると、運用部門と実際の画面を見ながらブラッシュアップできます。フロントエンドとの疎通も前倒しにでき、開発時にも実際のAPIで検証しながら開発を進めることができます。この提供スピードが一番のメリットであると感じました。
フロントエンド開発の柔軟性
項番5"APIを利用してフロントエンドを開発"の工程においてもメリットを発揮しました。
段階的にリニューアルを進めているReader Storeでは、既存のCMSで提供している箇所が多くあります。2023年時点でリニューアルを完了していないページでも、今回移行をした"お知らせ"を出している箇所がありました。
もしも従来型のCMSでリニューアルをしていた場合、従来型のCMSではフロントのページは丸々1ページ分、CMSから直接出されているものになります。部分的な対応をしようとするとiframeで埋め込むといった手法をとる形になります。後々リニューアルするページなので作った埋め込みページは丸々破棄になるか、拡張できるよう対処することになるか、いずれにせよのちのリニューアルに向けては検討が必要になっていそうです。
一方で、headlessCMSではAPIを出すのみなので、既存のページで出しているお知らせの箇所を従来の出し方からAPIの呼び先をheadlessCMSにすることで部分的な対応を実現しました。既存ページの改修は必要ですが、APIはリニューアル後も利用できますし、コストや無駄は従来型と比べ低いものになったはずです。
こうした段階的なリニューアルにおいても、headlessCMSではスムーズな移行に寄与しています。
使って感じた点
先述の通り、2点のメリットをheadlessCMSを用いることで実感できました。
- バックエンドの提供スピード
- フロントエンド開発の柔軟性
それ以外にもSaaS型のheadlessCMSを利用する中で実感したことがありましたのでご紹介します。
コンテンツ登録や公開日、バージョンなどの管理機能開発が基本不要
CMSにおいて必要な機能ですが、自前で開発をしようとすると大変な機能です。こちらが元から提供されていることで開発の必要がなかったのは非常に助かりました。
一方で、提供されている標準機能では足りない機能が要件としてある場合は実装に考慮が必要です。
Reader Storeでは未来に公開する記事を、プレビューの日時を指定し、その特定日時に想定した記事で公開されていることを確認したい、という要望がありました。ECサイトであるReader Storeにとって、未公開情報や商品の販売日などを考慮した日時指定プレビュー機能は重要なニーズです。microCMSには標準で下書きプレビュー機能がありますが、この要望を実現するには不十分でした。そのため、CMS側ではなくアプリケーション側の実装で対応することになりました。
このように、標準で提供されている機能から外れると何かしらの考慮が必要になってきますが、microCMSの標準として提供されている機能の範囲であれば、容易に利用ができています。プレビュー機能も標準的な導入は、各フレームワークごとにドキュメントが整理されており容易でした。
内部で管理するインフラを縮小
SaaS型のheadlessCMSを利用することで、インフラ側のOS、利用モジュールのEOLやセキュリティ対応がCMSサービス提供側の責務になります。これにより、自社でメンテナンス対象とするインフラの範囲を現在よりも縮小できました。
今回利用したmicroCMSは開発用ステージング環境を作成する機能を提供していました。本番環境をベースに迅速に別の環境を用意できます。各環境に対して接続IPなどを個別に設定できるため、本番用と開発用を簡単に作成できました。
しかし、サービス提供型のCMSであるため、提供側のインフラに関する制約も考慮する必要があります。例えば、秒間リクエスト数に制限があり、キャッシュからのリクエストには制限がないといった点です。この制限により、クエリに日時を指定した場合にmicroCMSのCDN（CloudFront）のキャッシュがヒットしにくいという事象が発生しました。キャッシュのヒット率を高めるために、指定する日時の秒・ミリ秒単位を切り捨てるといった実装上の工夫をしました。
管理画面上の細かいカスタマイズはフルカスタムに比べ劣る
提供されている機能で実現をする必要があったので、制限されることや別の箇所で回避しなければいけないことがありました。運用部門に強いこだわりがあり、管理画面のカスタマイズが必須要件の場合、フィットはしなかったです。 以下は一例です。
複数項目でのバリデーションができなかった
日時の開始日・終了日を設定するなど、複数項目間でのチェックをしたい場合、スクラッチであれば開始日<=終了日でなければ入力を弾くなどのバリデーションをかけるところでした。しかし、そういった機能の提供はなかったため、管理画面上に注釈を残して運用部門に注意を促し、フロントエンドの表示ロジックにて制御しました。
直接htmlを打ち込めない
テキストエリアにWYSIWYGエディターを提供されていたのですが、WYSIWYGエディター内でhtmlを直接打ち込む機能は提供されていませんでした。シンプルなページを作成する場合は問題ないのですが、特定のページをよりリッチに作成したい、といった要望が簡単には実現できないです。
さいごに
リニューアルに伴いSaaS型headlessCMSを使い始めることになりましたが、一般的に言われるメリット・デメリットは実感できました。それらを踏まえて、開発チームがフロント開発に注力できるチームであれば、CMSを導入する際の選択肢としてheadlessCMSは良い選択肢と言えます。本稿でそれらの感じたことをお伝えできていれば幸いです。
ここまで読んでいただきありがとうございました。
