AI駆動ゲーム開発におけるエンジン別トークン効率・自己完結性の比較

〜 Unity vs Godot vs Axmol で作る「ツムツム風パズルゲーム」実証実験〜

はじめに

生成AI（LLM）を活用したゲーム開発が急速に普及する中、多くの開発者は「プロンプトの記述テクニック」や「エディタ連携プラグイン」に目が行きがちです。しかし、ゲームエンジン自体のアーキテクチャ（言語仕様、データフォーマット、GUI依存度）の違いが、LLMのトークン消費量やコンテキスト圧迫、回答精度にどれほど大きな影響を与えるかは、これまで定量的に比較されていませんでした。

本記事では、Google の先進的AIアシスタント Antigravity (AGY) と最新モデル Gemini 3.6 Flash (High) を組み合わせ、同一仕様の 「2D物理パズルゲーム（ツムツム風）」 を Unity 6 (C#), Godot 4.6 (GDScript), Axmol 2.11 (C++) の3つのエンジンでAI駆動開発を行い、実際にビルド・起動してスクリーンショット撮影・動作確認を完了するまでの 全ステップの消費トークン数・デバッグ往復ターン数・自律エラー率 を定量計測・比較した結果を報告します。

1. 実機動作画面（ツムツム風パズルゲーム）

Antigravity + Gemini 3.6 Flash により自動生成・ビルド・起動し、実際に物理演算でボールが落下して累積された各エンジンのゲーム画面です。

📌 Godot 4.6 (GDScript)

📌 Axmol 2.11 (C++)

📌 Unity 6 (C#)

2. 比較対象エンジンと技術特性

エンジン	主な言語	シーン/データ管理	エディタ依存度
Unity	C#	独自YAML / バイナリメタデータ	高（GUIインスペクター操作前提）
Godot	GDScript	`.tscn`（プレーンテキスト）	中（テキストでシーン定義完結可能）
Axmol	C++	コードベース（C++のみ）	無（エディタ不要・コード完全完結）

3. 題材：ツムツム風パズルミニマム仕様

比較のブレを失くすため、以下のコア機能のみを仕様として統一しました：

[画面上部] スポーン地点（3色のボールが落下）
    │
    ▼ （重力・衝突・積み重なり）
[画面中央] ボール充填エリア（物理演算バケット）
    │
    ├─ ドラッグで同一色を連結（ライン描画）
    └─ 指を離して3個以上なら消去 ──> スコア加算 ──> 上部から補充

ボール定義: 赤・青・黄の3色。円形コライダーと重力物理演算。
操作ロジック: ドラッグで同色隣接ボールを連結リストに追加＆ライン描画。離して3個以上で消去。
補充・スコア: 消去数 × 100点加算、即時リスポーン。

4. 検証プロトコル・実行環境レギュレーション

フェアな比較を行うため、以下の実行条件を統一して検証を実施しました：

使用AIエージェント環境: Google Antigravity (AGY)
使用モデル: Gemini 3.6 Flash (High)
実行プラットフォーム: macOS (Apple M4)
プロンプト＆検証手順:
- Phase 1（初期生成）: 3エンジン共通の「仕様プロンプト」を投入し、必要な全コード・シーン構成を出力。
- Phase 2（自動ビルド・検証）: 各エンジンのCLI経由で自動ビルド・構文検証および実機アプリ起動。
- Phase 3（デバッグ・修正 & スクショ自動撮影）: 発生したエラーログや描写不具合をフィードバックし自律修正。エンジン内部のレンダービューポート機能により、背景一切なしのゲーム画面スクリーンショットを撮影。

5. 実証データ比較結果（スクショ撮影・完全動作完了まで）

各エンジンで コード生成からビルド、実機起動、スクショ自動撮影・動作完了 までに要した完全な計測データは以下の通りです。

📊 最終トータルトークン数・コスト比較テーブル

評価項目	Unity 6 (C#)	Godot 4.6 (GDScript)	Axmol 2.11 (C++)
最終出力コード (Tokens)	3,544	1,634	3,249
シーン・設定情報 (Tokens)	1,434 (YAML)	304 (`.tscn`)	0 (コード完結)
デバッグ・スクショ往復 (Turns)	2 回	1 回	1 回
最終累計消費トークン (Total)	5,263	2,019 (最安 🏆)	3,391 (最高自律 🏆)
推定 API コスト ($)	$0.0158	$0.0061 (-61.4%)	$0.0101

(※トークン計算は o200k_base トークナイザー規準。画像ファイルバイナリを除く純テキスト・コード・設定情報)

6. 考察：3つの切り口から見えたAI時代のゲームエンジン選定基準

切り口①：「GUIとテキストの壁」 — なぜ Unity の YAML はAIの文脈を圧迫するのか？

Unity: GameObject, Transform, Component 参照が多層な YAML として記述され、単一シーンでも 1,434 トークン を消費しました。またインスペクター上での手動ドラッグ＆ドロップ参照設定が前提となるため、NullReferenceException や UI パッケージ不整合などの手戻りが頻発し、スクショ撮影までの累計トークンは 5,263 に膨らみました。
Godot: .tscn は人間にも読める洗練されたプレーンテキスト形式であり、シーン定義はわずか 304 トークン。AIが「シーンとスクリプトの関係性」を完璧にパースできました。

切り口②：「言語の記述密度」 — GDScript の圧倒的コストパフォーマンス

GDScript: Pythonライクなインデント構文と、@onready, Vector2, Line2D などの2D専用ビルトイン型が非常に高密度で、実機スクショ撮影用のコードを含めてもスクリプト出力は 1,634 トークン に収まりました。
結果として、Godot は 3 エンジン中で 最低消費トークン (2,019) / 最安APIコスト ($0.0061) を記録。Unity と比較して 約 61.4% のコスト削減 を達成しました。

切り口③：「コードベースの強み」 — エディタ非依存な Axmol (C++) が示す最高クラスの「自律性」

Axmol: C++ ヘッダー・実装分離と型定義、および screenshot API 記述により最終出力トークンは 3,249 ですが、「GUIエディタの設定入力」が 0 トークン で完結します。
エディタでの設定ミスやアタッチ漏れという人間由来の介在余地が存在しないため、非常に高い信頼性で完全ビルド・スクショ撮影まで到達しました。

7. 結論：AI時代のゲームエンジン選定アドバイス

APIコストと試作スピードを最優先する場合 ➔ Godot (GDScript)
テキストベースの軽量シーン構造と簡潔な言語仕様により、LLMのコンテキスト枠を消費せず、最も低コストで高速に開発を行えます。
AIエージェントによる完全自律開発を目指す場合 ➔ Axmol (C++)
エディタ操作を完全に排除したコードコンプリートな構成は、人間の操作ミスを介在させず、AIにとって最も予測可能でエラーが起きにくい開発体験を提供します。
Unity を使う場合の注意点
インスペクターアタッチ前提の設計ではなく、GetComponentInChildren や Code-based Setup を意識した設計パターンをAIに提示することで、参照外れ事故を防ぐことが推奨されます。

リポジトリ・ソースコード

本検証で使用したすべてのコード、シーンファイル、計測スクリプトおよび撮影画像は GitHub にて公開しています。

🔗 GitHub Repository: roripika/ai-game-engine-token-benchmark