AIゲーム開発研究室

「森のどんぐり大作戦」開発ドキュメント

基本ゲームループ完成 ― Unity AI Agent、残り25クレジットでゲームを閉じる

前回までの実装によって、

パンタ開始 → どんぐりをキャッチ → 大喜び → 退場 → ポン登場 → どんぐりをキャッチ → 大喜び

までが完成しました。

ゲームとして残されていたのは、その先です。

ポンが大喜びしたあと、どうなるのか。

ここまでどれだけ正常に動作しても、最後がなければゲームは終わりません。

そこで今回は、

「ポン大喜び → 退場 → ゲーム終了」

を実装し、「森のどんぐり大作戦」の基本ゲーム構造を最後までつなげることにしました。

ただし、一つ問題があります。

Unity AI Agentの残りクレジットは、

114 / 1,000

です。

かなり心細い数字になってきました。

今回は余計な実験をせず、既存システムをできるだけ利用して、ゲームを最後まで完成させることを優先します。

---

1．今回の目的

今回実装するゲーム終了までの流れは単純です。

ポンがどんぐりを3個キャッチする。

↓

ポンが大喜びする。

↓

しばらく大喜びを続ける。

↓

大喜びアニメーションを続けたまま、真下へ下降する。

↓

ポンが完全に画面外へ退場する。

↓

どんぐりの新規生成を停止する。

↓

「ゲームクリア！」

を表示する。

今回はゲーム終了後のメニュー画面、リスタート、結果画面などは作りません。

目的は、

ゲーム開始からゲーム終了までの基本構造を成立させること

です。

---

2．新しい仕組みを作らせない

Unity AI Agentへの指示では、今回も実装範囲を明確にしました。

特に重要視したのが、

既存のパンタ退場処理を調査し、その設計を参考にする

ことです。

パンタではすでに、

大喜び → 一定時間待機 → 大喜びしながら下降 → 完全に画面外へ退場

という処理が正常に動いています。

したがって、ポンのために別の複雑なシステムを新しく作る必要はありません。

また、前回修正したポンのアニメーション素材についても、

共通キャンバス

共通Sprite Rect

共通Pivot

を変更しないよう明示しました。

ポンの大喜びには、人間が生成画像を選別し、同一サイズの透明キャンバス内でキャラクター位置を調整することによって制作した上下動が、すでに含まれています。

したがって、Unity側で新たな上下ジャンプを加える必要はありません。

退場時に必要なのは、

GameObject全体をTransform Yで真下へ移動させること

だけです。

ここでも、

Sprite画像内で制作された動き

と、

Unityが担当するゲーム空間上の移動

を分離します。

---

3．ゲーム終了時の仕様

ポンが大喜びを開始すると、すでにBasketCatchAreaのColliderは無効になるよう実装されています。

そのため、退場中にどんぐりをキャッチすることはありません。

スコアは、

どんぐり：3 / 3
合計：6

の状態で止まります。

ポンが完全に画面外へ出たら、AcornSpawnerによる新しいどんぐりの生成を停止します。

その時点をゲーム終了としました。

そして既存のUIを利用して、画面中央付近へ、

「ゲームクリア！」

を表示します。

これだけです。

豪華なResult画面はありません。

しかし、今回必要なのは完成したゲーム画面ではなく、

ゲームというシステムが最後まで動作すること

です。

---

4．Unity AI Agentへ実装を依頼する

以上の条件をまとめ、Unity AI Agentへ実装を依頼しました。

今回の指示では、

• 既存実装を最初に確認する
• PantaMovementの退場処理を参考にする
• PonMovementへ必要最小限の処理を追加する
• ポンの既存アニメーションを変更しない
• Sprite Import設定を変更しない
• BasketCatchAreaの既存処理を維持する
• ポン退場後にAcornSpawnerを停止する
• 既存Canvasを利用して「ゲームクリア！」を表示する
• Scene遷移やリスタートなどは実装しない
• 不要なリファクタリングを行わない

ことを指定しました。

残りクレジットが少ないため、今回は特に、

必要のない仕事をAIにさせない

ことを重視しました。

---

5．突然のクレジット切れ

Unity AI Agentが作業を開始しました。

既存SceneやGameObject、Scriptを調査しながら、次々と処理を進めていきます。

そして画面には、

Completed actions (46)

と表示されました。

かなり多くの処理が行われています。

ところが、その直後です。

Unity Assistantの画面に赤い警告が表示されました。

Not enough credits remaining.

クレジットが足りません。

作業開始前には114あったクレジットが、実装途中でほぼ尽きてしまったのです。

しかもUnity AI Agentから、

「実装が完了しました」

という最終報告を受け取る前です。

これは困りました。

実装途中で止まったのであれば、ゲーム終了処理のどこまで完成しているのか分かりません。

しかし、画面を見るとUnity AI Agentは46個もの処理をすでに完了しています。

さらに作業内容には、

gameClearVisible

gameClearText

ponCurrentScore

totalScore

など、ゲーム終了状態を確認していたと思われる項目も見えます。

もしかすると、

実装そのものは終わっていて、最後の報告を行う前にクレジットが尽きただけなのではないか。

そこで追加の質問は行いませんでした。

残り少ないクレジットを使ってUnity AI Agentに状況確認をさせるのではなく、

人間がPlayして確認します。

---

6．Playボタンを押す

ゲームを最初から実行します。

パンタが登場します。

どんぐりを3個キャッチ。

どんぐり：3 / 3

パンタが大喜びします。

そのまま画面下へ退場。

同時にポンが画面下から登場します。

ポンが通常位置へ到着するとCurrent Scoreがリセットされます。

どんぐり：0 / 3
合計：3

ここまでは前回までに完成していた部分です。

続いてポンを操作します。

1個。

2個。

3個。

どんぐり：3 / 3
合計：6

ポンが大喜びを始めます。

そして――

そのまま大喜びしながら、画面下へ下降を始めました。

ポンは完全に画面外へ退場します。

新しいどんぐりも出現しなくなりました。

そして画面中央に、

ゲームクリア！

と表示されました。

全部できています。

---

7．Unity AI Agentは仕事を終えていた

結果として、

ポン大喜び

↓

下降開始

↓

完全退場

↓

どんぐり生成停止

↓

ゲームクリア表示

のすべてが正常に動作しました。

Unity AI Agentは、

「クレジット不足」

というエラーを表示して停止しました。

しかし、Unityプロジェクト側では要求した機能がすでに完成していました。

つまり今回、

AIとの対話上ではタスク完了報告まで到達していない

一方で、

実際のゲーム実装は完成している

という状態が発生しました。

ここにも一つ興味深い点があります。

AIの画面上に、

「完了しました」

と表示されたかどうかと、

実際の制作物が完成しているかどうか

は同じではありません。

最終的な判断対象は、AIの返答ではなく、

実際に動いているゲームそのもの

です。

---

8．残り25クレジット

実装後、Unity Cloudのクレジット管理画面を確認しました。

残っていたのは、

25 / 1,000クレジット

でした。

今回の実装開始時には114クレジットでした。

したがって今回使用したのは、

89クレジット

です。

Unity AI Agentは残りわずかなクレジットを使いながら、ゲーム終了までの処理を完成させてくれました。

最後の報告をする余力は残っていませんでしたが、ゲームそのものは完成していました。

そこでプロジェクトをしっかり保存し、

Unity AI Agentにはしばらく休暇を出すことにしました。

---

9．ゲームの基本構造が閉じた

今回の実装によって、「森のどんぐり大作戦」は次のようになりました。

ゲーム開始

↓

パンタ登場

↓

パンタを操作

↓

どんぐりを3個キャッチ

↓

パンタ大喜び

↓

パンタ退場

↓

ポン登場

↓

Current Scoreリセット

↓

ポンを操作

↓

どんぐりを3個キャッチ

↓

ポン大喜び

↓

ポン退場

↓

どんぐり生成停止

↓

ゲームクリア

これで、

開始から終了までゲームが一本につながりました。

もちろん、まだ完成版のゲームではありません。

キャラクターはパンタとポンしか実装されていません。

本来はコンタ、リン、ミミも登場します。

パンタのアクション素材も、今後5カット構成へ作り直す予定です。

UI、ゲームバランス、演出、Result画面なども、これから改良していくことになります。

しかし、それらは今後、

すでに成立したゲーム構造へ追加していく要素

になります。

これは大きな違いです。

---

10．人間とAIは何をしてゲームを作ったのか

ここまでの実制作を振り返ると、ゲームは一つのAIが自動的に作ったものではありません。

人間がゲームの方向を決めました。

ChatGPTとの対話によって仕様や実装方法を検討しました。

画像生成AIがキャラクターやアクション候補を生成しました。

人間が画像を選別し、必要に応じて同一キャンバス内で配置を調整し、ゲーム用アニメーション素材を制作しました。

Unity AI AgentがUnityプロジェクトを調査し、Script、Animator、Collider、UIなどを実装しました。

そして人間がPlayボタンを押しました。

動かなければ原因を探します。

違和感があれば、その理由を考えます。

AIへ調査を依頼します。

修正後、再びPlayします。

その繰り返しによって、ゲームが少しずつ成立していきました。

ここで起きていることは、

人間 → AI → 完成

という単純な工程ではありません。

設計 → 制作 → 実装 → 検証 → 発見 → 修正 → 再検証

という循環です。

そして、その各段階で人間と複数のAIが異なる役割を担っています。

---

11．「ゲームを作る」から「ゲームを育てる」へ

今回、最も重要なのは「ゲームクリア！」という文字が表示されたことではありません。

ゲームの基本構造が、

閉じた

ことです。

これまでは、常にゲームの先に未実装部分がありました。

パンタを動かせても、その先がない。

どんぐりをキャッチできても、交代できない。

交代できても、ポンが遊べない。

ポンが遊べても、ゲームが終わらない。

その一つ一つを実制作によって解決してきました。

そして今回、初めて最後まで到達しました。

ここから先は、

ゲームを成立させるための開発

から、

成立したゲームを育てていく開発

へ移ることができます。

キャラクターを増やす。

キャラクターごとの動きを作る。

難易度を調整する。

演出を加える。

UIを整える。

ゲーム世界を広げる。

さらに次のゲームへつなげる。

基本構造が存在することで、これらの作業はすべて同じ土台の上で行えるようになります。

---

今回の到達点

「森のどんぐり大作戦」の実制作を始めてから、画像生成AIによる素材制作、Unityへの配置、キャラクター移動、どんぐり落下、キャッチ判定、スコア、キャラクター交代、大喜び、退場など、一つずつ実装を積み重ねてきました。

そして今回、

ゲーム開始からゲーム終了までの基本ゲームループが完成しました。

Unity AI Agentの画面には、

Not enough credits remaining.

そしてUnity Cloudには、

残り25クレジット。

一方、UnityのGameビューには、

「ゲームクリア！」

と表示されています。

AIは最後の報告をする前に力尽きました。

しかし、ゲームは最後まで動いていました。

今回はここでUnityプロジェクトを保存します。

Unity AI Agentには休暇を取ってもらいます。

そして私たちは、ここまでの実制作によって何が分かったのかを整理し、再び研究へ戻ります。

論文からゲームを作るだけではありません。

ゲームを作ることで、論文もまた作られていきます。

 

「森のどんぐり大作戦」の基本構造は、これで完成です。

AIゲーム開発研究室

「森のどんぐり大作戦」開発ドキュメント

ポン実装編 ― AIが生成した「動き」はどこに記録されていたのか

前回までの実装によって、パンタがどんぐりを3個キャッチすると大喜びし、そのまま画面下へ退場し、次のキャラクターであるポンが登場するところまで完成しました。

今回は、その続きとしてポンのゲームシステムを実装していきます。

目標は、

ポンがどんぐりをキャッチする

↓

キャラクターごとの取得数とゲーム全体の取得数を表示する

↓

3個キャッチすると操作を停止する

↓

ポンが大喜びする

というところまでです。

ところが今回、実装を進める中で予想していなかった重要な問題が見つかりました。

それは、画像生成AIによって制作されたアニメーション素材の「動き」の一部が、Unityへ読み込む過程で失われていたという問題です。

---

1．キャラクターごとの取得数と合計取得数

まず、スコア表示を整理しました。

これまでは単純に取得したどんぐりの数を表示していましたが、キャラクター交代を実装したことで、二種類の数字が必要になりました。

Current Score

現在操作しているキャラクターが取得したどんぐり数。

Total Score

ゲーム開始から全キャラクターが取得したどんぐりの累計数。

パンタが3個取得した場合、

どんぐり：3 / 3
合計：3

となります。

その後パンタが退場し、ポンの登場が完了した時点でCurrent Scoreだけをリセットします。

どんぐり：0 / 3
合計：3

そしてポンが1個取得すると、

どんぐり：1 / 3
合計：4

となります。

Unity AI Agentは既存のScoreManagerを拡張し、Current ScoreとTotal Scoreを同時に管理する構造を実装しました。

重要なのは、キャラクター交代の途中ではCurrent Scoreをリセットせず、ポンが通常プレイ位置へ到着した時点でリセットするようにしたことです。

これによって、パンタの退場中やポンの登場途中でスコア表示が不自然に切り替わることを防いでいます。

---

2．ポンにもどんぐりキャッチを実装する

次に、ポンがどんぐりをキャッチできるようにします。

パンタにはすでに、

BasketCatchArea

というどんぐりを受け取るための当たり判定が実装されています。

Unity AI Agentに既存システムを調査させたところ、この仕組みはパンタ専用に作り直す必要がなく、そのままポンにも利用できることが分かりました。

そこで新しいキャッチ用スクリプトを作るのではなく、既存のBasketCatchAreaをポンにも使用しました。

ただし、パンタとポンでは体形も籠の位置も異なります。

そのため、ポン用にColliderの位置だけを調整しました。

これによって、

共通のキャッチシステム

と

キャラクター固有の位置設定

を分離することができました。

実際にPlayモードで確認すると、ポンも正常にどんぐりをキャッチし、

1個目では、

どんぐり：1 / 3
合計：4

2個目では、

どんぐり：2 / 3
合計：5

3個目では、

どんぐり：3 / 3
合計：6

と正しく表示されました。

---

3．ポンの大喜びは、人間が構成する

パンタの大喜びアニメーションでは、少し変わった実験を行いました。

画像生成AIによって制作された7枚の独立した大喜びポーズをUnity AI Agentに見せ、

どの画像を使うか

どの順番にするか

どのタイミングで表示するか

をUnity AI Agent自身に判断させました。

その結果、Unity AI Agentは、

05 → 02 → 04 → 01 → 06 → 03 → 07

という、人間が事前に指定していない順序を構成しました。

Playモードで確認すると、これが予想以上に自然な大喜びアニメーションになりました。

今回は比較のため、ポンでは別の方法を試します。

画像生成AIが制作した8枚の大喜び候補から、人間が5枚を選択しました。

さらに、

01 → 02 → 03 → 04 → 05

という使用順序も人間が決定しました。

一方、各画像をどれくらいの時間表示するかについてはUnity AI Agentに任せました。

つまりパンタでは、

AIがポーズ選択・順序・時間を決定

したのに対して、ポンでは、

人間がポーズ選択・順序を決定し、AIが時間と実装を担当

します。

同じ大喜びアニメーションでも、人間とAIの役割分担を変えてみたわけです。

---

4．Unity AI Agentが決めたポンの時間

Unity AI Agentは、5枚を確認したうえで、

6fps

を採用しました。

各画像の表示時間は約0.167秒。

全体では約0.833秒です。

順序は指定通り、

01 → 02 → 03 → 04 → 05

です。

Unity AI Agentが6fpsを選択した理由は、既存のポンの待機・移動アニメーション、さらにパンタの大喜びアニメーションも6fpsで構成されており、ゲーム全体のテンポと統一できるためでした。

ここでは、人間がポーズの構成を決め、AIが既存ゲームの実装を参照しながら時間軸へ変換しています。

---

5．Playボタンを押して分かった二つの問題

Unity AI Agentからは、

「正常に実装完了」

という報告が返ってきました。

しかし、ここでいつものように人間がPlayボタンを押します。

すると二つの問題が見つかりました。

一つ目は、

大喜びになっても、どんぐりをキャッチし続ける

という問題です。

見た目は大喜び状態へ変わっていますが、BasketCatchAreaのColliderは動作したままでした。

そのため大喜びしているポンの近くをどんぐりが通ると、Current ScoreもTotal Scoreも増えてしまいます。

そこでCelebration開始と同時に、ポンのBasketCatchAreaのColliderだけを無効化するよう修正しました。

共通で使用しているBasketCatchArea.csそのものは変更していません。

これによってパンタには影響を与えず、ポンだけが大喜び開始後にキャッチできなくなりました。

ここでも、

見た目の状態が変わったことと、ゲーム内部の状態が変わったことは同じではない

ということが分かります。

---

6．もう一つの違和感

しかし、もう一つ気になることがありました。

ポンの大喜び素材は、制作した段階ではかなり大きく上下するアクションになっていました。

ところがUnity上では、

思ったほど上下していない。

最初はUnity側でTransformのY座標を動かす必要があるのではないかとも考えました。

しかし、そうではありません。

元画像を思い出すと、すでに画像そのものの中でポンの位置を上下させていました。

つまり5枚を同じ位置で切り替えるだけで、本来ならポンは上下して見えるはずなのです。

では、なぜ動かなかったのでしょうか。

---

7．消えていた「透明な運動情報」

Unity AI Agentに画像のImport状態を調査させました。

そこで原因が判明しました。

ポンの大喜び素材はすべて、

320×400

という同じサイズの透明キャンバス上に制作されていました。

そして、そのキャンバスの中でポンの位置そのものを上下させています。

ところがUnityへImportした際、キャラクターが描かれている部分だけが画像ごとに自動的にトリミングされていました。

さらに、切り取られたそれぞれのSpriteの中央がPivotになっていました。

つまり、

元画像ではポンが上にいる

↓

ポンの周囲だけ切り取る

↓

切り取った画像の中央をPivotにする

↓

Unity上では再び中央に表示される

ということが起きていました。

画像生成AIが作った上下位置の差が、UnityへのImportによって相殺されていたのです。

---

8．透明キャンバス全体をSpriteとして扱う

そこで大喜び素材5枚を、

Rect：320×400のキャンバス全体

Pivot：すべてCenter（0.5, 0.5）

に統一しました。

Transformによる上下移動は一切追加していません。

GameObjectそのものは同じ位置に置いたままです。

変えたのはSpriteのImport方法だけです。

Playボタンを押してみます。

すると――

ポンがめちゃくちゃ大喜びしました。

素材画像の中に最初から存在していた上下動が、そのままゲーム画面に現れたのです。

---

9．「いまいち飛んでいない」の正体

ここで、以前から感じていた別の違和感にも気づきました。

ポンの通常キャッチアクションです。

ポンのキャッチ素材も画像生成時には上下に跳ねるようなポーズとして制作していました。

しかしゲーム上では、

「いまいち飛んでいないな」

という印象がありました。

そこで、

Pon_Catch_Up

と

Pon_Catch_Right

についても同じ問題が起きていないか調査しました。

結果は同じでした。

---

10．Pon_Catch_Upでも運動情報が消えていた

Pon_Catch_Upの5枚は、すべて、

340×400

のキャンバスです。

しかし修正前には、それぞれ異なるSprite Rectでトリミングされていました。

特に上下位置を見ると、

01は y=0、

02は y=74、

03は y=82、

04は y=40、

05は y=0

からキャラクター部分が切り出されていました。

これは非常に分かりやすい結果です。

元画像では02、03でポンが明らかに上へ移動しています。

ところが、その位置からキャラクターだけを切り出して中央をPivotにしたため、Unity上ではその高さの違いが消えていました。

そこで5枚すべてを、

Rect：340×400

Pivot：Center（0.5, 0.5）

へ統一しました。

Transformによる上下移動は追加していません。

---

11．右移動でも同じことが起きていた

Pon_Catch_Rightでも同様でした。

こちらの5枚は、

400×400

です。

やはり各画像が個別にトリミングされており、03ではy=38、04ではy=31から切り取られていました。

これも、

Rect：400×400

Pivot：Center（0.5, 0.5）

へ統一しました。

右移動の場合は少し構造が違います。

上下方向のアクションはSprite画像そのものが担当します。

一方、画面右方向への移動はUnityのTransformが担当します。

つまり、

Sprite画像内の上下運動

＋

UnityによるX方向移動

によって、一つの右移動アクションが成立しています。

左移動では、このアニメーションをflipXによって反転しています。

---

12．動きにリズムが生まれた

修正後、再びPlayボタンを押しました。

今度は明らかに違いました。

停止中のキャッチでも、左右移動中のキャッチでも、ポンが上下に跳ねます。

これまで少し平坦に見えていた動きに、はっきりとしたリズムが生まれました。

しかもUnity側で新しいジャンプ処理を追加したわけではありません。

今回の修正では、

Scriptの変更はありませんでした。

画像生成AIが制作した素材には、最初からその動きが存在していたのです。

Unityへ受け渡す過程で、それが見えなくなっていただけでした。

---

13．透明部分は「何もない」のか

今回の実験から、非常に興味深いことが分かりました。

一般に透明PNGの透明部分は、

「何も描かれていない部分」

と考えがちです。

しかし、今回のアニメーション素材では違いました。

透明キャンバスの中で、

キャラクターがどこに存在しているか

その位置自体が、フレーム間の運動を表現していました。

つまり透明部分は、単なる余白ではありません。

キャラクターの空間的位置を記録するための座標空間

として機能していたのです。

したがって今回の素材では、

透明キャンバスそのものがアニメーション情報の一部

だったことになります。

---

14．AIからAIへ渡す途中で情報が失われる

今回の問題は、画像生成AIが正しく素材を作れなかったことが原因ではありません。

Unity AI Agentがアニメーションを作れなかったことが原因でもありません。

画像生成AIが作った素材には、すでに必要な上下動が存在していました。

問題が発生したのは、

画像生成AIによる素材制作

↓

PNG

↓

Unity Import

↓

Animation Clip

という工程の途中です。

生成物そのものでも、実装コードでもなく、

制作工程間の情報変換によって情報が失われていた

のです。

AI時代のゲーム開発では、複数のAIやソフトウェアを連携させることになります。

そのとき重要なのは、

それぞれのAIが正しく仕事をしたか

だけではありません。

一つの工程で作られた情報が、次の工程へ正しく受け渡されたか

を確認する必要があります。

---

15．人間が見つけたもの

Unity AI Agentは、それぞれの作業について実装完了を報告しました。

しかし、

「ポンがいまいち飛んでいない」

という違和感を感じたのは、人間でした。

大喜びアニメーションをPlayして、その違いがさらに明確になりました。

そこから原因を疑い、Unity AI Agentに調査させたことで、Import設定の問題が発見されました。

今回も、

AIが実装する

↓

人間がPlayする

↓

人間が違和感を発見する

↓

AIが原因を調査する

↓

AIが修正する

↓

人間が再びPlayして評価する

という循環が発生しています。

これはこれまで繰り返し現れてきた、

設計 → 制作 → 実装 → 検証 → 発見 → 再設計

というAIゲーム開発の循環そのものです。

---

16．今回得られた制作ルール

今回の実験から、今後の2Dアニメーション素材制作に使える重要なルールが得られました。

連続アクション用Spriteでは、透明キャンバス内におけるキャラクターの位置も運動情報の一部として扱う。

画像生成AIによって同一キャンバス内でキャラクターの上下位置を変化させている場合、Unity Import時に各フレームをキャラクター輪郭で個別にトリミングしてはなりません。

同一アクションを構成するSpriteは、

共通キャンバス

共通Sprite Rect

共通Pivot

を維持します。

そして、画像内ですでに上下動が設計されている場合には、Unity側でさらにTransform Yを動かす必要はありません。

一方、画面内を左右へ移動するようなゲーム上の移動についてはUnity側で制御します。

つまり、

素材が担当する動き

と

ゲームエンジンが担当する動き

を分離します。

---

17．ポンらしい動きが生まれた

今回の修正によって、ポンの動きはパンタとはかなり違うものになりました。

これは当初から数値で細かく設計した結果ではありません。

画像生成AIによって制作された複数のアクション素材を実際にゲームへ組み込み、Playし、その動きを見たことで、

「ポンはこう動くキャラクターなんだ」

という個性が見えてきました。

キャラクター設定から動きを作るだけではありません。

生成された動きを見ることで、キャラクターのゲーム上の個性が決まっていく。

ここでも、

設計 → 生成

だけではなく、

生成 → 発見 → 設計

という逆方向の流れが生まれています。

パンタについては、現在使用している3カット素材を今後5カット素材へ全面的に入れ替える予定です。

その際には、今回得られた共通キャンバスと共通Pivotのルールを最初から適用します。

---

今回の到達点

今回の実装によって、

パンタが3個キャッチ

↓

パンタ大喜び

↓

パンタ退場

↓

ポン登場

↓

Current Scoreを0へリセット

↓

ポンがどんぐりをキャッチ

↓

Current ScoreとTotal Scoreを同時管理

↓

ポンが3個キャッチ

↓

操作停止

↓

キャッチ判定停止

↓

ポン大喜び

までが完成しました。

ポンの大喜び、待機キャッチ、左右移動キャッチについても、画像生成時に素材へ組み込まれていた本来の上下運動が復元されました。

残る基本ゲームループは、

ポン大喜び → ポン退場 → ゲーム終了

です。

ただし、今回はここで実装を止めることにしました。

Unity AI Agentの残りクレジットは、

114 / 1,000

となりました。

 

次回はクレジットに余裕がある状態で、ポンの退場とゲーム終了を実装します。

AIゲーム開発研究室

ゲーム開発ドキュメント

Unity AI Agentは「演出」まで設計できるのか

― 大喜びからキャラクター交代までをAIに任せてみた ―

今回は、2Dゲーム「森のどんぐり大作戦」の制作を進めました。

前回までに、

どんぐりが落下する
→ パンタが籠でキャッチする
→ どんぐりが消える
→ スコアが加算される
→ UIに表示される

ところまで実装されています。

今回の目的は、その先です。

規定数のどんぐりをキャッチする
→ パンタが大喜びする
→ パンタが退場する
→ 次のキャラクター、ポンが登場する

ここまでをUnity AI Agentとともに実装しました。

しかし実際に作業を進めてみると、今回の実験は単なるゲーム進行処理の実装では終わりませんでした。

---

1．7枚の静止画から「大喜び」を作る

パンタには、あらかじめ画像生成AIによって制作した7枚の「大喜び」候補画像がありました。

これらは連続アニメーションとして制作したものではありません。

それぞれ独立した、

「パンタなら、こんなふうに喜ぶかもしれない」

というポーズ候補です。

これまでの制作方法なら、人間がその中から使用する画像を選び、順番を決めてからUnityへ実装することになります。

実際、対話AIであるArcも、

03 → 04 → 05 → 07 → 02

という5枚の構成案を考えました。

しかし今回は、あえてそれをUnity AI Agentへ伝えませんでした。

さらに、人間も使用する画像、順番、タイミングを決めませんでした。

Unity AI Agent自身に7枚の画像を確認させ、

「どのポーズを使うか」
「どの順番に並べるか」
「どのくらいの時間で再生するか」

を判断させることにしました。

---

2．Unity AI Agentが静止画を読み取った

Unity AI Agentが選んだ順番は、

05 → 02 → 04 → 01 → 06 → 03 → 07

でした。

しかも7枚すべてを使用しました。

Unity AI Agentは、それぞれのポーズを単なるファイル番号として扱ったのではありません。

05を「最大の喜び」、

02と06を左右に対応する動的なポーズ、

04と03を左右のリズミカルなステップ、

01と07を正面方向のポーズ、

というように解釈しました。

そして、それらを時間軸上に再構成し、一つの「大喜びアニメーション」を作りました。

再生速度は6fps。

約1.17秒で1周するループアニメーションです。

人間がPlayモードで確認した結果、

非常に滑らかな大喜びアニメーションになっていました。

ここで興味深い結果が得られました。

これまで私たちは、

画像生成AIが動作候補を作る
→ 人間がポーズを選択する
→ 人間が運動として構成する
→ Unity AI Agentが実装する

という役割分担を考えていました。

しかし今回、

画像生成AI
→ 静止ポーズ候補
→ Unity AI Agentによるポーズの意味解釈
→ Unity AI Agentによる時間的再構成
→ 人間によるPlay評価

という別の経路が成立しました。

---

3．3個キャッチするとパンタが大喜び

次に、

どんぐりを3個キャッチするとパンタが大喜びする

処理を実装しました。

3個にしたのは、現在がゲーム進行システムを検証する段階だからです。

3個目をキャッチすると、

パンタの左右操作を停止
→ 通常アニメーションを停止
→ Celebrationへ移行

します。

人間によるPlay確認では、

キャッチ
→ スコア加算
→ 「どんぐり：3」
→ 大喜び

まで正常に動作しました。

---

4．大喜びしながら退場する

次はパンタの退場です。

ここでも、細かな演出数値を人間側から指定しませんでした。

Unity AI Agentに、

大喜びを少し見せる
→ 大喜びを続けたまま真下へ移動する
→ 完全に画面外へ出たら非表示にする

という目的を伝えました。

Unity AI Agentが設定したのは、

大喜び待機時間：1.5秒

退場速度：3.5

でした。

1.5秒という時間は、大喜びアニメーションを約1.3周見せることができる時間として選ばれました。

その後、Spriteアニメーションを継続したまま、Transformを使ってパンタを真下へ移動させます。

ここでは、

Sprite Animation＝大喜び

Transform＝退場移動

と役割を分離しています。

Playしてみると、

大喜びしながら地面へ沈んでいくパンタ

という、予想以上に楽しい演出になりました。

---

5．次のキャラクター、ポンを登場させる

パンタが退場したら、次はポンです。

最初の実装では、

パンタ完全退場
→ 0.6秒待機
→ ポンが画面下から上昇

という構成になりました。

Unity AI Agentはポンの既存アニメーションを確認し、登場中のアニメーションとして、

Pon_Catch_Up

を選択しました。

「上を見上げるポーズなので、画面下から上へ登場する動きに自然に合う」

という判断です。

登場速度には、パンタの退場速度と同じ、

3.5

が選ばれました。

これも正常に動作しました。

しかしPlayしてみると、一つ違和感がありました。

---

6．「0.6秒」が0.6秒には感じられない

数値上では、パンタ退場後の待機時間は0.6秒です。

しかし実際には少し長く感じました。

原因は画面を見れば分かりました。

ポンは画面外から移動を開始します。

さらにゲーム画面下部には前景として草が配置されています。

つまり、

0.6秒待機
＋ 画面外を移動する時間
＋ 下草の裏を移動する時間

を経て、ようやくプレイヤーからポンが見えるのです。

ここで、

プログラム上の待機時間と、プレイヤーが知覚する待ち時間は同じではない

ということが分かりました。

ゲームの演出は数値だけでは判断できません。

最終的には、人間がPlayして「どう感じるか」を確認する必要があります。

---

7．退場と登場を同時にする

そこで演出を変更しました。

パンタが退場移動を開始する
→ 同時にポンも画面下から登場移動を開始する

という方式です。

これによって、

パンタ ↓

ポン ↑

というキャラクター交代が同時進行します。

ただし、ここで別の問題があります。

二人が同じX座標にいると、上下移動中にキャラクターが重なってしまいます。

そこで、

退場位置と登場位置を重ねない

という方針を決めました。

---

8．Unity AI Agentが登場位置まで判断した

ポンの基本登場位置は、

画面中央 X=0

としました。

しかしパンタは、3個目のどんぐりをどこでキャッチするか分かりません。

パンタが中央付近で大喜びを始めれば、そのまま中央から退場します。

すると中央から登場するポンと重なります。

Unity AI Agentは、この問題に対して動的な処理を実装しました。

パンタが退場を開始した瞬間、

パンタのX座標をポン側へ通知

します。

そしてパンタとポンの距離が近すぎる場合には、

2.2ユニット以上離れるようにポンの登場位置を変更

します。

パンタが中央から十分離れていれば、ポンはX=0から登場します。

パンタが中央付近にいれば、その位置を避けて少し左右へずれた場所から登場します。

その結果、

退場するパンタと登場するポンが重ならない

キャラクター交代が実現しました。

Playモードで確認した結果、この演出も正常に動作しました。

---

9．AIが「実装」から「演出設計」へ入り始めた

今回、Unity AI Agentが行ったのはコード生成だけではありませんでした。

人間がすべてを数値として指定したわけでもありません。

Unity AI Agentは、

静止ポーズの意味を読み取る

アニメーションの順番を決める

再生タイミングを決める

大喜びを見せる時間を決める

退場速度を決める

登場に使用する既存アニメーションを選ぶ

登場速度を決める

キャラクター同士が重ならない登場位置を計算する

ところまで行いました。

これは、Unity AI Agentの役割が、

「人間が決めた仕様をコードへ変換するAI」

だけではない可能性を示しています。

人間が目的と制約を与え、細かな部分を固定しなければ、

AI自身が演出上の選択肢を評価し、初期案を設計する

ことも可能になってきました。

---

10．それでも最後に判断するのはPlayした人間

一方で、今回もっとも重要だった修正は、

「0.6秒では少し長く感じる」

という人間の感覚から始まりました。

処理そのものは正常でした。

バグでもありません。

Unity AI Agentの説明にも合理性がありました。

しかし実際にゲームをPlayすると違和感があった。

その違和感によって、

パンタ完全退場後にポン登場

から、

パンタ退場開始と同時にポン登場

へ設計そのものが変わりました。

つまり、

AIが正しく実装したことと、ゲームとして良いことは同じではありません。

ゲームは実際に動かし、人間が体験することで初めて分かることがあります。

---

11．今回の制作工程

今回の工程を整理すると、

画像生成AIが大喜びポーズ候補を生成

↓

Unity AI Agentが静止ポーズを解釈

↓

Unity AI Agentが大喜びアニメーションを構成

↓

人間がPlayして評価

↓

Unity AI Agentが大喜び後の退場を実装

↓

人間がPlayして評価

↓

Unity AI Agentがポンの登場を実装

↓

人間が「間が長い」と感じる

↓

人間と対話AIが原因を検討

↓

退場と登場を同時にするよう再設計

↓

Unity AI Agentが重なり回避まで含めて再実装

↓

人間がPlayして最終確認

となりました。

今回も、

設計 → 実装 → 検証 → 発見 → 再設計 → 再実装 → 再検証

という循環が実制作の中で確認されました。

---

12．人間の仕事はなくなったのか

今回、人間は大喜びアニメーションのフレーム順すら決めませんでした。

コードも書いていません。

退場速度も登場速度もUnity AI Agentが決めました。

一見すると、人間の仕事が減っているように見えます。

しかし実際には、人間は別のことをしています。

何をAIに決めさせるのかを決める。

何を固定条件として与えるのかを決める。

生成された結果をPlayする。

違和感を発見する。

何を変更すべきか考える。

そして、

最終的に採用するかどうかを決める。

今回、人間が意図的に「決めない」ことで、Unity AI Agentがどこまで演出を構成できるのかを検証することができました。

したがって、

人間が作業しないことを意図的に選択することも、AI時代の設計行為になり得る。

今回の実験は、その可能性を示したものだと考えます。

---

13．今回使用したUnity AIクレジット

前回作業終了時点では、

652 / 1,000クレジット

残っていました。

今回の作業終了時点では、

426 / 1,000クレジット

です。

したがって今回使用したクレジットは、

226クレジット

でした。

今回の226クレジットによって、

パンタの大喜びアニメーション構成
→ 3個キャッチによる大喜び移行
→ 大喜び後の退場
→ ポンの登場
→ キャラクター交代タイミングの修正
→ 登場位置の動的な重なり回避

まで実装しました。

Unity AIくん、今回はかなり働きました。

そのぶん、

226クレジットという、なかなかお高いギャラを持っていきました（笑）。

ただし、今回得られたものはコードだけではありません。

AIが静止画から動きを構成できること。

AIが既存素材の意味を読み取って演出へ利用できること。

人間が細部を決めなくても、AIが初期演出案を設計できること。

そして、AIが作った結果を人間が体験することで、次の設計変更が生まれること。

ゲームそのものと同時に、

 

AI時代のゲーム開発方法論そのものが、また一段進んだ一日になりました。

AIゲーム開発研究室

ゲーム開発ドキュメント

Unity AI Agentでどんぐり取得数とUIを実装する

前回は、画像生成AIによって制作したポンの5枚のアクション素材をUnityへ組み込み、左右移動と上下キャッチアクションを実装しました。

その過程では、アニメーションのループでキャラクターが一瞬消える問題や、キャラクターと前景との描画順の問題も発生しました。

それらを人間が実際のゲーム画面から発見し、Unity AI Agentへ修正を指示することで解決しました。

今回は、ゲームそのものをもう一段階進めます。

次に実装するのは、

どんぐりをキャッチした数を記録し、ゲーム画面に表示する機能

です。

---

まず既存の実装を調査する

今回、いきなりUnity AI Agentへ新しい機能を実装させることはしませんでした。

「森のどんぐり大作戦」では、すでにパンタが落下するどんぐりを籠でキャッチする仕組みを以前の実験で制作しています。

しかし、どこまで実装されているのかを人間が記憶だけで判断して、新しい処理を追加すると、すでに存在する機能を重複して作ってしまう可能性があります。

そこで最初にUnity AI Agentへ、

まだ何も変更せず、現在のプロジェクトを調査する

よう日本語で指示しました。

調査対象は、

Panta

BasketCatchArea

Acorn

AcornSpawner

関連するCollider、Rigidbody2D、スクリプト

既存UI

です。

---

Unity AI Agentが既存システムを調査する

Unity AI Agentによる調査の結果、パンタにはすでに、

BasketCatchArea

という籠の当たり判定用GameObjectが存在していることが確認されました。

そこには、

BoxCollider2D

と、

BasketCatchArea.cs

が設定されています。

さらに、パンタの移動方向やアニメーション状態に応じて、籠のコライダー位置を自動的に調整する処理も実装されていました。

落下するどんぐりには、

Rigidbody2D

CircleCollider2D

FallingAcorn.cs

が設定されています。

そして最も重要なのは、以前実装したキャッチ処理が、そのまま残っていたことです。

パンタの籠にどんぐりが入ると、

接触を検知する

↓

キャッチ成功と判断する

↓

どんぐりをDestroyする

ところまでは、すでに完成していました。

つまり今回、恐れていた当たり判定をもう一度作る必要はありませんでした。

---

既存システムを作り直さない

今回のUnity AI Agentの調査では、

既存のキャッチ判定、籠の追従、どんぐりの消去処理は作り直す必要がない

という判断が示されました。

これは重要です。

AI Agentを利用すると、つい、

「これを実装してください」

と新しい機能をそのまま作らせたくなります。

しかしゲーム開発が進むほど、プロジェクト内部にはすでに多くのGameObject、Component、Script、設定が存在しています。

そこで新しい処理を追加する前に、

AI Agent自身に現在のプロジェクトを調査させる

という工程を入れることで、既存の実装を利用しながら必要な部分だけを追加できます。

今回新たに必要だったのは、

キャッチ成功 → 取得数を1加算 → UIへ表示

という処理だけでした。

---

ScoreManagerを追加する

Unity AI Agentへ、既存のキャッチシステムを維持したまま取得数とUIだけを追加するよう指示しました。

その結果、新しく、

ScoreManager

が作成されました。

ScoreManagerは、現在のどんぐり取得数を保持・管理します。

取得数は、

CurrentScore

として外部から参照することができます。

また、

AddScore

によって取得数を加算し、

ResetScore

によって0へ戻すことができます。

さらに取得数が変化すると、

OnScoreChanged

というイベントを発生させる構造になりました。

この仕組みによって、今後、

一定数取得したらゲームクリア

といった処理からも、現在のどんぐり数を利用できるようになります。

---

どんぐり取得数をUIへ表示する

続いて、画面に取得数を表示するため、

ScoreCanvas

ScoreText

EventSystem

が追加されました。

ゲーム画面には、

どんぐり：0

と表示されます。

パンタがどんぐりをキャッチすると、

どんぐり：1

どんぐり：2

どんぐり：3

というように数字が増えていく予定です。

今回はUIデザインそのものを完成させることが目的ではありません。

そのため、どんぐりアイコンなどの装飾は追加せず、まず数字が正常に機能することを優先しました。

---

Unity AI Agentは「実装完了」と報告した

Unity AI Agentからは、

どんぐりキャッチ時の取得数カウントおよび画面UIへの表示実装が完了した

という報告がありました。

内部では、

BasketCatchArea

↓

ScoreManager

↓

OnScoreChanged

↓

ScoreUI

↓

ScoreText

という流れが構築されていました。

報告だけを見ると、問題なく完成したように見えます。

しかし、実際にゲームをPlayしてみると問題がありました。

---

どんぐりを取っても「0」のまま

パンタを操作し、落下してくるどんぐりをキャッチしました。

どんぐりは正常に消えています。

つまり、

当たり判定そのものは動いている

と考えられます。

ところが画面左上の表示は、

どんぐり：0

のままです。

何個キャッチしても数字が増えません。

Unity AI Agentは実装完了と報告していましたが、実際のゲームとしては正常に動作していませんでした。

---

すぐに修正させない

ここで今回は、

「直してください」

とは指示しませんでした。

まず、

プロジェクトを変更せず、原因だけを調査する

ようUnity AI Agentへ指示しました。

確認させたのは、

キャッチ時にCurrentScoreが増えているのか

OnScoreChangedが発火しているのか

ScoreUIがイベントを受信しているのか

ScoreTextへの参照は正常なのか

Consoleにエラーが発生していないのか

といった点です。

つまり、AIにいきなり修正を任せるのではなく、

まず何が正常で、どこから異常なのかを特定させる

ことにしました。

---

Unity AI Agentが原因を特定する

調査の結果、非常に明確なことが分かりました。

まず、

キャッチ時のCurrentScoreは正常に増加していました。

0から1、2、3と内部では正しく加算されています。

OnScoreChangedも正常に発火していました。

ScoreTextへの参照も正常でした。

Consoleにもエラーはありません。

問題があったのは、

ScoreUIがOnScoreChangedイベントを受信していない

ことでした。

---

原因は初期化順序だった

Unity AI Agentの調査によると、原因はUnityの初期化順序とイベント購読のタイミングにありました。

ScoreUIのOnEnableが実行された時点では、まだScoreManagerの初期化が完了していませんでした。

そのため、

ScoreManager.Instanceがnull

となり、ScoreUIによるイベント購読が行われませんでした。

その後ScoreManagerが正常に動き始めても、ScoreUIはイベントを購読していないため、取得数の変更通知を受け取ることができません。

結果として、

ゲーム内部では1、2、3……と増えている

にもかかわらず、

画面には「どんぐり：0」と表示され続ける

という状態になっていました。

---

エラーが出ない不具合

今回の問題でもう一つ興味深かったのは、

Consoleにエラーが出ていなかった

ことです。

プログラムそのものが停止しているわけではありません。

ScoreManagerは正常に動作しています。

イベントも正常に発火しています。

しかし、そのイベントを受け取る側が存在していませんでした。

そのためUnity上ではエラーとして検出されず、

ゲームを実際にPlayして画面を見なければ分からない不具合

になっていました。

---

原因を特定してから修正する

原因が特定されたところで、初めてUnity AI Agentへ修正を指示しました。

今回変更したのは、

ScoreUI.cs

だけです。

初期化順序に左右されないよう、ScoreManagerへのイベント購読処理を改善しました。

さらに、

isSubscribed

という購読状態を管理する仕組みを追加し、イベントが二重に登録されないようにしました。

購読解除についても処理されています。

つまり、

問題の原因を特定する

↓

原因となった部分だけを修正する

という方法を取りました。

---

10個連続でキャッチして確認する

修正後、再びゲームをPlayしました。

パンタを操作し、落下するどんぐりをキャッチします。

今度は、

どんぐり：0

から、

1、2、3……

と正常に数字が増えていきました。

今回は動いたところで確認を終了するのではなく、10個までどんぐりをキャッチして動作を確認しました。

結果、

10個まで正常にカウントされ、UIにも正しく表示されました。

これによって、

キャッチ判定

↓

どんぐり消去

↓

取得数加算

↓

UI更新

という一連の処理が正常に動作することを確認できました。

---

「実装完了」は「ゲーム完成」ではない

今回の実験は、AI Agentを利用したゲーム開発において重要なことを示しました。

Unity AI Agentは最初、

実装が完了した

と報告しました。

コード上でも、それぞれの処理は存在していました。

しかし実際にPlayすると、UIは更新されませんでした。

つまり、

AI Agentが実装を完了したことと、その機能がゲーム上で正しく動作することは同じではありません。

人間による実機確認が必要です。

---

AIにすぐ修正させないという方法

今回もう一つ見えてきたのは、不具合発生時のAI Agentへの指示方法です。

問題が発生したからといって、すぐ、

「直してください」

と指示する必要はありません。

今回は、

「まだ変更しないでください。原因だけを調査してください」

と指示しました。

その結果、Unity AI Agentは、

当たり判定は正常

ScoreManagerも正常

スコア加算も正常

イベント発火も正常

ScoreUIのイベント購読だけが異常

というところまで問題を切り分けました。

その後、原因となったScoreUIだけを修正しました。

この方法であれば、正常に動いている部分までAIが変更してしまう危険を減らすことができます。

---

AI Agentを使ったデバッグの流れ

今回の実験から、AI Agentを使ったゲーム実装とデバッグについて、一つの流れが見えてきました。

AI Agentが既存プロジェクトを調査する

↓

必要な部分だけを実装する

↓

AI Agentが実装完了を報告する

↓

人間が実際にPlayする

↓

人間が問題を発見する

↓

AI Agentへ「変更せず原因を調査する」よう指示する

↓

AI Agentが問題を切り分ける

↓

人間が調査結果を確認する

↓

AI Agentへ最小限の修正を指示する

↓

人間が再びPlayする

↓

正常動作を確認する

これは、AIにすべてを任せる開発方法ではありません。

同時に、人間がすべてのコードを書き、すべての原因を調査する従来の方法とも異なります。

人間とAI Agentが役割を分担しながらデバッグする方法

と言えるかもしれません。

---

Unity AIのクレジット消費を記録する

今回から、Unity AI Agentの実用性を検証するため、クレジット消費についても記録することにしました。

前回の作業終了時点では、

739 / 1,000クレジット

が残っていました。

今回、

既存プロジェクトの調査

ScoreManagerとUIの実装

UIが更新されない原因の調査

ScoreUIの修正

まで行った後、Unity Dashboardを確認しました。

残りは、

652 / 1,000クレジット

でした。

したがって今回の作業前後の差は、

87クレジット

です。

ただし、この87という数値を個々の処理へ単純に割り振ることはできません。

今回の一連の作業による実際の残量変化として記録しておきます。

---

AIにできるかだけではなく、AIに任せる価値があるか

クレジット消費を記録する理由は、単に使用量を節約するためだけではありません。

今後、コンタ、リン、ミミとキャラクターが増えていきます。

すでに完成している仕組みを、新しいキャラクターへ適用するたびにUnity AI Agentへすべて作業させる方がよいのか。

それとも、単純なCollider設定や既存設定の複製については人間が手動で行った方がよいのか。

これは実際の作業量とAIクレジット消費の両方を見ながら判断できます。

AI時代のゲーム開発では、

「AIにできるか」

だけではなく、

「その仕事をAIに任せることが合理的なのか」

という判断も必要になります。

---

今回の実験から

今回完成した機能だけを見れば、

どんぐりを取ると数字が1増える

という非常に小さなものです。

しかし、その実装過程から多くのことが分かりました。

既存プロジェクトをAI Agent自身に調査させる。

すでに正常な部分は作り直さない。

必要な機能だけを追加する。

AIの「実装完了」という報告をそのまま完成とは考えない。

人間が実際にゲームをPlayする。

不具合があれば、すぐ修正させるのではなく、まず原因だけをAIに調査させる。

原因が特定されたら、その部分だけを修正する。

そして再び人間がゲームをPlayして確認する。

今回も、

実装 → 検証 → 発見 → 調査 → 修正 → 再検証

という循環が発生しました。

そしてこの循環の中では、人間とAIのどちらか一方だけが開発を進めているわけではありません。

AI Agentがプロジェクトを調査し、コードを書き、原因を分析する。

人間がゲームを操作し、結果を見て、異常を発見し、AIへ次の指示を与える。

AIが実装し、人間が現実のゲームとして評価し、その結果を再びAIへ戻す。

この反復によって、ゲームは少しずつ完成へ近づいていきます。

次は、この取得数をゲームの進行条件として利用します。

一定数のどんぐりをキャッチしたらパンタのプレイを終了し、大喜びアクションへ移行する。

そしてパンタが退場し、次のキャラクターであるポンへ交代する。

 

今回作成した取得数管理システムが、次のゲーム進行システムへつながっていきます。

AIゲーム開発研究室

ゲーム開発ドキュメント

5枚のアクション素材をUnity AI Agentで動かす

これまで「森のどんぐり大作戦」では、画像生成AIを使ってキャラクターのゲーム素材を制作してきました。

今回から、その素材を実際にUnityへ組み込み、ゲーム上の動きとして成立させていきます。

今回使用したキャラクターは、タヌキのポンです。

ポンについては、

大喜びアクション
右移動キャッチアクション
上下キャッチアクション

の素材制作が完了しています。

また今回から、キャラクターのアクションは基本的に5枚の画像によるパラパラ漫画方式へ統一することにしました。

パンタについても、今後素材を作り直し、同じ5枚構成へ統一する予定です。

---

日本語でUnity AI Agentへ指示する

今回、最初に大きな進展がありました。

これまでUnity AI Agentへの指示には、主に英語を使用していました。

しかし今回、日本語で現在のHierarchyやGameObjectの構成を確認するよう指示したところ、Unity AI Agentは日本語の指示内容を理解し、現在のシーン構成を確認することができました。

さらにその後、

新しいキャラクターの追加

アニメーションの作成

左右移動の実装

既存キャラクターを参考にした操作方法の適用

不具合の修正

描画順の修正

まで、日本語による指示で実行することができました。

これは単にUnity AI Agentへ日本語で質問できるということではありません。

日本語による自然言語の指示から、既存のゲームプロジェクトを確認し、実際の実装と修正まで行うことができた

ということです。

これによって、

人間 ⇄ 対話AI

↓

日本語による実装指示

↓

Unity AI Agent

↓

Unity上の実装

という流れでゲーム開発を進められることが確認できました。

---

ポンのゲーム素材をUnityへ追加する

Unityプロジェクト内では、すでにパンタについて、

Assets / Art / Characters / Panta

というフォルダが作成されています。

そこでポンについても、

Assets / Art / Characters / Pon

というフォルダを作成し、制作したゲーム素材を格納しました。

右移動キャッチアクションについては、

Pon_Catch_Right_01
Pon_Catch_Right_02
Pon_Catch_Right_03
Pon_Catch_Right_04
Pon_Catch_Right_05

という5枚の素材を使用します。

01から05までの順序が、アニメーションの基本的な再生順になります。

---

5枚の右移動キャッチアクション

今回使用する5枚は、従来のアニメーション制作のように、最初から厳密な連続動作として制作したものではありません。

画像生成AIに、

「このキャラクターなら、どのように動けばかわいいか」

という余地を残し、複数のアクション候補を生成させました。

その中から、人間がゲームに使えそうなポーズを選択しています。

この方法は、これまでの素材制作実験から生まれた**「候補ポーズ方式」**です。

画像生成AIに完成したアニメーションそのものを要求するのではなく、画像生成AIには多様な動作候補を作らせ、その中から人間が使えるものを選びます。

今回の5枚にも、

地面を蹴るようなポーズ、

身体が浮いたようなポーズ、

足を前後へ大きく動かしたポーズなど、

それぞれ異なる身体表現が含まれています。

これらを01から05の順番で切り替えながら、Unity側でキャラクターそのものを横方向へ移動させました。

その結果、5枚の静止画像から、ポンが元気よく移動しているアクションを作ることができました。

---

左移動専用素材を作らない

ポンには左移動専用の画像素材を制作していません。

これは、すでに実装しているパンタと同じ方法です。

右向きの画像をUnityのSpriteRendererによって左右反転することで、左方向への移動を表現します。

つまり、

右移動用5枚を制作する

↓

右移動ではそのまま使用する

↓

左移動では同じ5枚を左右反転する

という方法です。

これによって画像生成AIに左右両方の素材を作らせる必要がなくなり、必要なゲーム素材の数を減らすことができます。

---

既存の実装を参考に新しいキャラクターを実装する

今回、Unity AI Agentには、すでに実装されているパンタの移動方法を確認したうえで、ポンにも同様の操作方法を適用するよう指示しました。

ポンは、

矢印キーまたはA/Dキーで左右移動

右移動では5枚の右向き画像を再生

左移動では同じ画像を左右反転

という操作になりました。

さらに移動速度については、

パンタ：4.0

ポン：2.5

となり、ポンはパンタより遅い移動速度になっています。

この実験では、Unity AI Agentが既存のキャラクター実装を確認し、その構造を参考にしながら新しいキャラクターへ適用することができました。

これは、キャラクターが増えていく今後の実装を考えるうえでも重要な結果です。

---

画像生成AIが作ったポーズは、そのまま「運動」ではない

今回の実験で、非常に重要なことが分かりました。

画像生成AIによって作られた5枚のポーズを並べれば、それだけでゲーム上の運動が完成するわけではありません。

画像生成AIが作ったものは、あくまで動作の候補となる静止したポーズです。

そのポーズを見て、

どの画像を使うのか

どの順番に並べるのか

どのポーズを地面付近に置くのか

どのポーズを空中に置くのか

といった運動上の意味を判断したのは人間です。

例えば、地面を蹴っているように見えるポーズをジャンプの最高点に配置すれば、不自然な動きになります。

反対に、空中にいるように見えるポーズを地面に配置しても、運動としては不自然です。

つまり、今回行われたことは、

画像生成AIが動作候補を生成する

↓

人間が候補を選択する

↓

人間が各ポーズを観察し、運動上の意味を判断する

↓

人間が時間的な順序や位置関係を決める

↓

Unity AI Agentがそれをゲーム上のアニメーションとして実装する

という工程です。

ここで人間は、画像生成AIとUnity AI Agentの間を単に仲介しているだけではありません。

画像から運動を読み取る役割

を担っています。

---

静止画像から運動を構成する

これは「候補ポーズ方式」を考えるうえでも重要な発見です。

画像生成AIは、必ずしも正確な連続アニメーションを作る必要はありません。

むしろ、多様で魅力的なポーズを生成することに能力を使わせることができます。

そして人間が、

どのポーズを採用するか

どのような順序で使用するか

ゲーム上でどのような動きとして解釈するか

を判断します。

つまり、

画像生成AIが「動きの可能性」を作り、人間がそこから「運動」を構成する。

その構成された運動を、Unity AI Agentがゲームとして実装します。

今回の実験によって、素材制作段階で生まれた「候補ポーズ方式」が、実際のゲーム実装までつながりました。

---

Unity AI Agentは画像から運動を判断できるのか

一方で、ここには今後の検証課題もあります。

Unity AI Agentへ5枚の画像を渡しただけで、

「これは踏み切り」

「これは上昇」

「これは最高点」

「これは下降」

「これは着地」

といった運動上の意味を判断し、自動的に適切な動きを構築できることは、今回の実験では確認していません。

今回、その判断を行ったのは人間です。

したがって現段階では、

画像生成AIがポーズを生成する

↓

人間がポーズを解釈する

↓

対話AIと相談しながら実装指示を作る

↓

Unity AI Agentが実装する

という役割分担になっています。

将来的にUnity AI Agentあるいは別のAIが画像を解析し、ポーズの運動上の意味まで理解して、自動的にアニメーションを構成できるのか。

これは今後、実際に検証してみる価値があります。

---

上下キャッチアクションを実装する

続いて、

Pon_Catch_Up_01 ～ 05

の5枚を使って、左右へ移動していないときの上下キャッチアクションを実装しました。

左右入力がないときには上下キャッチアクションを再生し、左右入力が行われると右移動キャッチアクションへ切り替えます。

左方向へ移動する場合には、右移動素材を左右反転します。

この段階ではUnity側から新たなTransformのY方向移動は追加していません。

まず人間が選択・構成した5枚のポーズをそのまま切り替え、どのようなアクションとして見えるかを確認することにしました。

---

ループすると一瞬キャラクターが消えた

上下キャッチアクションを実際にPlayしてみると、不具合が発生しました。

5枚の画像を繰り返し再生したとき、ループの境界でポンが一瞬消えてしまったのです。

実装そのものは完了しており、5枚の画像も表示されています。

しかし実際のゲーム画面を見ると、05から01へ戻る部分で一瞬キャラクターが消えていました。

そこで人間が問題を発見し、

05から01へループするときに空白時間やSpriteがNoneになる部分がないか確認する

よう、日本語でUnity AI Agentへ修正を指示しました。

Unity AI AgentがAnimation Clipのキーフレームや再生時間を修正した結果、一瞬消える問題は解消されました。

---

「実装できた」と「正しく動いた」は違う

この不具合は、AI Agentによるゲーム開発を考えるうえで重要です。

Unity AI Agentはアニメーションを作成し、実装を完了しました。

しかし、

実装が完了したことと、ゲームとして正しく動いていることは同じではありません。

実際のゲーム画面をPlayして確認したことで、人間は初めて一瞬の表示消失に気づきました。

今回の流れは、

Unity AI Agentが実装する

↓

人間がPlayする

↓

人間が問題を発見する

↓

対話AIと原因・修正方法を検討する

↓

Unity AI Agentへ修正を指示する

↓

Unity AI Agentが修正する

↓

人間が再びPlayして確認する

となりました。

---

キャラクター同士の描画順を修正する

さらに別の問題が見つかりました。

パンタとポンが同じ場所付近に移動すると、キャラクター同士の前後関係が安定しませんでした。

そこでSpriteRendererの描画順を調整し、

Panta：Order in Layer 1

Pon：Order in Layer 2

として、ポンをパンタより手前に表示するようにしました。

これによって、キャラクター同士の前後関係は安定しました。

しかし、ここで新しい問題が発生しました。

---

一つの問題を直したら、別の問題が発生した

ポンをパンタより手前に表示するよう修正した結果、今度はポンが画面下部の前景の草よりも手前に表示されてしまいました。

本来の画面構造は、

背景

↓

キャラクター

↓

前景

でなければなりません。

キャラクター同士の描画順だけに注目して修正した結果、ゲーム画面全体の描画関係が崩れてしまったのです。

そこで今度はUnity AI Agentへ、ポンとパンタだけではなく、

Forest_Background

Panta

Pon

Forest_Foreground_Top

Forest_Foreground_Bottom

を含めて、描画順全体を確認するよう指示しました。

最終的に、下部前景については、

Forest_Foreground_Bottom：Order in Layer 10

となり、

背景

↓

Panta：1

↓

Pon：2

↓

前景：10

という描画関係になりました。

これによって、

ポンはパンタより手前

しかし、

パンタとポンはともに前景の草より奥

という目的の画面構造が成立しました。

---

AIによる局所修正とゲーム全体の整合性

今回の描画順の問題は、非常に興味深い結果です。

最初に人間が発見した問題は、

「パンタとポンの前後関係がおかしい」

という局所的な問題でした。

Unity AI Agentは、その問題を修正しました。

しかし、その修正によって、

「キャラクターと前景との前後関係がおかしい」

という別の問題が発生しました。

つまり、

局所的には正しい修正であっても、ゲーム全体では新しい問題を発生させる場合がある。

ということです。

そして、この新しい問題を発見したのも人間でした。

AI Agentによる実装では、AIが処理を完了したという報告だけを見て作業を終了することはできません。

人間が実際のゲーム画面を見て、

本当に意図した結果になっているのか

を確認する必要があります。

---

AIの実行には人間の許可が必要になる場合がある

今回の作業中、Unity AI Agentが処理を実行しようとした際、

Run unsafe command

This command performs non-revertable actions.

という確認画面も表示されました。

人間が「View」を選択して確認しましたが、この画面では具体的に何を実行するのかまでは確認できませんでした。

そのうえで人間が実行を許可し、処理を続行しました。

これはAI Agentによる自動化を考えるうえで、別の重要な問題を示しています。

AI Agentが自律的に作業できる範囲が広がっても、すべてを無条件で実行するわけではありません。

一定の操作では、人間の許可が必要になります。

一方で、人間が許可を判断するために十分な情報が提示されているのかという問題も残ります。

この点についても、今後の実験で継続して確認していきます。

---

Unity AIのクレジットを確認する

今回の実験終了後、Unity DashboardからUnity AIのクレジット残量を確認しました。

2026年9月2日の作業終了時点で、

月額クレジット：1,000

残りクレジット：739

と表示されました。

次回のクレジット更新日は、

2026年10月2日

です。

Unity AI Agentは無制限に使用できるわけではありません。

したがって今後は、単にAI Agentで何ができるかだけではなく、

一つのゲームを完成させるために、実際にどの程度のAIクレジットを必要とするのか

という点も実制作を通して観察していきます。

これはAIを中心としたゲーム開発方法論を考えるうえで、実用面から重要な検証項目になります。

---

画像生成AIとUnity AI Agentがつながった

今回の実験によって、これまで別々に研究してきた、

画像生成AIによるゲーム素材制作

と、

Unity AI Agentによるゲーム実装

が、実際の制作工程としてつながりました。

現在の流れを整理すると、

公式キャラクター基準

↓

公式4面図

↓

画像生成AIによるアクション候補生成

↓

人間による候補選択

↓

人間によるポーズの解釈とアクション構成

↓

Unityへの素材配置

↓

対話AIによる実装指示の設計

↓

Unity AI Agentによる実装

↓

人間によるPlay確認

↓

問題・違和感の発見

↓

対話AIとの検討

↓

Unity AI Agentによる修正

↓

人間による再確認

となります。

---

AI時代のゲーム開発における人間の役割

今回の実験では、画像生成AIもUnity AI Agentも実際のゲーム開発に大きく関わりました。

しかし同時に、人間の役割も明確になってきました。

画像生成AIが作った候補から、どれを採用するのか。

そのポーズをどのような運動として解釈するのか。

実際に動かしたときに魅力的に見えるのか。

一瞬キャラクターが消えるという小さな異常に気づけるのか。

キャラクター同士の描画順を直した結果、前景との関係がおかしくなったことに気づけるのか。

これらは今回、人間が行った仕事です。

したがってAI時代のゲーム開発における人間は、単にAIへ命令を入力する存在ではありません。

AIが生成した結果を見て、意味を読み取り、選択し、評価し、次の方向を決める存在

として機能しています。

---

今回の実験から

今回行ったことだけを見れば、

「ポンをUnity上で動かした」

という小さな作業です。

しかし、その制作過程を記録すると、AI時代のゲーム開発における重要な構造が見えてきました。

画像生成AIが候補を生成する。

人間が選択し、運動として解釈する。

対話AIと人間が実装方法を検討する。

Unity AI Agentが実装する。

人間がゲームをPlayする。

問題を発見する。

再びAIへ戻す。

そして、その結果によって次の設計や実装も変わっていきます。

つまりAI時代のゲーム開発とは、

人間が完成形を先に固定し、それをAIに作らせるだけの一方向の工程ではありません。

人間と複数のAIが、生成・選択・解釈・実装・検証・修正を繰り返し、その結果によって設計そのものも更新しながら、ゲームを完成へ近づけていく開発方法です。

今回、画像生成AIによって制作したポンのアクション素材をUnity AI Agentによって実装したことで、素材制作段階で見つけた**「候補ポーズ方式」と、Unity AI Agentを使ったAIによるゲーム実装**が、初めて一本の制作工程としてつながりました。

そして実装して終わるのではなく、その結果を人間が見て問題を発見し、再びAIへ戻すところまで実際に行われました。

これは、本研究で考えてきた、

設計 → 制作 → 実装 → 検証 → 発見 → 再設計・再実装

という循環が、実際のゲーム制作の中で現れた一例でもあります。

ゲームを作るために研究するだけではありません。

ゲームを実際に作ることによって、AI時代のゲーム開発方法論そのものが見えてきます。

 

今回の実験は、そのことを改めて示す結果となりました。