💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

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

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 つの部族にまたがる場合もあるが、**主たる運用モデル** で分類する。

| 部族 | 定義 | 代表例 |

| --- | --- | --- |

| SaaS ホステッド | ベンダーがホスト、API のみ公開、月額課金 | Sanity, Contentful, Storyblok, Hygraph, Prismic, Dato, ButterCMS, Cosmic, Hashnode, microCMS, Newt |

| オープンソースセルフホスト | 自前サーバーにデプロイ、DB は自分で運用 | Strapi 5, Payload, Directus, KeystoneJS, Ghost, WordPress, Statamic |

| Git ベース | コンテンツを Git リポジトリにコミット、ビルド時に処理 | Keystatic, Outstatic, decap CMS(旧 Netlify CMS), Contentlayer/MDX |

| ビジュアル・ページビルダー | マーケターがドラッグでページ自体を作る | Builder.io, Storyblok(ビジュアル面), Webflow, Notion |

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

- SaaS: エディタ UX 最高、運用責任なし、ロックイン大(データの export はできるが、API・画像変換・リアルタイムは消える)。

- OSS セルフホスト: ロックイン小、運用責任大(DB・バックアップ・スケール)。コンテナで上げれば単純だが、マーケターに優しい UX は自分の責任。

- Git ベース: ロックインほぼゼロ(コンテンツが自分のリポジトリに markdown としてある)、ただしマーケターが GitHub にログインする摩擦あり。

- ビジュアル: マーケター自由度最高、開発者がデザインシステムの一貫性を保つのが難しいページが生まれる。

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

| --- | --- | --- | --- | --- |

| マーケター UX | 最高 | 普通 | 低い | 最高 |

| 開発者の自由度 | 普通 | 高い | 非常に高い | 低い |

| ロックインリスク | 大 | 小 | ほぼなし | 大 |

| 運用負担 | なし | 大 | ほぼなし | なし |

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

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 のスキーマ

export const post = defineType({

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({

type: 'reference',

to: [{ type: 'author' }],

}),

})

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

// Next.js から記事一覧を取得

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 受信。ダッシュボードやリアルタイムサイトに有効。

強みと弱み

| 強み | 弱み |

| --- | --- |

| リアルタイム協調 UX | GROQ の学習コスト |

| schema-as-code(Git 追跡) | 自由度が高すぎて初期構造化に時間がかかる |

| 画像 CDN と変換を内蔵 | 価格が利用量で急速に上がる |

| 強力な参照(references) | マイグレーションは自分で書く |

誰が選ぶべきか

- コンテンツモデルが複雑で頻繁に変わるチーム。

- 多言語・多チャネル・多地域のコンテンツを 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・SOC 2・HIPAA | 価格が非常に速く上がる |

| ロケール・環境分離が成熟 | 無料 tier が狭く段差が大きい |

| GraphQL・REST・CDN すべて安定 | スキーマがコードではない(UI 定義) |

| ワークフロー・承認フロー豊富 | UX は SaaS の中では保守的 |

誰が選ぶべきか

- 大企業・金融・メディアなどコンプライアンス・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',

})

強みと弱み

| 強み | 弱み |

| --- | --- |

| MIT、セルフホスト可 | 運用責任は自分(DB・画像・バックアップ) |

| プラグインエコシステム | i18n・draft モデルが v4 から v5 で作り直し |

| TS フレンドリー | 管理 UI は SaaS 競合より素朴 |

| Strapi Cloud オプションあり | 大規模データセットで admin パフォーマンス報告 |

誰が選ぶべきか

- 自前インフラ(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

export default buildConfig({

collections: [

{

slug: 'posts',

fields: [

{ name: 'title', type: 'text', required: true },

{ name: 'slug', type: 'text', required: true, unique: true },

{

type: 'richText',

{

type: 'relationship',

relationTo: 'users',

access: {

read: () => true,

create: ({ req }) => Boolean(req.user),

db: mongooseAdapter({ url: process.env.MONGODB_URI! }),

})

// Next.js のサーバーコンポーネントから直接問い合わせ

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 }}"}'

強みと弱み

| 強み | 弱み |

| --- | --- |

| 既存 DB をそのまま活用 | コンテンツ専用ユースケースには過剰一般化 |

| BSL ライセンス(小規模は無料) | BSL なので一部企業は要検討 |

| Flows で強力な自動化 | リッチテキスト・ブロックモデルは SaaS 競合より弱い |

| データスキーマが SQL そのまま | i18n は自前モデリング |

誰が選ぶべきか

- 既に 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 のページをレンダー

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

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' }),

}),

})

強みと弱み

| 強み | 弱み |

| --- | --- |

| コンテンツが自分のリポジトリにある(ロックイン 0) | 同時編集は Git workflow の制約で弱い |

| TS スキーマ、型安全 | マーケターが GitHub アカウント・OAuth に慣れる必要 |

| 無料(ホスティング・DB なし) | 大容量アセット(画像)は CDN を別途構成 |

| ビルド時にそのまま取り込み | 多段階ワークフロー(承認)は PR で解決 |

誰が選ぶべきか

- ブログ・ドキュメントサイト・小規模マーケティングサイト。

- コンテンツも PR ベースのワークフローで管理したい開発者チーム。

- 「外部 SaaS にコンテンツを置きたくない」が強い要件である組織。

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

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

コア特性

- **Visual Editor** — サイトのプレビュー上で直接クリックして編集。

- **Bloks** — ページ = ブロックの組み合わせ。ブロック = コンポーネント。

- **CDN API** — グローバルキャッシュ。

- **多言語** — フィールド単位翻訳またはフォルダ単位。

- **Pipelines** — ワークフロー管理。

// Next.js で Storyblok ページを取得

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} />

}

強みと弱み

| 強み | 弱み |

| --- | --- |

| マーケターに優しいビジュアルエディタ | ブロックコンポーネントのカタログ設計が重要 |

| 多言語が成熟 | 価格が利用量で急上昇 |

| グローバル CDN | コンテンツモデルが SaaS UI 定義(schema-as-code 弱い) |

| ワークフロー豊富 | API レスポンスのサイズが大きい |

誰が選ぶべきか

- マーケティングチームがページを直接作りつつコンポーネント統制は維持したい時。

- 多言語サイトでグローバルキャンペーンを頻繁に回すブランド。

- 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]) {

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 クライアント

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. 誰が何を選ぶべきか — 意思決定ガイド

| ユースケース | 第 1 候補 | 第 2 候補 | 備考 |

| --- | --- | --- | --- |

選択ミスのシグナル

- **マーケターが毎回開発者に変更依頼してくる** → 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/