LIGブログをmicroCMSに移管できるか検証してみた

こんにちは、Web制作会社LIGのフロントエンドエンジニア、西澤です。

クライアントから「うちのWordPress、このまま使い続けて大丈夫ですか？」と聞かれることが増えました。

この質問への正直な答えは「サイトによります」です。ただ、「サイトによります」だけでは判断できません。WordPressのまま運用する場合と、別のCMSへ移す場合など、それぞれに何がどれだけかかるのかを並べて、はじめて判断していただけると考えています。

そこで1ヶ月かけて、WordPressからヘッドレスCMS「microCMS」へ、見た目を変えずに中身だけ移行する仕組みを作りました。移行という選択肢を、WordPressを継続する場合と同じ精度で提示できるようにするためです。この記事では、なぜそれを作ったのか、実際にやってみて何がわかったのかを書きます。

※なお、移行スクリプトそのものは社外非公開としているため、コードや実装の詳細には踏み込みません。そのぶん、判断の材料と、実際にかかった工数、うまくいかなかった部分などを具体的に紹介していこうと思います。

WordPress継続と移行、見積もりの精度がそもそも違う

サイトの相談をいただくとき、選択肢としては大きく2つあります。WordPressのまま運用を整えるか、別のCMSへ移すかです。

このうち前者は、長く手がけてきた領域なので、何にどれだけかかるかを具体的にお出しできます。

一方で後者は、業界的にも見積もりが立てにくい領域です。記事の中身もカスタムフィールドの使われ方も案件ごとにバラバラで、実際に手を動かしてみないと読めない部分が多い。どうしても「20〜40人日」のような幅のある数字になります。

片方は具体的な数字、もう片方は幅のある概算。これでは、2つを並べても比べたことになりません。そうなると、話は自然とWordPressを継続する方向に寄ります。多くの場合それが最適解でもあるのですが、「比較したうえでそう言える」状態にしておきたいという思いがありました。

2026年7月に見つかった脆弱性で、相談が急増した

2026年7月、WordPressコアに深刻な脆弱性が見つかりました。通称「wp2shell」と呼ばれているもので、ざっくり言うとログインしていない第三者が、外部からサイトを操作できてしまうという内容です。

深刻度を示すCVSSというスコアで最高レベルに近い評価がつき、特別なプラグインを入れているサイトだけでなく標準的な構成のサイトも対象でした。WordPress.orgが対象バージョンに更新を強制適用するという異例の対応も取られています。

※出典：IPA「WordPressの脆弱性対策について」（2026年7月22日公開）

私たちのところにも、緊急のご相談が相次ぎました。7〜8月は、調査と復旧の支援にエンジニア総出で当たった2ヶ月でした。

そして、冒頭の質問が一気に増えました。「うちは大丈夫か」「何かしたほうがいいのか」。

このとき改めて思ったのが、選択肢を並べて比較できる状態を、こちらが持っていないといけないということでした。移行を薦めたいわけではなく、「移行しない」という判断にも根拠が要るからです。

そこで、冒頭でもお伝えしたとおり1ヶ月かけて、LIGブログの実記事を使って移行を丸ごと一度やってみることにしました。型を作り、工数を実測して、両方の選択肢を同じ精度で出せるようにするためです。

以降は、そこで分かったことを順に書いていきます。

WordPressをめぐる状況とリスク

WordPressが狙われ続ける理由

どちらを選ぶにしても、リスクの中身を把握していないと比較になりません。ここは判断材料として整理しておきます。

WordPressが悪いソフトウェアだ、という話ではまったくありません。むしろ逆で、世界で最も使われているCMSだからこそ狙われるというのが実態です。

攻撃する側から見ると、シェアの高いソフトウェアはかっこうの標的です。ひとつ攻撃手法を確立すれば、それが世界中の膨大な数のサイトに通用してしまう。この構造がある限り、WordPressが狙われ続けるのは避けられません。

そしてもうひとつ、構造的な事情があります。WordPressはコア・テーマ・プラグインという三層でできていて、そのそれぞれが攻撃の入口になり得ます。コアの脆弱性はまだ情報が早く回りますが、個別のプラグインとなると、更新が止まっているものや、開発者が対応してくれないものもあります。

さらに運用側の現実として、次のような負担があります。

• 脆弱性情報を追いかけて、自社サイトが対象かどうかを判断する
• 検証環境でアップデートを試して、表示崩れや不具合が出ないか確認する
• 本番に適用するタイミングを調整する
• これを担当できる人が、社内に一人しかいない

最後の「属人化」が、実務ではいちばん重い問題だと感じています。担当者が異動や退職をした瞬間に、サイトの更新が止まってしまう。近い経験をした方も多いのではないでしょうか？

インシデント対応で痛感した、復旧より大変なこと

守秘義務の関係で詳細は書けませんが、私たちは実際にWordPressサイトの侵害対応を経験しました。そのときに痛感したことをひとつだけ書きます。

復旧そのものより、「どこまで侵入されたのか」を確定させるほうが、はるかに大変です。

サイトを元に戻すだけなら、バックアップがあれば技術的には可能です。しかし「いつ入られたのか」「バックアップ自体が汚染されていないか」「他に何か仕込まれていないか」を確認しないと、戻した瞬間にまた同じ状態になりえます。ログを追い、ファイルの更新日時を突き合わせ、一つずつ潰していく作業が必要になります。

そして、この調査には終わりが見えません。「もう安全です」と言い切るためには、それなりの根拠が必要になるからです。さらに、この期間サイトは止まったままになります。

こうした経験を経て、私たちは「どう守るか」と「そもそも何を守らずに済ませられるか」を、案件ごとに両方検討するようになりました。順番に書きます。

リスクへの、2つの向き合い方

これまで見てきたリスクに対して、2つの向き合い方があります。WordPressのまま運用を整えるか、そもそも守るべき範囲を減らすか。順に見ていきます。

選択肢①：WordPressのまま、リスクを下げる

移行の話に入る前に、WordPressのまま対応する方法を書きます。実務でやっている対応の大半は、こちらです。

• アップデート運用の仕組み化：自動更新の設定、検証環境での事前確認、定期メンテナンスの枠の確保。「気づいたときにやる」から「決まったタイミングでやる」に変えるだけで、対応の遅れはかなり減ります。
• プラグインの棚卸し：使っていないもの、更新が止まっているものを外す。プラグインの数は、そのまま攻撃の入口の数になります。
• 管理画面の露出を減らす：ログインURLへのIP制限やBasic認証、二段階認証、ログイン試行回数の制限。ここだけでも、機械的に行われる攻撃の多くは弾けます。
• WAFの導入：脆弱性が公表されてから、修正を適用するまでの時間を稼げます。
• 権限とアカウントの見直し：退職した方のアカウントや、もう使っていない管理者権限が残っていないか。実務ではここが穴になりがちです。
• バックアップと復旧手順の確認：取れているかどうかではなく、戻せるかどうか。改ざん検知とあわせて、復旧手順を一度通しておくだけで、いざというときの初動がまったく変わります。

これらに加えて、保守の体制や、公開側の構成を見直すという方法もあります。

前の章で書いた属人化は、技術ではなく体制の問題です。保守を担当できる人が社内に一人しかいないのであれば、外部の保守契約で二重化しておくほうが、CMSを乗り換えるよりも早く済みます。

また、「WordPressの管理画面はそのまま使い、公開側は静的なファイルとして書き出す」という中間的な構成もあります。編集体験を変えずに公開側の露出だけを減らせるので、選択肢として検討する価値はあります。

ここまでやれば、多くのサイトは十分に運用していけます。実際、私たちが保守しているWordPressサイトの多くは、この方向で運用しています。

そのうえで、ひとつだけ残る前提があります。コアやプラグインに脆弱性が出るたびに、追従し続けなければならないということです。次の章は、その前提そのものを変える選択肢の話になります。

選択肢②：守る範囲そのものを減らす

前章に挙げた対策は、どれも効果があります。私たちも日常的にやっています。ただ、これらはすべて「守るべきものがそこにある」という前提の上に成り立っています。守る対象が残っている限り、脆弱性が出るたびに手を動かし続けることになります。

ここからは、まったく別のアプローチの話です。

ヘッドレスCMSを使って、表示側を静的ファイルとして書き出し配信する構成は、この前提そのものを変えます。

ヘッドレスCMSって？

「管理画面とデータだけを持つCMS」のことで、表示側は別に作ります。この記事では、そのヘッドレスCMSと組み合わせて、表示側をあらかじめ静的なファイルとして書き出して配信する構成を前提に話を進めます。以降、この構成を「Jamstack」と呼びます。この記事で扱っているmicroCMSも、このヘッドレスCMSの一つです。

フロントエンド側にサーバーサイドの仕組みを持たせれば、ヘッドレスCMSでも動的な機能は実装できます。ただ、そうすると公開側に動く仕組みが戻ってくるので、ここで書いている「守る範囲が減る」というメリットは薄れます。

以降の比較は、すべて静的配信を前提にしたものだと思ってお読みください。

従来のWordPress構成では、記事を書く管理画面も、データベースも、ページを生成する仕組みも、すべて公開されているサーバーの上に乗っています。訪問者がアクセスするのと同じ場所に、管理機能が同居している状態です。

Jamstack構成では、これが分離されます。

• 記事を書く場所（管理画面・データベース）は、microCMSというサービス側に移る
• 表示する場所は、あらかじめ生成された静的なファイルを配信するだけになる

結果として、公開サーバー上に「乗っ取られる対象」が存在しなくなります。管理画面がないので管理画面は突破されませんし、動的にページを生成する仕組みがないので、そこを起点にした攻撃も成立しません。

対策を積み増すのではなく、守るべき範囲そのものを減らすという発想です。

もちろん、副次的なメリットもあります。静的配信になるので表示が速くなりますし、サーバーの固定費も下がるケースが多いです。ただ、この記事では話を広げすぎないよう、セキュリティの観点に絞ります。

ただし、これは「Jamstack構成のほうが優れている」という話ではありません。公開側から機能を削った結果として得られるメリットなので、当然その裏返しのデメリットもあります。両者の違いは、次の章で並べて整理します。

WordPressとJamstack構成、何が違うのか

すべてのサイトがJamstack構成にすべきだとは考えていません。microCMSなど、どのヘッドレスCMSを使うにしても、どちらにも強みと弱みがあるので、判断材料として並べて比較します。

こうして並べると、WordPressが優位な項目もはっきりあります。プラグインで機能を足していける柔軟さ、初期コストの抑えやすさ、そして扱える人の多さは、他のCMSではなかなか代えがききません。

つまり、WordPressが向いているのは、機能を継ぎ足しながら育てていくサイトです。会員機能や予約、ECのように動的な仕組みが中心のサイト、プラグインに支えられた機能が多いサイト、公開ボタンを押した瞬間の反映が必要なサイト。そして、社内に編集メンバーが多く、いまの運用が回っているサイトも、無理に変える理由はありません。

一方でJamstack構成が向いているのは、記事型で構成が定型化されているサイトです。ブログ、オウンドメディア、コーポレートサイトなど、ページの型が決まっていて、公開のタイミングが数十秒ずれても困らないもの。そして、保守の負担やセキュリティのリスクを、運用でカバーするのではなく構造から減らしたい場合です。

もうひとつ、あまり語られない判断軸があります。Jamstack構成は、保守できる人の要件が変わります。WordPressの管理画面を触れる人ではなく、フロントエンドのコードを読み書きできる人が必要になる。「属人化から抜け出すための移行」が別の属人化を生まないかは、事前に確認しておく必要があります。

ここまでが、判断材料の話です。次の章からは、実際に作ったものの中身を書いていきます。

microCMS移行の6ステップ

ここまで見てきた通り、目的はWordPress継続と同じ精度で、移行にかかる工数を示せるようにすることでした。検証の対象には、LIGのオウンドメディア「LIGブログ」を選びました。記事数の多い巨大なメディアで問題なく移行できれば、他のサイトへの応用もしやすいと考えたためです。

ここからは、その検証を実際にmicroCMSで行った内容を書いていきます。調査から公開まで、一度通しています。

① 現状調査

既存サイトの記事数、テーマファイルの構成、使っているカスタムフィールド、プラグインへの依存度、他との共通項目がないか等を洗い出します。ここで移行の難易度がほぼ決まるので、いちばん手を抜けない工程です。

② microCMS側のスキーマ設計

WordPressの投稿・カテゴリー・タグ・カスタムフィールドを、microCMS側のAPI構造にどう対応させるかを設計します。ここで欲張って複雑にすると、運用する編集者が使いづらくなるので、実際に使われているフィールドだけを残す方針にしました。

③ データ移行

自動化するために、移行スクリプトを用意しました。現時点で自動変換の対象にしているのは以下です。

• 記事本文
• 著者
• カテゴリー
• アイキャッチ画像

④ フロントエンドの構築

WordPressのテーマ（PHP）で作られていた画面を、フロントエンドのフレームワークで作り直します。今回はNext.jsを使いましたが、ここは要件やチームの得意分野に合わせて選べる部分です。見た目は変えない方針なので、既存のHTML構造とCSSはできるだけそのまま流用します。

ただし、目次の自動生成など、WordPressのプラグインやテーマ側の機能に依存していた部分は作り直しが必要になります。また、microCMSのプレビューページの実装も必要になります。

⑤ リダイレクト設計

URL構造が変わる場合は、旧URLから新URLへのリダイレクトを設計します。検索順位への影響を最小化するために、ここは慎重にやる必要があります（詳しくは次章で書きます）。

⑥ 公開

Vercelにデプロイします。microCMSで記事を公開すると自動的にサイトへ反映される仕組みも、ここで組み込みます。

やってみて分かった成果

移行後の再現率は、約80〜90%

実際にやってみた結果、移行前の記事の見た目・構造がそのまま移せた割合は、約80〜90%でした。手を入れる必要があるのは、残りの1〜2割だけです。

残りの10〜20%は何かというと、主に次のようなものです。

• 複雑なショートコードを使っている記事
• 記事内で個別にスタイルを当てている箇所
• 特殊なレイアウトの記事

これらは自動変換では吸収しきれないので、個別に手を入れて対応します。

この10〜20%を無理に自動化しない、というのは意図的な設計です。8〜9割を自動で片付けて、残りは人が見る。この配分がいちばん速く、仕上がりも確実になります。全自動を目指すと、かえって確認と手直しに時間がかかります。

移行部分の工数は、約8割の圧縮に

これが、今回いちばん大きな成果でした。

過去に実際にクライアントへ提出した移行案件の見積もりを、この仕組みを前提に組み直してみました。

※ WordPress → 別CMSへの移行見積もりの比較
※現時点で自動移行の対象にしているのはブログ記事のみです。固定ページ、問い合わせフォーム、予約投稿については、案件ごとに設計が必要なため対象外にしています（技術的には可能ですが、案件ごとにカスタマイズする仕様にしています）。

移行部分だけで見ると、約8割の圧縮です。さらに、今までは「20〜40人日」のように幅での見積もりしかだせませんでしたが、いまは記事数とテーマ構成が分かれば、根拠のある数字をすぐに出すことができます。

仕様把握・設計まで減る理由

データ移行が減るのはスクリプトのおかげで分かりやすいのですが、設計工数まで減っている理由は別です。社内でも聞かれたので補足します。

• 調査項目がチェックリスト化された：記事数、テーマ構成、カスタムフィールドの棚卸し、プラグインへの依存度など、見るべき箇所が固定されたので、調査の抜け漏れと手戻りがなくなりました。
• 設計書のたたきを自動生成できるようになった：調査結果を流し込むと設計書のたたきが出力されるプロンプトのテンプレートを用意しました。白紙から書き起こす時間がなくなり、人はレビューと案件固有の判断に時間を使えるようになっています。
• スキーマ設計が型化された：WordPressの投稿・カテゴリー・タグ・カスタムフィールドをmicroCMSのAPIにどう対応させるかを毎回ゼロから考えず、既存の型に当てはめて差分だけ設計すればよくなりました。
• 自動変換の守備範囲が実績で分かっている：どこまで自動で移せて、どこから手作業になるかの線引きが早い段階でつくので、見積もりの精度が上がりました。

AIが効くのは、あくまで型が決まっている部分の下書きまでです。何を残して何を捨てるか、どのフィールドをどう対応させるかといった判断は、結局こちらでやることになります。

逆に言えば、案件固有のカスタムフィールドや独自レイアウトの設計は、いまも人がやっています。ここがゼロにならないので、3〜4人日は残ります。

移行のハードルと、その乗り越え方

実際に手を動かしてみて、設計上の判断が必要になった部分を書きます。これから移行を検討される方の参考になるはずです。

カスタムフィールドのマッピング

WordPressのカスタムフィールドは、運用の中でどんどん増えていきます。移行しようとして中身を見ると、「これ、何のために作ったんだろう」というフィールドがかなり出てきました。

対処としては、全部を機械的に移さず、実際に値が入っているフィールドだけを対象にする方針にしました。移行前に棚卸しをする手間はかかりますが、移行後の運用が確実に軽くなります。

画像パスの張り替え

記事本文中の画像は、WordPressのメディアライブラリのURLで書かれています。これをmicroCMS側に移したうえで、本文中のパスも書き換える必要があります。

数が多いと手作業では現実的でないので、ここはスクリプト側で処理しています。ただし、外部サイトの画像を直リンクしている記事などは例外扱いになるため、事前の洗い出しが必要でした。

URL構造の変更とリダイレクト

ここがいちばん慎重に行わなくてはならない部分です。URLが変わると、検索エンジンからのSEO評価がリセットされる可能性があります。既存の記事に検索流入がある場合、ここでの設計ミスは直接的な損失になります。

基本方針としてはURL構造をできるだけ変えない、変わる場合は旧URLから新URLへ適切にリダイレクトを設定する、という進め方になります。

なお、リダイレクトは検索評価に直結する部分なので、あえて仕組みで一律に処理せず、案件ごとに設計する方針にしています。

プレビュー機能の作り直し

WordPressの「下書きプレビュー」に慣れている編集者の方は多いと思います。Jamstack構成では、この体験を別の形で作り直す必要があります。

microCMSの下書き機能とVercel側の仕組みを連携させれば実現できますが、WordPressのプレビューとまったく同じ挙動にはなりません。ここは移行前に、編集する方に必ず確認していただくようにしています。

公開フローの再設計

「公開ボタンを押したら即反映」というWordPressの体験は、静的配信ではそのままにはなりません。ただ、フロントエンドを自分たちで作る構成であれば、反映の速さを取るか、サイトの軽さを取るかを選べるようになります。

• 完全に静的化：表示は最速・最も堅い。反映はビルド完了後で、記事数が増えるほど時間が伸びる
• 更新されたページだけ再生成：記事数が増えても反映時間は変わらない。多くの案件はここが落としどころ
• アクセスのたびに生成：反映は即時。そのかわり静的配信の軽さは薄れる

しかもこれはページ単位で使い分けられます。記事詳細は静的、更新頻度の高い一覧だけ再生成、といった組み合わせが可能です。

運用フロー自体を見直す必要が出てくる場合もあるので、ここも事前のすり合わせが重要です。

それでも、毎回ゼロから考えていた部分がパターン化できただけで、進め方はかなり変わりました。

WordPress運用にお困りの方へ

移行するかどうか、判断がつかない場合もあると思います。そうした場合は、お気軽にご相談ください。

LIGは、WordPressサイトの構築・保守と、ヘッドレスCMSを使ったJamstack構成への移行のどちらも手がけています。今回作った移行の仕組みは、後者を選ぶ場合の選択肢のひとつです（LIGはmicroCMSの公式パートナーです）。

まずは現状を拝見して、どちらの方向が合っているかをお伝えする無料診断をご用意しました。記事数やテーマ構成、カスタムフィールドやプラグインの使われ方などを確認し、次の2点をご提示します。

• WordPressのまま運用する場合に、優先して手を入れるべき箇所
• Jamstack構成へ移行する場合の、移行難易度と想定工数の目安

更新頻度が高く動的な機能が中心のサイトであれば、WordPressを使い続けたほうが合理的です。その場合は、アップデート運用の仕組み化や保守体制のご提案をします。

• 毎回のアップデート対応が負担になっている
• CMSの保守を担当できる人が社内に一人しかいない
• いまの構成のままで、どこまでリスクを下げられるか知りたい
• 見た目は変えずに、中身だけ入れ替えたい

上記のような状況に心当たりがあれば、お気軽にご相談ください。

無料でWordPressサイト診断を申し込む