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

結論：microCMSは「記事の置き場」と「サイトの見た目」を切り離すCMS

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

なぜこの構成にするのか。理由は、表示を切り離すことでサイトが速く・安全になり、執筆画面は使いやすいまま保てるからです。私たち株式会社curveが運営するAI情報メディア「AIテックベース」も、WordPressを使わずこの構成で構築しました。本記事はその実体験をもとに、非エンジニアの方にも分かるよう解説します。

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

ヘッドレスCMSとは何か

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

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

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

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

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

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

記事はmicroCMS、表示はAstroで作る

典型的な流れは「microCMSで書く → Astroが取得 → 静的HTMLとして書き出す」です。AIテックベースの構成は次のとおりです。

• CMS：microCMS（日本製のヘッドレスCMS。執筆・記事管理を担当）
• フロント：Astro（ウェブフレームワーク。記事を読み込んでHTMLを生成）
• ホスティング：Cloudflare Pages（生成したHTMLを配信。無料・自動ビルド・無料SSL・独自ドメイン対応）

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

APIで記事を取得するイメージ

「APIで取得する」と聞くと難しそうですが、やっていることは「microCMSに記事をくださいと頼み、JSON形式のデータで受け取る」だけです。microCMSは日本製で管理画面が分かりやすく、SDK（取得を簡単にする部品）も用意されているため、非エンジニアでもAIコーディング支援「Claude Code」と一緒に進められました。

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

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

AIテックベースでは、microCMSのWebhook → Cloudflare Pagesのデプロイフックをつないでいます。記事を「公開」した瞬間にmicroCMSがCloudflareへ通知を送り、サイトが自動で再ビルドされて反映されます。担当者の操作は「公開ボタンを押すだけ」なので、WordPressと変わらない感覚で運用できます。Webhookの設定は別記事でも詳しく触れます。

microCMSとWordPressの違い

両者の違いを表で整理します。

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

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

向いているケース

• 表示速度とSEOを重視するメディア・コーポレートサイト（静的HTMLは表示が速い）
• セキュリティを高めたい（公開側に管理画面やデータベースを置かない）
• デザインや構成を自由に作り込みたい（表示を自前で設計できる）
• 記事中心の更新で、執筆者と開発を分けたい

向かないケース

• プラグインで機能を即追加したい（予約・会員・ECなどを手早く入れたい）
• 表示側を作る人がいない／構築の工数をかけたくない
• 更新頻度が極端に高く、即時反映が必須（ビルド時間が気になる場合）

AIテックベースは「記事中心・表示速度とセキュリティ重視」だったため、microCMS＋Astroが適していました。

構築で得られた実感とハマったこと

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

一方で、ホスティングまわりでは苦労もありました。公開先として最初にさくらのレンタルサーバーを使っていて、そこへGitHubから自動デプロイしようとして連続で失敗しましたが、真の原因は「国外IPアドレスフィルタ」でした。これはサイトの閲覧（HTTP）は止めず、FTPやSSH、管理画面など"管理系の入口"だけを海外IPから遮断する初期設定です。GitHubの自動処理は海外のサーバーで動くため、ここで弾かれていたのです。最終的にホスティングをCloudflare Pagesへ切り替え、さくらへ海外からアクセスする必要をなくすことで、フィルタを有効に保ったまま（高セキュリティのまま）自動デプロイできるようになりました。詳しい顛末は別記事「国外IPフィルタ」「Cloudflare Pages」で紹介します。

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

このシリーズの他の記事もどうぞ

本記事は、AIテックベースがWordPressではなく静的サイト構成を選んだ経緯を記録したシリーズの一部です。関連トピックもあわせてお読みください。

• なぜWordPressではなく、静的サイトを採用したのか
• 静的サイトの公開先はどう選ぶ？さくらとCloudflare Pages比較
• さくらの「国外IPアドレスフィルタ」でハマった話
• 個人情報を保存しない問い合わせフォームの作り方
• Webhookで「公開ボタンだけ」運用にする方法
• AI（Claude Code）と一緒に進めた制作の進め方
• 移行時のSEOで気をつけたこと

まとめ

• microCMSはヘッドレスCMS。記事の管理だけを担当し、表示はAstroなど別の仕組みに任せる。
• 仕組みは「microCMSで書く → APIで取得 → 静的HTMLとして表示」。表示が速く安全。
• Webhook連携で「公開ボタンを押すだけ」の自動反映ができる。
• WordPressとの違い：microCMSは速さ・安全・自由度、WordPressは手軽さ・既製機能の豊富さに強い。
• 向く：速度・SEO・セキュリティ重視のメディア／向かない：プラグインで機能を即追加したい場合。
• AIテックベースは記事中心・速度とセキュリティ重視のため、microCMS＋Astro＋Cloudflare Pagesで構築した。

関連記事として「WordPressを使わない選択」「Cloudflare Pages入門」「Webhookで自動公開」「サイト構築時のSEO対策」もあわせてご覧ください。