JetBrainsは2026年8月30日、コーディングエージェントJunie内で使用される大規模言語モデルの評価手法に関する分析を公開し、「解決率」（resolve rate）という単一の指標への依存をやめるよう呼びかけた。同社によれば、エージェントがタスクのテストに合格したかどうかを知ることは重要だが、それだけでは、どのように結果へ到達したのか、どれほどのコストがかかったのか、またコードパッチが限定的で保守可能かどうかまでは明らかにならない。
この考え方は、JetBrainsが独自のベンチマークでClaude Opus 4.7とGemini 3.5 Flashを比較した結果に基づいている。両モデルは同じ数のタスクを解決したが、Opusは平均184ステップを必要とし、実行コストは2.79ドルだったのに対し、Geminiは271ステップを必要とし、1.24ドルだった。同一の最終結果は、実行経路やツール利用の効率に明確な違いがあることを反映していなかった。
解決率が隠しているもの
Junieはissueとソフトウェアリポジトリのコンテキストで動作し、モデルによるファイルの検査、シンボルの検索、コードの変更、コマンドやテストの実行を可能にする。これらの行為は「実行経路」を構成し、モデルの内部思考を明らかにするものだと主張することなく監視できる。この経路からは、エージェントが変更前に問題箇所を特定したのか、検索操作を繰り返したのか、自らの仮説を検証したのか、それとも最終パッチを検証せずにタスクを終えたのかを確認できる。
そのためJetBrainsは、機能的な結果、実行効率、パッチの品質、プロセスの品質という4つの観点を組み合わせる評価パイプラインを提案している。具体的な測定項目には、テスト結果、実行時間、トークン数、モデルとツールの呼び出し回数、コスト、変更されたファイルとシンボルの数、複雑性の変化、繰り返されたファイル読み取り、結果が変わらないコマンドの再実行、ツールの失敗ループが含まれる。
結果から、そこへ至る経路へ
JetBrainsは、Claude Opus 4.7とGemini 3.5 Flashを比較する際、523個のタスクを含む4つのベンチマークでこの手法をテストした。Opusは267タスクを解決し、解決率は51.1%だった。一方、Geminiは254タスクを解決し、解決率は48.6%だった。430タスクでは結果が一致し、両モデルがともに成功したタスクは214件、両モデルがともに失敗したタスクは216件だった。実際の差が現れたのはわずか93タスクであり、ランキング表の生の差よりも行動上の違いが重要になる。
両モデルが成功した1つのタスクの例では、どちらも15ステップ目に関連ファイルを開き、根本原因を突き止め、包括的な検証を行った。しかしOpusはより対象を絞った検索を使用し、13ステップ後に実行を開始した。53ステップでタスクを完了し、探索、実行、検証の各段階の間を6回移行した。一方、Geminiは大規模なユニットをより広範囲に調査し、実行可能な最初の検査を30ステップ目に行った。実稼働コードへの最初の変更を実施したのは88ステップ目で、その後192ステップと、段階間の34回の移行を必要とした。
両モデルはテストに合格し、リファレンスパッチが変更したものと同じファイルとシンボルを変更した。しかしOpusは他のファイルに触れなかったのに対し、Geminiのパッチは追加で4つのファイルに及び、評価プロセスでは広範囲で、目立った重複と一部の幻覚を含むものとされた。JetBrainsは、この例は説明用であり、独立した統計的結果ではないと強調している。
失敗は一つの状態ではない
両モデルがともに失敗した216タスクを分析したところ、評価によれば、85%を超えるケースで根本原因が完全または部分的に特定されていた。あるケースでは、両エージェントはテキストがシンボル数の上限を超えたことがエラーの原因だと理解したが、テキストを適切な部分に分割するのではなく、テキストを切り詰めることを提案した。別のケースでは、一方の経路にあるダウンロードパラメーターを修正したものの、付随する経路にある同じ問題を見落とした。
これらのケースは、エージェントが責任を負うコンポーネントを見つけられなかった場合とは、実際上異なる。原因は、実装の不完全さ、誤った層の変更、タスクの正確な契約への不遵守、検証前の停止などである可能性がある。したがって実行経路は、リポジトリ内のナビゲーションの改善、タスク記述の調整、変更完了能力の強化、最終検証ステップの強制のいずれに介入すべきかを特定する助けとなる。
単一のランキングではなく行動プロファイル
JetBrainsは、Claude Opus 4.7が曖昧な不具合の根底にある原因を特定する傾向が強く、Geminiが失敗した53タスクを解決したと結論づけた。しかしOpusの実行のうち123件では、実行可能な検証が一切含まれておらず、そのうち68タスクは解決済みと判定された。同社は、この行動によって回帰やエッジケースに関する未発見のリスクが残る可能性があると考えている。
一方、Gemini 3.5 Flashは、期待される挙動が明確で、担当コンポーネントが比較的限定されている場合、実行可能な検査を実行し、その結果を使って解決策を改善する傾向が強かった。ただし、解決策への収束とリポジトリへの根付き方に問題が見られた。検索や同等のコマンドを繰り返し、ビルド構造に多くのステップを費やし、文書化されていないインターフェース、依存関係、経路、テスト環境により強く依存していた。Geminiの実行のうち195件、すなわち37.3%は中程度または深刻な幻覚を含むと分類され、Opusでは130件だった。またGeminiでは80件、つまり15.3%に大規模または深刻な反復が見られたのに対し、Opusでは6.5%だった。
実際には何を意味するのか
GPT-5.5、Claude Opus 4.7、Gemini 3.5 Flash、Qwen 3.6 27B FP8を522個の共通タスクで比較した、より広範な比較では、GPT-5.5が51.5%で最高の解決率を達成し、毎回実行可能な検査を実行した唯一のモデルだった。パッチ品質の指標ではOpusが首位となり、Qwen 3.6 27B FP8は運用コストがGPT-5.5の3%に相当する水準で、38.9%のタスクを解決した。
これらの数値は、モデルの選択がコストとリスクの所在に左右されることを示している。診断能力に優れたモデルは、未知のリポジトリや曖昧な不具合に適している可能性がある。一方、テストとフィードバックが利用できる場合は、検証においてより規律正しいモデルの方が適している可能性がある。失敗した試行のコストが限定的であれば、解決率が低くても低コストのモデルが実用的な選択肢になることもある。ただし、この解釈は、あるモデルがあらゆる環境で一貫した行動を示すことを意味しない。
JetBrainsは、行動プロファイルをモデルそのものに一般化しないよう警告している。結果はJunieの特定の構成に依存しているためである。また、大規模言語モデルに基づく評価者の判断は「グラウンドトゥルース」ではなく、単一のゴールドパッチに大きく左右される。正しい解決策が異なるファイルやアーキテクチャ層を使用する可能性があるためだ。したがって解決率は依然として不可欠な基礎だが、総合ランキング一つに還元するのではなく、効率、変更の品質、作業経路に関する証拠を添えることで、その価値は高まる。