パフォーマンスの盲点：AIエージェントは遅いコードを書く

コードはすべてのテストに合格しました。リンターはクリーンでした。型チェッカーも満足していました。コードレビューも承認されました。その関数は、本来必要な速度の446倍遅かったのです。¹

コードパフォーマンス最適化ツールであるCodeflashは、Claude Codeによって完全に生成された2つのプルリクエストを分析しました。Java言語サポートモジュールとReactフレームワーク統合にわたる76,000行のコードです。¹ その結果、重大なパフォーマンス問題を持つ118の関数が見つかりました。速度低下は3倍から446倍に及びました。最悪のケースは、呼び出しのたびにAST全体を再スキャンし、走査結果をキャッシュしない型抽出関数でした。動作は正しい。パフォーマンスは壊滅的。

この発見は異常値ではありません。NumPy、Pandas、SciPyなどのリポジトリにわたる498の最適化タスクのベンチマークであるSWE-fficiencyでは、トップパフォーマンスのLLMエージェントが、同じタスクでエキスパート開発者が達成した高速化の0.15倍未満しか達成できませんでした。² また、Claude 3.5、OpenAI o1、Llama 3.2を26の高性能コンピューティングコードでテストした別の研究では、Claude 3.5がシリアル最適化で1.02倍の高速化（実質的にゼロの改善）を達成し、30%のケースで不正確なコードを生成しました。³ Codeflash独自の100,000のオープンソース関数の分析では、AIが提案した最適化の90%が不正確であるか測定可能な効果がなく、正確なものの中でも73%が5%未満の改善にとどまりました。⁴

パフォーマンスは、AIコーディングツールが見ていない次元です。すべての標準的な品質ゲート（リンター、型チェッカー、テストスイート、コードレビュー）は正確性を検証します。効率性を検証するものはありません。その結果、すべてのチェックを通過しながら、投入されるすべてのシステムを劣化させる、AI生成コードに対する見えない税金が生まれています。

TL;DR

AIエージェントは正しいが遅いコードを書きます。CodeflashはClaude Codeの出力76,000行にわたって118のパフォーマンス問題を発見し、速度低下は3倍から446倍でした。¹ 学術的なベンチマークもこのパターンを裏付けています。LLMは最適化タスクでエキスパートの高速化の0.15倍未満しか達成できません。² 原因は構造的です。訓練データは正確性に報酬を与え、標準的な品質ゲートはパフォーマンスを測定しません。突破するにはパフォーマンスインフラが必要です。ユニットテストと並行したベンチマーク、フックでのASTベースのパターン検出、そして標準的なワークフローステップとしてのプロファイリングです。

要点

個人の開発者向け。 ホットパス内のAI生成関数ごとに、検証ステップでtimeやプロファイラーを追加してください。446倍の速度低下は、すべてのテストとすべてのリンターを通過しました。それを検出できた唯一のゲートはベンチマークです。「動く」ことは必要条件であって十分条件ではないと考えてください。「どれくらい速く動くか？」を標準的なフォローアップ質問にしましょう。

チームリード向け。 パフォーマンスの退行は、Good-Enough Plateauの見えない形態です。すべての機能テストに合格するAI生成コードは、誤った完了感を生み出します。ユニットテストと並行して、CIにパフォーマンスベンチマークを追加してください。Faros AIのデータによると、AI支援チームは21%多くのタスクを完了する一方で、9%多くのバグを生成しています。⁵ パフォーマンスバグはその9%にカウントされていません。なぜなら、誰もそれを測定していないからです。

プラットフォームエンジニア向け。 欠けているゲートを構築してください。リンターはスタイルをチェックします。型チェッカーはコントラクトをチェックします。テストスイートは振る舞いをチェックします。標準的なCIパイプラインでアルゴリズムの複雑性やランタイム特性をチェックするものはありません。ASTベースのパターン検出（Semgrepルール、ast-grepパターン、またはカスタムフック）は、最も一般的なパフォーマンスのアンチパターンを検出できます。冗長な走査、メモ化の欠如、不要なコピーです。

118のバグの実態

Codeflashによる2つのClaude Code PRの分析は、AI生成のパフォーマンス問題に関する最も詳細な公開データセットを提供しています。¹ 2つのPRは合計76,000行でした。Java言語サポートが52,000行、Reactフレームワークサポートが24,000行です。どちらも機能的でした。どちらもテストスイートに合格していました。どちらも実世界の負荷で劣化するコードを含んでいました。

根本原因は4つのカテゴリに分類されます。

非効率なアルゴリズム。 最も多いカテゴリです。バイトオフセットを行位置に変換する関数が、事前計算されたルックアップテーブルによるO(log n)の二分探索の代わりにO(n)のスキャンを使用していました。コードは読みやすく、変数名は説明的で、ロジックは正しかったです。計算量クラスが間違っていました。

冗長な計算。 キャッシュ可能な値を再パース、再走査、または再計算する関数です。ヘルパー関数ファインダーは、毎回の呼び出しで同じソースファイルを再パースしていました。メモ化デコレーターを使えば、最初の呼び出し後に74倍のオーバーヘッドをゼロに削減できたはずです。

キャッシュとメモ化の欠如。 冗長な計算と密接に関連していますが、データがより広いスコープで利用可能であった点で異なります。型定義エクストラクターは、最初のアクセス時にインデックスを構築する代わりに、毎回AST全体を走査していました。パターンとしては、エージェントが各関数をループ内でどのように呼び出されるかを考慮せずに、独立して書いているということです。

最適でないデータ構造。 セットや辞書がO(1)のルックアップを提供できる場面でのリストスキャンです。エクスポートチェッカーはメンバーシップをテストするためにリストを反復していました。セットへの変換で、9倍のオーバーヘッドを完全に排除できたはずです。

エージェントが遅いコードを生成する理由

パフォーマンスの盲点は、特定のモデルのバグではありません。原因は構造的で、訓練データ、評価基準、ワークフローの前提という3つのレベルで作用しています。

訓練データは可読性に報酬を与える

LLMは訓練データにおけるコードの分布から学習します。どのアルゴリズムでも、最も一般的な実装はナイーブなものです。チュートリアルコードは明快さを優先します。Stack Overflowの回答は正確性を優先します。オープンソースのコードにはパフォーマンス最適化されたバージョンも含まれますが、素直な実装に桁違いの数で上回られています。

このパターンはパフォーマンスだけにとどまりません。Stanfordは、AI支援開発者が5つのセキュリティタスクのうち4つでより不安全なコードを書き、同じ開発者が自分のコードは安全だとより信じやすいことを発見しました。⁸ この自信のギャップはパフォーマンスにも同様に当てはまります。コードがクリーンに見え、読みやすく、正しい出力を生成するため、開発者はそれを信頼します。SWE-fficiencyの研究者は、エージェントが最適化の機会を特定することや、関数をまたいだ実行について推論することに苦労していることを発見しました。² LLMはアルゴリズム的な改善ではなく、小さな入力固有の編集を行います。最適化を求められると、モデルはアルゴリズム的なアプローチを再考するのではなく、最も近い正しい変換（キャッシュの追加、関数のインライン化）に手を伸ばします。その結果、根本的に非効率な構造の上にマイクロ最適化が重ねられることになります。

パフォーマンスを測定する評価ゲートがない

標準的な品質ゲートは、設計された通りのものを検証します。

業界が標準化したすべてのゲートは正確性に基づいて動作しています。パフォーマンステスト（プロファイラー、ベンチマークフレームワーク、負荷テストツール）は存在しますが、ほとんどのチームがCIパイプラインに統合しない別のワークフローに位置しており、AIエージェントが自発的に呼び出すこともありません。

検証の真空は、10%の生産性の壁を説明するものであり、機能的な正確性よりも深い問題です。真空は「コードは動くか？」だけでなく「コードはパフォーマンスを発揮するか？」でもあり、標準的なゲートは2番目の質問をしません。

エージェントは関数を書くが、システムは書かない

最も根本的な原因はアーキテクチャにあります。AIエージェントは、1つの関数、1つのファイル、1つのタスクごとにコードを生成します。各生成のスコープは、当面の要件です。パフォーマンスの問題は境界で発生します。単一呼び出し用に書かれた関数がループ内で呼び出されるとき、小さな入力用に書かれたパーサーが大きなファイルを受け取るとき、正確性のために書かれたルックアップがリクエストごとにヒットするとき。

エージェント障害分類のTunnel Vision障害モードは、このパターンを機能レベルで記述しています。エージェントは統合ポイントをチェックせずに1つのコンポーネントを完璧にします。パフォーマンスの盲点は、ランタイム特性に適用されたTunnel Visionです。関数は単独では完璧です。関数のパフォーマンス特性がコンテキスト内で評価されなかったため、システムが劣化します。

見えない税金

パフォーマンスの盲点は、AI生成コードが本番システムのごく一部であれば、些細な問題でしょう。現在の数字はそれをシステミックリスクにしています。

DXはAI作成コードをマージされた本番コードの26.9%と測定しており、その割合は上昇中です。⁶ DevOps分析ベンダーであるFaros AIは、AI支援チームがAI導入前のベースラインよりも154%大きなPRをマージし、21%多くのタスクを完了し、開発者あたり9%多くのバグを生成していることを発見しました。⁵ この9%の数字は機能的な欠陥をカウントしています。パフォーマンスの退行は、ほとんどのチームが退行のベースラインとなるパフォーマンス基準を持っていないため、この指標に完全に欠落しています。

複利の計算が重要です。METRのランダム化比較試験では、経験豊富な開発者がAIツールを使用した場合に19%長くかかったにもかかわらず、AIが20%速くしてくれたと信じていました。⁹ 開発者自身がその影響を正確に評価できないのであれば、パフォーマンス負債は検出されずに蓄積されます。マージされたコードの26.9%が潜在的なパフォーマンス負債を抱え、組織にパフォーマンスゲートがない状態では、負債はスプリントごとに複利で膨らみます。DORA 2025レポートは、スループットが改善してもAIの導入がデリバリーの不安定性の増加と相関していることを発見しました。⁷ レポートは不安定性をパフォーマンスに特定して帰属させてはいませんが、メカニズムは一致します。より多くのコードが、より速くマージされ、パフォーマンス特性が一度も測定されていないということです。

Codeflashが調査したエンジニアリングリーダーの52%が、AIの使用増加がコードベースにパフォーマンスの問題をもたらすと報告しています。⁴ この数字は自己申告であり、ベンダー（Codeflashはパフォーマンス最適化ツールを販売）からのものですが、方向性はすべての独立したデータセットと一致しています。より多くのAI生成コードが、標準的な品質ゲートでマージされ、正しく動作するが遅く実行されるシステムを生み出しています。

10%の生産性の壁には、元のデータが表面化させないパフォーマンスの次元があります。AIがコード生成を10%加速させても、生成されたコードが数週間または数ヶ月後に本番インシデントとして表面化するパフォーマンス負債を抱えているなら、純粋な生産性向上はさらに縮小します。壁は「AIが開発者を速くしない」というだけではありません。壁には「AIが誰も測定していない方法でコードを遅くする」という面も含まれています。

検出の実態

AI生成コードのパフォーマンス検出には、ほとんどの組織が持っていないインフラが必要です。ツールは存在します。統合が存在しないのです。

CIにおけるベンチマークゲート

最も直接的な修正策は、クリティカルパスにベンチマークを設定し、退行時にビルドを失敗させることです。主要な言語ごとにフレームワークが存在します。Python用のpytest-benchmark、Java用のJMH、Rust用のcriterion、JavaScript用のbenchmark.jsです。課題はツールではなく実践にあります。ベンチマークにはベースラインが必要であり、ベースラインには、AI生成コードが退行する前に最初のベンチマークを書く人が必要です。

最小限の実行可能な実装として、ホットパスの10〜20の関数を特定し、それらのベンチマークを書き、CIに追加してください。Codeflashが発見した118のバグは、パーサーとAST走査関数、つまりグルーコードではなく計算のコア部分に集中していました。パフォーマンスの問題は毎回同じ場所に集中します。

ASTベースのパターン検出

静的解析は、コードを実行せずに最も深刻なパターンを検出できます。Semgrepとast-grepは、以下を検出するカスタムルールをサポートしています。

• 内側のコレクションが変化しない他のループ内のリスト内包表記やループ（キャッシュ候補）
• セットに変換できるリストに対する.index()やinチェック
• バッチ処理なしのループ内でのファイルI/Oやネットワーク呼び出し
• 同じ引数での繰り返しの関数呼び出し（メモ化候補）

これらのルールはプロファイリングの代替にはなりません。118のバグの大半を占めるパターン、つまり冗長な計算、キャッシュの欠如、不適切なデータ構造を検出するものです。

フックベースのパフォーマンス意識

Claude Codeユーザーの場合、PreToolUseフックがエージェントのワークフローにパフォーマンス意識を注入できます。このアプローチは、正確性に使用されるエビデンスゲートパターンと並行するものです。

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

このフックはプロファイラーではありません。意識を高めるものです。目標は他のすべての品質ゲートと同じです。見えないものを見えるようにし、コードが出荷される前に開発者（または後続のイテレーションでエージェント）が対処できるようにすることです。

欠落しているインフラ

すべてのデータポイントにわたるパターンは、10%の生産性の壁と7つの障害モードを説明するものと同じです。AIは既存のインフラを増幅します。インフラの不在も含めて。

CIにパフォーマンスベンチマークを持つ組織は、人間が生成したパフォーマンス退行を検出するのと同じ方法で、AI生成のパフォーマンス退行を検出できるでしょう。持たない組織は、パフォーマンス負債を見えない形で蓄積し続けます。DORAの「増幅器」の発見は直接的に当てはまります。AIはパフォーマンスの盲点を作り出すのではありません。AIがそれをスケールさせるのです。⁷

3つの最小限の投資がこのギャップを埋めます。

1. AIがコードを生成する前に、クリティカルパスにベンチマークを設定する。 ベンチマークがベースラインです。それがなければ、退行は検出できません。計算時間の大部分を占める10〜20の関数を特定し、それらのベンチマークを最初に書いてください。

2. ASTベースのパフォーマンスリンティングをCIパイプラインに追加する。 4つの主要なアンチパターン（冗長な計算、キャッシュの欠如、不適切なデータ構造、不必要な複雑性）をフラグするSemgrepまたはast-grepルールです。ルールは軽量で、既存のリンティングステップと組み合わせることができます。

3. エージェントのワークフローにパフォーマンス意識を注入する。 Claude Codeの場合：変更されたファイルのパフォーマンス関連パターンをフラグするフック。他のツールの場合：「アルゴリズムの複雑性を検証する」を標準的な指示として含むプロンプト。目標は自動最適化ではなく意識化です。現在は問わない「これは十分に速いか？」という質問をワークフローに表面化させることです。

盲点はAIではありません。盲点はパフォーマンスインフラの不在です。業界が構築したすべての標準的な品質ゲートは正確性を検証します。効率性を検証するものはありません。このギャップはAI以前から存在していました。AIがそれを本番コードの26.9%の問題にしたのです。

出典