AIコーディング助手は本当に使えるのか、実務データで検証

RealClawBench って何？従来のテストと何が違うの？

従来のコーディング・テストは、「完成度の高い問題」を後から作ってます。たとえば「フィボナッチ数列を求めよ」みたいに、明確なゴールと正解が用意されたもの。AI はそういう整理された問題には強く、だから 95 点みたいなスコアが出ていたんですよ。 RealClawBench は逆のアプローチ。実際にエンジニアが GitHub や開発ツール上で書いてる仕事のやり取りをそのまま拾ってきて、それをテストにする。つまり「その辺のコード修正を頼まれた」「要件を読み間違えた」「なぜか環境でだけ動かない」みたいな、実務特有の泥臭さがそのまま反映される。281 件のタスクは全部、誰かが本当に困ってたシーンなわけです。 そうなると AI の正答率が 65.8 パーセントに下がる。つまり、テストと実務のズレが可視化された。AI は整理された問題には強いけれど、不完全な情報や想定外の文脈には弱いということが、数字で証明されたということです。評価軸が『いい成績』から『役に立つか』へシフトしてきたような感じがします。

プログラマーとして AI コーディング助手を使ってる人にとって、正答率 65.8% って『使える』『使えない』のどっちなの？

正答率 65.8% をどう受け取るかは、その人がコードの何を AI に頼ってるのかで大きく変わります。 「全てのコードを一から書いてほしい」なら、3 回に 1 回はやり直しが必要な計算。これは使い物にならないレベルですよね。ただ、実務プログラマーの使い方を見ると、もっと細粒度の仕事を頼んでることが多いんです。既存コードの一部修正、ライブラリの使い方調べ、単純な関数の補完。そういった「部分的な補助」なら、正答率 65.8% は悪くない数字かもしれません。1 時間のうち 40 分は確実に時短できるけど、20 分は自分で手直しする、という感じ。 もう一つ重要なのは、AI が外した 34.2% が「どの種類のタスクか」という点。複雑な環境設定や要件読み取りだけが落ちるなら、むしろ AI の得意な単純タスクを選別して使う戦略が成り立つ。逆に、簡単なはずのコードで頻繁に間違うなら信頼度は下がります。「使える・使えない」は、正答率という数字より、自分たちの仕事の構成と、AI の失敗パターンがどう重なるかで決まるのかもしれません。

なぜ今になって『実務データでのテスト』が必要になったの？これまでのテスト方法は誰が作ってたの？

AI コーディング助手が急速に実用化されるにつれて、「テストと現実のギャップ」が目に見えるようになってきたのだと思います。 従来のテストは、研究機関やプラットフォーム企業が設計した「理想的な問題セット」でした。LeetCode のようなコーディング問題サイトや、学術論文の標準ベンチマーク。こうした問題は「採点しやすく、再現性が高い」という研究者側の都合で設計されてきたんです。バグなし、要件が完璧に明記された、実行環境が統一されている。つまり、実際の仕事とは異なる「クリーンな世界」での性能測定です。 でも ChatGPT や Claude が世間に出てくると、企業や開発者が本当に使い始めた。そこで初めて気づくのが「テストでは高スコアなのに、うちのプロジェクトではうまく機能しない」という違和感です。古いライブラリの組み合わせ、不完全な要件書、環境固有の制約。こうした「困った現実」を測らないテストは、もはや役に立たない。RealClawBench のような試みは、その反省から生まれているのかもしれません。

これって『テストと現実のギャップ』という、AI に限らずあらゆる技術評価で起きてる問題の一つなの？

そうですね。AI コーディング助手に限った話ではないんです。 テストと現実のギャップは、技術評価の根本的な課題。医療機器だって臨床試験で 95 点でも、実際の病院で 80 点になることはいくらでもあります。患者の体格、持病、投薬状況。環境変数が増えるほど、設定条件下での「完璧さ」は崩れていく。 ただ AI コーディング助手の場合、ギャップが特に大きいのは、テスト問題そのものが『解きやすく設計されたもの』だから。LeetCode みたいなアルゴリズム問題は、入力と出力が明確で、辺境のケースまで丁寧に書かれている。でも実務のコード修正は違う。相手は『誰が書いたか分からないレガシーコード』『仕様書が曖昧』『エラーメッセージだけが手がかり』という泥くさい環境です。 RealClawBench が 281 件の実セッションを拾い上げたのは、その泥くささを点数化する試みなんです。医療や製造では、実験室と現場のギャップに向き合うのに何十年もかかってますから、AI の評価がやっと『本当に困っている人向け』にシフトしているのは、むしろ前進に見えます。

正答率が 65.8% に留まるってことは、逆に言えばどんな種類の仕事なら AI が得意で、どんな仕事が苦手ってわかったってこと？

記事の内容からは、その詳細は直接は書かれていないんですよね。ただ、背景をもう一度見ると見えてくるものがあります。 記事に挙げられている「現実ならではの複雑さ」は、特定環境での動作、書き足りない要件の読み取り、微妙な検証。これらって、すべて『文脈を読む』『試行錯誤を重ねる』『フィードバックループを回す』という、一往還では終わらない仕事ばかりです。 逆に言うと、AI が得意なのは、問題と答えが明確に対応している単発のコード片。LeetCode みたいな教科書的な問題なら正答率 95% というのは、まさにそれを示しています。 でも実務では、開発者が最後に「ちょっと動かなくなった」と言い出したコードを直す。その時点では、背景にある実行環境、他のファイルとの関係、想定外の入力まで含めて考える必要がある。AI はそこを読み取れず、部分的な修正で止まってしまう、ということなのかもしれません。単純な問題の得意さと、現場の問題の得意さは、別物ということになりそうです。