Q.Studioから移る時、ヘッドレスCMSを使えばベンダーロックインを避けられますか？

一般的なCMSとヘッドレスCMSでは、どこに違いがあるのでしょうか。ヘッドレスCMSは、記事を入稿して管理する仕組みと、読者が見る表示画面を切り離したCMSです。CMSに保存した記事や画像のデータを取り出し、別に用意したWebサイトやアプリで表示します。

一般的なCMSやStudioは、記事の入力画面だけでなく、Webサイトのデザインや表示、サーバーのホスティングやSSLまでをまとめて管理できる仕組みを持っています。管理画面と公開ページがひとつの場所で結びついているため、専門知識が少なくてもWebサイトを立ち上げられる設計です。一方、ヘッドレスCMSの場合、CMSが受け持つのは記事を書いて保存するところまでです。ページのデザインやURLの組み立ては、表示側のサイトで行います。

具体的な構成例としては、日本製のmicroCMSに記事を保管し、WebフレームワークのAstroを使って画面を構築する手法が挙げられます。Astroは一つの例で、ほかの仕組みで作ってもかまいません。

ちなみに、Cloudflareが公開したEmDashのように、MITライセンスのオープンソースCMSでありながらAstroによるテーマ作成ができる仕組みも登場してきました。

導入前に確認したいのは、作る人と直す人です。表示側の開発とAPIとのつなぎ込みを担えるエンジニアが社内にいるか、外部のパートナーに頼めるかを先に決めておかないと、公開後の修正が止まります。

将来ほかのツールへ乗り換えたくなったとき、蓄積した記事をスムーズに持ち出せるのか、心配になる場面は多いものです。

これに対してヘッドレスCMSを使う構成では、記事データを保持する場所と、画面を表示して配信する場所を切り離せます。たとえばmicroCMSで文章を管理し、Astroで構築したWebサイトをCloudflare Pagesに配備する場合、CMSとWebサイトの配信サーバーを完全に別々のアカウントや基盤で運用できます。ただし、配信先や表示側を手直しなしで交換できるわけではありません。

CMSから出ていくときの条件も見ておきます。microCMSのCSVエクスポートはTeam、Business、Enterpriseの各プランで使え、Hobbyプランでは使えません（microCMSのCSVエクスポート）。出力には対象のAPIとコンテンツの読み取り権限が要り、参照先の権限がないと、その欄は「NO_READ_PERMISSION」と出力されます。

書き出したCSVファイルは、同じ形式のAPIに対してコンテンツを新規登録する用途で再インポートが可能です。ただ、別のCMSへそのまま入れられる保証ではないので、乗り換えを考えた時点で一度試しに書き出し、抜けている項目がないか見ておくと後で慌てません。

契約型のCMSは提供元の決めた条件の中で使うしかありませんが、オープンソースのCMSなら、動かす場所や保存先を自分で選べます。この点ではロックインは小さくなりますね。

例として、Cloudflareが公開したEmDashを見てみます。EmDashの公式解説にあるように、Cloudflare Workers上ではD1やR2を利用し、Node.js環境ではSQLiteやPostgreSQL、メディア保存にローカルディスクやS3互換サービスを選んで動かせる柔軟性があります。

ただ、選べる自由と引き換えに、運用は自分たちの仕事です。EmDashのような仕組みでは、データベースやメディア保存先の管理、日々のバックアップ、本体のアップデート作業を自社で抱えなければなりません。Studioでサービス側に任せていた部分が、そのままこちらへ移ってくる形です。

もう一つの違いが組み方です。EmDashはAstroに組み込む形で、管理画面とコンテンツの処理がAstroのアプリケーションの中に入ります。CMSと表示側を別々に置くヘッドレスCMSとは組み方が違うため、ライセンスが開いていることと、表示側を自由に替えられることは分けて考えたほうがよいでしょう。

ヘッドレスCMSを契約すれば、それだけでWebサイトまで完成させられるのでしょうか。

答えは明確で、表示側のWebサイトはCMSとは別にゼロから制作しなければなりません。ヘッドレスCMSは記事の入稿やデータ配信だけを担当し、画面そのものを描画する仕組みを持っていないためです。Astroのような仕組みで作るのが一つの方法です。

Studioから乗り換える際、既存のデザインやページ情報、HTMLなどのソースコードは一切書き出せません。そのため、現在の見た目やレイアウトは移行先のWebサイト側で新しく作り直す作業が伴います。今のサイトの画面を記録しておき、それを見ながら作るのが現実的でしょう。

フォームも見落としやすいところです。問い合わせフォームや会員ログインのような動きのある機能は、外部ツールを使うか、別に開発するかを選ぶことが多くなります。Studioでフォームを使っていたなら、移行先でどう受け付けるかを最初に決めておきましょう。

更新の流れも変わります。記事を更新するたびにサイトを作り直す「静的生成」の方式なら、更新のたびにビルドという作業が走ります。アクセスがあったときにAPIから記事を取ってページを作る方式もあり、こちらは更新ごとのビルドが要りません。

記事をまとめて入れるときは、microCMSのCSVインポートが使えます。また、CSVインポートで追加した記事では、更新を知らせるWebhookが送られません。記事更新に合わせて自動でページを再生成する設定にしていても、一括登録直後は自動ビルドが実行されないため、手動での再生成や表示確認を忘れずに行いたいですね。

サーバーの面倒を見なくてよいヘッドレス構成にしたはずなのに、なぜ制作会社から保守契約を案内されるのか、不思議に思う人は少なくありません。ホスティングやセキュリティを丸ごと預けられるStudioとは違い、ヘッドレスCMSとフロントエンドを組み合わせたサイトでは、安定した運用を続けるための専門作業が自社側に残ります。

主な作業のひとつが、表示側のフレームワークやライブラリのアップデート管理です。たとえばAstroでは本体と公式プラグインをまとめて更新する仕組みが備わっていますが、互換性の検証を挟まずに更新を適用すると、レイアウトの崩れや機能停止を引き起こすリスクがあります。

また、不測の事態に備えた復旧体制も欠かせません。Cloudflare Pagesには過去の正常な公開状態へ素早く戻せるロールバック機能があり、ビルドが成功した本番環境を指定して復元を行えます。ただしプレビュー環境はロールバックの対象外となるため、日頃から本番の配信状況を把握しておく必要があります。これはサイトの表示を戻す機能で、CMSの記事データまで戻るわけではないため、記事のバックアップは別に考えましょう。

保守サービスの一例として、Cleysenseでは、CMS・フレームワーク・プラグインの互換性の確認と更新、日次のバックアップと障害時の復旧、機能追加やテンプレートの修正を扱っています（Cleysenseの保守プラン）。緊急時の初動はプランごとに違います。

この時間は対応を始めるまでの目安で、復旧が終わるまでの時間ではありません。

APIキーの管理も保守に入れておきたい作業です。microCMSでは、APIキーを作成・編集・削除できるのは管理者権限を持つ人だけです。記事の更新代行やフォームの動作確認が入っているかは会社ごとに違うので、見積もりの項目で確かめてください。