- CMSテクニカル情報
writer / せんせー
ヘッドレスCMSとヘッドレスな運用ができるCMS考察
ここ数年、市場的には大きな盛り上がりを見せるヘッドレスCMSですが、いまのところ弊社の関わる案件ではあまりお目にかかっていません。
ただCMSで登録したデータをアプリとかECとか他のことにも使いたいというご要望はもちろんあって、じゃあそれ既存CMSのAPI使ってやるのと、ヘッドレスCMSに置き換えていくのとどっちがいいんだろうというのは多くの制作会社で抱えている懸案事項なんじゃないでしょうか。
今回は弊社でもよく使っている「MovableType」と国産ヘッドレスCMSの草分け「microCMS」を比較して考えてみたいと思います。
MovableType
https://www.sixapart.jp/movabletype/
microCMS
https://microcms.io/
ヘッドレスCMSとは：
おおざっぱに言うとhtmlを出力する機能がないCMSのことです。
利点としてはフロントエンドとバックエンドが分離しているので、出力形式にCMSの制約を受けないこと、開発に言語を選ばないことなどが挙げられます。
microCMSのいいところ
日本語対応
契約段階の資料から実際の管理画面UIまで完全に日本語対応なので、ユーザーにとっても安心できると思います。
製品によってはリッチテキストで日本語入力できないものとかもあるので、存外大きいポイントです。
サーバーレス
MovableTypeはPerlで動くので、ミドルウェアの準備とか意外とめんどくさいです。いざお客さまのサーバー室にインストールしに行ったら、すでに入ってるはずのモジュールが入ってないとか、権限がなくてMySQLにログインできないといったモヤモヤ問題がつきものですが、そういった環境問題から解放されます。
またCMSやOS自体の脆弱性対応とかもしなくてよくなるので、その分開発に注力できます。
※これらはMovableTypeでもクラウド版を使えば解消できるので、最近はソフトウェア版よりもクラウド版を選ぶケースが多くなっています。
ランニングコストが抑えられる
microCMSの場合API数3個、コンテンツ数10,000件までは無料です。
たとえば管理するコンテンツがお知らせやブログだけとかだったら、無料で運用することができることになります。
最下位の有償プランだと5,000円/月くらいで、API数が10個になるので、現実的にはここに当てはまる案件が多そうです。
※このAPI数というのはコンテンツのテーブルのことで、たとえば「コラム、カテゴリ、お知らせ、製品情報、採用情報」の入力を設計すると計5個になります。
テンプレートの開発工程がない
開発工程としてはhtmlが100%完成してからCMSへの組み込みがスタートするのが理想ですが、実際そんなことはほぼなくて、完成したページから五月雨で送られてきて随時組み込んでいくことは多いですよね。またあとから修正や仕様変更でhtmlが変わるので、テンプレートを作ってる最中や作り終わったあとにhtmlの修正箇所を確認して差分を反映していく作業が発生するのが常だと思います。
データとフロントエンドが分離されていれば、コーディングと並行してCMSの設定が進められ、しかも手戻りが発生しません。
またmtml（MTタグを使って実装されたテンプレートソース）とhtmlをそれぞれ管理する必要もなく、反映漏れの心配もありません。
単純に工数の削減にもなります。
サイト構成などにCMSの制約を受けない
MovableTypeは比較的柔軟に出力の設計ができるCMSですが、やはり仕様上「そのディレクトリにその一覧ページは作れない」みたいなケースは出てきます。
たとえばマルチブログを横断したカテゴリアーカイブはできないとか。コンテンツタイプのカテゴリに付加情報を設定できないとか。
どんなCMSでもページ構成やURL管理の方式によってどうしても一定の制約は出てくるものですが、microCMSで管理するのはコンテンツの内容やリレーションだけなので、そんな事情は関係なくなります。
再構築から解放される
再構築にやたら時間がかかったり、手動で全サイトの再構築が必要だったりするのはMTあるあるです。microCMSはデータを更新するだけなので基本的に管理画面内の操作が軽快です。
microCMSはNetlify、AWS Amplify、Github Actionsといったサービスへのウェブフックをサポートしているので、データを更新すると自動的にそれらのサービスでhtmlがビルドされ（るように作り）ます。
個人的には、Githubにリポジトリを置いて、データはmicroCMS、ホスティングはNetlifyというのが連携も簡単で開発もスムーズに感じました。
AWS Amplifyよく知らないですけど、S3にデプロイしたいときなんかはこれがハブになるんですかね。
MovableTypeにはこうしたフックはない（ですよね？）ので、ヘッドレスCMSとして使えます！と言い切ってしまうとちょっと違うかなぁという感じはします。
画像が動的変換できる
たとえば記事に画像を1枚登録すると、その画像パスにパラメータをつけてアクセスしたとき幅や高さを指定したサムネイルを生成して返してくれます。
ここはimgixを使っているらしく、生成された画像はCDNでキャッシュ配信されるので軽量・高速です。
ヘッドレスCMSとしては有名どころの「contentful」も画像加工＆キャッシュ配信をサポートしており、こういうところはやはり時流ですね。
MovableTypeにもサムネイルの生成機能はあるものの、負荷の高い処理なのであまり多用すると再構築に時間がかかります。単純なリサイズなので最適化ではないですし。
webp対応の手間なども考えると、パラメータつけるだけで色々変換してくれるのはとてもありがたいですね。
MovableTypeのいいところ
htmlを出力してくれる
CMSとしては当たり前の機能かもしれませんが、静的ファイルを吐き出してくれるのが最大の特長です。
完全にCMSサーバと公開サーバを分離できるのでわかりやすくセキュリティに強い。
そして公開サーバの要求スペックも低めにできます。
プレビューできる
これも当たり前といえばそうなんですが、ヘッドレスCMSの皆さんにはない機能です。
これといった設定をしなくても保存前の記事の見た目を確認できるというのは実はありがたかったんです。
ユーザー視点でいうと、登録したコンテンツがどう見えるかが重要で、特にコラムのような読み物だと必須ですよね。
※microCMSの場合はプレビューURLの設定はできるので、別途プレビューサイトを構築しておけばコンテンツ編集画面からプレビュー確認できるようなUIは用意されてます。
テンプレート開発のハードルが低い
MovableTypeは学習コストが驚くほど低いので、できる人を探したり育てたりという点ではだいぶ優位性があります。
モダンなフロントエンド開発ができるシュッとしたエンジニアを採用するのは結構大変なので、制作会社的にはここがネックになると思います。
またフロントエンドの実装をした制作会社がいなくなってしまってpackage.jsonも手に入らない案件とかを引き継いだりすると目も当てられない（そして稀によくある）ですが、MovableTypeなら最低限テンプレートさえ確認できればなんとかなります。
もはやhtmlが書けるだけではhtmlは書き出せない時代になってしまいましたが、一方で技術だけ先行して運用する現場が取り残されていることは往々にしてあります。
本当にいざという時には泥臭い修正方法があるというのは、重要なことじゃないでしょうか。
API「も」利用できる
MovableTypeは低価格、そして静的ファイル生成を主としたCMSでありながらデータ読み書き可能なAPIも備えており、コストパフォーマンスはかなり高いと言えます。
ただ外部からアクセスできるAPIとして使う場合はモジュール自体を公開サーバー上に置かないといけないので、ネットワークの構成は考える必要があります。
まあヘッドレス的な運用も十分できるとはいえ、正直なところAPIだけの利用であればあえてMovableTypeを選定する理由もないので、あくまでメインは静的生成だと思いますが。
クラウド版やサービス型のMovableType.netなど要件に応じたソリューション選択ができる
予算やサイト規模、やりたいことに応じて様々な選択肢があり、しかもそれらで構築のノウハウが共有できるというのは強みだと思います。
MovableType.netが提供するフォームや検索サービスは他のCMSや静的サイトでの利用も可能です。
プランによる機能制限が少ない
多くの場合必要とされる機能が下位プランで制限されていないというのは良心的だと思います。
microCMSは権限管理やIP制限といったところが上位プランのみの機能なのが少し引っかかりました。
MovableTypeの料金体系は、基本的にサイト規模や負荷、グループ会社での共同利用など、つまり「たくさん使う人は高いやつ買ってね」という設定なので、わかりやすいですね。
まとめ
最初は純粋にヘッドレス運用した場合の比較をしようと思っていたのですが、静的パブリッシングが最大の強みであるMovableTypeのAPIだけ取り出して比べてもあまり意味ないなと。
ウェブサイト構築全体で功罪を考えてみると、いま日常的にやっているサイト構築を全部ヘッドレスCMSに置き換えていくというのは、あまり現実的ではないように思えます。既存CMSの方がすんなり構築できる案件もたくさんあるわけで、結局のところ性能比較というよりは、作るのがそのウェブサイトだけなのかどうか、多角展開あるならAPIベースの設計にしやすいタイプがおすすめです、ということなんだと思います。
過去の案件を振り返ると、あれは完全にヘッドレスでよかったなというケースも結構あって、たとえば
- 店舗ごとのクーポン情報をhtmlとして出力し、webアプリで配信する
- 製品情報をJSONとして出力し、JSで検索する。ほかのページはほぼ静的なサイト
- 提携店舗とタイアップする企業の組み合わせから、該当するキャンペーンを検索できるページ
といった案件は（CMSの指定ありきでなければ）まあ向いていたんじゃないでしょうか。
MovableTypeに限らず、データをJSON出力してどうこうするような実装は結構ありますが、そもそもAPIベースのCMS使ってればいろいろ省略できる工程もあるんですよね。
昨年は日本政府・省庁のウェブサイトもクラウドでヘッドレスなJAMStackでDXするんじゃよっていうような話題もありましたし（結局Drupalになったみたいですが）、今後もAPIを起点にした開発手法が一層求められていくのだろうとは思うのでそこはしっかり追いかけつつ、かといって頭でっかちにならないよう、実際の運用に即した提案をしていきたいものです。
