Googleが測ったエージェントの「寄り道」　TODOのバグを追うとトークン77%増

米Googleは11月6日付の開発者向けブログの記事で、数千人のエンジニアが使ったコーディングエージェントの記録を、同社自身が分析した結果を公表した。TODOが指すバグを頼まれていないのにエージェントが追う寄り道は、1セッションあたりトークンを77%、ステップを70%、待ち時間を105%増やした。寄り道の先は閉じたバグが4割強、開いたバグが6割近くだった。数字は社内の計測で、第三者の検証はない。

バグ番号つきTODOが寄り道を誘う

Googleの開発者向けブログの記事「Agent Distraction」は、ソフトウェアエンジニアのSam Saccone氏とデータサイエンティストのMadhuri Garikapati氏が書いた。2人の出発点は、人が読み飛ばすコードの断片を、エージェントは「やるべきこと」と受け取るという観察だ。エージェントは計画と調査の段階で多くのファイルを読む。そこで古い仕様やとうに直ったバグ、更新の遅れた文書を拾うと、トークンと時間を余計に使う。悪い時は誤った前提のまま実装を進めてしまう。

月に数百万あるセッションを人がレビューして寄り道を数えることはできない。そこで2人は、バグの番号を書き込んだ「TODO(bug/...)」と「FIXME(bug/...)」のコメントを目印に選んだ。TODOはバグが片付いた後も残りやすく、リンク先のバグ票を見れば、そのバグがまだ生きているかが分かる。エージェントが読んだTODOごとにバグの状態と利用者のプロンプトを突き合わせれば、必要な作業と無駄な寄り道を機械で分けられるという考え方だ。

この形のTODOは、Googleが公開しているC++のスタイルガイドの書き方でもある。ガイドはTODOの後に、バグの番号や担当者など詳しい事情を知る手がかりを書くよう求めている。

寄り道でトークンが77%増える

分析に使ったのは、数千人のエンジニアのエージェント操作の分散トレースで、エージェントのステップは数億に上る。ファイルを読んだセッションのうち13%で、エージェントがバグ番号つきのTODOかFIXMEを目にした。目にした場面の94%では無視したが、6%ではそのバグ番号に向けて次の行動を起こした。そのうち83%は、開発者が頼んでいない行動だった。

頼まれていない寄り道をバグ票の今の状態と照らすと、失敗は2種類に分かれた。4割強の41%は、すでに閉じたバグを追っていた。内訳は、直って確認済みのバグが32%、対応しないと決まったバグが9%で、ほかに2%が重複か閲覧制限つきの票だった。残る57%は、まだ開いているバグに手を広げた例で、そのうち61%は調べるだけ、39%はコードを書き換えていた。

コストの数字は、開発者、コードの複雑さ、タスクの種類、モデルの階層、読んだファイルの数、最初のプロンプトの長さ、バグの参照が出たステップを揃えた回帰分析から出している。手法は多元の固定効果モデルで、標準誤差は開発者ごとにまとめた。その結果として、頼まれていないバグへの寄り道は1セッションあたりステップを70%、トークンを77%、待ち時間を105%増やしたとし、どれもp<0.0001だった。この数字は閉じたバグと開いたバグの寄り道を合わせた全体の値で、古いTODOだけの代償を切り出したものではない。

記事は具体例を2つ載せている。1つは、別のバグを調べていたエージェントが「SurfaceControlTest.java」のTODOを読み、2023年に直ったバグを掘り下げ始めた例だ。もう1つは、調べていたバグの中でTODOを見つけたエージェントが、頼まれずに「ModelDownloaderV1」のコードを書き換えた例で、後から利用者が作業の範囲を問いただし、モデルは範囲を広げすぎたと認めた。

数字は社内の計測に限られる

この分析は、Googleが自社のコードとエージェントで測ったものだ。記事には、どの製品やモデルのエージェントか、記録を集めた期間、セッションの総数が書かれていない。数字の基準にも揺れがある。83%は「行動のうち5件に4件超」と説明しつつ、括弧では「83% sessions」と書いている。

記事に限界を論じた節は無い。著者が自分で認めているのは、2つの例がどちらも小さな寄り道だったことだ。それでも時間とトークンと人の手間を使ったとしている。TODOは目印として選んだ1種類にすぎず、古い仕様書や文書が生む寄り道は数えていない。コストの数字は条件を揃えた回帰分析から出した値で、記事は比べる基準のセッションを明記していない。寄り道を止めた前後で測った値でもない。

古いTODOを数千件消した

Googleは対策として、すべてのコードを調べるエージェントを作った。まず、直ったか不要になったバグを指すTODOを拾った。ただ、それだけではTODOがまだ意味を持つかは判断できなかった。そこでエージェントはバグの経緯やファイル、コードの変更の履歴を、時には数年分さかのぼって確かめた。TODOとその意図が不要と確かめられた時だけ、削除の変更をレビューに出した。この掃除のエージェントは過去6か月で数千件の不要な参照を消し、人のレビューでの採用率は95%を超えたという。

記事は結びで、エージェントにやさしいコードには、よく通る経路のコードの健全さだけでは足りないと書く。対処として、コミット前の静的解析、コード全体のスキャン、古いTODOを直すコーディングエージェントを挙げた。価値が低いとして後回しにしてきた負債の掃除は、エージェントが大きな規模でコードを触る今、優先度を見直すべきだとしている。

測られた寄り道の4割強は閉じたバグに向かい、Googleの掃除もその種のTODOに絞られていた。閉じたバグと開いたバグへの分を合わせると、TODOが指すバグを頼まれずに追う寄り道は1セッションのトークンを77%増やす。これがGoogleの社内の計測が示した、TODOによる寄り道の代償である。

編集部の見方

編集部はこの発表を、リポジトリに残ったコメントもエージェントへの指示の一部として働くことをうかがわせる計測として読む。Googleの計測では、バグ番号つきのTODOを目にした場面の94%でエージェントは無視し、次の行動に移ったのは6%だった。寄り道の重さは別の数字で、頼まれていないバグへの寄り道は、寄り道をしたセッション1回あたりトークンを77%増やした。ファイルに「やること」が残っていれば、作業が逸れることがある。手元では、閉じたバグを指すTODOの数を数えるとよい。ただしプロンプトの工夫で防げるかは試されておらず、バグ番号を書かない運用のリポジトリで同じ割合になるかも分からない。