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

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

Avatar for ak2ie ak2ie
February 22, 2026

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

Avatar for ak2ie

ak2ie

February 22, 2026

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