WordPressを続けるべきか、Studio・Astro・microCMS・EmDash・Storyblokなどへ移行すべきか。海外企業の移行事例をもとに、更新権限、SEO、移行費用、保守体制から判断する方法を解説します。
WordPressで作った会社のホームページを、何年もそのまま使っている。ある日、サーバー会社からPHPの更新を求められたり、プラグインの脆弱性が見つかったりする。制作会社に相談すると、更新にも調査にも費用がかかると言われる。
そんなとき、「WordPressを使い続ける以外に方法はないのだろうか」と考えるのは自然なことです。
ただし、WordPressから別の仕組みに移せば、管理の問題がすべて解決するわけではありません。 乗り換え先によって、社員が編集できる範囲、制作会社の仕事、毎月の費用、将来の移行のしやすさが変わります。
この記事では、WordPressを続ける選択肢も含め、国内外の実例を確かめながら、企業サイトの運営体制から移行先を選ぶ方法を整理します。
1. WordPressから「乗り換えたい」のは、何を解決したいから?
移行先を調べる前に、今のサイトで困っていることを分けてみましょう。
古いPHP・プラグインの更新が難しい
使用しているテーマや拡張機能が新しい環境に対応しておらず、安全な更新に調査や改修が必要になっている。
お知らせを直すだけなのに制作会社へ依頼する
社員が更新できる場所が少なく、テキストや画像の変更にも待ち時間と外部委託費が発生する。
誰が何を変更したのか、責任が曖昧
社内で管理者権限を共有していたり、制作会社の管理範囲と社員の更新範囲が決まっていなかったりする。
問題が更新操作だけなら、WordPressの権限設計や運用ルールを見直すだけで改善することもあります。複雑な独自機能を多く使っている場合、乗り換えは新規制作と同じくらい大きな仕事になるかもしれません。
「WordPressか、それ以外か」ではなく、どの仕事を自社に残し、どの仕事を外部に任せるかから考えることが重要です。
WordPressを維持した場合の作業範囲は、先に公開したWordPressサイトの保守と納品後の責任で詳しく整理しています。
2. WordPress以外の移行先は、主に6つのタイプがある
CMSは、記事や画像を更新するための管理システムです。すべての会社に、WordPressのような多機能CMSが必要なわけではありません。
Studio
会社案内やサービス紹介を中心に、非技術者がページや記事を更新したい。
デザイン・ホスティング・CMSが一体。手離れはよい一方、サイトやCMSデータを他の仕組みに一括書き出しする標準機能には制約がある。
Astro + Cloudflare Pages
更新が少なく、原稿や変更内容を制作会社へ渡す運用で問題ない。
CMSなしの構成では、社員が管理画面から記事を更新する機能は別途用意する必要がある。
Astro + Decap CMS・Keystatic
記事更新とGitHubでの変更履歴・レビューを結び付けたい。
DecapにはPRを利用する編集ワークフローがある。KeystaticのGitHubモードは編集者にリポジトリの書き込み権限が必要で、組織の権限設計を確認したい。
Astro + microCMS
日本語の管理画面を使い、複数の担当者で記事や採用情報を継続的に更新する。
表示側のサイトは別に構築する。WordPressからのデータ移行も、項目設計やCSV・APIを使った変換が基本。
EmDash + Cloudflare
記事の編集画面を持ちながら、AstroのデザインやAI連携を自社サイト向けに柔軟に構築したい。
Workers・D1・R2などの運用、EmDash本体の更新、バックアップ、権限設定は管理者の責任。新しいCMSなので実運用の検証が欠かせない。
Storyblok・Contentful + フロントエンド
部署・ブランド・国ごとに多数のページを管理し、共通部品と承認体制を整えたい。
編集権限や環境の分離を設計できる反面、コンテンツモデルの設計・制作体制・利用料金の検討が必要。
ここでいう「ヘッドレスCMS」は、記事・画像などを管理する仕組みと、閲覧者に見せる画面を分ける構成のことです。企業側が扱う更新画面と、制作会社が修正するデザイン・機能を分離しやすい一方、両者をつなぐ開発と運用は必要です。
例えばStudioはWordPressのXMLデータを取り込めますが、既存サイトの見た目や機能がそのまま移るわけではありません。またサイト全体・CMSデータのエクスポートには制約があります。「管理が簡単」というメリットと「将来の移行のしやすさ」は別の評価軸です。
Gitベースの管理についても、Decap CMSの編集ワークフローとKeystaticのGitHubモードでは、レビューや権限の前提が異なります。製品名だけでなく、誰が公開ボタンを押せるのかまで確認しましょう。
3. 海外ではWordPressからどんな形で移行している?
海外の導入事例を見ると、単にCMSを新しくしたのではなく、「社員が更新できる範囲を広げ、サイトの構造は技術チームが管理する」という役割分担が共通しています。
以下はいずれも製品提供企業が公開した事例です。掲載されている数値は各社の報告であり、CMS変更だけによる成果だと断定できるものではありません。
Guild:1,000ページ超をWordPressからStoryblokへ
Guildは、従来のヘッドレスWordPress構成が拡張や運営の障害になっていたと説明しています。移行に際して、社内で必要な機能を整理し、外部パートナーとページの構造を再設計。Storyblokの発表によると1,000ページ以上を移行し、27の再利用可能なモジュールを整備。公開後のエンゲージメント率は前年比42%改善したと報告しています。
学べること: WordPressをやめるだけでなく、ページを部品化して、非技術者の編集とデザイン統制を両立させている点。
Ponant:コンテンツ更新の約80%をマーケティング部門へ
クルーズ事業を手がけるPonantは、WordPressからStoryblokへの移行を通じて、各地域のコンテンツ更新をマーケティング部門で担う体制に変更。Storyblokの事例では、更新対象コンテンツの約80%をマーケティング側で管理し、制作や公開にかかる時間が短縮されたと説明されています。
学べること: 社員にプログラムを変更する権限を与えるのではなく、あらかじめ用意した編集範囲を社員に任せ、機能や部品の開発は技術側に残している点。
konversionsKRAFT:編集の自由とブランドの統一を両立
konversionsKRAFTは、記事が多いWordPressサイトをStoryblokに移行。SEO資産を維持しながら、編集担当者が開発者に頼らずランディングページを作れるよう、再利用可能な部品とテンプレートを構築しました。事例で示された実装期間は3か月です。
学べること: 「誰でも自由にレイアウトを変えられる」よりも「決められたデザインの範囲でページを組み立てられる」ことが、企業運営に役立つ点。
Avatria:WordPressの記事をContentfulへ段階的に移行
Avatriaは、WordPressから書き出したXMLをPythonで読み取り、新しいContentfulのコンテンツ構造へ変換する工程を公開しています。画像などは自動化せず手作業とし、最初から大量移行するのではなく、まず1件を試して問題を確認する方法を勧めています。
学べること: 自動インポートがあっても、文章の構造、画像、関連リンク、SEO項目まで完全に移行できるとは限らない点。
国内でも、LooopがWordPressからmicroCMSへ移行した事例があります。従来は外部ベンダーへの依頼が必要だったコンテンツ更新を内製化し、外部委託の頻度が半分以下になったと報告しています。海外事例と同じく、移行先の技術より、更新業務の設計を変えたことに注目したい事例です。
これらの事例は、主に一定規模の企業が自社またはパートナーの開発体制を持って行った移行です。小規模な会社が同じ製品を導入すれば同じ成果が得られる、という意味ではありません。
4. EmDashはWordPressの乗り換え先になる?
EmDashは、AstroにCMS機能を組み込める比較的新しいオープンソース製品です。Cloudflare Workers上で実行する場合は、一般にD1をデータベース、R2を画像などの保存先として使います。
WordPress向けのインポート機能があり、投稿・固定ページ・分類・画像などを取り込む方法が公式ドキュメントに示されています。ただし、WordPressのテーマやプラグインの動きをそのまま再現する機能ではありません。 ページビルダーや独自ショートコード、サーバー上で生成していたブロックなどは、別途の再構築が必要です。
コンテンツ管理とサイト制作を分けられる
社員が編集画面から記事を作り、制作会社はAstroのレイアウトや機能を管理する。EmDashにはContributor(下書き作成・自分の下書きの修正)、Editor(全体の編集・公開)、Admin(設定やユーザー管理)などの役割があります。
Cloudflareに置いても「保守ゼロ」にはならない
CMSと依存パッケージの更新、データベース変更、バックアップ、アカウント管理、障害対応が残ります。公開運用前にはテスト環境で更新・復旧まで確認する必要があります。
特に企業では、ContributorとAuthorを混同しないことが重要です。EmDashの標準設定ではAuthorは自分の記事を公開できます。公開承認を必須にしたい場合、一般社員の権限はContributorなどに制限し、公開権限を持つ担当者を明確にする必要があります。詳しくはEmDashの権限一覧を参照してください。
現時点ではEmDashをWordPressの全面的な代替と決めつけず、まずは小規模な企業サイトの複製で編集・権限・移行・復元を試すのが現実的です。前節の海外事例は主にStoryblokとContentfulへの移行であり、EmDashで同じ成果が検証された事例ではありません。
5. 社員全員がAIでサイトを編集する必要はない
企業向けのWebサイトで大切なのは、AIの利用者数ではなく、各担当者が変更できる範囲を限定することです。
- 一般社員・現場担当者
必要な文章や画像を用意し、CMSで下書きを作る。AIは文章の整理などに利用してもよいが、本番反映の権限は持たない。
- 広報・Web責任者
事実関係、表現、画像の権利、リンク先などを確認し、公開を承認する。
- 制作会社・開発担当者
デザインの部品、フォーム、システムやCMSの更新などをGitHubのレビューとテストを通じて変更する。
- インフラ管理者
Cloudflareなどのアクセス権、秘密情報、監視、バックアップ、復旧、請求・契約の管理を担当する。
一人が複数の役割を兼ねることはあります。ただし、「誰が提案できるか」と「誰が公開を許可できるか」は分けることを基本にしましょう。
これはEmDashに限りません。Studio、microCMS、Storyblokなども、製品・契約プランに応じて権限やレビュー機能を確認する必要があります。CMSが承認フローを持たない構成なら、社内のチェック体制やGitHubのレビューを別に設計します。
6. 乗り換え費用は、制作費だけで比較しない
「WordPressの保守費用をなくしたい」という理由で乗り換える場合ほど、移行後の3年間に何が必要になるかを確認したいところです。
- 最初の再制作
デザイン・テンプレート・フォーム・ページ構造を作り直す費用。
- 記事と画像の移行
XML・CSV・APIでの移行、手作業の修正、リンク・画像の確認。
- CMS・配信の利用料
CMSのプラン、Cloudflareなどの利用量、外部サービスとの連携費用。
- 運用保守と更新
依存ライブラリ更新、セキュリティ、監視、復旧、更新担当者の作業時間。
- SEO・計測の引き継ぎ
URL変更時の301リダイレクト、canonical、構造化データ、GA4・Search Consoleなど。
- 次の乗り換えのしやすさ
データを書き出せるか、独自機能が特定のサービスに依存しすぎていないか。
単純な比較式は、初期移行費用 + 毎月の利用料・保守費用×36か月 + 想定される追加改修費用です。そこに、社内担当者が更新・確認に使う時間も加えると判断しやすくなります。
Cloudflareで運用するから安い、という結論にはなりません。Cloudflareのインフラ料金が小さくても、システムを管理する人の仕事が不要になるわけではないからです。
7. 移行する前に確認しておきたいチェックシート
次の7項目を確認すると、制作会社へ見積もりを依頼する際にも、比較すべき条件を揃えやすくなります。
乗り換え前の7つの確認
チェック結果はこのページの表示中だけ利用し、保存・送信しません。
移行後すぐに旧WordPressを削除せず、表示・画像・問い合わせ・検索インデックスなどを検証してから切り替えましょう。とくにWordPressの独自ブロックや画像の参照先は、移行できた記事数だけでは確認できない部分です。EmDashの移行ガイドでも、元のサイトを残して検証し、変更したURLのリダイレクトを準備することが勧められています。
8. 結局、WordPressを続けるべきか、乗り換えるべきか
どの製品が新しいかより、移行によって運営上の問題を減らせるかで判断しましょう。
- WordPressを継続する方がよい場合: 既存の独自機能が多く、現在の管理体制を整えるだけで問題を解決できる。移行費用が運用上のメリットを上回る。
- CMSなしのAstroなどが向く場合: 更新は少なく、社内で自由にページを増やす必要がない。変更は制作会社にまとめて依頼できる。
- Studio・microCMSなどが向く場合: 社員の更新頻度が高い。文章・画像の変更を社内で完結させたい。
- EmDash・Storyblok・Contentfulなどを検討する場合: 更新画面とサイトの設計を分けたい。権限や承認、複数のコンテンツ種類を設計・維持する担当者がいる。
海外事例で注目すべきことは、「WordPressからどのCMSへ乗り換えたか」という結果だけではありません。何を社員に任せ、何を制作会社の管理下に残すかを整理し直していることです。
Webサイトを作り直す前に、更新する人、承認する人、障害時に対応する人を決めておく。そうすれば、WordPressを続ける場合でも、乗り換える場合でも、現実的な選択をしやすくなります。
本記事は2026年10月30日時点の公開情報と、各CMS提供元が掲載する移行事例に基づく一般的な解説です。製品機能・料金・利用条件、移行事例の数値は変更される場合があります。製品の効果を保証するものではありません。
- Storyblok:GuildのWordPress移行事例 ↗
- Storyblok:PonantのWordPress移行事例 ↗
- Storyblok:konversionsKRAFTの移行事例 ↗
- Contentful:AvatriaのWordPress移行の実装記録 ↗
- microCMS:LooopのWordPress移行事例 ↗
- Studio:WordPressからのCMSデータ取り込み ↗
- Studio:サイトデータのエクスポート制限 ↗
- microCMS:CMS移行時のデータ投入方法 ↗
- EmDash:WordPressからの移行ガイド ↗
- EmDash:ユーザー権限と公開 ↗
- EmDash:Cloudflareへのデプロイ ↗
- Decap CMS:Editorial Workflows ↗
- Keystatic:GitHubモード ↗
サービスの機能・名称・画面表示は変わる場合があります。実際の操作前に最新の公式情報をご確認ください。