2026年10月8日にContentful Content Preview API、Strapi Draft & Publish、Sanity Visual Editingの必要本文を再確認した。配信APIと編集UIは別の役割で、draft previewのtokenと公開データを分離し、編集者・運用者が公開、失敗、復旧を具体的な手順で確認する。Contentfulの公式ページは原カードでHTTP 429だったため通常GET成功とは扱わず、資料の必要範囲だけを採用する。料金比較、復旧全体、実API受入、preview権限設定、セキュリティ合格を公式機能説明から保証しない。
Headless CMSは、コンテンツの管理と表示するアプリケーションを分け、APIなどで内容を渡す方式です。選定では製品一覧を見る前に、編集者が下書きを確認し、承認し、公開後の誤りを戻すまでの手順を決めます。ReactやNext.jsの採用だけでは、運用できるかは判断できません。
30秒で要点
- 編集画面の使いやすさに加え、下書きのプレビュー、承認、公開、配信への反映、回復まで一巡して比較します。
- Webとアプリで内容を再利用する構想がある場合も、共通化するデータ項目と表示側の責任を具体化します。
- 非公開データやプレビュー用トークンを公開側へ出さず、更新通知の失敗やキャッシュの古さを観察できる設計が必要です。
従来CMSとHeadless CMSの違いを責任で見る
従来CMSは管理と表示の機能がまとまっていることが多く、用意されたテーマやプラグインで運用を始めやすい構成があります。Headless CMSでは表示側を自由に作りやすい一方、プレビュー、URL、検索、フォーム、配信更新などを別の仕組みへ接続する作業が生じます。どちらにも多様な実装があり、「必ず安い」「必ず速い」という分類はできません。
表が収まらない場合は、横にスクロールできます
| 比較軸 | 確認する問い | 実演してもらう作業 |
|---|---|---|
| 編集 | 非エンジニアが誤りを発見できるか | 見出し・画像・リンクを変更して確認 |
| 公開 | 誰が何を承認するか | 下書きを承認後に公開 |
| 反映 | 公開後いつ、どこへ届くか | Webと別表示の更新確認 |
| 回復 | 誤公開や配信障害から戻せるか | 旧版復元、再配信、キャッシュ確認 |
| 移行 | 内容・画像・関係を持ち出せるか | 架空データの書き出しと読み戻し |
API連携と編集者の操作を別々に確認する
フロントエンドがReactやNext.jsでも、使えるプレビューや承認機能が自動的に完成するわけではありません。別のフレームワークでもAPI連携は可能です。選定条件は「使っている言語名」から、「今回の表示・編集・配信要件を接続できるか」へ置き換えます。
また、非エンジニアが毎日更新することはHeadlessを除外する理由にはなりません。実際の担当者に、下書きと公開済みの違い、入力エラー、画像の代替テキスト、リンク先、プレビューの見方を確認してもらいます。開発者が横で操作し続けないと完了できないなら、その支援負担を見積もりに含めます。
マルチチャネル展開では、本文を一つにすればすべて共通になるとは限りません。Web向けの表や埋め込みがアプリでは使えない場合もあります。見出し、要約、画像、本文、関連項目などを、どのチャネルが何に使うかを書き出してからモデルを設計します。
製品の確認範囲をそろえる
以下は確認した公式説明から、試験すべき部分を整理したものです。料金、全プランの機能、性能の順位を示す比較ではありません。契約時には採用するプラン・版・権限設定で再確認します。
表が収まらない場合は、横にスクロールできます
| 製品 | 公式資料で確認する部分 | 試す課題と留保 |
|---|---|---|
| Contentful | 公開・未公開内容を読むContent Preview API | プレビュー用トークンを分離し、公開APIへ未公開内容が混入しないか確認 |
| Strapi | コンテンツタイプごとのDraft & Publishと公開状態 | 機能の有効化、下書きと公開済みの違いを編集者が識別できるか確認 |
| Sanity | Visual Editingのライブプレビューや編集箇所との接続 | 採用するフロントエンドで実装し、操作・権限・反映を確認 |
ContentfulのPreview API説明では、公開・未公開の内容を扱う読み取り専用APIが説明されています。通常取得は今回429応答でしたが、公式ページ本文の必要範囲は別の閲覧で確認しています。この取得結果をAPI本体の障害や製品の性能評価に置き換えてはいません。
StrapiのDraft & PublishとSanityのVisual Editingも、機能名だけで運用の完成を意味しません。編集、承認、公開先、回復を同じ課題で比較してください。
架空のニュース更新を最後まで試す
「翌営業日の午前に公開するニュース」を課題にします。担当者は編集者、承認者、配信の運用担当の三役です。実際の顧客情報や本番の公開先を使わず、検証用の内容で一巡します。
- 項目を決める。 見出し、要約、公開予定日時、本文、画像、代替テキスト、関連リンクを登録します。必須入力とエラー表示も確認します。
- 下書きをプレビューする。 公開用とは分けた認証で表示し、未公開情報が検索や共有キャッシュへ出ないことを確認します。URLを知るだけで誰でも見られる構成なら保留します。
- 承認する。 承認者が文章だけでなくリンク先と小画面の表示を確かめ、誰が承認したかを残します。承認後の再編集で再承認が必要かも決めます。
- 公開し、反映を観察する。 CMSの公開済み表示だけで完了にせず、Web側の取得・再生成・キャッシュ更新が終わり、予定の内容が表示されたことを確認します。
- 通知失敗を試す。 更新通知が届かなかったときに、運用担当が検知し、同じ通知の再送で二重処理せず再反映できるか確かめます。
- 誤公開から回復する。 旧版へ戻し、表示側にも戻った内容が届いたことを確認します。画像削除やモデル変更を伴う場合は本文履歴だけで戻せないので、別の復旧手順を試します。
「プレビューが見えた」と「公開・回復まで運用できた」は別の達成です。各段階を担当者が自力で完了できるか、未確認の部分を残してください。
公開と回復の約束を記入する
表が収まらない場合は、横にスクロールできます
| 設計欄 | 架空の記入例 |
|---|---|
| 公開対象 | 承認済みニュースと画像、個人情報を含めない |
| 編集と承認 | 編集者が下書き、別担当が表示とリンクを確認 |
| 更新の許容時間 | 公開後5分以内に表示反映するというチーム内目標 |
| 反映観測 | CMSの版、通知ID、配信結果、表示中の版を対応付ける |
| 失敗時 | 自動再試行の上限後に担当へ通知し、原因を確認して再配信 |
| 戻す条件 | 誤公開、未公開情報混入、表示欠落、反映時間超過 |
| 回復の確認 | 旧版本文・画像・リンクが同じ公開URLで表示される |
5分はこの架空チームの目標で、各製品の保証ではありません。公開直後に1分の処理待ちと3分のキャッシュ待ちが重なるなら、合計4分を見込むという例になります。同時に進む処理か直列の処理かで計算は変わるため、実際の時刻を別々に記録します。
費用と移行まで含めて採用を決める
初期実装だけでなく、編集画面への接続、プレビュー、権限管理、配信監視、障害対応、依存更新、画像やデータの持ち出しを含めて見積もります。無料プランで試せた操作が契約条件でも同じか、利用人数・言語・データ量が増えたときに何が変わるかを確認します。
候補を採用する条件は、実担当者が試験を一巡でき、必要な権限と回復手順が揃い、残る運用負担を担当者が引き受けられることです。満たせなければ、従来CMSの継続や対象範囲を小さくする選択も検討します。
選定表の作り方はCMS選定ガイド、表示側の設計はNext.jsでのWeb制作、制作工程全体はWeb制作ガイドへつなげてください。