ハクソク

世界を動かす技術を、日本語で。

多くのSWE-bench-Passing PRはマージされないだろう

75日前原文(metr.org)

概要

  • SWE-bench Verifiedの自動評価と実際のメンテナーによるマージ基準の乖離を定量化した研究
  • 自動評価で合格したAI生成PRの約半数が、実際にはメインブランチにマージされない現実
  • 人間開発者のようなフィードバックによる反復がAIには許されていないため、能力限界とは断定しない
  • ベンチマークスコアの単純な解釈はAIの有用性を過大評価するリスク
  • ベンチマークはAI進歩の一要素に過ぎず、実世界の有用性評価には追加の検討が必要

SWE-bench Verifiedベンチマークと実世界の乖離

  • SWE-bench Verified で自動評価に合格したAI生成PRのうち、実際にメンテナーがマージを許可する割合は約半分にとどまる現実
  • 自動評価 は現実のメンテナーによるレビュー基準とは異なり、現実世界での有用性を過大評価する傾向
  • 人間開発者 はフィードバックを受けて反復的に修正できるが、AIエージェントにはその機会が与えられていない
  • 能力限界 ではなく、現状のベンチマーク運用方法の問題点として解釈
  • ベンチマークスコア をそのまま現実の課題解決率とみなすのは危険

研究方法と設計

  • scikit-learn、 Sphinx、 pytest の3リポジトリ、4名の現役メンテナーを招聘し、計296件のAI生成PRを評価
  • ゴールデンパッチ （実際にマージされた人間作成PR）47件も評価し、メンテナー判断のノイズを補正
  • AIモデル は主にAnthropic社のClaudeシリーズとGPT-5を対象
  • 自動評価合格PR のみメンテナーに提出し、落ちたものはメンテナーも不合格扱いとする仮定
  • レビュー基準 は受理/修正要求に加え、機能不全・他コード破壊・コード品質の観点で構造化フィードバック

主な結果と考察

  • 自動評価合格率 に対し、 メンテナーマージ率 は平均24ポイント低い
  • 年次改善率 もメンテナーマージ基準では自動評価に比べ9.6ポイント/年遅い傾向
  • ゴールデンパッチ でもメンテナー合格率は68%にとどまり、主観的要素が「最後の一押し」に影響
  • 80%以上進捗 したと評価されるPRは85%と高いが、最終マージには追加要件や主観が関与

ベンチマークの限界と今後の示唆

  • AIモデル は1回のみ提出、 人間 はフィードバックで反復修正できる構造
  • ベンチマーク の単純な数値解釈は誤解を招く可能性
  • 現実世界での有用性 評価には、より精緻なフィードバック誘導や人間との協働設計が必要
  • AI進歩予測 や社会的インパクト評価には、ベンチマークは参考情報の一要素として扱うべき

研究の進展点と今後の展望

  • 前回調査 よりも多様なモデル・課題・現役メンテナー参加で信頼性向上
  • ベンチマーク合格 ＝「現実で使えるAI」ではないことを定量的に示した意義
  • 今後は 反復フィードバック を組み込んだAI評価や、より多様なリポジトリでの検証が必要

Hackerたちの意見

2024年中頃のエージェント、これはAI考古学についての投稿？

└

LLMが書いたコードは、当時のSWE Benchも通過してたんだよね。これって、SWE Benchが不十分なテストだってことを示してるかもしれないし、真剣な評価には使うべきじゃないね。

└

AIよりもテストの方が重要だと思う。大体、AIに与えられたテストは適切に設計されてると思うよ。リリース時には、多くのAIがうまくいかないけど、モデルはすぐに追いついて、新しいテストが必要になるところまで行くんだ。能力の限界に近いところを測るべきだよね。特定のテストの性質を狙って注目を集めようとするものもいるけど、それは長期的には勝てない解決策だし、テストはどんどん難しくなっていくから。もしモデルが見たすべてのテストで良い結果を出せるようになれば、十分なテストがあればそれも問題じゃなくなるかも。もしかしたら、特定の年にリリースされたすべてのテストを評価する総合的なAIテストスコアが必要かもね。最新のテストをすごく良く通過しても、TestSet2024で前のモデルより悪い結果だったら、そのモデルは最新のクールなテストを通過するように訓練されてるってことになるかもしれない。X、Y、Zのテストを通過したAIが人間の能力を持ってると解釈するのは問題だよね。そう言ってる人には、「カスパロフはいいコーヒーを淹れるよ」って教えてあげて。

なるほど！昨日、swe-benchのようなテストベースの評価の弱点について何か書いたんだけど、確かに役立つけど、テストに組み込むのが難しいこと、例えば仕様や意図の整合性、スコープの拡大、コードベースのパターンへの遵守、チームの好み（リスク許容度など）を見逃してるんだよね。これらの要素は本当に重要だから、テスト評価は実際の有用性の決定的な指標としてではなく、弱い/方向性のある先行指標としてもっと頼るべきだと思うよ。[1] https://voratiq.com/blog/test-evals-are-not-enough/

「あなたのリポジトリ用の評価」を構築することに取り組んでるんだけど、一般的に使われるベンチマーク、例えばSWE-benchが壊れてるっていう理論に基づいてるんだ。正しい/価値のあることをテストしてないし、トレーニングデータに組み込まれてるから（OpenAIの研究についてはここを見てね https://openai.com/index/why-we-no-longer-evaluate-swe-bench...）。面白いことに、私が評価を行った3つのオープンソースリポジトリでは、モデル（5.1-codex-mini、5.3-codex、5.4）のテストスコアは比較的似てたけど、コードの質や元のPRとの同等性といった他の指標を見ると、かなりの違いがあったんだ。興味がある人はここに結果を載せてるよ https://www.stet.sh/leaderboard

└

いいね、君のアイデアすごく好きだよ。こんなの聞いたの初めて！

└

それについてもやってるよ。チャットしたいなら教えてね！

└

すごく面白そうだね。特に、既存のPRとの比較が好きだな。でも、既存のPRがほとんどの合理的なことやベストプラクティスのテンプレートになるのはどうかなって思う。自分が欲しいデザインパターンを強制する内部リンターを作ってて、共通のコードの臭いを指摘するようにしてるんだ（eslintみたいなツールはカスタムルールが簡単に書けるから便利だよ）。ユースケースは、ReactとFastAPIアプリの完全なリファクタリング。今、すべてが特別すぎる症候群に悩まされてて、機能間で同じパターンを使いたいだけなんだ。リンターがアーキテクチャや世界の見方を説明するagents.mdファイルを持ってると、かなりうまくいくんだけど、エージェント（今はClaude code opus 4.6）にディレクトリ構造やデザインの基本をしっかりさせて、変な行動を制限する方法はまだ分からない。各行のコードをシンプルで理にかなったものにするのが難しいんだよね。エージェントが範囲外に出て変なことをするのを防ぐ方法も、レビューで見つけて新しいルールを追加しないといけない。これは比較的新しい試みだけど、直感的には、リントルールや「評価」やしっかりしたエージェントのレビューサイクルがあれば、アーキテクチャから求めるものを強制するための特注リンターが整うのもそう遠くないと思う。ちなみに、これらすべての大きなボトルネックは、今のチームが引き継いだコードベースにテストが全くないことなんだ。画面の微妙な詳細をうっかり消しちゃうのが簡単すぎる。すべての機能が何か分からないと、良いテストを書くのもすごく難しい。大規模なエージェントの変更を行うためのブロッカーは、テスト戦略やソリューションを先に考えてから、厳格に再アーキテクチャや新しいデザインを進めることだと感じる。

コードベースのエントロピーを測る指標が必要だと思う。複雑さの信号を提供するためにね。トークンごとにお金を払ってるから、エージェントに即座に情報を伝えるコードパターンが欲しいんだ。そうすれば、パターンを繰り返したり、意味のある形で拡張したりできるから。これは次の支援コーディングの波になると思うよ。今はコードを書くのがうまくいく段階で、質も大体は良いけど、既存のリポジトリの文脈では不必要に複雑になってることがあるから。

└

コードベースの「エントロピー」を測る方法があるんだ。バイナリラムダ計算やトリアージ計算みたいなものを使って、プログラム（ライブラリやプログラミング言語の構造、OSを含む）をそれに変換して、ビット単位でプログラムのサイズを測るんだ。クロスエントロピーも測れるけど、これは基本的に上記のプログラムエントロピーからプログラミング言語や標準ライブラリの関数のエントロピーを引いたものだよ（つまり、一般的に知られていると仮定される抽象）。これは「標準的な」抽象への準拠を評価するのに役立つ。データ型が表現できる状態の数を数えることで「最大エントロピー」を測る方法もあるよ。関数の最大エントロピーは、入力と出力の間のクロスエントロピー（関数を通信チャネルのように扱う）なんだ。「最大エントロピー」と「関数エントロピー」（ビット単位のサイズ）の「違い」（どうやって変換可能にするかはわからないけど）が、関数に対する理解度（型シグネチャで表現された仕様と比較して）がどれくらい良いかを示すんだ。最近、ソフトウェア工学でエントロピー測定（と情報理論）を使って複雑さの見積もり（そして変更に必要な時間）をするべきだと主張してるんだ。

└

サイクロマティック複雑度が良い指標になるかもね。もちろん、これを利用することはできるけど、そういうのはすぐにわかるよね。

└

結局、これは文字列だから、文字列のエントロピーの測定はよく研究されてるよね。LLMは変数名でそれを利用し始めるかもしれないから、ASTを使う必要があるかも。実際にそんなことを試してみようかな；いいアイデアだね。

└

トヨタの意図しない加速事件で使われた「マッケイブのサイクロマティック複雑度」って指標があったけど、今のAI支援コードと一緒に使ってる人いるのかな？

「テスト通過」以外の代替スコアを見るのも面白いかも、例えば、差分のサイズ、追加/削除された抽象度の深さ、または解決策が新しいモジュールや依存関係を導入するかどうかとか。そうすれば、「マージできない」PRがシンプルな構造的信号と相関するかどうかがわかるかもしれないね。

実際に見てきたことと一致するね。失敗の原因は間違ったコードじゃなくて、人間が選ばないような方法で問題を解決するコードなんだ。不要な抽象、コードベースの既存のパターンを無視、根本原因ではなく症状を直す。テストは通るけど、PRはコードベースを悪化させる。SWE-benchは「パッチは機能するか」を測るけど、マージの実際の基準は「これがプロジェクトを理解しているチームメンバーが書いたように見えるか」なんだ。

└

自分はAIには懐疑的だけど、LLMが人間が選ばないような変な方法を見つけて、それが実は良い結果になることがあると思うんだ（ダフのデバイスレベルの話みたいな）。そういうのが人間のプログラミング用語に入ってくることになるかも。

└

これ、他の緑のユーザー名のコメントと一緒に、AI生成のコメントなのかな？もし違ったらごめんね。AIは人間の文章で訓練されてるから、目に飛び込んでくるんだ。編集：別の緑のコメントがAIでフラグが立てられたみたいで、何かを示唆してるかも。でも、なんでこのスレッドにこんなに緑のコメントが多いの？

└

リント、ビューティファイア、より良いテスト？

└

うーん、でも組織にいるなら、AGENTS.mdやCLAUDE.md、AIコードレビューなどを調整して、あなたの人間主導または自動生成されたAIコードが組織の基準に合うようにするよね。モデルが組織がどうしたいかを積極的に理解する必要はないと思う。ユーザーがそれを実現するから。だから、この投稿はちょっと行き過ぎかも。今まさに、自分のPRやClaudeの指示、PRの指示を基準に合わせて調整してるところなんだ。面白いことに、逆の問題が起きてて、Claudeが自分のPRの評価を下げてる。テストやドキュメント、エラーハンドリングがリポジトリ内の他のコードよりも良いから、合わなくて評価が低くなってるんだ。明示的な指示なしで、もっと頑張ってほしくないんだよね。

└

これらは、人間のジュニアエンジニアの仕事でよく見られる同じような問題だね。

└
  • ダッシュ * トリプレット * XはYではなく、Z * XだけどY * 最初は良さそうに見える言葉だけど、よく読むと議論の文脈では全く意味がない: 「根本原因ではなく症状を修正する」 フラグが立った。
└

「人間が選ぶような方法では解決できないコードだけど、人間が選ぶ方法よりも良いのか？それは重要なのか？」コンパイラも、人間が選ばないような方法でアセンブリを書くことがあるしね。コンパイラの初期の頃は、ほとんどのプログラマーが手作業でアセンブリを組んでたから、生成されたアセンブリを見て「これはダメだ」とバカにしてたんだよ。囲碁みたいなゲームでは、人間が選ばない手を選ぶ「AI」が人間を超えたってこともあるしね！つまり、「人間が選ぶ方法で問題を解決する」ことは、単に問題を解決することとは違うし、俺の意見では必ずしも必要ではないと思う。

エピソードの時間だ！Codex GPT 5.4 xhighにRustのprocマクロを生成させたんだけど、結構シンプルだったよ。sqlparserを使ってSQL文を解析して、行を生成するクエリのカラム名を抽出するってやつ。生成された実装はちゃんと動いたけど、コードが約480行もあって、ちょっと嫌だった。構造と流れがなんか…変だったんだよね。追いかけるのが難しくて、かなりイライラした。だから、いくつかの簡素化を加えて再実装してもらったんだ。そしたら、600行以上の結果が返ってきた。流れはシンプルで追いやすくなったけど、やっぱりこのタスクには多すぎる感じがした。そこで、袖をまくり上げて手動でコードを削除したり変更したりしてみた。少し経ったら、230行未満にまで減らせて、流れもすごく読みやすくなった。だから、SWEのベンチを通過するPRが機能的には正しくても、コードがひどくて受け入れられないってこと、すごく分かるよ。

└

時間があれば、手動で達成したコードに似たものを生成するようにプロンプトを変更する練習をすることを強くおすすめするよ。似たような練習をすることで、エージェントのプロンプトスキルが向上するし、プロンプトの一部を変更することで結果がどう変わるかが分かるからね。

└

うん、俺も似たような経験があったよ。125行の関数を25行に減らしたことがある。

この論文、あんまり情報がないね。カットオフは2025年の9月だった。モデルがすごく改善されてるから、この実験から何を得られるのか全然分からないよ。

テストは代理的なものであるべきだね。

これ、実際に気づいてたことと一致してる。テストに合格することとマージ可能であることは、根本的に違う品質基準なんだよね。テストは動作を確認するけど、コードレビューは保守性や可読性、解決策が全体のアーキテクチャに合ってるかを評価する。SWE-benchのメトリックは、基本的に「AIがテストを通過させるパッチを作れるか」を測ってるわけで、これは「チケットを終わらせたジュニア開発者」に近いんだよね。「クリーンなコードを出荷した経験豊富なエンジニア」とは全然違う。その二つのギャップが、ほとんどのコードレビューの摩擦の原因なんだ。もっと心配なのは、チームがこれらのベンチマークを使ってAIコーディングツールを評価し始めると、間違ったものに最適化しちゃうかもしれないってこと。マージ可能なPRを40%の確率で出せるツールは、テストに80%合格するけど大幅な手直しが必要なコードを生成するツールよりも価値があると言えるかもしれない。CIパイプラインだけじゃなくて、フルレビューサイクルを捉えるベンチマークが必要だよ。