InfoQが紹介しているのは、CNCFブログに掲載された Brandon Foley のベンチマーク研究です。
テーマはシンプルで、「AI coding agents は、現実の Kubernetes バグをどれだけ直せるのか？」というもの。
ここでいう AI coding agent は、ただコード補完するだけのツールではなく、issue を読んで、関連コードを探して、修正案まで出そうとするタイプの AI です。最近よく聞く “agentic” なやつですね。
この手のツール、デモ動画だとめちゃくちゃ賢く見えるんですが、実運用になると話は別。そこをちゃんと測ったのがこの研究で、私はかなり面白いと思いました。
しかも対象がKubernetesです。
巨大で、依存関係が多くて、ちょっと直したつもりが別の場所に波及しやすい。AIにとってはかなりイヤな相手です。人間でもつらいのに、AIが楽勝なわけがない。
Foley氏は、Kubernetesリポジトリで実際に修正された9件のバグ報告をベンチマークに使いました。
対象は kubelet、scheduler、networking、storage、apps など、複数のサブシステムにまたがっています。
ポイントは、AIには issue の説明だけを渡したことです。
つまり、答えのヒントになる pull request の説明や diff（差分）は見せていません。かなりフェアです。というか、現場っぽい。実際の開発でも、最初に見えるのは issue だけなので。
比較したのは次の3パターンです。
RAG（Retrieval-Augmented Generation）だけで見る方式。
RAGは簡単にいうと、AIが答える前に「関連資料を検索して、その内容を参照する」仕組みです。
この実験では、KAITO RAG Engine と Qdrant を使い、BM25 のキーワード検索と embedding ベースの意味検索を組み合わせています。
BM25は「単語がどれだけ似ているか」を見る検索、embedding は「意味が近いか」を見る検索だと思えばOKです。
まずRAGで関連箇所を探し、そのあとローカルのファイルも見に行く方式。
検索で入口を見つけてから、自分の足で現場を歩く感じです。
ローカルにクローンしたリポジトリだけを見て、検索インデックスは使わない方式。
検索に頼らず、コードベースを直接たどるタイプですね。
条件はそろえています。
モデルはすべて Claude Opus 4.6、タイムアウトは5分、出力形式も同じ。
違うのは「コードをどう見せるか」だけ。なので、比較としてはかなりきれいです。
まず速度の話。
RAG-only が一番速く、平均76秒でした。
理由は単純で、ファイルシステムを歩き回る必要がなく、検索で取れた断片からそのまま答えを作れるからです。
一方で Hybrid は一番遅く、平均で2分半くらい。
RAGで探す段階が必須なので、そのぶんオーバーヘッドがあります。
コスト面では、Hybrid が一番高くついたそうです。
これ、ちょっと意外に見えるかもしれませんが、理由は「読むコードが多いから」ではなく、モデル呼び出し回数が増えるから。
APIはステートレス、つまり毎回「前回までの会話を知っている」前提ではないので、呼び出しのたびに会話履歴を再送する必要があります。これが地味に重い。
実際、コストもレイテンシーも、呼び出し回数が最大の要因だったとのことです。
ここはかなり現実的な話です。
AIのコストって「賢いモデルを使うかどうか」だけで決まらず、「何回話しに行くか」でどんどん膨らむんですよね。個人的には、ここはAI運用で見落とされがちな罠だと思います。
速いだけなら、RAG-only は優秀です。
ただし、修正の質を見ると話は一気に難しくなります。
この研究で目立った失敗は、間違った修正よりも、不完全な修正でした。
つまり、AIは「主役のバグ」は直すのに、周辺で必要な変更を見落としがちだったのです。
たとえば、
要するに、AIは「ここが壊れている」には気づいても、
「これを直すなら、他にどこも動かす必要がある？」
という問いが弱い。
ここが本質だと思います。
人間のデバッグって、実は「バグを見つける」より「影響範囲を見積もる」ほうが難しいことが多いです。AIはまだその“広い視野”が弱い、というわけですね。
もう1つ興味深い傾向がありました。
AIは、選べるなら 既存の仕組みを再利用するより、新しい abstraction（抽象化）を足す 傾向があるそうです。
抽象化というのは、ざっくり言うと「複雑さをまとめるための共通の枠組み」です。
うまく使えば便利ですが、増やしすぎるとコードが重くなります。
この研究では、正解は既存の RestartCount フィールドを使うことだったのに、AIたちは代わりに新しい Attempt フィールドを作ってしまった例がありました。
機能的には正しくても、設計としては重い。
これ、すごく人間っぽい失敗でもあるのですが、同時に「AIはそれっぽい新設計を足しがち」というクセも見えます。
個人的には、ここはかなり重要です。
AIは“正解のコード”を出しているつもりでも、実際には“別の正解っぽいコード”を増やしているだけ、ということがある。
短期的には動いても、長期的には保守が大変になるかもしれません。
この研究で少し評価できるのは、RAGの位置づけを冷静に見ている点です。
結果を見ると、retrieval strategy は「発見」には効くが、「推論の質」そのものを変えるわけではないとされています。
つまり、RAGは
のには役立つ。
でもその後、AIが「システム全体としてどう影響するか」を理解するところは、まだローカルな推論のまま、ということです。
これはかなり大事な示唆です。
世の中では「もっと検索を良くすればAIはもっと賢くなる」と言いたくなりがちですが、今回の結果はそれに冷や水を浴びせています。
検索は地図であって、理解そのものではない。このたとえがしっくりきます。
この研究でかなり実践的だったのは、issue の書き方が強いと示したことです。
つまり、バグ報告がうまく書かれていて、ファイル名、関数名、期待動作までちゃんと書いてあると、3方式の差がかなり縮まったそうです。
これは面白いですよね。
AIを良くするには、巨大な検索基盤を入れることより、人間が問題を明確に書くことのほうが効く場合がある。
ちょっと皮肉ですが、本当にその通りだと思います。
AI時代でも、雑な依頼は雑な結果を呼ぶ。
結局のところ、「何を直してほしいのか」を人間がちゃんと伝える力は、まだまだ価値が高いです。
このベンチマークが教えてくれるのは、AI coding agents はたしかに有望だけど、自動バグ修正の万能薬ではないということです。
特に難しいのは、単体のバグではなく、
このあたりです。
Kubernetesのような大規模コードベースでは、ここが本丸になります。
そして、そこがまだ苦手。これはかなり正直な結果だと思います。
研究では、こうした課題を改善する手段として、structured agent skills や curated playbooks の可能性も示唆されています。
簡単にいうと、AIに“手順書つきの作業能力”を持たせる案です。
ただし、これにも落とし穴があります。
大きなコードベースに合わせてそういう技能や手順書を保つには、継続的なメンテナンスが必要です。
つまり、新しい万能薬を手に入れるというより、別の管理対象が増えるだけかもしれない。
ここはかなり現実的で、私はむしろ好感を持ちました。夢だけで終わらせていないからです。
この話を一言でいうと、AIエージェントは「見つける」のは得意になりつつあるが、「広く考える」のはまだ難しい、です。
そして、そのギャップを埋めるのはRAGだけではない。
むしろ、問題定義の質や、人間の書く issue の明確さが、かなり効いてくる。
AIを賢くするのは、AI側だけの仕事ではないということですね。
私はこの結果、けっこう好きです。
派手な万能論ではなく、「現場で本当に効くものは何か」をちゃんと見ているからです。
AIエージェントの未来は明るいと思います。でも、少なくとも今は、検索を足すだけで全部解決、とはいかない。そこが今回のいちばん大事なポイントではないでしょうか。
