AIコーディング 2026.10.22 読了 4 分

レガシー移行でAIが間違えた場所を、全部書き出した

うまくいった話より、どこで間違えたかのほうが役に立つはずなので記録しました。

この記事の結論

古いPHPの移行でAIを使って、間違いが出た場所を記録した。傾向がはっきりしている。

1. 存在しない関数を呼ぶ

いちばん多かった。古いコードの中で呼ばれている自作関数の定義を渡していないと、名前から推測して別物を書く。

calc_tax()が内部で丸め処理をしていても、渡していなければ単純な掛け算になる。動くので気づかない。

対策は、呼んでいる関数の定義を一緒に渡すこと。grepで集めるだけで防げる。

古いPHPは型がゆるい。"10" == 10が真になる前提のコードがある。

これを===に直すと、見た目は正しくなるが動かなくなる。GETで来る値は常に文字列なので、数値と比べると偽になる。

「厳密比較に直して」と頼むと、この落とし穴ごと直してくる。型の変換を同時に入れないと成立しない。

$row['name']を$row->nameに直す場面で、一部だけ変換が漏れる。

長いファイルの後半で起きやすい。変更後のコード全体を返させると、見落としが増える。差分の形で返させると減った。

前に書いたとおり、値ではない部分はプレースホルダにできない。

// 返ってきた（動かない）
$pdo->prepare('SELECT * FROM :table WHERE id = :id');

構文としては通るが、実行すると失敗する。先に「できない箇所は指摘して」と頼んでおくと、書き換えずに一覧で返るようになった。

頼んでいないのに、try-catchや例外処理が増える。親切なのだが、元のコードが例外で止まる前提になっていないと、握りつぶしてしまう。

エラーが出なくなったので直ったように見えて、実際は失敗を無視しているだけ、という形になる。

そのまま使える形

間違いは散らばらない。同じ種類に固まるので、分類して一括で見直す。

1番が最も多く、最も気づきにくい。渡していないコードについては、必ず「不明」と書かせる指示を入れておく。

古い案件はEUC-JPやShift_JISが残っている。mb_convert_encoding()の指定を、UTF-8前提に書き換えてくることがあった。

画面では一見読めるので気づきにくい。文字化けは特定の文字でしか出ないため、確認するなら「表」「噂」「ソ」のような問題の出やすい字を使う。

整理の名目で、古いコメントが落ちる。

そのコメントが// 2015年の仕様変更で、ここだけ四捨五入しないのような唯一の仕様書だった場合、取り返しがつかない。

「コメントは一字も変えないで」と毎回入れるようにした。

到達しないように見える分岐や、使われていなさそうな変数が整理される。

実際には、特定の条件でしか通らないだけだったことがある。年に数回しか通らない分岐は、読んだだけでは判断できない。消す提案は受け取っても、消す判断は人がやる。

間違いは、渡していない情報の所と、気を利かせた所に集中していた。

どちらも頼む前に対処できる。出てきた結果を直すより、頼み方を直すほうが早い。

見落としを前提にして、確認の側を機械にした。前の記事に書いた移行前後のHTML差分がここで効く。

人の目で全部見るのは無理だが、差分が出た所だけなら見られる。間違いを減らす努力と、間違いに気づく仕組みは、別々に用意しておく。

あわせて読む

エラー文の読み方を覚えたら、AIに頼む回数が減った — エラーが出るたびに全文を貼って聞いていました。どこを見ればよいか分かってから、自分で解決できる割合が増えた話です。
毎回手でやっていた作業を、AIに小さな道具を作らせて減らした — 月に数回の面倒な作業を、使い捨ての道具で片付けるようになりました。作る基準と、作らない基準の話です。
AIに頼りながら、少しずつ自分で読めるようになるまでにやったこと — 全部任せていると、いつまでも分からないままでした。負担を増やさずに読めるようになる進め方です。