AI生成コードを書き直すか直し続けるか、分かれ目はどこか

AIが書いたコードのプルリクエストを開く。差分は数百行、テストは半分しかない。意図を説明するコメントもない。こういう画面を見たとき、頭に浮かぶのは「全部書き直した方が早いのでは」という一言だ。だが、この問いの答えは一つではない。書き直した方が速い場面と、少しずつ直した方が速い場面は、どちらも確かに存在する。問題は、その境目を自分の中に持っているかどうかだ。

書き直しが裏目に出た、ある一場面

以前、注文の状態管理を担うクラスをAIが生成したコードがあった。読みにくく、分岐も多かったので、週末に一人でまるごと書き直した。状態の持ち方を整理し、分岐を一つのメソッドに集約し、見た目はずいぶんきれいになった。

その翌日、別の機能追加でAIに同じクラスへの変更を依頼したところ、AIは古い構造――書き直す前に存在していた、状態を複数のフラグで持つやり方――を前提にしたコードを、新しいメソッドとして追加してきた。AIは昨日の書き直しを知らない。渡した文脈に、書き直し後の構造が十分に反映されていなかったからだ。結果、同じクラスの中に「新しい一本化された状態管理」と「古いフラグ前提の処理」が混在し、どちらを正として読めばいいのか、レビューでは誰も判断できなくなった。差分としては小さい追加だったのに、クラス全体を読み直さないと安全性を確認できない塊に変わっていた。

書き直しが悪かったわけではない。悪かったのは、書き直したという事実をAIに渡す文脈として引き継がなかったことと、書き直しの範囲がクラス全体という、一度では把握しきれない大きさだったことだ。レビュー画面で二つの構造が混在した差分を見たとき、どちらを残すか決めるのに、結局クラスの全メソッドを読み直す羽目になった。一つのメソッドを足すだけの変更に、クラス全体を読み直すコストが乗ってしまったわけで、これは明らかに割に合わない。

もう一つの一場面、小さく直した側

同じプロジェクトの別の箇所では、違う進め方をした。支払い処理の分岐が増えすぎて読みにくくなっていたコードに対して、一気に書き直すのではなく、まず分岐の一つだけを別メソッドに切り出し、テストを足し、通ることを確認してからプルリクエストを出した。差分は数十行で済み、レビュアーは「この一つの分岐が独立した」という狭い範囲だけを確認すればよかった。翌週、AIに新しい支払い方法への対応を依頼したときも、渡す文脈は切り出した分だけで足りた。AIは残りの大きな塊に触れずに、新しいメソッドを一つ追加するだけで済んだ。一週間かけて数回に分けたこの進め方は、週末にまとめて書き直すより遅く見えて、実際には衝突も読み直しの手戻りも起きなかった。

線引きの軸は三つある

ここから引ける教訓は、「書き直すな」ではなく、「どこまでなら書き直してよいか」を先に決めておくことだ。実務で使える軸は三つある。

一つ目は、そのコードにテストの安全網があるかどうかだ。テストが薄い場所をいきなり書き直すのは、床の見えない部屋を一気に改装するのに近い。先にテストを足し、今のふるまいを固定してから書き直すなら安全だが、テストが無いまま大きく書き直すのは、どちらの場合も危険度が同じではない。

二つ目は、AIがその周辺を今後も触り続けるかどうかだ。一度きりで完結する処理なら、多少読みにくくても書き直す優先度は低い。逆に、これから機能追加が続く見込みのある領域――先のクラスのように、今後も別の変更がAIによって積み重なっていく場所――は、書き直した後の構造を次の依頼にどう引き継ぐかまで含めて考える必要がある。引き継ぐ手段がないなら、大きな書き直しはそもそも避けた方がいい。

三つ目は、自分がそのコードの構造を人に説明できるほど把握しているかどうかだ。説明できないコードは、実は書き直しの対象としては一番危険な部類に入る。何が何に依存しているか分からないまま全体を入れ替えると、見えていない依存関係まで一緒に壊す。こういうコードにまず必要なのは、全部を入れ替えることではなく、関数を一つずつ切り出し、意味のまとまりが見えるまで小さく削っていく作業だ。読めるようになってから、必要なら書き直すかどうかをもう一度判断すればいい。

判断を先に、作業の順番は後で決まる

三つの軸をまとめると、書き直しが向いているのは「テストで守られていて、AIが二度と触らない、自分が全体を説明できる」小さな範囲に限られる。逆に、どれか一つでも欠けるなら、少しずつ直す側を選んだ方が事故が少ない。小さな変更の連鎖は、一歩ごとにテストで確認でき、次にAIへ渡す文脈も小さく保てるので、さきほどのクラスのような食い違いが起きにくい。

迷ったときにまず聞くべき問いは、「このコードは書き直すべきか」ではなく、「このコードは、テストの安全網があり、自分が構造を説明できる範囲に収まっているか」だ。収まっていなければ、書き直しの前にやることがまだ残っている。この線引きを自分の中に持っておくことが、AIと一緒にコードを育てていく上での、地味だが効く判断力になる。

線引きの感覚を鍛えるには、設計やリファクタリングの定番書から判断軸を借りるのが早い。tasklogは、実際に読まれ、引用されている技術書や学習記事を集めている場所だ。

https://s-tasklog.com/books/general