TL;DR

ヘッドレス CMS というフレーズが Web 開発の世界で急速に広まっていますけど、その意味や「なぜ流行っているのか」分かりづらいと思いません？この記事では、ヘッドレス CMS が何なんなのか、それを扱うために必要な時間やリソースはどれくらいか、そしてその歴史的背景について詳しく解説します。

※ この記事は具体的なチュートリアルではなく、ヘッドレス CMS の概念、その学習コスト、そしてその歴史的背景についての理解を深めるためのガイドです。

ヘッドレス CMS とは？

一言で言うとヘッドレス CMS は、従来の CMS が持つ「ヘッド」部分（フロントエンド、つまりユーザーインターフェース）を切り離したものです。

ここでの「ヘッド」は、Web サイトの見た目を構築する部分を指します。従来の CMS は、フロントエンドとバックエンドが密接に結びついていますが、ヘッドレス CMS ではそれらが完全に別々になります。

従来型の CMS（WordPress など） では、内容（記事や画像など）を投稿すると同時に、その内容がどのようにウェブサイト上で表示されるかも管理します。しかし、ヘッドレス CMS では、コンテンツの作成と保存だけを担当し、その表示方法は別のシステム（この場合は Next.js などのフロントエンドフレームワーク）が管理します。

このヘッドレス CMS の利点は、表示方法を気にせずにコンテンツの管理に集中できること、またフロントエンドの技術を自由に選べることです。

ヘッドレス CMS の種類

こちらは、おすすめのヘッドレス CMS の一部です。各 CMS の名前は公式ウェブサイトへのリンクになっています。

無料枠

これらのヘッドレス CMS の多くは、無料プランを提供していますが、その範囲と制限は各サービスによります。以下に、各 CMS の無料プランの有無とその概要をご紹介します。

• Contentful: 無料プランあり。一定のコンテンツ量と API リクエスト数まで利用可能。
• Strapi: オープンソースなので基本的に無料で使用できますが、エンタープライズ機能には料金が発生します。
• Prismic: 無料プランあり。一定のページ数とユーザー数まで利用可能。
• Ghost: オープンソースなので自己ホスティングすれば基本的に無料ですが、Ghost のホスティングサービスは有料です。
• Sanity: 無料プランあり。一定のデータ使用量と API リクエスト数まで利用可能。
• Decap: オープンソースなので基本的に無料で使用できますが、ホスティングサービスは無料プランと有料プランがあります。
• GraphCMS: 無料プランあり。一定のコンテンツ量と API リクエスト数まで利用可能。
• microCMS: 無料プランあり。一定の API リクエスト数とデータストレージ量まで利用可能。

これらの無料プランは、小規模なプロジェクトや個人的な使用、または試用期間として有用です。しかし、大規模なプロジェクトや商用利用では、より高度な機能や大量のリソースを必要とするので、有料プランを検討することが多いです。それぞれの CMS の公式ウェブサイトで最新の料金情報とプランの詳細を確認してください。

ヘッドレス CMS を扱うまでの学習コスト

ヘッドレス CMS を扱うためには、Jamstack 理解する必要があります。Jamstack を学習するために必要な技術の難易度をまとめました。

こちらが、Jamstack（例えば、Next.js, Vercel, ヘッドレス CMS）を扱うために何が必要かをまとめた表です。ただし、あくまでも一例ですので全部学ぶ必要はありません。プロジェクトによっては不要なものもあります。個々の学習者の既存の技術スキル、学習リソースの質、学習者の学習スピードなどにより異なることをご理解ください。

※ 上記の学習項目は一部であり、他にも学ぶべきことがありますし、各ライブラリやフレームワークのバージョンアップをキャッチアップして更新し続ける必要もあります。

microCMS からデータを取得する

具体的に、どのようにヘッドレス CMS を取得して表示するのでしょうか？

例えば、Next.js で ヘッドレス CMS である microCMS の JavaScript SDK を利用してデータを取得する際は、以下のように記述します。

// lib/client.ts
import { createClient } from 'microcms-js-sdk'

// これはmicroCMSと通信するためのクライアントとなります。
export const client = createClient({
  serviceDomain: process.env.SERVICE_DOMAIN || '',
  apiKey: process.env.API_KEY || '',
})

そして、以下のように記述することで、microCMS で作成したコンテンツ一覧を表示することができます。

// pages/blog/index.tsx
import Link from 'next/link'
import { client } from '../../lib/client'

type Blog = {
  id: string
  title: string
}

const Home = ({ blog }: { blog: Blog[] }) => {
  return (
    <div>
      <ul>
        {blog.map((blog) => (
          <li key={blog.id}>
            <Link href={`/${blog.id}`}>{blog.title}</Link>
          </li>
        ))}
      </ul>
    </div>
  )
}

export default Home

// データをテンプレートに受け渡す部分の処理を記述します
export const getStaticProps = async () => {
  const data = await client.get({ endpoint: 'blog' })

  return {
    props: {
      blog: data.contents,
    },
  }
}

ヘッドレス CMS は、なぜ生まれたのか？

ヘッドレス CMS（Content Management System）は、従来の CMS の制約を克服するために生まれました。従来の CMS は、コンテンツの作成、管理、配信を一つのプラットフォームで行う「モノリシック」なアプローチを採用していました。しかし、このアプローチは、特定のテクノロジースタックやプレゼンテーション層（フロントエンド）に依存しているため、新しいテクノロジーやデバイスへの対応が難しく、柔軟性に欠けていました。

ヘッドレス CMS は、この問題を解決するために生まれました。ヘッドレス CMS は「ヘッド」（フロントエンド）を持たず、コンテンツの作成と管理のみを行うバックエンドシステムとして機能します。コンテンツは API 経由で配信され、どのように表示されるかはフロントエンドの開発者が決定します。これにより、ヘッドレス CMS は任意のテクノロジースタックやデバイスに対応可能な、より柔軟なコンテンツ管理ソリューションを提供します。

初期の CMS（1990 年代後半 - 2000 年代初頭）

初期の CMS は、ウェブサイトのコンテンツを管理するために開発されました。これらのシステムは、HTML と CSS の知識を必要とせずにウェブページを作成・編集できるように設計されていました。

モノリシック CMS（2000 年代 - 2010 年代初頭）

WordPress や Drupal などのモノリシック CMS が登場し、ウェブサイトの作成と管理を一つのプラットフォームで行うことが可能になりました。しかし、これらのシステムは特定のテクノロジースタックに依存しており、新しいテクノロジーやデバイスへの対応が難しいという問題がありました。

ヘッドレス CMS（2010 年代中頃 - 現在）

モバイルアプリ、IoT デバイス、VR/AR デバイスなど、新しいデバイスとテクノロジーの出現に対応するために、ヘッドレス CMS が開発されました。これらのシステムは API 経由でコンテンツを配信し、フロントエンドの開発者がコンテンツの表示方法を自由に決定できるようになりました。

ヘッドレス CMS のメリット

ヘッドレス CMS の大きなメリットは、コンテンツがどのように表示されるかについての制約がないことです。従来型の CMS では、テンプレートが指定され、コンテンツの表示方法が制約されます。しかし、ヘッドレス CMS では、コンテンツがどのように表示されるかは完全に開発者の手に委ねられます。

これにより、同じコンテンツを複数のプラットフォームで異なる形式で表示することが可能になります。例えば、ウェブサイト、モバイルアプリ、デジタルサイネージなど、多種多様なデバイスに対応することができます。これにより、デザインやレイアウトの自由度が飛躍的に向上します。

また、ヘッドレス CMS は API を通じてコンテンツを提供するため、フロントエンドの技術選択に自由度があります。React、Vue.js、Angular など、任意のフレームワークやライブラリを選択して開発を進めることができます。

ヘッドレス CMS のデメリット

一方、ヘッドレス CMS はフル機能の CMS と比べていくつかのデメリットがあります。

一つ目は、開発者がコンテンツの表示方法を完全に制御する必要があるため、フロントエンドの開発に更なる時間と労力が必要となることです。従来型の CMS では、プレビルトのテンプレートやテーマを使用して、短時間で高品質なウェブサイトを構築することが可能です。しかし、ヘッドレス CMS では、これが可能な限り自由である反面、フロントエンドの開発により多くの時間を費やす必要があります。

二つ目は、一部の CMS が提供する機能が利用できない可能性があることです。例えば、プレビュー機能や WYSIWYG（What You See Is What You Get）エディタなど、一部の CMS が提供する UI ベースの機能が利用できない場合があります。このような機能は、マーケティングチームやコンテンツ作成者にとって重要なツールであるため、その欠如は大きなデメリットとなり得ます。

以上が、ヘッドレス CMS のメリットとデメリットの一部です。適切な CMS を選択するためには、プロジェクトの要件や目標、開発チームのスキルセットなど、多くの要素を考慮する必要があります。

ヘッドレス CMS のセキュリティ

ヘッドレス CMS は、従来の CMS と比較して一部のセキュリティ上の利点があります。最大の利点は、プレゼンテーション層が CMS から分離されているため、攻撃者がシステム全体をコントロールするのが難しいことです。

しかし、ヘッドレス CMS でも以下のようなセキュリティ対策が必要です。

• 認証と承認: API キーの適切な管理や、各エンドポイントの権限の設定など。
• コンテンツセキュリティ: サニタイズされていないコンテンツが API 経由で送信されると、クロスサイトスクリプティング (XSS) 攻撃のリスクがあります。
• DDoS 攻撃: サーバーレスアーキテクチャを使用すると、一部の DDoS 攻撃から保護することができます。

ヘッドレス CMS から取得したデータを表示する

基本的なソースコードの例を見てみましょう。この例では、ヘッドレス CMS から取得したデータを表示する Next.js のページを作成します。

// pages/posts.tsx
import { GetServerSideProps } from 'next'

type Post = {
  id: string
  title: string
  body: string
}

type PostsPageProps = {
  posts: Post[]
}

const PostsPage = ({ posts }: PostsPageProps) => (
  <div>
    {posts.map((post) => (
      <div key={post.id}>
        <h2>{post.title}</h2>
        <p>{post.body}</p>
      </div>
    ))}
  </div>
)

export const getServerSideProps: GetServerSideProps = async () => {
  const res = await fetch('https://example.com/api/posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
  }
}

export default PostsPage

まずはじめにファイル名は pages/posts.tsx です。Next.js では、pages ディレクトリ下に配置された .tsx ファイルが自動的にルーティングされます。このファイルは /posts の URL でアクセス可能なページとなります。