「編集画面には入力欄しかない。公開ボタンを押すまで、実際の見た目が分からない」。ヘッドレスCMSの導入を検討する制作会社から、この不安をよく聞きます。WordPressのプレビューに慣れていると、当然の心配です。

結論から言うと、保存前のデータをそのままAPIで取りにきて描画する「完全なリアルタイムプレビュー」は、ヘッドレス構成では作り込みが要ります。現実的な解は、下書きをいったんサーバーに保存し、認証付きのプレビューURLで本番と同じテンプレートに流し込んで確認する形です。自分のサイト（Astro＋EmDash）が実際どう動いているかを、コードで確認しながら説明します。

なぜヘッドレスだとプレビューが引っかかるのか

ヘッドレスCMSは、コンテンツ管理と表示（フロント）を分離するのが特徴です。編集画面は入力フォーム、表示は別のアプリ。この分離が速度やセキュリティの強みになる一方、編集者から「今書いているものが本番でどう見えるか」が見えにくくなります。

WordPressはテーマとデータが一体なので、下書きをそのままプレビュー画面で描けました。ヘッドレスでは表示側が別物なので、下書きの中身を表示側へ渡す仕組みを別途つくる必要があります。各CMSでプレビューの実現方法は違い、専用のライブプレビュー機能やビューアーを用意している製品もありますが、「表示側へ一方向にデータを流して見せる」構成が一般的とされています。

引っかかる原因を分けると、こうなります。

  • 入力中の未保存データは、表示側からAPIで取りにくい
  • 下書き（非公開）データは、公開APIには出さないのが普通
  • だから「保存 → 認証付きで下書きを表示側へ渡す」段取りが要る
ヘッドレスCMSのプレビュー、よくある懸念と実装での解決を対比した表

現実解は「下書き保存＋認証付きプレビューURL」

入力中の一文字ごとを表示側に反映させる必要は、実務ではあまりありません。編集者がやりたいのは「公開前に、本番と同じ画面で最終確認する」こと。ここを満たせば十分です。

自分のサイトで確認したEmDashのプレビューは、次の流れで動いていました。

  • 編集内容は公開版とは別の「下書きリビジョン」としてDBに保存される（draft_revision_id で参照）
  • 管理画面から署名付きのプレビューURLを発行する。URL末尾に _preview=… というトークンが付く
  • そのURLを開くと、表示側のミドルウェアがトークンを検証し、正しければ下書きの中身を描画する

肝は「保存」と「署名」です。未保存のデータではなく、いったん下書きとして保存したものを見る。そして、そのURLは誰でも開けるわけではなく、署名で守られています。

プレビュー実装の構成要素、下書き保存・認証付きURL・同じテンプレート・公開前確認の4点

トークンで下書きを守る仕組み

プレビューURLに付くトークンは、EmDashのコードを読むとHMAC-SHA256で署名されていました（src/preview/tokens.ts）。中身は「対象コンテンツのID」と「有効期限」で、既定の有効期限は1時間です。

const payload = {
  cid: contentId,   // "blog_posts:記事ID" のように対象を限定
  exp: now + duration, // 期限（既定1時間）
  iat: now,
};

このトークンは対象コンテンツごとに限定されます。ある記事のプレビューURLを、別の記事に使い回すことはできません。表示側のミドルウェア（src/astro/middleware/request-context.ts）が _preview を受け取ると署名と期限を検証し、通ったときだけ下書きを表示する仕組みでした。期限切れや改ざんは弾かれ、プレビュー用のレスポンスには Cache-Control: private, no-store が付いて、キャッシュに残らないようになっています。

もう一つの経路が、ログイン済みの編集者向けの「編集モード」です。認証されたユーザーはコンテンツ全体の下書きを見られます。URLトークンは「関係者に一時的に共有する」用、編集モードは「ログイン中の本人が確認する」用、と使い分けられていました。

本番と同じテンプレートで描くから、ズレない

プレビューで見落としやすいのが「プレビュー専用の画面を別に作ってしまう」パターンです。それだと本番と見た目がズレて、確認の意味が薄れます。

自分のサイトでは、記事ページのテンプレート（src/pages/blog/[slug].astro）は1つだけです。公開記事もプレビューも同じテンプレートを通ります。違うのは「表示するデータが公開版か下書きリビジョンか」だけ。getEmDashEntry という同じ関数を呼び、プレビュー時は下書きの中身を返す作りになっていました。だから、プレビューで見た余白・見出し・画像の並びが、そのまま本番になります。

制作会社の視点でまとめると、ヘッドレス導入で気にすべきは「プレビューがあるか」だけではありません。

  • 下書きが公開版と分けて保存されるか
  • プレビューURLが署名などで保護され、期限が切れるか
  • 本番と同じテンプレートで描画されるか（別画面を作っていないか）
  • 公開前の最終確認が、編集者の操作だけで完結するか

この4点が押さえられていれば、「編集者が公開前に見られない」という不安は実装で解けます。自分は実際にこの構成で運用していて、記事の公開前確認で困ったことはありません。

ヘッドレスCMSのプレビュー実装や、Astro＋ヘッドレス構成そのものの相談は、Astro・ヘッドレスの実装を任せたい制作会社へや、EmDashとは何か、WordPressからEmDashへの乗り換えもあわせてどうぞ。実装の勘所を一次情報で書いています。

Web制作・コーディングのご相談、お見積もりはすべて無料です。ヘッドレス導入の「ここが不安」を、実装でどう解くか一緒に整理します。まずは お問い合わせ からお気軽にどうぞ。