Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Claude Codeはレガシー移行でどこまで使えるのか?

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for ak2ie ak2ie
February 22, 2026

Claude Codeはレガシー移行でどこまで使えるのか?

Avatar for ak2ie

ak2ie

February 22, 2026
Tweet

More Decks by ak2ie

Other Decks in Technology

Transcript

  1. 今回のミッション MySQL 4 → 8 へDBのみ移行 MySQL 4.0 は 2003年リリース(約23年前)

    Movable Type 3系 Perl製の古いプラグインあり ボランティア団体のホームページ 業務外の対応 単純移行 → 動かない 3
  2. Claude Codeと回した検証ループ 1. 仮説を立てる — 「MySQL側の文字変換?」 「Perl側?」 「データ自体?」 2. 検証スクリプトを書かせる

    — Perlで診断CGIを作成 3. 実行結果を渡して分析 — 結果をファイル出力して分析 4. 仮説を排除して次へ — 仮説を潰し、原因の層を掘り下げ 7
  3. Step 1: 仮説を立てる MySQL 4 → 8 で日本語を含むカラムだけ壊れている Claude Codeの仮説:

    「MySQL 8.0が文字コード変換しているのではないか」 BLOBデータがutf8mb4 として再解釈され、バイナリが壊れた? 状況を伝えるだけで、仮説を立ててくれる 8
  4. Step 2: 検証スクリプトを書かせる 「この仮説を検証して」と指示 LENGTH() (バイト長)と CHAR_LENGTH() (文字長)を比較 文字変換が起きていれば値にズレが 出るはず

    # MySQL側のLENGTH vs CHAR_LENGTH比較 my $sth = $dbh->prepare( "SELECT plugindata_id, LENGTH(plugindata_data) as byte_len, CHAR_LENGTH(plugindata_data) as char_len FROM mt_plugindata WHERE plugindata_plugin ='rightfields'" ); $sth->execute; while (my $r = $sth->fetchrow_hashref) { my $match = ($r->{byte_len} == $r->{char_len}) ? "SAME" : "DIFFERENT!"; } 9
  5. Step 3: 実行結果を渡して分析 検証スクリプトの出力を @output.txt で渡す 結果:全レコードで SAME Claude Codeの分析:

    「MySQL側では文字変換は起きてい ない」 === MySQL LENGTH() vs CHAR_LENGTH() === ID=1 byte=16623 char=16623 => SAME ID=2 byte=1966 char=1966 => SAME ID=3 byte=8939 char=8939 => SAME ID=4 byte=820 char=820 => SAME : (全17レコード SAME) 10
  6. 根本原因 phpMyAdminがBLOBを文字列リテラルでエクスポート → バイナリの0x82 が UTF-8検証でU+FFFD(置換文字)に化けた 正しいパック長: 00 00 01

    82 → 386 ダンプ内: 00 00 01 EF BF BD → 495 と誤読 DBeaverでHEXリテラル形式(0x534552... )でエクスポート → 文字変換の影響を受けず、正常にインポートできた 12
  7. 結果と学び 感覚では約 15時間 削減できた 特に助かったのは 仮説 → 検証 → 分析

    → 次のアクション提示のループを回してくれたこと 仮説を検証・排除し、原因を絞り込んでくれた 検証スクリプトもPerlで書いてくれた Claudeは魔法ではない。でも、 「詰まる時間」を劇的に減らしてくれる 13