ベンチマークの過信は危険？ AIコーディングに潜む「非効率性」を見抜き、最適化するアプローチ：AWS発IDE「Kiro」の開発チーム解説

Kiroの開発チームは、ベンチマークの数値だけでは見逃されるAIコーディングエージェントの非効率性を発見、改善する取り組みを解説した。無駄なやりとりを削減することで、開発者体験を継続的に向上させるという。

[＠IT]

　AI（人工知能）IDE（統合開発環境）「Kiro」の開発チームは2026年2月23日（米国時間）、AIコーディングにおける非効率性を自動検出、改善する取り組みについて公式ブログで解説した。

　AIコーディングにおいて、コードのコンパイルが通りテストに合格すれば、通常は「タスクが完了した」と見なされる。しかしその裏側では、エージェントがファイルを見つけられずに複数回試行を繰り返していたり、絶対に機能しないコマンドを複数回繰り返したりするケースが存在するという。

　そこでKiroの開発チームは、表面的なベンチマーク評価では見逃されるこうしたAIの非効率性を浮き彫りにし、根本解決を目指す「推論と適応学習による継続的最適化のための専門システム」を構築した。同チームはこのシステムを「CORAL」と呼んでいるという。

「テスト合格＝高精度」とは限らない？　ベンチマークが見逃す“無駄なターン”

　AIコーディングエージェントは通常、合格率、トークン数、レイテンシ（遅延）などのベンチマークで評価される。しかし、これらの指標は結果を示すのみで、プロセスに潜む非効率性までは可視化できない。

　タスクが「合格」しながらも、エージェントが誤った検索パターンやツール理解の不足により、余分なターン（やりとり）が発生することがある。何千ものエージェントインタラクションを処理する環境においては、手動によるレビューは対応が困難という課題もある。

軌跡ベースの学習で行動全体を分析

　Kiro開発チームが構築したCORALは、Kiroのインタラクションを分析し、ベンチマークでは見落とされる非効率性を浮き彫りにする。CORALで採用されたのが、エージェントの操作履歴全体を分析する「軌跡ベースの学習」（trajectory-based learning）と呼ばれるアプローチだ。

CORALによる最適化のサイクル（提供：Kiroの開発チーム）

　コードがコンパイルされるかどうかを確認するだけでなく、エージェントが取った一連のアクション全体、つまり全てのツール呼び出し、全ての意思決定ポイント、全ての回復試行を検証する。

　結果的に同じ「合格」だとしても、無駄なく5つのステップで完了した場合と、試行錯誤を繰り返して17のステップを費やした場合ではプロセスの質が大きく異なる。CORALは、そうした違いを正確に識別できるという。

CORALの仕組み

　毎日、同意を得たユーザーの実際のKiroセッションを何千件もサンプリングし、大規模言語モデル（LLM）が軌跡（trajectory）を分析してエージェントがどこで時間を失ったかという非効率の根本原因を特定し、一般化可能な教訓を抽出する。

　抽出された教訓は、すでに学習済みの内容と照合される。新しいものか、対処可能なものか、既存の洞察と矛盾しないかを確認し、これらをパスすれば、「ツール使用」「ワークフローパターン」「エラー回復」「行動ガイダンス」といったカテゴリーで整理された構造化ナレッジベースに追加される。

　各洞察はエビデンスも追跡する。あるパターンが多くの軌跡にわたって繰り返し現れると、信頼度が高まる。

　高信頼度の洞察は、ツールの説明の更新、システムプロンプトの変更、またはエージェントの動作修正に反映され、モデルの再トレーニングなしに改善が適用される。

発見事例1：検索パターンの誤解

　エージェントが「*.py」のようなパターンでファイルを検索する際、ツール自体はエラーを発生させず「成功」（該当ファイル0件）していた。そのためエージェントは「ファイルが単純に存在しない」と誤認した。

　その結果、grep検索の4分の1以上が、エラーも出ないまま失敗していた。検索結果が0件の場合、別のクエリでの再試行やディレクトリツリーの探索など、エージェントは試行錯誤した。これにより、失敗した検索1回につき平均で約5ターン分の余計なやりとりが生じていたという。

　この非効率性の原因は、LLMが「ripgrep」などのツールから学習した常識にあった。ripgrepでは「*.py」と書けば通常は再帰的（サブディレクトリも含めて）検索されるものの、Kiroの検索APIでは、再帰検索には「**/*.py」と記述する必要があった。この微妙な違いがツールの説明に明記されていなかった。

　そこで開発チームは以下のようにツールの説明文を1行調整した。この変更により、本番環境における誤ったgrepパターンを約99％削減できたという。

- includePattern (optional): Glob pattern for files to include (e.g. '*.ts')
+ includePattern (optional): Glob pattern for files to include (e.g. '**/*.ts'). Use ** for recursive search.

発見事例2：「cd」コマンドの誤用

　エージェントは「cd src && npm test」のようなシェルコマンドを生成していたが、実行環境では作業ディレクトリの変更に「cwd」パラメーターを使用する仕様となっており、このコマンドは全て失敗していた。

　「cd dir && command」はシェルスクリプトの一般的なパターンであり、LLMは学習過程でこのパターンを大量に見てきた。一方、「cwd」パラメーターを指定する方法は一般的なシェル操作とは異なるため、エージェントはツール仕様よりも学習済みのパターンに頼ってしまった。

　この誤用は全シェル呼び出しの3.46％で確認され、18％のセッションに影響を及ぼしていた。全ての実行は失敗し、エージェントはコマンドの再試行、代替手段の探索などで平均2.7ターンの回復処理を費やしていた。

　そこで対策として自動補正機構を導入した。エージェントが「executeBash(command="cd src && npm test")」と送信すると、Kiroは自動的に「executeBash(command="npm test", cwd="src")」に変換する。実行後、CORALはエージェントに対してツールの正しい使い方を強化させるためのリマインダーを内部的に通知する。

　この改善により、「cd」コマンドの誤用によるエラー率は100％から約0％に、影響を受けたセッションは18％から約0％に減少すると予測しているという。

調査中のパターン

　Kiroの開発チームはこれ以外にも、以下のようなパターンを積極的に調査している。

• フォーマット後のコンテンツドリフト
  • エージェントがファイルを編集した後、「Prettier」や「Black」のようなフォーマッターが空白と構造を整形する。エージェントは次の編集をする際、ファイルを書いた時と同じ状態であると仮定するが、実際は変化している。「oldStr」が見つからないという失敗が繰り返し発生することも判明した
• 散在するマルチファイル編集
  • 変更が複数のファイルにまたがる場合、すぐに編集に入るエージェントは他のファイルの関連コードを見落とすことが多い。変更を加える前に検索を使用してコードベース全体の変更ポイントをまずマッピングするエージェントの方が、より完全で一貫した結果を生み出すことが分かった
• 承認の行き詰まり
  • エージェントがリクエストに対して「了解しました」や「分かりました」と応答した後、何もしない軌跡を発見した。ユーザーは実際の作業を進めるために再度プロンプトを送る必要がある
• 曖昧さのコスト
  • エージェントが曖昧なリクエストに対して誤った推測をし、間違ったものを構築してしまい、作業をやり直さなければならなくなった軌跡を発見した。最初に1つの質問をするだけで、複数ターンの無駄な作業を節約できた可能性がある

継続的最適化へ

　Kiroの開発チームは、このように無駄なターンを分析し改善することで、AIの非効率性の課題に取り組んでいる。CORALはバックグラウンドで実行され、チームがレビューしてリリースできる修正を洗い出す。ユーザーによるKiroへのフィードバックも取り込み、将来的には改善ループの完全自動化を目指すとしている。