この記事を書いた人
- 大日 慧Webエンジニアリンググループ/フロントエンドエンジニア（ビジネス・アーキテクツ）
2021年に株式会社BAXSに入社。SaaS型ソフトウェア「PANAMA」のデザインや、フロントエンドの業務を経験し、経験値を積む。 2025年に会社が統合されてからは、お客様のサイトのオーサリングやサイトの保守・運用業務を行なっている。自分の持ち味をいかし、デザインもできるエンジニアを目指して日々勉強中。
「更新のたびに重い」「プラグインだらけで管理がつらい」「セキュリティが不安」。
WordPressを長く運用するなかで、こうした課題から別のCMSへの移行を考えることがあります。
そのとき気になるのが、「いまプラグインで動いている機能を、移行先でも再現できるのか」ということではないでしょうか。
Business Architects（ビジネス・アーキテクツ、以下BA）は、プラグインで作り込まれたWordPressサイトを含め、さまざまなサイトのPowerCMS Xへの移行を手がけてきました。
この記事では、その中の一つ、自社の社内向けオウンドメディアをWordPressからPowerCMS Xへ移行したプロジェクトを例に、何を既存の機能で賄い、何を作り、何を見送ったのかを紹介します。実際の移行で直面した難しさも含め、PowerCMS Xへの移行を検討する際の判断材料をお伝えします。
WordPress運用、こんな課題を抱えていませんか
WordPressは世界で最も使われているCMSのひとつで、豊富なプラグインを組み合わせれば、専門知識がなくても手軽にサイトを構築・運用できます。一方で、数年運用するうちに悩みが積み重なってきます。
管理するプラグインが増え、相性や本体バージョンとの互換性に気をつかう。アップデートのたびに「どこかが壊れないか」と不安になり、使われないプラグインがセキュリティ上の弱点にもなる。アクセスが増えると動作が重くなり、更新のやり方が特定の担当者に偏って属人化していく。
こうした悩みが積み重なると、別のCMSへの移行が視野に入ります。とはいえ、移行を検討するときに気になるのが、「いま動いているこの機能を、移行先でも実現できるのか」という点です。プラグインで動く機能が多いほど、この不安は大きくなります。この記事では、その不安に実際の移行経験からお答えします。
なぜ移行先にPowerCMS Xを選んだのか
今回の移行先に選んだのが「PowerCMS X」です。国内のCMSベンダーであるアルファサードが開発する国産CMSで、企業サイトやオウンドメディアなど、中〜大規模サイトの構築・運用を想定した製品です。テンプレートを自由に組める柔軟さと、ページを静的に書き出して公開できる仕組みを備えているのが特徴です。
移行先として選んだ決め手は、主に次の3点でした。
- 公開の安定性と安全性
ページをあらかじめHTMLとして書き出して公開する方式（静的パブリッシュ）に対応しているため、アクセスのたびにページを動的に生成する必要がありません。表示速度や安定した配信を重視するうえで、今回の要件に合っていました。 - テンプレートの自由度
テンプレートを柔軟に設計でき、既存のHTMLやデザインを活かしながらサイトを構築しやすいため、これまでの制作の工夫を移行後も引き継げます。 - 複数サイト・ドメインをひとつの管理画面で管理できること
PowerCMS Xは複数のサイト・ドメインに対応しており、サイトごとに管理画面を分けて運用できます。そのため、既存のサイト単位の管理体制を大きく変えずに移行できる点が、今回の要件に合っていました。
移行してわかった「できること・難しいこと」
WordPressで動いていた機能が、移行先でどうなったのか。今回の移行では、すべての機能を同じ方法で再現したわけではありません。PowerCMS Xの機能でそのまま賄えたものもあれば、自分たちで作り直したもの、優先度を考えて見送ったものもありました。
プラグイン機能は「賄う・作る・見送る」で整理する
WordPressで動く機能の多くは、プラグインが支えています。移行を考えるときの最初の不安は「このプラグインの機能を移行先でも再現できるのか」でしょう。
すべてが同じ形で移せるわけではありませんが、移行先での対応は大きく3つに分けて考えると整理できます。
- 移行先の標準機能や用意されたプラグインで賄えるもの
記事検索などがこれにあたり、比較的少ない手間で再現できます。 - 自分たちで設計して再現するもの
記事一覧の出し分けやパーツのブロック化がこれで、ひと手間かかるぶん、決まった型に縛られず要件どおりに作り込めます。 - 優先度を見て見送るもの
自作の手間が大きく必要度が高くない機能は、後のフェーズに回す判断も現実的です。
大切なのは「作れるか・作れないか」で考えないことです。今回扱った機能も、手間をかければ自作できるものはありました。本当に効いてくるのは、限られた時間の中で「何をいますぐ再現し、何を後回しにするか」という優先度の見極めです。
今回扱った主な機能をこの3つに当てはめると、次のようになりました。
ここからは、それぞれの機能をどのように実現し、どこに難しさがあったのかを具体的に紹介します。
ブロック機能の柔軟性：記事パーツを運用しやすい形で再構築できた
移行では、既存ページをそのまま移すだけでなく「移行を機に、その後の運用をどう楽にするか」まで考えて設計しました。その代表が記事パーツの「ブロック化」です。
ここでいうブロックとは、PowerCMS Xのブロックエディタ機能（記事を部品単位で組み立てる編集機能）で使う、再利用可能なパーツのことです。今回はデザイナーが既存記事を洗い出し、使用頻度が高く部品化しておくと便利なパーツを選んで整備しました。
移行するだけならHTMLをそのまま貼り付ける方法でも成立します。それでもあえてブロック化したのは、公開後の運用を見据えてのことです。ブロック化しておけば、記事作成のたびにHTMLを触る必要がなくなり、専門知識のない担当者でも記事を組み立てられます。この「誰でも記事を作れる状態にする」ことこそ、移行で最も重視した点でした。ブロックごとに余白（マージン）などの表示ルールを設定し、組み合わせてもレイアウトが崩れにくいよう設計しました。これにより、担当者がパーツを組み合わせるだけで、体裁の整った記事を作りやすくなりました。
一方で、大変だった点もあります。パーツのバリエーションが多く、進めるうちに「このパターンも必要では」と追加候補が出てきました。ここはすべてを一度に作り込まず、プロジェクトマネージャーと相談しながら、移行時にどこまで再現するかを切り分けて進めました。
表示設計の自由度：記事一覧や関連記事を要件どおりに実現できた
今回WordPressで利用していたプラグインでは、手早く機能を追加できる一方、表示の型があらかじめ決まっているものもあり、あとから「ここを変えたい」となったときに調整しにくい場面がありました。
PowerCMS Xでは、表示の出し分けを、テンプレートに専用の記述（テンプレートタグ）を書いて自分で組み立てます。正直、最初は慣れるまでが大変でした。ただ、慣れれば要件どおりに作れます。「新着順」「同じカテゴリ」「タグが一致」といった一般的な出し分けは、調べればすぐ実現できました。
一方、単純な条件では表せない出し分けには工夫が要ります。たとえば「おすすめ記事」のように人が選んだ記事を出したい場合です。これは、PowerCMS Xの標準機能「グループ」（複数の記事を手動でひとまとめにし、表示順も決められる仕組み）に表示したい記事を登録し、それを参照して表示しました。
決まった型に頼らず独自の見せ方まで作り込めるのが、自分で設計する方式の強みです。なお、テンプレートタグの記述を含む実装作業については、現在では生成AIを補助的に活用する選択肢もあります。詳しくは後半で紹介します。
プラグインの活用：記事検索を追加開発せずに再現できた
記事検索は、PowerCMS Xで標準的に提供されている検索用プラグイン（全文検索の仕組み）を使いました。一から自前で開発せず、用意されたプラグインを土台にできたのは助かった点です。
さらに良かったのは、検索結果の画面を自分たちのデザインどおりに作れたことです。今回WordPressで利用していた検索プラグインでは、検索結果の見た目を調整しにくい部分がありました。PowerCMS Xでは表示部分（ビュー）を自分で組めるため、サイトに合わせた検索結果ページを比較的自由に実現できました。
ただし、すんなり動いたわけではありません。検索対象の記事がうまく登録されず結果が出てこない、といったつまずきもありました。プラグインが用意されていても、思いどおり動かすまでには調べながらの試行錯誤が必要だった、というのが正直なところです。
用意されたプラグインを土台にしながら、必要な部分は自分たちで調整する。こうした切り分けも、移行を現実的に進めるうえでは重要です。
自作に伴う実装負荷：いいね・人気記事機能は移行を見送った
すべての機能をそのまま移せるわけではありません。実際に見送ると判断したのが、記事への「いいね」と、それを集計して人気記事を表示する機能でした。
WordPressではプラグインで手軽に実現できていましたが、当時PowerCMS X側に該当するプラグインが見当たらず、いいねの記録・集計・活用を一から設計・実装する必要がありました。自作自体は可能です。ただ、社内に当時の実装者が在籍しておらず、プロジェクトにも遅れが出ていて、調査だけで10時間ほどを要し、完成までの工数が見通しにくい状況でした。
最終的に、調査結果をもとにプロジェクトマネージャーと相談し、「公開にあたって最優先で移行すべき機能ではない」と判断。いいね機能は次フェーズであらためて実装する方針とし、現時点では見送っています。
ポイントは、作れるか作れないかではなく、限られた時間で「何をいますぐ移し、何を後回しにするか」を見極めたことです。優先度をつけて段階的に移行する。これが、限られた期間で移行を進めるうえで欠かせない現場の判断です。
難しさをどう乗り越えるか。そして、いま挑むなら
今回の移行を振り返ると、難しかったのはPowerCMS Xで機能を実装することだけではありませんでした。WordPressで使っていた機能を一つずつ整理し、PowerCMS Xの標準機能やプラグインで賄えるのか、自分たちで作り直す必要があるのか、あるいは移行時には見送るのかを判断する。そのための調査や検証にも、多くの時間を使いました。
特に、PowerCMS Xでの実現方法がすぐに分からない機能については、ドキュメントを調べたり、実際にテンプレートを書いて試したり、社内の詳しいメンバーに相談したりしながら、一つずつ実現可能性を確かめていく必要がありました。
こうした経験から、移行では「作れるかどうか」だけでなく、限られた期間の中で、どこまで調査・検証し、何を移行対象とするかを判断することが重要だと分かりました。
そして、今回の移行を行った当時と現在では、この調査や検証の進め方も変わっています。その大きな変化の一つが、生成AIの活用です。もし今回と同じ移行をいま行うなら、当時人手で行っていた調査や実装の一部には、生成AIを活用できると考えています。
生成AIは移行にどう効くか：設計の検証と下書きづくりを助ける
当時は、生成AIを実務で使える環境がまだ整っておらず、PowerCMS Xで実現方法が分からない機能があるたびに、ドキュメントを調べ、テンプレートタグの書き方を試し、社内の詳しいメンバーにも相談しながら実装方法を探っていました。現在であれば、こうした工程の一部に生成AIを活用できます。
たとえば、「WordPressではこのように実現している機能を、PowerCMS Xではどう設計できるか」といった実現方法の整理や、テンプレートタグを使った実装の下書き、書いたコードの確認などです。生成AIを調査や検証の補助として使うことで、ゼロから調べて試していた工程を効率化できます。
実際に現在のBAでも、調査や実装、検証など、さまざまな業務に生成AIを取り入れています。
ただし、生成AIが設計や判断のすべてを代わりに担えるわけではありません。「何を作り、何を見送るか」を決め、出力が正しいかを見極めるのは人の役割です。むしろ生成AIを活かすほど、要件を整理し、優先度を判断できる人の重要性は増します。一方で、実装方法を調べたり下書きを作ったりするハードルは下がり、以前よりも「自分で作る」部分に挑戦しやすくなっています。
まとめ：PowerCMS Xへの移行が向いているのは
WordPressを長く運用するなかで、次のような課題を感じている場合は、PowerCMS Xへの移行を検討するタイミングかもしれません。
- プラグインが増え、管理やアップデート、互換性の確認が負担になっている
- セキュリティや安定したサイト運用に不安がある
- プラグインなど既存の仕組みに合わせるのではなく、自社の要件に合わせて機能や表示を設計したい
- CMSの移行を機に、記事制作など日々の運用方法も見直したい
一方で、WordPressでプラグインに任せていた機能が、PowerCMS Xでもそのまま使えるとは限りません。標準機能やプラグインで賄えるものもあれば、自分たちで作り直す必要があるもの、実装にかかる工数や優先度を考えて見送るものもあります。
だからこそ、すべての機能をそのまま移そうとするのではなく、「何を既存の機能で賄い、何を自分たちで作り、何を見送るか」を整理し、優先度をつけて段階的に進めることが重要です。
BAでは、実際の移行プロジェクトで、現在のサイトや機能を整理しながら、この切り分けを行ってきました。こうした経験があるからこそ、単にCMSを移し替えるだけでなく、実現方法や工数、移行後の運用まで見据えた、現実的な移行プランをご提案できます。
「いま使っている機能をPowerCMS Xで再現できるのか」
「どこまで移行時に対応すべきか」
といった段階からでもご相談いただけます。まずは現在のサイトや運用上の課題を整理し、PowerCMS Xで何を再現し、何を見直すのかというところから、一緒に考えていきます。