AI時代のリファクタリング──可読性の基準が変わり始めている
はじめに
「リファクタリングってどこまでやるべきなんだろう」
あるプロジェクトで、久しぶりにこの問いと正面から向き合うことになりました。ただ、最近この問いの前提そのものが変わってきているのではないか、と感じています。
AIと一緒にコードを書くようになって、「誰のための可読性か」という根本的な問いが浮かび上がってきたんです。
AI開発で起きている「理解の負債」
従来の技術的負債とは違う現象が起きています。
理解を伴わないコードが増える
人間が一行ずつ書いたコードは、少なくとも書いた本人は理解しています。でもAIに生成させると「動いたからOK」で、なぜそう書かれたかを誰も把握していない。
- 一貫性がない（スタイル・パターンがバラバラ）
- 過剰に複雑（エッジケース対応で条件分岐が増殖）
- 設計意図が読み取れない
書くコストが下がった分、読んで理解するコストの比重が上がっている。これを「理解の負債」と呼んでみました。
技術的負債との違い
従来の技術的負債は「将来の変更コスト」の問題でした。「今は急いで実装するけど、後で直す」という先送りです。
一方、理解の負債は「現在の理解コスト」の問題です。コード自体は動いているし、構造的に破綻しているわけでもない。ただ、誰もその意図を説明できない。
技術的負債は「後で返済する」という選択肢がありますが、理解の負債は「今すぐ理解できないと次の変更ができない」という即座の問題になります。
でも、本当に問題なのか？
ところが、実は最近コードを読んで理解しようということをあまりやっていません。
AIに読んでもらって概要を教えてもらう。細かく知りたいときはAIに仕様を聞く。人にとっては理解しにくいコードでも、AIの方が早く確実に情報を紐解いてくれます。
だとすると、「理解の負債」はどのくらい重いのか。正直、わからなくなってきました。
AIに聞けば済む、で回らなくなる瞬間
もちろん、すべてがうまくいくわけではありません。
デバッグで迷走するAI
不具合の指摘をして問題箇所を特定してもらう。でも何度やっても根本原因にたどり着かない。デバッグ用のコードが場当たり的に仕込まれて、結局問題解決しない。
ここ、イラッとします。
人間のデバッグなら「ここは違った、次はこっち」と絞り込んでいく感覚があります。でもAIは同じところをぐるぐる回る。試行錯誤しているようで、実は何も学習していない。
なぜAIはこれが苦手なのか：
- 状態を持っていない（さっき試したことを構造的に覚えていない）
- 仮説を立てていない（網羅的に見えて場当たり的）
- 諦め時がわからない（延々と小手先の修正を提案）
結局、デバッグみたいに「なぜ」を掘る作業は、まだ人間がハンドルを握った方が早いことが多いです。
現状の落とし所
AIには「ここが怪しいと思うんだけど、この関数の挙動を説明して」みたいに、仮説の検証を手伝わせる使い方の方が噛み合います。
生成や理解は任せて、問題の切り分けと判断は人間がやる。これが今の現実解かもしれません。
AIのためのリファクタリング
ここで最初の問いに戻ります。
リファクタリングの目的が変わってきているのではないか。
従来：人間のための可読性
- 変数名がわかりやすい
- 関数が短い
- コメントが丁寧
全部「人が読むから」という理由でした。
これから：AIが正確に扱える形
AIにとって扱いやすいコードの条件：
- スコープが小さい → 一度に把握できる範囲を超えると精度が落ちる
- 依存関係が明確 → 暗黙の結合が多いと影響範囲を見誤る
- 状態が少ない → グローバルな状態や副作用は追跡できない
- テストが充実 → 変更の影響を即座に判定できる
これって昔から言われている「良い設計」の原則と重なります。ただ、理由が「人間が読みやすいから」ではなく「AIが正確に扱えるから」に変わっている。
人間とAIで最適解は違うのか
ここで新しい問題が浮上します。
分割粒度のジレンマ
人間の場合：
- 流れで理解する（上から下にストーリーとして）
- 途中で別ファイルに飛ばされると文脈が途切れる
- 分割しすぎると全体像が見えなくなる
AIの場合：
- 関数定義を見に行くコストがほぼゼロ
- 分割されていても困らない
- むしろ一つの塊が大きいと本質と枝葉の区別が難しい
共通化のトレードオフ
人間が嫌がる理由：
- 影響範囲が見えなくなる
- 「これを変えたらどこが壊れる？」を追えない
AIの得意・不得意：
- 参照箇所の列挙は得意
- でも「この共通関数を変えていい文脈か」の判断は苦手
つまり、最適な設計が人間とAIで違う可能性があります。
これからどう判断するか
選択肢1：AIにとっての読みやすさを優先
人間がコードを読む機会が減っていくなら、コードは「AIが正確に扱える形」に最適化する。人間向けの説明は必要なときにAIに生成させればいい。
メリット：
- AIの精度が上がる（デバッグの迷走が減る）
- 変更コストが低い（AIに直させられる）
デメリット・懸念：
- AIの「正解」がまだわかっていない
- 次世代のAIで最適解が変わるかも
選択肢2：使い分ける
- AIに任せる前提のユーティリティ層 → 細かく分割
- 人間が判断するビジネスロジック層 → 流れを重視
課題：
- 境界線の引き方が難しい
- 多くのプロジェクトでは混在している
選択肢3：今は両方を満たす設計を目指す
人間のための可読性とAIのための扱いやすさは、今のところ大きく矛盾していない。むしろ同じ方向を向いている。
将来的には：
- AIの比重が上がれば最適化の方向も変わる
- その時また判断すればいい
私の暫定的な答え
正直に言うと、確立した答えはありません。
ただ、今の実感としては 「AIがデバッグで迷走しない粒度」を一つの指標にする のが現実的だと考えています。
実際にそこで困っているわけですから。
具体的には：
- 関数は小さく保つ（AIが一度に把握できる範囲）
- 状態管理を明確にする（暗黙の依存を減らす）
- テストを書く（AIの変更を検証できる状態にする）
そして、人間が読む必要があるときはAIに説明させる。この分業が、今の落とし所かもしれません。
残る問い
- リファクタリングの基準は本当に「AIの扱いやすさ」に移行していくのか
- 人間にとっての可読性は二の次でいいのか
- そもそも「良いコード」の定義は書き換わっていくのか
私自身、まだ答えが見えていません。
ただ一つ言えるのは、「誰のための可読性か」を問い直す時期に来ているということ。そして、その答えは現場で試行錯誤する中からしか出てこない、ということです。
あなたは、誰のためにコードを書いていますか？
こうした判断や内省のプロセスを、
エンジニア向けにもう少し整理して書いています。
興味があれば、こちらにまとめています。
Discussion