Coding Agent のモデルを選ぶとき、最初の流れはかなり単純に見えます。SWE-bench やコミュニティの leaderboard を見て、スコアが一番高いモデルを選び、Codex や Claude Code などの harness を自分の project に入れる。

私も public leaderboard は今でも見ます。候補を絞るには便利です。ただ、長く保守する repository に実際に入れると、問題はもっと具体的になります。TypeScript が中心なのか Python なのか。テストで browser、Postgres、Redis を起動するのか。普段の変更は UI、cache、SQL、build system のどこに多いのか。過去の merged PR の難易度はどう分布しているのか。

public benchmark だけで、そこまで答えるのは難しいです。

最近 Show HN で SelfBench を見つけました。もう一つの共通 leaderboard を作るのではなく、自分の repository で実際に merge された PR を Coding Agent の eval task に変え、同じ task set で model、harness、reasoning effort、cost を比較する project です。

最初に確認したかったのは単純でした。repository が変わると、本当に model ranking も変わるのか。

2026-10-07 時点で SelfBench が公開していた 9 repository の release を全部取得し、公開 result をこちらで再集計しました。さらに public task の一部を読み、upstream guardrail が本当に source code に実装されているかも確認しました。

結果として repo-specific eval の価値はかなり支持されました。ただし、もっと強い言い方はできません。最も高い accuracy を出す setting は repository ごとに変わります。しかし task が数十件しかない現在の release では、数ポイントの差だけで「この model が明確に強い」と言うにはまだ不安定です。

SelfBenchの面白さは、過去のPRを自分のtask distributionに変えること

SelfBench は generic な coding puzzle を人手で並べるところから始めません。repository で実際に merge された変更を材料にします。

流れはおおむね次の通りです。

```text merged PR ↓ 変更前の base commit に戻す ↓ engineering request から instruction を作る ↓ held-out tests + reference patch を用意 ↓ smoke / nop / oracle / determinism ↓ independent reviewer ↓ Harbor task として export ↓ 同じ task を複数の model / harness / reasoning setting で実行 ↓ accuracy と cost を比較 ```

土台になっている Harbor task format はこの用途と相性がいいです。instruction、container environment、tests、solution が分かれ、agent は自分の環境で実装し、verifier が held-out material で採点します。

SelfBench はそこに「過去の PR を benchmark 化する」層を追加しています。

ある程度まとまった PR history を持つ team にとって、ここはかなり大きな違いです。model が向き合うのは誰かが作った一般問題だけではありません。自分たちが本当に merge してきた変更、その repository layout、dependency、test style、長年積み重なった engineering constraint まで task distribution に入ってきます。

単に「public leaderboard から自分と似た tech stack の repository を探す」より一段具体的です。

だから私は public benchmark を不要だとは思いません。役割を変えるだけです。public leaderboard で shortlist を作り、最後の default setting は自分の repository の task で決める。その使い分けが自然です。

9つのrepositoryを比べると、ずっと1位のsettingはなかった

当時 SelfBench の public result API には 9 repository がありました。各 release から task count、passed、accuracy、model、harness、reasoning level、cost-per-task を取得し、published accuracy が本当に `passed / tasks` と一致することも確認しました。

最高 accuracy の setting は次の通りです。

Repository	Tasks	Highest-accuracy setting
vercel/next.js	38	GPT-6.1 Sol / Codex / High — 84.2%
PostHog/posthog	36	Claude Opus 5.5 / Claude Code / High — 69.4%
earendil-works/pi	50	GPT-6 Sol / Codex / High — 84.0%
getsentry/sentry	81	Claude Opus 5.5 と Claude Sonnet 5.5 / Claude Code / High — 82.7% で同率
mupt-ai/self-bench	38	GPT-6.1 Sol / Codex / High — 76.3%
vercel/eve	38	Claude Opus 5.5 / High と GPT-6.1 Sol / Low — 73.7% で同率
vercel/vercel	47	Claude Opus 5.5 / Claude Code / High — 80.9%
supabase/supabase	36	4 setting が 77.8% で同率1位
pingdotgg/t3code	39	Claude Opus 5.5 / Claude Code / High — 76.9%

同率も含めると、9 repository から 6 種類の exact top setting、5 種類の winner model family が出ました。すべての repository で勝つ一つの完全な setting はありません。

同じ setting が複数 repository に出ている部分について、相対順位の Spearman rank correlation も計算しました。repository pair ごとの相関は約 0.462 から 0.995、中央値は 0.807 です。

これは「repository が変わるたびに leaderboard が完全に逆転する」という話ではありません。強い model は多くの場合やはり強いです。ただし「public leaderboard で1位なら、自分の repository でもそのまま1位」と考えられるほど安定してはいません。

その結果、私が気になる問いも変わりました。

この repository、この実際の変更分布、この harness、この cost budget なら、どの setting が適しているか？

ここで model name だけを見るのは足りません。SelfBench が model、harness、reasoning effort を一つの setting として扱うのは理にかなっています。同じ model でも harness や effort を変えると、accuracy と cost が両方動くからです。

「Claude vs GPT」だけに縮めると、比較に必要な情報を一段落としてしまいます。

cost 側では逆にかなり安定した結果が出ました。今回確認した 9 release すべてで、最安の model family は GPT-6 Luna でした。ただし Low / High reasoning setting は repository ごとに違います。

もちろんこれは 2026-10-07 の snapshot です。provider pricing、reasoning configuration、task length は変わります。再利用できるのは「accuracy × cost の Pareto frontier を見る」という方法であって、今日の価格を固定値として覚えることではありません。

現在の結果は SelfBench public directory で確認できます。

私が言い方を変えた理由：9つとも1位と2位がきれいには分かれなかった

上の表だけを見ると、「Next.js には GPT-6.1 Sol、PostHog には Claude Opus が向いている」と書きたくなります。

方向性としては理解できます。ただ、断言するには強すぎます。

現在の release は 36〜81 task しかありません。

そこで各 setting の `passed / tasks` から Wilson 95% interval を使った小標本の sensitivity check を行いました。benchmark task を厳密な IID sample と仮定したわけでも、正式な significance test をしたわけでもありません。見たかったのは一つだけです。leaderboard で数ポイントしか離れていない差が、小さな sample の不確実性を入れたときにどれだけ頑丈に見えるのか。

結果は 0 / 9 でした。

9 repository のどれも、1位の interval が2位の interval より完全に上に分離していません。

Next.js なら1位は 32/38、84.2%。2位は 30/38、78.9% です。leaderboard では 5.3 point 差ですが、descriptive interval はかなり重なります。

Sentry はもっと近く、67/81 が 82.7%、66/81 が 81.5% です。ここから「Claude Sonnet が GPT-6.1 Sol に明確に勝った」と書くのは、leaderboard に持てない確信まで持たせることになります。

これは model に差がないという意味ではありません。SelfBench が無意味という話でもありません。

むしろ repository-specific eval は model selection を現実の engineering に近づけています。ただ、数十 task の leaderboard は方向性の evidenceとして使うのが自然です。どれが大きく遅れているか、どれが Pareto frontier に入るか、どの setting を自分の repository でもう一度試すべきかを見る。2% や 5% の差から永久的な勝者を決めるものではありません。

team default、調達、model routing のような重要な決定に使うなら、私は task を増やし、trial を繰り返し、batch が変わっても ranking が安定するか確認します。

private leaderboard を一回だけ走らせて長期 winner を決めるなら、public leaderboard を一回だけ見るのと本質的にはあまり変わりません。

自動生成benchmarkの怖さは、agentの作弊よりgraderの偏りにある

SelfBench で最初から気になっていた点があります。task authoring agent は、元の完成済み PR を見ることができます。

これは便利です。完成した変更から instruction、tests、reference solution を作る必要があるからです。ただし benchmark 設計としては明確な危険もあります。hidden tests が gold implementation に寄りすぎると、task が「要求を満たす」から「元の作者と同じ作り方を再現する」に変わってしまいます。

SelfBench はこの問題をかなり意識しています。upstream を commit `67242b85569ea0c27af0c68bd2769ed2d02a05c4` に固定し、README ではなく source code を確認しました。

実際に確認できた guardrail は次の通りです。

• static audit が gold patch と held-out test patch の file overlap を block する
• verifier が agent による held-out path の変更を restore し、grading 前に保護する
• nop gate では base snapshot が新しい test に失敗し、既存 regression は pass する必要がある
• oracle gate では reference patch 適用後に pass する必要があり、fail-to-pass を繰り返して determinism も見る
• independent reviewer prompt が 別の正しい実装でもこの test に通るべきか を明示的に確認する

さらに Next.js から2 task、Sentry から2 task を抽出し、instruction、test patch、gold patch を読みました。third-party repository code は実行していません。

4 task とも structural check は問題ありませんでした。test と gold の file overlap は 0、instruction に source PR number / GitHub URL / grader artifact name の明確な leakage はなし、environment image は digest pin、held-out path protection あり、benchmark canary ありです。

manual review でも、gold にしか存在しない private helper を hidden test が要求するような分かりやすい coupling は見つかりませんでした。

たとえば Next.js の stale-cache task は stale-while-revalidate、same-key deduplication、root-param key の独立性など observable behavior を要求しています。hidden tests は app fixture や cache API を通してそれを検証し、gold patch は内部 cache wrapper を変更します。

Sentry の dropped-data UI task では、説明文の検証に幅を持たせた semantic regex を使い、元の PR の exact copy に固定していません。

こういう grader は健全です。

ただし4 task は4 taskです。これで generation pipeline 全体が常に公平だとは言えません。Authoring agent は完成後の implementation を見ています。その information advantage 自体は残ります。mechanical rule と reviewer は coupling risk を下げられますが、論理的に 0 にすることはできません。

training contamination も別の制約です。

SelfBench は公開 task に benchmark canary を入れ、通常の検索に載りにくくする工夫もしています。将来の filtering や contamination detection には役立ちます。しかし benchmark が作られる前から public だった PR、code、discussion が過去の training data に入っていないことまでは証明できません。

つまり「自分の repository 由来の benchmark」イコール「contamination-free benchmark」ではありません。private repository はこの点では有利ですが、今度は source code、credential、data governance の問題が増えます。

今の使い方：public leaderboardで絞り、自分のrepositoryでdefaultを決める

この分析を終えて、私はむしろ public coding-agent benchmark をこれからも使うつもりです。ただし最終決定までは任せません。

小さな personal project で merged PR がまだ少ない、あるいは Coding Agent をたまにしか使わないなら、自前の repo-specific eval は割に合わないことがあります。public benchmark から2〜3候補を選び、価格と実使用で決めるだけでも十分です。

一方で、複数 model / harness を常用している、API cost が無視できなくなった、team default を決めたい、repository に数十〜数百の代表的 merged PR がある、test environment を安定して再構築できる、あるいは model routing を作って「どの task をどこへ送るか」を決めたい——こうなってくると自分の repository の eval に価値が出ます。

それでも最初から巨大な benchmark は作りません。

まず実際の work distribution を代表する PR を選ぶ。task instruction と hidden tests を人が確認する。その上で accuracy、cost、failure pattern、setting の ranking stability を見る。task を増やしたり再実行したりしても同じ傾向が残るかを確かめる。

SelfBench はこの workflow をすでにかなり完整に実装しています。この article のために duplicate companion repository を作る意味はありません。実装を見るなら mupt-ai/self-bench から始められます。instruction、environment、solution、verifier を分離する task format 自体を理解したいなら Harbor Task Structure が次に役立ちます。

「Agent が書いた test suite 自体を信頼できるか」が気になるなら、以前行った Mutation Testing の第一者 A/B 実験 も関連します。Codex の新 model が client に表示されないことが問題なら、Codex Model Catalog と Sub2API の原名 passthrough をどうぞ。

今回 SelfBench から得た一番大きな収穫は、その日にどの model が1位だったかではありません。

model selection を「他人の leaderboard における平均能力」から一歩進め、「自分が本当に merge する種類の変更で、この setting はどう振る舞うか」に変えられることです。そしてもう一つを忘れないこと。agent を評価するだけでなく、agent を評価する benchmark 自体も評価する必要がある。 そこまでやって初めて、repo-specific eval は別の高価な leaderboard 信仰ではなく、engineering decision の材料になります。