💬 NLP

GameCraft-Bench: Can Agents Build Playable Games End-to-End in a Real Game Engine?

本論文は、コーディングエージェントが完全でプレイ可能なゲームをエンドツーエンドで生成する能力を評価するために設計された、Godotベースの140のタスクからなるベンチマークであるGameCraft-Benchを紹介し、現在の最先端モデルは、認識可能なメカニクスを実装しているにもかかわらず、アーティファクトの完全性とインタラクティブな一貫性を達成することにおいて著しく苦戦することを明らかにしている。

原著者： Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan

公開日 2026-06-17

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Tongxu Luo, Rongsheng Wang, Jiaxi Bi, Chenming Xu, Zhengyang Tang, Jianlong Chen, Juhao Liang, Ke Ji, Shuqi Guo, Yuhao Du, Fan Bu, Wenyu Du, Xiaotong Zhang, Kyle Li, Shaobo Wang, Linfeng Zhang, Yuxuan Liu, Xin Lai, Chenxin Li, Yiduo Guo, Zhexin Zhang, Xinyuan Wang, Tianyi Bai, Ziniu Li, Benyou Wang

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

ロボットシェフを雇い、複雑で多皿構成のディナーのレシピを与えた場面を想像してみてください。あなたは単にロボットが紙にレシピを書き留めることではなく、実際に料理を作り、盛り付け、提供し、あなたが一口食べて味を感じられることを望んでいます。

これこそが、この論文「GameCraft-Bench」の本質です。これは、AIコーディングエージェントが、単にゲームのコードを書くだけでなく、ゼロからプレイ可能なビデオゲームを実際に「調理」できるかどうかをテストするものです。

以下は、簡単な比喩を用いたこの論文の主要なアイデアの解説です。

1. 問題点：「レシピ vs 本物の料理」

かつて、AIのコーディング能力をテストする場合、主にコードが書面上で正しく見えるか（レシピの材料が正しくリストされているかを確認するように）をチェックしていました。しかし、ビデオゲームの場合、コードが正しいだけでは不十分です。ゲームは動作し、グラフィックスが表示され、プレイヤーがキャラクターを動かして何が起こるかを確認できなければなりません。

著者らは、AIのゲーム制作能力を真にテストするためには、3つの要素が必要だと主張しています。

本物のキッチン（エンジンへの接地性/Engine Grounding）： AIは、簡略化された偽のバージョンではなく、実際のゲームエンジン（彼らは人気のある無料ツールである Godot を使用しました）の中で作業しなければなりません。これは、シェフに玩具のコンロではなく、本物のコンロを使うよう求めるようなものです。
フルコースの料理（成果物の完全性/Artifact Completeness）： AIは単一の材料（例えば、ジャンプするキャラクターのスクリプトなど）を渡すだけではいけません。起動準備が整った、パッケージ化されたゲーム全体を届けなければなりません。欠けている部分があってはいけません。
味見（インタラクティブな検証/Interactive Verification）： 完成した料理をただ眺めるだけでは不十分です。実際に食べなければなりません。ゲームは実行され、ボタンが押され、世界が正しく反応するかどうかを確認することで、AIの成功が判断されます。

2. テスト：GameCraft-Bench

研究者たちは、GameCraft-Bench という巨大なテストキッチンを構築しました。

メニュー： 彼らは、15種類のゲームタイプ（プラットフォーマー、レースゲーム、ストラテジーゲーム、ホラーゲームなど）にわたる 140種類の異なるチャレンジ を作成しました。
プロセス：
1. 自然言語による説明（例：「コインを集めて敵を避ける2Dプラットフォーマーを作って」）をAIに与えます。
2. AIはGodotエンジン内でゲームを構築します。
3. AIはまた、「デモトレース」と呼ばれる、ゲームの遊び方を正確に示すビデオスクリプトも記録しなければなりません。これは、ゲームが機能していることを証明するためのものです。
4. コンピュータシステムがそのスクリプトを使用してゲームを「プレイ」し、ビデオを記録し、その後、スマートなAI判定器がそのビデオを見てスコアを付けます。

3. 結果：「書くのは得意だが、料理は苦手」

結果は驚くべきものであり、AIコミュニティにとって少し謙虚にならざるを得ないものでした。最も高度で進んだAIモデル（Opus-4.7やGPT-5.5など）でさえ苦戦しました。

スコア： 最も優れたAIでも、テストで約 41% しか得られませんでした。ほとんどのモデルは40%を下回っていました。
得意なこと： AIは「コアループ」の構築にはそれなりに優れていました。例えば「キャラクターがジャンプする」ゲームを求めれば、キャラクターはおおむねジャンプできました。彼らはエンジンのパーツを構築することができました。
不得意なこと： 彼らは、それらすべてを組み合わせて「完全な体験」を作り上げることに苦戦しました。
- コンテンツの欠落： 彼らが作ったゲームは、あまりにも短すぎたり、進行するためのレベルが存在しなかったりすることがよくありました。
- 壊れたビジュアル： グラフィックス自体はあるかもしれませんが、意味を成していませんでした（例：プレイヤーが敵を見ることができない、あるいはUIが壊れているなど）。
- 「デモ」の乖離： 多くのAIはゲームを構築しましたが、動作を証明するために必要な「デモトレース」の記録を忘れてしまいました。これは、シェフが料理を作ったものの、判定師のために皿に盛り付けるのを忘れたようなものです。

4. 主な発見（「なぜ」か）

論文では、なぜAIが失敗したのかを掘り下げています。

見ることは信じること（Seeing is Believing）： 最も成績が良かったAIは、構築している間にゲーム画面を見ていたAIでした。彼らは視覚的な出力をデバッグツールとして扱いました。キャラクターの見た目が変であれば、コードを修正しました。画面を見ずにコードだけを書いたAIは、より多くの間違いを犯しました。
忙しさは正義ではない（Busy isn't Better）： あるAIモデル（MiMo）は、膨大な量のコードを書き、多くのコマンドを実行しましたが、それによってスコアが高くなったわけではありませんでした。それは、シェフが野菜を猛烈に刻んでいるものの、実際には料理を完成させていないようなものです。最終ステップを逃していれば、多くの作業を行うことは良い結果を保証しません。
異なるスキル： 「ジャンプ」のメカニズムを機能させること（メカニクス）は、ゲームを美しくすること（アート）や、十分なレベルを用意すること（コンテンツ）とは別物です。AIはある分野には長けていても、他の分野では不得手であることがあります。これらは互いに連結されていません。

5. 結論

この論文は、AIがコードを書くことには非常に長けてきている一方で、エンドツーエンドのゲーム制作は依然として大きな挑戦であると結論付けています。

現在のAIは、ゲームの「断片」や単純なプロトタイプを作ることはできますが、人間のクリエイティブなアイデアを受け取り、それを洗練された、プレイ可能な、完全なゲームパッケージへと確実に変換することは、まだ自力ではできません。「正しく見えるコードを書くこと」と「機能するシステムを届けること」の間には、依然として大きな隔たりがあります。

要約すると： AIはレシピを書くことはできますが、フルコースの料理を作り、顧客に提供する方法をまだ学んでいる最中なのです。

技術要約: GameCraft-Bench

問題定義

本論文は、エンドツーエンドのゲーム生成（end-to-end game generation）という課題に取り組んでいる。これは、自律的なエージェントが自然言語によるゲーム仕様（ $s$ ）を、特定の開発および実行環境（ $E$ ）内において、プレイ可能なインタラクティブなシステム（ $G$ ）へと変換するプロセスと定義される。従来のコーディングタスクでは成功がコードの正当性やユニットテストによって測定されるのに対し、ゲーム生成では、プレイヤーの入力にリアルタイムで応答する、一貫した起動可能なアーティファクトの生成が求められる。

著者らは、既存の評価手法がこのタスクの完全な複雑さを捉えきれていないと主張している。現在のベンチマークは、以下の点に焦点を当てがちである：

実際のエンジン環境の複雑さに欠ける、ウェブベースのゲーム。
完全な構築ではなく、既存プロジェクトへの局所的な編集。
コードやアセットの静的な検査。これは実際のゲームプレイの挙動を検証できない。

これに対処するため、本論文はエンドツーエンドのゲーム生成を写像 $(s, E) \mapsto G$ として定式化し、有効なベンチマークのための3つの重要な**デシデラタ（要件）**を特定している：

エンジンへのグラウンディング（接地）: 開発は、独自のドキュメント、アセット、および実行時の制約を持つ、実際のゲームエンジン内で行われなければならない。
アーティファクトの完全性: エージェントは、部分的なコードやプロトタイプではなく、メタデータ、シーン、スクリプト、アセットを含む、完全で起動可能なゲームプロジェクトを納品しなければならない。
インタラクティブな検証: 評価は、静的なコード解析ではなく、観察されたゲームプレイのインタラクション（プレイヤーの行動とシステムの応答）に基づいて行われなければならない。

手法: GameCraft-Bench

著者らは、これらのデシデラタを、Godot 4エンジンにおけるコーディングエージェントを評価するために設計されたベンチマークであるGameCraft-Benchにおいて具現化した。

1. タスクスイート

規模: 15の異なるゲームファミリー（例：プラットフォーマー、ストラテジー、ローグライク、ビジュアルノベル、タイクーン）にわたる140のタスク。
タスク構造: 各タスク $\tau = (s, E, \rho)$ $τ = (s, E, ρ)$ は以下で構成される：
- $s$ : プレイヤーのファンタジー、コアループ、およびメカニクスを記述した自然言語による仕様。
- $E$ : ワークスペース、ツールチェーン、および共有アセットを提供するGodotベースの環境。
- $\rho$ : 検証器によって使用される隠された評価ルーブリック。

2. 評価パイプライン

本ベンチマークは、5段階のパイプライン（図5）を採用している：

タスクパッケージング: エージェントは仕様と環境を受け取る。
エージェント生成: エージェントは完全なGodotプロジェクト（ $G$ ）と、タイミング付きのキーボード/マウスイベントを含む再生可能なインタラクション・トレース（ $\Pi$ ）を生成する。
ビルドゲート: 検証器はプロジェクトの起動を試みる。ビルドに失敗するか、トレースが解析不能な場合、スコアはゼロとなる。
リプレイ: 検証器はヘッドレスGodotインスタンス内でトレースを再生し、ゲームプレイ動画を記録し、フレームをサンプリングする（2 FPS）。
スコアリング: マルチモーダルなジャッジが、隠されたルーブリックに従って、以下の4つのカテゴリについてゲームプレイの証拠をスコアリングする：
- コアメカニクス (M): ルール、状態遷移、および目標。
- コンテンツの深さ (D): 進展、多様性、および実行時の範囲。
- 機能的なビジュアル (V): 視認性、フィードバック、およびUIの安定性。
- アートとプレゼンテーション (A): 美的な一貫性と「作り込まれた」感覚。
- 最終スコア公式: $Score = BUILD \times (w_M M + w_D D + w_V V + w_A A)$ 。ここで、重みはコンテンツの深さとプレゼンテーションを優先する。

3. エンジンの選択

Godotは、そのオープンソース性、軽量なセットアップ、ネイティブな2Dワークフロー、テキストベースのシーンファイル、および再現可能な自動評価に不可欠なコマンドライン/ヘッドレス実行能力により選定された。

主な結果

著者らは、7つの最先端コーディングエージェントの構成（Claude Code、Codex、Kimi Code、Code Buddyを含む）をフルベンチマークで評価した。

全体的なパフォーマンス: エンドツーエンドのゲーム生成は、依然として未解決の領域である。最も強力なエージェント（Claude Code with Opus-4.7）は、**41.46%**の総合スコアを達成した。他のほとんどのエージェントは40%を下回り、一部（例：DeepSeek-V4-Pro）は2.15%という低いスコアであった。
カテゴリ別内訳:
- メカニクス: エージェントはここで比較的良好な成績を示し（例：Opus-4.7は55.34%）、認識可能な局所的なインタラクションループを作成できた。
- コンテンツとプレゼンテーション: スコアはコンテンツの深さとアート/プレゼンテーションにおいて大幅に低下した。これは、エージェントがメカニクスを完全で洗練された一貫性のあるシステムへと組み立てることに苦慮していることを示している。
実行可能性 vs 再生可能性: 多くのエージェントが高い「ビルド通過率（Build Pass Rate）」（ゲームの起動）を達成したが、有効なリプレイ・トレースを提供できなかったり、トレース内で意図したゲームプレイを実現できなかったりすることが多く、その結果、最終スコアが低くなっている。

診断的知見

視覚的フィードバックの重要性: 描画された画面の検査（例：Kimi-K2.6）を利用したエージェントは、ソースコードだけでは見えないUIのズレやレイアウトの崩れといった問題を修正する優れたデバッグ能力を示した。
ツール利用 $\neq$ 品質: ツール呼び出し（特にシェルコマンド）の量が多いことは、必ずしもスコアの向上とは相関しなかった。成功は、ビルド、デモ・トレースの提供、およびプレイ可能性の確保の間のループを閉じることに依存していた。
部分的な因果関係: メカニクス、コンテンツ、およびビジュアルにおけるパフォーマンスの相関は中程度であった。エージェントは、メカニクスとしては機能するが、コンテンツの深みや視覚的な洗練さに欠けるゲームを生成することがあった。

意義と主張

本論文は、GameCraft-Benchが、焦点をコードの正当性からインタラクティブなシステムの正当性へとシフトさせることで、クリエイティブなソフトウェアエージェントを評価するための新しい標準を確立すると主張している。

ベンチマーク契約: これは、エージェントが実際のエンジン内で動作し、完全なアーティファクトを納品し、インタラクションを通じて判断されることを要求するベンチマーク契約を定義している。
現在の限界: 結果は、現在の最先端エージェントがゲームのようなソフトウェアの「断片」を生成することはできるものの、自然言語の仕様を完全にプレイ可能で一貫性があり、視覚的に整合したゲーム体験へと確実に変換することはまだできないことを示している。
評価パラダイム: 本研究は、クリエイティブな実行可能システムを評価するには、静的なコード検査やビルドの成功、あるいは単なる視覚的な妥当性を超えた、インタラクションに根ざした評価（プレイ可能性）が必要であると論じている。

著者らは、本ベンチマークは現在2DのGodotゲームと視覚的評価（オーディオを除く）に限定されているものの、複雑なインタラクティブシステムを構築する現在のエージェントの具体的なギャップを診断するための厳格な枠組みを提供すると強調している。