【ITニュース解説】Your Agent Says It Made It Faster. Benchmark Both Branches Before You Land

AIエージェントが「コードを3倍速くした」と主張しても、その言葉をそのまま信じるのは危険である。なぜなら、多くの場合、そのような性能向上は検証されていない単なる「主張」に過ぎないからだ。システムエンジニアを目指す上で、このような主張に直面したとき、それを科学的に検証する能力は非常に重要となる。

過去の研究でも、AIコーディングエージェントに実際の最適化タスクを与えたところ、正しく動作し、かつ人間が達成した速度向上の95%以上に達する成功率は5%未満という結果が出ている。これは、AIがコードのボトルネック（性能の足を引っ張る部分）を見つけるのが苦手だったり、単に表面的な変更を加えるだけの「怠惰な最適化」をしてしまったりすることが原因と考えられている。つまり、AIが性能向上を主張しても、それはあくまで「仮説」であり、必ず自分自身で測定・検証する必要がある。

では、具体的にどのように検証すれば良いのだろうか。まず、性能を比較するためのコードを正確に用意することが最初のステップとなる。AIエージェントが作業したのが例えばhermes/speed-up-parselineというブランチだったとする。この場合、比較すべきは「AIエージェントが作業を開始する前の状態のコード」と「AIエージェントが変更を加えた最新の状態のコード」の二つだ。git worktreeコマンドを使うと、一つのGitリポジトリから複数の作業ディレクトリを同時に作成できるため、これを活用する。

git worktree add --detach ../app-base $(git merge-base main "hermes/speed-up-parseline")というコマンドで、AIエージェントのブランチがmainブランチから分岐した時点のコード（これを「マージベース」と呼ぶ）を../app-baseディレクトリに展開する。これにより、AIエージェントが行った変更以外の要素が比較に混ざるのを防ぐことができる。また、git worktree add --detach ../app-agent hermes/speed-up-parselineでAIエージェントの最新の変更を含むコードを../app-agentディレクトリに展開する。--detachオプションを使うことで、すでにチェックアウトされているブランチを別のワークツリーでも使えるようになる。

コードの準備ができたら、次に性能を測定する。測定対象がコマンドラインプログラムやビルドステップなど、プログラム全体であればhyperfineというツールが非常に役立つ。まず、二つのワークツリー（app-baseとapp-agent）それぞれで実行ファイルをビルドする。例えばGo言語のプログラムであれば、go build -o ~/bench/base ./cmd/appのようにして実行ファイルを作成する。

その後、hyperfine --warmup 3 --runs 30 -n base "$HOME/bench/base convert big.csv out.json" -n agent "$HOME/bench/agent convert big.csv out.json"のようにコマンドを実行する。--warmup 3は実際の測定前に3回実行して、ディスクキャッシュなどをウォームアップすることで、測定結果が安定するようにする。--runs 30は各コマンドを30回実行して十分なサンプル数を確保する。--prepareオプションを使えば、各実行前に出力ファイルを削除するなど、環境をリセットして公平な測定をすることができる。hyperfineは平均実行時間やそのばらつきを出力し、さらにwelch_ttestスクリプトを使えば、二つの結果の間に統計的に有意な差があるかを判断できる。もしp値が0.05未満であれば、その差は偶然ではないと判断できる。

もし性能向上を主張しているのがプログラム全体ではなく、特定の関数であれば、Go言語の標準testingパッケージに用意されているベンチマーク機能を使う。b.Loop()を使ってベンチマーク関数を記述し、その中で測定したい関数を呼び出す。この際、b.ReportAllocs()を追加すればメモリ確保の回数も測定できる。

ベース側とエージェント側で同じベンチマークファイルを用意し、それぞれgo test -c -o ~/bench/base.test ./csvxのようにしてベンチマークテスト用の実行ファイルをビルドする。その後、for i in $(seq 20); do ~/bench/base.test -test.run='^$' -test.bench=ParseLine -test.benchmem >> old.txt; ~/bench/agent.test -test.run='^$' -test.bench=ParseLine -test.benchmem >> new.txt; doneのようにループで20回ずつ実行し、結果をファイルに出力する。benchstat old.txt new.txtコマンドを実行すると、二つの結果ファイルを比較分析してくれる。

benchstatの出力は、各ファイルのメディアン（中央値）とその95%信頼区間の範囲、そして二つの間の変化率、p値、サンプル数（n）が表示される。例えば「1.718µ ± 1% 1.423µ ± 1% -17.20% (p=0.000 n=10)」という表示は、最初の測定が1.718マイクロ秒で、二番目が1.423マイクロ秒であり、17.20%の改善があったことを示す。p値が0.000であれば統計的に非常に有意な差があることを意味する。もし~と表示された場合は、測定可能な速度向上がなかったことを示す。

測定結果を読み解く際にはいくつかの注意点がある。~は速度向上がないと判断する。一度結果が出た後に、期待する結果が出るまで何度も測定を繰り返してはならない。これは「多重検定」と呼ばれ、結果に偏りを生じさせる。また、p値が0.05未満でも、約5%の確率で実際には差がないにも関わらず有意差があるように見える「偽陽性」が発生する可能性がある。

さらに重要なのは、統計的に有意な差があっても、それが実用上「大きな」差であるとは限らないことだ。データが非常に正確でノイズが少ない場合、ごくわずかな差でも統計的には有意と判断されることがある。そのため、単に「速くなった」と判断するだけでなく、「この程度の速度向上が、このコードの複雑化に見合うか」という実用的な視点で判断する必要がある。AIエージェントの「3倍速い」という主張が間違っていても、例えば「17%速くなった」という結果が得られたら、その事実を正確に記録し、AIエージェントにフィードバックすることが、今後の改善につながる。そして、どんなに速くなっても、コードが正しく動作しなければ意味がないことを忘れてはならない。

これらの測定と分析を通して、AIエージェントの主張を盲信せず、常に客観的なデータに基づいてコードの変更を評価する習慣を身につけることが、システムエンジニアとして成長する上で不可欠である。