Grounding Machine Creativity in Game Design Knowledge Representations: Empirical Probing of LLM-Based Executable Synthesis of Goal Playable Patterns under Structural Constraints

この論文は、Unity 環境における構造的制約下でゴールプレイパターンに基づいた実行可能ゲームを生成する際、LLM の直接生成よりも人間が作成した中間表現（IR）を用いたパイプラインの方が、コンパイル成功率の向上や構造的な接地性の問題の軽減に有効であることを、26 種類のゴールパターンを用いた実証実験を通じて示しています。

要約

この論文は、**「AI にゲームのアイデアを、実際に動くゲーム（プログラム）に変えてもらうこと」**に挑戦した研究報告です。

まるで、**「天才的な料理のレシピ（ゲームの設計図）を、完璧な料理人（AI）に渡して、実際に美味しい料理（動くゲーム）を作ってもらおうとしたが、なぜかすべて焦げてしまった」**という物語のような内容です。

以下に、専門用語を排して、身近な例え話で解説します。

---

1. 何をやろうとしたのか？（目的）

ゲームデザイナーは「敵を倒したらポイントが貯まる」といったアイデアを思いつきます。しかし、それを実際に動くゲームにするには、膨大なコード（指示書）を書く必要があります。

研究者たちは、「最新の AI（LLM）に、このアイデアを渡せば、自動的に動くゲームを作ってくれるのではないか？」と試みました。

• 入力： 「敵を倒すとポイントがもらえるゲーム」
• 期待される出力： Unity（ゲーム作成ソフト）で実際に動くプログラム

2. 試した方法（2 つのアプローチ）

AI に指示を出す際、2 つのやり方を比較しました。

• A. 直接指示（自然言語）：
  • 「敵を倒すとポイントがもらえるゲームを作って」と、ただの文章で頼む方法。
  • 例え： 料理人に「美味しいパスタを作って」と言うだけ。
• B. 中間設計図（IR）を使う：
  • まず AI に「ゲームの部品リスト（どのオブジェクトがどこにあるか、どう動くか）」という**設計図（中間表現：IR）**を書かせて、それを元にコードを作らせる方法。
  • 例え： 料理人にまず「材料リストと手順書」を書かせて、それを見てから料理を作るように頼む方法。

3. 結果：すべて失敗しました（しかし、失敗には理由があった）

驚くべきことに、26 種類のゲームパターンすべて、AI が作ったコードは「コンパイル（完成）」に失敗しました。
つまり、**「1 個も動くゲームが作れなかった」**のです。

しかし、研究者たちは「失敗したから終わり」ではなく、**「なぜ失敗したのか？」**を徹底的に分析しました。ここがこの論文の真骨頂です。

4. 失敗の 2 つのタイプ（原因の特定）

AI の失敗は、大きく 2 つのタイプに分けられました。

① 「土台がズレている」失敗（Grounding Failures）

• 原因： AI が、**「そのゲームプロジェクトに存在しないもの」**を使おうとしたことです。
• 例え： 料理人が「このキッチンには『魔法のスパイス』がないのに、レシピにそれを使って料理を作ろうとした」状態。
  • AI は「Unity というゲームエンジン」の仕組みや、「このプロジェクトにどんな部品（Prefab）があるか」を正しく理解できていませんでした。
  • 結果： 「その部品は存在しません」というエラーが大量に出ました。

② 「書き方のミス」失敗（Hygiene Failures）

• 原因： 文法ミスや、余計な文字が入ってしまうなどの**「書き方の不手際」**です。
• 例え： 正しい材料を使おうとしたのに、「材料の名前を間違えて書いたり、句読点が抜けていたり」した状態。
  • これは AI が「何を作りたいか」は理解していても、「コードという言語のルール」を厳密に守れていない場合です。

5. 意外な発見：設計図（IR）を使うとどうなった？

「中間設計図（IR）」を使うと、①の「土台がズレる」失敗は減りました。しかし、②の「書き方のミス」が増え、さらに「料理を作るのに時間がかかりすぎて（タイムアウト）、途中で断念される」ケースが爆発的に増えました。

• なぜ？
  • 設計図（IR）を詳しく書かせると、AI が生成するコードが複雑になりすぎたのです。
  • 例え： 料理人に「詳細な手順書」を与えたら、逆に「材料を準備するだけで 3 時間かかり、火が通る前に鍋が焦げてしまった」ような状態です。

6. この研究から何がわかったか？（結論）

1. AI はまだ「ゲームの現場」に慣れていない：
   AI は一般的なプログラミングは得意でも、「特定のゲームエンジン（Unity）の細かいルール」や「そのプロジェクト固有の部品」を理解するのは苦手です。
2. 設計図（IR）は「両刃の剣」：
   設計図を使うと方向性は合いますが、逆にコードが複雑になりすぎて、AI が処理しきれなくなることがわかりました。
3. 人間と AI の役割分担が必要：
   「アイデア（何を作るか）」は人間が設計し、「細かい実装（どう作るか）」を AI に任せるには、まだ**「AI が迷子にならないための、より強力なガイド」**が必要です。

まとめ

この論文は、**「AI にゲームを作らせるのは、まだ『完璧な料理人』にはなれていない」**と結論づけています。

AI は「アイデア」を「コード」に変える能力はありますが、「そのプロジェクトのルール（土台）」を正しく理解し、かつ「複雑な指示」を処理しきれないという壁にぶつかっています。

今後は、AI が「失敗しないように」より良いガイドライン（設計図）を作ったり、AI が「文法ミス」をしないように手助けしたりする仕組みが必要だと示唆しています。

一言で言えば：

「AI にゲームを作らせようとしたら、すべて焦げてしまった。でも、なぜ焦げたのか（材料不足か、火加減ミスか）を詳しく分析したから、次はもっと上手に作れるはずだ！」

という、前向きな失敗報告でした。

技術概要

この論文「Grounding Machine Creativity in Game Design Knowledge Representations: Empirical Probing of LLM-Based Executable Synthesis of Goal Playable Patterns under Structural Constraints（ゲームデザイン知識表現における機械的創造性のグラウンディング：構造的制約下での LLM による目標実行可能パターンの実行可能合成の実証的探求）」は、大規模言語モデル（LLM）を用いて、ゲームデザインの抽象的な概念（ゴールパターン）を、Unity エンジン上で実際に動作するコード（実行可能アセット）に変換する際の課題と限界を調査したものです。

以下に、論文の技術的な要約を問題定義、手法、主要な貢献、結果、意義の観点から詳述します。

1. 問題定義 (Problem)

計算機ゲーム創造性（Computational Game Creativity）における中心的な課題は、複雑なゲームプレイのアイデアを実行可能なアーティファクト（Unity プロジェクトやコード）に変換することです。

• 実行可能性の制約: 単に意味的に正しいだけでなく、Unity エンジンの構造的・構文的要求（コンパイルエラーがないこと、アセットの依存関係が正しいことなど）を満たす必要があります。
• グラウンディングの欠如: 既存の LLM は、一般的なプログラミングコード生成では優れていますが、特定のゲームエンジン（Unity）のコンポーネントモデル、シーングラフ、MonoBehaviour ライフサイクル、およびプロジェクト固有のアセット構造に対する「グラウンディング（外部知識への接続）」が不足しています。
• スケーラビリティ: 人間による手動実装は高品質ですがスケーラビリティに欠けます。LLM を用いて設計知識を実行可能なコンテンツに変換するパイプラインが確立できれば、ゲームデザイン空間の大規模な探索が可能になります。

本研究は、構造化された中間表現（Intermediate Representation: IR）を用いて、LLM が構造的制約下で実行可能な Unity コードを生成できるかどうかを問うものです。

2. 手法 (Methodology)

研究では、26 種類の「ゴール実行可能概念（Goal Playable Concepts: GPCs）」（ゲームデザインパターンと Unity 実装のペア）を評価対象とし、以下のパイプラインを構築・比較しました。

• 評価対象モデル:
  • DeepSeek-Coder-V2-Lite-Instruct
  • Qwen2.5-Coder-7B-Instruct
  • 両モデルともコード生成に特化したオープンソースモデルです。
• 生成パイプラインの比較:
  1. ベースライン（No-schema）: 自然言語（Markdown 形式のパターン記述）から直接 C# コードを生成。
  2. IR 条件付きパイプライン: 自然言語からまず中間表現（IR）を生成し、それを C# コードに変換する 2 段階アプローチ。
     • IR の仕様 (v0.2-runtime-evidence): Unity プロジェクトの構造（Prefab、スクリプト、パラメータ）とゴールパターンの意味論をエンコードする JSON 形式。
     • 3 つの条件:
       • Free: スキーマ制約なし。
       • Min: 最小限のフィールド構造のみ。
       • Full: 完全なスキーマと 4 つのハード制約（参照整合性など）を適用。
• 評価プロトコル:
  • 生成された C# スクリプトを Unity 2022.2.23f1 のバッチモードでコンパイル。
  • 主要指標: コンパイル成功（M1 Compile Success）。
  • 失敗分析: コンパイルエラーコードを収集し、「グラウンディング失敗」と「衛生（Hygiene）失敗」に分類して分析。

3. 主要な貢献 (Key Contributions)

1. 創造的実現（Creative Realization）の枠組み: 実行可能なパターン実装を計算機創造性の問題として位置づけ、コンパイル可能な状態をアーティファクト存在の必要条件として確立しました。
2. 実行ベースの評価パイプライン: HPC 推論から Unity バッチ再生、メトリクス集計までのエンドツーエンドのワークフローを構築しました。
3. Unity 固有の中間表現（IR）: プロジェクトレベルの構造的慣習とゴールパターンの意味知識を両方エンコードする IR v0.2-runtime-evidence を提案し、3 つの条件で評価しました。
4. 構造化された失敗分類体系: 「グラウンディング失敗（知識不足によるエラー）」と「衛生失敗（構文やフォーマットのエラー）」を区別し、LLM 生成におけるボトルネックを特定しました。

4. 結果 (Results)

すべての設定（モデル、パイプライン、IR 条件）において、生成されたアーティファクトのコンパイル成功率は 0%（pass@k = 0.0）でした。 しかし、失敗の分布分析から重要な知見が得られました。

• 失敗の分類:
  • グラウンディング失敗 (Grounding Failures): 対象プロジェクトや Unity API に存在しない型、メンバ、名前空間を参照するエラー（例：CS0246 - 型が見つからない、CS0115 - 適切なメソッドではない）。これはモデルがプロジェクト固有の構造やパターン知識を正しく把握できていないことを示します。
  • 衛生失敗 (Hygiene Failures): 重複宣言、構文エラー、フォーマット漏れなど（例：CS0101, CS1029）。これは出力の整形や構文規則の遵守に関する問題です。
• IR の影響:
  • 構造的グラウンディングの改善: IR 条件付き（特に Full）では、アーキテクチャ固有の失敗（例：CS0115）がほぼ完全に排除されました。これは IR が MonoBehaviour や継承の慣習を正しく伝達したことを示します。
  • プロジェクトレベルのグラウンディングの限界: しかし、プロジェクト固有の型が見つからないエラー（CS0246）は、IR 条件付きでも依然として多く発生しました。スキーマだけではプロジェクト固有の詳細な知識を完全にカバーできていないことが示唆されます。
  • コンパイルタイムアウトの増加: IR 条件付き設定では、スキーマが詳細になるにつれてコンパイルタイムアウト率が急増しました（No-schema: 37-51% → Full: 97-99%）。これは、IR 条件付き生成が構造的に複雑なコードを生成し、Unity のコンパイル予算を消費してしまうことを示しています。
• モデル間の違い:
  • DeepSeek は重複宣言などの構造的エラーが多く、Qwen はフォーマットや型変換エラーが多かったなど、モデルごとの失敗プロファイルに差異が見られました。

5. 意義と結論 (Significance & Conclusion)

• 知見: 現在の LLM は、構造的な中間表現（IR）を用いることで、エンジンレベルのアーキテクチャ慣習（継承、コンポーネント構造）を学習・適用できる能力を持っていますが、プロジェクト固有の詳細な知識（どの Prefab がどのスクリプトに紐付いているか等）のグラウンディングには依然として大きな課題があります。
• 人間と機械の役割分担: 人間はドメイン知識と構造的スキーマを提供し、機械は生成の幅を提供するという役割分担が有効ですが、その境界はタスク全体ではなく「パターンレベル」で調整する必要がある可能性があります（一部の複雑なパターンはより高度な知識注入を必要とする）。
• 今後の方向性:
  • 失敗分類に基づき、グラウンディング失敗には RAG や PEFT による知識注入、衛生失敗には制約付きデコーディングやポストプロセッシングを適用する。
  • 構文の正しさを追求するのではなく、構造化されたコンポーネントの組み合わせ（アセンブリ）に焦点を当てた生成アプローチへの転換。
  • 単なるコンパイル成功だけでなく、ゲームプレイの意味的忠実度（Semantic Fidelity）の評価へ発展させる。

結論として、LLM によるゲームデザイン知識の実行可能合成は有望ですが、プロジェクトレベルとエンジンレベルのグラウンディングが主要なボトルネックであり、IR を介した知識注入は必須であるが十分条件ではないことが実証されました。この研究は、知識条件付き生成ゲームシステムの構造的・意味的評価の分析的基盤を提供しています。