コードフラッシュ分析：2つのPRで118件のパフォーマンスバグを発見（Claude Codeで記述）

AI生成コードのパフォーマンス分析

Codeflashは自社の最適化ツールを使用して、Claude Codeで書かれた2つのプルリクエストを分析しました。分析対象となった機能は、Java言語サポート（パーサー、コンテキスト抽出器、計装、テストランナー、アサーショントランスフォーマーを含む52,000行）とReactフレームワークサポート（コンポーネント発見、プロファイリング、ベンチマーキング、コード置換をカバーする24,000行）です。

主な発見

これら2つのPRだけで、Codeflashは必要以上に著しくパフォーマンスが低下している118の関数を特定しました。これらは特殊なケースではなく、最適化ツールのホットパスに位置し、すべてのユーザーの最適化ジョブごとに実行される関数でした。

非効率性のパターン

• 壊滅的に非効率なアルゴリズム: Javaコンテキストモジュールの型抽出関数は、tree-sitterベースの抽出ではなく単純な文字列スキャンで実装されていたため、必要な速度の446倍遅くなっていました。同様の理由で、ヘルパー関数ファインダーは74倍遅くなっていました。
• 冗長な計算: 関数は既に解析済みのデータを再解析したり、既に走査済みのツリーを再走査したり、文字列を文字ごとに再構築したりしていました。アサーションターゲット呼び出しビルダーは、呼び出しごとにソースバイト変換を再計算するため（キャッシュせず）、19倍遅くなっていました。React PRのインポート挿入ユーティリティは、冗長なツリートラバーサルのため36倍遅くなっていました。
• キャッシュの欠如: 同じ入力で繰り返し呼び出される関数が、毎回ゼロから結果を計算していました。React PRの型定義抽出器は、中間結果をメモ化しないことで16倍遅くなり、エクスポートチェッカーも同様の理由で9倍遅くなっていました。
• 最適でないデータ構造: セットを使用すべき箇所でリストを使用していたり、ハッシュ検索が機能する箇所で線形検索を行っていたり、ループ内で文字列連結（結合ではなく）を行っていたりしました。ブレースバランスパーサーは、非効率なデータ構造選択により3倍遅くなっていました。

具体例：19倍のパフォーマンス改善

Claude Codeは、バイトオフセットを文字位置に変換するためにこの関数を書きました：

# ファイル内で見つかったすべてのASTノードに対して呼び出される
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

Codeflashはこれを以下のように置き換えました：

# ルックアップテーブルを一度構築し、各ノードに対して二分探索を行う
from bisect import bisect_right
cum_bytes = [0]
for ch in source.decode("utf8"):
    cum_bytes.append(cum_bytes[-1] + len(ch.encode("utf8")))
start_char = bisect_right(cum_bytes, start_byte) - 1
end_char = bisect_right(cum_bytes, end_byte) - 1

元のコードは、呼び出しごとにファイルの先頭からバイトプレフィックス全体をデコードします — ルックアップごとにO(n)です。数百のASTノードを持つファイルでは、同じバイトを何百回も再デコードすることになります。最適化されたバージョンは、ルックアップテーブルを一度構築し、二分探索を使用します — O(n)が一度、その後ルックアップごとにO(log n)です。

この記事は、AIコーディングエージェントを使用するかどうか（使用を推奨しています）ではなく、使用した後にコードに何が起こるかについて強調しています。これらのパフォーマンス問題は、AIエージェントがパフォーマンス最適化よりも正確性と可読性に焦点を当てることで体系的に導入する、新しい種類の技術的負債を表しています。