8月27日、Kiroが「Are AI coding agents actually getting better?」と題した記事を公開した。この記事では、KiroのAIコーディングエージェントが過去6ヶ月間でどれだけ改善したかを、静的解析ツールの診断データ（約140万件の会話・40万件以上の診断呼び出し）をもとに定量的に検証している。
なお、Kiro IDEはAmazon/AWSが提供するAI統合コーディング環境であり、エージェントがコード生成・編集・デバッグを自律的に行う機能を中心に設計されている。本分析のデータソースはAmazon社内ユーザーによる実運用ログだ。
「最終出力の品質」より「途中で何をしたか」が重要
AIコーディングエージェントの改善を測る際、最終出力に残ったエラー数を数えるだけでは不十分だ。Kiroチームが着目したのは、エージェントがコード生成の途中で自律的に静的解析ツールを呼び出しているかどうかという行動シグナルだ。
最終出力だけを見ると、「一度も自己チェックせずにたまたまきれいなコードを出したモデル」と「チェック→エラー検出→修正を繰り返して品質を担保したモデル」を区別できない。診断ツールの呼び出しログを追うことで、モデルがどのエラーを自力で直せるのか、何回の追加ツール呼び出しが必要なのかというプロセスレベルの能力差が初めて見えてくる。
分析対象は2026年1月〜6月の約140万件のKiro IDE上での会話。Claude Opus 4.5・4.6・4.7・4.8とSonnet 4・4.5・4.6の計7モデルをカバーし、TypeScript・Python・Java・Rust・Go・Kotlin・C++・Swiftの複数言語にわたる40万6千件の診断ツール呼び出しを抽出した。
診断ツールを「自発的に使う」モデルはまだ少数派
まず確認したのが診断ツール呼び出し率——コーディング会話のうちモデルが少なくとも1回診断ツールを使った割合だ。
- Opus 4.6が最も積極的で 22.26%
- Opus 4.7・4.8は約10%台に後退
- Sonnet 4.5は **2.74%**（最低値）
- Sonnet 4.6は 13.89% へ急増
全体として3〜22%という水準は、大多数の会話でモデルが自発的な静的チェックをしていないことを意味する。明示的なプロンプトや設計上の制約なしには、モデルはデフォルトで診断ツールを使わない傾向があることを示している。
なお、診断ツールの使用をエージェントが最終編集を確定する前に必須とする設計にすると、誤ったコードの受け入れ率が**約90%から約8%**に激減するという関連実験結果が元記事内で引用されており、「任意ツールとして提供するだけ」では効果が薄いことが示唆されている。
ファイルあたりのエラー数：Sonnetは57%減
次の指標はチェックされたファイル1件あたりの平均エラー数。生成コードがコンパイル可能な状態にどれだけ近いかを示す。
| モデル | 平均エラー数/ファイル |
|---|---|
| Sonnet 4 | 3.01 |
| Sonnet 4.5 | 2.90 |
| Sonnet 4.6 | 1.29 |
| Opus 4.5 | 1.74 |
| Opus 4.6 | 1.21 |
| Opus 4.7 | 1.82 |
| Opus 4.8 | 1.21 |
Sonnetは57%減という明確な改善トレンドを示す。一方Opusは単調な改善ではなく、4.6と4.8が1.21と優れた値を記録する一方、4.7は1.82に悪化するという非単調なパターンを見せた。最新世代では両系統とも約1.2エラー/ファイルに収束しており、「箱から出してすぐコンパイルできるコード」に近づいている。
1回の診断呼び出しで複数ファイルを確認する傾向
モデルが診断ツールを使うスコープも変化している。1回の呼び出しで確認するファイル数が増えている。
- Sonnet 4：1.57ファイル/回 → Sonnet 4.6：1.86ファイル/回
- Opus 4.5：1.78ファイル/回 → Opus 4.7：2.04ファイル/回
かつては「編集したファイルだけチェック」が基本だったのが、実装ファイルとそのテスト、モジュールと利用側をセットで確認する戦略へと移行しつつある。数字だけ見ると地味に映るが、40万件超の呼び出し規模では、クロスファイルの型不整合や破損インポートを早期に検出できているケースが大幅に増えていることを意味する。
エラー種別：「未解決インポート」がどのモデルでも首位
エラーの内訳を見ると、未解決インポート（unresolved imports）が全モデルで最大カテゴリを占め、多くのモデルで全診断の約3分の1、Opus 4.7では**57.6%**に達した。続いて未定義シンボル、型エラー（implicit any、構文エラー、未解決参照など）が続く。
モデルによって失敗パターンが異なる点も興味深い。Opus 4.7はインポート解決の失敗に集中しているのに対し、Sonnet 4.5やOpus 4.5は複数のエラーカテゴリに広く分散している。エラー数が減っているだけでなく、エラーの種類そのものが変化しているという指摘はKiroチームが特に強調している点だ。
注意すべき解釈の限界
Kiroチームは、以下の点を明示的な断り書きとして挙げている。
- 診断ツールは静的解析のみ。ランタイムエラー・ロジックバグ・パフォーマンス劣化は対象外
- ユーザーのインストール済み拡張機能によって診断の厳しさが変わる（ただし今回のデータはAmazon社内ユーザーで共通ツールが多い）
- エラー率の変化はモデル改善だけでなく、プロンプト設計やオーケストレーション層の変更も影響しており、切り分けは困難
詳細はAre AI coding agents actually getting better?を参照していただきたい。
