microCMSでできること・できないこと｜CMS選びの判断基準

microCMSはヘッドレスCMSと呼ばれるジャンルのサービスです。ヘッドレスというのは管理画面とデータを届けるAPIだけを提供し、実際の見た目（フロントエンド）は自分たちで作るという分業のことを指します。表示側をNext.jsのようなモダンな技術で組めるので、表示速度や体験を自分でコントロールできるのが特徴です。

その上でmicroCMSが本当に強い領域は「コンテンツの配信」です。

まず、管理画面を自作しなくて済みます。お知らせやブログを更新するための入稿画面は普通に作ろうとすると意外と手間がかかります。microCMSはそこが最初から用意されていて、しかも日本語で直感的に触れます。

配信まわりも充実しています。高速なコンテンツAPI、画像をリサイズ・変換して返す画像API、公開前に表示を確認できるプレビュー、公開日時を指定する予約投稿、誰がいつ何を直したかを追える更新履歴、公開前のレビュー機能。最近ではMCPサーバー経由でAIから直接入稿したり、AIに文章をレビューさせたりする機能も加わっています。

価格も入りやすい。有料の入り口であるTeamプランは月4,900円から使えて、API10個・コンテンツ2万件まで扱えます。お知らせ、ブログ、実績紹介、スタッフ紹介、商品カタログのような「見せるコンテンツ」を運用するならこれで十分に足ります。

ここまでの用途であれば、microCMSは文句なしに第一候補です。むしろ、自前でCMSを組むのは時間の無駄になりかねません。

向いている方

ここまでを踏まえると、microCMSが力を発揮する相手ははっきりしています。

サイトで主に更新するのが、お知らせ、ブログ、実績紹介、商品カタログといった「見せるコンテンツ」である会社。表示はNext.jsのようなモダンな技術で速くきれいに作りたいけれど、そのための管理画面をゼロから用意する手間はかけたくない。こうした中小・中堅の企業にmicroCMSはよく噛み合います。

編集するのは少人数で、扱うコンテンツは多くても数千件から二万件ほど。言語は日本語ひとつ、あるいはお知らせだけを英語でも出す、といったライトな多言語まで。この範囲であれば、月4,900円から始められるコストも含めて選ばない理由を探すほうが難しいくらいです。

制作を外部に任せる場合の相性もいいところです。日本語のサポートがあり、管理画面が直感的なので納品後にお客様自身が無理なく運用を引き継げます。「作って終わり」にならないCMSとして堅実な選択肢になります。

この規模を超えると、他のCMSが視野に入る

一方で、同じ「見せるコンテンツ」であっても規模や要件が一定を超えると、microCMS以外のほうが素直な場面が出てきます。

ここで先に断っておきたいのは、これはまだ「見せる用途のなかの話」だということです。データを溜めたり掛け合わせたりする要求が出てきたらそれはCMSの比較ではなく、後述する「データ基盤」の話に変わります。あくまで見せることに絞ったうえで規模の観点だけを整理します。

本格的な多言語・多拠点でグローバルに展開するならContentfulのような海外の大手が有力です。複数言語・複数チャネルへの配信を前提に設計されていて、この領域の実績も豊富です。ただし有料プランは月300ドルほどからと価格帯が一段上がり、アクセスが増えれば従量課金も膨らみます。規模に見合った体制があってこそ活きるツールです。

大企業のガバナンスが要件になる場合、役割ごとの権限、監査ログ、SLA、シングルサインオンなどを厳格に求められるケースでは、国産でエンタープライズ寄りのKurocoや、海外のContentstackといった選択肢が候補になります。microCMSもBusinessプランで権限管理などに対応しますが、より重い統制が前提ならはじめからそこに寄せて作られた製品のほうが収まりがよくなります。

開発者が主導して自由にカスタムしたい、あるいはオープンソースを自社で運用してベンダーに縛られたくない、という方針であれば、SanityやStrapiが向いています。すでにWordPressが動いていて、それを活かしながら段階的に移していきたい場合はWordPressをヘッドレス化する構成も現実的な着地です。

最後に、規模とは別の観点をひとつ添えておきます。SaaS型のCMSには、サービスそのものが終了するリスクがあります。実際、国産で知られたNewtは2026年11月にサービス提供を終える予定です。長く使うものだからこそ、機能や価格だけでなくそのCMSが続いていくのか、ベンダーの継続性も選定の軸に入れておくと安心です。

線を引くのはここからです。microCMSには、構造上どうしても苦手な領域が2つあります。ひとことで言えば、データの「関係」と「蓄積」です。

関係があるデータ

microCMSでもコンテンツ同士を参照でつなぐことはできます。ただ、リレーショナルデータベースのような自由な掛け合わせ、複数のテーブルをまたいだ結合や条件を組んだ集計、複雑な検索はできません。

たとえば「この顧客が過去に問い合わせた案件を、担当者別・月別に集計したい」といった要求はmicroCMSの範囲外です。microCMSはコンテンツを届けるための構造であって、データを掛け合わせて分析するための構造ではないからです。ここは得意不得意というより、そもそも目的が違うと理解するのが正確です。

保存するデータ

ここは誤解されやすいところなので正確に書きます。microCMSにも書き込みのためのAPI（マネジメントAPI）はあります。だから「書き込めない」というのは間違いです。

問題は、その書き込みが「編集者がコンテンツを入稿する」ための書き込みだということです。エンドユーザーが大量に送ってくるフォームデータ、会員登録、予約、在庫の増減といった「業務トランザクション」を正面から受け止める設計ではありません。

数字にも上限があります。コンテンツ数はTeamプランで2万件まで。データ転送量にも上限があり超えると従量課金になるか無料枠では配信が止まります。ユーザーやアクセスが増えるほど、コンテンツ用のデータベースに業務データを溜めていく使い方は上限とコストの両方に当たっていきます。

権限と、業務利用のコスト

もうひとつ現実的な話として、役割ごとに細かくアクセスを分ける権限管理、IP制限、本番と検証を分ける複数環境といった機能は、Businessプラン（月75,000円）からになります。

お知らせを更新するだけなら安価に始められる一方で、「社内の業務システムとして、部署ごとに権限を分けて使う」段階に入ると価格帯が一段変わります。この落差自体がmicroCMSがどこまでを想定して作られているかを物語っています。

線引きの基準 ― 「保存する？」「関係がある？」

ここまでを踏まえると選定の判断はとてもシンプルにできます。扱おうとしているデータについて2つだけ問えばいい。

ひとつ、そのデータは「保存・蓄積」されるものか。ユーザーが送ってくる、時間とともに増えていく、業務のなかで書き換わっていく、そういう性質があるか。

ふたつ、そのデータは他と「関係」を持つか。顧客と案件、注文と在庫のように掛け合わせて意味が出るものか。

どちらもノーなら、それは「ただ見せるだけのコンテンツ」です。microCMSが最適です。

どちらかがイエスなら、話はコンテンツCMSの枠を超えます。そこで必要になるのは、データベース——つまり基盤です。PostgreSQLをベースにしたSupabaseのようなデータ基盤が力を発揮するのはこの領域です。

「CMSかデータベースか」で迷うのではなく、「見せるだけか、動かすか」で切る。この一本の線が引ければ、選定の9割は終わります。

その先にある「データ基盤」

CMSを「コンテンツを管理するツール」として見るかぎりmicroCMSは優秀な選択肢です。ここは何度でも繰り返しておきたいところです。

ただ、会社のサイトは時間が経つと、「見せる」だけでは終わらなくなります。問い合わせを溜めて活用したい、会員を管理したい、予約を受けたい、社内で数字を見たい。「関係」と「蓄積」の要求はたいてい後からやってきます。

そのとき、見せるために作られたコンテンツCMSに無理をさせるより、はじめから「保存」と「関係」を前提にしたデータ基盤の上に立って、見せる部分にだけ必要ならCMSを組み合わせる、そのほうが素直で長く使えます。

そして何より大事なのは、案件ごとに正しく線を引くことです。見せるだけの案件にデータ基盤を持ち込むのは過剰ですし、動かす案件にコンテンツCMSを当てるのは窮屈です。microCMSが最適な案件は、迷わずmicroCMSで組む。それが一番いい設計です。

CMS選びは、「どれが優れているか」ではなく「この案件で何を扱うか」から始まります。microCMSにできること・できないことがわかれば、その問いには、もう自分で答えられるはずです。