マルチデバイス・OneToOneマーケ時代のCMS、キーワードはdecoupled・headless・APIファースト

今後のCMSアーキテクチャとして考えるべき構造

CMSの役割がどんどん変わってきています

CMSというと、「Content Management System」ですよね。いわゆるWebサイトのコンテンツを管理するシステムですね。歴史的にはCMSの機能はどんどん変わってきています。

おおざっぱな流れとしては、次のような感じです。

太古には、CMSというと「個別のWebページを作成してFTPでアップロードしてくれるシステム」でした。

そこから、「サイト全体のデザインもまとめて管理し、コンテンツを作成・管理するシステム」になっていき、インターフェイスもどんどんWebブラウザで完結するようになっていきました。

企業利用が進むにつれ、ワークフロー管理がCMSにとって大切なものになりました。サイトを更新する人のユーザー管理、内容のプレビュー、承認フロー、公開予定設定などなどですね。

さらに時代が進み、ソーシャル連携やデータ配信の機能が追加され、コンテンツ制作面ももWYSIWYGや画像処理を行えるフロントエンドによって機能が強化されてきました。

今では、インバウンドマーケティングやリードナーチャリングの仕組みの一部としてOne to Oneマーケティングを実現するために、CRMやDMPなどとのデータ連携によって表示内容をパーソナライズするようになってきました。

さらにスマホなどのマルチデバイス対応に加えてAMPやソーシャルメディア上でのダイレクト表示などにも最適化するために、チャネルごとに異なる表示をするマルチチャネル対応機能が重要になってきました（その前にはガラケーの時代がありましたが）。

これまでのCMSは「ぜんぶ入り」

求められる環境やビジネス目的に対して変化してきたCMSですが、その構造は、比較的「ぜんぶ入り」なものが主流でした。

CMSが実現すべき機能には、大きく分けると次の3つがあります。

CMSに求められる機能（概要）

もうちょっと具体的にそれぞれの機能を見てみると、次のような感じです。実際にはここで示した機能だけでなく、さまざまなものが求められますが、ざっくりイメージをつかんでください。

CMSに求められる機能（詳細）

ここまでの仕組みは、どれもすべてCMSの中に入っています。技術的な表現をすると、1つにまとめた「モノリシック」な状態です。

しかし、「コンテンツ」を配信する先がどんどん増えてきました。PCサイトやスマホサイトだけならわかりやすいですし、場合によってはレスポンシブウェブデザインにすれば大きな問題ではありません。

おそらく、この時点では、CMSで管理しているのは「Webコンテンツ」が中心でしょう。AMPやFacebookのInstant Articles、さらにはSmartNewsやGunosyのようなニュースアプリへの配信、Googleニュースへの配信配信などが増えたとしても、なんとか対応できるでしょう。

ではここに、ブランド素材（ロゴ・写真・解説画像など）もデジタルアセットとしてCMSで一元管理するようにしたら、どうでしょう。さらには、配信先としてスマホアプリやデジタルサイネージが加わってきて、単なる「Webコンテンツ」だけでない、幅広い顧客コミュニケーションのためのコンテンツ全般を扱うようにしようとすると、どうでしょうか。

なかなか、これまでの仕組みでは対応するのが難しくなってきますよね。

また、Webやスマホアプリのフロントエンド（ユーザーが直接触れる画面側）の技術は変化が非常に激しいため、モノリシックな仕組みでは、なかなか新しい技術を取り入れるのも難しいものです。

さらには、システムが複雑化するにつれ、セキュリティ面のリスクも増えていきます。

そこで、昨今ではCMSの「Decoupled」「Headless」「Content as a Service」「APIファースト」といったことが言われています。

どういうことかというと、いままでCMSが一枚岩としてもっていた機能から「表示機能を分割（decouple）」して、「表示部分にはタッチせずコンテンツ管理だけ行う（headless）CMS」として作り、そのCMSから表示側の仕組みにコンテンツをAPI経由で提供する「Content as a Service（CaaS）」システム構成にするという考え方です。

decoupledなheadless CMSによるCaaS

これまでにもRSSやAtom API、XML-RPCといったコンテンツ配信関連の技術はありましたが、あくまでも補助的な仕組みとして扱われていました。それを、「あらゆる表示側システムはAPIでCMSからコンテンツデータを取得する」ことを主軸にとらえた「APIファースト」な考え方にするというものですね。

（場合によってはコンテンツ登録側も同様にAPIファーストにしてコンテンツ管理部分から切り離せます）

表示側のシステムは、コンテンツデータを「API」という仕組みでCMSから取り出して使います。Webサイトなら主にJavaScript（またはサーバー側のシステム）がその役割を担います。

特にWebではHTML5の高度な機能を使えば、そうした仕組みでも速度的には問題なく動作させられます。IE 9もIE 10もすでに公式サポートが（ほぼ）終了しているため、ブラウザの互換性を気にする必要も、かなり減っています。

JavaScriptを中心に作るページにするとSEOを気にする人もいるかもしれませんが、今のグーグルはJavaScriptを実行できるクローラーをもっているので、SEO的にも問題は少ないでしょう。

それどころか、グーグルが積極的に推進しているプログレッシブウェブアプリ（PWA）を作るにしても、こうしたシステム構成にしておくことで対応しやすくなります。

さらには、こうすることでフロントエンド側の自由度が高まり、サイトやアプリの作成やリニューアルをバックエンドのCMSとは（ある程度）切り離して自由にできるようになり、改善の速度を高められるようになります。

制作者が「AngularJSを使いたい」「Backbone.jsでいきたい」「Ember.jsで」という場合も、「なにそれ？ うちのCMSで対応してるの？」とか気にする必要はありません。コンテンツ取り出しのAPIの口さえちゃんと用意してあげればいいのですから。

また、それにともない、バックエンド側もシンプルにでき、セキュリティ面においても堅固にできる可能性が高まります。

もっと言うと、今後AIチャットボットによる顧客対応をしたり、さまざまなシステムと連携させた動的なサイトでOne to Oneマーケティングを実現したりすることもあるでしょう。そうした場合にも、APIによってコンテンツにアクセスできる環境を整えておくことで、スムーズに進めやすくなります。

もちろん、一気にこうしたアーキテクチャに変更することが良いとは限りません。段階的に対応するとしたら、中間の実装を経ることもあるでしょう。

その場合、おそらく現状のWebサイト用の表示の仕組みはCMSの機能を利用し、アプリなどWeb以外のものへのコンテンツ配信に関しては別途APIによる配信を行うことになるでしょう。次のような感じですね。

一部にはAPIによる配信を行う仕組み

とはいえ、実際に「Decoupled」な「Headless CMS」による「Content as a Service」をシステムとして実装しようとすると、いろいろと決めなければいけないことがあります。

ぱっと思いつくだけでも、アクセス権の管理や配信関連のロジックをどこに持つべきなのか、フロントエンド側の各システム用のユーザーログインなどの管理はどこに持つのがいいのか、ユーザー行動関連のデータはどう管理するべきなのかなどなどがあります。

さらにはこれまであまり必要なかったAPI管理の機能というのが、当然ながら必要になってきます。

また、デザインの管理という観点では、一元的に管理していくほうが楽な部分もあるでしょうから、表示側のシステムも何らかの形で共通化しておかないと、後々の運用が大変になってくるでしょう。

おそらく実際には、システムの設計上難しいことがこれ以外にも出てくると思います。

ただ、「CMSというと、こういうもの」という考え方にとらわれるのではなく、こうしたトレンドが出てきていること、実際にはこうした仕組みを前提としたCMSがすでに出てきていることなどは、知っておくといいのではないでしょうか。

ちょっと技術的な内容でしたが、Web担の読者さんにも知っておいていただきたく。