Unity MCPでゲーム実装をほぼ100% AIに任せて分かった、UnityとPhaserの選び方

作ったもの

unity1weekのお題「しろ」に合わせて、シロクロシロディフェンスというタワーディフェンスゲームを制作しました。

• 公開ページ：シロクロシロディフェンス（unityroom）
• 制作期間：3日間
• 私が能動的に作業した時間：約4時間（概算）
• 使用環境：Unity 6.5、CoplayDevのUnity MCP、Claude Code／Cowork、Codex

ゲームの特徴は、タワーや光源が持つ「光源値」によって、敵の移動経路が変わることです。

敵には、最短経路を選ぶものだけでなく、暗い場所を好むもの、明るい場所を好むものがいます。つまり、タワー配置は攻撃力だけでなく、敵をどの道へ誘導するかにも影響します。

「ほぼ100% AI実装」の範囲

最初に、表現を明確にしておきます。

私はゲーム制作のすべてをAIへ丸投げしたわけではありません。Unity上の実装作業をほぼ100% AIへ任せました。

私は制作中、C#コードを直接編集していません。Unity Editorも直接操作していません。

一方で、何を作るか、何を採用・却下するか、遊んだときに何が分かりにくいかは人間が判断しました。この区別は重要です。

実際の制作フロー

制作は、おおむね次の流れで進みました。

1. ゲームの着想と基本方針を決める
2. Opus 5と要件定義を行う
3. 要件定義を、実装担当が単独で作業できる粒度の仕様書へ展開する
4. Sonnet 5を中心に初期実装する
5. Unity MCPを使ってScene、Prefab、Componentを構築し、Play Modeで確認する
6. 私がゲームをプレイし、問題をフィードバックする
7. Sonnet 5やTerraが改善を実装する
8. AIにGit操作を任せる
9. 私がWebGLビルドとunityroomへのアップロードを行う

上流の設計役と下流の実装役を分けたことは、ロジック実装が比較的うまく進んだ理由の一つだと考えています。

制作リポジトリには、最初の短い仕様を、A*経路探索、35 Wave、UI寸法、光源モデル、クラス設計、Prefab、テスト項目、MCPの作業手順まで含む仕様書へ拡張した履歴が残っています。

Opus 5が作ったのは「説明資料」ではなく、AI向けの実装契約だった

今回提供した仕様書の冒頭には、次の目的が明記されています。

この spec/ ディレクトリは、AIエージェントが単独でゲームを完成させられることを目的に書かれた実装仕様書である。

さらに、AIは最初に索引を読み、次に実装順序と各フェーズの終了条件を定めた11_agent_workflow.mdを読むよう指示されています。仕様にない判断が必要になった場合は、AIが勝手に決めず、人間へ確認することもルール化しました。

仕様書には、Unity 6.5（6000.5.5f1）、WebGL、960×540という環境だけでなく、20×20グリッド、上下左右4方向、A*経路探索、経路を完全に塞ぐ配置の禁止、UnityEngineに依存しないCore、乱数を使わない決定的ロジックなどの不変条件も含まれています。

最初の実装では、仕様の粒度とコミットの粒度に差があった

最初の実装でも、着手前の仕様はかなり細かく作られていました。コミット履歴では、ブレストメモ相当だった4ファイル・約140行の仕様を、AIエージェントが単独で実装できる11ファイルの仕様書へ拡張しています。そこには、A*経路探索、Wave構成、UI寸法、クラス設計だけでなく、7フェーズの作業順序とフェーズごとの完了条件も含まれていました。

一方、mainブランチの初期実装履歴を見ると、Initial commitからimplement fundermentalsまでの差分は9コミットです。特に、仕様の最終修正後から基礎実装までの3コミットの範囲で、Core・Game・UIのasmdef、経路探索、光源計算、Wave、資金、強化、敵・弾・タワーのPrefab、Title/Gameの2シーン、ScriptableObject、EditModeテストまでがまとめて追加されています。

コミット名も、initial、updated spec、implement fundermentalsのように大きな作業をまとめたものが中心でした。これは実装が無計画だったという意味ではありません。仕様書側には実装順序と検証ゲートがあり、主要ロジックとテストを短期間で一気に成立させる方針だったと読み取れます。

ただし、Git履歴だけから「どの小機能を、どの仕様に基づいて変更し、何を検証したか」を後から追うことは、rev1・rev2より難しい状態でした。この反省を踏まえるように、その後の改善ではTask番号をコミットへ対応させ、変更理由と検証結果まで残す運用へ発展しています。

改善作業も、AIが実行できるTask単位まで分解した

初期実装後の改善でも、「UIをよくする」「演出を増やす」といった抽象的な依頼を、そのまま実装担当へ渡したわけではありません。改善要求を、依存関係・完了条件・検証方法を持つTaskへ分解してから実装させました。

rev1の仕様作成コミットでは、現行コードを読んだうえで、アップグレードUIが開かない原因や、光源タワーが空撃ちする潜在不具合まで特定し、個別のTaskへ落とし込んでいます。また、「正方形の盤面を画面幅の64%にする」といった幾何学的に成立しない要求や、実測と逆だったバランス上の前提は、そのまま採用せず、検算結果と変更理由を決定事項として残しました。

rev2では、経路探索、Wave、バランス、タワーUI、UI/UX、リリース作業を別々の仕様へ分け、42個の実装Taskと51個の受け入れテストへ展開しました。元の改善チェックリスト60項目についても、どのTaskで実装し、どのテストで確認するかを追跡できる構成にしています。

さらに、feature/rev1-improvementとfeature/rev2-improvementの実装履歴では、コミット名をTask 010 カメラ/CameraFitterの更新、Task 030 命中・撃破エフェクト、Task 135 LIFE表示 5x2配置（再現不能・変更なし）のようにTask番号と対応させました。コミット本文には、変更内容だけでなく、変更理由、維持した仕様、Play ModeやEditModeテストによる検証結果まで記録しています。

この形式により、AIは巨大な改善要求を一度に処理するのではなく、一つのTaskを実装し、検証し、コミットしてから次へ進むことができます。問題を再現できなかった場合に、推測で修正せず「変更なし」と記録するTaskもありました。Git履歴そのものが、AIの作業ログと検証記録を兼ねています。

この粒度まで上流設計を固めたことが、経路探索やWave、資金、強化、勝敗判定などの主要ロジックが初回実装から成立し、その後の大規模な改善も段階的に進められた理由の一つだと考えています。

Unity MCPは何を担当したのか

使用したUnity MCPは、AIアシスタントとUnity Editorを接続し、SceneやAssetの管理、テスト、Editor操作などを行えるようにするブリッジです。[1]

ただし、今回のコード生成まで、すべてMCPツール経由で行ったわけではありません。

この経験から、Unity MCPは「AIにコードを書かせるための経路」というより、AIがUnity Editor内部の状態を変更し、検証するための接続層だと捉えています。

なお、今回の制作では、接続切れ、タイムアウト、再接続といった明確なMCP障害は発生しませんでした。後述する使用量の多さを、MCPの不安定さだけで説明することはできません。

うまくいったこと：ゲームロジック

初回実装では、次の主要機能がほぼすべて動きました。

• 光源値を考慮した経路探索
• 最短・暗所優先・明所優先の3種類の敵
• タワー攻撃
• Wave進行
• 資金システム
• タワー強化
• 勝敗判定

私の評価では、プログラム的な処理はほぼ完璧でした。最終的に、プログラム上の未解決不具合や、実装できずに諦めた機能もありません。

特に、画面の裏側で動くロジックは、一度の大きな実装依頼で成立する場面が多くありました。

これは「AIに雑な一文を渡せばゲームが完成する」という意味ではありません。AIが単独で実装・検証できるところまで、事前に仕様を具体化したことが重要でした。

苦戦したこと：UIは「動く」だけでは足りない

最も苦戦したのは、ゲームロジックではなくUIでした。

最初に生成されたUIでは、文字と文字が重なっていました。スクリーンショットを渡して「重なっているので直して」と依頼しても、十分には改善しませんでした。

そこで、

「文字Aと文字Bが重なっている」「文字Cと文字Dが重なっている」

というように、問題を一組ずつ分解して伝える必要がありました。

視認性が悪く、長時間見ると目が疲れると感じる配置もあり、改善には複数回の対話が必要でした。

さらに重要だったのは、UIの崩れだけではありません。内部ロジックが正しく動いていても、初めて遊ぶ人がゲームルールを理解できるUIにはなっていなかったのです。

たとえば、このゲームでは敵によって明暗への反応が違います。しかし、内部にその処理が実装されていることと、プレイヤーが現在の敵の性質を理解できることは別問題です。

後半のフィードバックでは、単なる配置修正よりも、ルールを伝える表示、警告、経路プレビュー、情報カードなどを重点的に改善しました。

制作リポジトリには、UIの重なりを調査し、LayoutElementの最小高さ不足などを原因として特定し、修正後にEditModeテスト165件を通したコミットも残っています。

修正前のUI

修正後のUI

この比較から分かるように、今回の問題は「コードが動かない」ことではなく、正しく計算された情報を、人間が理解できる形で提示できていないことでした。修正後は、情報同士の重なりを解消するだけでなく、プレイヤーが敵の性質やゲームの状態を把握しやすい構成へ改善しています。

3日で完成したが、AIの使用量は少なくなかった

制作期間は3日間で、私が能動的に作業した時間は概算約4時間でした。残りの多くはClaude Codeなどの長時間実行を待っていた時間です。

一方、AI側の使用量は軽くありませんでした。

• Claude Pro側で週次使用制限へ到達（制作後の体験に基づく申告）
• ChatGPT PlusのCodex側でも週次使用制限へ到達（同上）
• 2026年7月27日のスクリーンショットでは、現在のセッションが100%、週次の「すべてのモデル」が81%使用済み
• 同じ画面には、Claude Codeの週次制限が50%増量（8月19日まで）、Coworkの制限が100%増量（8月5日まで）と表示

Claudeでは、会話の長さ・複雑さ、モデル、機能などによって使用量が変わり、Claudeの各画面、Claude Code、Claude Desktopの利用は共通の利用枠へ影響します。[2]

当時のCoworkプロモーションは5時間枠を2倍にするもので、週次枠自体の2倍とは別でした。[3]

Codexも、タスクの規模・複雑さ、実行場所、長時間実行、保持するコンテキストなどによって消費量が変わります。[4]

そのため、週次枠への到達を正確なトークン数やAPI料金へ換算することはできません。

ただし、少なくとも次のことは言えます。

人間の作業時間を節約できたことと、計算資源やサブスクリプション枠を節約できたことは同義ではありませんでした。

なぜPhaserのほうがAIに扱いやすいと感じたのか

比較対象として、公開リポジトリのMaxwell's Demon Simulatorを挙げます。この作品もPhaser 3、TypeScript、Viteで制作しました。

これは、60秒間で温度の異なる22個の球を左右のチャンバーへ仕分ける、リアルタイム物理シミュレーションゲームです。通常操作に加えてOVERDRIVE、途中ミッション、スコア、仕分け率、結果グレードを備えています。

シロクロシロディフェンスと同一規模・同一仕様ではありませんが、実装内容を公開コードで確認できる比較例です。体感としては、このPhaser開発のほうがAIの使用量が少なく済みました。

理由として考えているのは、ゲームの状態や構造の多くをコードベースで表現できることです。

Phaserでは、TypeScriptを直接編集し、ブラウザで即座に確認できます。AIから見ると、コードを検索・変更すれば、プロジェクトの大部分を観測できます。

対してUnityでは、コードだけでなく、Scene、Prefab、GameObject、Component、Serialized Fieldなど、Editor側に存在する状態も扱う必要があります。Unity MCPによってAIがそれらへアクセスできるようになっても、「ファイルを編集すれば完了」という構成より観測・操作の経路は増えます。

ここから、私は次の仮説を持っています。

AIに実装を委譲する小規模2Dゲームでは、エンジンの高機能さよりも、ゲーム全体をコードとして観測・編集できることが有利になる場合がある。

ただし、これは同じゲームを同じモデルでUnityとPhaserへ実装した比較実験ではありません。異なる作品の制作経験から得た技術選択上の仮説です。「Phaserなら必ず速い・安い」と一般化するつもりはありません。

UnityとPhaserをどう選ぶか

今回の経験から、次のように考えています。

私自身、unity1weekという条件がなければ、今回のような小規模2D作品はPhaserで作っていた可能性があります。

一方で、Unity MCPが不要だという結論ではありません。3D、中規模以上、Unityのイベント、Unity資産を活用したい場面では、AIがEditor内部を操作できる価値は大きいはずです。

重要なのは、すべてのゲームを同じ技術で作ることではなく、AIへどこまで実装を委譲するかも含めて、技術を選ぶことです。

次に同じことをするなら

次に小規模な2DゲームをAI中心で制作するなら、私は最初に次の順で判断します。

1. Unity指定イベントやUnity固有機能が必要か
2. 3D、複雑な物理、Animation、Asset Store資産が必要か
3. Scene・Prefab中心の制作か、コード中心で表現できるか
4. AIに実装のどこまでを委譲するか
5. UXを誰が評価し、どの頻度でプレイテストするか

Unityを選ぶ場合でも、すべてをMCPへ通すのではなく、次の分担がよいと考えています。

• 大量のC#編集：通常のファイル編集
• Scene・Prefab・Component：Unity MCP
• 反復的な一括処理：Editor Scriptや専用ツール
• Play ModeとEditor固有状態の確認：Unity MCP
• 面白さ、分かりやすさ、視認性：人間

この事例の限界

この結果には、いくつかの限界があります。

• 1作品・1制作環境の事例である
• Unity MCPの正確なバージョンを記録できていない
• 正確な入出力トークン数、MCP Call数、API料金は復元できていない
• UnityとPhaserで同一仕様を比較したわけではない
• 「初回実装でほぼ動いた」「能動作業約4時間」は制作者による評価・概算を含む
• UIが難しかったという経験を、すべてのAI・UI実装へ一般化はできない

そのため、この記事はベンチマークではなく、公開作品とGit履歴に基づくポストモーテムとして読んでください。

まとめ

Unity MCPを使うことで、コードを書かず、Unity Editorを直接触らずに、タワーディフェンスゲームを完成・公開できました。

詳細な仕様書があれば、AIは経路探索、Wave、資金、強化、勝敗判定など、複雑なゲームロジックを高い完成度で実装できます。

しかし、完成したゲームが初見のプレイヤーに分かりやすいか、UIが目に優しいか、何を改善すべきかを判断する仕事は残りました。

そして、人間の能動作業を約4時間へ減らした代わりに、Claude ProとCodex Plusの利用枠を大きく消費しました。

AI時代の技術選定では、「人間にとって使いやすいか」だけでなく、次の問いも必要です。

この技術は、AIがプロジェクト全体を観測し、変更し、検証しやすいか。

小規模2Dで実装を大きくAIへ委譲するならPhaser。中規模以上、3D、Unity指定の環境、Editor資産が重要ならUnity＋MCP。

今回の経験から得たのは、どちらか一方が常に優れているという答えではなく、人間とAIの役割分担からゲームエンジンを選ぶという新しい判断軸でした。

参考資料

• シロクロシロディフェンス（unityroom）
• CoplayDev/unity-mcp
• Claudeの使用量と長さの制限
• Claude Cowork June 2026 usage promotion
• ChatGPTプランでCodexを使う