ヘッドレスCMSの選択をSanityとPayload派またはStoryblok派に絞り込んだなら、このカテゴリーが放つノイズの80％は既に排除できている。残りの決定は面白い部分だ——エディトリアルチームの体験を最適化するのか、それともエンジニアリングチームのオーナーシップを優先するのか。その質問を正しく理解できれば、残りの選択はほぼ自動的に決まる。
Sanityはエディトリアルチームが主役の場合に答えになる。Seahawk Mediaで12,000件以上のクライアントビルドを運用し、過去18ヶ月間にSanityで直接数件をリリースした経験から、ここでの誠実な見解——勝つ場所、Payloadに負ける場所、Storyblokの勝ち場所。価格設定、機能、マイグレーションパス、そしてベンダーの営業ページでは誰も教えてくれない trade-offについて。
2026年のSanityは実際には何か
Sanity はホストされたヘッドレス CMS で、TypeScript または JavaScript でスキーマを記述し、Sanity Studio と呼ばれるカスタマイズ可能な React ベースの管理アプリ（通常は自分のドメインにデプロイ）を実行して、GROQ（GraphQL に似ているがドキュメント関係でより表現力が高いグラフスタイルクエリ言語）経由でコンテンツをクエリします。コンテンツはボックスから出した時点でエディタ間でリアルタイム：同じドキュメント内の 2 人のエディタは Figma のようにお互いのカーソル位置をリアルタイムで見ることができます。
プラットフォームは成熟している：Sanity v3は過去2年間安定したメジャーバージョンであり、Studioは単一の入力コンポーネントレベルまで本当にカスタマイズ可能で、Live Content APIはドキュメント変更をポーリングなしでフロントエンドにストリーミングする。Sanityは2026年のヘッドレスCMS選択肢の中でも、火曜日の午後に初期段階の製品のように感じられない数少ないもののひとつだ。
2026年の Sanity 価格設定、実際のコスト曲線
3つのプラン。無料枠は寛容に見えますが、ハードキャップに達するまで。Growthプランは1シートあたり月額15ドルから開始。Enterpriseはカスタムで、Growthプランのスケーリングが止まるところから始まります。
無料プラン
- 月額0ドル、20シート含まれ、超過分は一切なし。
- Administrator と Viewer ロールに限定され、Editor、Developer、または Contributor ロールはありません。
- ドキュメント、アセット、APIリクエスト、CDN帯域幅にハードキャップあり。クォータに達すると、影響を受ける機能はクォータがリセットされるか、アップグレードするまでブロックされます。
- 現実的な用途：プロトタイプ、社内ツール、または5,000ドキュメント未満で小規模編集チームを持つコンテンツサイト。
Growthプラン
- 1シートあたり月額15ドル、最大50シート。
- 5つのロールすべてが利用可能：Admin、Viewer、Editor、Developer、Contributor。
- 月間25万件のAPIリクエスト、100万件のAPI CDNリクエストが含まれ、超過分は従量課金です。
- 25,000 ドキュメントのハードキャップ、Growth ではこれ以上のペイアズユーゴーはなく、Enterprise に移行する必要があります。
- スケジュール済みドラフト、コラボレーション機能、SSO アドオンを追加した場合のシングルサインオン（詳細は下記参照）。
- 現実的な用途：1～10人のエディターと2万5,000ドキュメント未満を抱える本番環境のコンテンツサイトが大半です。
Enterpriseプラン
- カスタム価格設定、営業が対応します。
- ドキュメント上限の拡大、カスタム保持期間、高度なセキュリティ、専任サポート、SLA保証のパフォーマンス。
- 現実的な用途：5万ドキュメント以上のサイト、規制対象業界、調達要件を持つエンタープライズ企業。
Growthの見た目より費用がかかるSSO アドオン
Growthプランの SAML SSO は月額1,399ドルのアドオンです。その他の費用が月額75ドルの5シート体制チームにとって、SSO を追加するとコストが19倍に膨れ上がります。セキュリティ方針で初日からSSOが必須な場合、Growthプランは割に合わず、Enterpriseの機能セットを持たないままEnterpriseの価格を支払うことになります。コミットする前に確認しておく価値があります。
Sanityが勝つケース（そしてそれを選ぶブリーフの種類）
分散チーム全体のリアルタイム編集
Sanityのコラボレーションモデルは、ヘッドレスCMSの中でGoogle Docでの作業に最も近い。同じドキュメント内の2人の編集者は互いのカーソルが見える。コメントは個別フィールドにスレッド化される。ドキュメントの存在状況はナビゲーションに表示される。ブランドチーム、コンテンツマーケティングチーム、2人以上が同じ時間帯に同じドキュメントに触れる組織にとって、これは本当にカテゴリーを定義する機能だ。
CMSテンプレートのように感じさせないスキーマカスタマイズ
Studio は出荷する React アプリです。カスタム入力コンポーネント、カスタムプレビュー、カスタムワークフローボタン、カスタム検証、カスタムアセットパイプライン、すべてリポジトリ内に存在します。編集チームが特別なニーズを持っている場合（銀行休場日を拒否するカスタム日付とタイムゾーンピッカー、競合他社リストに対して検証するスラッグフィールド、カスタム画像トリミング UI）、Sanity Studio はプラットフォームと戦うことなくそれを構築できる唯一のヘッドレス CMS です。
クエリ言語としてのGROQ
GROQ はドキュメントグラフクエリの場合、GraphQL より表現力があります。参照全体でジョイン、ネストされたフィールドをプロジェクト、計算値でフィルタリング、単一のクエリでリストをスライスできます。トレードオフは、GROQ は Sanity 固有であり、クエリを他の場所に持ち出すことはできません。複雑なコンテンツサーフェスを提供するチーム（ファセット付きディレクトリ、関連コンテンツウィジェット、マルチロケールフォールバックチェーン）の場合、GROQ は同等の GraphQL クエリとフロントエンドロジックより記述が高速で反復が高速です。
Next.jsフロントエンドでのビジュアル編集
Sanityのビジュアル編集機能は2025年以降一般利用可能で、編集者がプレビューモードのNext.jsまたはNuxtページ上で直接クリックし、Studio内の基盤となるフィールドを編集できる。これはStoryblok以外のヘッドレスCMSスペースで最もクリーンなビジュアル編集の実装だ。編集ワークフローが主にプレビューファーストの場合、これは本当の生産性向上をもたらす。
PayloadがSanityを上回るケース
エンジニアリングチームがビルドの主役であり、エディターチームが若干開発者向けのアドミン体験へのオンボーディングが可能な場合、Payloadが適切な選択肢である。
TypeScriptファーストのスキーマを規範的なソースとする
Payloadのスキーマはアプリケーションコードと同じTypeScriptファイル内に存在する。型安全性はエンドツーエンドである：スキーマ、APIクライアント、Next.jsアプリはすべてコード生成ステップなしで同じ型を共有する。Sanityのスキーマもコード定義されているが、型生成フローはより複雑で、TypeScriptストーリーはより本来的ではない。
セルフホスト、お客様のPostgresデータベース、お客様のS3バケット
Payload はデータ所有が譲歩できない場合の方が優れた回答です。CMS はインフラストラクチャで実行され、データベースは Postgres または MongoDB インスタンスで、アセットは S3（または互換性のある）バケットに置かれます。Sanity はドキュメントを Sanity のホストインフラストラクチャに格納し、ほとんどのチームにとっては問題ありませんが、規制業界またはサードパーティデータストアなし」ポリシーを持つチームにとっては重大な障害です。
HTTPオーバーヘッドなしのLocal API
PayloadのLocal APIを使用すると、HTTPリクエストなしにNext.jsコードからCMS機能を直接呼び出すことができる。CMSが複数のデータソースの1つに過ぎない緊密に統合されたアプリケーションの場合、これはSanityのネットワークのみのアクセスパターンより測定可能に優れたパフォーマンスを実現する。
PayloadとStrapiの決定について詳しくはこちらで説明した：Payload vs Strapi in 2026。短いバージョンは同じ形である：TypeScriptが多いチームで所有権を望むチームはPayload、より充実したプラグインエコシステムを望むチームはStrapi。
StoryblokがSanityを上回る（特定の1つのケース）
StoryblokはSanityを1つの特定の側面だけで上回る：コードに触れずにコンポーネント単位でページをレイアウトしたいマーケティングチームのためのビジュアルエディター。StoryblokのVisual Editorを使用すれば、非技術的なマーケティングマネージャーは事前定義されたコンポーネントブロックからヒーロー、CTA付きヒーロー、3列機能グリッドレイアウトを構築し、その過程でライブプレビューを確認できる。Sanity Visual Editingは優れているが、同じペルソナを中心に設計されていない。
編集チームがマーケティング主導の非技術者で、ページを組み立てたいのであればStoryblokが正解です。編集チームがコンテンツ第一主義（ライター、編集者、ジャーナリスト、ナレッジマネージャー）であれば、Sanityのドキュメントファースト・エディターのほうが優れた体験になります。
Sanityへの移行：現実的なパス
WordPressから
標準パターン：WP All Export 経由で WordPress コンテンツをエクスポート、Sanity の NDJSON ドキュメント形式に変換、Sanity CLI 経由でインポート。スキーママッピングは機能、ページ、投稿、カスタム投稿タイプ、ACF フィールドはすべて Sanity 相当である必要があります。WordPress から Next.js への移行プレイブックは CMS ターゲットに関係なく適用される SEO 転送側をカバーしています。5,000 ページのサイトでの時間：移行のみのための 4～8 週間の集中した作業、スキーマに複雑な関係コンテンツが含まれている場合はさらに長くなります。
Contentfulから
WordPressより簡単です。Contentful のコンテンツモデルが Sanity のドキュメント・アンド・リファレンス構造にきれいにマッピングされるからです。Sanity の移行ツーリングには Contentful エクスポート専用のインポーターがあります。同規模サイトでの現実的なタイムライン：2 週間から 4 週間。
Drupalから
3 つのうち最も難しい。Drupal のエンティティ・アンド・バンドルモデルは構造的に異なるからです。ほとんどのチームは自動移行ではなく、Sanity でスキーマをゼロから再構築することになります。複雑な Drupal マルチ言語サイトで 6 週間から 12 週間。
よくある質問
Sanity は HIPAA 準拠ですか？
Sanity の Growth プランでは HIPAA Business Associate Agreement を公開していないため、Sanity はデフォルトでは PHI の保存に対応していません。医療ワークフローを持つエンタープライズ顧客はカスタムデータハンドリング契約を交渉できますが、これはデフォルトではありません。医療アプリが PHI を直接保存する CMS が必要な場合、HIPAA アドオン付きの Supabase または HIPAA 対応ホスト上の自己ホスト型 Payload デプロイメントの方が防御可能です。
Sanity は Contentful より優れていますか？
2026年のほとんどのチームにとって、はい、Sanity はより高いスキーマ柔軟性、より優れたリアルタイム協力、より可能なクエリ言語（GROQ）、および同等の機能セットのための意味のある低い価格を提供します。Contentful の強みはエンタープライズ調達と従来のマーケティングスタックとの統合です。チームが技術的で編集ワークフローが優先の場合、Sanity の方が優れた選択です。ステークホルダーが調達フレンドリーなエンタープライズコントラクトを要求する場合、Contentful の方が安全な選択です。
5 人のチームにおける Sanity のコストはいくらですか？
Growth プランは月額 $75 で 5 シートまで利用でき、1 シートあたり $15 です。SAML SSO が必要な場合は月額 $1,399 を追加すると、同じチームで月額 $1,474 になります。無料プランは 20 シートをハードキャップ付きでカバーしているため、チームが小規模で使用量が少ない場合、無料ティアで初年度をカバーできる可能性があります。
Sanity を Next.js で使用できますか？
はい、Next.js は 2026 年の Sanity における最も一般的なフロントエンドです。公式の @sanity/client パッケージが API 呼び出しを処理し、GROQ クエリは Server Components またはAPI ルート経由でサーバーサイドで実行され、Visual Editing はプレビューモードでサポートされています。Sanity は保守されている Next.js スターターテンプレートを提供しており、それをクローンすることが動作するプロジェクトに到達する最速の方法です。
GROQ とは何であり、なぜそれが重要なのですか？
GROQ は Sanity のコンテンツクエリ言語で、グラフ型の投影ベースのクエリ言語であり、ヘッドレス CMS コンテンツに必要な結合とフィルタリングの種類向けに設計されています。ドキュメントグラフクエリに関しては GraphQL よりも表現力が高いです。欠点は GROQ が Sanity 固有のため、将来 Sanity から移行する場合はすべてのクエリを書き直す必要があることです。ほとんどのチームにとって、短期的な生産性の向上はロックインのリスクを上回ります。
関連資料
2026 年の WordPress 代替案：ノーコードが答えでない場合、スタック代替案に関する親記事、ヘッドレス CMS 選択肢に関するセクションを含みます。
WordPress から Next.js への移行でランキングを失わない方法は、CMS ターゲットが Sanity、Payload、またはその他のものであるかにかかわらず適用されます。SEO 転送は CMS に関係なく同じです。
ヘッドレスアーキテクチャの長所と短所、ヘッドレスモデル自体の誠実なトレードオフ、意思決定フレームワークの前置きとして有用です。
WordPress Stack Advisor、URL を貼り付けて、Sanity が特定のブリーフに適した CMS かどうかを含むカスタマイズされた推奨事項を取得します。
CMS の選択がボトルネックになることはほとんどない。ボトルネックは編集チームの新しいツールでの最初の 1 ヶ月である。編集チームが興奮している場合は Sanity を選択し、エンジニアリングチームが興奮している場合は Payload を選択する。
30 分間の CMS 選定通話を予約し、ブリーフ、チーム、タイムライン、統合について説明し、Sanity vs Payload vs Storyblok の決定について、トレードオフについて誠実な理解を持って話し合います。