WordPressからmicroCMSへの移行を決断した皆さま、おめでとうございます。しかし、その決断の先に、最も厄介な作業が待ち構えていることにお気づきかもしれません。
それは、**「既存コンテンツの移行」**です。
何百、何千と蓄積された記事を前に、「これを全部、気合でコピペするしかないのか…」と絶望している担当者の方も少なくないでしょう。
本記事では、その「気合でコピペ」という非生産的な「労働」を、今回限りで終わらせるための、現実的な移行戦略について解説します。
コンテンツ移行の前に立ちはだかる「気合でコピペ」という名の壁
コンテンツ移行の手段を考えると、大きく分けて「すべて手動」か「すべて自動」かの二択を想像しがちです。しかし、どちらも大きな落とし穴があります。
なぜ「愚直な手動コピペ」を選んではいけないのか？
「気合でコピペ」は、一見シンプルですが、最も危険な選択肢です。
- 品質の低下: 担当者のスキルや集中力によって、書式が崩れたり、画像が抜け漏れたりします。
- リンク切れの多発: 記事内の内部リンクや外部リンクの修正漏れが必ず発生します。
- 膨大な検証コスト: 移行した全記事が正しく表示・機能しているかを確認する作業は、移行作業そのものよりも時間がかかることさえあります。
- 担当者の疲弊: 何より、この「労働」は担当者のモチベーションを著しく低下させます。
「完全自動化」の幻想と、コストの現実
では、すべてをスクリプトで自動化すればよいのでしょうか。それもまた現実的ではありません。
長年運用されたWordPressは、独自のカスタムフィールド（ACF等）や、Gutenbergのカスタムブロック、特定のプラグインが生成するショートコードなどで「魔改造」されていることがほとんどです。
これらすべてを完璧にパース（解析）し、microCMSの新しいスキーマにマッピングする**「完璧な移行スクリプト」**を開発するコストは、移行プロジェクト全体の予算を圧迫するほど高額になりがちです。
「労働」を最小化するmicroCMS移行戦略の全体像
私たちが推奨するのは、「愚直な手動」でも「完璧な自動化」でもない、**「8割の自動化と2割の戦略的手動移行」**というハイブリッドなアプローチです。
ステップ1：移行対象の「棚卸し」と「仕分け」
まず、既存の全コンテンツをリストアップし、以下の3つに仕分けします。
- 移行する（必須）: ビジネス上、またSEO上、必ず必要なコンテンツ。
- 移行しない（廃棄）: 情報が古すぎる、アクセスが全くないなど、廃棄すべきコンテンツ。
- 要確認（アーカイブ）: 移行はしないが、データとしては残しておきたいコンテンツ。
この時点で「移行しない」と決断するだけで、移行対象は大幅に削減できます。
ステップ2：「型」が決まっているコンテンツ（8割）を定義する
次に、「移行する」と決めたコンテンツの中で、構成がパターン化されているものを見つけます。
- 「タイトル」「本文（クラシックエディタ）」「アイキャッチ画像」「カテゴリ」「タグ」だけで構成されるシンプルなブログ記事
- 「商品名」「価格」「説明文」といったカスタムフィールドで構成される商品紹介ページ
これらが、移行対象の「8割」を占めるはずです。この**「型」**こそが、自動化のターゲットです。
ステップ3：「型」をスクリプトで自動移行する
ステップ2で定義した「型」に基づき、移行スクリプトを作成します。WordPressからデータを取得し、microCMSのAPIスキーマに合わせてデータを投入（POST）します。 （具体的な方法は後述します）
ステップ4：「型」から外れるコンテンツ（2割）を戦略的に手動移行する
自動化のターゲットから外れた、残りの「2割」のコンテンツ。
- Gutenbergのカスタムブロックを多用した、複雑なランディングページ
- 特殊なプラグイン（例：表作成プラグイン、FAQプラグイン）で作成されたページ
これらこそが、「気合でコピペ」（＝戦略的な手動移行）の対象です。数は少ないため、品質を担保しながら手作業で移行します。
なぜWordPressの「標準エクスポート」では不十分なのか？
WordPressには標準でXMLエクスポート機能がありますが、microCMSへの移行には適していません。
メディア（画像）の課題
標準エクスポートは、画像の「参照情報」は含みますが、画像ファイルそのものを移行先のメディアライブラリ（microCMSの場合はS3など）にアップロードしてはくれません。
カスタムフィールド（ACF等）とGutenbergの壁
標準エクスポートのXMLは、ACFなどで追加したカスタムフィールドのデータを正しく含めないか、非常に扱いにくい形式でしか出力しません。Gutenbergのブロックデータも同様で、HTMLコメントとして埋め込まれた複雑なJSON構造を正しくパースするのは困難です。
実践：「8割」を自動化する移行スクリプトの構成例
「型」が決まった8割のコンテンツは、APIベースで移行するのが最も効率的です。
準備：WordPress側でAPI（WPGraphQL）を準備する
WordPressをAPIサーバー化します。標準のREST APIでも可能ですが、カスタムフィールドなどを柔軟に取得するために**「WPGraphQL」**プラグインの導入を強く推奨します。
WPGraphQLを使えば、移行に必要なデータ（タイトル、本文、カスタムフィールド、カテゴリ、タグ、アイキャッチ画像のURLなど）をGraphQLクエリ一つで効率的に取得できます。
# WPGraphQLのクエリ例
query GetPostsForMigration {
posts(first: 100) { # ページネーションで全件取得する
nodes {
title
content
date
slug
featuredImage {
node {
sourceUrl
}
}
categories {
nodes {
name
}
}
# ACFのフィールドなどもここに追加
}
}
}
実行：移行スクリプト（Node.js等）でデータをマッピング
次に、Node.jsやPythonなどで、WPGraphQLから取得したデータをmicroCMSのAPI（コンテンツ作成エンドポイント）にPOSTするスクリプトを作成します。
// Node.js (axios) でのmicroCMSへのPOST例 (イメージ)
import axios from 'axios';
// WPGraphQLから取得したデータ (post)
const post = {
title: "WPから取得したタイトル",
content: "<p>WPから取得した本文HTML</p>",
// ... other fields
};
// microCMSのスキーマに合わせてデータをマッピング
const microCMSPayload = {
title: post.title,
body: post.content, // microCMSのリッチエディタのフィールド名
// ...
};
// microCMS APIにPOST
await axios.post(
'https://YOUR_SERVICE.microcms.io/api/v1/YOUR_ENDPOINT',
microCMSPayload,
{
headers: { 'X-MICROCMS-API-KEY': 'YOUR_API_KEY' },
}
);
検証：画像リンクと内部リンクの処理
スクリプト処理で最も重要なのがリンクの処理です。
- 画像: 本文（
content）内の<img>タグを正規表現やDOMパーサーで抽出し、sourceUrlをmicroCMSのメディアストレージにアップロードし直し、その新しいURLに置換します。 - 内部リンク:
href属性が自社ドメインを指している<a>タグを見つけ、移行後の新しいパーマリンク構造（例：/blog/SLUG）に置換します。
「残りの2割」＝コピペの価値を最大化する
さて、自動化から漏れた「2割」の複雑なコンテンツです。これを「労働」と捉えず、「品質向上のための仕上げ」と捉えましょう。
「手動」だからこそできる、リッチエディタへの最適化
WordPressのGutenbergブロックやショートコードで無理やり実現していたレイアウトを、microCMSの新しいリッチエディタや、フロントエンドで用意されたカスタムコンポーネント（例：microCMSの「繰り返しフィールド」と連携）を使って、よりクリーンでセマンティックな構造に再構築するチャンスです。
移行を「コンテンツ精査」の機会に変える
手動で移行する過程で、「この記事の情報は古くないか？」「このCTAは今も最適か？」と、一つ一つのコンテンツを再評価できます。
「気合でコピペ」は、移行対象を絞り込み、自動化を徹底した上で、最後に残った「本当に重要なコンテンツ」に対してのみ行う、価値ある「手作業」なのです。
「最後の労働」を終わらせるために
WordPressからmicroCMSへの移行は、単なるツールの乗り換えではありません。それは、過去の「負債」を清算し、将来のコンテンツ運用を効率化するための「構造改革」です。
移行スクリプトの作成にはコストがかかりますが、それは数百件のコピペ作業にかかる人件費と、その後の検証コスト、そして担当者のモチベーション低下に比べれば、はるかに安価な「投資」です。
