Unity MCP × Claude Code に 2D ゲームの弾幕処理・アスレチック生成・ダンジョン生成をさせて破綻するかどうか観察してみた

はじめに

前回の記事 では、Unity MCP と Claude Code に 3D ゲームの改造という重めのタスクを与えてみました。マテリアルの不統一やライティングの破綻など課題は多く、AI 単独での完結は難しいという結論でした。ただ、あれは 3D という負荷の高いタスクだったからこそ苦戦した面もあります。3D と比べて 2D のほうが AI にとって扱いやすいのではないかと考える読者もいるでしょう。

しかし、2D ゲームであっても現場視点では破綻しうるポイントがいくつもあります。大量のオブジェクトが飛び交う弾幕処理でパフォーマンスは持つのか、自動生成した足場にプレイヤーが到達できない場所はないか、複数の部屋が絡み合うダンジョンで詰み状態は発生しないか……。こうした問題は 2D であっても容易には解けない可能性があります。

本記事では空の 2D プロジェクトから 3 本のゲームを新規作成させ、AI がこれらの課題に対応できるかを観察しました。結論から言うと、単純なゲームは問題なく動きましたが、複雑なゲームでは「コード上は成立しているように見えるが、実際には遊べない」という特徴的な破綻が見られました。 本記事ではその過程と原因を報告します。

検証フロー

各テーマとも以下のフローで検証しました。Claude Code に実装を指示し、初回出力を人間が手動で検証します。問題があれば 1 回だけ修正指示を出し、修正後の出力を最終評価とします。

検証環境

対象読者

• Unity や Unreal Engine でゲーム開発をしている技術者
• AI コーディングツールの実力に関心がある開発者
• Claude Code や MCP を業務で使い始めている、または検討している人

参考

• Unity AI Assistant (MCP)
• Claude Code
• 前回記事: Unity MCP × Claude Code で 3D ゲームを改造する検証

Unity MCP の導入

前回記事 を参考にしてください。

テーマ 1, 2: 弾幕シューティングと自動生成アスレチック

まず比較対象として単純なテーマの結果を示します。プロンプトの全文は付録に掲載しています。

テーマ 1: 弾幕シューティング

プレイヤーがキーボードで自機を操作し、ボスの弾幕を回避する 2D シューティングゲームを作らせました。Claude Code の作業時間は約 7.5 分でした。

初回出力の時点でゲームとして成立していました。5 種の弾幕パターンが実装され、色分け・難易度の時間経過による上昇・回避可能性のいずれも問題ありませんでした。ゲームバランスも良好で、初見でも数秒から十数秒の生存が可能でした。

修正指示では、同時に画面上に存在する弾数を 500〜1,000 発規模にスケールアップし、パフォーマンスが維持できるよう必要であれば設計の見直しも行うよう指示しました。Claude Code は 1,500 発のオブジェクトプールを事前確保する方式にアーキテクチャを再設計し、物理演算も手動の距離計算に置き換えました。修正後も、エディタ上での目視確認の範囲では目立つフレーム落ちは確認されませんでした。

テーマ 2: 自動生成アスレチック

横スクロールの 2D アスレチックコースで、足場を自動生成する仕組みを作らせました。Claude Code の作業時間は約 9 分でした。

こちらも初回出力でゲームとして成立していました。目視で数回再生成した範囲では、15 個の足場がランダムに配置され、すべてジャンプで到達可能でした。ジャンプ力が高すぎて足場が視界から外れる、壁に横から接触すると張り付くなど、軽微な問題はありましたが、ゲームとしての破綻ではありません。修正指示なしで完了としました。

テーマ 3: 探索型ダンジョン

テーマ 1, 2 はいずれも初回出力でゲームとして成立しており、2D ゲーム開発の現場で実際に問題になりうる破綻ポイントを十分に探れたとは言えませんでした。本検証で特に確認したかったのは「ゲームが破綻しないか」という点です。 たとえば、複数の部屋が非線形に接続され、特定のアビリティがないと先に進めないゲートが設けられた探索型のゲームデザインでは、部屋の接続順序やアビリティの配置を少しでも間違えると簡単に詰み状態が発生します。この種の複雑さに対して Claude Code × Unity MCP がどこまで対応できるかを確かめるため、テーマ 3 を追加しました。

プロンプトと Claude Code の出力

プロンプトでは、部屋同士が通路で接続されたマップの自動生成、移動アビリティ (二段ジャンプ・ダッシュ・壁登り) の段階的な取得、敵の配置、ミニマップの表示などを指示しました。全文は付録を参照してください。

Claude Code は約 49 分で実装を完了しました。内訳は計画策定に約 18 分、実装からテストに約 31 分です。テーマ 1 の 7.5 分、テーマ 2 の 9 分と比べて大幅に長くなっています。生成されたスクリプトは 10 ファイル、約 1,700 行にのぼります。

以下のような要素が、 Claude Code によって生成されました。

• 二段ジャンプ → ダッシュ → 壁登りの順にアビリティを取得する進行設計
• アビリティの配置順序に矛盾が生じないようアルゴリズムで保証
• 3 種の敵 (巡回型・ジャンプ型・飛行型) を部屋の進行度に応じて配置
• Canvas ベースの UI でミニマップ、HP バー、操作説明を表示

特筆すべきは、Claude Code が自ら 7 回テストを実行し、5 件の問題を自力で修正した点です。 この回数はセッションログにおける Unity MCP の Play モード呼び出し回数から確認しました。

このテストと自己修正のループは Unity MCP によって成り立っています。Claude Code は Unity MCP を通じて Play モードの開始・停止、コンソールログの取得、ゲーム内オブジェクトの状態検査、スクリーンショットの取得を行いました。 たとえば「一部のエリアに部屋が割り当てられない」問題は、Unity MCP 経由で部屋の分布状況を問い合わせて発見しています。少なくとも本検証のような反復的な確認・修正サイクルは、Unity MCP に大きく依存していました。

手動検証: 初回出力は破綻していた

スタート部屋から出られませんでした。 部屋の出入口が壁の中央付近に配置されており、プレイヤーの初期ジャンプでは届かない高さにありました。二段ジャンプを取得すれば届きますが、二段ジャンプは別の部屋にあります。最初の部屋から一歩も出られないまま詰んでいました。

Claude Code は 7 回テストし 5 件の問題を自力で直していましたが、この最も基本的な問題を見落としていました。原因は Claude Code のテスト手法にあります。Claude Code はテスト中にプレイヤーを MCP 経由でワープさせて各部屋の状態を確認していました。デバッグ用の操作によって動作確認している状態に近く、実際にキーボードで操作して遊べるかどうかは試していませんでした。

修正指示と結果

修正指示として「スタート部屋から出られない。初期状態で隣の部屋に移動できるよう修正してほしい」と伝えました。Claude Code は問題を正確に特定しました。出入口が壁の中央にありジャンプで届かないことが原因だと判断し、出入口の位置を壁の中央から床面レベルに変更しました。修正箇所は 2 箇所、所要時間は 4 分でした。

修正後の検証: 遊べるようになったが、詰みパターンは残存する

出入口の問題は解消され、部屋間の移動、アビリティ取得、敵との戦闘、ゴール到達まで一通り動作するようになりました。ゲームとしては成立しています。

ただし、複数回プレイすると詰みパターンが確認されました。

詰みパターン 1: 初期部屋の障害物

初期スポーン地点に背の高い障害物が生成されると、二段ジャンプがないため越えられません。二段ジャンプは別の部屋に行かないと手に入りません。出入口は通れるのに、部屋の中で行き止まりになります。

詰みパターン 2: 上にしか道がない部屋

部屋によっては、他の部屋への通路が上方向にしかありません。二段ジャンプを持っていない状態でその部屋に落ちてしまうと戻れず、閉じ込められます。初期スポーン部屋がこの部屋になるパターンもありました。

Claude Code は「どの部屋にどのアビリティを置くか」という配置の整合性は保証していました。しかし 「いまの能力でこの部屋を実際に通り抜けられるか」という操作レベルの検証が欠けていました。

また、その他の残存問題として、HP バーの長さがダメージを受けても変わらない不具合 (ただし色は意図通り赤く変化する)、壁に横から接触すると張り付く問題 (テーマ 2 と同じ)、丸い形の敵がアビリティアイテムと見た目が似ている問題が確認されました。

考察

テーマ横断比較

3 テーマの結果を並べると、タスクの複雑さと出力の品質の関係が見えてきます。

単純なタスクでは初回出力で実用レベルに達します。一方、タスクが複雑になると破綻が生じます。修正指示を重ねることである程度の復旧は可能であると考えられます。

テーマ 3 において、Claude Code が自ら 7 回テストし 5 件を修正する自己修正ループが発生した点は注目に値します。テーマ 1, 2 では初回出力で動作していたため、タスクの難度に応じてテスト回数が増えたものと観測されます。

設計図は正しいが、遊べない

テーマ 3 で Claude Code が作ったダンジョンの設計ロジック自体はよくできていました。アビリティの配置順序に矛盾が生じないようアルゴリズムで保証し、データとしての整合性は取れていました。しかし実際に操作して遊んでみると詰みが発生しました。

原因は 「データの正しさ」と「体験の正しさ」のギャップにあると考えます。 Claude Code はダンジョンの設計図としては正しいものを作りました。しかし、その設計図の上で人間がキャラクターを動かしたときにどうなるかまでは検証していません。Claude Code のテスト手法がこのギャップを端的に示しています。Claude Code はテスト時にプレイヤーをワープさせてゲーム状態を検査していました。 これはデバッグコンソールによる動作確認であり、コントローラーを握って遊ぶテストではありません。ゲームのデータが正しく動いているかは確認できますが、そのゲームが遊べるかどうかは確認できません。

どうすれば防げるか

この問題に対処するには、いくつかの方法が考えられます。

1. プロンプトで指示する
   「出入口の高さがジャンプで届く範囲にあるか確認せよ」のように、チェック観点を人間が明示します。手軽ですが、問題を事前に予測できなければ意味がありません。
2. 数値チェックを組み込ませる
   出入口の高さとジャンプ力を比較するロジックを生成コードに含めさせます。出入口の問題はこれだけで防げました。ただし、詰みパターン 1, 2 のような部屋内レイアウトの問題にはもう少し高度な経路探索が必要です。
3. AI に実際にプレイさせる
   自走プレイヤーとしてステージを走らせ、到達可能性を網羅的に検証します。最も確実ですが、現時点では実現コストが高いです。

今回の検証で見えたのは、2 の段階ですら AI は自発的に行ってくれないということです。出入口の高さとジャンプ力の比較は単純な算数ですが、AI はそのチェックが必要と気づきませんでした。現時点では、人間がプロンプトやツールの設計で「実際に遊べるかどうか」という観点を補う必要があります。

まとめ

3 テーマの検証を通じて見えた結論は以下の 3 点です。

• 単純なタスクは初回出力で実用レベルに達する
  弾幕シューティングとアスレチックはいずれも初回で動作し、修正指示への対応も的確でした。
• 複雑なタスクでは初回出力に破綻が生じる
  修正指示により最低限のゲーム進行は可能になりましたが、詰みパターンは残存しました。AI も自らテスト回数を増やして対処しようとしますが、テスト手法の限界から重大な問題を見落とすことがあります。
• AI は設計図としては正しいものを作れるが、遊べるかどうかの検証はまだ人間の仕事
  データの整合性と実際の操作体験の間にはギャップがあり、現時点ではこのギャップを埋めるのは人間の役割です。

付録: プロンプト全文

このプロジェクトには Unity MCP が導入されています。Unity MCP を通じて Unity Editor を操作しながら、2D 弾幕シューティングゲームを作成してください。

### ゲーム内容

- プレイヤーはキーボードで自機を操作し、敵の弾幕を回避する
- 画面上部にボス敵が 1 体おり、複数の弾幕パターンで攻撃してくる
- 弾幕パターンは少なくとも 3 種類用意し、時間経過で切り替わるようにする
- プレイヤーが被弾したらゲームオーバーとし、リトライできるようにする
- 生存時間をスコアとして表示する

### 弾幕の要件

- 弾幕ゲームとして成立する密度であること。弾が少なすぎて回避が trivial にならないようにする
- 一方で、初見でも数秒〜十数秒は生存できる程度の難易度に調整する
- ボスは時間経過で弾幕パターンを切り替え、後半ほど難しくなるようにする

### 制約

- 外部アセットは使用しない。図形やシンプルなスプライトで構成する
- Play ボタンを押したら即座に遊べる状態にすること

弾幕の密度が物足りないです。同時に画面上に存在する弾数が 500〜1,000 発規模になるようにスケールアップしてください。パフォーマンスが維持できるよう、必要であれば設計の見直しも行ってください。

このプロジェクトには Unity MCP が導入されています。Unity MCP を通じて Unity Editor を操作しながら、2D プラットフォーマーのステージ自動生成システムを作成してください。

### ゲーム内容

- 横スクロール型の 2D プラットフォーマーとする
- プレイヤーはキーボードで移動・ジャンプを操作する
- ステージはプレイ開始時に自動生成される
- スタート地点からゴール地点まで到達するとクリアとする

### 自動生成の要件

- プレイヤーがスタートからゴールまで到達可能であることを保証すること
- 足場の配置がランダムでも、ジャンプで届かない距離に足場が置かれるような理不尽が発生しないこと
- ステージを再生成するたびに異なるレイアウトが生成されること
- 落下したらミスとし、リトライできるようにすること

### 制約

- 外部アセットは使用しない。図形やシンプルなスプライトで構成する
- Play ボタンを押したら即座に遊べる状態にすること

このプロジェクトには Unity MCP が導入されています。Unity MCP を通じて Unity Editor を操作しながら、2D 探索アクションのマップ自動生成システムを作成してください。

### ゲーム内容

- サイドビューの 2D アクションとする
- プレイヤーはキーボードで移動・ジャンプ・攻撃を操作する
- プレイヤーには HP があり、敵の攻撃を受けるとダメージを受ける。HP がゼロになるとゲームオーバーとする
- マップは複数の部屋で構成され、プレイ開始時に自動生成される
- 部屋同士は通路で接続され、一方通行ではなく自由に行き来できる
- 部屋には敵が配置される。敵は部屋ごとに異なる種類や配置とする
- 探索を進めると移動アビリティ (二段ジャンプ、ダッシュ、壁登りなど) を取得できる。取得したアビリティによって、それまで通れなかった地形や障害を突破し、新たなエリアへ進めるようにする
- すべてのアビリティを集め、最奥の部屋に到達するとクリアとする
- 画面上にミニマップを表示し、探索済みの部屋と現在位置がわかるようにする

### 自動生成の要件

- マップ全体が到達可能であることを保証すること。手詰まり (必要なアビリティが取得不能な状態) が発生してはならない
- アビリティの配置順序が論理的に正しいこと。たとえば、二段ジャンプがないと到達できない部屋に二段ジャンプが置かれるような矛盾がないこと
- 部屋の数は 8 以上とし、生成するたびに異なるマップが生成されること
- 部屋のレイアウトや接続にバリエーションがあること

### 制約

- 外部アセットは使用しない。図形やシンプルなスプライトで構成する
- Play ボタンを押したら即座に遊べる状態にすること

スタート部屋から出ることができません。初期のジャンプ力では最初の足場に届かず、部屋間を移動できないためゲームが詰んでいます。プレイヤーが初期状態のアビリティだけでスタート部屋から隣接する部屋へ移動できるよう修正してください。