AIが書くコード「エラー率はJavaがPythonの6.7倍」 150万「会話」データで分かったAIコーディングの盲点：AIエージェントはコード生成中、自発的に見直さない

AWSは、AIコーディングエージェント「Kiro」の利用データを基に、モデルが生成するコードの解析結果を分析した。事後の静的解析ではなく「“コード生成の途中で”エージェント自身が解析ツールを呼び出す挙動」に着目しているという。

[＠IT]

　Amazon Web Services（AWS）は2026年8月28日、AIコーディングエージェント「Kiro」の利用データを基に、AIモデルが生成したコードの品質が、バージョンを重ねてどう改善されたかをまとめた分析を公開した。

　対象は2026年1〜6月の6カ月間に統合開発環境「Kiro IDE」で交わされた約150万件の「会話」（ツール呼び出しを含む、人間〜モデル〜ツール間のやりとり）データで、そこから40万6000件の静的解析ツール呼び出しを抽出している。

　対象モデルは「Claude Opus 4.5〜4.8」「Claude Sonnet 4〜4.6」の7種類で、「TypeScript」「Python」「Java」「Rust」「Go」「Kotlin」「C++」「Swift」など複数のプログラミング言語を含む。データはAWS社内のユーザーから得たもので、Opus 4.5と4.6が分析データの51％超を、Sonnet 4.5が全分析リクエストの45％を占める。

「“コード生成の途中で”エージェント自身が解析ツールを呼び出す挙動」に着目

　Kiro IDEには、エージェントがコードを書いたり、変更したりするたびに静的解析を実行する「diagnostics」（診断・解析）ツールが組み込まれている。開発者がエディタ上で下線を引かれるなどで目にするのと同じチェックで、「モジュールのimport漏れ」「解決できないimport」「型の不一致」「暗黙のany型」「未定義シンボル」など、本来ならビルド時に初めて表面化する問題を検出する。

diagnosticsツールの動作例。エージェントは3件のエラー（25行目：numberをstringに代入できない型不一致、45行目：read-onlyな「executionTime」への書き込み、55行目：「StackProps」に存在しない「itemAge」プロパティのハルシネーション）を検出し、ファイルを編集して再チェックし、残りエラーがゼロであることを確認している（提供：AWS）

　diagnosticsの解析には、TypeScript／JavaScriptは「tsserver」、Javaは「jdtls」、Pythonは「Pyright」、Rustは「rust-analyzer」、Goは「gopls」、C/C++は「clangd」といった各言語の標準的なLSP（Language Server Protocol）サーバと、「ESLint」のようなリンターが使われている。

　AWSが今回着目したのは、最終的な成果物に残ったエラーを数える“事後の”静的解析ではなく、「“コード生成の途中で”エージェント自身がdiagnosticsツールを呼び出す挙動」だ。これには2つの理由があるという。

　1つ目は、モデルの自己監視能力を捕捉できるからだ。自分の成果物を一度もチェックせずにきれいなコードを出したモデルと、チェック後にエラーを検出して修復したモデルは、最終状態だけを見ると区別がつかないので、事後の静的解析では分からない能力だという。

　2つ目は、コード生成の途中で呼び出した際の解析データは詳細な分析を可能にするからだ。「モデルが、どのエラーカテゴリーを生成するのか」「そのうち、どれを自律的に修正できるのか」「そのために、どれだけの追加ツール呼び出しが起こるのか」を明らかにし、「モデルの認知がどこで成功し、どこで失敗するのか」が分かるという。

　以下、AWSが分析した結果をまとめた。

解析ツールの呼び出し頻度：AIエージェントはコード生成中、自発的に見直さない

　モデルがdiagnosticsを少なくとも1回呼び出したコーディング会話の割合は、最も高いOpus 4.6で22.26％、最も低いSonnet 4.5で2.74％だった。Sonnet 4.5から4.6の13.89％への上昇はエラー解析への意識の高まりを示すが、全体としては3〜22％の範囲にとどまり、ほとんどの会話はモデルが静的に見つかるエラーを積極的にチェックしないまま完了している。

　AWSは、「モデルは明示的なプロンプトやファインチューニングなしには解析ツールをめったに使わない」という最近の知見と整合すると説明している。エラーが解決されるまでエージェントの確定をブロックする用途に解析ツールを使えば、誤ったコードの受け入れを約90％から約8％に減らせると示唆する実験もあり、任意のツールとして用意しておくよりはるかに効果が大きいという。

モデル別で見たdiagnostics呼び出し率（提供：AWS）

ファイル当たりのエラー数：最新モデルは約1.2件に収束

　チェックされたファイル当たりの平均エラー数は、Sonnetの系列で明確に改善していた。

　Sonnet 4の3.01件からSonnet 4.5の2.90件、Sonnet 4.6の1.29件に下がり、削減率は57％に達する。Opusの系列は単調な改善ではなく、1.21件（Opus 4.6、4.8）と1.7〜1.8件（Opus 4.5、4.7）の間を行き来している。両ファミリーとも今回の最新版では約1.2件に収束しており、そのままコンパイルできるコードの生成に向けた前進を示している可能性がある。

モデルのバージョン別に見たチェック済みファイル当たりの平均エラー数（提供：AWS）

1回の呼び出しで確認するファイル数：新しいモデルではファイル数が増加傾向

　新しいモデルほど、1回のdiagnostics呼び出しでより多くのファイルをチェックする傾向も見られた。

　Sonnetは1.57ファイル（Sonnet 4）から1.86ファイル（Sonnet 4.6）へ増え、OpusもOpus 4.5の1.78ファイルからOpus 4.7の2.04ファイルでピークに達した。ファイルを編集してそのファイルだけをチェックするのではなく、実装とそのテスト、モジュールとその利用側のように、関連するファイルをまとめてチェックする方向に戦略が変わってきている。

　約1.6ファイルから約2.0ファイルへの変化は小さく見えるが、数十万回の呼び出しにわたって見れば、importの破損やインタフェースの不一致、下流の型エラーといったファイルをまたぐ退行を、以前の世代より高い頻度で捕捉していることを意味する。

モデルが1回のdiagnostics呼び出しでチェックする平均ファイル数（提供：AWS）

エラー分類の上位5件：最多エラーは「解決できないimport」

　エラーの種類を分類すると、全てのモデルで「解決できないimport」が単独で最大のカテゴリーとなった。多くの場合は全体の約3分の1を占め、Opus 4.7では57.6％に達する。

　残りは「未定義シンボル」「構文エラー」「解決できない参照」「暗黙のany型」といった型システムのエラーが長い裾を作る形だ。分布はモデル間で異なり、Opus 4.7がimport解決の失敗に大きく偏る一方、Sonnet 4.5やOpus 4.5はカテゴリー間に、より均等に広がっていた。

モデル別に見たエラーカテゴリーの分布（提供：AWS）

ソースファイルとテストファイル比較：テストファイルのエラーはソースファイルの3〜4倍

　ソースファイルとテストファイルを分けて見ると、差は一貫していた。Opusファミリーはソースファイルのエラーを1.4件以下に保つが、テストファイルは3.64件（Opus 4.6）から6.00件（Opus 4.8）まで幅がある。差が最も大きいのはSonnet 4.5で、エラーはソースファイル当たり2.26件に対しテストファイル当たり9.13件だった。

　テストコードにはモック（テスト用ダミーを作成、制御する仕組み）フレームワークやアサーション（判定・検証）ライブラリ、複雑なセットアップのパターンが関わり、テストツールとテスト対象コードの両方を理解している必要がある。モデルのサイズや世代にかかわらず、テストファイルはエラーの主な発生源であり続けている。

ソースファイルとテストファイルのファイル当たり平均エラー数（提供：AWS）

言語別の状況：Javaのファイルエラー率はPythonの6.7倍

　diagnostics呼び出し数が最も多いOpus 4.6について言語別のファイルエラー率を見ると、ばらつきが大きかった。低い順に並べると次の通り。

• JavaScript（1.6％）
• Python（4.0％）
• Go（8.0％）
• Kotlin（8.5％）
• TypeScript（8.6％）
• TSX（React）（11.2％）
• C++（12.2％）
• Rust（15.1％）
• Java（26.7％）

　Javaは26.7％でトップに位置し、生成されたJavaファイルの4つに1つがエラーを含む計算になる。冗長なimport、複雑なジェネリクス、検査例外、厳格な型解決の組み合わせが、今回分析したモデルにとってJavaを最も難しい言語にしている。

　最も低いJavaScriptの1.6％は、モデルがより良いコードを書いていることではなく、素のJavaScriptで利用できる静的解析が最小限であることを反映している。TypeScriptの型システムを上に載せると、この率は8.6％に跳ね上がる。

　動的型付けで静的解析が限定的なPythonにも同じことが当てはまり、低い静的エラー率は編集時に捕捉できるものを反映しているのであって、Javaよりもコードが正しいことを意味するわけではない。

　JavaのコードベースでAIコーディングエージェントを重点的に使うチームは、PythonやTypeScriptよりも解析結果の“後始末”に時間を費やすことを見込んでおく必要がある。

Opus 4.6における言語別のファイルエラー率（提供：AWS）

　なおAWSは、「今回のデータで捉えているのは問題の一部に過ぎない」と断っている。実行時エラーやロジックのバグ、性能劣化などの動的解析やテストを要するものは静的解析には表れず、「diagnosticsのチェックがクリーンである」ことは「コードが正しい」ことを意味しない。diagnosticsはsteeringプロンプトやフック、サブエージェントといったオーケストレーション層を含む広いシステムの中で動作しており、観測された改善をモデルのアップグレードだけに帰属させることはできないとしている。