microCMS「埋め込み機能」利用時のHydrationエラー対策方法
VIEW →
当サイトをmicroCMSに移行しました。
執筆時点の2025年現在はディレクター業務の比重が多いものの、microCMSの実装工数感や最新アップデートを把握するため、自ら実装にも着手しました。これまでクライアントワークでWordPressに携わってきた経験を踏まえ、具体的な活用シーンや事例を交えながら、CMS選びで迷う方の参考になる情報をお届けいたします。
W3Techsの調査によるとWordPressが圧倒的なシェアを占めており、全世界のWebサイトの約43%でWordPressが使用されています。これは単一のCMSとしては驚異的な数値で、他のCMSを大きく引き離しています。
日本国内ではWordPressのシェアはさらに高く、日本語を扱うWebサイトのうち約83%がWordPressを使用しているという統計もあります。これは日本でのWordPressの普及度の高さを物語っています。
参考データ
WordPressは2011年頃から着実にシェアを拡大してきており、現在でもその圧倒的な地位を確立しています。
出典:Kinsta「WordPressの市場シェア統計(2011~2024年)」
一方で、近年注目を集めているのがヘッドレスCMSという新しいカテゴリです。ヘッドレスCMSは、従来のCMSとは異なり、コンテンツ管理機能とフロントエンドの表示を分離したアーキテクチャを採用しています。これにより、セキュリティの向上、コンテンツのパフォーマンス向上、マルチチャネル対応などのメリットを実現しています。
microCMSは、この成長するヘッドレスCMS市場における主要なサービスの一つとして位置づけられています。
microCMSは、APIベースの日本製ヘッドレスCMSです。従来のWordPressのような一体型CMSとは大きく異なり、コンテンツ管理(バックエンド)とコンテンツ表示(フロントエンド)を完全に分離したアーキテクチャを採用しています。
この構造により、以下のようなメリットが得られます。
管理画面とフロントエンドが分離されているため、攻撃対象となる要素が限定され、セキュリティリスクを大幅に軽減できます。
フロントエンドを静的サイト生成(SSG)で構築し、CDN(Content Delivery Network)と組み合わせることで、非常に高速なWebサイトを実現できます。
同じコンテンツをWebサイト、モバイルアプリ、IoTデバイスなど、複数のチャンネルで活用できます。
microCMSは、日本製ヘッドレスCMSとして着実に成長を遂げており、2024年12月時点で利用企業数10,000社突破、サービス継続率99%以上を記録しています。
「国内最大級のヘッドレスCMS『microCMS』、利用企業数が10,000社を突破」
引用元:microCMS公式プレスリリース
これらの数値は、国内ヘッドレスCMS市場でのmicroCMSの地位を示しており、多くの企業から信頼を得ていることがわかります。
microCMSは段階的な料金体系を採用しており、企業規模や利用状況に応じた柔軟な選択が可能です。
プラン | 月額料金 | API呼び出し | API数上限 | メンバー数上限 | 適用規模 |
---|---|---|---|---|---|
Hobby | ¥0 | 無制限 | 5個 | 3名 | 個人・小規模プロジェクト |
Team | ¥4,900〜 | 無制限 | 10個+追加可能 | 3名+追加可能 | チームの小規模プロジェクト |
Business | ¥75,000〜 | 無制限 | 30個+追加可能 | 20名+追加可能 | 標準的なプロジェクト |
Enterprise | 要相談 | 無制限 | 50個以上 | 50名以上 | 大規模や重要度の高いプロジェクト |
参考:https://microcms.io/pricing
特に注目すべきは無料プランの存在で、小規模なプロジェクトやスタートアップであれば、コストをかけずにヘッドレスCMSの恩恵を受けることができます。
サイトの構成は以下となっております。
月額のランニングコストを抑えたいという背景があり、ホスティングには無料プランから独自ドメインを利用できるCloudflare Pagesを、CMSにはmicroCMSを選定いたしました。
フレームワークはNext.jsとAstroで迷いましたが、使用経験があるNext.jsを採用いたしました。
サイトの速度とホスティング環境を踏まえて、公開ページはSSGを採用しています。
その場合microCMSで記事公開時に、毎回ターミナルでbuildコマンドを叩かないと記事がサイトに公開されないため、Webhookを活用して、microCMS管理画面で記事が公開や下書きに変更されたタイミングで、通知をCloudflare Pagesに飛ばしています。
通知を元にCloudflare Pages上でビルドが走り、サイトが更新されます。
お問い合わせフォームのreCAPTCHAに関しては、Next.jsのAPIルートを使用して実装しています。
CloudflareだとEdge Runtime環境で動作するため、通常のNext.jsのAPIルートがそのまま使えませんでした。なのでCloudflare環境向けに少しだけ調整しています。
Cloudflareに移管したことで、利用を考えていたムームーメールが正規の方法では利用できなかったため、「Cloudflare Email Routing」と「Resend」を導入いたしました。
Cloudflare Email Routingがメールを受信する役割、Resendが送信する役割を担っています。
プレビュー機能は独自実装しています。
実装方針としてSSRを利用するパターンや、CSR利用するパターンなどがありますが、今回はSSRで実装しています。
参考:https://blog.microcms.io/preview-pattern/
当初は「Next.jsのDraft Mode」を利用して進めていたのですが、Cloudflare環境移行後に動かず、SSRでの実装に切り替えました。
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側で自動的に行われます。これにより、保守管理のコストの低減につながります。
開発コストについては、少し考慮が必要な点があるかもしれません。
APIの活用や、ホスティング環境とフレームワークの組み合わせ、レンダリングに関する知識など、フロントエンドエンジニア寄りのスキルが求められる場面が増える可能性があります。
そのため、プロジェクトに適したWEB制作会社を見つけることが、WordPressでのプロジェクトよりも少し難しくなるかもしれません。結果として制作にかかる費用が増加するケースも考えられます。
ただし、これはプロジェクトの規模や要件によって大きく異なりますので、一概に言えるものではありません。重要なのは、プロジェクトの目的や予算、期待する成果などを総合的に考慮し、最適なアプローチを選択することです。
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選びの参考になれば幸いです。