microCMSで「本番公開」をチェックボックス1つで切り替える実装ガイド【Next.js対応】

はじめに

microCMSでサイトを運用していると、こんな場面に遭遇しないでしょうか。

「記事はもう書き終わったけど、本番に出す前にステージング環境で表示確認したい」 「公開タイミングはディレクターが決めるから、エンジニアのデプロイ作業なしで切り替えたい」

microCMSには「下書き」と「公開」のステータス機能がありますが、これはあくまでmicroCMS内部の状態管理です。フロントエンド側で「開発環境では全件表示、本番では公開済みだけ表示」といった出し分けをしたい場合、もうひと工夫が必要になります。

この記事では、microCMSのブール値（真偽値）フィールドを1つ追加するだけで、本番公開をコントロールできる仕組みを紹介します。コード量も少なく、非エンジニアのメンバーでもCMS画面からチェックを入れるだけで運用できるのがポイントです。

どういう仕組みなのか

やっていることはシンプルです。

microCMSのコンテンツに isProductionRelease というブール値フィールドを追加します。フロントエンド側では、本番環境のときだけ「isProductionReleaseがtrueのコンテンツ」に絞り込んでAPIを叩く。開発環境ではフィルターをかけず全件取得する。これだけです。

つまり、コンテンツの公開・非公開をmicroCMSのチェックボックス1つで切り替えられるようになります。デプロイは不要です。

microCMS側の設定手順

まず、microCMSの管理画面でAPIスキーマにフィールドを追加します。

対象のAPIスキーマ設定画面を開き、新しいフィールドを追加してください。フィールド名は「本番公開」、フィールドIDは isProductionRelease、種類は「真偽値」を選択します。

これだけで準備は完了です。既存のコンテンツには自動的にfalse（OFF）が入るので、過去のコンテンツが意図せず非公開になることはありません。ただし、本番環境で表示するには既存コンテンツのフラグもONにする必要があるので、導入時にまとめて切り替える作業が発生します。この点だけ注意してください。

運用の流れ

日常的な運用は以下のようになります。

まず、ライターやディレクターがmicroCMSでコンテンツを作成・編集します。この段階では isProductionRelease はOFFのままにしておきます。

次に、開発環境（ステージング環境）でページの表示を確認します。開発環境ではフィルターがかからないので、フラグがOFFでもコンテンツは表示されます。レイアウト崩れや誤字がないかをここでチェックしましょう。

問題がなければ、microCMSの管理画面で isProductionRelease をONに変更します。これだけで本番環境にコンテンツが反映されます。

もし公開後に問題が見つかった場合は、チェックを外すだけで本番から非表示にできます。ロールバックも一瞬です。

フロントエンド側の実装

ここからはフロントエンドの実装です。microCMS APIへのリクエスト時に、環境変数を見てフィルター条件を分岐させます。

// lib/microcms.ts

function isProduction(): boolean {
  return process.env.ENV === "production";
}

async function fetchNews(): Promise<News[]> {
  let filters = "";

  if (isProduction()) {
    filters = "isProductionRelease[equals]true";
  }

  const response = await microCMSClient.getList({
    endpoint: "news",
    queries: { filters },
  });

  return response.contents;
}

コードの解説をしておきます。

isProduction() は環境変数 ENV の値で本番かどうかを判定する関数です。Vercelを使っている場合は VERCEL_ENV を参照するなど、デプロイ先に合わせて書き換えてください。

filters にはmicroCMSのフィルター構文を渡しています。isProductionRelease[equals]true と指定すると、ブール値がtrueのコンテンツだけが返ってきます。開発環境では空文字を渡しているので、フィルターなし＝全件取得になります。

この分岐を入れるだけで、本番環境と開発環境の表示内容を自動的に出し分けできます。

複数エンドポイントで使い回す場合

「お知らせ」だけでなく「ブログ」「事例紹介」など複数のエンドポイントで同じ仕組みを使いたい場合は、フィルター生成を共通化しておくと便利です。

// lib/microcms.ts

function getProductionFilter(existingFilters?: string): string {
  if (!isProduction()) return existingFilters || "";

  const productionFilter = "isProductionRelease[equals]true";

  if (existingFilters) {
    return `${existingFilters}[and]${productionFilter}`;
  }

  return productionFilter;
}

// 使用例
async function fetchNews(): Promise<News[]> {
  const response = await microCMSClient.getList({
    endpoint: "news",
    queries: { filters: getProductionFilter() },
  });
  return response.contents;
}

async function fetchBlogs(categoryId?: string): Promise<Blog[]> {
  const categoryFilter = categoryId
    ? `category[equals]${categoryId}`
    : "";

  const response = await microCMSClient.getList({
    endpoint: "blogs",
    queries: { filters: getProductionFilter(categoryFilter) },
  });
  return response.contents;
}

getProductionFilter は既存のフィルター条件がある場合に [and] で結合してくれるヘルパー関数です。カテゴリ絞り込みなど他のフィルターと組み合わせるケースでも、この関数を通せば本番フィルターが自動的に付与されます。

導入時の注意点

この仕組みを導入するにあたって、いくつか気をつけておきたい点があります。

まず、ISR（Incremental Static Regeneration）やSSGを使っている場合です。microCMS側でフラグを切り替えても、フロントエンドのキャッシュが残っていると反映が遅れることがあります。microCMSのWebhookとオンデマンドISRを組み合わせるか、revalidateの時間を短めに設定しておくと安心です。

次に、一覧ページと詳細ページの整合性です。一覧では非表示なのに、URLを直接叩くと詳細ページが見えてしまう、というケースは避けたいところです。一覧取得だけでなく、詳細取得のAPIにも同じフィルター処理を入れるようにしてください。

最後に、microCMSの「予約公開」機能との使い分けです。予約公開はCMS側のステータス管理で、今回の仕組みはフロントエンド側の表示制御です。役割が異なるので併用可能ですが、運用ルールが複雑にならないように、チーム内で「どちらをどう使うか」を事前に決めておくことをおすすめします。

まとめ

microCMSにブール値フィールドを1つ追加し、フロントエンドの取得処理にフィルター分岐を入れるだけで、本番公開の制御が実現できます。

コードの変更量はごくわずかですし、運用もmicroCMSのチェックボックスを切り替えるだけ。非エンジニアのメンバーでも安心して公開作業を行えるようになります。

ステージング環境での確認フローを整えたい、公開タイミングの権限をディレクターに渡したい、といった課題を感じている方は、ぜひ試してみてください。