Vibe Code Bench: Evaluating AI Models on End-to-End Web Application Development

本論文は、AI モデルによるゼロから完結する Web アプリケーション開発を評価する新たなベンチマーク「Vibe Code Bench」を提案し、最先端モデル 16 社によるテストで最高精度が 58.0% に留まったことを明らかにするとともに、自己テストの実施が性能予測に有効であることや評価者の選定が結果に大きく影響することを示しています。

要約

「Vibe Code Bench」の解説：AI は本当に「ゼロからアプリ」を作れるのか？

この論文は、AI（人工知能）がコードを書く能力を測る新しいテスト「Vibe Code Bench（バイブ・コード・ベンチ）」を紹介するものです。

これまでの AI のテストは「数学の問題を解く」や「特定のバグを直す」といった**「単一の課題」に焦点を当てていました。しかし、この新しいテストは、「アイデアを口頭で伝えたら、AI がゼロから完全な Web アプリを完成させられるか」**という、もっと現実的でハードな課題に挑戦しています。

以下に、難しい専門用語を使わず、身近な例え話を使って解説します。

---

1. 従来のテスト vs 新しいテスト：料理の例え

• これまでのテスト（HumanEval や SWE-Bench など）：
  「卵を割って、バターを溶かす」という**「特定の工程」**だけを評価していました。AI は「卵を割る」のは得意でも、「料理全体を完成させる」ことはまだ試されていませんでした。
• 新しいテスト（Vibe Code Bench）：
  「イタリアンレストランを開きたい。メニューはパスタとピザ、注文システムも欲しい」という**「お店全体の企画」**を AI に渡します。
  AI は、レシピ（コード）を書くだけでなく、
  • 食材の調達（データベースの設定）
  • 厨房の設備設置（サーバーの構築）
  • 注文ボタンの動作確認（ブラウザでのテスト）
  • お客さんが注文できるか試す（実際の動作確認）
    これらをすべて一人で完結させて、実際に動くお店（アプリ）を完成させる必要があります。

2. 実験の仕組み：AI 職人と自動検査員

このテストでは、以下の手順で AI を評価しました。

1. 100 人の「注文主」：
   「個人用の習慣管理アプリ」「駐車場の予約アプリ」「企業の経費申請アプリ」など、現実的な 100 種類のアプリの注文（仕様書）を用意しました。
2. 16 人の「AI 職人」：
   最新の AI モデル 16 社（OpenAI, Anthropic, Google など）に、それぞれ 50 時間以内の制限時間でアプリ作成を依頼しました。
3. 自動検査員（ブラウザのロボット）：
   AI が作ったアプリが本当に動くか、人間の代わりに**「目が見えて、クリックができるロボット」**がチェックします。
   • 「ログインボタンを押したら画面が変わるか？」
   • 「注文したらメールが届くか？」
   • 「支払いができるか？」
     これらを 1 つずつ確認し、アプリが「合格」するか「不合格」かを判定します。

3. 驚きの結果：まだ「完璧」には程遠い

結果は、AI の進化を示しつつも、課題も浮き彫りにしました。

• ベストな成績でも 6 割強：
  最も優秀な AI（GPT-5.3-Codex）でも、100 個のアプリのうち62 個程度しか完全に成功させられませんでした。残りは、ログインができなかったり、支払いエラーが出たりして「お店がオープンできない」状態でした。
• 「自分で試す」のが重要：
  成功した AI は、コードを書いている最中に**「自分でアプリを立ち上げて、ボタンを押してテストする」**という行動を頻繁に行っていました。
  • 例え： 料理人が味見をしながら調理する人ほど、美味しい料理を作れるのと同じです。
  • 逆に、ただひたすらコードを書き続けるだけで「味見（テスト）」をしない AI は、失敗することが多かったです。
• コストと時間のトレードオフ：
  高い性能の AI は、より多くの時間とコストをかけていましたが、必ずしも「時間を使えば使うほど上手くなる」わけではなく、ある程度で頭打ちになる傾向もありました。

4. 評価者の「目」が結果を変える

面白い発見として、「誰が採点するか」で結果が変わることがわかりました。

• 同じアプリを、異なる AI モデルや人間がチェックすると、評価がバラつくことがありました。
• 特定の AI モデル（Claude Sonnet など）は、人間の評価者と非常に近い基準で採点できることがわかりました。これは、AI が AI を評価する際にも、「誰にチェックさせるか」が重要であることを示しています。

5. なぜこのテストが重要なのか？

このテストは、AI の能力を「コードを書くこと」から**「ソフトウェアを作る（ビジネスを立ち上げる）」**という視点で評価する第一歩です。

• 現状： AI は「優秀なアシスタント」ですが、「一人前のエンジニア」として任せるにはまだ不安定です。
• 未来： このテストを通じて、AI が「ゼロからアプリを作る」能力を高めれば、プログラミングが苦手な人でも、アイデアを口にするだけで自分のアプリやサービスを作れるようになるかもしれません。

まとめ

この論文は、**「AI はもうコードが書けるが、まだ『ゼロからアプリを完成させる』のは難しい」**と伝えています。

しかし、AI が**「自分で試して修正する（味見する）」**習慣を身につけることで、その能力は劇的に向上することがわかりました。今後は、AI が単なる「指示待ちの職人」ではなく、「自分で考えて試行錯誤する職人」に成長していくかが、次の大きな課題です。

技術概要

Vibe Code Bench: エンドツーエンド Web アプリケーション開発における AI モデルの評価

本論文は、Vals AI とマサチューセッツ工科大学（MIT）の研究者たちによって執筆された「Vibe Code Bench（VCB）」という新しいベンチマークと、それを用いた大規模言語モデル（LLM）の評価結果を報告するものです。以下に、問題定義、手法、主要な貢献、結果、および意義について詳細な技術的サマリーを記述します。

1. 問題定義と背景

現在のコード生成 AI の評価基準は、単一の関数生成（HumanEval など）や既存のコードベースにおけるバグ修正（SWE-Bench など）に偏っています。しかし、実社会での「Vibe Coding（自然言語の意図からアプリケーションをゼロから構築する）」の真価は、**「ゼロからワン（Zero-to-One）」**の完全な Web アプリケーション開発能力にあります。

既存のベンチマークには以下のギャップが存在します：

• 完全なアプリケーションの欠如: 単一ファイルや既存コードの修正ではなく、マルチファイル、設定、デプロイ、ユーザーワークフローを含む完全なアプリの生成を評価するものがない。
• 実用性の欠如: 非技術者が自然言語で指示を出し、動作するプロトタイプを即座に得られるかどうかを測る指標が不足している。

2. 手法とベンチマーク設計

2.1 Vibe Code Bench (VCB) データセット

VCB は、100 の Web アプリケーション仕様（50 件の検証用、50 件のテスト用）で構成されるベンチマークです。

• タスクの多様性: 「個人用アプリ（24 件）」「ソロファウンダー向け（45 件）」「企業ツール（31 件）」の 3 つのドメインに分類され、難易度や要件（認証、決済、メール通知など）が異なります。
• 外部サービス統合: 28% のタスクで Stripe（決済）やメール（MailHog）との統合が必要であり、非同期処理や状態同期の難易度を高めています。
• 評価指標: 964 のブラウザベースのワークフロー（10,131 のサブステップ）で構成され、生成されたアプリが実際にユーザーとして操作可能かどうかが問われます。

2.2 生成環境（Generation Harness）

モデルは、OpenHands をベースに改造されたコンテナ化された環境で動作します。

• 環境: ブラウザ、ターミナル、および Supabase（DB/認証）、Stripe、MailHog へのアクセス権限を付与。
• 制約: 1 アプリあたり最大 5 時間の壁時計時間（Wall-clock time）を制限。
• 技術スタックの強制: 評価の一貫性を保つため、React + Vite（フロントエンド）、Supabase（バックエンド）、Tailwind CSS、Docker Compose によるデプロイを強制しました。
• 自己テストの強制: モデルは提出前に Docker Compose でアプリをビルド・起動し、ブラウザで動作確認を行うことをシステムプロンプトで義務付けています。

2.3 自動評価パイプライン

生成されたアプリは、自律的なブラウザエージェント（Browser Use）によって評価されます。

• 評価方法: DOM 固有のセレクタに依存せず、ユーザー視点での「クリックとナビゲーション」ワークフローを実行します。
• スコアリング: 各ワークフロー内のサブステップの 90% 以上が成功した場合に「合格」と判定されます。
• 評価者: ベンチマークの標準評価者として Claude Sonnet 4.5 を使用し、人間とのアライメント検証も行っています。

3. 主要な貢献

1. 新規ベンチマークの提案: 自然言語仕様から完全な Web アプリを生成・評価するための、ブラウザエージェントを用いた初の標準化されたデータセットとパイプライン。
2. 16 社・16 モデルの包括的評価: 最先端のクローズドソースおよびオープンウェイトモデル（GPT-5 系、Claude 系、Gemini 系など）を対象とした、コスト、レイテンシ、エラー分析を含めた大規模評価。
3. 評価者のアライメント研究: 異なるモデル間および人間との評価結果の一致度を分析し、評価者の選択が結果に与える影響を定量化しました。
4. 再現性アートの公開: 生成されたアプリの軌跡（トラジェクトリ）、仕様、評価スクリプトを公開。

4. 実験結果と分析

4.1 モデル性能

16 モデルの評価において、最高性能は GPT-5.3-Codex で、テストセットのワークフロー通過率は 61.8% でした。

• トップモデル: GPT-5.3-Codex (61.8%), Claude Opus 4.6 (57.6%) がトップを争っています。
• オープンモデル: GLM-5 や Qwen3.5 などは 15-24% 程度で、トップのクローズドモデルには大きく劣ります。
• SWE-Bench との比較: SWE-Bench ではトップとボottomの差が僅差（2.8%）ですが、VCB では 42.7% の差があり、VCB の方がモデルの能力差をより鋭く識別できることが示されました。

4.2 重要な知見

• 自己テスト（Self-Testing）の相関: モデルが生成中にブラウザを使用して自己テストを行う頻度と、最終的な精度には強い正の相関（ピアソン相関係数 $r=0.72$）があります。単にコードを編集する量ではなく、「試行錯誤と検証」のサイクルが成功の鍵です。
• エラーの分布: 失敗の多くは「機能の欠落（46.7%）」や「認証問題（20.4%）」でした。トップモデルは「完全な失敗（スコア 0）」を減らす傾向にあり、性能向上は部分的な改善よりも「動作しないアプリを作らない」ことに起因します。
• 統合の難易度: 外部サービス（Stripe やメール）の統合があるタスクでは、性能が劇的に低下します（例：GPT-5.3-Codex は統合なしで 71.3%、統合ありで 29.6%）。
• 評価者のアライメント: 評価者の選択が結果に大きく影響します。Claude Sonnet 4.5/4.6 や Gemini 3.1 Pro は人間と高い一致（86% 以上）を示しますが、GPT-5.2 は人間との一致が低く（36%）、評価者モデルの選定が重要であることを示唆しています。

5. 意義と結論

Vibe Code Bench は、「AI がコードを書けるか」という問いから、「AI がソフトウェアを構築できるか」という次の段階への移行を測る指標を提供します。

• 現状の課題: 最良のモデルでも 61.8% の成功率であり、信頼性の高いエンドツーエンド開発はまだ「フロンティア（未解決領域）」にあることが明らかになりました。
• 将来の展望: 本ベンチマークは、非技術者が自然言語でアプリを構築する未来の実現可能性を測定し、モデルの進化を追跡するための重要な基準となります。特に、モデルが「自己検証」を行う能力が、実用的な開発能力の強力な予測因子であることが示されました。

本論文は、AI によるソフトウェア開発の評価において、単なるコード生成の正解率ではなく、**「動作する製品としての完成度」**を重視する新しいパラダイムを確立した点に大きな意義があります。