ヘッドレスCMS比較 2026年版：中小企業のコーポレートサイトに本当に合う選択肢

まず、正直に言うと、自分もつい最近まで「コーポレートサイトにもヘッドレスCMSを採用すべきだ」と思っていた一人だった。

Astroで静的サイトを作る案件が増えてきた頃、「コンテンツ管理はどうしますか？」という話が毎回出る。MDXをGit管理する方法もあるけど、「非エンジニアが更新するんですよ」という話になると、すぐにヘッドレスCMSの名前が出てくる。microCMSとかContentfulとかSanityとか。

半年前に、とある中小企業のコーポレートサイトをAstroで構築するとき、自分もContentfulを採用した。「海外の大手だし安定してるだろう」という判断だった。

結果から言うと、3ヶ月後にそのクライアントから「CMSの管理画面、誰も触れてないんです」という連絡が来た。

「入れたけど使われなかった」理由

Contentfulの管理画面は、エンジニアにとっては分かりやすい。コンテンツモデルを定義して、フィールドを設定して、エントリを作って——というフローが整理されている。

でも、非エンジニアの担当者（総務兼任のWeb担当者）にとっては、最初の画面から「これは何をするところ？」という感じだったらしい。ドキュメントは英語か機械翻訳。サポートも英語が基本。

WordPressに戻せ、とまでは言われなかったけど、「更新が必要なときだけ業者に頼む」運用になった。これは完全に自分の選定ミスだったと思っている。

その後、何件かのサイトを経験して、ヘッドレスCMS選定の判断基準をだいぶ更新した。今回はその整理を書いておこうと思う。

国産 vs 海外ヘッドレスCMS：料金と運用前提の比較

2026年時点での主要サービスを並べると、こんな感じになる。

「料金だけ見るとmicroCMSが安い」という話になりがちだけど、ここで注意が必要で、ContentfulのFreeプランはAPIコール数やコンテンツ量に上限があるし、SanityのGrowthプランはプロジェクト単位の課金になっている。コーポレートサイト1本なら月額費用よりも「誰が使うか」の方が重要な判断軸だったりする。

Git管理（MDX）との境界線

自分がよく迷うのが「ヘッドレスCMSを入れるか、MDXのまま行くか」という選択だ。

結論から言うと、更新者がエンジニアかどうかで分岐するのが実態に近い。

// microCMSの場合、APIクライアントの設定はこんな感じ
import { createClient } from 'microcms-js-sdk';

const client = createClient({
  serviceDomain: 'your-service', // xxxx.microcms.io の xxxx 部分
  apiKey: import.meta.env.MICROCMS_API_KEY,
});

export const getNewsList = async () => {
  const data = await client.getList({
    endpoint: 'news',
    queries: { orders: '-publishedAt', limit: 10 },
  });
  return data.contents;
};

これに対して、MDX管理の場合はファイルシステムが「CMS」になる。

// Astro + MDX の場合
// 改善の余地あり：Zodスキーマを変更した際に既存MDXファイルへの影響範囲が広く、
// 漏れなく更新できているかビルドログを丁寧に確認する必要がある
import { getCollection } from 'astro:content';

export async function getNewsEntries() {
  const entries = await getCollection('news', ({ data }) => {
    return data.status === 'published';
  });
  return entries.sort((a, b) =>
    new Date(b.data.publishedAt).getTime() - new Date(a.data.publishedAt).getTime()
  );
}

エンジニアがコンテンツを更新するなら、MDXの方がGit履歴に残るし、PRレビューを経由するのでミスが少ない。逆に非エンジニアにGitHubを使わせるのはハードルが高すぎる、というのが現実だ。

「中間の解として、ヘッドレスCMSのデータをビルド時にフェッチしてAstroに流し込む」という組み合わせが増えている。コンテンツ更新は管理画面から、ビルドはGitHub Actionsで走る——という構成は、両方の良いとこ取りに見えて、「どこで何を管理するか」が曖昧になりやすいという落とし穴もある。ドキュメントにはこう書いてあるけど、実際に運用してみると「コンテンツの更新がビルドに反映されるまで何分かかるの？」という質問がクライアントから来る。

非エンジニア編集者が使う前提での評価軸

Contentfulの件で反省してから、クライアントのWeb担当者に「実際に試してもらう」というステップを必ず入れるようにした。

触ってもらう時間は30分。「今日の天気でもなんでも、記事を1本作ってみてください」というシナリオだけ渡して、横で見ている。その様子を見ると、サービスの向き不向きが手触りとして分かる。

非エンジニア編集者目線で評価するなら、自分は以下の3点を重視するようになった。

microCMSが国産で日本語UIという点は、中小企業にとって思った以上に重要なんですよね。「困ったときにサポートに聞けるか」は継続利用の生命線で、英語のみのサポートだと担当者が諦めてしまう。

Sanityは「Studioをカスタマイズできる」という強みがあって、エンジニアが手を入れれば非エンジニアにも使いやすい管理画面にできる。ただ、カスタマイズの工数がかかるし、そこに時間を割けるかどうかはプロジェクト規模次第だ。コーポレートサイト1本のためにSanity Studioをカスタマイズするのは、ちょっとオーバーエンジニアリングになりやすい。

「ヘッドレスCMSは過剰」なケースの判断基準

ここが今思えば一番大事な話かもしれない。

コーポレートサイトの更新頻度と更新コンテンツの種類を見ると、ヘッドレスCMSを使わなくていいケースが思ったより多い。

自分の判断基準をまとめると:

• 更新頻度が月1回以下で、更新するのが採用情報・お知らせ程度 → MDX管理で十分
• 更新者がエンジニアチームのみ → MDXの方がGit管理できて品質が保ちやすい
• 更新頻度が週1回以上、更新者が非エンジニア → ヘッドレスCMSが効果を発揮する
• コンテンツ量が少ない（10〜20件程度） → ヘッドレスCMSを使う動機が弱い
• 予算が限られている（月数千円も出せない） → microCMSの無料プランかMDX管理を選ぶ

ここ数年で「コーポレートサイトにもヘッドレスCMSを」という流れが来たのは分かる。WordPressから離れたいというニーズに、ちょうど良い選択肢として提示されたわけで。

でも実際にやってみると、「ヘッドレスCMSを入れたら管理が楽になった」と言っているのはエンジニア側だったりする。クライアント側が使いこなせているかどうかは別の話だ。

ぶっちゃけ、「ヘッドレスCMSが過剰かどうか」を判断するよりも、「誰が何を更新するか」を最初に明確にする方が早い。その一点を詰めれば、選択肢はかなり絞れる。

振り返って

Contentfulの失敗から半年経って、今は「まず30分のハンズオン」をやるようになった。これが一番効くと思っている。スペック比較表を眺めるよりも、実際に触ってもらう方が合う・合わないがはっきりする。

選択肢が増えると比較検討の時間も増えるんですよね。2026年現在、国産・海外合わせて10サービス以上が選択肢として出てくる状況で、「どれが最強か」を追い続けるのは正直きつい。

今の自分のデフォルトは「非エンジニアが更新するならmicroCMSを試してもらう、エンジニアのみならMDX」で、そこから外れる要件があれば別のサービスを検討する——というシンプルなルールだ。ここは好みが分かれるところだと思うし、もっと良い判断基準を持っている方がいたら、ぜひ教えてもらいたい。

XECIN サービス

AI Web Platform — AIが動かすコーポレートサイト基盤

ヘッドレスCMS と Git 管理（MDX）の境界線で迷っているなら、XECINの「AI Web Platform」が一つの解です。MDX + AIエージェント運用で、非エンジニアの更新負荷と CMS 運用コストの両方を抑えます。このサイト自体がその構成で動いています。

AI Web Platform を見る →