コードのきれいさはコーディングエージェントにも関係ある？

本記事では、コードの「きれいさ」が、コーディングエージェントの動きにどれくらい影響するのかを調べた事例を紹介します。

ここでいうコーディングエージェントとは、Claude CodeやCursorのように、指示を出すとコードを読んだり、修正したり、テストを動かしたりしてくれるAIツールのことです。

こうしたツールはすでにかなり広がり始めていますが、今回の本題は「今すぐ開発現場が全部変わる」という話ではありません。むしろ、これからAIエージェントがもっと大きな範囲の開発作業を担うようになったとき、コードベースの状態がどれほど重要になるのかを考えることです。

よくあるコーディングエージェントの評価は、「タスクを解けたかどうか」が中心です。バグを直せたか、テストを通せたか、新しい機能を実装できたか、という見方。

ただ、研究者たちはそこに少し違う問いを立てています。

人間にとって読みやすいコードは、AIエージェントにとっても扱いやすいのか。

たとえば、二千行の巨大な関数より、小さな関数に分かれていて名前もわかりやすいコードのほうが、人間には読みやすいはずです。では、同じことがAIにも言えるのでしょうか。

この論文は、その素朴だけどかなり重要な問いを、実験で確かめようとしています。

実験用ベンチマークの作り方

既存のベンチマークには、今回のような比較に向いた素材がありませんでした。そこで著者たちは、実験用のコードセットを自作しています。

きれいさだけが違うペアを作る

使われた考え方は、言語学でいう「ミニマルペア」です。これは、ほとんど同じだけれど、ある一点だけが違うペアのことです。

今回の場合は、機能や依存ライブラリやテスト結果は同じまま、コードのきれいさだけが違う二つのリポジトリを用意します。

コードのきれいさは、SonarQubeという静的解析ツールの違反数で測ります。静的解析ツールとは、コードを実行せずに読んで、まずそうな箇所を指摘してくれる道具です。違反が少ないほど、きれいなコードとして扱われます。

ペアの作り方は、次の二方向です。

どちらの変換でも、テストが通り続けることを確認しています。最終的には、Java系が三つ、Python系が三つ、合計六組のペアが作られました。

そのうち半分は、社内の非公開リポジトリです。これは、AIが学習データとして事前に覚えていたコードを使ってしまう、いわばカンニングのような状態を避けるためです。

タスクも実験用に作る

リポジトリのペアだけでは実験にならないので、著者たちはタスクも三十三個作っています。

タスク作成では、次のようなルールが置かれました。

タスクの種類は、大きく三つに分けられています。

この分け方によって、「どんな種類の作業でコードのきれいさが効くのか」まで見ようとしています。

測り方

実験では、コーディングエージェントとしてClaude Codeが使われ、モデルにはSonnet 4.6が使われています。

各タスクは、きれいなコード側と汚いコード側でそれぞれ十回ずつ実行されました。合計すると六百六十回の試行になります。

記録された指標は、単に成功したかどうかだけではありません。

重要なのは、ファイル再訪問です。これは、エージェントが一度触った場所にまた戻ってくる動きです。人間でいえば、「さっき直したところ、本当に大丈夫かな」と何度も見直しに行くようなものです。

結果

成功率はほとんど変わらない

まず一番大きな結果は、成功率です。

きれいなコードでも汚いコードでも、タスクを解ける割合はほぼ同じでした。差は一パーセント未満です。

つまり、「きれいなコードならAIが急に正解しやすくなる」というほどの劇的な変化はありませんでした。

ただし、これは「コードのきれいさは意味がない」という話ではありません。むしろ、成功率の裏側にある動き方が変わっていました。

きれいなコードではエージェントの動きが軽くなる

きれいなコード側では、トークン使用量や推論量が減っています。

大きいのは、ファイル再訪問が三分の一ほど減ったことです。

著者たちはこれを、きれいなコードではエージェントが迷いにくくなるからだと解釈しています。前に編集した場所に何度も戻る必要が減り、より自信を持って作業を進められるようになる、ということです。

この点は、今後の開発現場を考えるうえでかなり重要です。エージェントが長時間、自律的にコードを触るようになるほど、「迷わず進めるコードベース」の価値は大きくなるからです。

タスクの種類による違い

すべてのタスクで同じような効果が出たわけではありません。

複数モジュール型では効果が出やすい

複数のモジュールをまたぐタスクでは、きれいなコードのほうがはっきり軽くなりました。

これはかなり自然な結果です。複数の場所を行き来する作業では、コードの構造や名前のわかりやすさが手がかりになります。整理されたコードであれば、エージェントは必要な場所にたどり着きやすくなります。

一か所集中型では単純に軽くなるとは限らない

一方で、複雑な一か所を中心に直すタスクでは、トークン使用量はあまり変わりませんでした。むしろ、きれいなコード側のほうが開くファイル数が増えることもあります。

これは、汚い巨大関数をきれいにするときに、処理を小さな関数や別ファイルに分けることがあるためです。

人間にとっては読みやすくなっていても、エージェントにとっては確認すべき場所が増える場合があります。複雑さが消えるというより、広く分散することがあるわけです。

ばらつきの大きさ

この研究は、結果のばらつきが大きいことも正直に示しています。

同じタスクを同じコードで十回動かしても、重い試行は軽い試行の二・五倍ほどトークンを使うことがあります。

また、タスク単位で見ると、きれいなコード側のほうがトークンを多く使うケースもあれば、大きく少なくなるケースもあります。

そのため、この論文は「一つのタスクだけ見て結論を出すのは危ない」という慎重な立場を取っています。

対照的な二つの事例

大きく効いた事例

一つ目の事例は、commons-bcelというライブラリです。

汚いコード側には、数百行にわたる大きなswitch文がありました。きれいなコード側では、それが小さな名前付きヘルパー関数に分けられていました。

こうなると、エージェントはキーワード検索で目的の場所にたどり着きやすくなります。結果として、トークン使用量は約三十五パーセント減りました。

この事例では、コードをきれいにしたことが、エージェントの探索コストをはっきり下げています。

逆に重くなった事例

もう一つの事例は、genieというリポジトリです。

こちらでは、中心となるロジックはあまり変わらず、周辺部分だけがヘルパー関数に分けられていました。その結果、きれいなコード側では見るべきファイルが増え、エージェントが余計に歩き回る形になりました。

結果として、トークン使用量は約八パーセント増えています。

この二つの事例からわかるのは、コードを整理すれば必ず軽くなるわけではないということです。重要なのは、複雑さの中心まできちんと整理できているかどうかです。

コメント量の影響

著者たちは、「実はコードのきれいさではなく、コメント量の違いが効いているだけではないか」という可能性も検証しています。

コード中の説明文が多かったり少なかったりすると、それだけでトークン使用量が変わってしまう可能性があります。そこで、コメント量をそろえたうえで再実験しました。

その結果、きれいなコード側の優位は残りました。むしろ差がよりはっきりした部分もあります。

つまり、この効果はコメントの量だけでは説明できません。コードの構造そのものが、エージェントの動きに影響していると考えられます。

注意点

著者たちは、注意点も明記しています。

今後、エージェントが一回きりの修正ではなく、数日、数週間、あるいは継続的にコードベースを触るようになると、コードのきれいさの効果は積み上がるかもしれません。逆に、エージェントが慣れていけば差が小さくなる可能性もあります。

この点は、まだこれからの研究課題です。

まとめ

今回の論文の結論は、とてもシンプルです。

コードのきれいさは、AI時代にもちゃんと関係ある。

ただし、それは「タスクの成功率を大きく上げる」という形ではありません。むしろ、エージェントが作業するときの迷いを減らし、トークン使用量や推論量を抑え、同じ場所を何度も見直す動きを減らす、という形で効いています。

ファイル再訪問が三分の一ほど減ったことは象徴的ですね。人間にとって読みやすいコードは、AIエージェントにとっても扱いやすい可能性が高い、ということです。

これから開発現場でエージェントがより深く使われるようになるなら、コードのきれいさは単なる美学ではなくなります。人間のための保守性だけでなく、AIに仕事を任せるための土台にもなっていきそうです。

本記事の関連研究