ヘッドレスCMSとは？

ヘッドレスCMSアーキテクチャは、バックエンドのコンテンツ機能（作成、管理、格納など）とフロントエンド機能（表示、配信など）に分かれています。

つまり、ヘッドレスCMSとは一体どういうものなのでしょうか？

ヘッドレスCMSの実際の意味や、ヘッドレスアーキテクチャがデジタル体験の未来に与える影響についてご説明します。

ヘッドレスアーキテクチャは、Webコンテンツの進化に対応したものでもあります。 長い間、ほとんどのWebコンテンツはWebページとしてブラウザ経由で配信されていました。しかし、今では新しいコネクテッドデバイスが次々と登場しています。

今日、ユーザーはスマートフォンやウェアラブルデバイス、AI対応音声アシスタント、さらにはVRヘッドセットなど、さまざまなフォームファクターを持つ新しいインターフェースを通じてコンテンツを消費しています。

ヘッドレスCMSアーキテクチャは、このような新たなコンテンツの課題に対応するための基礎となるものです。つまり、より多くのコンテンツを簡単に作成、管理して、より多くの場所へと配信できるようになるのです。

技術的な詳細に入る前に、基本的なことから説明していきましょう。

まず、二つの基本的なアーキテクチャの概要と、それらがコンテンツの作成、格納、管理、配信、そしてパーソナライズにどのように影響を与えるかについてご説明します。

CMSアーキテクチャがページ内のコンテンツにどのように影響を与えるか？

ページベースのアーキテクチャとオブジェクトベースのアーキテクチャの違いや、AI対応音声アシスタントが思ったほどスマートではない理由をご覧ください。

CMSアーキテクチャは、コンテンツがどのように（そしてどこに）配信されるかにどのように影響するか？

ヘッドレスアーキテクチャと非ヘッドレスアーキテクチャの違いを理解し、ヘッドレスでは通常ともなわないパーソナライズや分析を可能にする方法をご覧ください。

CMSフロントエンド vs バックエンド

従来のCMSは、フロントエンドとバックエンドの二つから構成されています。

大まかに言うと、CMSのバックエンドはコンテンツが管理される部分で、フロントエンドはコンテンツが表示される部分です。店舗のウィンドウディスプレイのようなものとお考えください。

フロントエンドでは、商品を選んだり、並べたり、看板をつけるなど、通りからのぞき込むように見ることができます。

バックエンドは、看板を作ったり、在庫を保管したり、店舗での商品の移動を管理する、いわば物流部分が相当します。

基本的なWebサイトの場合、バックエンドには次が含まれています。

• コンテンツを作成するためのシンプルなインターフェース
• デジタルアセットを格納するためのデータベース
• デザインのフレームワークを作成、適用するためのアプリケーション層

そしてフロントエンドでは、コンテンツや格納されているアセット、デザインを引っぱってきて、HTMLページに公開します。

デカップルドCMSとは？

従来、CMSのフロントエンドとバックエンドは緊密に連携していました。ユーザーは、コンテンツの作成、保存、管理、公開のすべてを一つのインターフェイスでおこなうことができました。

技術者ではないユーザーがブログのようなシンプルなコンテンツを公開する場合、この仕組みはすばらしく、シームレスな動作でした。

しかし、デジタル体験が進化するにつれ、デベロッパーはより高度なコンテンツをより多様なデバイスに提供するためのカスタム回避策に多くの時間を費やすようになっています。

デカップルドCMSは、バックエンドとフロントエンドのタスクを分離します。つまり、デベロッパーはバックエンド技術に縛られることなく、好みの言語でフロントエンド体験をすばやくコーディングしたりデザインできます。また、API（アプリケーションプログラミングインターフェース）を使い、コンテンツの格納や管理のようなバックエンド機能をフロントエンドの配信環境につなげられます。

APIファーストCMSとは？

デカップルドCMSはバックエンドとフロントエンドの機能を分離しますが、ページのテンプレートやモジュール統合のようなフロントエンドの配信ツールが含まれてことが多くあります。

APIファーストのCMSは、デフォルトのフロントエンドを持たないという点で、機能的にはヘッドレスCMSと同じです。デベロッパーは配信レイヤーを自由に作成し、（お好きな言語で）想像しうる限りの新しいチャネルにコンテンツをプッシュできます。

APIファーストのCMSは、経験豊富なデベロッパーチームには最適です。CMSでコンテンツを管理し、開発チームがビルドしたフロントエンド配信レイヤーからのAPIコールを待つだけです。

一方、デカップルドCMSは、フロントエンドとバックエンドが分離されていることで得られる柔軟性と、公開におけるサポートが必要な企業に最適です。

ヘッドレスCMSは、間違いなくコンテンツ管理の未来です。それには重要な理由が二つあります。

第一に、デジタルコンテンツはより洗練され、ユーザーの期待もそれにともない高まっていることです。目立つためには、美しく、即応性の高いインタラクティブなコンテンツを構築し、しかもそれを迅速に提供できなくてはなりません。

第二に、新しいチャネルやユーザーデバイスがつねに出現し続けていることです。美しいコンテンツをただ作るだけではなく、それをあらゆる場所に、可能な限り効率的に配信する必要があります。ヘッドレスCMSにより、マーケティング担当者とデベロッパーは優れたコンテンツを構築できるようになった今、将来を見据えたコンテンツ運営をおこない、あらゆる場所で一貫してすばらしいコンテンツを提供し続けることが求められています。

マーケティング担当者、デベロッパー、ユーザー、全員に最適

マーケティング担当者に最適な理由…

…コンテンツを一度作成すれば、デベロッパーはそれをどこにでも表示できます。 つまり、管理作業に費やす時間を減らし、よりすばらしい体験の構築に時間をかけられるようになります。

ユーザーに最適な理由…

…ユーザー体験はつねに高速で、一貫性があり、即応性があります。これは、クライアント側がバックエンドシステムと通信する必要がなく、コンテンツをレンダリングするだけでよいからです。

デベロッパーに最適な理由…

…デベロッパーは、専門知識のないプログラミング言語によるバックエンドの制約から解放されます。使い慣れたツール（例：JavaScriptライブラリやフレームワーク）を使用してユーザー体験のルック & フィール、機能性を構築し、最新のAPIを活用してコンテンツをどこへでもプッシュできます。

既製のヘッドレスCMSは、コンテンツに関するすべての課題を解決する特効薬ではありません。入念に考慮すべき点が二つあります。

一つ目は、柔軟性の代わりに、アクセシビリティが損なわれる点です。表示（プレゼンテーション）はJavaScriptを書くデベロッパーに任されるため、技術的な知識のないマーケティング担当者はWYSIWYG（What You See Is What You Get）によるオーサリングや編集ができません。

二つ目はより大きな問題です。

CMSのヘッドを切り離すと、サーバーはお客様のやり取りデータを、フロントエンドとバックエンド間でリアルタイムに送信する機能が失われるのです。

つまり、体験のパーソナライズやコンテンツ分析ができなくなってしまいます。

パーソナライズは今や「あれば役立つもの」から「必要不可欠」になりました。お客様はアマゾンやNetflix、Spotifyのような業界リーダーがおこなっているパーソナライズがどれほど有用か身を持って体感しています。

近しい体験を提供できないと、お客様はすぐに他社サービスへ心変わりしてしまいます。それでは、何が正解なのでしょうか？

理想的なCMSアーキテクチャは、ヘッドレスCMSの柔軟性と拡張性に、従来のカップルドCMSが提供するパーソナライズとコンテンツ分析機能を組み合わせたものです。

Sitecoreのヘッドレスオプションは、まさにそれを実現するものです。

複数のヘッドレスオプションで、フロントエンドデベロッパーは、さまざまなデバイスやブラウザ上でコンテンツをレンダリングするソリューションやアプリを構築できます。 Vue.js、React.js、Angular.jsなどのJavaScriptライブラリを使用したり、新しいASP.NET Core SDKやヘッドレスレンダリングホストアーキテクチャを活用するなど、デベロッパーは最適なものを選べます。

これらのオプションには、Sitecoreのコンテクストコンテンツデリバリーサーバーに接続するAPIが付属しています。このAPIは、Sitecore Experience Database™の情報を使用して、デバイスやブラウザがコンテンツとパーソナライズルールの両方をリアルタイムに解釈することをサポートするものです。そのため、ユーザーはプロフィール情報や過去のやり取りなどに基づいたさまざまなコンテンツを見ることができます。