---
title: "ヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/1317/"
published: 2023-09-11
updated: 2026-10-19
categories: ["CMS"]
publisher: "株式会社一創"
---

# ヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】

ヘッドレスCMSとは、コンテンツの入力・管理だけを受け持ち、表示（ヘッド）を持たずにREST APIやGraphQL APIでコンテンツをJSONとして配信するCMSです。WordPressのような従来型CMSが管理画面とWebページの生成を1つのシステムで抱えるのに対し、ヘッドレスCMSはページを作りません。画面はNext.jsなどで別に作り、CMSからデータを取りに行きます。この記事では、仕組みと従来型との違い、microCMS・Contentful・Sanity・Strapiの2026年10月時点の料金と課金のされ方、導入後に必ず必要になるプレビューと更新反映の実装、APIキーの守り方、そして2026年11月24日に終了する国産ヘッドレスCMS「Newt」の例から見る出口設計までを、公式情報に沿って整理します。

## まとめ：ヘッドレスCMSの定義と選定の結論

- **定義**：管理画面とコンテンツ配信APIだけを持つCMS。表示はReact／Next.jsなどで別に作る。
- **従来型との違い**：従来型はサーバーがHTMLを組み立てて返す一体型。ヘッドレスは同じコンテンツをWeb・アプリ・サイネージへAPIで配る分離型。
- **料金の見方**：microCMSはデータ転送量とAPI数、Sanityは席数、Strapi CloudはAPIリクエスト数で課金が伸びる。無料枠の上限に当たったときの挙動（API停止か従量課金か）まで確認する。
- **導入後に必要な実装**：下書きプレビュー、公開時の再ビルドまたは再検証、APIキーをブラウザに出さない取得経路の3つ。
- **選ぶべきでない場面**：更新頻度の低い小規模サイトで、フロントを保守するエンジニアがいない場合。WordPressなど従来型のほうが早く安く回る。

以下、仕組みから順に根拠を示します。

## ヘッドレスCMSの仕組みとコンテンツ配信API

「ヘッド」は閲覧者が見る表示層を指します。ヘッドレスCMSはこの表示層を持たず、管理画面で入力された記事タイトル・本文・画像URLなどを構造化データとして保存し、APIで外部へ渡します。CMS側はHTMLを組み立てません。

### REST・GraphQLでJSONを返す配信の流れ

フロントエンドはAPIにリクエストを送り、返ってきたJSONを画面に描画します。RESTはエンドポイントごとに決まった形のデータを返し、GraphQLは画面に必要なフィールドだけを1回の問い合わせで取れます。microCMSの場合、一覧取得は `GET /api/v1/{endpoint}` で、リクエストヘッダー `X-MICROCMS-API-KEY` に読み取り権限を持つキーを付けます（[microCMSのGET APIリファレンス](https://document.microcms.io/content-api/get-list-contents)）。同じAPIをWebサイト・スマホアプリ・店頭サイネージが参照できるため、更新は1か所で済みます。

### SSG・ISR・SSRとの組み合わせと表示速度

表示速度はヘッドレスかどうかだけでは決まりません。レンダリング方式に加え、CMS APIの応答時間、キャッシュ、画像やJavaScriptの配信量にも左右されます。ビルド時にHTMLを作るSSGなら、公開ページはCDN上の静的ファイルとして返り、閲覧のたびにCMSやデータベースへ問い合わせません。Next.js 16.4（2026年10月時点の最新安定版）では、`fetch` は既定でキャッシュされず、`cache: 'force-cache'` や正の `next.revalidate` を指定すると、取得結果をData Cacheに保存できます（[Next.jsのfetchリファレンス](https://nextjs.org/docs/app/api-reference/functions/fetch)）。次の例は、取得結果にタグを付けてキャッシュし、後述のWebhookでタグ単位に更新するものです。microCMSのWebhookは失敗時に自動再送されないため、本番では通知失敗の監視と手動再検証の手段を用意してください。

```
// app/blog/page.tsx（Next.js App Router）
async function getPosts() {
  const res = await fetch("https://your-service.microcms.io/api/v1/blogs?limit=20", {
    headers: { "X-MICROCMS-API-KEY": process.env.MICROCMS_API_KEY! },
    cache: "force-cache",
    next: { tags: ["blogs"] },
  });
  if (!res.ok) throw new Error(`microCMS ${res.status}`);
  return res.json();
}
```

これはサーバーコンポーネントから呼び出す取得関数の抜粋です。ページとして動かすには、同じファイルにdefault exportするページコンポーネントを定義してgetPostsを呼び出します。サーバーコンポーネントから呼ぶ限り、APIキーはブラウザに送られません。SSG側のツール選定とビルド時間の考え方は[SSGとは？静的サイトジェネレーターの仕組みと企業サイト採用の判断基準](/column/details/17699/)で比較しています。

## 従来型CMS（WordPress）との違い：構成・運用・セキュリティの比較

WordPressなどの従来型CMSは、コンテンツ管理とテンプレートによるHTML生成を備える一体型です。ページキャッシュを使う構成では、生成済みのHTMLを返すため、アクセスのたびにHTMLを生成するとは限りません。違いは次の表のとおりです。

| 観点      | 従来型CMS        | ヘッドレスCMS           |
| ------- | ------------- | ------------------ |
| 構成      | 管理と表示が一体      | 管理と表示を分離           |
| HTML生成  | CMSのサーバー      | フロント側（SSG・SSR）     |
| 配信先     | 主にWebサイト      | Web・アプリ・サイネージ      |
| 見た目の変更  | テーマ・テンプレート    | フロントのコード           |
| 更新の担い手  | 非エンジニアだけで可    | 入稿は非エンジニア、画面はエンジニア |
| 公開側の攻撃面 | 管理画面・プラグインと同居 | 静的配信なら管理画面と分離      |

運用面の差が一番効きます。従来型は入稿者がプレビューを見ながら公開まで1人で完結しますが、ヘッドレスはプレビュー画面も公開時の反映もフロント側で作る必要があり、それを保守するエンジニアが継続して要ります。セキュリティ面では、静的配信にすれば公開サーバーからCMSへの経路が無くなる一方、代わりにAPIキーの管理が新しい攻撃面になります（後述）。

### WordPressをヘッドレス化する構成とハイブリッド型

WordPressは4.4でREST APIの基盤を、4.7で `wp/v2` のコア・エンドポイントを取り込んでおり、`/wp-json/wp/v2/posts` から投稿をJSONで取れます（[WordPress REST APIハンドブック](https://developer.wordpress.org/rest-api/using-the-rest-api/discovery/)）。管理画面はそのまま入稿に使い、表示だけをNext.jsで作るのが「ヘッドレスWordPress」です。既存の入稿フローと記事資産を残せるのが利点ですが、テーマ前提のプラグイン（表示を書き換えるSEO・フォーム・ページビルダー系）はフロント側で同じ機能を作り直すことになります。従来型の表示を残したまま一部のページやアプリにだけAPIで配る使い方は「ハイブリッド型」と呼ばれ、全面移行の前段として現実的です。Reactとの具体的な組み合わせ方は[WordPressとReactの連携方法：ヘッドレス構成とテーマ組み込みの使い分け](/tech/details/2059/)で扱っています。表示側をVercelに置く場合は[VercelでWordPressを使う構成：PHPを置けない理由とヘッドレス化・更新の即時反映](https://www.issoh.co.jp/tech/details/18585/)を参照してください。

## ヘッドレスCMSのメリットとデメリット（実務での重み順）

判断に効くのはデメリット側です。メリットは導入目的が合えば自然に得られますが、デメリットは体制が無いと運用を止めます。

### メリット：複数チャネル配信とフロントの作り替えやすさ

最大の利点は、1つのコンテンツをWeb・iOS／Androidアプリ・サイネージへ同じAPIから配れることです。更新の二重管理が消えます。次に、フロントの技術を後から作り替えてもコンテンツ側を移さずに済む点があります。画面をReactから別のフレームワークへ移す場合でも、CMSとAPIはそのまま使えます。

### デメリット：プレビュー・更新反映・初期開発が自前

重い順に並べると、下書きのプレビュー画面を自分で作る必要があること、公開した記事をサイトへ反映する再ビルドや再検証の仕組みが要ること、画面一式の初期開発費が上乗せされることです。Next.jsでSSGやキャッシュを使う場合は、CMSの公開操作と再ビルド・再検証を連携させます。毎回CMSから取得するSSRなら、再ビルドなしで公開内容を反映できます。プレビューと反映の具体的な作り方は後半の章でコードを示します。

## 主要ヘッドレスCMSの料金と課金軸の比較（2026年10月）

料金表の金額よりも、何が増えると請求が増えるか（課金軸）を見てください。アクセスが伸びたときに効くのは転送量やAPIリクエスト数、編集部が増えたときに効くのは席数です。金額は2026年10月11日に各社の公式料金ページで確認したもので、改定されることがあります。

| サービス       | 形態        | 無料枠      | 最安の有料               | 主な課金軸         |
| ---------- | --------- | -------- | ------------------- | ------------- |
| microCMS   | SaaS（国産）  | Hobby 0円 | Team 月4,900円〜       | 転送量・API数・席    |
| Contentful | SaaS      | Free $0  | Lite 月300ドル         | APIコール・席・ロケール |
| Sanity     | SaaS      | Free $0  | Growth $15／席・月      | 席・利用量         |
| Strapi     | OSS／Cloud | セルフホスト無料 | Cloud Starter $35／月 | APIリクエスト・転送量  |

同じ「無料」でも中身は違います。次の3つの節で、上限に当たったときの挙動まで分けて見ます。

### 国産SaaSのmicroCMS：転送量20GBでAPIが止まるHobby

microCMSは日本語の管理画面・ドキュメント・サポートで完結する国産サービスです。[microCMSの料金ページ](https://microcms.io/pricing)によると、無料のHobbyはAPIリクエスト無制限・メンバー3人・API 5個・コンテンツ1万件・データ転送量20GB/月で、転送量を超えると翌月1日までAPIが使えなくなります。有料のTeam（月4,900円〜・税抜）は転送量200GB/月で、超過分は1GBあたり20円の従量課金に変わります。Business（月75,000円〜）から権限管理・IP制限・複数環境・技術サポートが付きます。本番サイトをHobbyで動かすと、画像の多い記事が拡散した月にAPIが止まり、ページが表示できなくなる可能性があります。商用サイトでもHobbyは利用できますが、転送量超過によるAPI停止を許容できない場合はTeam以上を推奨します。

### 海外SaaSのContentfulとSanity：席と利用量で増える料金

Contentfulは[Contentfulの料金ページ](https://www.contentful.com/pricing/)でFreeを$0（ユーザー10人・ロケール2つ・API呼び出し月10万回）、Liteを月300ドル（ユーザー20人・ロケール3つ・API呼び出し月100万回）としています。無料の次がいきなり月300ドルで、ロケール数もプランの枠に入っているため、対応言語の数で必要なプランが変わります。APIの種類ごとの呼び出し数の増え方と移行手順は[Contentfulの解説記事](/tech/details/17724/)で実コードとともに扱っています。

Sanityは[Sanityの料金ページ](https://www.sanity.io/pricing)でFreeを$0（最大20席・データセット2つは公開のみ）、Growthを1席あたり月15ドル（最大50席）としています。編集者が10人いればGrowthは月150ドルです。Freeのデータセットは公開設定に限られるため、会員限定の記事など読み取りにも認証をかけたいデータを扱うサイトでは、有料プランを前提に見積もります。Sanity固有のGROQやStudioの使い方は[Sanity CMSの解説記事](/tech/details/8066/)にまとめています。

### セルフホスト対応のStrapi・Payload・Directus：ライセンス条件の違い

Strapiは2026年10月7日公開の5.57.0が最新版で、[リポジトリのLICENSE](https://github.com/strapi/strapi/blob/main/LICENSE)では `ee/` ディレクトリ外のCommunity EditionをMITライセンスで提供しています。セルフホストならライセンス費は不要で、費用はサーバーとデータベースの運用費になります。運用を任せる[Strapi Cloud](https://strapi.io/pricing-cloud)はStarterが1プロジェクト月35ドル（APIリクエスト月10万回・アイドル時はスリープ）、常時起動はPro（月90ドル）からです。Next.jsアプリの中にCMSを組み込むPayload（npmの最新3.90.2・MIT）も同じくTypeScript製です。注意したいのはDirectusで、v12.0.0（2026年6月）でライセンスがBSL 1.1から[MSCL-1.0-GPL](https://github.com/directus/directus/blob/main/license)に変わりました。MITのようなOSSライセンスではないソース公開型で、競合サービスとしての提供（Competing Use）やライセンスキー機能の回避は認められず、キー無しでは管理画面の席数やコレクション数に上限がかかります。セルフホストできることと無料で無制限に使えることは別なので、採用前にライセンス本文と必要な機能の利用条件を確認します。詳細は[Directusの解説記事](/tech/details/8081/)で検証しています。

## プレビューと更新反映を実装する手順（Next.js＋microCMSの例）

この章では、下書きを編集者だけに見せるプレビューと、公開した記事をキャッシュ済みのページへ反映する仕組みを、Next.js 16.4とmicroCMSの組み合わせで示します。

### 下書きプレビュー：画面プレビューのdraftKeyとDraft Mode

microCMSは管理画面の「API設定」→「画面プレビュー」で遷移先URLを登録でき、URLに `{CONTENT_ID}` と `{DRAFT_KEY}` を埋め込めます（[microCMSの画面プレビュー設定](https://document.microcms.io/manual/screen-preview)）。下書きは取得時に `draftKey` パラメータを付けると返ります。Next.js側は[Draft Mode](https://nextjs.org/docs/app/guides/draft-mode)で `__prerender_bypass` クッキーを立て、その閲覧者にだけキャッシュを迂回させます。遷移先URLを `https://example.com/api/draft?secret=…&id={CONTENT_ID}&draftKey={DRAFT_KEY}` にした場合のRoute Handlerは次のとおりです。

```
// app/api/draft/route.ts
import { draftMode, cookies } from "next/headers";
import { redirect } from "next/navigation";

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const id = searchParams.get("id");
  const draftKey = searchParams.get("draftKey");
  if (searchParams.get("secret") !== process.env.PREVIEW_SECRET || !id || !draftKey) {
    return new Response("Invalid token", { status: 401 });
  }
  // 下書きが実在するかをCMSに確かめてから有効化する
  const res = await fetch(
    `https://your-service.microcms.io/api/v1/blogs/${encodeURIComponent(id)}?draftKey=${encodeURIComponent(draftKey)}`,
    { headers: { "X-MICROCMS-API-KEY": process.env.MICROCMS_API_KEY! } },
  );
  if (!res.ok) return new Response("Invalid id", { status: 401 });
  const content = await res.json();
  if (content.id !== id) return new Response("Invalid id", { status: 401 });

  (await draftMode()).enable();
  (await cookies()).set("mc_draft_key", draftKey, { httpOnly: true, secure: true, path: "/" });
  redirect(`/blog/${id}`); // 遷移先はクエリ文字列でなくCMSで確認したIDから組み立てる
}
```

記事ページでは `(await draftMode()).isEnabled` が真のときだけ、`(await cookies()).get('mc_draft_key')?.value` を読み取り、その値を取得URLの `draftKey` パラメータに指定します。`secret` の照合と、遷移先をCMSで確かめたIDから組み立てる処理は、Next.jsの公式ガイドもオープンリダイレクト対策として求めています。

### 公開時の反映：Webhookからタグ単位で再検証

SSGやキャッシュを使うと、公開ボタンを押しただけではサイトが変わりません。microCMSのWebhook（カスタム通知）で公開・更新を通知し、Next.jsの `revalidateTag` で該当タグのキャッシュを古い扱いにします。microCMSはシークレット値を設定すると、リクエストボディをHMAC-SHA256で署名した値を `x-microcms-signature` ヘッダーに付けて送ります（[microCMSのWebhook設定](https://document.microcms.io/manual/webhook-setting)）。Next.js 16では引数1つの `revalidateTag(tag)` は非推奨で、第2引数に `"max"` を渡す形が推奨されています（[revalidateTagのリファレンス](https://nextjs.org/docs/app/api-reference/functions/revalidateTag)）。

```
// app/api/revalidate/route.ts
import { createHmac, timingSafeEqual } from "node:crypto";
import { revalidateTag } from "next/cache";

export async function POST(request: Request) {
  const body = await request.text(); // 署名は生のボディで計算する
  const expected = createHmac("sha256", process.env.MICROCMS_WEBHOOK_SECRET!).update(body).digest("hex");
  const signature = request.headers.get("x-microcms-signature") ?? "";
  if (Buffer.byteLength(signature) !== Buffer.byteLength(expected) ||
      !timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return new Response("Invalid signature", { status: 401 });
  }
  const { api } = JSON.parse(body) as { api: string }; // 例: "blogs"
  revalidateTag(api, "max"); // 次のアクセスで裏側から取り直す
  return Response.json({ revalidated: api });
}
```

ボディの `api` にはAPIのエンドポイント名が入るため、取得側でエンドポイント名と同じタグを付けておけば対応が取れます。`"max"` は「古い内容を返しながら裏で取り直す」動きなので、再検証が完了するまでのアクセスには旧版が返る場合があります。速報性が必要なページだけ `{ expire: 0 }` で即時に失効させる、と使い分けます。

## APIキーと認証情報の守り方

ヘッドレスCMSでは、公開サイトとCMSをつなぐのはAPIキーです。microCMSのリファレンスは「X-MICROCMS-API-KEYが判別できると、第三者による不正なコンテンツの操作が可能となります」と注意しています。公開サイト側で守ることは次のとおりです。

- **キーをブラウザに出さない**：取得はサーバーコンポーネント・ビルド時・Route Handlerで行う。`NEXT_PUBLIC_` 付きの環境変数に入れるとクライアントのJavaScriptに埋め込まれる。
- **権限を分ける**：公開サイト用は読み取り（GET）だけのキー、入稿の自動化には書き込みキーを別に発行する。microCMSのAPIキー数はHobbyで1個、Teamで3個まで。
- **下書き用の認証を別にする**：下書きを返すキーやトークンは公開用と分け、プレビュー経路でしか使わない。

CMSのAPI認証情報が悪用された実例として、集英社は2026年9月、ブロガー管理システムで「CMSの設定の不備に起因するAPI認証情報を狙った攻撃」により特権アカウントを作られ、2,835名分の情報が流出したと公表しました（CMS製品名は非公表）。経緯と開発側の対策は[集英社の不正アクセスでブロガー2,835名が流出｜CMS設定不備とAPI認証情報の守り方](/tech/details/18197/)で整理しています。

## サービス終了とロックインに備える出口設計

SaaS型のヘッドレスCMSは、提供元が終われば管理画面もAPIも止まります。国産ヘッドレスCMSの「Newt」は、2026年11月24日（火）13時59分でCMS App・Form Appを含む全サービスを終了すると告知しており、SDK（newt-client-js）のREADMEにも「管理画面・APIともにご利用いただくことができなくなります」と書かれています（[Newtのサービス終了に関するFAQ](https://www.newt.so/notice/newt-close-faq)）。利用者は期限までに別のCMSへデータとスキーマを移し、フロントの取得コードを書き換える必要があります。

選定時に確認しておくと移行が軽くなるのは次の3点です。コンテンツをAPIやCSVで一括エクスポートできるか（microCMSのCSVエクスポートはTeam以上）、リッチテキストがHTMLやMarkdownで取り出せるか、独自形式のJSONでしか返らないか。そして、フロントの取得処理を1つのモジュールに集め、画面のコンポーネントがCMS固有のレスポンス形式を直接読まない設計にしておくことです。取得処理を集約すると、CMS変更時のデータ取得・変換処理の修正箇所を絞れます。ただし、画像移行、リッチテキストの描画、プレビュー、Webhookなどは別途変更が必要になる場合があります。

## ヘッドレスCMSを選ぶべきでない場面と選定の順番

ヘッドレスCMSは新しいから良いわけではありません。**更新頻度が低い小規模なコーポレートサイトやブログ単独で、フロントを継続して触れる開発者がいないなら、選ぶべきではありません。**プレビュー・再検証・APIキー管理という運用を抱えるだけで、従来型より高くつきます。この条件ならWordPressなどの従来型で十分で、[WordPressサイト制作・CMS構築](/service/web/wordpress/)のように一体型で作るほうが早く公開できます。

採用が合うのは、Webとアプリなど複数チャネルへ同じコンテンツを配る、フロントを自由な技術で作りたい、保守できる開発体制がある、の3条件がそろう場合です。そのうえで次の順に絞ります。

1. データを自社で持つ必要があるか：あればStrapiなどのセルフホスト。
2. 入稿者が日本語のサポートを必要とするか：必要ならmicroCMS。
3. 多言語・大規模・複数ブランドか：該当すればContentfulやSanityの有料プラン。
4. 候補ごとに、上限到達時の挙動・エクスポート手段・下書き取得の方法を確認する。

要件定義から比較表の作り方までは[CMS選定の進め方と選び方｜要件定義の項目と比較チェックリスト【2026年版】](/column/details/7509/)で手順化しています。

## よくある質問

### ヘッドレスCMSとは何ですか？

表示（ヘッド）を持たず、コンテンツの入力・管理と配信APIだけを持つCMSです。入力したコンテンツはREST APIやGraphQL APIでJSONとして配信され、WebサイトやアプリがそれをAPIから取得して表示します。画面は自由に作れる代わりに、フロントエンドとプレビューの仕組みは自分で用意します。

### ヘッドレスCMSの例にはどんな製品がありますか？

SaaS型ではContentful・Sanity・国産のmicroCMS、OSSではStrapi・Payload、ソース公開型ではDirectusが代表的です。WordPressもREST APIを使えばヘッドレスCMSとして使えます。国産のNewtは2026年11月24日にサービスを終了するため、新規採用の候補から外します。

### ヘッドレスCMSの料金はいくらですか？

2026年10月時点で、microCMSはHobby無料・Team月4,900円〜（税抜）、Sanityは無料プランとGrowth（1席月15ドル）、Strapiはセルフホストならライセンス費無料でStrapi Cloudは月35ドルからです。実際の請求は転送量・APIリクエスト数・席数で増えるため、想定アクセスと編集者数で見積もります。

### 無料で使えるヘッドレスCMSはありますか？

あります。microCMSのHobbyはAPIリクエスト無制限・コンテンツ1万件・転送量20GB/月まで無料ですが、転送量を超えると翌月までAPIが止まります。StrapiのCommunity EditionはMITライセンスでセルフホストなら無料です（サーバー費は自己負担）。Sanityも無料プランがありますが、データセットは公開設定のものに限られます。

### JavaScriptで書かれたヘッドレスCMSはどれですか？

StrapiとPayloadはどちらもNode.js上で動くTypeScript製です。StrapiはContent-Type Builderで定義した型からREST APIを生成し（GraphQL APIはGraphQLプラグインを入れると使えます）、PayloadはNext.jsアプリの中に管理画面ごと組み込めます。フロントもNext.jsで作るなら、言語を1つに揃えられる点が選ぶ理由になります。

## 関連記事

- [CMSとは？仕組み・種類・WordPressとヘッドレスの違いと選び方を発注視点で解説](/column/details/15425/)
- [Strapiとは？読み方・使い方と料金を最新版5.55で解説【2026年9月】](/tech/details/8082/)
- [Contentfulとは？API構成と料金の増え方・移行手順を実コードで解説](/tech/details/17724/)
- [Payload CMSとは？使い方・Next.js統合・Strapiとの違いを解説](/tech/details/8065/)
- [Jamstackとは？意味・仕組みから開発・WordPress比較まで解説【2026年版】](/column/details/3121/)

---

出典: [ヘッドレスCMSとは？従来型との違い・料金比較とプレビュー実装【2026年10月】](<https://www.issoh.co.jp/tech/details/1317/>)（株式会社一創）