この記事は Quickエンジニア Advent Calendar 2025 20日目 & microCMSでやってみた！AI活用からユースケースまで大募集 by microCMS Advent Calendar 2025 23日目の記事です
こんにちは、clipnoteです！
今年WordPressで管理していた記事をmicroCMSに移行する対応を行ったのですが、元から運用されていたWordPressが魔改造や自由な運用をされていたため、すんなりと移行が難しい状況でした。
そのような状況は他サービスでもあると思うため、どう移行を進めたかを残しておきます。
CMS移行することになった背景
新しいサイトを立ち上げるにあたり、既存メディア媒体の記事を移管し新しいサイトのコンテンツを拡充することで、新しいサイト内でサービス提供価値の伝達をしやすい状況をつくることになりました。
今回そのままWordPressを使用するのではなく、microCMS導入を決定した理由は下記2点です。
- 記事以外のコンテンツも管理可能
- フロント側の技術スタックが自由に選択でき、セキュリティリスクを下げられるヘッドレスCMS
他にも背景を満たすCMSはありましたが、システム運用含めトータルコストの削減ができ、日本語サポートがあるmicroCMSに決定しました。
どのような状況だったのか
WordPress魔改造については、
- 言われた要求そのままを実現するためにWordPressのAddQuicktagプラグインでHTML実装をしていた
- microCMSのカスタムクラスだけでは対応が難しい多層構造のQuicktagが複数あり
- 適切な要件定義がされていないように見受けられるところあり
- WordPressやプラグインのプログラムが直接修正されていたり、独自のカスタム関数が追加されていた
という状態でした。
自由な運用については、魔改造にも関係してくるのですが、使用する表現の意図や運用ルールが定まっておらず、編集者1個々人が好きなように記事を作成していた状態でした。
移行時に気をつけていたこと
下記2点です。
- 改めて要求や運用整理をする
- 記事移行をプログラムだけでやりきろうとしない
それぞれ細かく説明します！
改めて要求や運用整理をする
前段でも書いたとおり自由に開発・運用をされていたため、現状できていることや、記事作成などの業務に必要と思われている要求を整理しました。
以前と同じまま進めてしまうと、今後の開発や運用のコストが上がり続けることは目に見えていたためです。
特にmicroCMSのカスタムクラスだけでは対応が難しい多層構造のQuicktagが複数あり、何も考えずにそれを実現するためのカスタムフィールドをつくってしまうと、開発だけでなく記事自体の運用保守も大変になるため、どういう意図で必要なのかを編集者にヒアリング、すり合わせしながら要件や仕様を詰めました。
技術的にできるからと言ってカスタムフィールドを安易に追加するのではなく、リッチエディタで要求の実現できないかを考えることは、CMS運用観点で大事なポイントだと思います。
記事移行をプログラムだけでやりきろうとしない
WordPressからmicroCMSへの記事移行はWordPressからmicroCMSにコンテンツを移行するチュートリアル【実行編】で紹介されているサンプルコード（以降、「移行プログラム」とする）を修正したもので実施しました。
移行対象記事の中にはHTML構造が適切でないものもあり、そのまま移行すると表示が崩れる等のイレギュラーケースがありました。
それらイレギュラーケースを数回程度しか実行しない移行プログラムで正常移行できるように修正するのはコストが見合わないため、移行後の記事を確認していく段階で見つけたら修正をする方針で対応しました。
イレギュラーケースかそうでないかは、該当する構造がどれくらいあるか移行プログラムのsrc/libs/replace-content.jsでデバッグすれば件数は把握できます。
また、既存記事でページ内リンクしている部分は、一度microCMSに記事移行した後で遷移先のIDを把握し手作業で修正する必要があったため、その部分は必然的に手作業での修正となりました。
※後日談：その後、力技でページ内リンクを実現する方法をst1212が実装してくれていました
まとめ
記事移行は単なるデータ移行だけでなく、今後シンプルな開発・執筆・運用ができるように要求と運用を整理する絶好の機会です。
ここを逃すと見直し機会を確保するのは難しいと思うため、スコープが広がり対応期間も伸びますが対応することをおすすめします！
-
CMSで記事を執筆・監修する人 ↩