記事を一括移行できるCMSの選び方｜数百記事をWordPressから移す前の3層リスク診断

結論：一括移行が必要かは「記事数」ではなく3層の自動処理で決まる

記事の一括移行に対応したCMSへ乗り換えるべきかどうかは、①データ層（文字コード・ファイル形式）②構造層（画像パス・内部リンク・URL）③品質層（公開可否の判定）の3つを自動で処理できるかで判断します。手作業のコピー＆ペーストでは、この3層のうち必ずどこかが抜け落ちます。一括インポート・エクスポートは、記事を1本ずつ移す作業をなくし、フォーマット変換・画像の再配置・カテゴリとタグの割り当てまでまとめて処理する機能です。乗り換え時の初期コストを抑えながら、既存の記事資産を新しい運用基盤へそのまま引き継げます。

この記事は誰向けか：数百記事を抱える運用担当者と、複数CMSを預かる制作会社向けです

次のような立場・規模に当てはまるなら、この記事の判断軸はそのまま使えます。自分の状況に近いものがあるか確認してください。

• 自社ECのオウンドメディアを1人で回している担当者：WordPressで数百本の記事が積み上がり、商品カテゴリの改編に合わせてCMSを乗り換えたいが、移行作業に割ける時間が週数時間しかない、という状態。
• 複数クライアントのサイトを預かる制作会社・Webコンサルのディレクター：案件ごとにWordPress・Contentful・HubSpotが混在し、クライアントごとに移行手順を作り直している、というパターン。
• 事業統合でメディアを1本化する編集責任者：2つのドメインに分かれた記事を1つに寄せる必要があり、重複記事とURL設計をどう捌くかが決まらない、という状態。
• 外部ライターに記事を発注してきた事業部の担当者：納品物がGoogleドキュメントやMarkdownでバラバラに残っており、CMSへの登録が追いついていない、というパターン。

記事資産が多いほど移行コストは膨らみますが、一括処理に対応した仕組みがあれば、移行そのものの判断ハードルを下げられます。

記事の一括移行で実際に起きる失敗は、ほぼ4パターンに集約される

移行事故の大半は、移行作業中ではなく「移行前の確認漏れ」で決まります。典型的な状況を具体的に挙げます。

• 文字コードを確認せずCSVを取り込み、全記事が文字化けする：Excelで編集したCSVがShift_JISのまま保存され、取り込み後に本文が「?」や記号の羅列になる。元ファイルを上書き保存していると、正しい原稿がどこにも残っておらず記事の再作成が必要になる、という最悪のパターンに落ちます。
• 絶対URLの画像がリンク切れになる：旧サイトのドメインを直書きした画像タグをそのまま移し、旧サーバーを解約した瞬間に数百枚の画像が一斉に表示されなくなる。公開直後は気づかず、数週間後に読者からの指摘で発覚するケースが起きます。
• 内部リンクが旧URLのまま残る：本文は移行できたのに、記事中のリンクだけが旧URL構造を指し続け、リダイレクトも張られていない。回遊が切れるうえ、どのページから何本張られているかを後から手作業で洗い出す羽目になります。
• 品質チェックを飛ばして一括公開してしまう：旧サイト時代の「業界No.1」「必ず成果が出る」といった表現や、出典のない数値が入った古い記事が、そのまま新サイトで公開される。数年前のキャンペーン価格が残ったまま公開され、問い合わせで指摘されて初めて気づく、という事故が起こります。

移行リスク3層診断：赤が1つでもあれば手動移行は中止する

この記事では、移行前の確認を「データ層・構造層・品質層」の3つに分けて判定する枠組みを、移行リスク3層診断と呼びます。各層を赤・黄・緑で判定し、赤が1つでもあれば手作業での移行は諦め、一括インポート機能に切り替えるのが基本方針です。

層	確認する項目	赤（手動移行は不可）	黄（条件付きで可）	緑（手動でも可）
第1層：データ層	文字コード／ファイル形式／列構成	CSVがShift_JIS、または形式が混在している	UTF-8だが列名が独自	WordPressの標準エクスポート（WXR）がそのまま出せる
第2層：構造層	画像パス／内部リンク／URL設計	画像が絶対URLで、旧ドメインを廃止する予定がある	URL構造が変わるがリダイレクト設計が未着手	URLも画像パスも変わらない
第3層：品質層	重複記事／古い数値・表現／薄い記事	重複記事の有無を誰も把握していない	古い記事が混在しているが一覧化はできている	直近に棚卸し済みで公開可否が判定できる

3層はそれぞれ独立して事故を起こします。データ層が緑でも構造層が赤なら、文字化けはしないのに画像だけ全滅する、という結果になります。

移行前チェックリスト：着手前に7項目を潰す

下の7項目に「いいえ」が3つ以上あるなら、テストインポートから始めてください。

#	チェック項目	該当する層	「いいえ」のときの対応
1	エクスポートファイルの文字コードをUTF-8と確認したか	データ層	元ファイルを別名で退避してから変換する
2	ファイルの列名とCMS側の項目の対応関係を書き出したか	データ層	インポート前プレビューでマッピングを確認する
3	本文中の画像が相対パスか絶対URLかを確認したか	構造層	画像の再アップロードオプションを有効にする
4	新旧URLの対応表（リダイレクト表）を作ったか	構造層	移行対象記事の一覧に新URL列を追加して埋める
5	記事中の内部リンク本数と向き先を把握しているか	構造層	移行後に一括で洗い出して差し替える
6	タイトルが似ている重複記事を洗い出したか	品質層	重複検出にかけ、統合の要否を先に決める
7	公開前に品質を判定する基準が決まっているか	品質層	採点基準を決め、基準未満は下書きのまま保留する

一括インポート・エクスポートは何を自動で処理するのか

ATKの一括インポートは、WordPressのエクスポートファイル（WXR形式）・CSV・Markdownのほか、ContentfulやHubSpotなどのCMSからの移行に対応しています。取り込み時には記事の構造変換・画像の再配置・カテゴリとタグの自動マッピングが実行され、ATKの記事テンプレートに沿った状態で保存されます。エクスポートはWXR形式・CSV・JSONなど複数の書き出し形式を選択でき、マルチサイトpublishと組み合わせれば、ATKを編集ハブにして複数媒体へ配信する流れも組めます。

インポートした記事はすべてdraft（下書き）として保存され、そのまま自動公開されることはありません。カクンダーZによる品質採点を経てから公開判断をする流れが標準です。前述の第3層（品質層）の事故は、この下書き保留の運用でほぼ防げます。

移行の運用フロー：6ステップのどこで3層診断を使うか

一括インポートを使った移行は、次の6ステップで進み、各ステップが3層診断のどこを潰すのかが決まっています。

ステップ	作業内容	潰す層	ATKの動き
1. エクスポート準備	元のCMSから記事データを書き出す（WXR・CSV等）	データ層	－
2. フォーマット確認	列構成と文字コードを確認し、必要に応じて調整する	データ層	インポート前プレビューで列マッピングを確認できる
3. テスト＆本番インポート	少量でテスト投入し、結果を見てから全件を投入する	データ層・構造層	構造変換・画像再配置・カテゴリマッピングを自動処理
4. 重複チェック	既存記事との重複を確認し統合方針を決める	品質層	重複候補を自動検出し、統合の要否を提示する
5. 品質チェック	取り込んだ記事を採点し、修正対象を絞る	品質層	カクンダーZで採点し、基準未満の記事を抽出する
6. 公開判断	担当者の確認を経て公開する	構造層・品質層	WordPressへの自動公開、または手動公開を選択できる

一括移行で動くのは「削減工数×人件費」と「移行事故による逸失利益」の2経路

記事の一括移行が利益に効く経路は2つあり、どちらも自社の数字を入れて試算できます。下の式に自社の値を代入してください。以下に置く数値はすべて計算手順を示すための仮の値で、実績値ではありません。

経路1：手動コピー工数の削減額

削減コスト（円）＝ 移行記事数（本）× 1記事あたりの手動移行工数（分）÷ 60 × 担当者の時間単価（円）

• 移行記事数＝A本（自社の数字を入れてください）
• 1記事あたりの手動工数＝B分（本文コピー＋画像再アップロード＋カテゴリ設定の合計を、実際に3本計測して平均を取る）
• 担当者の時間単価＝C円（人件費／稼働時間、または外注単価）

仮にA＝300、B＝20、C＝3,000と置くと、300×20÷60×3,000＝300,000円が手動移行にかかる人件費の目安になります。ここに、一括移行の準備（3層診断・テストインポート・確認）に要する時間×時間単価を引いた差額が、実質の削減額です。

経路2：移行事故で失う流入の逸失利益

逸失利益（円）＝ 事故で影響を受ける記事の月間セッション × 想定CVR × 平均成約単価 × 復旧までの月数

画像リンク切れや内部リンク切れは、発覚が遅れるほど「復旧までの月数」が伸びます。月間セッションと想定CVR、平均成約単価はすべて自社の実測値を入れてください。セッションとCVRの元データはGA4・Search Console連携で記事単位に揃えられます。

投資回収の見方

回収月数＝ 導入・移行にかかる費用 ÷（経路1の月あたり削減額 ＋ 経路2で回避できる月あたり損失）。分子・分母とも自社の数字で埋めれば、乗り換えを今やるか先送りするかの判断材料になります。

他機能とつなぐと、移行後の改善作業まで一続きになる

一括インポートで取り込んだ記事は、下書きのままATKの他機能へ引き渡せます。リライト候補抽出を使えば、取り込んだ既存記事のうち検索パフォーマンスが低い記事や内容が薄い記事を自動で拾い出せるため、移行直後の「どれから直すか」で止まらずに済みます。

WordPress自動公開と組み合わせると、インポート後のdraft記事を担当者の確認後にそのまま公開するまでを一連の手順にまとめられます。複数のブランドやクライアントのサイトをまとめて扱う場合は、マルチワークスペースでデータを分離しながら一括移行することも可能です。

移行前後に押さえておく5つの注意点

• 文字コードとフォーマットは着手前に確認する：CSVはUTF-8、WXRはWordPressの標準エクスポートそのままが安定します。列名が異なる場合はインポート時のマッピング設定で対応できます。
• 画像URLの書き換えを前提に設計する：元サイトで絶対URLを使っている記事は、インポート後に画像パスが変わることがあります。画像をATK Storageへ再アップロードするオプションを有効にしておくと、旧サーバー解約後のリンク切れを避けられます。
• 取り込んだ記事は必ず下書きで確認する：旧サイトで使っていた出典のない数値やキャンペーン表現は、コンプラチェックで洗い出してから公開判断してください。
• 内部リンクのURLは移行後に一括更新する：URL構造が変わる場合、記事内のリンクも合わせて修正が必要です。内部リンク最適化の機能で残存リンクをまとめて確認できます。
• 大量移行は必ず分割して実行する：全件を一度に投入する前に少量でテストインポートを行い、マッピングと変換結果を目視で確認してから本番移行に進んでください。

よくある質問

Q. WordPressから別のCMSに記事を一括移行できますか？

できます。WordPressの標準エクスポート（WXR形式）をそのまま取り込めるほか、CSV・Markdown、ContentfulやHubSpotからの移行にも対応しています。取り込み時に構造変換・画像再配置・カテゴリマッピングが自動で行われます。

Q. CMSを移行するとSEO評価は下がりますか？

URLが変わるかどうかで対応が分かれます。URL構造を維持できるなら追加作業は少なく済みますが、変わる場合は新旧URLの対応表を作ってリダイレクトを設計し、記事内の内部リンクも旧URLから差し替える必要があります。この2つを放置したまま公開すると、回遊とクロールの両方が切れます。3層診断の第2層（構造層）が赤なら、公開前にここを潰してください。

Q. 移行中にサイトを止める必要はありますか？

ありません。インポートした記事はdraftとして保存されるため、元サイトを稼働させたまま作業を進められます。新サイトへの切り替えタイミングは別途調整してください。

Q. インポートしたCSVが文字化けするのはなぜですか？

ほとんどの場合、Excelで保存した際にShift_JISになっていることが原因です。元ファイルは必ず別名で退避したうえでUTF-8に変換し、少量でテストインポートしてから全件を投入してください。元ファイルを上書き保存していると復元できません。

Q. WordPressのプラグインや設定は引き継げますか？

記事コンテンツ（本文・タイトル・カテゴリ・タグ・アイキャッチ画像）は移行できますが、プラグイン設定やウィジェットの設定は対象外です。SEOプラグインのメタ設定（meta descriptionやOGPなど）はCSV経由で別途取り込む形になります。

Q. 移行後に元のCMSへ戻すことはできますか？

できます。WordPress WXR形式やCSV・JSONで書き出せるため、元のCMSへの書き戻しも可能です。記事データはATK内に保持したまま、必要なタイミングでエクスポートできます。

まとめ：3層診断で赤が出たら、移行より先に「直す順番」を決める

記事の一括移行は、ファイルを取り込んだ時点ではなく、下書きの品質判定と内部リンクの差し替えを終えた時点で完了します。ここまでの内容を踏まえて、次の3条件のうち1つでも当てはまるなら、移行作業そのものより先にリライトの優先順位づけに着手してください。

• 移行リスク3層診断の第3層（品質層）が赤、つまり重複記事の有無を誰も把握していない
• ステップ5の品質チェックで、基準未満と判定された記事が全体の3割を超えた
• 経路1の計算式（移行記事数×手動工数÷60×時間単価）で出た金額が、担当者の月あたり可処分工数を超えている

この段階で優先順位づけの方法を確認すると、「どの記事を直し、どの記事を統合し、どの記事を移行対象から外すか」が記事単位で判断できるようになります。確認の際は、現CMSのエクスポートファイル（WXRまたはCSV）、記事一覧と新旧URLの対応表、過去12か月分のセッションと検索クエリのデータを手元に用意しておくと、そのまま優先順位表に落とし込めます。リライトsprintの進め方はこちらで確認できます。