ハクソク

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

コードのクリーンさはコーディングエージェントに影響を与えるか？制御されたミニマルペア研究

2026年7月6日原文(arxiv.org)

概要

  • 本論文は、 自律型コーディングエージェント がコードの「 クリーンさ」にどのように影響されるかを評価
  • 構造的・スタイル的品質 （クリーンさ）がエージェントの作業効率に与える影響を検証
  • 同一アーキテクチャ・依存関係 を持つがクリーンさのみ異なるリポジトリの比較実験
  • タスク完了率 には影響がないが、 消費トークン数やファイル再訪問回数 に大きな差
  • AI時代でも伝統的なメンテナンス原則の重要性 を示唆

コードのクリーンさが自律型コーディングエージェントに与える影響

  • 自律型コーディングエージェント の普及状況
  • 従来は タスク完了率 のみで評価されてきた背景
  • コードのクリーンさ （構造的・スタイル的品質）がエージェントの 作業効率や行動 に与える影響の未解明
  • 評価プロトコル として「ミニマルペア」リポジトリ手法を導入
    • アーキテクチャ・依存関係・外部動作 は同一、 静的解析ルール違反 や 認知的複雑性 のみ異なるリポジトリの比較
    • エージェントパイプラインで、クリーンなリポジトリを劣化または乱雑なリポジトリをクリーン化してペアを作成
  • 33タスク を6組のリポジトリペアで設定
  • Claude Code を用いて660回の試行
  • タスク完了率 には有意な差が見られず
  • しかし、 クリーンなコード では
    • 消費トークン数が7〜8%削減
    • ファイル再訪問回数が34%減少
  • コードのクリーンさ がエージェントの
    • 計算コスト
    • ナビゲーション効率 に大きく寄与
  • AI開発時代 でも、 伝統的なメンテナンス原則 （可読性・保守性）の重要性を再確認

コーディングエージェントの評価手法と今後の示唆

  • モデル選択
  • ハーネス構成
  • プロンプト設計
  • これらに加え、 コードクリーンさ もエージェント行動に影響する新たな要因
  • ソフトウェア開発現場 でのAI活用時、 クリーンコード維持 の意義が高まる
  • 今後の エージェント開発・評価基準 に、 コードクリーンさ を組み込む必要性

参考情報

  • 分野 ：Software Engineering (cs.SE), Artificial Intelligence (cs.AI)
  • arXiv ID ：arXiv:2605.20049
  • DOI ：https://doi.org/10.48550/arXiv.2605.20049
  • 著者 ：Priyansh Trivedi
  • 投稿日 ：2026年5月19日

Hackerたちの意見

自分の経験から言うと、コードベースがデッドコードや冗長なコード、到達不可能なフォールバック、漏れた抽象、半端なデザインパターンで散らかっていると、エージェントのパフォーマンスに大きな差が出るよね。逆に、コードがきちんと整理されていて、データフローが明確で、良いカプセル化とクリーンなアーキテクチャがあれば、最初や二回目の試行でうまくいくことが多い。悪いコードだと、フロンティアモデルが何度もコードレビューやQAをしなきゃならないのを見てきたから。

└

あなたのコメントを読んで、同意しつつも、なぜこれが悪いコメントなのかを感じていたんだ。こういう逸話的な発言は科学的な議論の対極だってことに気づいた。ここには質問に答えようとしている論文があって、逸話的な証言は読者にバイアスをかけるだけで、問題について客観的に結論を出すための価値を何も加えない。最も有益な議論は、みんなで論文を読み、その方法論や結果を批評することだと思う。

└

そう感じるけど、ちょっとパラノイア気味で、頻繁にリファクタリングやコード整理をしてるから、確実に差があるとは言えないな。ただ、LLMがそんなに良くないって文句を言う人は、散らかったコードベースを持ってるタイプに見える。

└

散らかったコードベースで作業してると、同じ気持ちになるよね… どこかで、ひどいパターンがうつってきちゃうし…

└

上で挙げたような問題、例えばデッドコードの削除やコードの重複、到達不能コードなんかは、ほとんどのプログラミング言語のエコシステムで、ずいぶん前から決定論的リンターを使って解決されてるよ。LLMにスクリプトを実行させて、これらをチェックさせることができるし、同じスクリプトをプリコミットフックとして実行することで強制することもできる。これを自分が関わるすべてのコードベースでしっかり設定することで、エージェント的なコーディングが一番効果を発揮してる。自分が使ってるさまざまなリンターについて、もっと詳しく書いた記事はこちらにあるよ: https://www.balajeerc.info/Use-Deterministic-Guardrails-for-...

└

これらのことをずっと使ってるけど、毎回「人間に接するように扱う」ってやると、パフォーマンスが良くなる気がする。エージェントが散らかったコードベースよりも、クリーンなコードベースの方がパフォーマンスが良くなるなんて想像できないよ。しっかりした仕様書やドキュメントにアクセスできると、さらに良くなるしね。

「エージェントパイプラインが[...] 散らかったリポジトリをクリーンにする」って、これってひどいアプローチだと思う。全体の研究を否定するのに十分な理由だよね。どうやら、この研究の「ミニマルペア」の半分はこんな風に作られたらしい。AIが「クリーンにした」リポジトリが実際に良いコードベースを代表しているなんて、全く信じられない。

└

AIにめちゃくちゃにされたクリーンなリポジトリを信じられる？

└

ここでの第一著者です。ちょっと説明させてください。「クリーン」の概念は、エージェントにより良いコードを書かせることじゃないんです。むしろ、50〜100個の静的解析ルール違反（とコードのLOC）のリストを渡して、それを取り除くように頼むんです。そして、ルール違反が解決されたかをチェックします。これらの違反を取り除くためにコードを書き直すのにLLMを使うのは、かなり一般的なやり方です。Sonarの既存のワンショットLLMベースのアプローチ[1]（1年以上運用中）や、最近のエージェント的アプローチ[2]がうまく機能しています。 [1] https://www.sonarsource.com/solutions/ai/ai-codefix/ [2] https://www.sonarsource.com/products/sonarqube/remediation-a...

エージェントが残したスタブやWETなクソコードをナビゲートできるようになったとしても、実際に何が起こっているのかを人間が追えないコードベースが欲しいの？

└

エージェントが何でもやったとしても、英語はコードが何をしているかを正確に表現しているわけじゃない。だから、少なくとも自分はコードについて「コードで」話したいと思ってる。

└

なんか、DRYをやりすぎてることがあるよね。小さい関数が共通のヘルパーに分けられるロジックを持ってるのに、普通のプログラマーはそんなことしないと思う。だって、それってクリーンな抽象じゃないし、どっちかを変更したいときに壊れちゃうから。

Hacker Newsで議論の続きを見る