リファクタリングはただの綺麗好き？いいえ、実は最強のコスト削減術なんです

「コードを綺麗にする時間なんてない」──そう言ってリファクタリングを後回しにしていませんか？実は、技術的負債を放置することは、将来的に莫大な「利息」を支払うことと同義です。リファクタリングは単なる自己満足ではなく、開発スピードの維持、バグ発生率の低下、そしてチームの生産性を最大化するための極めて経済的な投資戦略です。今すぐ負債を返済し、将来のエンジニアリングコストを劇的に下げましょう。

要点は「リファクタリングでトークン消費が減る」ってことだね。

あれこれ理屈を並べるより、メリットを数値化しようとする試みは評価できるよ。マーティン・ファウラーがリファクタリングに関する本 [1] を書いているけど、その中で「リファクタリングの絶対条件は……堅牢なテストだ」と述べていることに触れておく価値がある。これはAIを使っていようがいまいが、ここでの真のメリットだと思う。優れたテストは、人間であれロボットであれ、リグレッションから守ってくれるからね。それに、仕様をコードとして落とし込む助けにもなるし、人間もロボットもそれを読むことができる。

[1] https://www.oreilly.com/library/view/refactoring-improving-t... (https://www.oreilly.com/library/view/refactoring-improving-the/9780134757681/)

これに関するデータがあるのはすごく興味深い。

LLMは整理されたコードから大きな恩恵を受ける一方で、そういったコードを『作成』するのはそれほど得意ではない、という自分の経験とも一致してるよ。

ほとんどの人間の開発者と同じようなもんじゃないかな！

コードの総量がほとんど変わらなかったのは面白いね。自分の経験だと、散らかったコードをリファクタリングすると行数が半分になることも珍しくないからさ。

これって、人間がループの中に入るのが不可欠なパターンのひとつだと思う。

エージェントによるリファクタリングのプロセス自体は理にかなってるよ。最初のタスク出力に集中している『生成』側LLMが見落としたポイントを、レビュー側の別のLLMが指摘できるからね。

でも、レビュー側のエージェントが、このプロジェクトが一体何なのか、コードがどう組み合わさって動いているのかを本当に理解できるんだろうか？ つまり、コードのどの部分が冗長で、どこをもっとエレガントにできるかという判断だ。

コーディングエージェントにリファクタリングを頼むのは、外科医に運動能力を向上させてくれと頼むようなものかもしれない。エージェントがこれを適切に行うには、本当に全体的な視点が必要になるはず。

僕が言いたいのは、巨大なファイルを分割するだけじゃ、何と何が関連していて、何をユーティリティ関数に抽出できるかという『理論』がなきゃ、それは表面的なリファクタリングに過ぎないってこと。ファイルを分けるのは、因数分解みたいなものなのか、それとも巨大な数字を小さな数字に分けて、結局また足し合わせるだけみたいなものなのか？

エージェントは結局、システム全体を『完全には』理解していないといういい例がある。API経由ですでに取得済みのデータを、わざわざ保存して計算するようなシステムを実装したりするからね。人間は、プロジェクト全体を捉えるホリスティックな感覚と、タスクに向き合う時の精密なメスのような感覚——『あ、このJSONを見ればすでに必要なキーがあるじゃないか』といった——という二重の視点を持っていることが多いんだ。

メリットはトークン消費の削減だけじゃないよ。コンパクトなコンテキストは推論を促進するし、もし単一のコンテキストに詰め込めるなら、より多くの層でインテリジェンスを活用できる。それを可能にするソフトウェアを書くことは、より正確で、汎用性が高く、テスト済みケースだけでなく、その補間や外挿についても高い確率で正しく動作するソフトウェアにつながるんだ。

優れた抽象化に向けたリファクタリングは、みんなが思っている以上に強力だよ。それを裏付ける情報理論的なベイズ数学もある。

経済的かつエネルギー効率よく処理・実行できるソフトウェアが、結果としてより正確になりやすいっていうのは、ちょっとした奇跡的な偶然だよね。

結局のところ、コードのエントロピーを減らすことがすべてなんだ。https://benoitessiambre.com/entropy.html (https://benoitessiambre.com/entropy.html)

エージェントのコードはエージェントにしか読めないし理解できない。人間には、この巨大なコードの塊を理解できないところまで来てしまったんだよ。

これって機能なの？ バグなの？ それとも創発的な特性？

区別なんて現実の前では重要じゃないと思う。

AIツールで生成されたコードだから、僕らはAIツールを使わざるを得ない状況にロックインされているんだ。

こういう「破滅の巨大ファイル」は、どのみち人間が生成しても手に負えないものだった。LLMのおかげで、ようやく編集やリファクタリングが管理可能、あるいは実現可能になったんだよ。

正直、コードベースが巨大化して人間が理解できなくなった今、LLMが僕らを救ってくれるんじゃないかと思ってる。（破滅のモノレポだよ）

個人的にはこういう巨大ファイルは大嫌いだけど、それは個人の好みに過ぎないし、マーティン・ファウラー的なリファクタリングやクリーンアップの手法が今後も重要であり続けるかは疑問だね。ある意味で悲しいことだけど。

すごくいい記事だね。AIについて書くならこうあるべきだよ。具体的で、ツールが実際にどう使われているかに即していて、かつ定量的だ。世の中には、中身がひどく曖昧だったり、実際のユースケースからかけ離れていたり、そもそもツールを実際に使っていない人間が書いたAI評論が多すぎる。「AIが苦手なのはこういうことで、それを証明する測定値がこれです」という批判は、理由もなく「なぜAIが社会にとって問題だと思うか」を語るよりずっといい。

少し話は違うけど、同じ理由で気に入っている別の研究に、ボコ・ハラムのメンバーがテロを支援するためにAIをどう使ったかを聞き取ったレポートがある。延々と unproductive な議論が繰り返されるオンライン掲示板に比べると、こういった具体的な報告は本当に清々しいよ。

https://casp.ac/reports/ai-enabled-terrorism (https://casp.ac/reports/ai-enabled-terrorism)

ほとんどのIT企業で無視されてきたプログラマーのベストプラクティスが、AIのベストプラクティスとして再発見されているのが面白いよね。

退屈な現実：ドキュメントは社内のSharePointサーバーにアップロードされたWordファイルじゃなくて、コード内に書くべきだ。

ワクワクする未来：AIのためのドキュメントは社内のSharePointサーバーにアップロードされたWordファイルじゃなくて、コード内に書くべきだ。

退屈な現実：Jiraのタスクで細かく管理するんじゃなくて、開発者にプロジェクトの全体像を伝えるべきだ。

ワクワクする未来：プロンプトで細かく管理するんじゃなくて、CLAUDE.mdでAIにプロジェクトの全体像を伝えるべきだ。

退屈な現実：リファクタリングは長期的に開発者の生産性を高める。

ワクワクする未来：リファクタリングは長期的にAIの生産性を高める。

素晴らしい記事だけど、一番重要な点を見落としているよ。リファクタリングの経済的メリットの大半は、人間が理解しやすくなることから生まれるんだ。つまり、深夜の障害対応が早く終わる、本番環境へのバグ混入が減る、そして競合他社より速くリリースして市場で優位に立てるということだ。何より重要なのは、システムを理解していれば、みんなが責任と当事者意識を持ちやすくなること……つまり、何か問題が起きた時にすぐに対応できるし、改善の余地があるなら率先して手を出せるようになる。

面白いね。でも、元のコードベースとリファクタリング後のコードベースで、新機能を追加する際のトークンコストを比較できたらもっと面白いと思う。リファクタリングされたコードベースから始めれば、新機能追加のコストが低くなると期待したいよね。もしそうなら、長期的にはリファクタリングが経済的に理にかなっているという証明になるはずだ。