ヘッドレスCMSベンダー5社のサービス比較【レポート】
09/27/2021 Mo.に開催された、MOONGIFT.dev #1「ヘッドレスCMS」の勉強会に参加したのでそのレポートを書きました。
結論から言うと、大変勉強になりました。Jamstack案件の際の技術選定で大変参考になるお話を聞けました。今回はそこで得たヘッドレスCMSのベンダー各社におけるサービスの差別化ポイントを中心にレポートします。
MOONGIFT.devとは
compassより引用
あらゆるテクノロジー、技術ワードについて探求するコミュニティ
今回はこのMOONGIFT.devが主催する第１回目の勉強会、「ヘッドレスCMS」の回に参加しました。
ベンダー5社の比較
では、今回の勉強会で登壇されたベンダー5社のサービスの特徴をそれぞれレポートしていこうと思います。
今回登壇されたベンダーは以下5社です。
- Kuroco / 株式会社Diverta 加藤 健太さん
- microCMS / 株式会社microCMS 柴田 和祈さん
- Shifter Headless / 株式会社デジタルキューブ 岡本 秀高さん
- Storyblok / Storyblok株式会社 福﨑 有彩さん
- Drupal / 言問株式会社 藤田 拓さん
Kuroco
Kurocoは株式会社Divertaが提供している純国産のヘッドレスCMSです。
Kurocoは同社が提供しているRCMSというCMSの実績を元に開発されているのもあり、RCMSの機能も一部使われている。
私が勉強会に参加して感じたKurocoの特徴はこんな感じ。
- API中心設計で構築されているヘッドレスCMS
- パーソナライズ化されたWebサイトに強い
API中心設計で構築されている
Kurocoは非常にAPIファーストな構築がされている。
そのため開発者が慣れたプログラミング言語で開発できることもあり、開発コストを抑えることができる。
またAPI設計に特化した仕様なため、管理画面からAPIの設計を容易にかつ柔軟にできる。
パーソナライズ化されたWebサイトに強い
元々Kurocoは「パーソナライズ化された体験をマルチデバイスで届けたい」というお客様の課題を解決するということにフォーカスして開発された背景があり、パブリックなサイトだけでなく、ユーザの情報や属性でパーソナライズ化されたサイトに強い仕様が揃っている。
具体的には
- 会員制サイト
- 社内ポータルなどのイントラサイト
への導入に最適なヘッドレスCMS。
Kurocoにはデフォルトでログイン・ログアウト・閲覧制限・問い合わせ機能が揃っているため、こうした会員制サイトを短期間で構築できるというメリットがある。
バックエンドはデフォルトの機能で大半をカバーできると考えると、APIの設計をちょこっと変更してするだけですぐにオリジナルの会員制サイトを開発できるのは良きですね。
Jamstack案件でこのようなサイトを構築する場合はKurocoの利用を検討してもいいかもですね。
microCMS
国産ヘッドレスCMSの代表格とも言えるmicroCMS。
導入実績も多く、とてもネームバリューのあるヘッドレスCMSです。
microCMSの特徴は以下の通り。
- 開発者フレンドリー
- 高い柔軟性
- マルチチャネルのコンテンツの一元管理
開発者フレンドリー
- 管理画面でAPIのプレビューが見れることや各種SDK、画像のAPIもある。
- 国産のヘッドレスCMSなので日本語ユーザにとってわかりやすいドキュメントやブログなど、参考にできるリソースが多いというのも強み。
- これらドキュメントの豊富さもあり、エンジニアからも高い支持を得ている。
確かにドキュメントが多いと開発者としてはとてもありがたいですね。
ふむふむって感じです。
高い柔軟性
Webhook、iFrameの仕組みを用いているので柔軟にカスタマイズが可能。
自社のセキュアなデータや膨大なデータなど、CMS内に配置したくないデータとの連携できる。
→POSなどの顧客データや商品データなどの外部のITとの連携が可能。
自社の開発内で管理画面の拡張ができるので、わざわざmicroCMSの会社にコストをかけて拡張を依頼しなくてもいい！→これだけでもかなりコストを抑えられますね🤔
マルチチャネルのコンテンツの一元管理
APIベースということもあり、Webサイトだけでなく、様々なチャネルのコンテンツを一元管理できるという仕様。
以下例
- Webサイト
- 自社サービス
- モバイルアプリ
- 店頭サイネージ
- 音声デバイス
導入事例
企業の規模も大手から中小、ベンチャー、スタートアップとほんとに幅広い。
事例がたくさんあるのは技術選定する側としても参考にしやすいですよね🤔
現在までで2000社以上の導入実績があるそう。
Shifter Headless
一言で表すとヘッドレスなWordPress。
WordPressをAPIと管理画面だけに特化したようなヘッドレスCMS。
またこのCMSはJamstackに必要なプラグインをプリインストール・そして自動更新もしてくれる。
→プラグインの管理の手間が減りますね。運用者に優しい。。。🥺
ではプラグインの更新はどうなってるのかというと、Shifter Headlessを提供するデジタルキューブ側でアップデートをしてくれるとのこと。
使用可能なプラグインはGithubで公開されています。
ただ、ここにないプラグインも、ユーザの要望で追加してくれることもあるそう。
またデジタルキューブは主要SaaSのベンダーとパートナーシップを契約している。
- Stripe: オンライン決済プラットフォーム
- Algolia: 全文検索APIサービス
- Netlify: Jamstackホスティングサービス
パートナーシップを契約しているということは、それらSaaSを利用した最適なソリューションを提案できることの証でもあるので、Jamstack案件でShifter(WordPress) Headlessとこれらのサービスの利用を考えているのであれば、デジタルキューブに問い合わせることで詳細を聞ける可能性！
Shifter Headlessを導入するメリット
Shifter Headlessを導入するメリットについてもお話されていたので軽くまとめます。
- WordPressをそのまま使える。
これは一番大きいですね。使い慣れたツールをそのまま利用できるので、学習コストも少なく導入はしやすいですよね。 - 今ある普通のWordPressからデータだけ持ってきてフロントエンドだけアレンジすることも可能。
普通のWordPressからHeadlessなWordPressへの移行も問題なさそうですね！ - 大規模なOSSエコシステムの恩恵を受けやすい
ベースはWordPressなので市場にプレイヤーが多い。よって事例やナレッジが多い！！
WordPress APIの導入事例(npmjs.com)
Storyblok
Storyblokはオーストリア発祥のスタートアップ企業、Storyblok株式会社が提供しているヘッドレスCMSです。
まだ日本ではあまり馴染みのないヘッドレスCMSですね。
ですがこの勉強会でとても魅力のあるヘッドレスCMSだということがすごく伝わってきました。
Storyblokの特徴は大きく分けて2つ。
- Visual Editor搭載
- 豊富なハンズオン
それでは一つ一つ見ていきます。
Visual Editor搭載のヘッドレスCMS
「すべての人に使いやすく」をモットーに、Visual Editorを初めて搭載したヘッドレスCMS。
確かに公式の動画を見てみても分かるとおり、直感的に操作したり、API初心者でも使いやすそうだなと思いました。まさに「すべての人に使いやすく」が反映されている仕様なんですね〜
そしてこのVisual Editor、リアルタイムで変更が反映されるそうで、エディタで編集すると即座に同じ画面内のビューも変更が反映されるという仕様。開発体験が良さそうですね〜
何よりエディタとビューが同じ画面にあるのがいいですね。
また、コンテンツ周りのコンポーネントもブロック化されているため、ドラッグ&ドロップでコンテンツを配置できるとのこと。
またアトミックデザインがベースになっているので、ネスタブルにコンポーネントを配置可能。
→再利用性の高いコンポーネントが簡単に作成可能
豊富なハンズオン
Storyblokはハンズオンが充実しているのも利点ですね。
ヘッドレスCMS自体まだまだ成長段階のツールでもあるので、ドキュメントが少ないことを考えると公式がそこら辺のハンズオンを用意してくれてるのは嬉しいですね。
用意されてるハンズオン例
- マルチリンガルのブログ作成のサンプルプロジェクト
- 多言語対応のWebサイトを開発する際にもってこいですね。Storyblokの開発チームは多国籍なメンバーで構成されているというのもこういったマルチリンガルサービスに強い背景なのかもしれませんね。やはり海外製は強い！！！
- Storyblokを5分で導入できるチュートリアル
- Gatsby Cloud Hostingへのデプロイ方法
- Alexa killの実装方法
デメリット
ただ、オーストリア発祥のサービスとだけあって、ドキュメントはすべて英語。英語があまり得意ではない開発者が多い日本ではメンバーによっては逆に開発効率がダウンしてしまう可能性を考えなくてはなりませんね。
日本ではあまり普及していないのもあり、日本語のナレッジも少ないという現状を考慮した上での技術選定になりそうです。
ドキュメント
フロントエンド側で推奨されている技術
導入事例
Drupal
こちらもStoryblok同様、海外製のヘッドレスCMSとなります。
WordPress同様、オープンソースのヘッドレスCMSです。
日本語の文献やナレッジが少ないので知らない人も多いかもですね。
勉強会で知り得たDrupalの特徴
- コンテンツの表示形式をシミュレーションできる
- ハイパフォーマンス
- マルチリンガルサイトに強い
それでは細かくみていきます。
コンテンツの表示形式をシミュレーションできる
Drupalにはビューモードという機能があり、コンテンツの表示形式をシミュレーションできるモードが存在。
要は画像というコンテンツをレイアウトするにも、でっかくキービジュアルのように配置するかカードのサムネイルとして表示するかなどをシミュレーションできるというわけですね。
元々のコンテンツをどういう風に見せるかをリアルタイムに検討しながら開発・設計を進められるということで、具体的な仕様や設計が確定していない・または開発途中で仕様変更の可能性があるアジャイル開発のプロジェクトで重宝しそうだなと思いました。
ハイパフォーマンス
登壇されていた藤田さんいわく、様々なCMSのパフォーマンステストをした結果、Drupalが一番パフォーマンスが良かったそう。
ヘッドレスCMSはAPIのデータ量が多いほどレスポンスが遅くなったりと、パフォーマンスが低下するのが一般的ですが、Drupalは大量のデータを格納しつつもレスポンスが早いという高性能なスペック。
マルチリンガルサイトに強い
こちらもStoryblok同様、マルチリンガルのWebサイト開発に強いという特徴。
強いとはどういうことかというと、マルチリンガルのWebサイトを開発するためのモジュールが予め揃っているということです。多言語対応のためのバックエンドを一から構築しなくてもいいんですね。
海外製というのもあるが、オープンソースなCMSであるが故に世界中の人が開発やメンテナンスに携わっているというバックグラウンドがあるから強いのかもですね。
いずれにせよ海外製はマルチリンガルのサイト制作に強いんだなぁと勉強会に参加して思いましたね。
ヘッドレスCMSを導入するメリット
勉強会後半のQAでヘッドレスCMSを導入するメリットに関してもお話されていて、とても為になったのでまとめます。
- 業務における責任分解点がハッキリする。
- ヘッドレスCMSを導入すると、フロントエンドとバックエンドがほぼ完全に分離されるため、各担当者の作業範囲が従来のCMSよりも明確になるという。
- 同時にエンジニアと運用者(編集者)の作業範囲も明確に分離できる。
- 参入のための共通言語として、GraphQLやREST APIなどの標準的な知識だけでいい。
- 普通のCMSだとCMS特有の仕様などを覚えなくてはならないので、学習コストが増える。それを踏まえるとヘッドレスCMSの導入は学習コストを抑えることにもつながる。
- APIなのでデータの再利用性が高い。
- 確かに頻繁にページで使うデータをわざわざSQL叩いてデータベースにアクセスするのはだるいですもんね。そう考えるとAPIになったことでデータへのアクセスが容易になりましたね。
ヘッドレスCMSの今後
勉強会の後半で非常に興味深いお話を聞けました。
それは、ヘッドレスCMSの今後考えられる導入事例として、Alexaスキルの管理やチャットボットのデータ管理などに導入できる余地があるのでは？と言うお話でした。
世の中ではCMSと聞くと「Webサイトで使うもの」という認識が強いように思いますが、CMSは元々コンテンツ・マネジメント・システムとあるようにコンテンツを管理するためのものなので、別にWeb専用のサービスではないということをハッとさせられた瞬間でした。
確かに従来のCMSではWebブラウザ上の管理画面からテンプレートのhtmlにコンテンツを入稿するという縛りがあったため、Webに限定される仕様でしたが、APIベースのヘッドレスCMSになったことにより、「Web限定」という縛りがなくなったというように感じました。
そう考えてみると、ヘッドレスCMSはまだまだ応用できる分野が存在するのでは？新しい顧客体験創出のキーとなるSaaSになりうるのでは？とも思いました。
感想
勉強会参加前の私のヘッドレスCMSのイメージとしては、どれもAPIベースでフロントエンドはないという感じで、ベンダーが違うからといってそれぞれそんなに違いはないのではないか？と思っていました。
しかし各ベンダーさんの話を聞いていると、やはり各サービスそれぞれ特有の差別化ポイントがあり、Jamstack案件でとりあえずメジャーなヘッドレスCMSを導入すればいいっか！では真に顧客視点の技術選定はできないなと思いました。
Discussion