シリーズ②ヘッドレスCMS「microCMS」を選んだ理由｜WordPressとの違いを実体験で解説

結論：microCMS（マイクロシーエムエス）は、記事の管理だけを担当し、表示は別の仕組み（Astroなど）に任せる「ヘッドレスCMS」です。WordPressのように1つのソフトで「執筆」も「表示」もこなすのではなく、執筆はmicroCMS、表示は静的サイトを作る仕組みと、役割を分担します。

なぜこの構成にするのか。理由は、表示を切り離すことでサイトが速く・安全になり、執筆の画面は使いやすいまま保てるからです。株式会社curveが運営するAI情報メディア「AIテックベース」も、WordPressを使わずにこの構成で作りました。

本記事は、AIテックベースがWordPressではなく静的サイトの構成を選んだ経緯を記録したシリーズの第2回です。前回の「なぜWordPressではなく、静的サイトを採用したのか」に続き、今回はその構成を支えるヘッドレスCMS「microCMS」を選んだ理由を、実際に運用して分かった注意点も含めて解説します。

1. ヘッドレスCMSとは何か

「ヘッド（見た目）」を持たないCMS

ヘッドレスCMSとは、コンテンツを管理する機能だけを持ち、表示用の画面（ヘッド）を持たないCMSのことです。「ヘッドレス＝頭（見た目）が無い」という意味で、記事のデータだけを保管し、外部へAPIで渡します。

具体的には、microCMSの管理画面で記事を書いて「公開」すると、その記事のデータはAPI（データを受け渡す窓口）から取り出せる状態になります。サイト側はそのデータを受け取り、自分でデザインした見た目にはめ込んで表示します。

WordPressは「管理」と「表示」が一体

一方、WordPressは管理画面・データベース・表示のテンプレートが1つにまとまった「一体型のCMS」です。記事を書くのも、訪問者にページを見せるのも同じWordPressが行います。手軽な反面、表示のたびにサーバーで処理が走り、管理画面やプラグインが攻撃の対象になりやすいという側面があります。

2. microCMSとAstroを組み合わせる仕組み

基本の流れは「microCMSで書く → Astroが記事を取得する → 静的なHTMLとして書き出す → 配信する」です。AIテックベースの構成は次のとおりです。

• 記事の管理：microCMS（日本製のヘッドレスCMS。執筆と記事の管理を担当）
• 表示：Astro（Webサイトを作るための仕組み。記事を読み込んでHTMLを作る）
• 配信：Cloudflare® Pages（作ったHTMLを配信。自動ビルド・無料のSSL・独自ドメインに対応）

Astroは、サイトを作る（ビルドする）ときにmicroCMSのAPIを呼び出して記事を取得し、すべてのページを「ただのHTMLファイル」に変換します。訪問者が見るのはこの完成済みのHTMLなので、表示が速く、表示のたびにデータベースへアクセスすることもありません。

「APIで取得する」と聞くと難しそうですが、やっていることは「microCMSに記事をくださいと頼み、決まった形式のデータで受け取る」だけです。microCMSには取得を簡単にする部品（SDK）も用意されており、非エンジニアでもAIコーディングツール「Claude Code」と一緒に組み立てられました。

3. Webhook連携で「公開＝自動反映」にする

静的サイトの弱点は、「記事を書いても、サイトを作り直さないと反映されない」点です。これはWebhookで自動化できます。Webhookとは「ある出来事が起きたら、別のサービスへ自動で通知する仕組み」です。

AIテックベースでは、microCMSのWebhookと、Cloudflare Pagesの「デプロイフック」（通知を受けるとサイトを作り直す窓口）をつないでいます。記事を「公開」した瞬間にmicroCMSがCloudflareへ通知を送り、サイトが自動で作り直されて反映されます。担当者の操作は「公開ボタンを押すだけ」なので、WordPressと変わらない感覚で運用できます。公開ボタンを押してから実際のサイトに反映されるまでは、サイト全体を作り直すため数分ほどかかりますが、記事中心のメディアであれば困ることはほとんどありません。設定の手順はWebhookの解説記事で紹介しています。

4. microCMSとWordPressの違い

要点は、「microCMSは速さと安全さに強く、WordPressは手軽さと既製の機能の豊富さに強い」ということです。

5. microCMSを選んだ4つの決め手

ヘッドレスCMSにはいくつも選択肢がありますが、AIテックベースがmicroCMSを選んだ理由は次の4つです。

1. 日本製で、管理画面が分かりやすい：画面も説明書も日本語で、記事を書く人が迷いにくい
2. APIの仕組みが素直：記事の取得・更新の方法がシンプルで、AIに組み立てを手伝ってもらいやすい
3. 無料から始められる：無料のHobbyプラン（作れるAPIは5つまで、月の転送量20GBまで）で試せ、規模が大きくなれば有料のTeamプラン（月額4,900円〔税抜〕から）などに移れる（2026年9月時点）
4. Webhookで自動公開を組める：静的サイトの弱点である「反映の手間」をなくせる

6. 実際に運用して分かった3つの注意点

記事を数十本運用してみて、事前には気づかなかった注意点もありました。これから導入する方の参考になれば幸いです。

注意点1：本文に入れた画像や装飾が消えることがある

APIで本文を送り込むと、microCMSの編集欄の仕様上、画像のタグや、独自の装飾用の指定（クラスや囲みの要素）が取り除かれることがありました。AIテックベースでは、本文には「[図:名前]」のような目印だけを書き、サイトを作るときにAstro側で図に置き換える方式にして解決しました。

注意点2：見出しの識別子が自動で振り直される

記事の冒頭に目次を作り、各見出しへのリンクを付けようとしたところ、microCMSが見出しの識別子を保存時に自動で付け直すため、リンクが切れてしまいました。いったん保存して、付けられた識別子を読み取ってから目次のリンク先を合わせる、という手順で対応しています。

注意点3：記事を登録するAPIでは「下書き→公開」に切り替えられない

APIで下書きとして保存した記事を、記事の登録に使うAPIから公開に切り替えることはできませんでした。なお、別の「マネジメントAPI」には公開状態を変える機能があり、APIキーに権限を付ければ、下書きから公開への切り替えもできます。下書きの公開は管理画面で公開ボタンを押す運用にし、APIで直接公開する場合は最初から公開状態で登録しています。

いずれも致命的な問題ではなく、仕組みを理解すれば回避できるものでした。むしろ注意点1の対応によって、図はすべてサイト側のフォルダで管理することになり、全記事の図のデザインを同じ形式でそろえやすくなるという副次的な効果もありました。導入前に「本文にどこまで装飾を入れたいか」「APIで何を自動化したいか」を整理しておくと、こうした仕様に後から戸惑わずに済みます。

7. microCMSが向いているケース／向かないケース

向いているケース

• 表示の速さと検索エンジン対策を重視するメディアや会社のサイト
• セキュリティを高めたい（公開側に管理画面やデータベースを置かない）
• デザインや構成を自由に作り込みたい
• 記事中心の更新で、書く人と作る人の役割を分けたい

向かないケース

• 予約・会員・ネットショップなどの機能を、プラグインですぐに追加したい
• 表示側を作る人がいない、作る手間をかけたくない
• 更新が極端に多く、公開した瞬間に反映されないと困る（サイトの作り直しに数分かかるため）

AIテックベースは「記事中心で、表示の速さとセキュリティを重視」していたため、microCMS＋Astroの構成が合っていました。

8. 構築でハマったことと、そこからの学び

作ってみて一番実感したのは、「公開側に管理画面が無いと安心感が違う」という点です。表示が速く、攻撃される入口（管理画面・プラグイン・データベース）が無い分だけ安全でした。

一方で、公開先まわりでは苦労もありました。最初はさくらのレンタルサーバーに、GitHubから自動で公開しようとして失敗が続きました。原因は、さくらの「国外IPアドレスフィルタ」でした。これはサイトの閲覧は止めず、ファイル転送（FTP）やSSHなど「管理用の接続」を海外からの接続から守る初期設定で、海外のサーバーで動くGitHubの自動処理が、ここで弾かれていたのです。最終的に公開先をCloudflare Pagesに切り替え、フィルタは有効のまま（安全なまま）自動で公開できるようにしました。詳しい経緯は国外IPアドレスフィルタの記事にまとめています。

非エンジニアとしての学びは、「原因らしきものを片っ端から試す」のではなく、先に環境の仕様を確かめ、エラーの意味を調べて原因を1つに絞ってから直すことの大切さでした。

9. まとめ

• microCMSはヘッドレスCMS。記事の管理だけを担当し、表示はAstroなど別の仕組みに任せる
• 仕組みは「microCMSで書く → APIで取得 → 静的なHTMLとして表示」。表示が速く安全
• Webhookと組み合わせれば「公開ボタンを押すだけ」で自動反映できる
• WordPressとの違いは、速さ・安全・自由度（microCMS）か、手軽さ・既製機能の豊富さ（WordPress）か
• 運用では、画像や装飾が消える、見出しの識別子が振り直される、記事を登録するAPIでは下書きを公開にできない、といった点に注意
• 記事中心で速さとセキュリティを重視するサイトに向いている