2020年のヒューマンコードがバイブコードエージェントをエージェントテストで圧倒

ChatGPT やその他のバイブコーディング ツールは、約 40,000 件のマッチでテストされましたが、大規模言語モデルの発明前に書かれた大学院生のコードに負けました。

英国の新しい研究では、研究者らは人間がコード化したエージェントと バイブコード 最新の大規模言語モデル（LLM研究者たちは、ChatGPT-5 や Claude などの新しいタイプのエージェントをテストし、AI の支援なしで作成されたエージェントが AI を活用したバージョンを非常に簡単に打ち負かすことを発見しました。

両エージェントセットは、スイス連邦工科大学ローザンヌ校人工知能研究所の異なる世代の学生によって作成されました。非AIエージェントは、ChatGPTの誕生と法学修士課程（LLM）革命の始まりの2年前、2020年に授業の一環として開発されました。一方、新しいエージェントは、最新かつ最高の法学修士課程（LLM）の支援を受けて、現在在籍する学生によって作成されました。

不正操作されたゲームであっても、バイブコード化されたソリューションは勝つことができず、上位 5 位は一貫して「未加工の」エージェントによって占められ、LLM エージェントの大多数 (40 個中 33 個) は、さまざまな変数と状況を伴うトーナメントでの 38,304 回のチャレンジで、「非常に単純な」ベースライン エージェントに簡単に打ち負かされました。

論文は次のように述べています。

「私たちの研究は、最先端の LLM は実行可能なコード (つまり、構文エラーのないコード) を生成できるものの、生成されたソリューションは、戦略計画、最適化、マルチエージェント競争などの側面で人間が設計したソリューションと競合できないことを示しています。

「したがって、この研究はコード生成におけるこの新たな領域を最前線にもたらし、推論主導のコード合成を重視するベンチマーク、データセット、オープンソースのベースラインの開発を促進することを目指しています。」

考案された課題は、さまざまな戦略を駆使してオークションに創造的に参加し、落札した商品を落札者に届ける物流を手配することでした。

著者らは、LLMには、パフォーマンス向上のためにコードに介入するなど、多くの利点が与えられていたと指摘している。これは2020年版のコードでは認められていない利点である。にもかかわらず、結果を確実に改善する修正コードが提供されたとしても、LLMはそれを受け入れたり、活用したりすることができない。

「私たちのベンチマークでは、コンテキスト内で優れたソリューションを公開しても、LLM はそれを利用できません。

「この結果は、複雑なシナリオにおける文脈内学習と検索強化問題解決の限界に関する、今後の興味深い研究課題も提起しています。」

テストに使用されたLLMは GPT-5の思考, ジェミニ 2.5 プロ, クロード・オーパス4.1、と ディープシークR1*.

当学校区の 新しい紙 というタイトルです バイブコーディングはコンピュータサイエンス大学院生に勝てるか？市場主導型戦略プランニングにおける法学修士課程（LLM）対人間コーディングトーナメントは、サウサンプトン大学の著者と、オックスフォード大学およびアラン・チューリング研究所の著者によって発表された。著者らによると、このベンチマークは まもなくリリース.

方法

著者らは、この分野における従来のテストは、明確に定義されたバイナリソリューションを持つ課題に焦点を当てていると指摘している（正しい or 正しくありません）、検証済み 単体テスト著者らは、これはLLM支援コードの限界を探る理想的な方法ではないと主張し、代わりに複数の内部ベンチマークとマイルストーンを備えた、より複雑なチャレンジシナリオを考案した。このシナリオでは、勝利は可能だが決して単純ではない。

標準的な単体テスト ベースのアプローチ (上) と、著者が考案したよりオープンエンドなチャレンジ シナリオ (下、青) の比較。 ソース

著者らの研究で使用されたオークション・集荷・配送問題（APDP）は、スイスの大学が2020年に作成した学生の課題集が利用可能であったため、部分的に自主的に選択されたものでした。この課題は、AIによる開発の促進が可能になる以前に、APDPタスク用の自動エージェントの作成を目指したものでした。そのため、現代の学生に同じ課題を与え、最新のツールを利用することは比較的容易でした。

著者らは、次のような一般的なテストフレームワークを避けようとした。 HumanEval, ビッグコードベンチ および WebDevアリーナ （他にも多くの例がありますが）この種のテスト手順はデータ汚染（つまり、システムが テストデータでトレーニング 尊重する代わりに split).

APDPは、以下の2段階のロジスティクス問題に基づいています。 逆オークション および 配車ルート最初の段階では、エージェントは各配送タスクの完了に対して支払われるべき金額を入札することで、タスクの獲得を競います。入札額が高すぎるとタスクの獲得が難しくなり、低すぎると損失につながる可能性があります。

第 2 段階では、各エージェントは、時間とリソースの制約下で、獲得したタスクのみを、容量とコストが異なる車両に割り当てて、達成するための効率的な計画を作成する必要があります。

APDP では、企業は配送タスクの逆オークションで入札し、獲得したタスクのみを実行するように車両ルートを最適化して、利益の最大化を目指します。

目標は、単にタスクを完了することではなく、どのタスクの組み合わせが最も効果的かを予測し、同じことをしようとしている競合他社の戦略を予測することで、全体的な利益を最大化することです。

APDP ベンチマークは、一連の相互依存オークションに戦略的計画を導入し、各入札が将来の選択肢の状況を再形成することで、コード生成タスクの難易度を高めます。そのため、エージェントは、即時のコストだけでなく、位置、タイミング、長期的な結果についても推論する必要があります。

配達の根本的な問題は NPハードつまり、タスク数が増えるにつれて、いかなるアルゴリズムも妥当な時間内に最適な解を確実に見つけることはできない。そのため、総当たり法は実行不可能なアプローチとなり、エージェントは精度と速度を犠牲にせざるを得なくなる。

レースは始まっています

著者らの評価では、40個のLLMコードエージェントと17個の人間コードエージェントを一連の直接対決トーナメントで比較した。12のトーナメントではそれぞれ4種類の道路網トポロジーの異なる組み合わせが使用され、 オールプレイオール エージェントは他のすべての対戦相手と 2 回対戦します。1 回は、異なる車両仕様を持つ 2 つの会社をそれぞれ制御します。

この設定により、トーナメントごとに3,192試合、合計38,304試合が行われました。各試合では、集荷・配達地点と重量によって定義された50の配達タスクがオークションにかけられ、スイス、フランス、イギリス、オランダをモデルにした道路レイアウト上でランダムに抽選されました。

トーナメントで使用される簡略化された道路網：イギリス（左上）、スイス（右上）、オランダ（左下）、フランス（右下）。青と赤の四角は集荷と配達のタスクを示します。色付きの三角形はエージェントの車両の現在位置を示します。

学生エージェントは2020年のコーストーナメントから選出されました。シングルエリミネーション決勝で上位の成績を収めた8名と、ベースラインエージェントとの直接対決で優れた成績を収めた4名が選出されました。

ベースラインエージェントは固定された ヒューリスティック. ナイーブ 1 台の車両のみを使用し、バッチ処理を無視して合計距離を計算し、それに応じて入札しました。 ExpCostFixedBid 10 個のランダムなタスクをシミュレートし、平均限界費用を入札しました。 正直な タスクをスケジュールに挿入する際の実際の限界費用を計算しました。 モデル対戦相手 同じことをしたが、相手のコストの見積もりを追加し、最大額を入札した。 リスクシーキング 時間減衰事前分布とライブコスト推定および対戦相手のモデリングを組み合わせ、ここでも 2 つのうち高い方を入札しました。

評価には、（前述の）GPT-5 Thinking、Claude Opus 4.1、Gemini 2.5 Pro、DeepSeek R1を使用して構築されたLLMコード化エージェント40体が含まれました。各モデルには5つの異なる戦略が提示され、モデルごとに2回ずつ適用されました。

2つの戦略では、異なる著者によって書かれた静的なプロンプトを使用し、3つ目の戦略ではモデルに自己反省と出力の修正を求め、さらに別の戦略では別の法学修士による批評と修正を実施した。最後の戦略では、GPT-4を用いて、4つの先行アプローチすべてをレビューすることで、新しいプロンプトを合成した。

基本プロンプトは元の学生の課題を反映したもので、非常に複雑な方法に頼ることなく、配信環境を説明し、モデルに入札して利益を最大化するための計画を立てるように指示します。

すべてのLLMエージェントは、セルフプレイとトーナメントの両方の設定で、観察可能なバグがすべて修正されるまでテストされました。バグ修正は、エラー情報に基づいてLLM自身によって自律的に処理されました。

論文によると、一般的なLLMの失敗には、タイムアウト制限の違反、割り当てられたタスクの受け取りまたは配達の失敗、車両容量制限の違反などがあり、これらのエラーは、明示的な指示を無視したり、誤った再計画ロジックから発生することが多い。^†:

私たちが発見したもう 1 つの一般的な問題 (主に Gemini、Claude、DeepSeek で発生し、GPT ではそれほど多くありません) は、LLM がバグを解決できないことが頻繁に発生することです。

たとえば、エージェントは、LLM にエラーを通知して更新されたバージョンのコードを受信するサイクルを複数回 (たとえば 5 ～ 15 回) 実行したにもかかわらず、一貫してタイムアウトします。

「このような状況（LLMが繰り返し同じバグを解決できない状況）に対して私たちが見つけた唯一の解決策は、 ゼロからやり直す全体的に、私たちは バグのないコードを実現するための多大な手作業評価対象としたバグのないエージェント 40 個を取得するには、相当多くのエージェントを生成する必要がありました。」

以下に示す結果は、4 つのネットワーク トポロジとトポロジごとに 3 つのトーナメントにまたがり、40,000 試合のベスト パートを生成した 12 のダブル ラウンドロビン トーナメントの結果をまとめたものです。

各エージェントはトーナメントごとに112試合をプレイしたため、エージェントあたりの勝敗数の最大平均は112です。標準偏差（SD）はトーナメント間の変動を反映しています。人間がコーディングしたエージェントは太字で表示されます。LLMコーディングされたエージェントは、モデル（O = GPT-5 Thinking、G = Gemini 2.5 Pro、A = Claude Opus 4.1、D = DeepSeek R1）ごとにラベル付けされ、その後に2文字のプロンプト戦略コードと、そのプロンプトで生成された最初のエージェントか2番目かを示す数字が続きます。 ソース

上記の結果に関して、著者らは次のように述べている。^†:

「LLMは、APDP問題のより単純な変種においてさえ、期待通りの、あるいは競争力のあるコードを生成しませんでした（コードはほぼ構文バグがないにもかかわらず）。これは、自動補完を超えてLLMの新たな弱点を特定する、推論駆動型コード評価ベンチマークの重要性を強調しています。」

「私たちの結果は、人間がコード化したエージェントの明らかな優位性を示しています。(i) 上位5位は常に学生エージェントが占めている、および (ii) LLMエージェントの大部分（40のうち33）は、非常に単純なベースラインエージェントに負けています。 （予想コスト固定入札など）。

「重要なのは、学生のコードをデバッグしなかったことです（LLMのコードは、セルフプレイとトーナメントの両方で徹底的にテスト・デバッグしました）。学生エージェントがクラッシュするたびに、自動的にLLMに勝利を与えました。これらのクラッシュの多くは簡単に修正できます（エージェントのタイムアウトなど）。そのため、学生エージェントは さらに上位にランクイン。 '

さらなる実験として、GPT-5 Thinkingは、最高のパフォーマンスを発揮した人間のエージェントのコードを改善するように促されました。 学生1しかし、LLMによって修正されたエージェントはその後10位に落ち、人間のスコアの中で最悪のスコアとなりました。LLMの変更は、解を向上させるどころか、20%近くも低下させてしまったのです。

著者らは結論する：

「[私たちの]研究結果は、LLMコード生成における重要な限界、特に生成時の推論および計画能力の限界を浮き彫りにしました。現代のLLMは構文バグのない実行可能なコードを生成できますが、それは高度な汎用AIに向けた進歩を測るためのベンチマークとしては適切ではありません。」

結論

著者らは論文の終盤で、バイブコーディングがあらゆる技術的背景を持つ人々に力を与えてきたと述べ、その実践を「平等化の力」として肯定的に評価している。しかし同時に、バイブコーディングは登場したばかりであるため、その限界は不明であり、現実的に予想されるよりもかなり高い可能性があると示唆している。

彼らは目標の転換を呼びかけることで提案を締めくくった。コンパイルされるコードから競合するコードへ.

この興味深い新しい論文をたまたま読んだ人が抱く疑問の一つは、著者らが上を狙っているのか下を狙っているのか、ということだ。なぜなら、問題のエージェントタスクは、PowerShell スクリプトやその他の形式の小さな機能や修正を吐き出すことよりも、はるかに複雑で込み入っており、バイブコーディングが適しているからだ。

* この論文では「ディープ考える 「R1」という名前は存在しないようですが、インターネット上ではほんの数件の参考文献しか見つかりません（おそらく他の著者が「DeepSeek R1」と誤って表記したものと思われます）。もしこれが私の誤りであれば、プロフィールからご連絡ください。修正いたします。

^† 強調は著者のものであり、私のものではありません。

最初に公開されたのは、2025 年 11 月 26 日水曜日です。フォーマットのため、17:35 EST に修正されました。