microCMSの記事が反映されない原因|Webhookと再ビルドを実測
VIEW →
当サイトをmicroCMSに移行しました。
これまでクライアントワークでWordPressに携わってきた経験を踏まえ、具体的な活用シーンや事例を交えながら、CMS選びで迷う方の参考になる情報をお届けいたします。
比較項目 | WordPress | microCMS |
|---|---|---|
基本構造 | 管理画面、データベース、テーマ、公開機能を一体で構成 | コンテンツ管理とAPIを提供し、公開サイトは別に構築 |
公開方法 | 通常はWordPressからそのまま公開 | SSG、SSR、ISR、クライアント側取得などを要件に合わせて実装 |
拡張方法 | テーマやプラグインを利用しやすい | APIとフロントエンドのコードで実装する |
保守範囲 | WordPress本体、テーマ、プラグイン、サーバーを管理 | CMS基盤はmicroCMSが管理。公開サイトとビルド環境は利用者側で管理 |
費用の考え方 | WordPress本体のライセンス料は不要。サーバー、ドメイン、有料テーマ・プラグイン、保守費用が発生 | microCMSの利用料に加え、フロントエンド開発、ホスティング、保守費用を考慮 |
向いている体制 | 管理画面を中心に運用し、既存のテーマやプラグインを活用したい | フロントエンドを開発でき、表示やデータ利用を柔軟に設計したい |
WordPressはオープンソースで、テーマやプラグインの選択肢が多く、管理画面から記事や固定ページを公開できます。WordPress本体の特徴は、WordPress.orgの公式機能紹介でも確認できます。
microCMSはAPIベースの日本製ヘッドレスCMSです。コンテンツをAPIで取得し、Webサイトやアプリの表示へ利用します。ヘッドレスCMSの仕組みを先に確認したい場合は、ヘッドレスCMSと従来型CMSの違いもあわせてご覧ください。
WordPressは、管理画面、データベース、テーマ、公開機能を一つのシステムとして扱います。記事を書いて公開すれば、通常は同じWordPress環境からページが表示されます。
microCMSが担当するのは、コンテンツ管理とAPIによるデータ提供です。microCMS公式ヘルプでも、CMSのインフラはmicroCMS側が管理する一方、Webサイトのフロントエンドと配信環境は別途用意する必要があると説明されています。
参考:microCMS公式「インフラは何を用意したら良いですか?」
この違いは、単に管理画面の使い勝手だけではなく、開発体制、公開方法、保守対象を決めます。microCMSではフロントエンドを自由に設計できる反面、CMSを契約しただけではWebサイトは公開できません。
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側で管理されます。そのため、利用者側の主な保守対象は、フロントエンドとホスティング・ビルド環境です。
サイトの構成は以下となっております。
月額のランニングコストを抑えたいという背景があり、ホスティングには無料プランから独自ドメインを利用できるCloudflare Pagesを、CMSにはmicroCMSを選定いたしました。
フレームワークはNext.jsとAstroで迷いましたが、使用経験があるNext.jsを採用いたしました。
サイトの速度とホスティング環境を踏まえて、公開ページは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での実装に切り替えました。
現在は、microCMS公式MCPとCodexを接続し、記事の取得、下書き作成、更新、公開までを記事運用へ組み込んでいます。実際に確認した設定と操作は、microCMS公式MCPをCodexで使った検証で紹介しています。
企画、執筆ルール、CMSへの反映、公開後の改善までを含む流れは、AIエージェントとCMSを連携した記事運用にまとめました。
WordPressは、ページへのアクセス時にサーバー上でPHPが実行され、データベースへクエリを発行して記事やテンプレート情報を取得し、動的にHTMLを組み立てて返却します。その後、ブラウザがCSSやJavaScriptを読み込んで最終レンダリングを行うため、この一連の処理が初回バイト応答時間(TTFB)を延長し、キャッシュ未ヒット時には顕著な遅延を招く可能性があります。
たとえば Next.js の SSG 機能を利用する場合、ビルド時に microCMS の API からコンテンツを取得して静的 HTML を生成し、CDN 上に配置します。ユーザーからのリクエスト時にはサーバー処理を一切行わず、最寄りのエッジサーバーから完成済みのファイルを直接配信するため、TTFB がほぼ一定かつ非常に短くなる可能性があります。また、CDN キャッシュによってネットワーク遅延を最小化し、ルート単位の自動コード分割や <Link> コンポーネントによるページのプリフェッチ、画像最適化といったフレームワーク標準の機能を併用することで、さらに高速かつ安定した表示が実現できる可能性があります。
まとめると、WordPressの動的生成ではPHP実行とDBクエリ、テンプレート組み立てをユーザーリクエストごとに行うため、TTFBが延長しキャッシュ未ヒット時に遅延が発生しやすいという課題があります。
一方、microCMS+SSG(例:Next.js)の構成では、ビルド時にAPIから取得したコンテンツを静的HTMLとして生成・CDNに配置し、アクセス時はエッジサーバーから完成済みファイルを直接配信します。
この仕組みにより、TTFBの安定化と短縮、ネットワーク遅延の低減が図れ、さらに自動コード分割やプリフェッチ、画像最適化などモダンフレームワークの標準機能を併用することで、より高速かつ安定したページ表示を実現できる可能性があります。
microCMSは、コンテンツ管理に特化したヘッドレスCMSであり、その最大の特徴は、シンプルさと使いやすさにあります。直感的なUIで、誰でも簡単にコンテンツを作成・編集できます。専門的な知識がなくても、Webサイトやアプリのコンテンツを管理することが可能です。
WordPressだと管理画面からコード編集ができてしまったりなど、コンテンツを作成すること以外のことができてしまうので、人によっては少し複雑に感じる場合があります。一方、microCMSはコンテンツ管理に特化しているため、余計な機能がなく、ユーザーはコンテンツ作成に集中できます。
誤解してほしくないのが、シンプルなだけでなく、高度な機能も備えているということです。例として、リッチエディタとHTMLエディタを組み合わせて使用することで、本文の途中に任意のHTMLコードを埋め込むことも可能です。これにより、記事を書くという点においては、非常に柔軟な表現が可能になります。
2025年8月に確認した時点では、リンクを別タブで開く設定なども直感的に行えました。

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

WordPressはWordPress本体や、プラグインのアップデートが頻繁に発生するので、その度に更新をしていく必要があります。脆弱性が発見されると、すぐに攻撃が開始されることがあり、セキュリティ対策は非常に重要です。
なのですが、実態としてアップデートせずに放置されてしまっているサイトがあるというのが現実かと思います。理由としては、更新作業にかかるコストを捻出できない、あるいはウェブ技術に関する知識が不足しているために適切な管理ができていないなどが考えられます。
一方、microCMSはクラウドサービスとして提供されており、システムの更新やセキュリティパッチはmicroCMS側で適用されます。WordPressのようにCMS本体を利用者側で更新する必要がないため、保守管理にかかる負担を抑えられます。
また、ヘッドレスCMSとSSGを組み合わせた構成では、CMSで更新したコンテンツがビルドとデプロイを経て公開サイトへ反映されます。CMSの管理画面と公開環境が分離しており、管理画面上の変更は、ビルドとデプロイが完了するまで公開中のページには反映されません。そのため、更新途中の内容やビルド時の不具合が、本番環境へ直接影響しにくい点もメリットです。
開発コストについては、少し考慮が必要な点があるかもしれません。
APIの活用や、ホスティング環境とフレームワークの組み合わせ、レンダリングに関する知識など、フロントエンドエンジニア寄りのスキルが求められる場面が増える可能性があります。
そのため、プロジェクトに適したWEB制作会社を見つけることが、WordPressでのプロジェクトよりも少し難しくなるかもしれません。結果として制作にかかる費用が増加するケースも考えられます。
ただし、これはプロジェクトの規模や要件によって大きく異なりますので、一概に言えるものではありません。重要なのは、プロジェクトの目的や予算、期待する成果などを総合的に考慮し、最適なアプローチを選択することです。
WordPressからmicroCMSへの移行は、記事データをコピーするだけでは完了しません。少なくとも次の項目を先に整理します。
SEOの観点では、既存URLを変更しない設計が最も分かりやすいです。URLを変更する場合は、旧URLから新URLへの恒久的なリダイレクトと、サイトマップ・内部リンク・canonicalの更新を同時に行います。
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選びの参考になれば幸いです。

関連記事
この記事と同じテーマのコラムを紹介します。
講座・書籍の紹介
Web制作やマーケティングに役立った講座・書籍を紹介します。