新卒エンジニアのぱっちょです。
今回は、CMSのCの字もわからなかった自分が、WordPressからmicroCMSへ引っ越す仕組みづくりのプロジェクトにアサインされた話をお届けします。実際に記事224本を移してみて、何につまずき、どう対処したのかを新卒目線でまとめました。
プロジェクトの背景
2026年7月、WordPressコアに深刻な脆弱性が見つかったこともあり、「このままWordPressを使い続けて大丈夫か」というご相談が増えました。その判断材料として、WordPress継続とmicroCMSへの移行、それぞれにかかる工数を同じ精度で比較できるようにしようというプロジェクトが立ち上がり、そこに新卒の自分がアサインされました。
体制はエンジニア4人チーム。検証の題材は、このLIGブログ自身です。詳しい背景や、WordPress継続とJamstack移行の比較については、先輩のにっしーさんの記事にまとめられているので、気になる方はそちらもあわせてどうぞ。 LIGブログをmicroCMSに移管できるか検証してみた
Yuya Nishizawa
この記事では、にっしーさんの記事で紹介されている移行の仕組みを実際に224本の記事に対して動かしてみて、何がうまくいき、何につまずいたのかを新卒目線でご紹介します。
記事を「構造ごと」引っ越す仕組みを作った
作ったのは、一言でいうと「WordPressの記事を、構造ごと microCMSに運び込む仕組み」です。
この構造ごとが記事のキモなのですが、正直、最初は「コピペじゃダメなの？」と思っていました。
WordPressとmicroCMSでは、記事の持ち方がそもそも違います。WordPressが本文をひとかたまりで持っているのに対し、microCMSは見出し・段落・画像・吹き出し・CTA……といったブロックを積み重ねて記事を作る仕組みです。つまり、ただコピペするだけでは移りません。
1本のHTMLを解析して、microCMSのブロックに分解し直す。ここが、この仕組みの一番の仕事です。
▲全体構成図（WP→スクリプト→microCMS→Vercel／Next.js）
- 💡 WordPress → microCMS移行の手順
-
- 抽出：WordPressのエクスポートデータから記事を取得
- 変換・マッピング：1本のHTMLをmicroCMSのブロックに分解し、著者・カテゴリーなどを対応づけ（一番苦労してスクリプト化した工程）
- 投入：1コマンドでmicroCMSへ登録。マスタ作成・画像アップロード・公開まで（スクリプトが自動でやってくれる）
- 表示：Vercel上のNext.jsフロントで表示
- 差分チェック：元記事と見比べて崩れを補正
実際の移行は、上記の5ステップで進みます。2と3は基本、今回作成したスクリプトが自動でやってくれます。
なお、移行した記事を表示するフロントは、今回はNext.jsで構築しました。microCMSはAPIでデータを返す仕組みなので、フロントの技術は自由に選べます。
自動で移行できるもの
スクリプトが自動で運んでくれるのは、こんなデータです。
- 記事本文（ブロックに分解して）
- 著者/カテゴリー/タグ
- アイキャッチ画像（＋本文中の画像も。microCMSにアップし直してURLを差し替え）
- 公開日（元記事の日付をそのまま引き継ぎ）
- SEO情報（メタタイトル・ディスクリプション）など
つまり、記事コンテンツの本体はほぼ丸ごと自動で移行できる、ということになります。
そして、作りながら特に大事だと思ったのが取りこぼしゼロの設計です。どのブロックにも当てはまらないHTMLは、必ず「リッチテキスト」ブロックとしてそのまま残す。変換しきれなくても、中身が消えることはありません。
受け皿になるmicroCMSの設計について
移行先であるmicroCMS側の設計（スキーマ）にも、少しだけ触れておきます。
ポイントは、WordPressの構造をそのまま写さないことです。最初は「そのまま再現するのが正解じゃないの？」と思っていたのですが、長年運用したWordPressは、プラグインや歴代担当者の工夫で、構造がどうしても入り組んできます。それを忠実に再現すると、引っ越し先にまで負債を持ち込むことになるんです。
そこで今回は、「移行後にどう運用したいか」から逆算して、記事・著者・カテゴリー・タグなどをそれぞれ独立したAPIとして設計し直しました。
▲microCMS管理画面
いざ、LIGブログの記事224本を移してみた
今回移したのは、LIGブログの記事224本です。2026年7月10日時点の最新記事から順に持ってきただけで、記事の選別はしていません。画像が多い記事も、表や吹き出しが入り組んだ記事も、独自ショートコードが残った記事も、そのまま含まれています。
1. 抽出
まずは「抽出」。WordPressのエクスポートデータをスクリプトに食わせて、記事データを取得します。ここは機械的な処理なので、特につまずきはありませんでした。
2. 変換・マッピング
1本のHTMLを読み取って、見出し・画像・吹き出し……と、microCMSのブロックに分解していきます。今でこそスクリプトが自動でやってくれますが、そこまで持っていくのが一番大変でした。開発中の画面はかなり地味で、そして、いちばん手こずったのもここでした。
最初に試したのは、吹き出しが大量に出てくる対談記事。
フキダシの中に黄色マーカーが入ってるとやっかい。
上記のように吹き出しの中に黄色マーカーが入れ子になっている箇所で、変換が途中でぶつ切りになりました。
ほかにも、見た目はそっくりなのに役割が違う「比較表」と「人物紹介の表」を取り違えたり。どれも、実データを流してみて初めて気づく落とし穴です。
そこから「1記事で試す→直す」を何度も往復して、ようやくどの記事もきれいにブロックへ落ちるようになりました。
3. 投入
変換が通ったら、いよいよ投入です。やることは本当に、ターミナルでコマンドを1行打つだけです。
kuroda_haruka@RM20260401-03 wp-to-microcms % node migrate.js --ids 681305 対象: 1記事(下書き) ── ⓪ microCMS の既存メディアを取得 ⚠ メディア一覧がレート制限。15秒待って再試行 (1/5) 既存メディア: 1881種類のファイル名 同名で流用禁止のファイル名: 39種類 ── ① マスタ確保(著者・カテゴリ・タグ) WPからプロフィール文を取得: 563人分 WPからカテゴリ階層を取得: 98件 author: 作成 0 / 更新 1 article-category: 作成 0 / 更新 3 article-tag: 対象なし series: すべて登録済み(1件) ── 681305 "思いつきが商品になる"プラットフォーム「BUZZMADE」 ② 画像 本文画像: 22枚(残り 0枚をアップロード) アイキャッチ: アップ済みのためスキップ ③ 記事 ✓ 記事を更新 完了。 ※ 記事は下書きで入稿しています。全記事投入後、公開する際は --publish を付けて再実行してください(publishedAt も設定されます)。
実行すると、ログが流れ始めます。著者・カテゴリー・タグのマスタを用意し、画像をアップロードし、記事を作成して公開まで。これを全部、1コマンドが順にこなしていきます。
224本で、かかった時間は約120分でした。
microCMSの管理画面を開くと、さっきまでWordPressにあった記事が、ずらっと並んでいました。
▲スクリプト実行後のmicroCMSの記事一覧
正直、ちょっと拍子抜けするくらい、あっさり終わりました。1本ずつ開くと、本文がちゃんとブロックに分かれていて、アイキャッチも著者もカテゴリーも、勝手に紐づいています。これを手で1本ずつコピペしていたら何日かかったんだろう……と考えると、少しゾッとします。
4〜5. 表示・差分チェック
とはいえ、管理画面に入っただけでは「移せた」とは言えません。読者が見るのはサイト側です。そこで今回構築したフロントで、同じ記事を表示してみました。WordPressの元記事と、microCMS移行後の記事を並べたのがこちらです。
▲左=WP元記事/右=microCMS移行後
パッと見、ほぼ同じです。少なくとも「別物になっちゃった」感はありません。厳密に見比べた結果はこうでした。
- そのまま移ったもの
-
- 本文のテキスト/見出し/リスト
- 画像（本文中/アイキャッチ）
- 著者/カテゴリー/タグ/公開日
- 吹き出し/CTA/比較表/コードなどよく使う装飾
- ズレたもの
-
- テーマ独自の装飾（マーカーなど）の見た目
- 昔の独自のショートコード
- 一部の凝ったレイアウト
再現率でいうと、だいたい80〜90%。”だいたい”なのは、記事のクセによって上下するからです。ただし、ズレたからといって中身が消えるわけではありません。変換しきれなかった部分も、そのまま記事に残るように作ってあります。では、その「残り10〜20%」で何が起きていたのか。次の章でお伝えします。
うまくいかなかったところ・工夫したところ
前章で書いたとおり、10〜20%はそのままでは移りませんでした。何にぶつかって、どう対処したのか。まとめるとこうなります。
| うまくいかなかったこと | 対策 |
|---|---|
| テーマ独自CSSの装飾は、データは移るが見た目が消える | 中身のデータは必ず残し、見た目はフロント側で当て直す領域と割り切る |
| 独自ショートコードは展開されず、そのまま残る | 勝手に解釈せず、原文のまま保持。あとから個別に対応できる状態にする |
| カテゴリの親子関係や独自項目の対応づけが、機械的には決まらない | 「移行後にどう運用したいか」から逆算して、人が設計判断する |
| 大きすぎる画像・取得できない画像・飛ばなくなるリンクなど、例外が必ず出る | 実行時に自動でリストに書き出し、人が1つずつ潰せるようにする |
表を見て気づいた方もいるかもしれませんが、右側の工夫には共通点があります。全部を自動で解決しようとしていないんです。
4つの壁に共通するのは、どれもそのサイトだけの事情で、機械が正解を決められないこと。だからスクリプトは消さない・壊さない・見落とさないに徹して、判断は人に渡す設計にしました。何度実行しても安全なので、「1記事で試す → 確認 → 全記事へ」と段階を刻んで進められます。
この仕組みはボタン一発で全部終わるツールではなく、人の確認と判断を助ける補助ツール。そう割り切ったことで、かえって安心して224本を任せられるものになりました。
ちなみに、移したあとの話
移行後はブロック単位で記事を編集できるのですが、これがかなり快適です。個人的に「移行してよかった」を一番実感できるのは、この編集画面かもしれません。
▲編集画面
おわりに
正直に言うと、アサインされた当初は「WordPressからmicroCMSへの移行」と聞いても、何がどう大変なのか、まったくピンときていませんでした。
それが今回、実データ224本と格闘してみて、移行のいちばんの敵は、難しい技術ではなくそのサイトだけの事情だということがわかりました。吹き出しの入れ子も、そっくりな2種類の表も、ドキュメントをいくら読んでも出てきません。手を動かして、実物にぶつからないとわからないことだらけでした。
「そのサイトだけの事情」は、WordPressでもmicroCMSでも、運用しているうちに必ず積もっていきます。今回、装飾の役割を1つずつ調べ直す作業に一番時間がかかったからこそ、装飾を追加するときは「何のための装飾か」がわかる名前をつけておく必要性を学びました。
CMSのCの字もわからなかった自分でも、ここまで来られました。同じように最初は知識が足りず「よくわからないプロジェクト」を任された新卒の方や、WordPressの移行を考えている方の、何かの参考になればうれしいです。ここまで読んでいただき、ありがとうございました！
- 日本・海外（フィリピン）での活躍チャンス
- 最先端技術と多言語環境での成長
- 入社後はメンターがそばで支える安心の成長環境
現在、IT職・営業職ともに積極採用中です。「挑戦できる環境で早く成長したい」「世界を舞台に活躍したい」そんな方は、以下よりぜひご応募ください！
