Portfolio課題を言葉にして、Webというカタチに変える──
そんな仕事をしています。

microCMSとWordPress徹底比較:2026年更新|実際に実装した体験談

当サイトをmicroCMSに移行しました。

これまでクライアントワークでWordPressに携わってきた経験を踏まえ、具体的な活用シーンや事例を交えながら、CMS選びで迷う方の参考になる情報をお届けいたします。

microCMSとWordPressの違いを先に比較

比較項目

WordPress

microCMS

基本構造

管理画面、データベース、テーマ、公開機能を一体で構成

コンテンツ管理とAPIを提供し、公開サイトは別に構築

公開方法

通常はWordPressからそのまま公開

SSG、SSR、ISR、クライアント側取得などを要件に合わせて実装

拡張方法

テーマやプラグインを利用しやすい

APIとフロントエンドのコードで実装する

保守範囲

WordPress本体、テーマ、プラグイン、サーバーを管理

CMS基盤はmicroCMSが管理。公開サイトとビルド環境は利用者側で管理

費用の考え方

WordPress本体のライセンス料は不要。サーバー、ドメイン、有料テーマ・プラグイン、保守費用が発生

microCMSの利用料に加え、フロントエンド開発、ホスティング、保守費用を考慮

向いている体制

管理画面を中心に運用し、既存のテーマやプラグインを活用したい

フロントエンドを開発でき、表示やデータ利用を柔軟に設計したい

WordPressが向いているケース

  • 記事作成から公開までを一つの管理画面で完結させたい
  • テーマやプラグインを利用して、短期間で必要な機能をそろえたい
  • 問い合わせ、検索、会員機能などを既存の仕組みで実装したい
  • 社内や運用担当者がWordPressの操作に慣れている

WordPressはオープンソースで、テーマやプラグインの選択肢が多く、管理画面から記事や固定ページを公開できます。WordPress本体の特徴は、WordPress.orgの公式機能紹介でも確認できます。

microCMSが向いているケース

  • Next.jsやAstroなどを使い、フロントエンドを独自に設計したい
  • Webサイトとアプリなど、複数の配信先でコンテンツを使いたい
  • CMSと公開サイトを分離し、技術構成を要件に合わせて選びたい
  • WordPress本体やプラグインの更新を含む保守範囲を見直したい

microCMSはAPIベースの日本製ヘッドレスCMSです。コンテンツをAPIで取得し、Webサイトやアプリの表示へ利用します。ヘッドレスCMSの仕組みを先に確認したい場合は、ヘッドレスCMSと従来型CMSの違いもあわせてご覧ください。

microCMSとWordPressでは、管理する範囲が異なる

WordPressは、管理画面、データベース、テーマ、公開機能を一つのシステムとして扱います。記事を書いて公開すれば、通常は同じWordPress環境からページが表示されます。

microCMSが担当するのは、コンテンツ管理とAPIによるデータ提供です。microCMS公式ヘルプでも、CMSのインフラはmicroCMS側が管理する一方、Webサイトのフロントエンドと配信環境は別途用意する必要があると説明されています。

参考:microCMS公式「インフラは何を用意したら良いですか?」

この違いは、単に管理画面の使い勝手だけではなく、開発体制、公開方法、保守対象を決めます。microCMSではフロントエンドを自由に設計できる反面、CMSを契約しただけではWebサイトは公開できません。

microCMSとWordPressの料金を比較

2026年8月29日時点で、microCMSの料金は次のとおりです。表示価格は税抜きで、TeamとBusinessは利用人数やAPI数などに応じて追加料金が発生します。

プラン

月額料金

API呼び出し

API数上限

メンバー数上限

適用規模

Hobby

¥0

無制限

5個

3名

個人・小規模プロジェクト

Team

¥4,900〜

無制限

10個+追加可能

3名+追加可能

チームの小規模プロジェクト

Business

¥75,000〜

無制限

30個+追加可能

20名+追加可能

標準的なプロジェクト

Enterprise

要相談

無制限

50個+追加可能

50名以上

大規模や重要度の高いプロジェクト

最新の上限や機能差は、microCMS公式の料金プランで確認できます。

WordPress本体はGPLv2以降で提供されており、ソフトウェアのライセンス料は不要です。

ただし、導入時には要件整理、テーマの設計・実装、プラグインの選定・設定などの開発工数がかかります。公開後も、WordPress本体・テーマ・プラグインに加え、PHPバージョンの更新などを含めた運用・保守が必要です。

microCMSは、選択するプランに応じた利用料がかかります。無料プランも用意されているため、小規模なプロジェクトやスタートアップであれば、CMSの利用料をかけずにヘッドレスCMSを利用できます。

導入時には、API設計、フロントエンドの設計・実装、ホスティング、プレビュー、Webhook、ビルド環境の構築などの開発工数がかかります。

公開後の保守範囲はWordPressと異なります。microCMSはSaaSとして提供され、CMS基盤のインフラはmicroCMS側で管理されます。そのため、利用者側の主な保守対象は、フロントエンドとホスティング・ビルド環境です。

当サイトでmicroCMSを実装した構成

WEBサイトの構成

サイトの構成は以下となっております。

月額のランニングコストを抑えたいという背景があり、ホスティングには無料プランから独自ドメインを利用できるCloudflare Pagesを、CMSにはmicroCMSを選定いたしました。

フレームワークはNext.jsとAstroで迷いましたが、使用経験があるNext.jsを採用いたしました。

レンダリング:SSG,SSR,ISR,On-demand ISRなどに関して

サイトの速度とホスティング環境を踏まえて、公開ページはSSGを採用しています。

その場合microCMSで記事公開時に、毎回ターミナルでbuildコマンドを叩かないと記事がサイトに公開されないため、Webhookを活用して、microCMS管理画面で記事が公開や下書きに変更されたタイミングで、通知をCloudflare Pagesに飛ばしています。

通知を元にCloudflare Pages上でビルドが走り、サイトが更新されます。

実際の反映時間と、記事が404または更新前の内容になる場合の確認方法は、microCMSの記事が反映されない原因とWebhookの確認手順にまとめています。

サーバー側の処理が関わる部分に関して

お問い合わせフォームのreCAPTCHAに関しては、Next.jsのAPIルートを使用して実装しています。

Cloudflare Pagesへ移行した当時は、Next.jsのAPIルートをEdge Runtimeで動かすため、Cloudflare環境向けの調整を行いました。現在、Cloudflareは動的なNext.jsアプリケーションの実行環境としてWorkersを案内しており、Pagesは静的エクスポート向けの選択肢として案内しています。最新の構成は、Cloudflare公式のNext.jsガイドで確認できます。

メールアドレスに関して

Cloudflareに移管したことで、利用を考えていたムームーメールが正規の方法では利用できなかったため、「Cloudflare Email Routing」と「Resend」を導入いたしました。

Cloudflare Email Routingがメールを受信する役割、Resendが送信する役割を担っています。

プレビュー機能に関して

プレビュー機能は独自実装しています。

実装方針としてSSRを利用するパターンや、CSR利用するパターンなどがありますが、今回はSSRで実装しています。

参考:https://blog.microcms.io/preview-pattern/

当初は「Next.jsのDraft Mode」を利用して進めていたのですが、Cloudflare環境移行後に動かず、SSRでの実装に切り替えました。

MCPとAPIを記事運用へ取り入れた

現在は、microCMS公式MCPとCodexを接続し、記事の取得、下書き作成、更新、公開までを記事運用へ組み込んでいます。実際に確認した設定と操作は、microCMS公式MCPをCodexで使った検証で紹介しています。

企画、執筆ルール、CMSへの反映、公開後の改善までを含む流れは、AIエージェントとCMSを連携した記事運用にまとめました。

WordPressとの比較して感じたメリット・デメリット

パフォーマンス(表示速度)の観点

WordPress(PHP+動的生成)の仕組みと課題

WordPressは、ページへのアクセス時にサーバー上でPHPが実行され、データベースへクエリを発行して記事やテンプレート情報を取得し、動的にHTMLを組み立てて返却します。その後、ブラウザがCSSやJavaScriptを読み込んで最終レンダリングを行うため、この一連の処理が初回バイト応答時間(TTFB)を延長し、キャッシュ未ヒット時には顕著な遅延を招く可能性があります。

microCMS+SSG の仕組みとメリット(例:Next.js を利用した構成)

たとえば Next.js の SSG 機能を利用する場合、ビルド時に microCMS の API からコンテンツを取得して静的 HTML を生成し、CDN 上に配置します。ユーザーからのリクエスト時にはサーバー処理を一切行わず、最寄りのエッジサーバーから完成済みのファイルを直接配信するため、TTFB がほぼ一定かつ非常に短くなる可能性があります。また、CDN キャッシュによってネットワーク遅延を最小化し、ルート単位の自動コード分割や <Link> コンポーネントによるページのプリフェッチ、画像最適化といったフレームワーク標準の機能を併用することで、さらに高速かつ安定した表示が実現できる可能性があります。

まとめると、WordPressの動的生成ではPHP実行とDBクエリ、テンプレート組み立てをユーザーリクエストごとに行うため、TTFBが延長しキャッシュ未ヒット時に遅延が発生しやすいという課題があります。

一方、microCMS+SSG(例:Next.js)の構成では、ビルド時にAPIから取得したコンテンツを静的HTMLとして生成・CDNに配置し、アクセス時はエッジサーバーから完成済みファイルを直接配信します。

この仕組みにより、TTFBの安定化と短縮、ネットワーク遅延の低減が図れ、さらに自動コード分割やプリフェッチ、画像最適化などモダンフレームワークの標準機能を併用することで、より高速かつ安定したページ表示を実現できる可能性があります。

microCMSの特徴:シンプルさと使いやすさ

microCMSは、コンテンツ管理に特化したヘッドレスCMSであり、その最大の特徴は、シンプルさと使いやすさにあります。直感的なUIで、誰でも簡単にコンテンツを作成・編集できます。専門的な知識がなくても、Webサイトやアプリのコンテンツを管理することが可能です。

WordPressだと管理画面からコード編集ができてしまったりなど、コンテンツを作成すること以外のことができてしまうので、人によっては少し複雑に感じる場合があります。一方、microCMSはコンテンツ管理に特化しているため、余計な機能がなく、ユーザーはコンテンツ作成に集中できます。

誤解してほしくないのが、シンプルなだけでなく、高度な機能も備えているということです。例として、リッチエディタとHTMLエディタを組み合わせて使用することで、本文の途中に任意のHTMLコードを埋め込むことも可能です。これにより、記事を書くという点においては、非常に柔軟な表現が可能になります。

外部リンク設定

2025年8月に確認した時点では、リンクを別タブで開く設定なども直感的に行えました。

microCMSエディタのリンク設定画面

使いやすいテーブル

テーブル設定機能も備わっており、直感的に操作できます。

microCMSエディタのテーブル設定画面

microCMSのメリット:保守管理のコスト

WordPressはWordPress本体や、プラグインのアップデートが頻繁に発生するので、その度に更新をしていく必要があります。脆弱性が発見されると、すぐに攻撃が開始されることがあり、セキュリティ対策は非常に重要です。

なのですが、実態としてアップデートせずに放置されてしまっているサイトがあるというのが現実かと思います。理由としては、更新作業にかかるコストを捻出できない、あるいはウェブ技術に関する知識が不足しているために適切な管理ができていないなどが考えられます。

一方、microCMSはクラウドサービスとして提供されており、システムの更新やセキュリティパッチはmicroCMS側で適用されます。WordPressのようにCMS本体を利用者側で更新する必要がないため、保守管理にかかる負担を抑えられます。

また、ヘッドレスCMSとSSGを組み合わせた構成では、CMSで更新したコンテンツがビルドとデプロイを経て公開サイトへ反映されます。CMSの管理画面と公開環境が分離しており、管理画面上の変更は、ビルドとデプロイが完了するまで公開中のページには反映されません。そのため、更新途中の内容やビルド時の不具合が、本番環境へ直接影響しにくい点もメリットです。

初期の開発コストに関して

開発コストについては、少し考慮が必要な点があるかもしれません。

APIの活用や、ホスティング環境とフレームワークの組み合わせ、レンダリングに関する知識など、フロントエンドエンジニア寄りのスキルが求められる場面が増える可能性があります。

そのため、プロジェクトに適したWEB制作会社を見つけることが、WordPressでのプロジェクトよりも少し難しくなるかもしれません。結果として制作にかかる費用が増加するケースも考えられます。

ただし、これはプロジェクトの規模や要件によって大きく異なりますので、一概に言えるものではありません。重要なのは、プロジェクトの目的や予算、期待する成果などを総合的に考慮し、最適なアプローチを選択することです。

WordPressからmicroCMSへ移行するときの確認項目

WordPressからmicroCMSへの移行は、記事データをコピーするだけでは完了しません。少なくとも次の項目を先に整理します。

  • 投稿、固定ページ、カスタム投稿を、microCMSのどのAPIへ移すか
  • カテゴリー、タグ、著者、関連記事をどのフィールドで管理するか
  • 本文内の画像とメディアURLをどう移行するか
  • 既存URLを維持するか、変更する場合にどのURLからリダイレクトするか
  • title、meta description、canonical、OGP、構造化データをどこで生成するか
  • 下書きプレビューと公開後の再ビルドをどのように行うか

SEOの観点では、既存URLを変更しない設計が最も分かりやすいです。URLを変更する場合は、旧URLから新URLへの恒久的なリダイレクトと、サイトマップ・内部リンク・canonicalの更新を同時に行います。

WordPress静的化という第3の選択肢

CMS選びは用途・求める機能によって異なりますが、「WordPressの使い勝手はそのままに、保守負担やセキュリティ面の不安を減らしたい」という方には、SaaS型サービスのShifter(Shifter Static)がおすすめです。

Shifter(Shifter Static)は、WordPressの利用環境から公開用ホスティングまでをSaaSで一括提供するサービスです。WordPressを静的HTMLに変換し、HTML/CSSファイルをCDN経由で配信することで、管理画面と公開領域を完全に分離。公開環境ではPHPが動作せず、安全かつ高速なサイトが実現できます。

さらに、インフラ環境の構築や運用、WordPress本体の管理(プラグインなどはユーザー側)はShifter側が行うため、ユーザーはコンテンツの作成・更新に専念でき、保守にかかる工数を大幅に削減できます。

実際に私自身もShifterで制作をしたことがありますが、お問い合わせフォームや検索機能など、デプロイ後の静的状態ではPHPの処理ができない点を意識して要件定義を行えば、基本的にはWordPressの知見がある方であれば対応可能だと感じました。

まとめ

これまでWordPressをはじめ、WebflowやSTUDIOなどのノーコードツール、EC-CUBEやShopifyといったECプラットフォームなど、さまざまなCMSを使ってきました。それぞれに長所と短所があり、一概に「これが最適」とは言い難いのが正直なところです。

私自身、WordPressの保守作業で「もう少し楽になれば…」と感じることが多く、2022〜23年ごろからヘッドレスCMSにも関心を持つようになりました。複雑なサイトの保守を実際に経験してきたからこそ、microCMSのシンプルさと扱いやすさには、とても惹かれています。

最終的には、プロジェクトの規模や目的、チームのスキルセットに合わせて、最適なツールを選ぶことが大切です。この記事が、みなさまのCMS選びの参考になれば幸いです。

#
執筆者 | 西條輝
1995年生まれ。
Web業界は8年目です。それ以前は、実製品の品質管理などを5年ほど担当していました。
生成AIの進歩で「作ること自体のハードル」は下がったからこそ、現場の課題を丁寧に言葉にし、Webというカタチに落とし込むことが、これからますます重要になると感じています。
X(Twitter)
お問い合わせはこちら

関連記事

RELATED BLOG

この記事と同じテーマのコラムを紹介します。

講座・書籍の紹介

LEARNING

Web制作やマーケティングに役立った講座・書籍を紹介します。