過去4年間、私はこれら3つのCMSすべてを使用した本番プロジェクトを構築してきました。新規構築もあれば、WordPressやボロボロになったレガシーシステムからのマイグレーションもありました。クライアントが「どのヘッドレスCMSを使うべき?」と聞くたびに、万能な答えを提供することに抵抗してきました。しかし2025年を通じて2026年にかけて数十のプロジェクトを出荷した後、実際の傷跡に支えられた強い意見を持つようになりました。

この記事は、Contentful、Sanity、Payload CMSを、実際に何かを構築するときに本当に重要な側面に分けて説明します。規模での料金、実戦でのデベロッパー体験、コンテンツモデリングの柔軟性、APIデザイン、そしてコンテンツチームが愛するか嫌うかのいずれかになる日々の編集ワークフローです。

目次

Contentful vs Sanity vs Payload: ヘッドレスCMS比較 2026

30秒での概要

Contentfulは既存勢力です。2013年から存在し、エンタープライズサイトを規模で支えています。洗練されており、信頼でき、高価です。

Sanityはリアルタイムの構造化コンテンツアプローチとカスタマイズ可能なスタジオを備えた開発者のお気に入りです。強力ですが、学習曲線があり、料金モデルが驚くかもしれません。

Payloadは静かに真摯な競争相手となった新興勢力です。オープンソース、デフォルトで自社ホスティング(クラウドオプション付き)、TypeScriptで書かれており、ライセンス料金はゼロです。2025年、Payload 3.0はNext.jsの上での完全な書き直しで出荷され、方程式全体を変えました。

機能 Contentful Sanity Payload
タイプ SaaS SaaS(スタジオ自社ホスティング) オープンソース/自社ホスティング
言語 N/A(APIのみ) JavaScript/React TypeScript/Next.js
ライセンス料金 あり あり(使用量ベース) なし(MIT)
GraphQL あり あり(GROQ推奨) あり(自動生成)
REST API あり あり あり(自動生成)
リアルタイム協働 制限的 優れている 良好(2.0以降)
自社ホスティング いいえ スタジオのみ 全スタック
データベース 独自仕様 独自仕様 MongoDBまたはPostgres

料金の内訳:実際に支払う金額

ここが現実的なポイントです。料金はプロジェクト途中でのCMS切り替えの理由第1位であり、評価中に人々が過小評価する第1位のものです。

Contentful料金(2026年)

Contentfulの無料枠は1スペース、5ユーザー、25K APIコールを提供します。ブログなら十分です。

Basic プラン月額$300から始まり、より多くの環境とロールを提供します。Premium プラン — ほとんどの真摯なチームが必要とするもの — はカスタム価格ですが、通常は中規模組織で月額**$2,000~$3,000**から始まります。企業向け契約が年額$80K以上のものも見てきました。

キッチャーは:APIコール超過料金です。ContentfulはコンテンツデリバリーAPIコール、コンテンツマネジメントAPIコール、資産帯域幅に対して個別に料金を請求します。月間1000万ページビュー以上の高トラフィックサイトでは、含まれるクォータを簡単に超えることができます。協力した1つのクライアントは、ウイルス的に広がった製品ローンチ後、CDNとAPI超過料金が原因で月額請求書が$2,500から$4,800に跳ね上がるのを見てきました。

Sanity料金(2026年)

Sanityは「成長に応じて支払う」と呼ぶ使用量ベースのモデルを使用しています。無料プランには3人の非管理者ユーザー、500K APIリクエスト、20GB帯域幅、10GBストレージが含まれます。始めるのに寛容です。

Growth プラン月額$15/ユーザープラス使用超過料金です。Enterprise プランはカスタム価格です。

Sanity料金に人々が引っかかることについて:GROQクエリとAPI CDNリクエストは計測され、コンテンツの複雑さに応じてコストが拡張します。深くネストされた参照されたコンテンツを取得する単一のGROQクエリは、予想より多くのクォータを消費する可能性があります。Sanityはここで透明性を改善しましたが、チームが早期に予算アラートを設定することをお勧めしています。

典型的な中規模プロジェクトコスト:チームサイズとトラフィックに応じて月額$200~$800

Payload料金(2026年)

PayloadはMITライセンスです。CMS自体は**$0**です。永遠に。ユーザーあたりの料金、APIコール計測、Payloadからの帯域幅料金がありません。

コストはインフラストラクチャです:Node.jsアプリとデータベースのホスティング。Railway、Render、または基本的なAWS/DigitalOcean設定のようなサービスでは、ほとんどのプロジェクトで月額$20~$100を見ています。AWS RDSの管理Postgres、適切にサイズ設定されたEC2またはECS設定、およびCloudFrontを正面に持つ大規模なデプロイであっても、深刻なトラフィックで月額**$300~$500**を超えることはほとんどありません。

Payload Cloud(ホストされたオファリング)は月額$50から始まり、ストレージと帯域幅に基づいてプランが拡張されますが、完全にオプションです。

シナリオ Contentful Sanity Payload(自社ホスティング)
ソロ開発者、小規模サイト $0(無料枠) $0(無料枠) $20~40/月(ホスティング)
5人チーム、中程度トラフィック $300~500/月 $200~400/月 $50~100/月(ホスティング)
10人チーム、高トラフィック $2,000~4,000/月 $500~1,500/月 $150~400/月(ホスティング)
エンタープライズ、50人以上の編集者 $5,000~10,000以上/月 $2,000~5,000/月 $300~800/月(ホスティング)

料金の話は曖昧ではありません。Payloadはすべての層でコストで勝ちます。

デベロッパー体験

料金はドアを開けます。デベロッパー体験は彼らをそこに留めます—または彼らを追い出します。

Contentful DX

Contentfulのデベロッパー体験は…問題ありません。SDKサポートは広い(JavaScript、Python、Ruby、Java、Swift等)、ドキュメンテーションは成熟しており、RESTとGraphQL APIは十分に文書化されています。

しかしここで私を苛立たせるもの:すべてはウェブUIを通じて設定されます。コンテンツタイプ、フィールド、検証—すべてブラウザでクリック・クリック・クリックです。はい、Contentful CLIとマイグレーションスクリプトを使用してスキーマをバージョン管理できますが、それは付け足されたように感じます。コード優先ではなく、UIが優先でコード脱出ハッチがあります。

マイグレーション機能はcontentful-migrationパッケージで改善されていますが、スキーマをTypeScriptで定義してすぐに型安全性を得ることと比較すると?1世代後ろに感じます。

Sanity DX

Sanityのデベロッパー体験は多くの方法で本当に優れています。スキーマはJavaScript/TypeScriptファイルで定義されます。スタジオはカスタマイズ可能なReactアプリです—カスタム入力コンポーネント、カスタムビュー、ワークフロープラグイン。

GROQ、彼らのクエリ言語は、習得すると強力です。しかし「習得すると」はその文でたくさんの重い仕事をしています。GROQはSQLではありません。GraphQLではありません。それ自体のものであり、あなたのチームのすべての新しい開発者がそれを学ぶ必要があります。数週間GROQ射影で苦労している初心者開発者を見てきました。

// GROQクエリ - 強力だがユニークな構文
*[_type == "post" && publishedAt < now()] | order(publishedAt desc) [0...10] {
  title,
  slug,
  "author": author->{ name, image },
  "categories": categories[]->{ title, slug },
  body[] {
    ...,
    _type == "image" => {
      "url": asset->url
    }
  }
}

Sanityのリアルタイム機能は素晴らしいですが。複数のエディタが同じドキュメントで作業しており、プレゼンスインジケータとセーブ競合なし—それはただ機能します。コンテンツレイク アーキテクチャは競合他社ができない方法でこれを可能にします。

Payload DX

Payload 3.0はすべてを変えました。Next.jsの上に構築され、完全にTypeScriptで書かれており、設定ファイルが唯一の情報源です。コレクション、フィールド、フック、アクセス制御、カスタムエンドポイントすべてをコードで定義します。

典型的なPayloadコレクションの外観:

import { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  admin: {
    useAsTitle: 'title',
    defaultColumns: ['title', 'status', 'publishedAt'],
  },
  access: {
    read: () => true,
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => user?.role === 'admin',
  },
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'content',
      type: 'richText',
    },
    {
      name: 'author',
      type: 'relationship',
      relationTo: 'users',
    },
    {
      name: 'status',
      type: 'select',
      options: ['draft', 'published'],
      defaultValue: 'draft',
    },
    {
      name: 'publishedAt',
      type: 'date',
      admin: {
        position: 'sidebar',
      },
    },
  ],
  hooks: {
    beforeChange: [
      ({ data, operation }) => {
        if (operation === 'create') {
          data.publishedAt = new Date()
        }
        return data
      },
    ],
  },
}

すべてが型付けされています。IDEはフィールド名をオートコンプリートします。フックはライフサイクル制御を提供します。アクセス制御はフィールドの隣に関数として定義され、別々のパーミッション UIではありません。そしてそれがただのNext.jsアプリだからこそ、カスタムページ、APIルート、またはサーバーアクションをCMSコードの隣に追加できます。

Next.js開発を行うチームにとって、Payload 3.0はDXの視点から不動産です。CMSとフロントエンドは同じプロジェクトにあります。同じデプロイメント。同じリポジトリ。

Contentful vs Sanity vs Payload: ヘッドレスCMS比較 2026 - アーキテクチャ

コンテンツモデリング

コンテンツモデリングは、成功のために自分自身をセットアップするか、数年間住むことになるナイトメアを作成するかです。

Contentfulのアプローチ

Contentfulは従来のコンテンツタイプ→エントリモデルを使用します。フィールドでコンテンツタイプを定義し、編集者がエントリを作成します。コンテンツタイプ間の参照は明示的です。それは単純なコンテンツ構造に対してうまく機能します。

制限は豊富なテキストで表示されます。Contentfulの豊富なテキストフィールドはコンテンツを構造化されたJSONツリーとして保存します。これはレンダリング柔軟性には素晴らしいですが、ネストされたコンポーネントを持つ複雑なページレイアウトをモデル化するには、組み込みエントリと参照の創造的な使用が必要です。厄介になることができます。

Contentfulは基本プランで50コンテンツタイプ、プレミアムで100以上をサポートします。多くのコンテンツタイプを持つ大規模なサイトの場合、これは制約になる可能性があります。

Sanityのアプローチ

Sanityのコンテンツモデリングは、おそらく3つの中で最も柔軟です。彼らのブロックコンテンツ(Portable Text)は豊富なテキストのための公開仕様で、コンテンツを構造化されたデータとして保存します。カスタムブロックタイプ、インラインオブジェクト、注釈を定義できます。

スキーマシステムは深くネストされたオブジェクトタイプ、条件付きフィールド、カスタム検証をサポートします。Sanityで本当に複雑なコンテンツモデルを構築しましたが、Contentfulではそれが苦痛になります。

// Portable Textカスタマイズを備えたSanityスキーマ
export default {
  name: 'post',
  type: 'document',
  fields: [
    {
      name: 'body',
      type: 'array',
      of: [
        { type: 'block',
          marks: {
            annotations: [
              { name: 'internalLink', type: 'object',
                fields: [{ name: 'reference', type: 'reference', to: [{ type: 'post' }] }]
              }
            ]
          }
        },
        { type: 'image', options: { hotspot: true } },
        { type: 'codeBlock' },
        { type: 'callout' },
      ]
    }
  ]
}

Payloadのアプローチ

PayloadのコンテンツモデリングはContentfulの構造化シンプリシティとSanityのフリーフォーム柔軟性の間のどこかに位置しますが、完全にTypeScriptであるという利点があります。

Payloadのブロックフィールドは特にページビルディングで強力です。各ブロックタイプを独自のフィールドで定義し、編集者はこれらのブロックからページを構成できます。layoutフィールドタイプと条件付きロジックと組み合わせて、ほぼ何でもモデル化できます。

Payload 3.0のLexical豊富なテキストエディタは傑出しています。Slate(問題ありませんが老化している)を、カスタムノード、インラインブロック、サーバーサイドレンダリングをサポートする最新のエディタで置き換えました。豊富なテキストコンテンツに直接Reactコンポーネントを埋め込むことができます。

バージョン管理システムは言及する価値があります。Payloadはドラフト/パブリッシュワークフローと完全なドキュメント版履歴と差分を提供します。これは組み込まれており、有料アドオンではありません。

API:REST、GraphQL、その間のすべて

Contentful API

Contentfulは配信(CDNキャッシュ、読み取り専用)、プレビュー(キャッシュなし、ドラフトコンテンツ)、管理(CRUD)、画像用の別々のAPIを提供します。分離は理にかなっていますが、複数のAPIトークンとベースURLをやり繰りすることを意味しています。

GraphQL APIは堅いですが、深さの制限とレート制限があり、深く参照されたコンテンツをモデル化するときに苛立つことができます。複雑なクエリは複数のラウンドトリップが必要な場合があります。

Sanity API

Sanityのプライマリクエリ言語はGROQで、HTTP経由で提供されます。彼らはGraphQL APIを提供していますが、それは個別に展開され、二流に感じます。ほとんどのSanityユースケースではGROQが強力です。

本当の魔法はSanityのリアルタイムリスナーAPIです。任意のクエリへの変更にサブスクライブし、瞬時に更新を取得できます。これにより、本当に印象的なライブプレビュー体験が可能になります。

Payload API

Payloadはコレクション設定からREST APIとGraphQL APIの両方を自動生成します。追加のセットアップなし。コレクションを定義し、両方のREST APIとGraphQLを即座に取得します。

# 自動生成されたGraphQLクエリ
query {
  Posts(where: { status: { equals: published } }, sort: "-publishedAt", limit: 10) {
    docs {
      id
      title
      content
      author {
        name
      }
      publishedAt
    }
    totalDocs
    hasNextPage
  }
}

しかしPayloadが独特な利点を持つのはここです:Next.jsアプリと同じプロセスで実行されるため、APIをスキップしてPayloadのローカルAPIをサーバーサイドデータ取得に使用できます。同じアクセス制御、フック、検証を備えたダイレクトデータベースクエリ—ただしHTTPのオーバーヘッドがゼロです。

// ローカルAPI - HTTPなし、シリアル化オーバーヘッドなし
const posts = await payload.find({
  collection: 'posts',
  where: { status: { equals: 'published' } },
  sort: '-publishedAt',
  limit: 10,
})

これはサーバーレンダリング ページのための大規模なパフォーマンス勝利です。CMS APIへのネットワークラウンドトリップなし。ただ関数呼び出しです。

編集体験

開発者はCMSを選択しますが、編集者は毎日住んでいます。彼らの体験を無視してはいけません。

Contentfulは最も成熟した編集UIを持っています。クリーン、予測可能、非技術的なチームはそれを迅速に拾います。プレミアムプランのスケジュール設定、ワークフロー、承認チェーンは堅いです。しかし、それは硬く感じることができます—編集インターフェースをカスタマイズするにはContentful Appを構築する必要があり、別々のReactアプリ全体です。

Sanity Studioは最もカスタマイズ可能です。完全にカスタムの編集体験を構築できます。しかしそのカスタマイズはコストで来ます:すぐに、Sanity Studioは非技術的な編集者に圧倒的に感じることができます。構造ビルダーはよく構成するために開発者の時間を必要とします。

Payloadの管理パネルは3.0で劇的に改善されました。クリーン、高速(Next.jsアプリ)、カスタムコンポーネント、条件付きフィールドレンダリング、ライブプレビューをサポートします。Contentfulの UIほど洗練されていませんが、Contentfulより努力なくカスタマイズ可能で、デフォルト体験ではSanityより親しみやすいです。

自社ホスティング対SaaS:実際のトレードオフ

これは哲学的な分割です。ContentfulとSanityはSaaSプラットフォームです。インフラストラクチャを管理しません。彼らが管理するために支払います。Payloadはデフォルトで自社ホスティングされます。

SaaS議論:運用オーバーヘッドが少ない、組み込みCDN、管理されたアップタイム。これらは特にDevOps体験のない小さなチームにとって実際の利点です。

自社ホスティング議論:データ所有権、ベンダーロックイン なし、予測可能なコスト、規制コンプライアンス(GDPR、HIPAA、データレジデンシー)、何かをカスタマイズする自由。

ヘッドレスCMS開発を行うエージェンシーのように、2026年の自社ホスティングはほとんどのクライアントへの推奨になりました。インフラストラクチャ機能は、Payload アプリをRailway、Vercel、またはAWSに展開するのが単純になるポイントまで成熟しました。Dockerはそれを再現可能にします。そしてコスト削減はSaaS CMS上で年ごとに複合します。

運用負担が懸念されている場合、Payload Cloudはオープンソースの利点を保持しながらホスティングを処理します。

パフォーマンスとスケーラビリティ

ContentfulのCDN支援のデリバリーAPIは高速です。エッジノードからの典型的なレスポンス時間は50~100msです。10年間規模でバトルテストされています。

SanityのCDN APIはキャッシュされたコンテンツに同様のパフォーマンスを配信し、リアルタイム層がライブクエリに20~30msを追加しています。

Payloadのパフォーマンスはインフラストラクチャに依存しますが、これが重要です—Next.jsサーバーコンポーネントでローカルAPIを使用する場合、ローカルデータベースへの関数呼び出しを行っています。レスポンス時間は10ms未満になる可能性があります。Next.js出力の正面にCDNを追加します(Vercel、CloudFront等)そしてあなたはSaaSオプションと一致するか、打つことになります。

Astroベースのプロジェクトの場合、3つすべてがAPIソースとしてうまく機能しますが、PayloadのREST APIとGraphQL APIは特にAstroのデータ取得層で簡単に消費されます。

エコシステムとコミュニティ

Contentfulは最大のエンタープライズエコシステムを持っています。トンの統合、アプリマーケットプレイス、広範なエージェンシーサポート。

Sanityは熱心な開発者コミュニティ、優れたドキュメンテーション、成長するプラグインエコシステムを持っています。彼らのコミュニティSlackは本当に役に立ちます。

Payloadは3つの中で最も速く成長するコミュニティを持っています。彼らのDiscordは非常にアクティブで、コアチームが定期的に質問に応答しています。プラグインエコシステムは小さいですが急速に成長しています—PayloadはただのNode.js/TypeScriptなので、必要なものを任意でnpm installできます。

Payloadの GitHub は2026年初期現在3万個以上のスターを持ち、軌跡は急勾配です。

結論

ストレートで言います:Payload は 2026年のほとんどのプロジェクトのための最高のヘッドレスCMSです。

理由はここです:

  1. あらゆる規模でゼロライセンス料金。50人の編集者エンタープライズチームはPayloadに1円も支払いません。
  2. TypeScript-native 設定はコンテンツモデルがコード、バージョン制御、型安全、PRで見直し可能であることを意味します。
  3. ローカルAPI + Next.js統合は SaaS CMSが物理的に一致できないパフォーマンスをあなたに与えます。
  4. データ所有権—コンテンツはあなたのデータベースに住んでいます、誰か他の人の独自仕様ストアではなく。
  5. ベンダーロックイン なし—切り替わりたい場合、データはPostgresまたはMongoDBにあります。それを照会してください。

他の状況が勝つことがあります:

  • Contentfulを選択大規模エンタープライズがポーランドされた、ゼロ運用編集体験が必要な確立されたコンテンツチームで、予算があります。
  • Sanityを選択リアルタイム協働がワークフローに重要な場合、Portable Textの無敵の構造化豊富なテキストが必要な場合、または高度にカスタマイズされたスタジオ体験を構築しています。
  • Payloadを選択他のすべてのもの。スタートアップ、エージェンシー、中堅企業、開発者主導のチーム、データ制御が必要な規制産業、そして驚きの請求書に目を覚ましたくない誰でも。

新しいプロジェクトのヘッドレスCMSを評価していて、仕様についてお話ししたい場合は、私たちは喜んでお手伝いします。私たちは本番のPayload、Sanity、Contentfulプロジェクトを出荷し、実際の要件と予算に基づいて誠実なアドバイスを提供できます。

FAQ

Payload CMS は本当に無料ですか?

はい。PayloadはMITライセンスのオープンソースソフトウェアです。ライセンス料金、ユーザーあたりの料金、Payloadからのコール制限がありません。唯一のコストはホスティングインフラストラクチャ(サーバーとデータベース)で、スケールに応じて通常月額$20~$500実行します。Payload Cloudはインフラストラクチャを管理したくない場合の有料ホストオプションとして利用可能です。

Sanity は自社ホスティングできますか?

部分的に。Sanity Studio(管理UI)は任意の場所に展開できるReactアプリです。しかし、コンテンツレイク—実際のデータが存在する場所—はSanityが管理するホストサービスです。データレイヤーを自社ホスティングすることはできません。つまり、コンテンツはSanityのインフラストラクチャに常に住んでいます。これはデータレジデンシーまたはコンプライアンス要件の懸念かもしれません。

どのヘッドレスCMSが最高のGraphQLサポートを持っていますか?

ContentfulとPayloadの両方が強いGraphQL APIを提供しています。Payloadはコレクション設定からGraphQLスキーマを直接自動生成するため、手動スキーマメンテナンスはゼロです。ContentfulのGraphQL APIは成熟しており、十分に文書化されています。SanityはGraphQLを提供していますがGROQをプライマリクエリ言語として優先し、GraphQL実装はすべてのGROQ機能をサポートしていません。

Contentful は 2026 年の価格の価値がありますか?

複雑なコンテンツ運用、既存のContentfulワークフロー、ハンズオフSaaS アプローチを値を入れるチームを持つ大規模エンタープライズの場合—はい、それは価値がある場合があります。小~中規模のチームでは、Payloadが同等の(いくつかの方法で優れた)機能を提供するとき、コストを正当化することはますます難しいです。複数のクライアントがコスト特に理由にContentfulから移行したを見ました。

Payload CMS は画像最適化をどのように処理しますか?

Payloadは組み込みイメージリサイズと焦点トリミングがあります。イメージをアップロードすると、Payloadは設定に基づいて複数のサイズを自動的に生成できます。Next.js 3.0でのPayloadを使用して、Next.jsイメージ最適化と組み合わせてレスポンシブ、WebP/AVIF提供ができます。Contentfulのイメージ API(URL-ベースの変換を提供するもの)ほど機能豊富ではありませんが、サードパーティサービスなくユースケースの90%をカバーします。

Contentful から Payload にマイグレーションできますか?

はい。Payloadは標準データベース(PostgresまたはMongoDB)を使用するため、マイグレーションはContentfulコンテンツを管理APIを通じてエクスポートし、Payloadコレクションにインポートすることを含みます。ContentfulコンテンツタイプからPayloadコレクションへのコンテンツモデリング変換は通常単純です。複数これらのマイグレーションを処理しました—最も厄介な部分は通常、構造化データではなく豊富なテキスト変換です。

どのCMSが非技術編集者に最適ですか?

Contentfulは非技術的ユーザーのための最も直感的なアウトオブボックス編集体験を持っています。Payloadの管理パネルは近い秒で、急速に改善しています。Sanity Studioは、開発者がそれをカスタマイズするために時間投資する場合、3つすべての最高可能性ですが、デフォルト体験は編集者のための急勾配の学習曲線があります。

Payload CMS は Next.js 以外のフレームワークで機能しますか?

絶対。Payload 3.0はNext.jsを管理UI フレームワークとして使用しますが、REST APIとGraphQL APIはあらゆるフロントエンド— Astro、Nuxt、SvelteKit、Remix、またはモバイルアプリでも機能します。ローカルAPIはNext.js-特定ですが、外部API はフレームワークの依存性を持っていません。Payload は一般的にプロジェクト要件に応じてNext.jsとAstroの両方とペアリング定期的にします。