APIの「進化」が招いたCMSの「分化」

2005年頃からMovable Type、ExpressionEngine、eZ Publish（現Ibexa DXP）、a-blog cms、Craft CMS、NOREN、WordPress、Drupal、SITE PUBLIS、Adobe Experience Manager等々、様々なWebCMSに携わってきました。思想や仕様が違うものはあるものの、コンテンツタイプ、カテゴリ / タクソノミー、アセット管理、多言語対応、パフォーマンス対応、スケジューリング、ユーザー権限管理といった大枠は、どれにも備わっている機能でした。

それらの操作方法についてはマニュアル / ドキュメンテーションを読めば比較的理解はできるのですが、Webページの画面を扱うテンプレートの仕様はそれぞれのCMSで全く違い、ちょっと時間が経つと「このデータはどうやってとるんだったっけ？」と忘れてしまうことがあります。この各CMSにおける車輪の再発明のようなテンプレート仕様の違いは、エンジニアを悩ませたり距離を取らせたりする原因ともなりました。

2007年にApple社がiPhoneを発表した頃、マルチデバイスの流れが加速してテンプレートによるデバイスタイプ毎の出し分けのニーズが大きくなり、テンプレート工数が1.5倍程度以上増えましたが、レスポンシブデザインで各画面サイズに対応することにより収束へと向かいました。当時のテンプレート工数の増大で感じたのは、マルチデバイスの対応はCMS側でやらない方がよいのでは？ということです。2011年頃に作成した私のスライドをみると、このあたりへの思いが垣間見えます。

この頃よりCMS側もAPI提供のための仕組みを強化し始めます。Movable TypeのData APIやWordPressのREST API、DrupalのRESTful API / JSON:API等が標準で備わり、それに加えAPIエンドポイントの多数化問題の解決策も含めたGraphQLの登場があり、上記スライドのような仕様は当たり前のものとなっています。さらに2010年代に台頭してきたJavaScriptフレームワークによりJSON / XMLをデータソースとして画面を表現する流れが進み、ReactやNext.jsの登場によりフロントエンドの仕組みは私の思いの実現を大きく加速してくれました。それどころかテンプレート機能を持たずデータ / コンテンツ提供のAPIのみを持つというヘッドレスCMSが誕生しました。今やCMSテンプレートの制約はなくなり、より自由なフロントエンド表現ができる土台ができたといえるでしょう。

さて、ヘッドレスCMSと似つつもちょっと違う言葉としてデカップルドCMSがあります。実はMovable TypeやWordPress、DrupalのようにAPIについて利用可能でありつつも従来どおりのフロントエンドのためのテンプレートも利用できるCMSのことをいいます（諸説ありますが…）。エンタープライズCMSとしてリードするAdobe Experience Managerもヘッドレス対応のドキュメンテーションを用意しており、デカップルドCMSといえるでしょう。

ヘッドレスCMSがAPIオンリーであるのに対して、デカップルドCMSはAPIファーストと謳っていたりもしますが、実際のところMovable TypeやWordPress、Drupal等のAPIを備えているCMSもまだまだ独自フロントエンドテンプレートを利用しているのが実情でしょう。デカップルドCMSにおいてはNext.jsやAstroといったモダンなフロントエンドフレームワーク対応へのベストプラクティスがまだ模索中ということがあるのかもしれません。しかしCMSが用意したフロントエンドテンプレートを使いつつ、お知らせ / イベント / 商品の一覧はCMSが出力するJSONを使用するケースは珍しくなくなってきました。ちなみにこのような使い方をハイブリッドと言ったりもします。

以上より、2023年現在ではCMSをAPI視点で大きく分けると、下記3つがあるといってもいいでしょう。

• 旧来のCMS（フロントエンドテンプレートのみでAPIを持たないCMS）
• デカップルドCMS（従来のフロントエンドテンプレートもあるがAPIもあるのでヘッドレスもできる）
• ヘッドレスCMS（完全APIオンリー）

先ほども触れましたが、デカップルドCMSは大方旧来のCMSと同じ作りで開発を進めつつ一部だけAPI利用をするというケースが多く、この場合は今までと変わらないインフラで構築が可能です。しかし、デカップルドCMSにおいてヘッドレスに寄せた開発をする場合はヘッドレスCMSでの構築と同じようにインフラも含めて旧来とは違う技術スタックで進める必要があります。後者を選ぶと今までの技術資産が利用できなくなるケースもあるため、お客様にとってはどちらが望ましいアーキテクチャなのかを十分に選択する必要があるといえるでしょう。とはいえ、ヘッドレスアーキテクチャのメリットであるセキュリティや高速化、かつ、強力な柔軟性や再利用性はビジネス展開を加速させるツールになりえる可能性を大きく秘めています。

ミツエーリンクスではこれらのCMSをお客様のご要件に合わせてご提案させていただきます。ぜひお声がけいただければと思います。