WordPressの移行圧力が高まっている

WordPressの保守費や更新対応の工数が、CMS移行の理由になっています。他CMSでは記事データのインポートに加え、既存データの調査や変換プログラムの開発を支援する機能も増えています。

移行にはデータ変換や独自機能の再実装、動作検証が必要です。その範囲を特定するためにも、インポート機能や移行支援を使い、実際のデータで検証を始めることが有効です。対応できる部分と追加開発が必要な部分を分ければ、移行予算と工期を具体化できます。

WordPressの継続利用が見直されている

2026年11月5日時点の市場統計と、企業サイト・メディアの公開事例を確認しました。

CMSシェアは1年で2.3ポイント低下

W3Techsによると、CMSを判別できたサイトに占めるWordPressの割合は、2025年11月1日の60.5%から、2026年11月4日の58.2%へ低下しています。同期間にShopifyは6.8%から7.9%、Wixは5.7%から6.1%に上昇しました。^[1]

図1：2025年11月〜2026年11月の各月1日。縦軸は55〜65%に拡大しています。シェアは採用比率を示す数値で、既存サイトの移行件数とは区別します。出典：W3Techs。^[1]

保守と更新の負担が移行理由になる

一休のコーポレートサイトでは、脆弱性についてセキュリティ部門から指摘を受けていました。保守予算の追加確保が難しく、軽微なデザイン修正にもエンジニアの対応が必要だったといいます。Studioの導入事例によると、移行後は非エンジニアでも制作・更新ができるようになりました。^[4]

2026年7月には、WordPress本体の特定バージョンで、外部からコードを実行される脆弱性が公表されました。修正版が公開され、対象バージョンには強制自動更新も有効化されました。運用側では、修正版の適用状況を確認する対応が必要になりました。^[3]

他CMSのインポート機能から、移行先を検討する

インポートの対応範囲はCMSごとに異なる

WordPress専用のインポート機能に加え、サードパーティ製アプリやCSV経由でデータを移行する方法もあります。各ツールの対応範囲を確認すると、インポートできるデータと、個別の変換・再実装が必要な機能を区分できます。

図3：専用インポート機能、サードパーティ製アプリ、データモデルの設計・変換支援による移行方法。

減らしたい保守から、移行後の構成を選ぶ

移行先を選ぶ際は、現在の保守のどの作業を減らしたいかを先に整理します。公開サイトまでサービス側で管理する構成と、フロントエンドを自社で運用する構成では、開発者が担当する範囲が変わります。

移行後の保守対象は、採用するシステム構成によって変わります。LooopのmicroCMS導入では、フロントエンド（公開サイトの表示・操作部分）にNext.js、ホスティングにAWS Amplifyを採用しています。コンテンツ管理とフロントエンドを別々に運用する構成です。^[18]

将来、別のCMSへ移行する際のデータ取得条件も異なります。StudioにはCMSデータなどのエクスポート機能がありません。Webflowではソースコードをエクスポートできますが、CMSのデータや機能は含まれません。microCMSではコンテンツをCSVでエクスポートできます。^[19][20][21]

AIによる移行支援は、データモデルの設計や変換処理の開発にも広がる

データモデルの設計と変換スクリプトの生成を支援する

microCMSの公式ブログに掲載された2024年の移行チュートリアルでは、投稿データと画像を個別に取得し、記事・カテゴリ・タグを管理するAPIを定義する手順が示されています。画像を再アップロードして参照URLを更新し、記事データを登録するスクリプトも実装する必要がありました。^[23]

2026年11月4日には、microCMSからWordPress移行用のAgent Skillが公開されました。AIエージェントに移行作業の手順を与え、既存サイトのデータモデルの調査から、移行先CMSの設計・データ登録・検証までを進める機能です。^[15]

投稿タイプやカスタムフィールドを調査し、移行先CMSのデータモデルを提案します。データモデルは、投稿の種類や入力項目、カテゴリなどとの参照関係を定義したものです。移行計画の承認後は、AIエージェントが変換スクリプトを生成し、登録件数やデータの整合性を検証します。変換できなかった項目のレポートや、旧URLと新URLの対応表も作成できます。^[15]

従来の手順で開発者が担当していたデータ調査、移行先のデータモデル設計、変換ロジックの実装まで、AIによる移行支援の対象が広がっています。既定のインポート仕様に合わせてデータを変換する工程に加え、移行先CMSの投稿タイプ・フィールド・参照関係を設計する段階からAIエージェントを利用できます。

ClaudeとMCPを利用したWebflowへの移行事例

Webflowが公開したArkose Labsの事例では、WordPressのエクスポートデータをClaudeに渡し、MCP経由でコンテンツ移行やSEO要件の整理を進めています。MCPは、AIから外部サービスの機能を呼び出すための接続仕様です。同社は、契約から3週間半で新サイトを公開したと報告しています。^[16]

事前調査で既存のデータモデルと未対応項目を特定できれば、追加開発の範囲を明確にできます。エンジニアにとっては移行処理の実装範囲を、決裁者にとっては移行予算と工期を検討する材料になります。

データ変換と独自機能の置換を分けて、移行範囲を絞る

ショートコードの表示機能は、そのまま移行できない

WordPressから記事データをXMLでエクスポートできても、テーマやプラグインで実装した表示・編集機能を、移行先でどう再現するかは別途設計が必要です。^[7]

ショートコードは、本文中の短い記法をWordPress側で処理し、ギャラリーや動画などを表示する機能です。本文をコピーしても、その処理は移行されません。生成済みのHTMLを保存する方法と、移行先CMSで編集できるコンポーネントとして再実装する方法では、開発工数も移行後の編集方法も変わります。^[22]

図2：記事データのインポートと、既存機能の再実装を分けて整理する。^[7][6]

LIGは記事データの変換スクリプトを開発した

LIGの移行検証では、実際の記事224本を使い、本文のHTMLをmicroCMSで管理するコンテンツブロックへ変換しています。見出し・画像・吹き出しなどの種類ごとに変換処理を実装しました。吹き出し内のマーカーを含むHTMLの変換が途中で途切れたり、比較表を人物紹介の表として処理したりする不具合があったと報告しています。^[6]

変換スクリプトの完成後、224本の記事を登録する処理には約120分かかりました。開発段階では、記事内のHTMLを解析し、変換ロジックを実装する作業に苦労しています。未対応のHTMLは削除せずに保持し、独自の装飾などを後から個別に修正できる設計にしています。^[6]

同社は、サイトごとに本文の形式やカスタムフィールド（独自に追加した入力項目）の使い方が異なるため、移行工数の見積もりに幅が生じると説明しています。継続利用と移行の費用を同じ精度で比較できるよう、約1か月かけて移行処理を検証しました。^[5]

記事数だけでは、データ変換と機能の再実装に必要な工数は見積もれません。独自実装への依存は移行コストを高めるため、現在も必要な機能を選び、移行先の標準機能に置き換えられるかを確認します。代表的な記事で変換を検証すれば、追加開発が必要な形式や機能を洗い出し、見積もりの前提を具体化できます。

移行支援を使い、実データで移行範囲を確かめる

保守費用や更新対応の工数に加え、他CMSのインポート機能とAIによる移行支援の拡充が、WordPressからの移行圧力を高めています。移行作業を補助するだけでなく、追加開発が必要な項目を特定する手段も増えています。

次のリニューアルや保守契約の更新に向けては、移行先の検証を計画に入れます。代表的な記事と独自の入力項目を含むデータを取り込み、表示・編集・URLを確認する。標準機能で対応できる部分と、変換や再実装が必要な部分を分ければ、開発費用と工期を検討できます。

保守負担を減らすために移行するなら、現在の構成をそのまま再現する前に、必要な機能を絞ることも有効です。移行後に減らせる保守と実現したい運用を具体化し、そのために必要な移行作業へ予算と工数を割り当てます。