ヘッドレス CMS 2026 — Sanity / Contentful / Strapi 5 / Payload (Figma 買収) / Directus / Keystatic / Storyblok 徹底比較

プロローグ — 「コンテンツはどこに住むべきか」

2026 年、あるマーケティング PM の言葉。

「Next.js で作り直しています。コンテンツモデルは誰が決めますか? マーケターがテキストと画像を直接変更できる必要があって、多言語対応も必要で、ビルダーでページを組み立てたくて、それでいて開発者は MDX でも書けると嬉しい」

これが 2026 年のごく普通の要望だ。「CMS を入れよう」が答えではなくなった。エディタ UX、データモデル、API の形、デプロイモデル、価格、ロックイン という五軸のマトリクスで、自分たちのチームの位置を見つけなければならない。

この記事は 2026 年 5 月時点のヘッドレス CMS 市場を 1 枚に並べ、それぞれの CMS の強み・弱み・直近 12 ヶ月の変化を整理する。Strapi 5 の Document Service(2024.9)、Payload の Figma 買収(2024.9)を巡る OSS コミュニティの論争、GraphCMS から改名した Hygraph の現状 まで — 決定を後回しにせず、一度整理しよう。

1. 2026 年のヘッドレス CMS マップ — 四つの部族

まず市場を 4 つの部族に切る。1 つの CMS が 2 つの部族にまたがる場合もあるが、主たる運用モデル で分類する。

この分類が重要なのは、エディタ UX、運用責任、ロックインの度合い が部族ごとに違うからだ。

• SaaS: エディタ UX 最高、運用責任なし、ロックイン大(データの export はできるが、API・画像変換・リアルタイムは消える)。
• OSS セルフホスト: ロックイン小、運用責任大(DB・バックアップ・スケール)。コンテナで上げれば単純だが、マーケターに優しい UX は自分の責任。
• Git ベース: ロックインほぼゼロ(コンテンツが自分のリポジトリに markdown としてある)、ただしマーケターが GitHub にログインする摩擦あり。
• ビジュアル: マーケター自由度最高、開発者がデザインシステムの一貫性を保つのが難しいページが生まれる。

軸でまとめるとこうなる。

ここからは部族別に見ていく。

2. Sanity — リアルタイムの標準

Sanity は 2017 年にノルウェーで始まり、2026 年のヘッドレス CMS 市場で 開発者がもっとも好む SaaS の地位を固めつつある。

コア特性

• Sanity Studio — コンテンツモデルを TypeScript コードで定義するエディタ UI。マーケターが使う画面そのものが自分のリポジトリ内のコード。
• GROQ — GraphQL ではなく独自のクエリ言語。JSON のような構文で深い join とフィルタリング。
• Portable Text — 単純な markdown ではなく、任意のブロックを差し込める JSON ベースのリッチテキスト。
• リアルタイム — 複数のエディタが同じドキュメントを同時編集すると Google Docs のように見える。
• Content Lake — ホステッドデータストア、アセット CDN と画像変換を内蔵。

// schemaTypes/post.ts — Sanity Studio のスキーマ
import { defineField, defineType } from 'sanity'

export const post = defineType({
  name: 'post',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: (r) => r.required() }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }] }),
    defineField({
      name: 'author',
      type: 'reference',
      to: [{ type: 'author' }],
    }),
  ],
})

GROQ のクエリはこんな見た目。

// Next.js から記事一覧を取得
import { createClient } from '@sanity/client'

const client = createClient({
  projectId: 'abc',
  dataset: 'production',
  apiVersion: '2026-05-16',
  useCdn: true,
})

const posts = await client.fetch(`
  *[_type == "post" && defined(slug.current)]
  | order(publishedAt desc)[0...10]{
    title, "slug": slug.current, publishedAt,
    author->{name, avatar}
  }
`)

2026 年の変化

• AI Assist — 2024–2025 年に追加された LLM ベースの翻訳・要約・alt 生成が安定化。
• Sanity Connect — Shopify や Stripe など外部システムからデータを取り込むコネクタ。
• Live Content API — GROQ クエリを subscribe してデータ変更時に push 受信。ダッシュボードやリアルタイムサイトに有効。

強みと弱み

誰が選ぶべきか

• コンテンツモデルが複雑で頻繁に変わるチーム。
• 多言語・多チャネル・多地域のコンテンツを 1 箇所で管理する必要があるチーム。
• 複数のエディタが同時に作業するマガジン・メディア。

3. Contentful — エンタープライズのデフォルト

Contentful は 2013 年ベルリン発で、2026 年も エンタープライズヘッドレス CMS のデフォルト だ。大企業の RFP にはほぼ必ず登場する。

コア特性

• Content Model — Web UI でフィールドを定義、タイプシステム(Symbol・Text・Reference・Asset・JSON)。
• Compose — ページ単位の編集 UI(エンタープライズ向けアドオン)。
• GraphQL / REST / CDN API — 全て対応、グローバル CDN。
• App Framework — エディタに自前アプリを組み込んでワークフローを拡張。
• Locales — 多言語をファーストクラスでサポート。

// Contentful の GraphQL クエリ
const query = `
  query {
    postCollection(limit: 10, order: publishDate_DESC) {
      items {
        title
        slug
        publishDate
        author { name }
      }
    }
  }
`

const res = await fetch(
  `https://graphql.contentful.com/content/v1/spaces/${process.env.CONTENTFUL_SPACE_ID}/environments/master`,
  {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${process.env.CONTENTFUL_TOKEN}`,
    },
    body: JSON.stringify({ query }),
  },
)

強みと弱み

誰が選ぶべきか

• 大企業・金融・メディアなどコンプライアンス・SLA が必須のチーム。
• コンテンツワークフロー(作成 → レビュー → 公開)が定型化されている組織。
• 多言語の言語数が多く、言語ごとに専属エディタが付く運用。

4. Strapi 5(2024.9) — Plugins v5 + Document Service

Strapi はフランス発の OSS ヘッドレス CMS。Node/TS ベース、MIT ライセンス。2024 年 9 月に Strapi 5 が正式リリースされ、2026 年現在の入り口は v5。

v5 のキーチェンジ

• Document Service API — v4 の Entity Service を置き換え。drafts・publish・locales を統一 API に。
• Plugins v5 — プラグインマーケット整備、TypeScript ファースト。
• Server-side React Admin — 管理画面を書き直し。
• Vite ベースのビルド — 管理画面のビルド時間が大幅短縮。

// Strapi 5 の Document Service API 例(カスタムルート内)
const documents = await strapi.documents('api::article.article').findMany({
  filters: { publishedAt: { $notNull: true } },
  sort: { publishedAt: 'desc' },
  populate: ['author'],
  status: 'published',
  locale: 'en',
})

// drafts と published を明示的に扱うのが v5 の違い
const draft = await strapi.documents('api::article.article').findOne({
  documentId: 'abc123',
  status: 'draft',
})

強みと弱み

誰が選ぶべきか

• 自前インフラ(Kubernetes、Vercel 外)で運用したいチーム。
• データを自前 DB(Postgres)に置きバックアップ・レプリケーションまで支配したい組織。
• プラグインを自作してワークフローを拡張する意思のあるチーム。

5. Payload(Figma 買収 2024.9) — TS-first の論争

Payload は TypeScript-first のヘッドレス CMS。2021 年登場、急速に開発者ファンを集めた。2024 年 9 月、Figma が Payload を買収 し、直後に OSS コミュニティで懸念と論争が起きた — 「Figma が Payload を自社製品に統合するにつれ、オープンソースとしてのアイデンティティが薄れるのではないか」。

2026 年 5 月時点の観察: Payload は MIT ライセンスを維持 しており、コアはオープンに活発開発中だ。だが、Payload Cloud(ホステッド) と Figma 側の統合機能 が以前より速く増えている。コミュニティの一部はこれを「段階的な enclosure」と見ている。

コア特性

• TypeScript-first — スキーマが TS 型と統合、管理コンポーネントも React/TS。
• コードファースト設定 — コンテンツモデルを payload.config.ts に定義。
• ローカル API — Next.js のサーバーコンポーネントから DB に直接アクセスする関数呼び出し。
• Access Control — 関数で定義する権限。
• Blocks — ページビルダー風のコンポーネント組み立て。

// payload.config.ts
import { buildConfig } from 'payload'
import { mongooseAdapter } from '@payloadcms/db-mongodb'

export default buildConfig({
  collections: [
    {
      slug: 'posts',
      fields: [
        { name: 'title', type: 'text', required: true },
        { name: 'slug', type: 'text', required: true, unique: true },
        {
          name: 'content',
          type: 'richText',
        },
        {
          name: 'author',
          type: 'relationship',
          relationTo: 'users',
        },
      ],
      access: {
        read: () => true,
        create: ({ req }) => Boolean(req.user),
      },
    },
  ],
  db: mongooseAdapter({ url: process.env.MONGODB_URI! }),
})

// Next.js のサーバーコンポーネントから直接問い合わせ
import { getPayload } from 'payload'
import config from '@/payload.config'

export default async function PostPage({ params }: { params: { slug: string } }) {
  const payload = await getPayload({ config })
  const result = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  })
  const post = result.docs[0]
  return <article>{post.title}</article>
}

Figma 買収の含意

• 追い風 — 資本・人員確保でコア開発速度が増す、Figma デザインシステムとの統合可能性。
• 懸念 — ホステッド製品に機能が先に入り OSS が後回しになるリスク、ライセンス変更の可能性(他社の前例あり)。
• 現在 — MIT 維持、コア活発コミット。ただし意思決定権は買収企業にあるため、ロックインリスク評価は自分で。

誰が選ぶべきか

• TS 開発者がコアユーザーのチーム。
• コンテンツモデルがコードでバージョン管理されるべきワークフロー。
• Next.js・React と深く統合したいチーム(サーバーコンポーネントから直接呼べる)。

6. Directus — DB から API へ、逆向きに作る

Directus の出発点は変わっている。ほとんどの CMS が「管理 UI から DB へ」と進むのに対し、Directus は 既存の SQL DB に被せて、自動で管理 UI と REST/GraphQL API を生成 する。つまり既存データをそのまま CMS にする。

コア特性

• DB-first — Postgres・MySQL・SQLite・MSSQL をそのまま使う。
• 自動 API — テーブル定義から REST・GraphQL を自動生成。
• ノーコード管理 — マーケターが使う画面。
• Flows — 条件・Webhook・スクリプト自動化。
• 拡張 — Extensions で hooks・endpoints・panels を追加。

-- 既存の articles テーブル
CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT NOT NULL,
  slug TEXT UNIQUE NOT NULL,
  content TEXT,
  published_at TIMESTAMPTZ
);

このテーブルを Directus に繋ぐだけで、即座に管理 UI と API が生まれる。

# REST で取得
curl "https://cms.example.com/items/articles?fields=*,author.*&filter[status][_eq]=published"

# GraphQL で取得
curl -X POST https://cms.example.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query":"{ articles(filter:{status:{_eq:\"published\"}}){ title slug }}"}'

強みと弱み

誰が選ぶべきか

• 既に SQL DB で運用しているデータをマーケターに公開したいチーム。
• サイトだけでなく社内運用ツールまで 1 つの管理に束ねたい組織。
• データ・CMS・管理ツールの 3 つを 1 つに統合したい時。

7. Cosmic / Builder.io — ビジュアル + ヘッドレス

この 2 つは「マーケターがページを自分で作る」が中心価値。

Cosmic

• 2014 年スタート、SaaS ヘッドレス CMS。
• やや SaaS 標準的なコンテンツオブジェクトモデル(オブジェクト・メタフィールド)。
• Next.js・React のスターターが豊富、小規模チームの素早い立ち上げに最適。
• 直近で AI ベースのコンテンツ生成・翻訳機能を強化。

Builder.io

• ビジュアルページビルダー + ヘッドレス API。
• ドラッグ&ドロップエディタ でマーケターが React コンポーネントからページを組む。
• Visual Copilot — Figma デザインをコードに変換。
• A/B テスト・パーソナライゼーションを内蔵。
• Mitosis でコンポーネントを複数フレームワークに変換。

// Next.js で Builder.io のページをレンダー
import { builder, BuilderComponent } from '@builder.io/react'

builder.init(process.env.NEXT_PUBLIC_BUILDER_KEY!)

export default async function Page({ params }: { params: { slug: string[] } }) {
  const content = await builder
    .get('page', { url: '/' + params.slug.join('/') })
    .toPromise()

  return <BuilderComponent model="page" content={content} />
}

誰が選ぶべきか(両方)

• マーケティング・コンテンツチームが開発者なしでページを直接作りたい時。
• ランディング・キャンペーンが頻発する EC・SaaS。
• ページ単位の A/B テスト・パーソナライゼーションが必要な運用。

ただし デザインシステムの一貫性 を失いやすい。利用可能なコンポーネントカタログを事前に絞っておくのが鍵。

8. Keystatic(Thinkmill) — Git ベース TS-first

Keystatic はオーストラリアの Thinkmill が作り、Mark Pinches がコアメンテナーの 1 人。2023 年登場で、2026 年現在 Git ベース CMS の TS-first 代表 として定着した。

コア特性

• コンテンツが Git リポジトリの markdown/YAML/JSON として保存 — DB なし。
• スキーマが TypeScript コード — 型安全。
• ローカル管理 UI — localhost で markdown をビジュアル編集。
• GitHub App モード — GitHub OAuth でマーケターが管理にログイン、変更は commit/PR で。
• Next.js・Astro・Remix と統合。

// keystatic.config.ts
import { config, fields, collection } from '@keystatic/core'

export default config({
  storage: { kind: 'github', repo: 'me/blog' },
  collections: {
    posts: collection({
      label: 'Posts',
      slugField: 'title',
      path: 'content/posts/*',
      format: { contentField: 'content' },
      schema: {
        title: fields.slug({ name: { label: 'Title' } }),
        publishedAt: fields.date({ label: 'Published' }),
        content: fields.markdoc({ label: 'Content' }),
      },
    }),
  },
})

強みと弱み

誰が選ぶべきか

• ブログ・ドキュメントサイト・小規模マーケティングサイト。
• コンテンツも PR ベースのワークフローで管理したい開発者チーム。
• 「外部 SaaS にコンテンツを置きたくない」が強い要件である組織。

9. Storyblok — ビジュアルエディタの強者

Storyblok はオーストリア発の SaaS ヘッドレス CMS。2017 年スタートで、ビジュアルエディタ が最大の差別化。

コア特性

• Visual Editor — サイトのプレビュー上で直接クリックして編集。
• Bloks — ページ = ブロックの組み合わせ。ブロック = コンポーネント。
• CDN API — グローバルキャッシュ。
• 多言語 — フィールド単位翻訳またはフォルダ単位。
• Pipelines — ワークフロー管理。

// Next.js で Storyblok ページを取得
import { storyblokInit, apiPlugin, getStoryblokApi } from '@storyblok/react'

storyblokInit({ accessToken: process.env.STORYBLOK_TOKEN, use: [apiPlugin] })

export default async function Page({ params }: { params: { slug: string[] } }) {
  const slug = params.slug?.join('/') || 'home'
  const sb = getStoryblokApi()
  const { data } = await sb.get(`cdn/stories/${slug}`, { version: 'published' })
  return <StoryblokComponent blok={data.story.content} />
}

強みと弱み

誰が選ぶべきか

• マーケティングチームがページを直接作りつつコンポーネント統制は維持したい時。
• 多言語サイトでグローバルキャンペーンを頻繁に回すブランド。
• EC・B2B SaaS のマーケティングサイト。

10. Hygraph(旧 GraphCMS) — GraphQL ファースト

GraphCMS は 2022 年に Hygraph へリブランド。名前は変わったが、GraphQL ファーストのヘッドレス CMS というアイデンティティはそのまま。

コア特性

• GraphQL ネイティブ — REST でなく GraphQL が一次 API。
• Content Federation — 外部 GraphQL ソースを結合。
• i18n ファーストクラス — Localizations。
• Stages — DRAFT・PUBLISHED などのステージモデル。
• Asset Pipeline — 画像変換・最適化を内蔵。

# Hygraph GraphQL クエリ
query Posts {
  posts(orderBy: publishedAt_DESC, first: 10, locales: [en, ko]) {
    id
    title
    slug
    publishedAt
    author {
      name
    }
  }
}

誰が選ぶべきか

• 既存インフラが既に GraphQL 中心。
• 複数のデータソースを GraphQL Federation でまとめたいチーム。
• 多言語がコンテンツモデルの中心軸。

11. Prismic / Hashnode / Outstatic — その他 SaaS と Git

Prismic

• 2013 年フランス発、老舗 SaaS CMS。
• Slices — マーケターがページに差し込む再利用コンポーネント片。
• 小規模チームに合理的な価格。
• 強み: 安定性・多言語。弱み: 革新速度は Sanity・Storyblok より遅い。

Hashnode

• 開発者ブログ・ニュースレター特化の SaaS。
• 独自 CDN・SEO・ニュースレター配信を内蔵。
• 寛大な無料 tier、独自ドメイン無料。
• ヘッドレス API も提供し、自前サイトの背後で Hashnode をコンテンツバックエンドに使える。
• 誰が: 個人開発者・技術ブロガー。

Outstatic

• Next.js フレンドリーな Git ベース CMS。
• Keystatic と似たが Next.js 統合を最優先。
• GitHub OAuth で管理、markdown コミット。
• 誰が: Next.js で小規模サイトを素早く立ち上げる 1 人開発者。

12. Dato CMS / ButterCMS / KeystoneJS — その他ヘッドレス

Dato CMS

• イタリア発の SaaS ヘッドレス CMS。
• Modular Content — ブロックベースのリッチテキスト。
• 画像パイプライン — imgix 統合。
• 強み: 豊富なフィールドタイプ・画像処理。弱み: 価格が速く上がる。

ButterCMS

• API ファーストの SaaS CMS、小規模チームに優しい。
• 価格が明快で単純。
• マルチサイト対応が強み。
• 誰が: 小規模会社がブログ・マーケティングページを素早く立ち上げる時。

KeystoneJS

• TypeScript-first OSS ヘッドレス(Thinkmill 製、Keystatic とは別プロジェクト)。
• Prisma ベースのデータモデル、GraphQL API 自動生成。
• 管理 UI 同梱。
• 誰が: セルフホストで強力なデータモデルが必要なチーム。

13. Ghost / WordPress headless / Webflow / Notion — 非伝統的 CMS

この 4 つは「ヘッドレス専用に生まれていないがヘッドレスとして使う」部族。

Ghost

• Node ベースのブログ・ニュースレタープラットフォーム。
• ネイティブエディタ UX がもっとも洗練されている部類。
• Content API でヘッドレス利用が可能。
• 誰が: ライター・ニュースレター・1 人メディア。

WordPress headless

• 2026 年もインターネットの大きな部分が WordPress。
• WP REST API または WPGraphQL でヘッドレスモード。
• 強み: 豊富なプラグイン・マーケターに馴染み。弱み: WP の運用負担、セキュリティ。
• 誰が: 既に WP にコンテンツが多い組織がフロントエンドだけ Next.js に移したい時。

Webflow

• サイトビルダーだが CMS Collections を API として公開。
• デザイナー・マーケターがデザインとコンテンツを並行運用。
• ヘッドレスモード: Webflow をコンテンツバックエンドにし、フロントは Next.js。
• 誰が: デザイナー主導のマーケティングサイト。

Notion as CMS

• Notion API + ビルド時 fetch でサイトを構築するパターン。
• 摩擦が最小のエディタ(全会社が既に Notion を使う)。
• 弱み: API レートリミット、画像 URL の期限切れ、コンテンツモデリングの制約。
• 誰が: 初期スタートアップのマーケティングサイト・ドキュメントサイト。

14. decap CMS(旧 Netlify CMS) / Statamic — Git ベースとフラットファイル

decap CMS(旧 Netlify CMS)

• もとは Netlify CMS、2023 年に decap CMS へ改名・コミュニティ運営へ移行。
• Git ベース、markdown コミット、GitHub/GitLab/Bitbucket OAuth。
• 静的サイトジェネレータ(Hugo・Jekyll・Astro・Next.js)と組み合わせて使われることが多い。
• 強み: 無料、ロックイン 0。弱み: コミュニティ主導でリリース頻度がまばら。

Statamic

• Laravel ベースの フラットファイル CMS(DB 不要)。
• コンテンツが YAML/markdown としてファイルシステムに保存。
• 自前の管理 UI 同梱。
• ヘッドレスモード(GraphQL/REST API)もサポート。
• 誰が: Laravel に慣れたチームが、コンテンツもファイルベースで持ちたい時。

15. 韓国 — Markdown CMS トレンドとカカオコンテンツ

2026 年の韓国でのヘッドレス CMS 利用パターンの特徴。

Markdown / Git ベース利用の増加

• velog・tistory などのホステッドブログから Next.js + Contentlayer / Keystatic / Outstatic によるセルフホストサイトに移る開発者が増えた。
• 2024–2026 年の採用市場で「自分の技術ブログ」が評価項目になり、ロックインのない markdown CMS の需要が増えた。

カカオコンテンツ / Brunch / Naver

• カカオ Brunch Story は作家登録制 SaaS で、API 公開はほぼなし。ヘッドレス利用は難しい。
• Naver ブログ・Tistory も外部公開は RSS 程度。
• 韓国メディア企業(JoongAng・Hankyung 等)は社内 CMS(自社ビルド + WP/Drupal 中心)が多く、徐々にヘッドレスへ移行中。

SaaS 利用

• 韓国企業も Contentful・Sanity・Storyblok の導入事例が増加。とくに グローバルサイト(EN/KO/JA/ZH) が必要な EC・ゲーム会社。
• LINE・Kakao・Coupang など規模の大きいところは自前 CMS・ツールチェーンを維持。

韓国語検索・SEO の考慮

• 韓国 SEO は Naver の検索シェアが依然大きく、Naver のコンテンツインデックスはサイトマップ・RSS への依存が大きい。ヘッドレスサイトほど SSG・ISR で静的 HTML を適切に出すことが重要。

16. 日本 — microCMS、Newt、Storyblok 日本

日本は ローカル SaaS CMS が強い市場だ。

microCMS

• 日本で作られた SaaS ヘッドレス CMS、2019 年スタート。
• 日本語 UI・日本語ドキュメント完備、日本企業がもっとも使うヘッドレス CMS の 1 つ。
• コンテンツ API・管理 API・画像 API を分離。
• 日本企業に優しい価格、JPY 決済。
• 誰が: 日本市場中心のサイト(EC・メディア・コーポレート)。

// microCMS クライアント
import { createClient } from 'microcms-js-sdk'

const client = createClient({
  serviceDomain: 'example',
  apiKey: process.env.MICROCMS_API_KEY!,
})

const data = await client.get({
  endpoint: 'posts',
  queries: { limit: 10, orders: '-publishedAt' },
})

Newt

• 2021 年日本で登場した SaaS ヘッドレス CMS、microCMS の競合。
• 日本語ファースト UX・国内決済。
• GraphQL・CDN API 両対応。
• 誰が: microCMS とほぼ同ペルソナ、よりモダンな UX を好む層。

Storyblok 日本進出

• Storyblok が 2023–2024 年に本格的に日本市場参入。
• 日本語 UI・日本決済対応。
• 日本の大企業がグローバルサイトを作る際、microCMS の代わりに Storyblok を選ぶ事例が出現。

Contentful・Sanity 利用

• 日本の大企業の一部は Contentful 利用。特にグローバルコンプライアンスが必要な金融・自動車。
• Sanity は日本市場シェアこそ小さいがデザイン・メディア系スタートアップで選択肢として浮上。

17. 誰が何を選ぶべきか — 意思決定ガイド

選択ミスのシグナル

• マーケターが毎回開発者に変更依頼してくる → CMS のエディタ UX が間違っている。
• コンテンツの export が怖くて CMS を変えられない → SaaS のロックインが大きすぎる。
• コンテンツ量に比例してビルド時間が爆発する → SSG-only を ISR/SSR に移すか、SaaS の CDN をもっと使うかを検討。
• 多言語が常に手間取る → i18n がファーストクラスでない CMS を選んだ可能性。
• 画像変換を自前でやっている → CDN 内蔵 CMS への移行、または Cloudinary・imgix を追加。

マイグレーションコストの目安

• SaaS から SaaS: データ export → import マッピング + 画像再アップロード。コンテンツ 1000 件あたり 1–2 週。
• SaaS からセルフホスト: 上記 + インフラセットアップ。2–4 週。
• WordPress からヘッドレス: コンテンツモデル再定義 + ルーティング再設計。2–6 週(ブログ) / 2–6 ヶ月(大規模サイト)。
• Git から SaaS: markdown から CMS フィールドへのマッピングスクリプト。1–2 週。

おわりに — コンテンツは資産

CMS を選ぶことは コンテンツ資産をどこに置くかを決める ことだ。ツールは 5 年ごとに乗り換えられるが、その間に積み上げたコンテンツは自社の資産だ。

2026 年 5 月時点の 1 行サマリ。

• 自由と統制: Strapi 5、Payload、Directus、Keystatic。
• マーケター UX と多言語: Sanity、Contentful、Storyblok。
• ロックインのない小規模サイト: Keystatic、Outstatic、Hashnode、decap。
• ビジュアル・ページビルダー: Builder.io、Storyblok、Webflow。
• 日本市場: microCMS、Newt。

ルールは 2 つだけ。第 1 に、データ export を保証する CMS を選べ。 第 2 に、マーケターが毎日使う UI を自分で 1 度使ってみろ。 残りはカタログのディテール。

参考 / References

• Sanity — https://www.sanity.io/
• Sanity GROQ docs — https://www.sanity.io/docs/groq
• Contentful — https://www.contentful.com/
• Strapi 5 release notes — https://strapi.io/blog/strapi-5
• Strapi Document Service API — https://docs.strapi.io/dev-docs/api/document-service
• Payload CMS — https://payloadcms.com/
• Payload joins Figma (2024-09) — https://payloadcms.com/blog/payload-joins-figma
• Directus — https://directus.io/
• Cosmic CMS — https://www.cosmicjs.com/
• Builder.io — https://www.builder.io/
• Keystatic — https://keystatic.com/
• Storyblok — https://www.storyblok.com/
• Hygraph (formerly GraphCMS) — https://hygraph.com/
• Prismic — https://prismic.io/
• Hashnode — https://hashnode.com/
• Outstatic — https://outstatic.com/
• Dato CMS — https://www.datocms.com/
• ButterCMS — https://buttercms.com/
• KeystoneJS — https://keystonejs.com/
• Ghost — https://ghost.org/
• WPGraphQL — https://www.wpgraphql.com/
• Webflow — https://webflow.com/cms
• Notion API — https://developers.notion.com/
• decap CMS — https://decapcms.org/
• Statamic — https://statamic.com/
• microCMS — https://microcms.io/
• Newt — https://www.newt.so/