microCMS は、管理画面が日本語で作られた国産のヘッドレス CMS だ。コンテンツの編集機能と配信 API を分離し、Next.js や Nuxt といったフレームワークで作ったフロントエンドへ、API 経由でコンテンツを供給する。
日本語チームでの使いやすさ
ヘッドレス CMS は海外製が多く、管理画面が英語のためライターや編集担当に使ってもらいにくい——という現場の悩みがある。microCMS はこの摩擦を解消する。非エンジニアのメンバーが迷わず記事を更新でき、エンジニアは API でそれを取得する、という分業が自然に成り立つ。日本語のドキュメントやサポートが揃っている点も、導入の障壁を下げている。
機能の組み立て
- コンテンツ API: リスト形式・オブジェクト形式の両方に対応し、ブログ記事から単一のサイト設定まで扱える
- 画像 API: アップロードした画像を URL パラメータでリサイズ・変換でき、別途画像最適化サービスを挟まずに済む
- Webhook: コンテンツ更新時にビルドを自動トリガーでき、JAMstack の再生成フローと噛み合う
料金とスケールの注意
無料枠は API 数やコンテンツ数に制限があり、小規模サイトなら収まる。有料は月額制で、API 数や転送量に応じて段階的に上がる。プラン境界を意識せず API を増やすと、思ったより早く上位プランが必要になる点は計画段階で見ておきたい。
スキーマ変更の取り回し
運用に入ってから効いてくるのが、API スキーマ（フィールド定義）の柔軟さだ。microCMS はフィールドの追加が手軽な反面、すでに多数のコンテンツが入った API で必須フィールドを増やすと、過去コンテンツの埋め直しが要る。立ち上げ時に「繰り返しフィールド」や「カスタムフィールド」をどこに使うかを設計しておくと、後の手戻りが減る。プレビュー機能を使えば下書き状態を本番フロントで確認できるので、編集フローと一緒に最初に組み込んでおきたい。
多言語サイトでの限界
多言語サイトをロケールごとに一元管理したい場合、microCMS は標準のロケール管理が手厚いとは言いにくく、Contentful のような多言語前提の CMS のほうが素直なことが多い。国内向けの日本語サイトに用途を絞れば、選定で迷う要素は少ない。
API スキーマを先に固める運用になる
microCMS はコンテンツの型を管理画面で定義し、その定義に沿って API のレスポンス構造が決まる。フィールドを増やす分には影響が小さいが、型の変更や削除は既存コンテンツとフロント側の実装に波及する。立ち上げ時にスキーマを雑に決めると、運用開始後の変更コストとして返ってくる。とくに繰り返し要素をどう表現するか（繰り返しフィールドか、参照する別 API か）は、後から変えにくい判断になる。
ブラウザから直接 microCMS を呼ぶ実装では、キーが利用者から見える状態になります。読み取り専用のキーであっても、下書きや非公開コンテンツへのアクセス範囲を持つキーが露出すると問題になります。サーバー側で取得して配信する（SSR や静的生成）構成にするのが安全です。
静的生成との組み合わせが本領
コンテンツ更新のたびにサイトを再生成する構成（Next.js や Astro などとの組み合わせ）と噛み合わせると、表示速度と運用の手軽さを両立できる。Webhook で更新を検知してビルドを走らせる流れが標準的だ。逆に、更新が極端に頻繁なメディアや、ユーザーごとに出し分けが必要なコンテンツでは、静的生成の前提が崩れるため構成の見直しが要る。