microCMSとは?日本製ヘッドレスCMSの特徴と強み
microCMSの概要 — APIベースの国産ヘッドレスCMS
microCMSは、株式会社microCMSが2019年9月にリリースした APIベースのヘッドレスCMS(コンテンツ管理システム)です。 「ヘッドレス」とは、従来のCMS(WordPressなど)が持つフロントエンド(表示部分)を持たず、コンテンツ管理のバックエンド機能だけを提供するアーキテクチャを意味します。
最大の特徴は、日本製で管理画面が完全日本語対応していることです。 海外製のヘッドレスCMS(ContentfulやStrapiなど)は英語UIが基本ですが、 microCMSは管理画面・ドキュメント・サポートのすべてが日本語で利用できます。 これは非エンジニアのチームメンバー(ライター・編集者・マーケター)との 協業において非常に大きなアドバンテージです。
2026年4月時点での主要な実績は以下のとおりです。
- 導入企業数: 14,000社以上(国内ヘッド��スCMS最大級)
- 継続率: 99%
- パートナー企業数: 100社以上(2026年1月時点)
- 導入企業例: ABEMA、SmartHR、ポート、LIFULL、カカクコムなど
ヘッドレスCMSと従来型CMSの違い
そもそも「ヘッドレスCMS」とは何が違うのか。 WordPressに代表される従来型CMS(カップルドCMS)と比較して理解しましょう。
| 比較項目 | 従来型CMS(WordPress等) | ヘッドレスCMS(microCMS等) |
|---|
| アーキテクチャ | フロント+バックエンド一体型 | バックエンドのみ(API提供) |
| 表示技術 | PHP + テーマ | 自由(React / Next.js / Vue等) |
| 表示速度 | サーバーレンダリング(やや遅い) | SSG/ISRで高速 |
| セキュリティ | プラグイン脆弱性のリスク | 攻撃面が小さい |
| カスタマイズ性 | テーマ・プラグインに依存 | フロントエンドを完全自由に設計 |
| サーバー管理 | 自分で管理(or マネージド) | 不要(SaaS) |
| 学習コスト | 低い(GUI中心) | やや高い(API・フロント開発が必要) |
ShiftB校長 ぶべの見解として、 「2026年の個人開発でWordPressを選ぶ理由はほとんどない」と断言できます。 Next.js + microCMSの組み合わせなら、表示速度・セキュリティ・開発体験のすべてが WordPressを大幅に上回ります。唯一WordPressが有利なのは 「プラグインで即座に機能追加したい非エンジニア」のケースですが、 個人開発者(=コードが書ける人)にはヘッドレスCMS一択です。
microCMSの主要機能一覧
microCMSが提供する機能を整理します。
- APIスキーマ定義: GUI上でフィールドを追加してAPI構造を設計
- リッチエディタ: 見出し・リスト・画像・コード埋め込みに対応したWYSIWYGエディタ
- 画像API(imgix連携): アップロード画像をURLパラメータでリサイズ・フォーマット変換
- Webhook: コンテンツの公開・更新時に外部サービスへ通知
- 画面プレビュー: 下書き状態のコンテンツをフロントエンドで確認
- コンテンツ参照: API間でリレーション(参照関係)を定義
- メディア管理: 画像・ファイルの一元管理
- AIレビュー: コンテンツの品質をAIがチェック(Teamプラン以上)
- APIグループ: APIをグループ化して管理しやすく整理
- カスタムステータス: 「下書き → レビュー中 → 公開」などワークフローを定義(Businessプラン以上)
microCMSが個人開発者に向いている4つの理由
理由1: 無料プランでも本格運用が可能
Hobbyプラン(無料)でもAPIコール無制限、コンテンツ10,000件まで管理でき、 個人ブログやポートフォリオサイトなら十分すぎるスペックです。 クレジットカード登録も不要で、アカウント作成後すぐに使い始められます。
理由2: 日本語ドキュメントが充実している
公式ドキュメント、ブログ記事、チュートリアルがすべて日本語で提供されています。 Next.js(App Router / Pages Router)との連携チュートリアルも公式に用意されており、 初学者でも迷わずセットアップできます。 海外CMS特有の「英語ドキュメントを読み解く」ストレスが��ロです。
理由3: セットアップが圧倒的に簡単
サーバー構築もデータベース設計も不要。ブラウザ上でAPI定義を作り、 SDKをインストールするだけで、最短30分でコンテンツ管理を始められます。 ShiftBの受講生データでは、microCMSの初期セットアップ(アカウント作成〜最初のAPIコール成功)に 平均45分しかかかっていません。
理由4: Next.js / Vercelとの相性が抜群
microCMSはNext.jsとの連携を公式にサポートしており、 SSG(静的サイト生成)・ISR(増分静的再生成)・SSR(サーバーサイドレンダリング) すべてのレンダリング方式に対応しています。 Vercelへのデプロイ + microCMSのWebhookを組み合わせれば、 コンテンツ更新時に自動でサイトを再ビルドする仕組みも簡単に構築できます。

microCMSの料金プランと選び方【2026年最新】
全プランの機能・制限を一覧で比���
microCMSの料金プランは4つあります(2025年6月改定後)。 個人開発では99%のケースでHobbyプラン(無料)で十分です。

| 項目 | Hobby | Team | Business | Enterprise |
|---|
| 月額料金 | ¥0 | ¥4,900〜 | ¥75,000〜 | 要見積もり |
| API数 | 5 | 10(追加 +¥2,000/個) | 30(追加可) | カスタム |
| メンバー数 | 3名 | 3名(追加 +¥1,200/人) | 20名(追加可) | カスタム |
| コンテンツ数 | 10,000件 | 20,000件 | 50,000件 | カスタム |
| データ転送量 | 20GB/月 | 200GB/月(超過 +¥20/GB) | 1TB/月(超過 +¥18/GB) | カスタム |
| APIリクエスト | 無制限 | 無制限 | 無制限 | 無制限 |
| 権限管理 | なし | なし | あり | あり |
| AIレビュー | なし | 700クレジット/月 | 7,000クレジット/月 | カスタム |
| IP制限 | なし | なし | あり | あり |
| サポート | コミュニティ | メール | テクニカルサポート | 専任担当 |
個人開発のフェーズ別おすすめプラン
ShiftBの受講生データから、開発フェーズに応じた最適なプラン選択を解説します。
| 開発フェーズ | 推奨プラン | 月額 | 判断基準 |
|---|
| 学習・プロトタイプ | Hobby | ¥0 | API 5個・コンテンツ10,000件で十分 |
| 個人ブログ・ポートフォリオ | Hobby | ¥0 | 月間20GBの転送量で数万PVまで対応 |
| 本格的な個人開発サービス | Hobby → Team | ¥0 → ¥4,900 | API 6個以上 or 転送量20GB超過時に移行 |
| チーム開発・受託案件 | Business | ¥75,000 | 権限管理・カスタムステータスが必要な場合 |
ポイントは、HobbyプランのAPIリクエストが無制限であることです。 多くの���ッドレスCMSが無料プランのAPIコール数に厳しい制限を設けている中、 microCMSはリクエスト数を気にせず開発・運用できます。 制限にかかるのはデータ転送量(月20GB)ですが、 テキスト中心のブログなら月間数万PVでも問題ありません。
ShiftBの受講生で最も多いパターンは、 「Hobbyプランで開発・リリース → API数が足りなくなったらTeamプランに移行」 という流れです。実際にTeamプランに移行した受講生は全体の15%以下で、 大半の個人開発プロジェクトはHobbyプランで完結しています。
2025年6月の料金改定で何が変わったのか
2025年6月10日に料金プランの改定が行われました。主な変更点は以下の3つです。
- Hobbyプランのapi上限が3個→5個に緩和: 個人開発での利用シーンが大幅に広がりました
- BusinessプランがV63,000→¥75,000に値上げ: エンタープライズ向けの機能拡充に伴う改定です
- Advancedプランの新規受付停止: Enterpriseプランに統合されました
個人開発者にとっては、Hobbyプランの強化が最も大きなメリットです。 従来はAPI 3個が上限だったため「ブログ + お知らせ + カテゴリ」の3つで枠を使い切ってしまいましたが、 5個に拡大されたことで「+ 著者 + タグ」のようなリレーション用APIも 無料で追加できるようになりました。
AI時代のアプリ開発コース
ShiftBのAIシフトコースは、Claude Codeで本格的なWebアプリケーションを作りながらAI駆動開発を身につけるコースです。ただ作って終わりではなく、コードを読め、セキュリティに責任を持って提案でき、要件定義などの上流工程まで担えるところまで現役エンジニアがサポートします。
AIシフトコースを見る →他のヘッドレスCMSとの徹底比較(Contentful・Strapi・Newt)
主要ヘッドレスCMS 5サービスの機能比較
ヘッドレスCMSの選択肢は多数ありますが、個人開発者が現実的に検討すべきサービスを 5つに絞って比較します。
| サービス | 開発元 | 無料プラン | 日本語対応 | 特徴 | 個人開発の推奨度 |
|---|
| microCMS | 日本 | API無制限 / 20GB転送 | 完全対応 | 日本語UI・手厚いサポート | ★★★★★ |
| Contentful | ドイツ | 10ユーザー / 10万コール | なし(英語のみ) | グローバル実績・豊富なエコシステム | ★★★☆☆ |
| Strapi | フランス | セルフホスト無料 | なし(英語のみ) | OSS・完全カスタマイズ可能 | ★★★☆☆ |
| Newt | 日本 | 100万リクエスト / 100GB | 完全対応 | 日本語対応・シンプルなUI | ★★☆☆☆(※) |
| Notion API | アメリカ | 個人利用無料 | 一部対応 | Notionをそのまま CMS化 | ★★★☆☆ |
※ Newtは2026年11月24日にサービス終了が予定されています。 新規プロジェクトでの採用は非推奨です。後継としてCraft Cross CMSが提供されていますが、 まだエコシステムが成熟していないため、安定性を重視するならmicroCMSを推奨します。
microCMS vs Contentful — 国産 vs 海外最大手
ヘッドレスCMSの世界シェアNo.1であるContentfulとの詳細比較です。
| 比較項目 | microCMS | Contentful |
|---|
| 管理画面の言語 | 日本語 | 英語のみ |
| 無料プランのAPIコール | 無制限 | 月10万回 |
| 無料プランのデータ転送 | 20GB/月 | 50GB/月 |
| SDK(JavaScript) | microcms-js-sdk | contentful.js |
| 画像API | imgix統合(高機能) | Contentful Images API |
| ドキュメント | 日本語で充実 | 英語(豊富だが読解コスト高) |
| コミュニティ | 日本国内に活発なコミュニティ | グローバルで巨大 |
| 向いている用途 | 日本語コンテンツ・国内向けサービス | 多言語サイト・グローバル展開 |
結論として、日本語コンテンツを扱う個人開発なら、microCMS一択です。 日本語UIのストレスフリーさ、APIコール無制限の太っ腹さ、 そして日本語コミュニティの充実度はContentfulでは得られないメリットです。 一方、英語圏向けのサービスやグローバル展開を視野に入れる場合は Contentfulも有力な選択肢になります。
microCMS vs Strapi — SaaS vs セルフホスト
StrapiはオープンソースのヘッドレスCMSで、自分のサーバーにホスティングできる点が特徴です。
- microCMSが向いている人: サーバー管理をしたくない、すぐに使い始めたい、日本語UIがほしい
- Strapiが向いている人: 完全にカスタマイズしたい、データを自分のサーバーに置きたい、OSSが好き
ShiftBではmicroCMSを推奨しています。理由は「個人開発で最も貴重なのは時間」だからです。 Strapiはセットアップにサーバー構築・DB設定・デプロイ環境の整備が必要で、 平均8〜16時間かかります。microCMSなら30分〜1時間で同等の環境が手に入ります。
microCMS vs Notion API — CMSとして使えるか?
最近は「NotionをCMS代わりに使う」というアプローチも人気です。 Notion APIを使えば、Notionのデータベースからコンテンツを取得できます。
ただし、Notion APIには以下の制限があります。
- レート制限: 1秒あたり3リクエストまで(microCMSは無制限)
- レスポンス速度: microCMSのCDN経由と比べてNotion APIは遅延が大きい
- 画像URL: Notionの画像URLは1時間で期限切れになるため、別途画像ホスティングが必要
- Webhook非対応: コンテンツ更新時の自動ビルドトリガーが組みにくい
ShiftBの受講生でNotion APIを試した方の約70%が、 最終的にmicroCMSに移行しています。「Notionは執筆ツールとしては最高だが、 CMSとしては制約が多い」というのが共通の感想です。

Next.js × microCMS — セットアップから記事表示まで
Step 1: microCMSのアカウント作成とAPI定義
まずmicroCMSのアカウントを作成し、コンテンツを管理するAPIを定義します。
- アカウント作成:
microcms.io にアクセスし、Googleアカウントまたはメールアドレスで登録 - サービスの作成: サービス名(例: my-blog)を入力。これがサブドメイン(
my-blog.microcms.io)になります - APIの作成: 「リスト形式」を選択し、エンドポイント名を
blogsに設定 - スキーマ定義: 以下のフィールドを追加します
| フィールドID | 表示名 | フィールド種類 | 必須 |
|---|
title | タイトル | テキストフィールド | ○ |
content | 本文 | リッチエディタ | ○ |
eyecatch | アイキャッチ画像 | 画像 | - |
category | カテゴリ | コンテンツ参照(categories API) | - |
description | 概要 | テキストフィールド | - |
Step 2: Next.jsプロジェクトの作成とSDKインストール
Next.jsプロジェクトを作成し、microCMSの公式SDKをインストールします。
# Next.jsプロジェクトを作成(App Router)
npx create-next-app@latest my-blog --typescript --tailwind --app
cd my-blog
# microCMS SDK をインストール
npm install microcms-js-sdk
次に、環境変数を設定します。プロジェクトルートに.env.localを作成してください。
# .env.local
MICROCMS_SERVICE_DOMAIN=your-service-domain
MICROCMS_API_KEY=your-api-key
注意: APIキーはNEXT_PUBLIC_プレフィックスを付けないでください。 サーバーサイドでのみ使用し、クライアントに露出させないことがセキュリティの基本です。
Step 3: microCMSクライアントの初期化
APIクライアントを初期化するファイルを作成します。
// lib/microcms.ts
import { createClient } from "microcms-js-sdk";
import type {
MicroCMSQueries,
MicroCMSImage,
MicroCMSListContent,
} from "microcms-js-sdk";
// microCMS クライアントの初期化
export const client = createClient({
serviceDomain: process.env.MICROCMS_SERVICE_DOMAIN!,
apiKey: process.env.MICROCMS_API_KEY!,
});
// ブログ記事の型定義
export type Blog = {
title: string;
content: string;
eyecatch?: MicroCMSImage;
category?: Category & MicroCMSListContent;
description?: string;
} & MicroCMSListContent;
// カテゴリの型定義
export type Category = {
name: string;
slug: string;
};
// ブログ記事一覧を取得
export async function getBlogList(queries?: MicroCMSQueries) {
const listData = await client.getList<Blog>({
endpoint: "blogs",
queries,
});
return listData;
}
// ブログ記事の詳細を取得
export async function getBlogDetail(
contentId: string,
queries?: MicroCMSQueries
) {
const detailData = await client.getListDetail<Blog>({
endpoint: "blogs",
contentId,
queries,
});
return detailData;
}
Step 4: 記事一覧ページの実装
App Routerで記事一覧ページを実装します。Server Componentとして 直接microCMSのAPIを呼び出せるのがNext.js App Routerの大きなメリットです。
// app/blog/page.tsx
import Link from "next/link";
import Image from "next/image";
import { getBlogList } from "@/lib/microcms";
export const revalidate = 60; // ISR: 60秒ごとに再検証
export default async function BlogPage() {
const { contents } = await getBlogList({
limit: 10,
orders: "-publishedAt",
});
return (
<main className="mx-auto max-w-3xl px-4 py-10">
<h1 className="mb-8 text-3xl font-bold">ブログ</h1>
<ul className="flex flex-col gap-6">
{contents.map((blog) => (
<li key={blog.id}>
<Link
href={`/blog/${blog.id}`}
className="flex gap-4 rounded-lg border p-4 transition hover:bg-gray-50"
>
{blog.eyecatch && (
<Image
src={blog.eyecatch.url}
alt={blog.title}
width={160}
height={90}
className="rounded object-cover"
/>
)}
<div>
<h2 className="text-lg font-semibold">{blog.title}</h2>
{blog.description && (
<p className="mt-1 text-sm text-gray-600">
{blog.description}
</p>
)}
</div>
</Link>
</li>
))}
</ul>
</main>
);
}
Step 5: 記事詳細ページの実装
動的ルーティングを使って、記事詳細ページを実装します。
// app/blog/[id]/page.tsx
import { getBlogDetail, getBlogList } from "@/lib/microcms";
import { notFound } from "next/navigation";
// 静的パスの生成(SSG)
export async function generateStaticParams() {
const { contents } = await getBlogList({ fields: "id", limit: 100 });
return contents.map((blog) => ({ id: blog.id }));
}
export const revalidate = 60;
type Props = {
params: Promise<{ id: string }>;
};
export default async function BlogDetailPage({ params }: Props) {
const { id } = await params;
const blog = await getBlogDetail(id).catch(() => null);
if (!blog) {
notFound();
}
return (
<main className="mx-auto max-w-3xl px-4 py-10">
<h1 className="mb-4 text-3xl font-bold">{blog.title}</h1>
<time className="text-sm text-gray-500">
{new Date(blog.publishedAt).toLocaleDateString("ja-JP")}
</time>
<div
className="prose mt-8"
dangerouslySetInnerHTML={{ __html: blog.content }}
/>
</main>
);
}
これで、microCMSの管理画面で記事を投稿すれば、Next.jsのサイトに自動で表示されます。revalidate = 60の設定により、最大60秒の遅延でコンテンツが更新されます(ISR)。
Step 6: Vercelへのデプロイと環境変数設定
最後にVercelにデプロイし、環境変数を設定します。
# Vercel CLIでデプロイ
npm i -g vercel
vercel
# または GitHubリポジトリをVercelに接続して自動デプロイ
Vercelのダッシュボードで以下の環境変数を設定してください。
MICROCMS_SERVICE_DOMAIN: microCMSのサービスドメインMICROCMS_API_KEY: microCMSのAPIキー
ShiftBの受講生データでは、このStep 1〜6の全工程を完了するまでの平均所要時間は約2〜3時間です。WordPressのサーバー構築 + テーマカスタマイズに 平均15時間以上かかっていたことを考えると、圧倒的な時短です。
コンテンツモデル設計のベストプラクティス
API設計の基本原則 — リスト形式 vs オブジェクト形式
microCMSのAPIには2つの形式があります。 用途に応じて正しく使い分けることが、コンテンツモデル設計の第一歩です。
| 形式 | 用途 | 具体例 | レスポンス構造 |
|---|
| リスト形式 | 複数コンテンツの管理 | ブログ記事、お知らせ、商品 | { contents: [...], totalCount, offset, limit } |
| オブジェクト形式 | 単一コンテンツの管理 | サイト設定、About、プロフィール | { fieldA, fieldB, ... } |
よくある間違いは、「サイト全体の設定情報」や「会社概要ページ」を リスト形式で作ってしまうことです。1件しか存在しないコンテンツはオブジェクト形式を使いましょう。
良いスキーマ設計 vs 悪いスキーマ設計
ブログサイトを例に、良い設計と悪い設計を比較します。
悪い例: すべてを1つのAPIに詰め込む
// ❌ 悪い設計: blogsのAPIにすべてを詰め込む
// フィールド定義
{
title: "テキストフィールド",
content: "リッチエディタ",
categoryName: "テキストフィールド", // ← カテゴリ名を直接入力
authorName: "テキストフィールド", // ← 著者名を直接入力
authorImage: "画像", // ← 著者画像を直接入力
tag1: "テキストフィールド", // ← タグ1
tag2: "テキストフィールド", // ← タグ2
tag3: "テキストフィールド", // ← タグ3
}
// 問題点:
// - カテゴリ名の表記ゆれが発生する("React" vs "react" vs "React.js")
// - 著者情報が記事ごとに重複する
// - タグの上限が3個に固定されてしまう
// - カテゴリ一覧ページが作れない
良い例: APIを適切に分離し、コンテンツ参照を使う
// ✅ 良い設計: APIを分離してコンテンツ参照で関連付ける
// API: blogs(リスト形式)
{
title: "テキストフィールド", // 記事タイトル
content: "リッチエディタ", // 本文
eyecatch: "画像", // アイキャッチ画像
category: "コンテンツ参照(categories)", // カテゴリへの参照
author: "コンテンツ参照(authors)", // 著者への参照
tags: "複数コンテンツ参照(tags)", // タグへの参照(複数選択可)
description: "テキストフィールド", // SEO用の概要
}
// API: categories(リスト形式)
{
name: "テキストフィールド", // カテゴリ名
slug: "テキストフィールド", // URLスラッグ
}
// API: authors(リスト形式)
{
name: "テキストフィールド", // 著者名
image: "画像", // プロフィール画像
bio: "テキストエリア", // 自己紹介
}
// API: tags(リスト形式)
{
name: "テキストフィールド", // タグ名
slug: "テキストフィールド", // URLスラッグ
}
// API: siteSettings(オブジェクト形式)← 単一データはオブジェクト形式
{
siteName: "テキストフィールド", // サイト名
description: "テキストエリア", // サイト説明
ogImage: "画像", // デフォルトOGP画像
}
この設計なら、HobbyプランのAPI 5個の枠内に収まります(blogs, categories, authors, tags, siteSettings)。 コンテンツ参照を使うことで、カテゴリ名の表記ゆれを防ぎ、 著者情報の重複もなくなり、タグも自由に追加できます。
コンテンツ参照(リレーション)の活用パターン
microCMSのコンテンツ参照は、RDBの外部キーに相当する機能です。 API間の関連性を定義することで、構造化されたデータモデルを実現できます。
- 1対1参照: 記事 → カテゴリ(「コンテンツ参照」フィールド)
- 1対多参照: 記事 → タグ(「複数コンテンツ参照」フィールド)
- セルフリファレンス: 記事 → 関連記事(同じAPIへの複数コンテンツ参照)
取得時にはdepthパラメータで参照先のデータを展開できます。
// 参照先のデータを2階層まで展開して取得
const blog = await client.getListDetail<Blog>({
endpoint: "blogs",
contentId: "article-id",
queries: { depth: 2 },
});
// blog.category.name → "React" (参照先のカテゴリ名が取得できる)
// blog.tags[0].name → "Next.js" (参照先のタグ名が取得できる)
// blog.author.name → "ぶべ" (参照先の著者名が取得できる)
注意: depthのデフォルトは1です。 参照の参照(例: 記事 → 著者 → 所属組織)を取得するにはdepth: 2以上を 指定する必要があります。ただし、depthを大きくするとレスポンスサイズが増えるため、 必要最小限に留めましょう。
繰り返しフィールドとカスタムフィールドの使い分け
microCMSには「繰り返しフィールド」という強力な機能があります。 これは、複数のフィールドをグループ化して繰り返し入力できる仕組みです。
例えば、「料金表」のようなデータ構造を表現する場合に便利です。
// 繰り返しフィールドの活用例: 料金表
// API: pricingPage(オブジェクト形式)
{
title: "テキストフィールド",
plans: "繰り返しフィールド" → [
{
planName: "テキストフィールド", // プラン名
price: "数値", // 月額料金
features: "リッチエディタ", // 機能説明
isRecommended: "真偽値", // おすすめフラグ
}
]
}
ShiftBでの実践Tips: 繰り返しフィールドは便利ですが、5階層以上のネストは避けることを推奨します。 データ構造が複雑になりすぎると、フロントエンドでの型定義やレンダリングが煩雑になります。
AI時代のアプリ開発コース
ShiftBのAIシフトコースは、Claude Codeで本格的なWebアプリケーションを作りながらAI駆動開発を身につけるコースです。ただ作って終わりではなく、コードを読め、セキュリティに責任を持って提案でき、要件定義などの上流工程まで担えるところまで現役エンジニアがサポートします。
AIシフトコースを見る →画像管理・Webhook・プレビュー機能の活用テクニック
画像API(imgix連携)で画像を最適化する
microCMSにアップロードした画像は、裏側でimgixのCDNを通じて配信されます。 URLにパラメータを追加するだけで、リアルタイムに画像処理が可能です。
// microCMSから取得した画像URLの例
const originalUrl = "https://images.microcms-assets.io/assets/xxx/yyy/image.jpg";
// リサイズ(幅800px、高さ自動)
const resized = `${originalUrl}?w=800`;
// WebP変換(軽量化)
const webp = `${originalUrl}?fm=webp&q=80`;
// リサイズ + WebP + 品質指定(最も推奨される形式)
const optimized = `${originalUrl}?w=800&fm=webp&q=80`;
// OGP画像用(1200x630にクロップ)
const ogp = `${originalUrl}?w=1200&h=630&fit=crop`;
// サムネイル(正方形にクロップ)
const thumbnail = `${originalUrl}?w=200&h=200&fit=crop`;
Next.jsのImageコンポーネントと組み合わせる場合は、next.config.jsに画像ドメインを追加する必要があります。
// next.config.ts
import type { NextConfig } from "next";
const nextConfig: NextConfig = {
images: {
remotePatterns: [
{
protocol: "https",
hostname: "images.microcms-assets.io",
},
],
},
};
export default nextConfig;
imgixのパラメータは100種類以上あり、顔検出によるスマートクロップ、 ぼかし、テキストオーバーレイなども可能です。 個人開発で特に使う頻度が高いのはw(幅)、fm(フォーマット)、q(品質)、fit(フィット方法)の4つです。
Webhook連携で自動デプロイを実現する
microCMSのWebhook機能を使えば、コンテンツの公開・更新・削除時に 外部サービスへHTTPリクエストを自動送信できます。 最も一般的な用途はVercelの自動デプロイトリガーです。
設定手順は以下のとおりです。
- Vercel側: Settings → Git → Deploy Hooks で新しいHookを作成し、URLをコピー
- microCMS側: API設定 → Webhook → 「カスタム通知」を追加
- WebhookのURLにVercelのDeploy Hook URLを貼り付け
- トリガーを「コンテンツの公開・更新時」に設定
これで、microCMSの管理画面で記事を公開するたびに、 Vercelが自動でサイトを再ビルドします。SSG構成の場合、 ビルド完了まで平均30秒〜2分で本番サイトに反映されます。
また、2024年にリリースされたWebhook署名検証機能により、 WebhookのリクエストがmicroCMSから送信されたものであることを暗号的に検証できるようになりました。 セキュリティを重視する場合は、署名検証の実装を推奨します。
// Webhook署名の検証例(Next.js API Route)
import crypto from "crypto";
import { NextRequest, NextResponse } from "next/server";
export async function POST(request: NextRequest) {
const body = await request.text();
const signature = request.headers.get("x-microcms-signature");
const secret = process.env.MICROCMS_WEBHOOK_SECRET!;
// 署名の検証
const expectedSignature = crypto
.createHmac("sha256", secret)
.update(body)
.digest("hex");
if (signature !== expectedSignature) {
return NextResponse.json({ error: "Invalid signature" }, { status: 401 });
}
// 署名が正しい場合の処理
const payload = JSON.parse(body);
console.log("Webhook received:", payload);
// キャッシュ再検証やSlack通知などの処理
return NextResponse.json({ ok: true });
}
画面プレビュー機能で下書きを確認する
画面プレビューは、下書き状態のコンテンツをフロントエンド上で 公開前に確認できる機能です。編集者がmicroCMSの管理画面から 「プレビュー」ボタンをクリックすると、指定したURLに遷移します。
プレビューの実装方法は2つあります。
| 方式 | 仕���み | メリット | デメリット |
|---|
| Draft Mode(推奨) | Next.jsのDraft Mode APIを使用 | 本番環境と同じ表示で確認可能 | 実装がやや複雑 |
| クライアントサイド取得 | ブラウザから直接APIを叩く | 実装が簡単 | APIキーがクライアントに露出するリスク |
セキュリティの観点からDraft Mode方式を推奨します。 以下はNext.js App RouterでのDraft Mode実装例です。
// 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 contentId = searchParams.get("contentId");
const draftKey = searchParams.get("draftKey");
const secret = searchParams.get("secret");
// セキュリティ: シークレットキーの検証
if (secret !== process.env.DRAFT_SECRET) {
return new Response("Invalid secret", { status: 401 });
}
if (!contentId) {
return new Response("Missing contentId", { status: 400 });
}
// Draft Modeを有効にする
const draft = await draftMode();
draft.enable();
// 記事詳細ページにリダイレクト(draftKeyをクエリパラメータで渡す)
redirect(`/blog/${contentId}?draftKey=${draftKey}`);
}
microCMS側のプレビュー設定では、URLにhttps://your-site.com/api/draft?secret=YOUR_SECRET&contentId={CONTENT_ID}&draftKey={DRAFT_KEY}を設定します。{CONTENT_ID}と{DRAFT_KEY}はmicroCMSが自動で置換してくれます。
ISR(増分静的再生成)でパフォーマンスと鮮度を両立する
SSG(完全静的生成)ではビルド時にしかページが更新されませんが、 ISR(Incremental Static Regeneration)を使えば、指定した間隔でバックグラウンドでページを再生成できます。
// ISRの設定(App Router)
// revalidateの値(秒)に応じてページが再生成される
// 60秒ごとに再検証(コンテンツ更新が頻繁な場合)
export const revalidate = 60;
// 1時間ごとに再検証(ブログなど更新頻度が低い場合)
export const revalidate = 3600;
// On-Demand ISR: Webhookで即時再生成する場合
// app/api/revalidate/route.ts
import { revalidatePath } from "next/cache";
import { NextRequest, NextResponse } from "next/server";
export async function POST(request: NextRequest) {
const body = await request.json();
// microCMSのWebhookから送られるcontentIdを取得
const { id } = body;
// 特定の記事ページだけを再生成
revalidatePath(`/blog/${id}`);
// 一覧ページも再生成
revalidatePath("/blog");
return NextResponse.json({ revalidated: true });
}
On-Demand ISR(Webhookトリガーで即時再生成)が最も推奨されるパターンです。 microCMSのWebhookで上記のAPIルートを叩けば、 コンテンツ更新から数秒以内にサイトが最新状態になります。
個人開発でのmicroCMS活用事例と実装パターン
パターン1: 個人ブログ(最も基本的な構成)
技術スタック: Next.js App Router + microCMS + Vercel + Tailwind CSS
最もシンプルで最も多い活用パターンです。ShiftBの受講生の約40%が このパターンで個人ブログを運営しています。
- API構成: blogs(リスト)、categories(リスト)、siteSettings(オブジェクト)→ API 3個
- 所要時間: 約8〜12時間(デザイン含む)
- 月額コスト: ¥0(Hobbyプラン + Vercel無料枠)
- ポイント: ISR(60秒)を設定し、記事更新時にWebhookでビルド
パターン2: ポートフォリオサイト
技術スタック: Next.js App Router + microCMS + Vercel + Framer Motion
転職活動やフリーランスの営業で必須のポートフォリオサイト。 実績(Works)をmicroCMSで管理し、デザインはコードで自由に表現します。
- API構成: works(リスト)、skills(リスト)、profile(オブジェクト)→ API 3個
- 所要時間: 約10〜16時間
- 月額コスト: ¥0
- ポイント: worksにサムネイル画像・使用技術(タグ参照)・URL・期間を持たせる
パターン3: ドキュメントサイト / ヘルプセンター
技術スタック: Next.js App Router + microCMS + Vercel
個人開発でSaaSを運営する場合、ヘルプページやドキュメントの管理にmicroCMSが活躍します。
- API構成: docs(リスト)、docCategories(リスト)、faq(リスト)、settings(オブジェクト)→ API 4個
- 所要時間: 約12〜20時間
- 月額コスト: ¥0
- ポイント: docsに「順序」(数値フィールド)を持たせてサイドバーの並び順を制御
パターン4: コーポレートサイト + ニュース更新
技術スタック: Next.js App Router + microCMS + Vercel
フリーランスや小規模法人のコーポレートサイトで、 「お知らせ」「実績」「メンバー紹介」など更新頻度の高いセクションだけをmicroCMSで管理するパターンです。
- API構成: news(リスト)、members(リスト)、companyInfo(オブジェクト)→ API 3個
- 所要時間: 約15〜25時間
- 月額コスト: ¥0(小規模なら十分)
- ポイント: 固定ページ(サービス紹介など)はコードで直接実装し、動的に変わる部分だけCMS化
パターン5: ECサイトの商品管理
技術スタック: Next.js App Router + microCMS + Stripe + Vercel
microCMSで商品情報を管理し、Stripeで決済処理を行う構成です。 少数の商品(100商品以下)を扱う個人開発ECに最適です。
- API構成: products(リスト)、productCategories(リスト)、shopSettings(オブジェクト)→ API 3個
- 所要時間: 約20〜30時間(Stripe連携含む)
- 月額コスト: ¥0(microCMS) + Stripe決済手数料3.6%
- ポイント: productsに
stripePriceIdフィールドを持たせてStripeと紐づけ
ShiftB校長 ぶべのアドバイス: 「個人開発ではHobbyプランのAPI 5個で収まるように設計するのが鉄則です。 API数を超えそうな場合は、まず『このAPIは本当に分ける必要があるか?』を見直しましょう。 例えば、タグが10個程度なら別APIにせずブログ記事のセレクトフィールドで管理するのも手です。 無料プランの範囲でリリースし、収益が出てから有料プランに移行する。 これが個人開発で最も成功率の高いパターンです。」
よくある質問(FAQ)
Q1. プログラミング初心者でもmicroCMSは使えますか?
microCMSの管理画面自体は、プログラミング知識がなくても直感的に操作できます。 コンテンツの作成・編集・公開はWordPress並みに簡単です。 ただし、フロントエンド(表示部分)は自分で実装する必要があるため、 HTML/CSS/JavaScriptの基礎知識は必要です。 ShiftBでは、React / Next.jsの基礎を2〜3週間で学んでからmicroCMSに入ることを推奨しています。 逆に言えば、Next.jsの基礎さえ理解していれば、microCMSの学習コストは非常に低いです。
Q2. microCMSのHobbyプラン(無料)でどこまでできますか?
Hobbyプランでは、API 5個、コンテンツ10,000件、メンバー3名、データ転送量20GB/月、APIリクエスト無制限で利用できます。個人ブログ・ポートフォリオ・小規模なWebサービスなら十分すぎるスペックです。 ShiftBの受講生でHobbyプランからTeamプランに移行した方は全体の15%以下で、 大半の個人開発プロジェクトは無料プランで完結しています。 データ転送量20GBは、テキスト中心のサイトなら月間数万PVをカバーできます。
Q3. microCMSのデータはエクスポートできますか?ロックインのリスクは?
microCMSのコンテンツはすべてREST API経由でJSON形式で取得できるため、 エクスポートは容易です。管理画面からCSVエクスポートも可能です。 万が一microCMSから別のサービスに移行する場合も、 APIでデータを取得してスクリプトで変換するだけで対応できます。 ベンダーロックインのリスクは、WordPressのプラグイン依存や Firebaseのデータ構造依存と比べてはるかに低いと言えます。
Q4. WordPressからmicroCMSに移行するにはどうすればいいですか?
WordPressからの移行は以下の手順で行えます。
- WordPress REST APIでコンテンツを取得(または WP管理画面からCSVエクスポート)
- microCMSのAPIスキーマを設計(WordPress のカスタムフィールドに対応するフィールドを作成)
- microCMS Management APIでコンテンツを一括登録(スクリプトで自動化推奨)
- Next.jsでフロントエンドを実装
- ドメインの向き先を変更
ShiftBの受講生で最も多い移行パターンは、WordPress記事50〜100本規模の移行で、 所要時間は平均2〜3日です。1,000記事以上の大規模移行の場合は、 Management APIを活用したスクリプトの作成が必須になります。
Q5. microCMSとAIコーディング(バイブコーディング)の相性はどうですか?
非常に良いです。microCMSはREST APIというWeb開発の標準的なインターフェースを 採用しているため、Claude CodeやCursorなどのAIツールが正確にコードを生成できます。 特にmicrocms-js-sdkはTypeScriptの型定義が充実しているため、 AIが型安全なコードを高精度で出力してくれます。 ShiftBの受講生でも、「microCMSのAPI定義だけ自分で設計し、 Next.jsとの連携コードはAIに生成させる」というワークフローで 開発時間を50%以上短縮している事例が多数あります。
Q6. microCMSは多言語サイトに対応していますか?
microCMS自体には多言語管理の専用機能はありませんが、 工夫次第で多言語対応は可能です。一般的なアプローチは以下の2つです。
- 方法1: 言語ごとにAPIを分ける(blogs-ja, blogs-en)
- 方法2: 1つのAPIにja/enのフィールドを並列で持たせる(title_ja, title_en)
ただし、本格的な多言語サイト(10言語以上、翻訳ワークフロー管理が必要)の場合は、 Contentfulのようなネイティブ多言語サポートを持つCMSの方が適しています。 個人開発レベルの日英2言語程度であれば、microCMSで十分対応可能です。
Q7. microCMSの画像はどこにホスティングされますか?容量制限は?
microCMSにアップロードした画像はimgixのCDNでホスティングされます。 グローバルに分散配置されたCDNから配信されるため、表示速度は非常に高速です。 画像の容量制限はプランによらず1ファイルあたり5MBまでです。 ファイルの総容量に明示的な制限はありませんが、 データ転送量(Hobbyプラン: 20GB/月)の枠内に収まるよう、 WebP変換やリサイズで画像を最適化することを推奨します。
まとめ — microCMSで個人開発のコンテンツ管理を最適化しよう
この記事では、microCMSの基礎から実践的なNext.jsとの連携まで、 個人開発で必要な知識を網羅的に解説しました。最後に要点をまとめます。
- microCMSは日本製のヘッドレスCMS。管理画面・ドキュメント・サポートが完全日本語対応で、導入企業14,000社超の実績
- Hobbyプラン(無料)で十分始められる。API 5個、コンテンツ10,000件、APIコール無制限は個人開発に十分すぎる
- Next.js App Routerとの連携が抜群。公式SDKとチュートリアルで、最短2〜3時間でブログサイトが完成する
- コンテンツモデル設計が重要。APIを適切に分離し、コンテンツ参照でリレーションを表現するのがベストプラクティス
- 画像APIで自動最適化。imgix連携により、URLパラメータだけでリサイズ・WebP変換が可能
- Webhook + ISRで即時更新。コンテンツ更新から数秒でサイトに反映される仕組みが簡単に構築できる
- AIコーディングとの相性も抜群。TypeScript型定義が充実しており、Claude CodeやCursorで効率的に開発できる
ShiftBでは、microCMSを使った個人開発を企画からリリースまで一気通貫でサポートしています。 「microCMSでブログやサービスを作ってみたいけど、何から始めればいいか分からない」という方は、 ぜひ無料相談会にお越しください。あなたのアイデアに合わせた技術スタックと開発プランを一緒に考えます。