ハクソク

世界を動かす技術を、日本語で。

リファクタリングの経済的利点

2026年7月31日原文(martinfowler.com)

概要

  • Agentic engineering の実験的アプリ構築とそのコードベースの特徴
  • 巨大な単一ファイル に成長したデータアクセス層のリファクタリング実践
  • リファクタリングによるトークン消費削減 の定量的測定と結果
  • エージェントによるリファクタリングの課題とプロセス考察
  • 今後の課題と、より広範なリファクタリングの可能性

エージェント駆動型開発における大規模リファクタリング実験

  • Agentic engineering の新しい世界に対応するため、完全自動化された高品質なWebアプリケーションを構築

    • Web UIの動的リフレッシュやモーダル、外部システム連携、機械学習、バックグラウンドジョブ、自動デプロイ環境を実装
    • Rust（約12万行）、TypeScript、Terraformで構成、総コード量約15万行
    • コードは Claude Code とCursor等のエージェントのみで生成、ほぼレビューなし

  • 開発中、データアクセス層が巨大な 単一Rustファイル （最終的に17,155行）へ膨張

    • 重複したHTTPリクエスト処理やJSONエンコード/デコード の繰り返し
    • 内部言語や関数・クラスの抽出がほぼ行われていない構造

  • リファクタリングの実験計画

    • エージェントによるコードベースのリファクタリングが 将来的なトークン消費削減 に繋がるかを検証
    • 各リファクタリングステップごとに、同じ代表的変更をエージェントに実行させ、 トークン消費量を測定
    • 変更内容は都度破棄し、 純粋なコスト比較 を実施

  • リファクタリング手順

    • 厳格なリファクタリング計画立案
    • 代表的な変更内容を単一プロンプトで定義
    • ベースラインコスト測定→各リファクタリング適用→同一変更の適用・トークン消費測定→記録・比較

  • 結果

    • データアクセス層の総行数はほぼ変わらず、 最大ファイルサイズのみ劇的減少
    • 入力トークン消費は17万→2.7万（約83%削減）、継続的なコスト削減効果
    • 出力トークン消費は大きく変化せず （出力トークンは単価が5倍だが量が少ない）

  • 考察

    • トークン消費削減は コード量の削減ではなく、エージェントが読むべきファイルの最小化 に依存
    • ファイル分割だけでなく、 論理的な切り出しと重複排除 が重要
    • エージェント（特にClaude Code）は リファクタリングの自律的提案や適用が苦手、人間による指示が必須
    • 実験全体で 最大500万トークン消費 （計画立案・実験設計含む）、今後はより正確な計測が課題

  • 今後の展望

    • より複雑な変更や、コードベース全体へのリファクタリングの適用実験
    • 継続的リファクタリング や異なるアプローチの効果測定
    • トークンコストと開発効率の最適化手法の模索

代表的変更内容（プロンプト例）

  • Rustプロジェクトにて、Firestore層へ ItemWatchStore という新しいpublic async traitを追加
    • 3つのメソッド：watch_item, unwatch_item, watched_items_for_user
    • Firestoreコレクションitem_watchesに保存、各ドキュメントはitemId, userId, createdAtを持つ
    • Rust構造体は不要、戻り値はVec<String>
    • FakeStoreとFirestore両方でtraitを実装

まとめ

  • 大規模エージェント生成コードのリファクタリング は、将来的なトークン消費の大幅削減に寄与
  • ファイル分割・重複排除・論理的整理 がコスト削減の鍵
  • エージェントの自律的リファクタリング能力には限界があり、 人間の指示・設計が不可欠
  • 本実験は、 今後のAIエージェント活用開発における生産性・コスト最適化 の第一歩

Hackerたちの意見

オチは「リファクタリングはトークン消費を減らす」ってことだね。こういうメリットを数値化しようとする努力は評価するよ。マーチン・ファウラーがリファクタリングについての本を一冊書いてることも言っておくべきだね。彼は「リファクタリングするための必須条件は[...]しっかりしたテスト」って言ってるけど、これが本当のメリットだと思う。AIがどうであれ、良いテストは人間でもロボットでもリグレッションを防いでくれるし、仕様をエンコードするのにも役立つんだ。

└

（一応言っておくけど、この記事はmartinfowler.comに載ってるけど、マーチンは著者じゃないよ。ThoughtworksのCTO、ジャイルズ・エドワーズ＝アレクサンダーの名前がクレジットされてる。）

これに関するデータがあるのはすごく興味深いね。私の経験とも一致してる。LLMはよく整理されたコードから大きな恩恵を受けるけど、そういうコードを作るのは得意じゃないみたい。ほとんどの人間の開発者と同じだと思う！

└

自分のために「無駄取り」の時間を明確に予算に入れてるよ。実際、今も右の窓のところでやってる。ネット上のAIから大きな恩恵を受けてるけど、整理するための時間も必要だね。俺はまだ「すべての行を読む」チームにいる。実際、他のチームのブロッカーになってたから、レビューをわざと後回しにしたこともある。何かを渡したら、今度は普段よりも大きな負債を抱えることになるけど、他のチームを早く解放するためにはそれが価値がある。AIのおかげで、技術的負債を取り除くのが楽になったし、俺の経験では、技術的負債を解決する方法を指導してくれるのも結構良い。別の人の経験は異なるけどね。

└

俺もその通りだと思う。リファクタリングの際に、どうリファクタリングするかを手助けすることで、より良いコードの形を作ることができたこともあった。良いリファクタリングの例を示すことは、たとえオープンソースのリポジトリでも、どのようにするべきか、しないべきかを示すのに大いに役立つ。

コードの量がほとんど変わらなかったのは興味深いね。私の経験では、ゴチャゴチャしたコードをリファクタリングすると、行数が半分になることは珍しくないよ。

└

両方の方向に行くことがあるね。行数はリファクタリングが解決しようとする目標にはあまり適した指標じゃないよ。

└

行数よりも質が大事。プロジェクトによっては、コードがあまりなかったり、十分なテストやドキュメントがなかったりすることもある。コードは主に他の人や未来のためにあるもので、作成者が他のプロジェクトに移ることを考えているならなおさら。

└

そうだね、オチは「この17,000行のコードが2,000行になった」ってなると思ってたけど、結局同じくらいの量なんだね。ちょっと面白い。最後の変更が一番大きな影響（トークンが4倍減少）を与えてるのも興味深いし、それが単一ファイルのLOCの最大の減少にもつながってる。

└

うん、これには私も本当に驚いたよ。だから、その図の一番上の行を入れたんだ。エージェントがリファクタリングを進める前に予測した内容とも一致してないしね。ここで何が起こっているのかを正確に理解するためには、さらに作業が必要だね。

これは人間が関わることが不可欠なものだと思う。エージェントによるリファクタリングは意味があるけど、1つのLLMが作業をレビューすることで、最初のタスクの出力に集中している間に見逃したことを見つけられるからね。でも、レビュアーのエージェントはこのプロジェクトが実際に何なのかを理解しているのかな？ コードがどのように組み合わさって作業を行うのか？ つまり、どの部分のコードが冗長で、どれがよりエレガントにできるのか。コードベースをリファクタリングするようにコーディングエージェントに頼むのは、外科医に運動能力を上げてくれって頼むようなものかも。エージェントはこれを適切に行うために、かなり全体的な視点が必要だと思う。大きなファイルを複数のファイルに分けるだけでは、コードがどれが一緒にあるべきか、どれがユーティリティ関数に抽出できるかという理論がない限り、表面的なリファクタリングに過ぎない。ファイルを分けることは、因子を分解することなのか、それとも最終的にまた足し算される小さな数に分けることなのか。私が言いたいのは、エージェントは全体のシステムを実際には理解していないことが多いってこと。API経由で取得されているものを保存して計算するシステムを実装するかもしれない。人間はしばしばプロジェクトの全体的な感覚と、タスクに集中する際の正確なメスを持っているんだ。「ああ、これを見れば、このJSONにはすでにこのデータのキーがあるね」って感じで。

└

俺は、ナレーションを担当することで、数ヶ月かかる予定だったものを1週間ほどで大幅にリファクタリングできたんだ。リファクタリングの経験や他の人のコードベースへのアプローチが役立ったし、俺自身が元のアーキテクトで、必要に応じて元の意図や現在の意図を説明できたのも大きい。あまり一般的ではないけど、能力があって扱いやすい言語を使って、依存関係の脆弱性をあまり管理しなくて済んだ。JavaScriptやPythonのバイアスを取り除く努力をしたら、すごくパワフルになって、ひらめいた瞬間から一気に進んだ。プロジェクトはJSR-223言語の世界で遊んでいて、人気のある多くの言語でスクリプトが書けたけど、全部JVMで動かす必要があったんだ。

Hacker Newsで議論の続きを見る