WordPressからmicroCMSに移行するべきか?比較・判断基準・手順を解説

こんにちは、湖と月デザインです。

今、WordPressでホームページを運用している方へ。

「表示がなんだか少しずつ重たくなってきた」「セキュリティのニュースを見るたびに、自分たちも大丈夫だろうかと不安になる」。

滋賀でホームページの相談を受けていると、既にWordPressをお使いの方から、こうした「ツールに対する小さな違和感」の相談をたくさんいただきます。

まず、プロとしての正直な結論からお伝えします。

結論として、WordPressからmicroCMSへの移行は、ほとんどの企業にとって「不要」です。無理をして、使い慣れた仕組みを根底から変える必要はありません。

ただし、表示速度に限界を感じている、セキュリティを構造から変えたい、運用フローを効率化したいのいずれかに当てはまるなら、移行は最高の投資になります。今回は、移行を迷っている方のための「YES/NOスコア診断」から、実際の「費用・期間・詳細な手順」まで、包み隠さずお話しします。なお、記事の後半では反対方向、つまりmicroCMSからWordPressへ戻すケースについても、同じ粒度で解説しています。そもそもmicroCMSとは?という全体像は、こちらのmicroCMSまとめ記事もあわせてどうぞ。

なぜ今、この問いが増えているのか

本題に入る前に、少し背景を整理しておきます。

W3Techsの調査(2026年9月時点)によると、世界のウェブサイトのおよそ40.7%がWordPressで構築されています。CMSを利用しているサイトの中だけで見ると、シェアは約59%。圧倒的なシェアを持つ一方で、その規模の大きさゆえに、セキュリティ上のリスクも常につきまとっています。

WordPressのセキュリティ専門機関Patchstackが発表した「State of WordPress Security in 2026」によると、2025年にWordPressエコシステム全体で新たに発見された脆弱性は11,334件。前年比42%増というペースです。このうち91%はWordPress本体ではなく、プラグインに起因するものでした。つまり、WordPress自体が危ういというより、便利に使うために追加してきたプラグインの数だけ、リスクの入口が増えている、というのが実情です。

本体(コア)側で起きた、実際のインシデント「wp2shell」

ただし、「本体は安全、危ないのはプラグインだけ」と言い切れるわけでもありません。2026年7月、WordPress本体そのものに、深刻な脆弱性が見つかりました。独立行政法人情報処理推進機構(IPA)が2026年7月22日に公開した注意喚起によると、REST APIのバッチ処理に関する脆弱性(CVE-2026-63030)と、SQLインジェクションの脆弱性(CVE-2026-60137)を組み合わせることで、認証なしに遠隔からコードを実行できる状態にあったと報告されています(IPA「WordPressの脆弱性対策について(CVE-2026-60137、CVE-2026-63030:wp2shell)」)。

この2つを組み合わせた攻撃手法は、発見者によって「wp2shell」と名付けられました。深刻度を示すCVSSスコアは9.8(10点満点中)と、最上位クラスの危険度です。特別なプラグインを入れていない、標準構成のWordPress 6.9.0〜6.9.4および7.0.0〜7.0.1が対象となり、事態の深刻さを受けてWordPress.org側が対象バージョンに対して自動更新を強制的に有効化するという、異例の対応を取っています。

プラグインを増やさないよう気をつけていても、本体そのものにこうした穴が見つかることがある。これが、WordPressを使い続けるうえで、更新を止められない理由でもあります。逆に言えば、常に最新の状態を保つ運用体制さえあれば、WordPressでも十分に安全性を維持できる、ということでもあります。

一方で、ヘッドレスCMS市場は世界的に拡大を続けています。市場調査会社の報告では、ヘッドレスCMSソフトウェアの世界市場は今後も年率20%前後の成長が見込まれており、コンテンツ管理と表示部分を分離する設計そのものへの関心が高まっています。こうした流れの中で、「そろそろウチも見直したほうがいいのでは」という相談が増えているのだと思います。

国内のCMS事情:WordPressが依然として主流、そのうえで選択肢も広がっている

もう少し詳しく、国内の状況も見ておきます。

日本語サイトに限定したW3Techsのデータ(2025年7月時点)によると、WordPressのシェアは約83%。世界全体の平均(約59〜61%)と比べても、かなり高い水準です(アップルップル「日本語を扱うCMSシェア 2025年7月版」)。つまり、日本のホームページ市場は、世界的に見てもとりわけWordPress一強の状態にある、ということになります。

その一方で、国産ヘッドレスCMSであるmicroCMSは、着実に利用企業数を伸ばしています。

2019年9月のサービス開始から、2022年7月に4,000社、2024年12月に10,000社、そして2026年5月には15,000社を突破しました(microCMS「利用企業数が15,000社を突破」)。

2024年12月から2026年5月までの約1年5ヶ月で5,000社増えており、ここ最近で導入ペースが加速していることがわかります。

国内最大級のヘッドレスCMSとして、スタートアップから大手企業まで、業種・規模を問わず採用が進んでいます。

参考までに、microCMS公式サイトで紹介されている移行事例をいくつか挙げておきます。

株式会社エイチームライフデザインの事例では、複雑化したWordPressの独自カスタマイズから脱却したことで、記事更新のリードタイムが7日から1日以下に短縮されたと報告されています。株式会社IVRyの事例でも、1週間ほどかかっていた記事公開が即時公開できるようになったとされています(microCMS「導入事例インタビュー」)。

ただし、これらはmicroCMS社が自社サイトで公開している事例であり、移行を検討している企業向けに選ばれた「成功事例」である点には注意が必要です。すべての移行がこれほど劇的な効果を生むわけではなく、効果の大きさは、もともとの運用体制やサイトの規模、カスタマイズの複雑さによって変わります。

WordPress側にも、更新のしやすさを保ったまま安定運用している事例は数多くあります。あくまで「うまくいった場合、どのくらいの変化がありうるか」の目安として捉えるのがよさそうです。

「市場シェア〇%」という形では表しにくいサービスですが、利用企業数の伸び方を見る限り、これまでWordPress一強だった国内のホームページ市場にも、少しずつ選択肢が広がってきていると言えそうです。

移行すべきか？「1分スコア診断」

ウチはどうすべきか」を判断するためのセルフチェックです。当てはまる項目を数えてみてください。

移行を検討すべき項目(1つにつき1点)

• ページの表示に3秒以上かかり、お客さまの離脱が気になっている
• プラグインや本体の更新を半年以上放置しており、不安がある
• 特定の枠に依存せず、より自由で質の高いデザインを追求したい
• コンテンツの更新頻度が高く、管理画面の重さがストレスになっている
• 外部からの攻撃(ログイン試行など)の形跡があった
• サイトの維持管理より、中身の発信そのものに時間を使いたい

1つ目の「表示に3秒以上かかる」は、実は軽視できないポイントです。

Googleが2017年にSOASTA社と共同で行った調査では、モバイルサイトの読み込みに3秒以上かかると、訪問の53%が離脱につながるとされています。

表示速度は、デザインの好みの話である以前に、そもそもお客さまに読んでもらえるかどうかの土台に関わる部分です。

診断結果

逆に「移行しなくていい」のはこんな方

スコアが高くても、以下に当てはまるならWordPressを使い続けるのが正解かもしれません。

• 更新頻度が低い
  月に数回しか更新せず、今の運用に大きな不満がない。
• 速度に困っていない

  サイトの表示速度にストレスを感じていない。

• コスト優先
  予算をできるだけ抑えて、手軽にデザインを変更したい。
• 自分たちで完結したい
  専門知識なしで、自分たちだけでプラグイン等の機能追加をしていきたい。

更新頻度が低く、月に数回しか更新せず今の運用に大きな不満がない。サイトの表示速度にストレスを感じていない。予算をできるだけ抑えて、手軽にデザインを変更したい。専門知識なしで、自分たちだけでプラグイン等の機能追加をしていきたい。こうした場合は、無理に移行する必要はありません。

反対に、microCMSからWordPressへ戻るケースもある

ここまでWordPressからmicroCMSへの移行を中心に見てきましたが、実際の制作の現場では、逆方向の相談もあります。

「エンジニアが退職・退任してしまい、フロントエンドのコードを触れる人が社内も委託先もいなくなった」「Next.jsなどの開発環境を維持するコストが、想像以上に負担になっている」「本文だけでなく、サイト全体のレイアウトまで自分たちの手で自由に触りたい」。

こうした理由から、あえてWordPress(特にフルサイト編集対応のテーマ)へ移す、という判断も十分にありえます。

WordPressには、世界中の開発者が作り続けてきた膨大なプラグイン・テーマの資産があり、多少の専門知識があれば、たいていの機能は「探せば見つかる」状態にあります。

この「エコシステムの厚み」は、microCMSにはまだない、WordPressならではの強みです。

移行の方向は、どちらが優れているかではなく、そのときの運用体制や、社内に残せる技術力によって決まる、という点は変わりません。

WordPressとmicroCMSの違い

それぞれの仕組みを、建物に例えて整理します。

編集画面の違い:ブロックエディターとmicroCMSのフォーム入力

毎日の更新作業に直結する「編集画面」も、両者ではかなり性格が異なります。

WordPressの標準エディターは、2018年にWordPress 5.0から導入された「ブロックエディター(Gutenberg)」です。段落、見出し、画像、ボタンなど、コンテンツを構成するすべての要素を「ブロック」という単位で扱い、それらを積み木のように自由に組み合わせてページを作っていきます。専門知識がなくても、レイアウトも含めて自分の感覚で自由にページを組み立てられる点が最大の強みです。その代わり、自由度が高い分、書き手によって見出しの使い方やレイアウトにばらつきが出やすく、サイト全体でデザインの一貫性を保つには、運用ルールを別途決めておく必要があります。

一方のmicroCMSは、あらかじめ「タイトル」「本文」「アイキャッチ画像」「公開日」といった項目(スキーマ)を制作側で設計しておき、入力者はその決められた項目に沿って入力していくフォーム形式です。本文欄にはリッチテキストエディターも用意されており、太字や画像挿入などの基本的な装飾はできますが、ページ全体の自由なレイアウト編集はできません。その代わり、入力者が「どこに何を入れればいいか」で迷うことがなく、誰が更新してもサイト全体のデザインが崩れない、という安心感があります。

つまり、「自由にレイアウトを組みたいのか」「決められた型の中で、迷わず安全に更新したいのか」。ここが、編集画面を選ぶときの分かれ道になります。前者はブロックエディターの強みで、後者はmicroCMSの強みです。microCMSでは、入力者が迷わないための専用フォームを事前に設計できるため、更新担当者が変わっても、品質を保ちやすいという利点があります(この設計作業については、後述する移行ステップの「②コンテンツの再設計」でも触れています)。

なお、WordPressには「フルサイト編集(Full Site Editing)」という機能もあります。ブロックエディターの考え方を記事本文だけでなく、ヘッダーやフッター、トップページのレイアウトといったサイト全体にまで広げたもので、対応テーマを使えば、コードを書かずにサイトの骨格そのものまでブロックで組み替えられます。「本文だけでなく、サイトの見た目そのものも自分たちでいじりたい」という場合は、この機能が強力な選択肢になります。ただし、こちらも自由度が高い分、触れる人が増えるほど、意図しないレイアウト崩れが起きやすくなる、という性質は本文のブロックエディターと同じです。

一方のmicroCMSは、そもそも「サイトの見た目(フロントエンド)」を編集する機能を持っていません。デザインやレイアウトはNext.jsなどを使って別途コードで作り込み、microCMS側は中身のデータを管理することに徹する、という役割分担です。そのため、フルサイト編集のように運用担当者がレイアウトごと触れることはできませんが、逆に言えば、デザインが意図せず崩れる心配もありません。「サイトの見た目まで自分たちで調整したいか」「中身の更新だけに集中したいか」も、両者を選ぶときのもうひとつの分かれ道になりそうです。

「費用」と「期間」の目安

「結局、いくらかかって、いつ終わるのか」という、湖と月デザインの実際の目安をお伝えします。

制作期間の目安は、約2ヶ月〜6ヶ月です。私たちは、単にデータを移すだけの作業はいたしません。「新しい家を建てる」ときのように、これからの数年、あなたがストレスなく発信を続けられるための「使いやすさ」を整えることを大切にしています。

実際の移行ステップ:WordPressからmicroCMSへの場合(6つの工程)

ホームページの移設は、一軒の家を建てることに似ています。土台を固め、柱を立て、住み心地を整える。ホームページ制作の現場では、以下のように慎重に進めていきます。

①現状の診断と棚卸し(地盤調査)

まずは今のWordPressの中身をすべて洗い出します。記事の仕分けでは、過去の記事のうち本当に移行すべきものはどれかを見極め、不要な情報を整理してサイトを身軽にします。構造の把握では、カテゴリー、タグ、カスタムフィールドなど、今のサイトがどんな情報で成り立っているかを可視化します。ここで、先ほど触れた「プラグイン由来の脆弱性」がどれだけ蓄積しているかも、あわせて棚卸しできると安心です。

②コンテンツの再設計(設計図)

microCMSには、最初から「本文欄」があるわけではありません。スキーマ設計では、「タイトル」「本文」「写真」「投稿日」といった項目を、一つひとつ定義していきます。運用画面のカスタマイズでは、入力者が迷わないための「専用の投稿画面」をこの段階で設計します。ここが、将来の使い心地を決める心臓部です。

③環境構築(基礎工事)

設計図をもとに、データの受け皿(API)を作成します。APIの実装では、microCMS上で設計した項目を反映させます。権限・安全性の設定では、編集者ごとに触れる範囲を決めたり、プレビュー用の設定を行ったりして、裏側の安全性を固めます。

④フロントエンド開発(上棟)

ここで、お客さまの目に触れる「表側の画面」を新しく作り上げます。最新技術の導入では、Next.jsなどの技術を用い、瞬時にページが開く仕組みをコードで書き上げます。デザインのブラッシュアップでは、スマホでの読みやすさやボタンの押しやすさなど、細かな手触りを整えていきます。

⑤データの流し込み(引っ越し)

エンジニアがプログラムを使い、慎重にデータを移します。変換プログラムの作成では、WordPressのデータをmicroCMSが理解できる形に変換し、一括で流し込みます。手作業ではないので、数千件あっても正確に移動できます。画像の最適化では、写真をmicroCMSのサーバーへ移し、表示が速くなる次世代形式(WebPなど)へ整えます。

⑥最終テストと公開(竣工)

リダイレクト設定は、ここがSEOの生命線です。WordPress時代のURLから新しいURLへ、検索エンジンの評価を引き継ぐための転送設定を丁寧に行います。そのうえで動作確認を行います。詳しくは、microCMSの公式ブログ「WordPressからmicroCMSにコンテンツを移行するチュートリアル」もご覧ください。

実際の移行ステップ:microCMSからWordPressへの場合

反対方向、つまりmicroCMSからWordPressへ移す場合の流れも、同じように具体的にお伝えしておきます。中身の管理と見た目の表示が分かれていた状態から、ふたたび「ひとつ屋根の下」にまとめていくイメージです。

①現状の棚卸しと要件整理

まずは、今microCMSでどんなスキーマ(項目設計)を組んでいるか、どんなAPIを使ってフロントエンドと連携しているかを洗い出します。あわせて、なぜWordPressへ戻したいのか(エンジニア不在なのか、コストなのか、自由度なのか)を整理し、優先順位をはっきりさせておきます。ここが曖昧なまま進めると、移行後にまた同じ課題にぶつかりかねません。

②WordPress環境の構築

サーバーとドメインを用意し、WordPress本体をインストールします。フルサイト編集に対応したテーマを使うのか、既存の人気テーマをベースにするのかを、運用したい自由度に応じて選びます。あわせて、セキュリティ対策プラグインや更新体制など、これから「継続的に守っていく」ための土台もこの段階で決めておきます。

③コンテンツ構造の再現

microCMSのスキーマで管理していた「価格」「対応エリア」といったカスタムの項目は、WordPressではカスタムフィールドという仕組みで再現していきます。ここは、microCMS移行時の「②コンテンツの再設計」と、ちょうど鏡合わせの工程です。単純にすべてを再現するのではなく、この機会に本当に必要な項目だけに絞り込むと、後の運用が身軽になります。

④デザイン・テーマの実装

お客さまの目に触れる画面を、WordPressのテーマとして作り直します。フルサイト編集を使うなら、ノーコードでレイアウトを組み立てられますし、独自性を追求するなら、専用テーマを一から実装することもできます。今まで培ってきたブランドイメージを損なわないよう、細部のデザインを丁寧に移植します。

⑤データの移行

microCMSのAPIから既存のコンテンツを一括で取得し、WordPressが読み込める形式に変換したうえでインポートします。記事数が多い場合は、変換プログラムを組んで自動化することで、手作業によるミスを防ぎます。画像やファイルも、あわせてWordPressのメディアライブラリへ移設します。

⑥最終テストと公開

こちらもWordPress→microCMSの移行と同様、URLのリダイレクト設定がSEO上とても重要な工程です。旧URLから新URLへ評価を引き継ぐ設定を確認したうえで、表示崩れがないか、フォームは正しく動くかなど、最終チェックを経て公開します。

microCMS移行で「失敗する」パターン

うまくいかないケースも正直に共有しておきます。「流行り」だけで決めてしまうと、更新メンバーが新しい仕組みに馴染めず、発信が止まってしまうことがあります。エンジニアが不在の場合、公開後に自分たちだけでデザインを大幅に変えたいと思っても、コードが書けないと手が出せません。「自分たちだけで全てを完結させ、手軽にカスタマイズし続けたい」なら、WordPressのほうが幸せな場合もあります。

CMSの移行について、よくある質問

移行にあたって、SEOの評価は引き継げますか?

適切にリダイレクト設定を行えば、多くの場合引き継ぐことができます。旧URLから新URLへの転送設定は、移行作業の中でも特に重要な工程のひとつです。設定が不十分だと、これまで積み上げてきた検索順位が一時的に下がるリスクがあるため、専門知識のある制作者と一緒に進めることをおすすめします。これはWordPress→microCMS、microCMS→WordPressのどちらの方向でも変わりません。

WordPressの記事数が多くても移行できますか?

可能です。変換プログラムを使って一括で移行するため、手作業では対応しきれない数千件規模の記事でも、正確に移すことができます。ただし、記事数が多いほど再設計や確認にかかる時間は増えるため、費用・期間ともに規模に応じて幅が出てきます。

移行後、自分たちで更新はできますか?

はい。むしろ、更新のしやすさを重視して設計するのがmicroCMS移行の目的のひとつです。専用の投稿画面をあらかじめ設計しておくことで、専門知識がなくても迷わず更新できる状態を目指します。

WordPressのセキュリティ対策をしっかりすれば、移行は不要ですか?

そのとおりです。更新を怠らず、プラグインを最小限に保ち、信頼できるセキュリティ対策を講じていれば、WordPressのままで十分に安全な運用は可能です。ただし、wp2shellのように本体側で深刻な脆弱性が見つかることもあるため、「更新を止めない」という運用体制そのものが前提になります。移行が必要になるのは、そうした対策や更新の手間そのものに、負担や不安を感じている場合です。

microCMSからWordPressに戻す場合、データはそのまま使えますか?

そのままではなく、変換が必要です。microCMSのスキーマ(項目構成)とWordPressの投稿・カスタムフィールドでは、データの持ち方が異なるため、APIから取得したコンテンツを、WordPressが読み込める形式に変換するプログラムを用意します。件数が多い場合ほど、この変換作業を自動化しておくことが重要になります。

エンジニアが社内にいなくても、microCMSからWordPressへ戻せますか?

戻すこと自体は可能ですが、フロントエンドをどう作るかによって、必要な体制は変わります。フルサイト編集に対応したテーマを使えば、コードを書かずにレイアウトを組めるため、エンジニアがいなくても運用しやすくなります。一方、独自性の高いデザインを求める場合は、実装できる制作者に依頼したほうが、結果的にスムーズです。

WordPressに戻すと、また同じセキュリティの不安が再発しませんか?

可能性はゼロではありません。ただし、以前の不安が「更新を後回しにしていたこと」や「プラグインを増やしすぎていたこと」に起因する場合、運用ルール(自動更新の設定、プラグイン数の上限を決めるなど)を最初から整えておくことで、同じ状態を繰り返さずに済みます。CMSを変えること自体よりも、運用体制を見直すことのほうが、実は本質的な対策だったりします。

まとめ:判断に迷っている方へ

WordPressか、microCMSか。それは、「どちらが優れているか」ではなく、「どちらが今のあなたを自由にするか」という選択です。

ほとんどの企業は、今のままで十分です。ですが、「これからさらに信頼を積み上げたい」「誠実なブランド体験を届けたい」という志を持つ方にとって、microCMSは、その未来を支える強い味方になります。

どちらが自社に合うか、ご自身での判断が難しい場合は、今のホームページの状態を一緒に診断するところから始めましょう。SEO診断ツールで気になる点が見つかった方も、そうでない方も、お気軽にご相談ください。