1.1　CMSとは？

　CMSは「Content Management System」の略で、コンテンツ管理システムとも呼ばれます。これは、ウェブサイトのコンテンツを作成、編集、管理するためのツールやプラットフォームを指します。HTMLをページ単位で全て手作業で書いていくのは非効率です。そのため、CMSでは枠組みとなるHTMLをプラットフォーム側で提供し、データベースで管理したコンテンツをそのHTMLに埋め込んで表示できる仕組みが採用されています。

1.2　ヘッド「あり」CMSとは

　「ヘッド付き」CMSとも呼ばれる従来のCMSは、バックエンドの管理機能とフロントエンドの表示機能が一体化したシステムです。例えばWordPressやDrupalといった著名なCMSがそれに該当します。またカスタム開発で作られた各種ウェブシステムにも何らかのCMS的な機能が存在しています。例えば企業のウェブサイトで、「お知らせ」の部分が管理画面から編集できるなら、その部分をCMSと呼んでも差し支えないでしょう。

　・バックエンド: これはCMSの管理側で、コンテンツの作成・編集・保存などを行うインターフェースが含まれます。データベースなども含まれます。

　・フロントエンド: これは「ヘッド」と呼ばれる部分で、ウェブサイトやアプリ上でコンテンツが表示される仕組みを定義します。デザインやレイアウト、テンプレートなどが該当します。

　ヘッド付きCMSでは、コンテンツの管理と表示の部分が密結合しています。つまり、CMSがコンテンツの表示方法も提供します。これにより、コンテンツの作成からウェブサイトの構築まで、一つのシステムで完結できるため、運用が簡単になります。ただし、コンテンツの公開方法などの柔軟性が低いという課題もあります。

1.3　ヘッドレスCMSとは

　それに対して「ヘッドレス」CMSとは、頭がないCMSということになります。バックエンドの機能のみを提供するCMSシステムです。コンテンツの表示方法は定めておらず、「ヘッド」を持ちません。これはバックエンドで入れられるデータの頭をすげ替えて使うことができるという意味です。プラットフォームとデータが分離しているため、自分の好きなプロントエンド技術を使用してCMSのデータを活用できることになります。

　・バックエンド： ヘッドレスCMSはコンテンツの保存・管理・配信機能に特化します。データが使用されるシステムとは独立して、独自の管理画面を持っています。

　・フロントエンド： フロントエンドの表示部分は持ちません。ヘッドレスCMS側では、データがどこにどのように表示されるのかを指定しません。

　デザインやレイアウト、テンプレートなどは何らかのフロントエンドの仕組みで作らなければなりません。データの配信はAPIを通じて行われます。RESTfulやGraphQLなどのAPIを使ってコンテンツを取得し、任意のフロントエンドで表示できます。

1.4　ヘッドレスCMSのほうが面倒？

　ある意味ではその通りです。従来のCMSは「全部乗せ」です。WordPressなどを設定してデザインもその中で選べば、それだけで簡単にかつ迅速にウェブサイトを運用できます。ヘッドレスCMSを使うなら、データの入力だけではなく、デザインを担当するフロントエンドの仕組みを別に開発しなければなりません。

1.5　既存CMSの限界

　さてそれら既存のCMSは「モノリシック」なCMSとも呼ばれることがあります。モノリシックとは、システムが一つの大きな単一の塊として構築されていることを指します。具体的には、従来のCMSではフロントエンド（表示部分）とバックエンド（データ管理部分）が一つのパッケージとして緊密に結びついています。これにより、CMSを導入するときは、そのCMSが提供するテンプレートや機能に大きく依存する形となります。

　CMSの最もシンプルなコンセプトは、記事やお知らせを入力する管理画面があり、そこに入力した文章はウェブページに反映されるというものです。しかしCMSが活用されるようになって、そこにはいろいろな機能が追加されるようになりました。それが膨れ上がり、重厚長大なシステムとなっている状態のことをモノリシックと表現します。

　モノリシックCMSの問題点は、その柔軟性の欠如にあります。特定のデザインや機能を変更したい場合、システムのソースコードに手を加える必要であることが多く、これは煩雑で時間がかかること作業となります。さらに、全体としてのシステムが複雑になることで、新しい技術やフレームワークの統合が難しくなることもあります。また、一つの部分に問題が発生すると、それが他の部分にも影響を及ぼすリスクがあります。

　このような背景から、より柔軟でスケーラブルなシステムを求める声が高まり、それに応える形でヘッドレスCMSが登場しました。ヘッドレスCMSは、表示とデータ管理を分離することで、上述したモノリシックCMSの問題を克服することを目指しています。

1.6　ヘッドレスCMSの登場

　こうした問題意識から近年、ウェブ開発の世界では「ヘッドレスCMS」という言葉が頻繁に取り上げられるようになりました。このヘッドレスCMS、実は単体では何もできないのです。ここに入力したデータもそのままだとどこかに表示することすらできません。

　WordPressのような従来のCMSですと、そこに入力したデータがそのまま同じ仕組みの上でウェブサイトに表示されるわけですからより不便になったと言えます。ヘッドレスCMSを使うということは、そこに入力したデータをどう出力するのかを自分で作らなければなりません。

　しかし、ヘッドレスCMSの魅力は、その柔軟性にあります。従来のCMSがフロントエンド（表示部分）とバックエンド（データ管理部分）を一つのパッケージとして提供していたのに対し、ヘッドレスCMSはバックエンドのみを提供します。このアプローチのおかげで、デベロッパーはどの技術やフレームワークを使用してデータを表示するかを自由に選ぶことができます。このため、Webサイトだけでなく、モバイルアプリ、IoTデバイス、AR/VRアプリケーションなど、多様なプラットフォームやデバイスに内容を統一して提供することが可能になりました。

　このように、ヘッドレスCMSは「表示」と「データ管理」を分離することで、より柔軟で、多様な出力オプションを持つデジタルエクスペリエンスを実現できるのです。一見、セットアップや運用が難しそうに思えるかもしれませんが、現代の多様なユーザー環境や高度なテクノロジー要件を満たすためには、このような新しいアプローチが必要不可欠となってきています。

1.7　メリットとデメリット

　ヘッドレスCMSは、近年のウェブ開発のトレンドとして注目を浴びています。しかし、その採用を検討する際には、メリットとデメリットの両方を理解することが重要です。

メリット

　・柔軟性： ヘッドレスCMSはフロントエンドとバックエンドが分離しているため、任意のフロントエンド技術やフレームワークと組み合わせることができます。

　・マルチプラットフォームに対応： APIをたたくことでデータをJSONやGraphQLで取得して使用するため、ウェブサイト、モバイルアプリ、IoTデバイスなど、さまざまなデバイスやプラットフォームでのコンテンツ配信が容易です。

　・スケーラビリティ： 自動でスケーリング、もしくは簡単に設定できるため、トラフィックの増減に柔軟に対応できます。大規模なプロジェクトや、急にアクセスが一時的に増大するような場合にも対応が容易です。

　・セキュリティ： フロントエンドとバックエンドが分離しているため、セキュリティリスクが低減します。サイトがハッキングされたとしても同じシステム内にデータベースなどを持っていないため、データ漏えいの心配がほとんどありません。

デメリット

　・不便： 圧倒的に戸惑うポイントは不便さを感じることでしょう。ヘッドレスCMSは単にデータの格納先ですので、自前でサイトを用意する必要があります。データを表示する仕組みを別に用意しないとならないため、オールインワンの既存CMSの単なる代替としては使えません。

　・守備範囲のわかりにくさ： どこまでがCMSの機能であるかわかりにくいため、サイトに変更を加えたい場合、誰に聞いたら良いのかわかりにくいかもしれません。

　・使用開始までのハードル： 表示部分であるフロントエンドを用意しなければサイトを公開できません。自分で作るならプログラミングの素養が必要ですし、誰かに依頼するなら開発費を請求されるでしょう。

　・コスト： 一部のヘッドレスCMSは、機能やトラフィックの増加に応じてコストが増加することがあります。WordPressなどですと開発も運用も安価でできる場合があり、ぱっと見のコストが高くなると感じるかもしれません。実際にはスケーリングやセキュリティなどの運用コストを加味するとヘッドレスCMSのほうが安上がりになる場合が多いはずです。

　ヘッドレスCMSの採用を検討する際には、これらのメリットとデメリットを比較し、プロジェクトの要件や目的に合わせて最適な選択を行うことが重要です。具体的には、フロントエンドを作れる当てがあるかどうかに掛かってくるかと思います。VueなりReactなりが使えると良い選択肢になります。PHPしか知らないとなると、WordPressのほうが良いかもしれません。多くのヘッドレスCMSはJavaScriptで記述するフロントエンドのフレームワークと相性が良いと言えます。

1.8　章のまとめ

　この章では、Storyblokとその現代のウェブ開発環境での役割を理解するための基礎知識を提供しました。この知識を持って、読者は後続の章で説明されるStoryblokのより詳細な機能を探る準備が整いました。

　・Storyblokの定義と目的：Storyblokはヘッドレスコンテンツ管理システム（CMS）であり、バックエンドのコンテンツ管理とフロントエンドのプレゼンテーション層を分離します。この分離により、開発者とコンテンツクリエーターはより柔軟かつ効率的に作業を進めることができます。

　・ヘッドレスCMSを使用する利点：従来のCMSとは異なり、StoryblokのようなヘッドレスCMSは柔軟性が高く、スケーラビリティが向上し、複数のプラットフォームにわたるコンテンツ配信をより良く制御できる利点があります。これは、複数のデバイスやチャネルを対象とする現代のウェブ開発の実践に最適なコンテンツファーストアプローチを促進します。

　・リアルタイムビジュアルエディタ：Storyblokの目立つ機能の一つは、CMSがヘッドレスであるにも関わらず、コンテンツ作成者が編集している内容がどのように見えるかをリアルタイムで確認できるビジュアルエディタです。

　・コンポーネントベースのアーキテクチャ：Storyblokは再利用可能なカスタムまたは事前定義されたコンポーネントから動的なページを構築できるコンポーネントベースのシステムを使用しており、開発速度とコンテンツの一貫性を向上させます。

　・柔軟性と制御：強力なAPI、カスタムプラグイン、ウェブフックを提供することで、Storyblokは開発者がコンテンツの取得と表示方法を完全に制御できるようにします。

　・オムニチャネル機能：オムニチャネルコンテンツ配信をサポートしており、Storyblokに保存されたコンテンツは、さまざまなプラットフォームやデバイスにシームレスに統合および配信されます。

　・開発者にとって：Storyblokは任意のフロントエンド技術スタックにコンテンツを取り込むためのAPIを提供し、さまざまなプログラミング言語やフレームワークをサポートしています。これにより、開発者はプロジェクトの要件に最適なツールを自由に使用できます。

　・コンテンツクリエーターにとって：直感的なインターフェースとコンテンツ調整に対するリアルタイムのフィードバックにより、Storyblokは複雑なコンテンツ構造を管理する必要があるコンテンツクリエーターにとって優れたツールです。

次のステップ

　本書を進めるにつれて、Storyblokのセットアップやカスタマイズの方法を詳しく掘り下げ、その高度な機能を探求し、実際のプロジェクトでその潜在能力を最大限に発揮するためのベストプラクティスを適用します。