【Web制作者必見】ヘッドレスCMSプレビュー環境構築方法を実装例も踏まえて徹底解説

2026年2月2日

生徒

ヘッドレスCMSで記事を書いているんですけど、公開前にプレビューで確認する方法が分かりません…どうやって実装すればいいですか？

ペン博士

よーく聞くんだぞ。今日はヘッドレスCMSのプレビュー環境構築について詳しく解説するぞい！実装方法は複数あるから、プロジェクトに合った方法を選ぶことが重要じゃ！

生徒

そうなんですね！ぜひ教えてください！

ヘッドレスCMSを使ったWebサイト開発では、公開前にコンテンツをプレビューできる環境が不可欠です。従来のWordPressなどのCMSでは標準でプレビュー機能が搭載されていますが、ヘッドレスCMSではフロントエンドとバックエンドが分離しているため、独自にプレビュー環境を構築する必要があります。

本記事では、Next.js App RouterとmicroCMSを使ったプレビュー環境の構築方法を、4つの実装パターンとともに詳しく解説します。実案件での選定基準、セキュリティ対策、トラブルシューティングまで網羅しています。

「学習→案件獲得」につなげた受講生のリアルな体験談も公開中！
働き方を変えたい方にも響くストーリーです。

片山さん
妊娠をきっかけに、子どものためにもどこでも働けるスキルを身に付けたいと考える。そこで、オンラインスクールのfammで1ヶ月間Web制作の勉強を開始。その後、独学で勉強に励むも限界を感じ、案件保証が魅力のWithCodeへ入学し、稼げる力を身に付けることができた。現在は副業として稼ぐ力を身に付け、10件以上の案件を担当するまでに成長した。

詳しくはこちらの記事をご覧ください。

片山さんの主な制作実績はこちら

信用力アップを目的にした新規HP制作

株式会社かぶらや様

企業ブランディング向上を目的にした新規HP制作

株式会社SOLIS 様

ヘッドレスCMSとは？

ヘッドレスCMS（Headless CMS）は、コンテンツ管理機能とフロントエンド（表示部分）が分離されたCMSです。従来のCMS（WordPress、Drupalなど）では、管理画面とフロントエンドが一体化していましたが、ヘッドレスCMSではAPIを介してコンテンツを配信します。

ヘッドレスCMSの特徴

API経由でコンテンツ配信：RESTful APIやGraphQLでデータを取得
フロントエンドの自由度：React、Vue、Next.jsなど好きな技術で構築
マルチチャネル対応：Web、モバイルアプリ、IoTデバイスなど複数の出力先
高速なパフォーマンス：静的生成（SSG）と相性が良い

主要なヘッドレスCMS

microCMS：日本製のヘッドレスCMS、日本語サポートが充実
Contentful：世界的に人気のヘッドレスCMS
Strapi：オープンソースのヘッドレスCMS
Sanity：リアルタイム編集が可能
Prismic：スライス機能が特徴

プレビュー環境が必要な理由

生徒

なぜプレビュー環境が必要なんですか？

ペン博士

コンテンツを公開前に確認することで、レイアウト崩れや誤字脱字を事前に防げるんじゃ！クライアントの確認作業にも必須じゃぞ！

1. レイアウト崩れの事前確認

実際のWebサイト上でコンテンツがどう表示されるかを確認できます。画像サイズ、テキストの長さ、改行位置など、CMS管理画面だけでは分からない表示を事前にチェックできます。

CMSの管理画面では、入力フォーム内のテキストしか見えません。
しかし、実際のサイトでは、

画像サイズが想定より大きい／小さい
テキストが長すぎてデザインが崩れる
改行位置が不自然になる
モバイル表示で余白が崩れる
見出し階層が適切に反映されない

といった問題が発生することがあります。

特にレスポンシブデザインでは、
PCでは問題なくても、スマホで崩れるケースが非常に多いです。

プレビュー環境があれば、

公開前に崩れを発見できる
デザイン修正コストを最小化できる
「公開後に慌てて修正」というリスクを防げる

という大きなメリットがあります。

2. クライアント確認プロセス

制作会社がWebサイトを納品する際、クライアントが公開前にコンテンツを確認する必要があります。

しかし、本番環境に直接反映してしまうと、

未完成の状態が一般ユーザーに見えてしまう
検索エンジンにインデックスされる
URLが拡散してしまう

といったリスクがあります。

プレビュー環境があれば、

限定URLで安全に共有できる
下書き状態のまま確認してもらえる
修正依頼を受けてから公開できる

という安全なワークフローが実現できます。

これは特に、

コーポレートサイト
医療・金融など信頼性重視のサイト
大型リニューアル案件

では非常に重要です。

3. 複数人での編集作業

複数の編集者が同時に記事を作成する場合、下書き状態のコンテンツを個別に確認できると便利です。

例えば、

ライターが原稿作成
ディレクターがチェック
クライアントが最終確認

という流れでは、下書き段階での共有が不可欠です。

プレビューがないと、

スクリーンショットでやり取りする
テキストを別ツールにコピペする
「どこを修正したのか分からない」状態になる

といった非効率が発生します。

プレビュー環境があれば、

下書きURLをそのまま共有できる
公開前の記事を個別に確認できる
複数記事を同時進行できる

ため、編集体制が整ったチーム運用が可能になります。

4. SEO最適化の確認

メタディスクリプション、OGP画像、構造化データなど、SEO関連の設定が正しく反映されているかをプレビューで確認できます。

プレビュー機能があることで、

メタディスクリプションが正しく出力されているか
OGP画像が意図通り表示されるか
titleタグが重複していないか
構造化データが正しく埋め込まれているか
canonicalタグが正しいか

を事前に確認できます。

特にOGPは、

サイズが規定外
画像が読み込めない
本番URLとズレている

といったトラブルが起きやすいため、
プレビュー確認は必須レベルです。

SEOは公開後に修正すると再クロール待ちになるため、
公開前のチェックが検索パフォーマンスに直結します。

プレビュー環境の4つの構築方法

生徒

ヘッドレスCMSの実装方法を知りたいです！

ペン博士

ヘッドレスCMSのプレビュー環境には、複数の実装パターンがある。それぞれメリット・デメリットがあるため、プロジェクトの要件に応じて選択するのじゃ！

方式A：クエリストリングベースのCSR（Client Side Rendering）

概要

クライアント側（ブラウザ）で、URLのクエリパラメータを基にAPIからデータを取得し、プレビュー表示する方法です。

実装例

// app/preview/[slug]/page.tsx
'use client';
import { useEffect, useState } from 'react';
import { useSearchParams } from 'next/navigation';
export default function PreviewPage({ params }: { params: { slug: string } }) {
  const searchParams = useSearchParams();
  const draftKey = searchParams.get('draftKey');
  const [article, setArticle] = useState(null);
  useEffect(() => {
    if (!draftKey) return;
    // クライアント側でAPIからデータ取得
    fetch(`https://your-service.microcms.io/api/v1/articles/${params.slug}?draftKey=${draftKey}`, {
      headers: {
        'X-MICROCMS-API-KEY': process.env.NEXT_PUBLIC_MICROCMS_API_KEY || '',
      },
    })
      .then((res) => res.json())
      .then((data) => setArticle(data));
  }, [params.slug, draftKey]);
  if (!article) return Loading...;
  return (
    
      {article.title}
      
    
  );
}

メリット

実装が簡単：シンプルなコードで実現可能
静的ホスティングに対応：S3やNetlifyなどで動作
サーバーコスト削減：完全静的生成で運用可能

デメリット

セキュリティリスク：APIキーがクライアント側に露出する
SEOに不利：クライアント側レンダリングのため検索エンジンがクロールできない
初期表示が遅い：データ取得に時間がかかる

推奨ケース

社内プレビューのみで、外部に公開しない場合。セキュリティ要件が低いプロジェクト。

方式B：環境変数によるSSR（Server Side Rendering）

概要

ステージング環境と本番環境で異なる環境変数を使い分け、ステージング環境ではキャッシュを無効化してプレビュー表示する方法です。

実装例

// app/articles/[slug]/page.tsx
import { getArticle } from '@/lib/microcms';
export const revalidate = process.env.NODE_ENV === 'production' ? 3600 : 0; // ステージングではキャッシュ無効
export default async function ArticlePage({ params }: { params: { slug: string } }) {
  // ステージング環境では下書きを含むデータを取得
  const article = await getArticle(params.slug, {
    draftKey: process.env.MICROCMS_DRAFT_KEY,
  });
  return (
    
      {article.title}
      
    
  );
}

// lib/microcms.ts
import { createClient } from 'microcms-js-sdk';

const client = createClient({
  serviceDomain: process.env.MICROCMS_SERVICE_DOMAIN || '',
  apiKey: process.env.MICROCMS_API_KEY || '',
});

export async function getArticle(slug: string, options?: { draftKey?: string }) {
  return await client.get({
    endpoint: 'articles',
    contentId: slug,
    queries: options?.draftKey ? { draftKey: options.draftKey } : {},
  });
}

環境変数の設定例

# 本番環境（.env.production）
MICROCMS_API_KEY=your-production-api-key
NODE_ENV=production

# ステージング環境（.env.staging）
MICROCMS_API_KEY=your-staging-api-key
MICROCMS_DRAFT_KEY=your-draft-key
NODE_ENV=development

メリット

セキュリティが高い：APIキーがサーバー側のみで管理される
一覧ページもプレビュー可能：すべてのページで下書きが表示される
実装がシンプル：既存コードの変更が少ない

デメリット

2環境必要：ステージングと本番の2つの環境を維持する必要がある
運用コスト増加：環境構築とデプロイの手間が2倍
本番と完全に同じではない：環境差異が発生する可能性

推奨ケース

すでにステージング環境が存在するプロジェクト。一覧ページのプレビューも必要な場合。

方式C：draftMode活用（Next.js公式推奨）

概要

Next.js 13以降で提供されるdraftMode機能を使い、Cookieベースでプレビューモードを切り替える方法です。Next.js公式で推奨されている標準的な実装方法です。

実装例

ステップ1：プレビューAPIルートの作成

// app/api/draft/route.ts
import { draftMode } from 'next/headers';
import { redirect } from 'next/navigation';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const slug = searchParams.get('slug');
  const secret = searchParams.get('secret');

  // シークレットトークンの検証
  if (secret !== process.env.PREVIEW_SECRET) {
    return new Response('Invalid token', { status: 401 });
  }

  if (!slug) {
    return new Response('Slug is required', { status: 400 });
  }

  // draftModeを有効化
  draftMode().enable();

  // プレビューページにリダイレクト
  redirect(`/articles/${slug}`);
}

ステップ2：記事ページでdraftModeを判定

// app/articles/[slug]/page.tsx
import { draftMode } from 'next/headers';
import { getArticle } from '@/lib/microcms';
export default async function ArticlePage({ params }: { params: { slug: string } }) {
  const { isEnabled } = draftMode();
  // draftMode有効時は下書きデータを取得
  const article = await getArticle(params.slug, {
    draftKey: isEnabled ? process.env.MICROCMS_DRAFT_KEY : undefined,
  });
  return (
    
      {isEnabled && (
        
          プレビューモード中
      
      )}
      {article.title}
      
    
  );
}

ステップ3：プレビュー解除APIの作成

// app/api/disable-draft/route.ts
import { draftMode } from 'next/headers';
import { redirect } from 'next/navigation';

export async function GET() {
  draftMode().disable();
  redirect('/');
}

microCMS側の設定

microCMSの管理画面で、プレビューURLを設定します。

https://your-site.com/api/draft?secret=YOUR_SECRET&slug={CONTENT_ID}

メリット

Next.js公式推奨：標準機能で安定動作
1環境で完結：本番環境のみでプレビューが可能
セキュリティが高い：シークレットトークンで保護
SSRのメリット：初期表示が速く、SEOにも有利

デメリット

Cookieの理解が必要：挙動がやや分かりづらい
手動で解除が必要：プレビューモードを終了するAPIを叩く必要がある
一覧ページのプレビューは工夫が必要：個別ページのみ対応

推奨ケース

最も推奨される方法。Next.jsを使った新規プロジェクトや、1環境で運用したい場合。

方式D：クエリストリングベースのSSR

概要

URLのクエリパラメータにdraftKeyを含め、サーバー側でAPIからデータを取得してプレビュー表示する方法です。microCMSの公式テンプレートでも採用されています。

実装例

// app/articles/[slug]/page.tsx
import { getArticle } from '@/lib/microcms';
export default async function ArticlePage({
  params,
  searchParams,
}: {
  params: { slug: string };
  searchParams: { draftKey?: string };
}) {
  // draftKeyがある場合は下書きを取得
  const article = await getArticle(params.slug, {
    draftKey: searchParams.draftKey,
  });
  return (
    
      {searchParams.draftKey && (
        
          プレビューモード中
        
      )}
      {article.title}
      
    
  );
}

microCMS側の設定

https://your-site.com/articles/{CONTENT_ID}?draftKey={DRAFT_KEY}

メリット

実装がシンプル：追加のAPIルート不要
URLで共有可能：プレビューURLを他の人に共有しやすい
セキュリティが高い：draftKeyが知られない限り安全
SSRのメリット：初期表示が速い

デメリット

URLにdraftKeyが露出：URLが漏れるとセキュリティリスク
キャッシュの制御が必要：draftKey付きのページをキャッシュしないよう設定

推奨ケース

シンプルな実装を優先したい場合。microCMS公式テンプレートをベースにしたい場合。

4つの方式の比較表

項目	方式A（CSR）	方式B（環境変数SSR）	方式C（draftMode）	方式D（クエリSSR）
レンダリング	クライアント側	サーバー側	サーバー側	サーバー側
セキュリティ	低い	高い	高い	中程度
環境数	1環境	2環境	1環境	1環境
実装難易度	簡単	簡単	やや複雑	簡単
運用コスト	低い	高い	低い	低い
一覧プレビュー	△	◯	△	△
推奨度	★☆☆☆☆	★★★☆☆	★★★★★	★★★★☆

実案件での選定基準

生徒

どの方式を選べばいいか迷います…

ペン博士

プロジェクトの要件に応じて選ぶんじゃ！選定のポイントを教えるぞい！

ケース1：Next.jsの新規プロジェクト

推奨：方式C（draftMode）

Next.js公式推奨の方法で、1環境で完結し、セキュリティも高い。

ケース2：すでにステージング環境がある

推奨：方式B（環境変数SSR）

既存のステージング環境を活用でき、一覧ページのプレビューも可能。

ケース3：シンプルさを優先

推奨：方式D（クエリストリングSSR）

実装が簡単で、microCMSの公式テンプレートでも採用されている。

ケース4：静的ホスティング（S3、Netlifyなど）

推奨：方式A（CSR）または別途サーバーを用意

SSRが使えない環境では、CSRを使うか、Vercelなどサーバー機能がある環境に移行。

セキュリティ対策

生徒

実装するにあたりセキュリティ面がう不安なんですけど、
具体的に何をすれば良いですか？

ペン博士

良い質問じゃ！主に4つの方法がある。今から解説するぞい！

1. シークレットトークンの設定

プレビューAPIには必ずシークレットトークンを設定し、不正アクセスを防ぎます。

// 環境変数
PREVIEW_SECRET=your-random-secret-string-here

// APIルートで検証
if (secret !== process.env.PREVIEW_SECRET) {
  return new Response('Invalid token', { status: 401 });
}

2. APIキーの適切な管理

microCMSのAPIキーはサーバー側のみで使用し、クライアント側に露出させません。

// 悪い例：クライアント側でAPIキーを使用
const response = await fetch(`https://api.microcms.io/articles`, {
  headers: {
    'X-MICROCMS-API-KEY': 'your-api-key', // 露出してしまう
  },
});

// 良い例：サーバー側でAPIキーを使用
// app/api/articles/route.ts
export async function GET() {
  const response = await fetch(`https://api.microcms.io/articles`, {
    headers: {
      'X-MICROCMS-API-KEY': process.env.MICROCMS_API_KEY, // 安全
    },
  });
  return response;
}

3. draftKeyの有効期限設定

microCMS側で、draftKeyに有効期限を設定できます。長期間有効なキーは避けましょう。

4. IPアドレス制限

プレビュー環境へのアクセスを特定のIPアドレスのみに制限することも有効です。

トラブルシューティング

生徒

ヘッドレスCMSのプレビュー環境構築するにあたってトラブルシューティングのことも知りたいです！

ペン博士

うむ。ここでは、主なトラブルシューティングを3つ紹介するぞい！

問題1: プレビューが表示されない

原因と解決法:

環境変数の設定ミス → MICROCMS_API_KEY、PREVIEW_SECRETを確認
draftKeyが間違っている → microCMS管理画面で正しいdraftKeyを確認
キャッシュが残っている → ブラウザのキャッシュをクリア

問題2: draftModeが解除されない

原因と解決法:

Cookieが残っている → 手動でCookieを削除するか、/api/disable-draftにアクセス
別のブラウザやシークレットモードで確認 → Cookieが共有されていない

問題3: 本番環境でもプレビューが表示される

原因と解決法:

環境変数の設定ミス → 本番環境にMICROCMS_DRAFT_KEYを設定していないか確認
キャッシュの設定ミス → プレビューページがキャッシュされていないか確認

生徒

プレビュー環境の構築方法がよく分かりました！プロジェクトに合った方法を選んで実装してみます！

ペン博士

その通りじゃ！まずはdraftModeから始めて、Next.jsの標準的な実装方法を学ぶのがおすすめじゃぞ！セキュリティにも気をつけるんじゃ！

生徒

はい！次のプロジェクトでdraftModeを使ったプレビュー環境を構築してみます！ありがとうございました！

まとめ

本記事では、ヘッドレスCMSのプレビュー環境構築方法について、4つの実装パターンを詳しく解説しました。

重要なポイントは以下の通りです。

・プレビュー環境の必要性：レイアウト確認、クライアント確認、SEO最適化に不可欠
・4つの実装方法：CSR、環境変数SSR、draftMode、クエリストリングSSR
・推奨方法：Next.jsプロジェクトではdraftModeが最適
・セキュリティ対策：シークレットトークン、APIキー管理、有効期限設定が重要
・選定基準：プロジェクトの要件、環境、予算に応じて最適な方法を選択

WithCodeで学んだNext.js・React・TypeScriptの基礎知識に、ヘッドレスCMSのプレビュー環境構築技術を組み合わせれば、どんな実案件でも対応できます。

ヘッドレスCMSのプレビュー環境は、クライアントワークに必須の機能です。ぜひ実際のプロジェクトで活用し、高品質なWebサイトを納品してください。

WithCodeを体験できる初級コース公開中！

初級コース（¥49,800）が完全無料に！

期間：1週間
学習内容：
ロードマップ/基礎知識/環境構築/HTML/CSS/LP・ポートフォリオ作成
→ 正しい学習方法で「確かな成長」を実感できるカリキュラム

副業・フリーランスが主流になっている今こそ、自らのスキルで稼げる人材を目指してみませんか？

未経験でも心配することはありません。初級コースを受講される方の大多数はプログラミング未経験です。まずは無料カウンセリングで、悩みや不安をお聞かせください！

公式サイトから無料カウンセリングに申し込む →

この記事を書いた人

WithCode 編集部

WithCode（ウィズコード）は「目指すなら稼げる人材」をビジョンに、累計400名以上のフリーランスを輩出してきた超実践型プログラミングスクールです。150社以上の実案件支援を特徴にWeb制作・Webデザインなどの役立つ情報を現場のノウハウに基づいて発信していきます。

【Web制作者必見】ヘッドレスCMSプレビュー環境構築方法を実装例も踏まえて徹底解説

ヘッドレスCMSとは？

ヘッドレスCMSの特徴

主要なヘッドレスCMS

プレビュー環境が必要な理由

1. レイアウト崩れの事前確認

2. クライアント確認プロセス

3. 複数人での編集作業

4. SEO最適化の確認

プレビュー環境の4つの構築方法

方式A：クエリストリングベースのCSR（Client Side Rendering）

概要

実装例

メリット

デメリット

推奨ケース

方式B：環境変数によるSSR（Server Side Rendering）

概要

実装例

環境変数の設定例

メリット

デメリット

推奨ケース

方式C：draftMode活用（Next.js公式推奨）

概要

実装例

microCMS側の設定

メリット

デメリット

推奨ケース

方式D：クエリストリングベースのSSR

概要

実装例

microCMS側の設定

メリット

デメリット

推奨ケース

4つの方式の比較表

実案件での選定基準

ケース1：Next.jsの新規プロジェクト

ケース2：すでにステージング環境がある

ケース3：シンプルさを優先

ケース4：静的ホスティング（S3、Netlifyなど）

セキュリティ対策

1. シークレットトークンの設定

2. APIキーの適切な管理

3. draftKeyの有効期限設定

4. IPアドレス制限

トラブルシューティング

問題1: プレビューが表示されない

問題2: draftModeが解除されない

問題3: 本番環境でもプレビューが表示される

まとめ

WithCodeを体験できる初級コース公開中！

初級コース（¥49,800）が完全無料に！

この記事を書いた人

関連記事

– service –WithCodeの運営サービス