Analyzegear
「開発現場で Claude Code を使い倒す」シリーズ4回目。今回はレガシーな巨大コードに手を入れる話です。何千行にも育った functions.php や、いくつもの環境にコピーされている同じファイル――こういう「触るのが怖い」コードほど、AIに任せるときの作法が効きます。合言葉は「小さく、局所的に、検証とセットで」。
読んでから、局所的に編集する
まず、編集する前に対象を読む。当たり前ですが、巨大ファイルほど効きます。そのうえで、ファイル全体を書き換えさせるのではなく、変更したい箇所だけを厳密な文字列一致で差し替える。周辺のコードのスタイル（命名・コメントの粒度・書き方）に合わせて、その場所だけを最小の差分で変える。全面書き換えを一気にやらせると、関係ない部分まで”きれいにされて”差分が読めなくなり、レビューもできなくなります。
巨大ファイルには「フラグ層」を一枚かぶせる
育ちすぎた functions.php をいきなり分割するのはリスクが高い。そこで有効なのが、新しい機能をフィーチャーフラグで出し入れできる層を一枚かぶせるやり方です。新旧を切り替えられる状態にしておけば、問題があればフラグを戻すだけで復旧できます。「いきなり作り直す」のではなく、安全に足場を作ってから少しずつ移す――ストラングラーパターンの前夜にあたる考え方です。この設計自体は別記事「巨大化した functions.php に「フィーチャーフラグ層」を一枚かぶせる」で詳しく書いています。AIに任せるときも、この「戻せる状態を先に作る」を最初のステップにします。
同じファイルが複数環境にあるなら、1ソースから展開する
私たちのWordPress運用では、同じテーマファイルが本番の複数インストールと検証環境に存在します。こういうとき、各所を個別に編集すると必ずズレます。1つのソースを直し、そこから全環境へ展開する形にして、AIにも「1か所を直して全部に配る」という手順で動いてもらいます。どこか1つだけ古い、という状態を作らないことが大事です。
多バイト・クォートの地雷を避ける
日本語を含む置換で、ハマったことがあります。サーバ上で sed を使って日本語を置換したら、多バイト文字とSSH越しのクォートが噛み合って、エラーも出さずに黙って失敗していました。以来、日本語を含む書き換えは手元で確実に置換してから、ファイルごと転送するようにしています。コマンド一発の見た目の速さより、確実に反映される手順を選ぶ。巨大ファイルの一部だけを狙って書き換えるときも、同じ理由で「厳密な文字列一致での差し替え」を基本にしています。
lint とテストで即座に確かめる
変更したら、その場で構文チェック（php -l など）やテストを走らせて確かめます。巨大ファイルは影響範囲が読みにくいので、「変更→即検証」を短いループで回す。まとめて直してから最後にまとめて確認、は事故のもとです。反映後は本番URLの表示も確認します(このあたりは前回の「危険な操作を安全に」とセットです)。
まとめ
- 読んでから、変更箇所だけを厳密一致で差し替える。全面書き換えを一気にやらせない。
- 巨大ファイルは「戻せる層（フラグ）」を先に作ってから移す。
- 同じファイルが複数環境にあるなら、1ソースから展開する。
- 日本語置換はサーバ上の
sedで黙って失敗しがち。手元で置換して転送する。 - 変更→即 lint／テスト→本番確認、を短いループで。
次回は「本番デプロイまで任せる」――WordPressの複数インストールやLaravelへの反映を、手順漏れなく検証までやり切る流れを書きます。
