ClaudeとGemini「AIコーディング解決率はほぼ同じ」 でも“解き方”に表れた正反対の「性格」：“解決率”によるLLM評価の限界

JetBrainsは、コーディングエージェントに組み込むLLMの性能を評価する独自のパイプラインを公式ブログで紹介した。同社のAIコーディングエージェント「Junie」に「Claude Opus 4.7」と「Gemini 3.5 Flash」を組み込んで評価した結果を例に挙げて解説している。

[＠IT]

　JetBrainsは2026年8月、コーディングエージェントに組み込む大規模言語モデル（LLM）の性能を評価する独自のパイプラインを公式ブログで紹介した。

　エージェントがタスクを解決したかどうかだけでなく、解決に至る過程も詳細に分析するものだ。同社のAIコーディングエージェント「Junie」に「Claude Opus 4.7」と「Gemini 3.5 Flash」を組み込んで評価した結果を例に挙げて解説している。

“解決率”によるLLM評価の限界

　コーディングエージェントの比較に最もよく使われる指標は、ベンチマークタスクの実行結果が評価テストに合格した割合を示す「解決率」だ。だがJetBrainsは、この数値からは解決に至った“いきさつ”がほとんど分からないと指摘する。

　JetBrainsはブログ記事の冒頭で、社内ベンチマークの一例を紹介している。

　それによると、Claude Opus 4.7とGemini 3.5 Flashは、同じ数のタスクを解決した。だが、Opusが1回の実行に平均184ステップ、2.79ドルを要したのに対し、Geminiは271ステップを要したものの、コストは1.24ドルにとどまった。両者の実行プロファイルは全く異なっていた。

　Junieのようなコーディングエージェントは、モデルにファイルの閲覧、シンボルの検索、コードの編集、コマンドやテストの実行を行わせる。これらの観測可能なアクションがエージェントの「軌跡」（trajectory）を形成する。軌跡からは、モデルが編集前に問題箇所を特定したかどうか、検索を繰り返したかどうか、パッチを絞り込んだかどうかなどが分かる。

　エージェントがタスク解決に失敗した場合も、軌跡を追うことで、関連コードを見つけられなかったのかどうか、問題の原因を誤解したのかどうか、誤ったレイヤーを編集したのかどうか、検証せずに終了したのかどうかなどを区別できる。

4つの観点と2つのレイヤーで評価

　JetBrainsが独自に開発した評価パイプラインは、ベンチマークタスクごとに「課題」「リポジトリのコンテキスト」「生成されたパッチ」「テスト結果」「実行トレース」を組み合わせ、次の4つの観点から実行を評価する。

• 結果：パッチがタスクを解決したか、どのテストに合格または失敗したか
• 効率：トークン数、モデル呼び出し数、ツール呼び出し数、所要秒数、費用
• パッチ品質：変更が、関連するファイルとシンボルに施され、範囲が限定されているかどうか
• プロセス品質：探索、実装、検証をどのように進めたか、作業の繰り返しや最終テストの省略がなかったかどうか

　このパイプラインでは、決定論的な指標と意味的な評価を組み合わせている。決定論的レイヤーは、ログとリポジトリのデータから、テスト結果、実行時間、トークン使用量、変更ファイル、ファイルの重複読み込み、ツール失敗のループといった再現可能な測定値を抽出する。

　一方、ルールだけでは解釈できない行動（ファイルを2回開いたのが無駄だったのか、編集後に必要だったのかなど）については、LLMジャッジが評価する。LLMジャッジは、コードの課題、生成されたパッチ、実行時の軌跡、リポジトリから構造化された証拠を受け取り、モデルが関連コードを発見したかどうか、欠陥を再現したかどうか、根本原因を特定したかどうか、結果を検証したかどうかといったマイルストーンを評価する。これにより、実行が失敗したかどうかだけでなく、どの段階で失敗したかが分かる。

JetBrainsの評価パイプラインの構成要素（提供：JetBrains）

近いスコア、異なる軌跡

　JetBrainsはこの評価パイプラインを使い、523タスクを含む4つのベンチマークデータセットで、Junieに組み込んだClaude Opus 4.7とGemini 3.5 Flashを比較した。Opusは267タスク（解決率：51.1％）、Geminiは254タスク（解決率：48.6％）を解決した。両モデルは430タスクで同じ結果となり（214件を解決、216件で失敗）、差が出たのは93タスクのみだった。

523タスクにおけるClaude Opus 4.7とGemini 3.5 Flashの実行結果（提供：JetBrains）

　同一タスクの比較を見ると、その違いが具体的に分かる。両モデルが解決した、あるタスクでは、いずれもステップ15で関連ファイルを開き、「根本原因を特定した」と判定された。

　Opusはその13ステップ後に実装を開始し、53ステップで完了した。一方、Geminiはモジュールをより広範に調査し、ステップ88で最初の編集を行い、192ステップを要した。さらに、4つのファイルに不要な編集を加え、パッチを作成した。これに対し、Opusは参照解と同じファイルにしかアクセスしなかった。

同じ成功に至った2つの異なる軌跡（提供：JetBrains）

　両モデルが失敗した216タスクの分析も示唆に富む。両モデルとも、これらの85％以上で根本原因を少なくとも部分的に特定していたことが判明した。失敗の原因は、リポジトリに対する理解不足ではなく、テキストの切り捨てや一部のコードパスの修正漏れなど、実装の不完全さだった。

両モデルが失敗した216タスクの段階別分析（提供：JetBrains）

評価結果に基づく「AIの性格」の違い

　JetBrainsはこれらの結果から、Claude Opus 4.7とGemini 3.5 Flashのプロファイルを作成した。モデルの長所と短所についての詳細情報を以下のようにまとめている。

Claude Opus 4.7

　「診断に強く、完遂に弱い」と特徴付けられた。曖昧な欠陥の根本原因を特定することに優れており、Geminiが解けなかった53タスクを解決した。主な弱点は問題箇所の特定後に現れる。実装後の実行検証を123回も省略していた。なお、そのうち68回はタスクを解決していた。

Gemini 3.5 Flash

　検証に強いが、グラウンディング（根拠付け）に課題があった。実行可能なチェックを行い、その出力で解を改良する傾向が強い一方で、関連コードに到達した後も検索を続け、未検証のAPIやパスに依存しやすかった。195回（37.3％）の実行で中程度または深刻なハルシネーションが見られ（Opusは130回）、80回（15.3％）で不要な冗長コードを生成した。これはOpusの2倍超だった。

GPT-5.5、Qwen 3.6 27B FP8

　JetBrainsは、「GPT-5.5」と「Qwen 3.6 27B FP8」（Floating Point 8-bit）にも独自の評価パイプラインを適用した。GPT-5.5は51.5％と最高の解決率に達し、実行可能なチェックを常に行った唯一のモデルだった。Opusはパッチ品質の全指標で首位に立ち、QwenはGPT-5.5の1回当たり費用の3％でタスクの38.9％を解決した。

522タスクでの4モデルの実行結果比較（解決率、1回の実行当たりのコスト、軌跡の長さ、根本原因の特定率、ハルシネーションの発生率、パッチの冗長性、実行可能な検証の省略）（提供：JetBrains）

注意点とまとめ

　JetBrainsは、これらのプロファイルはJunieの特定のスキャフォールド（※）に基づくものであり、モデル全般の説明として受け取るべきではないと注意を促す。さらに、LLMジャッジの評価は、特定の参照解（唯一の有効な解決策ではない）に大きく依存しており、診断的なシグナルに過ぎないとしている。

※モデルに渡す指示やツール説明、コンテキスト管理方法など、モデルの振る舞いを規定する設計図や足場（参考）

　同社は、「LLMを評価するリーダーボードを別の総合スコアに置き換えることを目指しているのではない」とする。その上で、「テストタスクの実行結果を効率性、パッチ品質、プロセス品質に関する証拠と組み合わせ、結果をもたらした要因を理解し、そのパターンを活用して、モデル選択、プロンプト作成、エージェント設計の改善につなげることが目標だ」と述べている。