ココログからWordPressへのブログ移行手引きCopilot・ChatGPT・GeminiなどのAI活用版

2026.10.09

26/10/14改稿

  1. はじめに
  2. 元データを直接書き換えない
  3. 最初から全記事を処理しない
  4. dry-runを使う
  5. 1. 自分のココログURLを確認する
    1. HTTPとHTTPSは別の文字列
    2. URLを分解して考える
    3. AIへの依頼例：旧サイトのURL構造を調べる
  6. 2. MTバックアップを取得する
  7. 3. HTTrackで旧ブログ全体を保存する
  8. 4. MTバックアップとHTTrackは役割が違う
  9. 5. 作業用フォルダーを作る
  10. 1. 対応表が移行の中心になる
  11. 2. 記事対応表を作る
    1. 対応表で使う主な項目
  12. 3. 画像対応表を作る
  13. 4. 画像を特定する順番
    1. HTTrackで原画像名が変わる例
    2. AIへの依頼例：画像対応表を作る
  14. 5. 旧記事URL対応表を作る
  15. 1. この章の目的
  16. 2. WordPress側の基本形
  17. 3. 形式A　window.open と .shared/image.html?/
    1. ココログ側の例
    2. WordPress側の例
    3. 変換内容
  18. 4. 形式B　表示画像と原画像が別
    1. ココログ側の例
    2. サムネイルを維持する場合
    3. 原画像へ統一する場合
  19. 5. 形式C　class="mb"
    1. 変換前
    2. 変換後
  20. 6. 形式D　photos/uncategorized 直リンク
  21. 7. 形式E　_thumb 方式
    1. ココログ側の例
    2. サムネイルを維持
    3. 原画像へ統一
  22. 8. 形式F　画像だけを表示
    1. 変換前
    2. 変換後
  23. 9. 外部画像と file:/// 参照
  24. 10. WordPress用画像フォルダーを作る
  25. 11. 画像をWordPressサーバーへアップロードする
  26. 12. MTバックアップの画像HTMLを一括変換する
  27. 1. 記事内リンクも旧ココログを指している
  28. 2. 実際に行った方法
  29. 3. AI活用版として考えられる方法
  30. 4. 同名記事に注意する
  31. 5. 旧URLと新URLの対応表を作る
  32. 6. MTバックアップ内の記事リンクを書き換える
    1. AIへの依頼例
  33. 1. 読み込み前の完成状態
  34. 2. 旧ココログの記述を検索する
  35. 3. 少数記事でテストする
  36. 4. WordPressへ読み込む
  37. 1. 記事の確認
  38. 2. 画像の確認
  39. 3. 記事内リンクの確認
  40. 4. 画像が見つからない場合
  41. 5. 画像は表示されるがクリックすると壊れる場合
  42. 6. 小さい画像しか表示されない場合
  43. 7. 問題を見つけたら上流へ戻る

はじめに

この手引きは、ココログで長期間運営してきたブログをWordPressへ移し、できる限り元の記事、画像、投稿日、カテゴリー、記事同士のリンクを残したい人のための実務手引きです。

HTML、Python、SQLなどに詳しくない人でも進められるよう、専門用語は必要な場面で使い、その直後に意味を説明します。専門用語を覚えることが目的ではありません。AIへ何を調べさせ、何を作らせ、どこを人間が確認するかを理解することが目的です。

今回の実測例では、MTバックアップに含まれる7,048記事を調査し、829件の画像参照と12種類のHTML構造を確認しました。実際の変換ルールとしては、おおむね6系統の画像表示方式に整理できました。

この手引きでは、移行作業を次の6部に分けます。

第1部　旧ココログを保存し、サイトの構造を確認する第2部　記事・画像・旧URLの対応表を作る第3部　ココログの画像をWordPress向けの形へ変換する第4部　記事内の過去記事リンクを新サイト用に直す第5部　画像と変換済み記事をWordPressへ移す第6部　移行結果を確認し、残った問題を直す

本手引きには、実際に行った方法だけでなく、保存データから確認した内容、保存結果をもとにした推定、AI活用版として提案する未検証の方法も含まれます。未検証の方法は、そのことが分かるように記載します。

この手引きで最も重要な原則

元データを直接書き換えない

移行作業では、次のような多数のファイルを扱います。

ココログから取得したMTバックアップHTTrackで保存した旧サイト記事の対応表画像の対応表旧URLと新URLの対応表AIに作成してもらった処理用プログラム処理結果の記録書き換え後のMTバックアップWordPressへ送る画像

一括処理の設定を一つ間違えるだけで、多数の記事を書き換えてしまう可能性があります。

必ず次の順番で作業します。

元データを保存↓作業用コピーを作成↓コピーだけを調査・変換↓変換結果は別ファイルへ保存

最初から全記事を処理しない

AIが作った処理用プログラムも、最初から正しく動くとは限りません。

1記事↓10記事↓1か月分↓全期間

の順で試します。

dry-runを使う

dry-run とは、実際にはファイルを書き換えず、何件が変更対象になるか、どのように変わる予定かだけを確認する試験実行です。

AIには、必ず次の条件を付けます。

  • 元ファイルを上書きしない
  • 最初はdry-runにする
  • 結果は別ファイルへ保存する
  • 変更予定件数を表示する
  • 変換前後の例を表示する
  • 未発見や複数候補を勝手に確定しない
  • 最初の10件だけで試せるようにする
  • エラー内容を記録する

第1部　旧ココログを保存し、サイトの構造を確認する

1. 自分のココログURLを確認する

本手引きでは、筆者が実際に移行した旧ブログを例にします。

移行時点のブログURLは次のとおりです。

https://buran.tea-nifty.com/blog/

サイトの一番上のURLは次のとおりです。

https://buran.tea-nifty.com/

ただし、長年の記事データにはHTTP時代のURLも残っていました。

http://buran.tea-nifty.com/blog/http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttp://buran.tea-nifty.com/blog/images/sample.jpg

そのため、この手引きではHTTPとHTTPSの両方を旧ココログURLとして調べます。

HTTPとHTTPSは別の文字列

次の2つは、人間には同じ記事に見えても、文字列としては別URLです。

http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.html

サイト側の設定によっては、HTTPからHTTPSへ自動転送され、同じ記事や画像が開く場合があります。しかし、検索や一括置換では別の文字列として扱われます。

したがって、旧URLを探すときは次の3種類を確認します。

http://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com

最後にサイト名だけでも検索すれば、HTTPとHTTPSのどちらで残っていても見つけやすくなります。

URLを分解して考える

https://buran.tea-nifty.com/blog/2006/08/post-89ad.html

は、次のように分けて考えます。

https://  HTTPかHTTPSかを示す部分
buran.tea-nifty.com  サイトを表す部分
blog/  ブログ部分の名前
2006/08/  記事の年月
post-89ad.html  個別記事のファイル名

すべてのココログが ○○○.tea-nifty.com/blog/ という形とは限りません。tea に相当する部分や、blog に相当する部分が異なる例もあるため、自分のブログの実URLを確認してください。

AIへの依頼例：旧サイトのURL構造を調べる

ココログからWordPressへの移行を行います。
まずMTバックアップとHTTrack保存データを調査し、旧ココログサイトのURL構造を確認してください。
筆者の例:https://buran.tea-nifty.com/https://buran.tea-nifty.com/blog/
ただし過去記事には、http://buran.tea-nifty.com/http://buran.tea-nifty.com/blog/も残っている可能性があります。
http:// と https:// の両方を調べてください。URL先頭のhttp/https以外が同じものは、同じ記事または画像の候補として記録してください。
buran、tea-nifty.com、blogに相当する部分は、他のココログでは違う可能性があるため固定しないでください。
この段階では何も書き換えず、見つかったURLの種類と構造だけを報告してください。

2. MTバックアップを取得する

MTバックアップは、記事をまとめて保存したテキストファイルです。主に次の内容が入っています。

  • 記事タイトル
  • 記事本文
  • 投稿日時
  • カテゴリー
  • 本文中の画像HTML
  • 旧画像URL
  • 過去記事へのリンク

ただし、画像ファイルそのものは入っていません。

元ファイルは、例えば次の名前で保存します。

cocolog_mt_original.txt

直接編集しないでください。

MT内の記事は、例えば次のような形です。

TITLE: 記事タイトルDATE: 09/12/2016 23:31:33CATEGORY: 日記・コラム・つぶやきBODY:記事本文

3. HTTrackで旧ブログ全体を保存する

HTTrackは、WebサイトをHTMLや画像を含めてパソコンへ保存するソフトです。

ブログが次のURLでも、

https://buran.tea-nifty.com/blog/

可能ならサイトの一番上から保存します。

https://buran.tea-nifty.com/

画像や共有ファイルが /blog/ の外側にある場合があるためです。

保存結果は、例えば次のようになります。

buran.tea-nifty.com├─ .shared├─ blog│  ├─ 2006│  │  └─ 08│  │     ├─ index.html│  │     └─ post-89ad.html│  └─ images└─ photos

4. MTバックアップとHTTrackは役割が違う

MTバックアップ  記事タイトル  投稿日時  記事本文  ココログ上の画像URL  過去記事へのリンク
HTTrack  月ごとの一覧HTML  個別記事HTML  パソコン内での画像参照先  実際に保存された画像ファイル

移行の中心作業は、この2種類の情報を結び付けることです。

MTの記事情報＋HTTrackの保存情報＋実際の画像ファイル↓WordPress移行用の対応表

5. 作業用フォルダーを作る

MigrationProject├─ backup_original│  ├─ mt│  └─ httrack├─ work│  ├─ mt│  └─ httrack├─ tables├─ scripts├─ output├─ logs└─ upload
  • backup_original：絶対に変更しない元データ
  • work：調査や変換に使うコピー
  • tables：記事・画像・URLの対応表
  • scripts：AIが作った処理用プログラム
  • output：変換後のMTファイル
  • logs：処理結果やエラーの記録
  • upload：WordPressへ送る画像

第2部　記事・画像・旧URLの対応表を作る

1. 対応表が移行の中心になる

主に次の3種類を作ります。

記事対応表MTの記事 → HTTrackの個別記事HTML
画像対応表旧画像URL → 保存画像 → WordPress配置先 → 新画像URL
旧記事URL対応表旧記事URL → 記事タイトル・投稿日 → 新記事URL

2. 記事対応表を作る

画像や旧記事リンクを正しく調べるには、MT内の記事がHTTrackのどの post-xxxx.html に対応するかを特定する必要があります。

照合は次の順で行います。

  1. タイトルと投稿日時が一致
  2. 投稿日時が一致
  3. タイトルと投稿日が一致
  4. 本文冒頭が一致
  5. 手動確認

例えば、MT側が次の場合、

TITLE: Ｃ７１申し込みDATE: 08/19/2006 14:02:02

HTTrack側の月別ページで、

2006-08-19 14:02↓post-89ad.html

と分かれば、同じ記事として対応表へ記録します。

対応表で使う主な項目

  • 記事タイトル
  • MT側の投稿日時
  • HTTrack側の投稿日時
  • 月別 index.html の場所
  • 個別記事HTMLの場所
  • 本文冒頭
  • 何を根拠に一致と判断したか
  • 確実度
  • OK、要確認、未発見などの状態
  • メモ

AIが扱いやすいよう英語の列名を使う場合でも、読者は意味を理解できれば十分です。

3. 画像対応表を作る

画像対応表には次を記録します。

どの記事にあった画像か↓MTに書かれた表示画像URL↓MTに書かれたクリック先URL↓HTTrackの記事HTMLに書かれた参照先↓実際に保存された表示画像↓実際に保存された原画像↓WordPressでの配置先↓新しい画像URL

ここで重要なのが、img src と a href です。

  • img src：記事中に表示する画像のURL
  • a href：画像をクリックしたときの行き先

この2つは同じとは限りません。

画像対応表には少なくとも次を記録します。

  • 記事タイトル
  • 投稿日時
  • 個別記事HTML
  • 記事内で何枚目の画像か
  • MT側の img src
  • MT側の a href
  • HTTrack側の img src
  • HTTrack側の a href
  • パソコン上の表示画像
  • パソコン上の原画像
  • 画像形式A〜F
  • どの方法で特定したか
  • 確実度
  • WordPressでの配置先
  • 新URL
  • 状態
  • メモ

4. 画像を特定する順番

正しい画像を特定するときは、次の順番を使います。

1. 個別記事HTMLから直接取得2. 月別index.htmlから取得3. 元画像名で検索4. 投稿日時に近い画像を候補にする5. ファイルサイズと画像サイズを比較6. 実際に画像を開いて確認

HTMLから直接分かった結果と、更新日時から推定した結果を同じ扱いにしません。

HTTrackで原画像名が変わる例

個別記事HTMLに次の記述がある場合、

<a href="../../../.shared/image8e08.jpg?/photos/uncategorized/c71cut.jpg">

次の対応が分かります。

ココログ上の原画像名c71cut.jpg
HTTrackが保存した原画像.shared/image8e08.jpg

HTMLから見つからない場合だけ、更新日時、ファイルサイズ、画像の縦横サイズ、目視確認へ進みます。

AIへの依頼例：画像対応表を作る

MT形式バックアップ、HTTrackの月別index.html、個別記事HTML、画像フォルダーを解析するPythonプログラムを書いてください。
目的:MTバックアップ中の画像参照と、HTTrackで保存された画像を対応付けること。
重要:・img srcは記事に表示する画像・a hrefはクリック先・表示画像と原画像が別の場合がある・.shared/imageXXXX.jpgへ名前が変わっている場合がある
照合順:1. 個別記事HTML内の参照2. 月別index.html内の参照3. 画像ファイル名一致4. 投稿日時と更新日時が近い候補5. 手動確認候補
対象:・.shared/image.html?/ を使う形式・window.openを使う形式・photos/uncategorizedとblog/imagesが別の形式・class="mb"を使う形式・_thumbを使う形式・imgタグだけの形式・外部画像・file:/// で始まる壊れた参照
条件:・元データは変更しない・未発見は別一覧にする・複数候補は自動確定しない・推定結果を確定結果と同じ扱いにしない・最初の10記事だけでテストできるようにする

5. 旧記事URL対応表を作る

記事本文中の旧リンクについて、次を記録します。

  • 旧URL
  • HTTPかHTTPSか
  • HTTrackの個別記事HTML
  • 記事タイトル
  • 投稿日
  • 投稿時刻
  • 本文冒頭
  • 判断方法
  • 確実度
  • 状態
  • メモ

HTTPとHTTPS以外が同じURLは、同じ記事の候補として扱います。ただし元URLは消さずに残します。

第3部　ココログの画像をWordPress向けの形へ変換する

1. この章の目的

この章の目的は、単に画像ファイルを新サーバーへコピーすることではありません。

ココログにあった多数の画像表示形式を、WordPressで扱いやすい標準的な形へそろえることです。

ココログの複数の画像表示形式↓表示画像と原画像を特定↓画像をWordPressへコピー↓新しい画像URLを決定↓MTバックアップの画像HTMLを書き換え↓WordPressで扱いやすい単純なHTMLへ統一

ココログでは、次のような記述が混在していました。

.shared/image.html?/window.open()class="mb"photos/uncategorizedblog/images_thumb

これらは削除する文字列の一覧ではありません。それぞれが、記事表示用画像、クリック先原画像、ココログ独自の画像表示機能などの役割を持っています。

2. WordPress側の基本形

ココログ側の複雑なHTMLを、基本的には次の形へそろえます。

<a href="新しい原画像URL">  <img src="新しい表示画像URL" alt=""></a>
  • <img src="...">：記事中に表示する画像
  • <a href="...">：画像をクリックしたときに開く原画像
  • alt：画像が表示できない場合などに使われる画像説明。元の値があれば残す

表示画像と原画像を同じファイルへ統一する場合は、href と src が同じURLになります。

3. 形式A　window.open と .shared/image.html?/

ココログ側の例

<a  href="http://buran.tea-nifty.com/.shared/image.html?/photos/uncategorized/sample.jpg"  onclick="window.open(this.href); return false">  <img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt=""></a>

ここでは、

  • img src が記事中の表示画像
  • href がココログ独自の画像表示ページ
  • onclick が別画面を開くための処理

です。

.shared/image.html?/ はWordPress側には存在しないため、そのまま残すと、画像は表示されてもクリック時にリンク切れになる可能性があります。

WordPress側の例

<a href="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg">  <img src="https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg" alt=""></a>

変換内容

  1. .shared/image.html?/ を使うココログ独自のリンクを残さない
  2. onclick を削除する
  3. href を新しい原画像URLへ変更する
  4. src を新しい表示画像URLへ変更する
  5. class="mb" があれば削除する

4. 形式B　表示画像と原画像が別

ココログ側の例

<a href="http://buran.tea-nifty.com/photos/uncategorized/sample.jpg">  <img src="http://buran.tea-nifty.com/blog/images/sample.jpg" alt=""></a>

この形式では、img src と a href の両方を修正します。

サムネイルを維持する場合

<a href="新しい原画像URL">  <img src="新しい表示画像URL" alt=""></a>

原画像へ統一する場合

<a href="新しい原画像URL">  <img src="新しい原画像URL" alt=""></a>

原画像が非常に大きい場合は、ページ表示が重くなる可能性があるため、少数記事で確認します。

5. 形式C　class="mb"

変換前

<a class="mb" href="旧URL">  <img src="旧画像URL" alt=""></a>

class="mb" はココログ側の画像表示機能に関係する指定であり、WordPressではそのまま使う必要がありません。

変換後

<a href="新しい原画像URL">  <img src="新しい表示画像URL" alt=""></a>

6. 形式D　photos/uncategorized 直リンク

href と src が同じ画像を指している場合があります。

その場合は両方を新しい画像URLへ変更します。

<a href="新画像URL">  <img src="新画像URL" alt=""></a>

7. 形式E　_thumb 方式

ココログ側の例

<a href="sample.jpg">  <img src="sample_thumb.jpg" alt=""></a>
  • sample_thumb.jpg：記事表示用の小さい画像
  • sample.jpg：クリック先の原画像

この形式では2つの実ファイルを区別します。

サムネイルを維持

<a href="新URL/sample.jpg">  <img src="新URL/sample_thumb.jpg" alt=""></a>

原画像へ統一

<a href="新URL/sample.jpg">  <img src="新URL/sample.jpg" alt=""></a>

8. 形式F　画像だけを表示

変換前

<img src="旧画像URL" alt="">

変換後

<img src="新画像URL" alt="">

クリック先がないため、基本的には src の変更だけで対応できます。

9. 外部画像と file:/// 参照

ココログ以外のサイトを参照する画像は、外部画像として別に扱います。権利や利用条件を確認せず、自分のサーバーへ自動コピーしない方が安全です。

file:///C:/...

は、記事作成時のパソコン内ファイルを指していた可能性があります。旧パソコンやバックアップから元画像を探し、見つからなければ未発見として記録します。

10. WordPress用画像フォルダーを作る

例えば次の形で画像を集めます。

upload└─ 2016   └─ 09      └─ sample.jpg

サーバー側の配置先は次のようになります。

wp-content/uploads/2016/09/sample.jpg

同名ファイルは上書きしません。

sample.jpgsample-2.jpgsample-3.jpg

ファイル名を変更した場合は、画像対応表の配置先と新URLも更新します。

11. 画像をWordPressサーバーへアップロードする

画像は、記事を本番で読み込む前にアップロードします。

画像対応表を完成↓アップロード用画像を作成↓WordPressサーバーへ画像を配置↓新画像URLをブラウザーで確認↓MTバックアップの画像HTMLを書き換え

新URLを直接開き、画像が表示されることを確認します。

https://www.buran-works.com/wp-content/uploads/2016/09/sample.jpg

12. MTバックアップの画像HTMLを一括変換する

AIには次の処理を依頼します。

画像対応表を使い、MT形式バックアップ内の画像HTMLをWordPress向けの単純なHTMLへ変換するPythonプログラムを書いてください。
変換ルール:1. 記事表示用画像URLを対応する新URLへ変更2. クリック先URLを対応する新しい原画像URLへ変更3. .shared/image.html?/ を使う旧リンクを残さない4. onclick属性を削除5. class="mb"を削除6. border、hspace、vspaceなど古い表示指定を削除7. 元のalt属性があれば維持8. altがなければalt=""を付ける9. _thumbは対応表の指定に従って維持または原画像へ統一10. 外部画像は自動変換しない11. 未発見や複数候補は自動変換しない12. 可能ならHTML解析ライブラリを使い、タグの順番や改行の違いにも対応する
安全条件:・元のMTファイルは変更しない・変換結果は別ファイルへ保存・最初はdry-run・変換前後の例を出力・変換数、未変換数、エラー数を記録・最初の10記事だけでテスト可能・文字コードを維持

第4部　記事内の過去記事リンクを新サイト用に直す

1. 記事内リンクも旧ココログを指している

記事本文には次のような過去記事リンクが残っています。

http://buran.tea-nifty.com/blog/2008/03/post-abcd.htmlhttps://buran.tea-nifty.com/blog/2008/03/post-abcd.html

画像だけ移行しても、これらを直さなければ過去記事リンクは旧サイトへ飛びます。

2. 実際に行った方法

実際の移行では次の方法を使いました。

WordPressへ記事を読み込む↓WordPressが実際に作った記事URLを取得↓旧URLと新URLの対応表を作成↓SQLを生成↓phpMyAdminで記事本文を一括更新↓Search Regexで旧リンクの残りを確認

SQLはデータベースへ処理を指示する命令文、phpMyAdminはブラウザーからデータベースを操作する管理画面です。この方法は実施済みですが、初心者には難易度が高い方法です。

3. AI活用版として考えられる方法

初心者向けには、WordPressのデータベースを直接変更せず、MTバックアップ側を先に直す方法を提案します。

MTバックアップから旧記事URLを抽出↓HTTrackでリンク先記事を特定↓記事タイトルと投稿日を取得↓新サイトの記事URLの付け方を決める↓旧URLと新URLの対応表を作る↓MTバックアップ内のリンクを書き換える↓WordPressへ少量テストで読み込む

ただし、この方法は全記事について実施済みではありません。少数記事でWordPressが想定どおりのURLを作ることを確認してください。

4. 同名記事に注意する

同じタイトルの記事が複数ある場合、タイトルだけでは新URLを決められません。

照合は次の順で行います。

タイトル＋投稿日＋投稿時刻タイトル＋投稿日投稿日＋本文冒頭表記ゆれを整えたタイトル手動確認

5. 旧URLと新URLの対応表を作る

oldurl_to_newurl.csv

という名前で、次を記録します。

  • 旧URL
  • HTTPかHTTPSか
  • 記事タイトル
  • 投稿日
  • 新URL
  • 判断方法
  • 確実度
  • OK、要確認、未発見などの状態
  • メモ

元の旧URLは消さずに残します。

6. MTバックアップ内の記事リンクを書き換える

OKと確認できたURLだけを変換します。

旧ココログ記事URL↓新WordPress記事URL

記事本文で昔のURLを説明しているだけの箇所まで変えないよう、<a href="..."> のリンク先を優先して処理します。

AIへの依頼例

旧URLと新URLの対応表を使い、MTバックアップの記事本文中にある旧ココログ記事リンクを新WordPress URLへ変換するPythonプログラムを書いてください。
条件:・元のMTバックアップは変更しない・結果は別ファイルへ保存・最初はdry-run・OKと確認済みのURLだけを変換・要確認、複数候補、未発見は変換しない・httpとhttpsの両方を確認・記事本文の説明用URLではなく、実際のリンク先を優先・変更した記事数とリンク数を記録・最初の10記事だけでテスト可能にする

第5部　画像と変換済み記事をWordPressへ移す

1. 読み込み前の完成状態

画像→ WordPressサーバーへ配置済み
新画像URL→ ブラウザーで表示確認済み
MT内の画像HTML→ WordPress向けの形へ変換済み
記事内の過去記事リンク→ 新URLへ変換済み、または未確定一覧へ分離済み

2. 旧ココログの記述を検索する

http://buran.tea-nifty.comhttps://buran.tea-nifty.comburan.tea-nifty.com.sharedimage.htmlwindow.openclass="mb"photos/uncategorizedblog/imagesfile:///_thumb

一致した箇所をすべて自動削除するのではなく、画像HTMLやリンクとして残っているのか、説明文に書かれているだけなのかを確認します。

3. 少数記事でテストする

テストには次を含めます。

  • 画像なし
  • 通常画像
  • .shared/image.html?/ を使う記事
  • class="mb" を使う記事
  • _thumb を使う記事
  • 複数画像の記事
  • 外部画像の記事
  • 過去記事リンクがある記事
  • 同名タイトルの記事
10記事↓100記事または1か月分↓全記事

の順で進めます。

4. WordPressへ読み込む

変換済みMTバックアップを、MT形式に対応したWordPressの読み込み機能で取り込みます。

確認項目は次のとおりです。

  • タイトル
  • 投稿日時
  • カテゴリー
  • 本文
  • 画像表示
  • 画像クリック先
  • 過去記事へのリンク
  • 記事URL
  • 文字化け
  • 改行
  • スマートフォン表示

問題があればWordPress上で大量に手修正せず、対応表と変換処理へ戻ります。

第6部　移行結果を確認し、残った問題を直す

1. 記事の確認

  • 記事数が大きく欠けていないか
  • タイトルが正しいか
  • 投稿日時が正しいか
  • カテゴリーが正しいか
  • 本文が途中で切れていないか
  • 文字化けしていないか
  • 改行が崩れていないか
  • 重複記事がないか

2. 画像の確認

  • 画像が表示されるか
  • 縦横比が正しいか
  • 小さい画像だけになっていないか
  • クリックすると原画像が開くか
  • 別記事の画像になっていないか
  • img src と a href の両方が新URLか
  • .shared/image.html?/ が残っていないか
  • file:/// が残っていないか

3. 記事内リンクの確認

  • 新WordPress記事へ移動するか
  • 旧ココログへ戻らないか
  • HTTP形式の旧リンクが残っていないか
  • HTTPS形式の旧リンクが残っていないか
  • 同名の別記事へ間違って飛ばないか

4. 画像が見つからない場合

MTのimg srcとa hrefを確認↓個別記事HTMLを確認↓月別index.htmlを確認↓元画像名で検索↓.sharedフォルダーを確認↓更新日時を比較↓ファイルサイズと画像サイズを比較↓目視確認

見つからない場合は、無理に別画像を割り当てず未発見として残します。

5. 画像は表示されるがクリックすると壊れる場合

img src だけが新URLになり、a href が旧URLのまま残っている可能性があります。

6. 小さい画像しか表示されない場合

サムネイルを原画像として使っている可能性があります。画像対応表の表示画像と原画像を確認します。

7. 問題を見つけたら上流へ戻る

対応表を修正↓画像フォルダーを作り直す↓MTバックアップを変換し直す↓再検査↓再テスト

WordPress上だけを手修正すると、再読み込みしたときに同じ問題が復活します。

AIを使うときの用語メモ

  • MTバックアップ：ココログの記事をまとめたテキストファイル
  • HTTrack：WebサイトのHTMLや画像をパソコンへ保存するソフト
  • HTML：記事内で画像やリンクの表示方法を指定する記述
  • img src：記事に表示する画像の場所
  • a href：クリックしたときの行き先
  • CSV：Excelでも開ける、表形式のテキストファイル
  • スクリプト：繰り返し作業を自動処理する小さなプログラム
  • dry-run：実際には変更せず、変更予定だけを確認する試験実行
  • 正規表現：一定の規則に合う文字を検索する方法。複雑なものはAIに作らせる
  • SQL：WordPressのデータベースへ変更を指示する命令文
  • phpMyAdmin：ブラウザーからデータベースを操作する管理画面
  • パーマリンク：各記事の固定URL
  • スラッグ：記事URLの最後に付く記事名部分
  • サムネイル：記事表示用の小さい画像
  • 原画像：クリック先などに使う元の大きい画像

最終結論

ココログからWordPressへの移行は、単にMTバックアップを読み込む作業ではありません。

旧サイトを保存↓記事・画像・旧URLの対応表を作成↓表示画像と原画像を特定↓画像をWordPressへ配置↓ココログの複数の画像表示形式をWordPress向けHTMLへ統一↓過去記事リンクを新サイト用に変換↓少量テスト↓本番移行↓旧URL、画像、クリック先、記事内リンクを検査

画像移行の本質は、画像ファイルを集めることだけではありません。

ココログに混在していた複数の画像表示方式を理解し、表示画像と原画像を正しく特定し、img src と a href の両方をWordPress用の新URLへ直すことです。

そして、AIにすべてを勝手に判断させるのではなく、確定、要確認、複数候補、未発見を分けて記録することで、移行後の修正と再実行が可能になります。

コメント