コーディング試験の「ノイズ」を見抜く：本当に優秀なエンジニアを見極める方法

コーディング評価において、有益なシグナルと単なるノイズをどのように切り分けるべきか。技術選考の現場で直面する課題について解説します。

AGIを実現するっていうのは、ただベンチマークのスコアを全部パスする以上のことだよ。未知の問題にも対応できなきゃ意味がない。

SWE-Benchが欠陥だらけだってことは、最初からみんな分かってたことじゃないの？作者たちですら制限を認めてるし、とっくの昔に次の段階へ進んでるよ。

新しいモデルをリリースする数日前にこれを発表するなんて、タイミングが悪すぎるだろ。

ここにある数字を見ると、ベンチマーク全体で800タスクもないみたいだな。それなら数人のエンジニアが1週間あれば総当たりできるレベルだ（実際、OpenAIが最終的にやったのがそれだし）。

一方で、実際にその作業をやり遂げたことについては評価したい。

もう一方で、ゴミを入れればゴミが出るっていう格言通りだよ。元の作者たちが実際にチェックしてなかったのは恥ずかしいし、それを追う側のみんなが誰もチェックしてなかったのも同じくらい恥ずかしいことだ。

それに記事を読めば分かるけど、LLMが問題を見つけられたとはいえ、プロのソフトウェアエンジニアが見つけるような問題については過小評価しがちな傾向がある。

「ベンチマークを直すために必要な作業を全部やったけど、結局ベンチマーク自体を捨てることにした」って言ってるように読めるな。元データがそんなに聖域化されてて、修正できない理由でもあるのか？最後の方で、ベンチマーク生成にもっと精査されたアプローチを求めてるけど、個人的な直感だと、現実世界のデータから雑で定義の甘いテストを持ってきて、それをフェアになるように修正していくっていうのが、かなり確実な道だと思うんだけどな。

結局のところ、彼らは「ソフトウェア開発者（人間であれ何であれ）に割り当てられるタスクって、不完全だったり、自己矛盾してたり、ひどいものが多いよね」っていう結論に至ってるんじゃないか？でも、それが自分たちのツールが戦わなきゃいけない現実世界だろ。同情はできないね。

Terminal Bench 2にはいろんな理由で偽のスコアが溢れてるよ（RyanやAlexといった最高のチームが最近かなり怪しい提出物をクリーンアップしてくれたけどね）。多くの研究室はタイムアウトやハードウェア構成をいじって結果を公表していて、実質的にタスク本来のテスト内容をバイパスしてるんだ。さらにハーネスレベルでのチートやモデルの報酬ハッキングなんかもあってさ…

実際、数ヶ月経ってもずっと気になってることがあって、それはgpt-5.5の公式提出物だ。特にこのタスクがひどい（https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0... ）。

タスクのタイムアウト設定は以下の通り（https://github.com/harbor-framework/terminal-bench-2/blob/main/caffe-cifar-10/task.toml ）。

[verifier]
timeout_sec = 1200.0

[agent]
timeout_sec = 1200.0

[environment]
build_timeout_sec = 600.0

つまり、どのエージェントも3000秒以上かかってはいけないはずなんだ。でも上のリンクにある5回の試行のうち2回は3000秒を大幅に超えてる（それぞれ75分と80分）。失敗したとはいえ、それだけ長時間動いてたっていう事実は疑わしいよ。

まさにグッドハートの法則が働いてるね。

新しいベンチマークが欲しいな。API費用に100ドル使えるとして、モデルが一連のベンチマークテストに対してどれだけの成果を出せるか、みたいなやつ。

効率と知能の組み合わせを測定できるような何かを出してくれよ。

そうすれば小規模モデルにとっても面白い戦術が取れるようになると思う。例えば、自分の結果を検証するためにコンピューターを使って時間をかけて問題をじっくり解く、みたいなことが可能になる。大規模モデルには自己テストするための予算がないかもしれないからね。

裏側を覗いてみると、どのベンチマークもかなりひどいもんだよ。

参考までに言うと、CodexやClaude Codeを使う時の面倒な手順を置き換える「スーパーバイザー」を作ってて、最近それをTerminal Bench 2.1で走らせてみたんだ。

最初はワクワクしたよ。自分の仕様駆動型スーパーバイザーが、いくつかのタスクで素のCodexを上回ったからね。でも詳しく調べていくうちに、タスクそのものに山ほど問題があることが分かった。

一番の要点は、指示が曖昧なのにテストケースが過剰に具体的すぎることだ。

いくつか例を挙げるよ。

• configure-git-webserver では、「～が実行できるように」というような表現があって、エージェントが何をすべきで、何を削除すべきかの境界が曖昧になってる。そのせいで、考えすぎたエージェントはサーバーを設定したあと、検証ツールがチェックするまさにそのファイルを削除しちゃうんだ。ユーザーが同じコマンドを打ったら競合しちゃうからね。

• make-mips-interpreter では、「あなたがDoomを正しく起動できたかチェックする」という記述があるせいで、エージェントは生成されたファイル /tmp/frame.bmp を残そうとする。スーパーバイザーはユーザーが「それ（エージェント）がDoomを起動した」ことを確認することを期待してるからで、孤立した環境でDoomが起動するかどうかを見てるわけじゃないんだ。ところが検証ツールは /tmp/frame.bmp が存在すると終了しちゃうから、Doomの起動に失敗する。ブートから生成されたものかどうかを確認してないんだよね[0]。

• mcmc-sampling-stan では、スーパーバイザーエージェントは正しい値に到達することが多いのに、単なる小数形式じゃなくて科学的表記法でドメイン固有の数値出力をしてしまう。すると検証ツールが結果をうまく解析できずに失敗する[1]。

これらは見つけた不一致のほんの一部だよ。つまりTerminal Bench 2.1はもう飽和してて、GPT-5.6やMythosの結果は期待されるしきい値の限界（それぞれ88.8%と88%）に達してるってことだ。

一番の問題は、ほとんどのベンチマークが「ワンショット」で、実際のユーザーが日常的に行っているような「モデル＋ハーネスでの長期反復タスク」をテストできてないことだと思うね。

[0] https://github.com/harbor-framework/terminal-bench-2-1/issues/9
[1] https://github.com/harbor-framework/terminal-bench-2-1/issues/11

これだけたくさんあるベンチマークのためのベンチマークが絶対に必要だな。