CNCF: KubernetesバグフィックスにおけるAIエージェントの3つのデータ取得戦略を比較
CNCFのベンチマークが、実際のKubernetesバグを修正するAIエージェント向けのRAG、ハイブリッド、純粋ローカル取得の3戦略を比較。RAGが最速（1分16秒）だが、主要ボトルネックは速度でもコストでもなく「スコープディスカバリー」——エージェントが複数ファイルにわたる影響コードを特定する能力——だった。
この記事はAIにより一次情報源から生成されました。
CNCFは何をテストしたのか？
Cloud Native Computing Foundationは2026年5月8日、AIエージェント——Claude Opusモデルを使用し、タイムアウト5分——がオープンなプルリクエストから抽出した複雑さの異なる9件の実際のKubernetesバグを修正するベンチマークを発表した。目標は特定のモデルの優越性を証明することではなく、今日のエージェントシステムで主流の3つのデータ取得アーキテクチャを比較することだった。
比較した3つの戦略とは？
同等の条件下で3つのアプローチをテストした。
- RAGのみ — KAIO/Qdrantインデックスによるセマンティック検索。
- ハイブリッド — ローカルファイルシステムへの直接アクセスと組み合わせたRAG。
- ローカルのみ —
grep、findなどのツールを使用してクローンしたリポジトリのみを使用するエージェント。
RAGは平均1分16秒と最も速く、ハイブリッドとローカルのアプローチはそれぞれ約2分25秒を必要とした。
本当のボトルネックは何か？
研究の主要な発見は速度とトークンが決定的な要因ではないということだ。ハイブリッドアプローチは平均8回のモデル呼び出し（合計264kトークン）を必要としたのに対し、RAGとローカルアプローチは187〜189kトークンに収束した。呼び出し回数がトークン量よりも重要なコスト要因であることが示された。
CNCFが本当のボトルネックと呼ぶのは**「スコープディスカバリー」**だ——エージェントが変更すべきすべてのファイルを特定する能力だ。エージェントはバグの主要な場所を修正することには成功するが、統合ポイントでの隣接する変更を見逃すことが多かった。あるケースでは、エージェントが「呼び出し元に伝播させる代わりにエラーをローカルで飲み込んだ——機能的には似ているが、アーキテクチャ的には誤り」だった。
エンジニアにとっての意味は？
より高度な取得パイプラインに投資するコミュニティにとって、結果は不快なものだ。バグの説明が正確な場合（正確なファイルと関数が指定されている場合）、戦略間の差異は実質的に消える。差異が大きくなるのは説明が不明確なバグの場合だけだ。結論は、Issueの説明の質が取得戦略を上回るということであり、コンテキストをどのように提供するかに関わらず、アーキテクチャを通じた系統的な推論はエージェントにまだ欠けている。
よくある質問
- AIエージェントの文脈でRAGとは？
- 検索拡張生成——エージェントがまずベクターDB（KAIO/Qdrant）から関連コードを取得し、それをコンテキストとして解決策を生成する。
- 「スコープディスカバリー」とはどういう意味ですか？
- エージェントがバグの完全な修正に必要なすべてのファイルとコード箇所を特定する能力。主要なエラー箇所だけでなく。
- トークン数よりモデル呼び出し回数の方が重要なのはなぜですか？
- ハイブリッドアプローチは平均8回の呼び出し（対187k〜264kトークン）を必要とし、最もコスト高になる——各呼び出しにはトークン料金以外にも固定コストがある。