ヘッドレス、結合型、ハイブリッドの CMS アーキテクチャの選び方

従来型（カップルド）のCMSは、コンテンツを保存し、それを表示するページもレンダリングします。編集者はページの見た目を把握しているシステムの中で作業し、開発者はそのシステムの中でテンプレートを作ります。ヘッドレスCMSはコンテンツを保存・管理してAPIで公開し、「ヘッド」（Webサイト、モバイルアプリ、キオスク端末の画面）は、コンテンツを取得して独自にレンダリングする別のアプリケーションになります。

違いはすべてこの分離から生まれます。ヘッドレスの利点とされるもの（速度、柔軟性、最新のフロントエンドフレームワーク、マルチチャネル配信）はすべてここから生じ、欠点もまた同様です。コンテンツはページではなく構造化データになり、柔軟性が得られる一方で、誰かがその構造を設計しなければなりません。レンダリングは組織自身のアプリケーションになるため、パフォーマンス、アクセシビリティ、稼働率は自社チームの責任になります。

ヘッドレスが最も力を発揮するのは、コンテンツを複数の場所に表示しなければならない場合です。たとえば、製品情報、法務関連の文面、プレスリリースを共有する十数のブランドサイトを持つグループ企業、同じコンテンツをWebサイト、モバイルアプリ、店頭ディスプレイに配信する企業、3つの言語でサービスを提供し、翻訳を原文と常にそろえておく必要がある組織などです。いずれの場合も、コンテンツを言語に対応した構造化エントリとして一度だけ保存し、APIで配信することで、大量のコピー作業と、それに伴う不整合をなくせます。

ヘッドレスは、すでにReactなどのフレームワークで開発を行う強力なフロントエンドエンジニアリングチームを持ち、Webサイトを他のアプリケーションと同じパイプライン、テスト、デプロイの手法で扱う「プロダクト」として運営したい組織にも適しています。そのようなチームがあるなら、テンプレートシステムよりもコンテンツAPIのほうが自然に馴染みます。

開発者は一般にヘッドレスを好みます。すっきりしたAPI、自分たちで管理できるフロントエンド、古いテンプレート言語が不要なことが理由です。一方、編集者はそれほど乗り気でないことが多く、コンテンツが公開されるかどうかは編集者の使い勝手にかかっています。カップルドCMSでは、編集者は実際の表示どおりにページを見ながら、コンポーネントをドラッグして配置し、公開ボタンを押します。純粋なヘッドレス構成では、編集者はフォームの項目に入力し、フロントエンドがうまく表示してくれると信じるしかありません。未公開コンテンツを実際のページでプレビューする機能は作り込む必要があり、CMSが提供していなければ、予約公開、ワークフロー、承認も同様です。

ヘッドレスを選ぶ前に、編集者にヒアリングしてください。週に何ページ公開しているか、ランディングページを自分たちで作るのか開発者に依頼するのか、編集中にページを見る必要があるのかを確認します。マーケティング部門がエンジニアの手を借りずにページを作成・変更する必要があるなら、API の上で本格的なビジュアル編集ができるCMSか、ハイブリッドモデルのいずれかが必要です。どちらの場合も、プレビューとページ構成のためのツールに予算を確保しておくべきです。

選択の影響が最も大きいのはEコマースです。ヘッドレスアーキテクチャでは、コンテンツプラットフォームに、独立したコマースエンジン、検索サービス、決済プロバイダーを組み合わせます。これはコンポーザブルスタックと呼ばれる構成です。独自の要件と有能なチームを持つ小売企業にとっては、各分野で最良の機能を選べ、どの部分でも自由に入れ替えられる構成です。しかし多くの組織にとっては、カタログ、コンテンツ、カート、チェックアウト、プロモーションの間の連携を自ら担い、複数ベンダーのロードマップの足並みをそろえ続けることも意味します。

コンテンツとコマースがデータモデルと管理画面を共有する統合型プラットフォームであれば、その連携コストがなくなり、通常はマーチャンダイザーの日々の使い勝手も向上します。判断の分かれ目は、コマースの要件が、スタックを自社で組み上げることを正当化するほど特殊かどうかです。多くの組織では、そこまで特殊ではありません。

ヘッドレスのサイトは高速であることが多いものの、その速さはアーキテクチャそのものではなく、フロントエンドの作り方から生まれます。ページが事前に、あるいはエッジでレンダリングされ、積極的にキャッシュされ、コンテンツが訪問のたびにブラウザで取得されるのではなく、ビルド時やリクエスト時に取得される場合に高速になります。コンポーネントごとにブラウザからコンテンツAPIを呼び出すヘッドレスサイトは、置き換え前のカップルドCMSより遅くなることもあります。適切に設定されたカップルドCMSをCDNの背後に置けば、ページは十分高速に配信されます。

パフォーマンスは予算（最初のコンテンツが表示されるまでの時間、最大のコンテンツ要素、操作可能になるまでの時間）を伴う要件として扱い、候補となるアーキテクチャには、オフィスの回線ではなくモバイルネットワークも含めて、その予算をどう満たすのかを示してもらいましょう。

コンテンツが1つのWebサイトにあり、編集者が自分でページを構成する必要があり、エンジニアリングチームが小規模か他のシステムと兼務で、アーキテクチャの選択肢よりも公開までの期間が重要であれば、カップルドまたはハイブリッドを選びます。多くの企業のマーケティングサイト、イントラネット、サービスポータルがこれに当てはまります。ページをレンダリングしつつ、すべてをAPIでも公開するハイブリッドCMSであれば、今日のWebサイトをカバーしながら、将来のアプリや2つ目のチャネルにも対応する余地を残せます。

コンテンツの配信先が複数ある場合、翻訳やブランドサイトを多数のサイト間で一貫させる必要がある場合、強力なフロントエンドチームが体験を自ら担いたい場合、あるいはコマースの要件がコンポーザブルスタックを必要とし、組織がそれを運用する準備ができている場合は、ヘッドレスを選びます。判断の基準は技術の評判ではなく、組織の実情です。