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時代のゲーム開発方法論そのものが見えてきます。

 

今回の実験は、そのことを改めて示す結果となりました。

AIゲーム開発研究室

ゲーム開発ドキュメント

キャラクターアクション素材をAIと共同制作する

今回の制作では、「森のどんぐり大作戦」に登場する5人のキャラクター、

パンタ、コンタ、ポン、リン、ミミ

のゲーム用アクション素材を制作した。

当初、この工程を始めたときには、まず各キャラクターの4面図を制作することに、それほど大きな意味があるとは考えていなかった。

ゲーム画面では正面や側面など、限られた方向からしかキャラクターを使用しない可能性がある。

そのため4面図は、

「必要になるかどうかは分からないが、キャラクターの基準資料として、とりあえず作っておこう」

という程度の位置づけから始まった。

ところが、実際にアクション素材の制作を進めてみると、この4面図が非常に重要な役割を果たすことになった。

---

4面図は「使う画像」ではなく「AIへ渡す設計資料」だった

今回制作した4面図は、

• 正面
• 側面
• 背面
• 反対側面

から、同じキャラクターを描いたものである。

重要なのは、4面図そのものをゲームで使用するかどうかではない。

画像生成AIがキャラクターの立体的な構造を理解するための基準資料として機能したこと

である。

顔だけではなく、

体形、手足の長さ、尻尾、リュック、ポシェット、衣服、帽子、スカーフなどを、複数方向から確認できる。

その結果、その4面図を基準画像としてアクション素材を生成すると、異なる角度や大きなポーズを取らせても、同じキャラクターとしての一貫性を維持しやすくなった。

これは実際に制作してみなければ分からなかった。

---

アニメーションを作らせることをやめた

これまでの実験では、画像生成AIに、

「歩行アニメーションを作る」

「右足と左足を交互に動かす」

「何コマ目では右足を前へ出す」

といった指示を与え、連続したアニメーションそのものを生成させようとした。

しかし、この方法では思ったような結果が得られなかった。

足の運びを細かく指定しても、すべて似たようなポーズになったり、左右の脚の関係が崩れたりする。

そこで今回は、考え方そのものを変更した。

画像生成AIに完成したアニメーションを作らせない。

代わりに、

一つの動作に対して、多数の「候補ポーズ」を生成してもらう。

そして、その中からゲームに使用できそうなポーズを人間が選択する。

選択した画像を連続表示し、キャラクターそのものの移動や上下運動はUnity側で制御する。

この方式を採用した。

---

AIにポーズを考えさせる

さらに今回、もう一つ大きく方針を変えた。

以前は、

「右脚を前へ」

「左脚を後ろへ」

「身体を何度傾ける」

といったように、人間側がポーズを細かく決めようとしていた。

しかし今回は、あえてそれをやめた。

画像生成AIに、

「このキャラクターなら、どんな動きをすると魅力的なのか」

を考えさせることにした。

もちろん最低限の条件は指定する。

たとえばパンタ、コンタ、ポンでは、

頭の上に籠を載せ、両手で支える。

リンとミミでは体形を考慮して、

胸の前で籠を両手で抱える。

さらに籠の中のどんぐりは、全キャラクター共通で2個とした。

キャラクターの公式デザイン、装備、籠の持ち方など、ゲームとして守らなければならない条件は人間が決める。

しかし、

その状態でどんなポーズを取るかについては、画像生成AIにかなり大きな自由を与えた。

すると、予想以上に面白い結果が得られた。

---

「正しい動き」ではなく「使いたくなる動き」が生まれた

生成された画像には、

走っているようなポーズ、

大きく脚を開いたポーズ、

小さく跳ねているポーズ、

身体を沈めたポーズ、

片脚を上げたポーズ、

身体を傾けたポーズなど、

人間側では最初から思いつかなかった動きが多数含まれていた。

特にリンでは、右移動用として生成した画像から、非常に軽快な走行アクションを構成できそうな候補が得られた。

ミミでは、大きな耳そのものが動きの一部となり、リンとはまったく異なる移動表現が生まれた。

ポンは丸い身体と大きな尻尾を使った、少し重そうで愛嬌のある動きになった。

コンタには、キツネらしい軽快さが現れた。

そしてパンタは、短い脚と丸い身体を使って一生懸命進んでいるような、パンタ独自の動きになった。

興味深いのは、

「キャラクターごとに違う動きを作れ」と細かく指定していない

ことである。

同じ「右方向へ移動する」という目的を与えても、キャラクターデザインそのものの違いから、それぞれ異なる動きが生成された。

---

キャラクターの個性は、動きからも生まれる

ゲーム設計の初期段階では、

「リンは速い」

「ポンは遅い」

「コンタは滑る」

「ミミは跳ねる」

といった個性を、あらかじめゲームシステム側から与えることを考えていた。

しかし今回の制作によって、この考え方も少し変わった。

先にキャラクターの動きを決める必要はないのかもしれない。

まず画像生成AIにさまざまなポーズを作らせる。

その結果を見て、

「このキャラクターは、この動きが似合う」

と判断する。

そしてUnity側で移動速度、ジャンプ量、上下動、加速、減速などを調整する。

つまり、

キャラクター設定 → 動きを制作する

という一方向だけではなく、

生成された動き → キャラクターのゲーム上の個性を発見する

という逆方向の設計も可能になる。

これはAIをゲーム制作へ導入することで生まれた、非常に興味深い制作方法だと思う。

---

「失敗画像」が問題ではなくなった

今回の方法には、もう一つ大きな利点があった。

一枚の画像の中に多数の候補ポーズを生成するため、すべてが完璧である必要がない。

実際、一部には、

籠の形が少し変化したもの、

キャラクターの一部に不自然さがあるもの、

ゲームには使いにくいポーズなども存在した。

しかし、8枚生成して6枚使えるのであれば、それでよい。

10枚生成して3枚が非常に良ければ、その3枚を使えばよい。

ここでは、

生成画像全体の完成度を評価する必要がない。

目的は、

ゲームに使える素材を発見すること

だからである。

これは完成したスプライトシートを一度に生成しようとする方法とは、根本的に異なる。

---

パンタを作り直す

今回、最後にパンタの素材を改めて制作した。

パンタにはすでに以前制作したアクション素材が存在していた。

しかし、他の4キャラクターを、

4面図 → 大喜び → 籠あり上下アクション → 籠あり右移動アクション

という新しい工程で制作した結果、パンタだけが以前の制作方法による素材として残ることになった。

比較すると、その違いは明らかだった。

そこでパンタについても、まず新しい公式4面図を制作し直した。

その4面図を基準として、

大喜び、

頭上に籠を載せた上下アクション、

頭上に籠を載せた右移動アクション、

を再制作した。

結果として、パンタも他の4キャラクターと同じ世界観、同じ制作方法の中へ統一することができた。

そして何より、

以前よりパンタらしく、かわいく、動きの大きな素材が得られた。

作り直したことによって、4面図から始める今回の方法の有効性を、逆に確認することになった。

---

今回確立した制作工程

今回の実験から、ゲーム用キャラクターアクション素材について、次の制作工程が見えてきた。

キャラクター公式基準画像

↓

公式4面図を制作する

↓

4面図を新しいキャラクター基準資料とする

↓

動作の目的と最低限の条件だけを決める

↓

画像生成AIに複数の候補ポーズを自由に生成させる

↓

人間がゲームに使用するポーズを選択する

↓

必要なカットを個別のゲーム素材へ加工する

↓

Unity上で連続表示する

↓

移動・速度・上下動・ジャンプなどをUnity側で制御する

この工程では、

画像生成AIにアニメーションを完成させることを要求していない。

AIには、

魅力的な「動きの断片」を発見する役割

を与えている。

そして人間は、その中から何を使うかを判断する。

Unityは、それらを時間と空間の中で動かす。

---

人間とAIとUnityの役割が見えてきた

今回の実験を整理すると、それぞれの役割はかなり明確である。

人間

ゲームの目的を決める。
キャラクターを決める。
守るべき条件を決める。
生成された候補から採用するものを判断する。

対話AI

人間との対話から制作条件を整理する。
画像生成AIへ渡すプロンプトを設計する。
生成結果を分析し、次の制作方針を組み立てる。

画像生成AI

キャラクター基準資料をもとに、多様なアクションポーズを創作する。
人間が想定していなかった動きも提案する。

Unity

選択された素材をゲーム内へ配置する。
画像を切り替える。
キャラクターを移動させる。
速度、上下動、ジャンプなどを制御する。

これは単純な、

「AIにゲーム素材を作ってもらう」

という関係ではない。

人間、対話AI、画像生成AI、ゲームエンジンが、それぞれ得意な仕事を担当する制作工程になっている。

---

AIに任せることで生まれたもの

今回、何度も感じたことがある。

細かく指示したときより、

ある程度AIに任せたときの方が、魅力的なものが出てくることがある。

もちろん、すべてをAIに任せればよいという意味ではない。

キャラクターデザイン、装備、籠の位置、どんぐりの数など、守らなければならない条件は明確に指定する必要がある。

しかし、その条件の内側に、

AIが自由に考える余地

を残しておく。

するとAIは、単なる作業装置ではなく、

制作上の選択肢を増やす存在

になる。

人間が一つのポーズを考えてAIに描かせるのであれば、最初から存在している選択肢は一つしかない。

しかしAIに10種類のポーズを考えさせれば、人間はその10種類を見てから考えることができる。

その中には、人間が思いつかなかった11番目のアイデアへつながるものさえあるかもしれない。

今回のアクション素材制作で得られた最大の収穫は、完成した画像だけではない。

AIに何を指示するかだけではなく、何を指示しないかも、AI時代の制作では重要である。

 

そのことが、実制作を通して見えてきた。

AIゲーム開発研究室

ゲーム開発ドキュメント

キャラクター4面図を作って分かったこと

― AI時代の「公式キャラクターデザイン確定工程」

ゲーム「おむすび山のなかまたち」の制作を進めています。

これまで、ゲームの背景、前景、キャラクターのアクション素材などを制作してきました。

そして今回、パンタ以外のキャラクターについても、正面・左右側面・背面を描いた「4面図」を作ることにしました。

ただし、制作を始めた時点では、この工程をそれほど重要なものだとは考えていませんでした。

2Dゲームで使用するキャラクター素材は、実際にはゲーム画面で必要となる方向やポーズを個別に制作していきます。

そのため、

「4面図が本当に必要なのかは分からない。でも、キャラクターの基準資料として作っておこう」

という程度のところから始めたのです。

ところが、実際に作ってみると話が変わってきました。

4面図を作るという作業によって、それまで気づかなかった問題が次々と見えてきたのです。

そして最終的には、

4面図は単なるキャラクター資料ではなく、公式キャラクターデザインを確定するための重要な工程ではないか

と考えるようになりました。

---

絵本のキャラクターは、本当に同じデザインだったのか

「おむすび山のなかまたち」のキャラクターたちは、これまで絵本の中で何度も描かれてきました。

パンタ、コンタ、ミミ、リン、ポン。

どの画像を見ても、それぞれ同じキャラクターとして認識できます。

ところが、今回4面図を制作するために過去の画像を改めて比較してみると、細部にはかなりの違いがあることが分かりました。

特に分かりやすかったのが、ミミです。

画像によってリュックがあったりなかったりします。

ポシェットの形も完全には同じではありません。

ワンピースの柄や細部のデザインにも違いがあります。

これまで絵本として見ていると、それほど気になりませんでした。

場面が変わり、ポーズが変わり、背景が変われば、多少の違いがあっても「ミミ」として成立していたからです。

ところが、

「では、ミミの正式なデザインはどれなのか？」

と聞かれると、答えられない。

ここで初めて問題が明確になりました。

---

そして、もっと大きな間違いを発見した

過去の基準画像を確認している途中で、さらに面白いものを発見しました。

ミミは、うさぎです。

当然、尻尾は小さく丸いうさぎの尻尾です。

ところが、これまで何度も基準画像として使用していた絵本画像のミミには、

なぜかリスのような大きな尻尾がついていました。

今まで気づきませんでした（笑）。

さらに面白いのは、その画像を基準画像として使っていたにもかかわらず、その後生成された多くのミミには、ちゃんとうさぎの尻尾が描かれていたことです。

つまり画像生成AIは、添付された画像の特徴を何も考えずにそのまま複製していたわけではありません。

「ミミはうさぎである」という情報や、他の視覚的特徴などを含めて解釈した結果、誤っていた尻尾をうさぎの尻尾へ戻していたと考えることもできます。

もちろん、毎回そのように都合よく修正してくれる保証はありません。

しかし少なくとも、

基準画像に描かれているものが、そのまま絶対的なキャラクター仕様になるわけではない

ことは分かりました。

これは生成AIを使って継続的にキャラクターを制作するとき、かなり重要な問題です。

---

「過去の画像を忠実に再現してください」では解決しない

ここで一つ困ったことが起きます。

過去の画像そのものに違いがあるのですから、

「添付画像を忠実に再現してください」

と指示しても、公式デザインは決まりません。

リュックはあるのか、ないのか。

ワンピースはどの柄なのか。

ポシェットはどの形なのか。

どれも過去作品の中に複数の答えがあります。

そこで方針を変えました。

過去の画像を「絶対的な正解」として扱うのではなく、

これまで描かれてきたキャラクターを確認するための資料

として扱うことにしたのです。

そして複数の画像に共通する特徴を残しながら、曖昧だった部分については、この機会に正式なデザインを決めることにしました。

---

ミミの公式デザインを決める

例えばミミでは、今回の制作によって、

ピンクの花柄ワンピース

白い襟

胸元の小さな白いリボン

ピンクのリュック

黄色いポシェット

頭のピンクのリボン

小さく丸いうさぎの尻尾

という基本デザインを整理しました。

特にワンピースの柄は、それまでかなり複雑で、画像によって変化していました。

そこで今回は、小さな白い花柄として整理しました。

ここで一つ、新しい問題も見えてきます。

従来のキャラクターデザインでは、デザイナーが描くことのできるデザインであれば成立します。

しかし生成AIによって大量のゲーム素材を制作する場合、それだけでは十分ではないかもしれません。

毎回違う模様になってしまうような複雑なデザインより、

繰り返し生成しても同じキャラクターとして再現しやすいデザイン

の方が適している可能性があります。

つまりAI時代には、

「生成AIが安定して再現できるか」

という条件そのものが、キャラクターデザインの一部になるかもしれません。

---

4面図にすると、体形まで見えてくる

ミミの最初の4面図は、かなり良い出来でした。

顔もかわいい。

衣装もいい。

リュックもポシェットも描かれています。

ところが、4方向のミミを横に並べて見ていると、どうしても気になることがありました。

少し背が高い。

絵本の中では気にならなかったのですが、キャラクターだけを取り出して並べると、少し大人びた体形に見えます。

そこで、

頭を大きくする。

胴体を小さくする。

腕を短くする。

脚を短くする。

全体をコンパクトにする。

という方向で再調整しました。

その結果、より幼いミミらしいプロポーションになりました。

ここでも4面図の意味が変わります。

4面図は衣装や持ち物を確認するだけではありません。

キャラクターの頭身や身体のシルエットを検証するための資料にもなる。

これは実際に4面図を作るまで気づかなかったことでした。

---

「左側面」と書くだけでは左側面にならない

もう一つ苦労したのが、左右の側面です。

最初のミミでは、4体描かれているにもかかわらず、

左右の側面が同じ方向を向いていました。

確かに4体あります。

でも4面図ではありません（笑）。

そこでプロンプトの書き方を変更しました。

単に、

「左側面」

「右側面」

と書くのではなく、

正面 ｜ ← 左向き側面 ｜ 背面 ｜ 右向き側面 →

と、完成画像上で鼻先がどちらを向くのかまで明示しました。

さらに、

「同じキャラクターを、その場で90度ずつ回転させて見ている」

と説明しました。

この考え方を取り入れてから、結果はかなり安定しました。

その後制作したコンタでは、ほぼ一回で4方向が成立しました。

---

一人目の失敗が、次のキャラクターを作る

ここから制作が面白くなってきました。

ミミでは何度も試行錯誤しました。

ところが、その失敗から得た情報を次のプロンプトへ組み込んでコンタを生成すると、最初からかなり完成度の高い4面図が生成されました。

つまり、

一人目で失敗したことが、二人目では最初から解決されている。

そしてコンタで得た結果を、さらにポンへ引き継ぎます。

こうしてキャラクターを一体作るごとに、4面図を生成するための方法そのものが成長していきました。

これは単なるプロンプトの使い回しではありません。

生成結果を検証し、問題を発見し、その問題を次の生成方法へ反映する。

実制作を通して、制作方法そのものが更新されていったのです。

---

ポンでは「存在しなかった公式デザイン」を作ることになった

ポンでは、さらに一歩進みました。

過去画像を見ると、頭に葉っぱがあるものとないものがあります。

首元のデザインにも違いがあります。

体形にも差があります。

リュックの細部も一定ではありません。

そこで今回は、どれか一枚の画像を正解とするのをやめました。

そして、

頭には緑色の葉っぱ

オレンジ系の革製の首輪

オレンジ色のリュック

太くて縞模様のある尻尾

少し小太りで、ころんとした体形

を、今後のポンの公式デザインとして決定しました。

これは、過去画像の再現ではありません。

過去作品を資料として利用しながら、

これから使用するポンのデザインを新たに確定した

ことになります。

ここまで来ると、4面図制作は明らかに単なる資料制作ではありません。

キャラクターデザインそのものの工程です。

---

詳しく指示すれば、必ず良くなるわけでもない

ポンの制作では、もう一つ面白い出来事がありました。

プロンプトを調整している途中で、意図せず画像生成が始まってしまいました。

ところが、その画像がかなり良かったのです。

その後、条件をきちんと整理した詳細なプロンプトで改めて生成しました。

しかし絵として見れば、

意図せず生成された最初の画像の方が魅力的に感じる部分もありました。

最終的には4面図としての整合性などを考えて別の画像を採用しましたが、ここからも重要なことが分かります。

プロンプトを詳しく書けば書くほど、必ず良い画像になるわけではない。

生成AIには偶発性があります。

そして、その偶発性から生まれたものを「失敗だから」と捨てるのではなく、人間が見て判断する必要があります。

---

リンのポシェットは、尻尾がうまく隠してくれた

リンにも特徴的な問題がありました。

リンが持っている黄色いポシェットは、これまでの絵本を見ると、意外に凝った形をしています。

単に、

「黄色いポシェット」

と指示すると、一般的な肩掛けバッグになってしまう可能性があります。

そこで過去の絵本画像を直接参照させました。

生成された4面図を見ると、完全に構造を解決したわけではありません。

ところがリンには、大きな尻尾があります。

その尻尾が、ポシェットの背面側をうまく隠してしまいました（笑）。

しかし、キャラクター基準として見ると問題ありません。

正面と側面から、ポシェットの特徴は十分確認できます。

ここで改めて考えました。

キャラクター4面図は、機械設計図ではありません。

すべての部品構造を完全に露出させることが目的ではない。

今後、そのキャラクターを同じキャラクターとして再現するために必要な情報が確認できればよい。

そう考えると、これも十分に成立しています。

---

最後に、もう一度ミミへ戻った

コンタ、ポン、リンの4面図を制作した後、最初に苦労したミミをもう一度作ってみることにしました。

今度は、最初のときとは条件が違います。

それまでの制作から、

左右方向をどう指示するか。

4方向をどうやって同一人物として認識させるか。

背景を完全透明にするにはどう指示するか。

余計な文字や設定表を出させないためにはどうするか。

デザインを変えずに体形だけを幼くするにはどう記述するか。

さまざまな知見が蓄積されています。

さらに、先に制作したミミの画像そのものも新しい基準画像として使用できます。

そして再生成しました。

結果は、

最初のミミより幼い体形になり、左右側面も正しい方向になりました。

最初の失敗から始まり、

ミミ
↓
コンタ
↓
ポン
↓
リン
↓
再びミミ

と一周したことで、最初のキャラクターまで改善されたことになります。

これは非常に興味深い制作過程でした。

---

4面図は「完成したデザインを記録するもの」だけではなかった

今回、最初に考えていた工程は単純でした。

キャラクターがいる。
だから4面図を作る。

ところが実際にやってみると、そうではありませんでした。

複数の過去作品を見る。

デザインの揺れを発見する。

何を残し、何を変更するか判断する。

曖昧だった部分を決定する。

対話AIがそれを言語化する。

画像生成AIが4面図として可視化する。

人間が結果を見る。

問題があれば再び対話する。

修正する。

そしてようやく、

「これを公式デザインとする」

と決定する。

つまり実際に起きたのは、

過去作品
↓
比較・検証
↓
デザインの揺れを発見
↓
公式仕様を決定
↓
プロンプトとして言語化
↓
4面図を生成
↓
人間による評価
↓
修正
↓
公式キャラクターデザイン確定

という工程でした。

4面図は、その最後に作られる資料ではありませんでした。

4面図を作ること自体が、キャラクターデザインを確定するための工程になったのです。

---

AI時代のキャラクターデザイン工程

今回の制作では、人間だけがキャラクターを設計したわけではありません。

画像生成AIだけが設計したわけでもありません。

人間は過去画像を見て、

「これは残す」

「これは違う」

「こちらの方がかわいい」

「もう少し幼くしたい」

「このリュックは必要」

と判断しました。

対話AIは、その判断を整理し、矛盾を発見し、画像生成AIへ渡す仕様として言語化しました。

画像生成AIは、その仕様を視覚化しました。

そして生成された画像を見た人間が、再び判断しました。

つまり、

人間 → 対話AI → 画像生成AI → 人間

という循環によって、キャラクターデザインが確定していきました。

これは、最初から完成したデザインをAIに描かせる工程とは少し違います。

AIとの対話と生成結果そのものを使って、デザインを発見し、確定していく工程

です。

---

やってみなければ分からなかった

今回の4面図制作は、最初から研究として大きな成果を期待して始めたものではありません。

むしろ、

「必要ないかもしれないけれど、とりあえず作っておこう」

というところから始まりました。

しかし実際にやってみると、

過去作品のデザインの揺れが見つかりました。

基準画像そのものの間違いも見つかりました。

キャラクターの体形の問題も見つかりました。

生成AIが再現しやすいデザインについて考えることになりました。

左右側面を安定して生成する方法も見つかりました。

一体目で得た知見を次のキャラクターへ継承できました。

そして最終的には、5人の公式キャラクターデザインを改めて確定することができました。

最初から方法論を考えていただけでは、おそらくここには到達しませんでした。

実際に作ったから、問題が見えた。

問題が見えたから、方法が生まれた。

AIを使ったゲーム開発では、この繰り返しそのものが研究なのだと思います。

そして今回、

「キャラクター4面図制作」

として始めた小さな工程から、

「AI時代の公式キャラクターデザイン確定工程」

 

と呼べるものが、一つ見えてきました。

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

どんぐりをゲットする

――AI Agentによる当たり判定の実装と、見えてきた現実的な制約

前回までの制作で、パンタを左右に操作できるようになり、画面上部からどんぐりが次々と落ちてくるところまで完成した。

パンタは左右に動く。

どんぐりはランダムな位置から落下する。

回転しながら地面へ向かい、画面外へ出たどんぐりは自動的に消える。

ここまで来れば、次に必要なのは当然、

パンタがどんぐりを取ること

である。

今回は、パンタの籠とどんぐりの当たり判定を実装する。

---

どんぐりを籠で受け止める

今回も基本的な方法は変わらない。

人間がUnity上でColliderを設定し、スクリプトを書いて実装するのではない。

まず人間と対話AIであるArcが、何を実現するのかを確認する。

その内容をもとにArcがUnity AI Agentへ渡す指示を作成する。

人間は、その指示をUnity AI Agentへ渡す。

そしてUnity AI Agentが、実際のUnityプロジェクトを調べ、必要な設定と実装を行う。

人間が行うのは、基本的に結果の確認である。

今回実現したいことは単純だった。

落下してきたどんぐりがパンタの籠に入ったら、そのどんぐりを消去する。

Unity AI Agentは、パンタの籠とどんぐりの状態を確認し、当たり判定に必要な設定を行った。

途中、Unity AI Agentから変更を実行するための許可を求められたため、人間が許可を与えた。

そしてゲームを実行する。

どんぐりが落ちてくる。

パンタを操作して、その下へ移動する。

籠にどんぐりが入る。

どんぐりが消えた。

成功である。

これで、

どんぐりを落とす

だけだったゲームに、

どんぐりを取る

というゲームとして最も基本的な仕組みが加わった。

---

実際に遊べるところまで来た

ここまでの実装によって、現在の「森のどんぐり大作戦」では、

パンタを左右に操作できる。

左右移動に合わせてキャラクターアニメーションが切り替わる。

画面外へ出ないように移動範囲が制限される。

どんぐりが画面上部から連続して出現する。

どんぐりは重力によって落下する。

落下しながら回転する。

画面下へ出たどんぐりは消える。

そして、

籠で受け止めたどんぐりも消える。

まだ得点表示もキャラクター交代もない。

しかし、ゲームの中心となる、

「キャラクターを操作して、落ちてくるどんぐりを取る」

という遊びそのものは成立した。

---

ところが、突然警告が表示された

当たり判定の実装は成功した。

ところが、その直後だった。

Unity AI Agentの画面に警告が表示された。

「Only 10% of your org's credits remain.」

組織に割り当てられているAIクレジットが、残り10％しかないという警告である。

さらに作業の最後には、

「Not enough credits remaining.」

という赤い表示も現れた。

AI Agentを利用するためのクレジットが不足しているらしい。

ゲームそのものを確認すると正常に動いている。

パンタは動く。

どんぐりも落ちる。

籠に入れば消える。

つまり、制作したゲームが壊れたわけではない。

問題は、Unity AI Agentを利用するためのクレジットだった。

---

残り27クレジット

Unity Cloudの管理画面を確認した。

そこで、現在の状況が明確になった。

利用可能なクレジット　27

AIサブスクリプション
残り27 / 1,000クレジット

さらに、

クレジット更新　2026年9月2日

月額クレジット　1,000

と表示されていた。

つまり、今回使用していたAIサブスクリプションには月額1,000クレジットがあり、そのほとんどを使ったことになる。

残りはわずか27クレジット。

今回の研究では、単にAI Agentへ質問していたわけではない。

シーンの確認。

キャラクター位置の調整。

アニメーションの作成。

画像素材の問題の診断。

左右移動の実装。

画面端での移動制限。

どんぐりの落下。

回転。

連続生成。

画面外での消去。

そして籠との当たり判定。

実際のゲーム制作をAI Agentに次々と行わせてきた。

その結果として、AI Agentを本格的なゲーム開発に利用した場合、クレジットが実際に消費されていくという、当然ではあるが重要な現実にぶつかった。

---

追加クレジットを購入できるのか

Unity Cloudには、

「もっとクレジットを買う」

という項目も表示されていた。

そこで追加購入が可能なのか確認してみることにした。

ところが、表示されたのは次のメッセージだった。

「この製品は現在、お住まいの国では入手できません。」

少なくとも今回、実際に使用している日本の環境から表示された購入経路では、追加クレジットを購入することができなかった。

したがって、現時点では残っている27クレジットを使い切れば、表示上の次回更新日である9月2日まで、新しい月額クレジットを待つことになる。

※UnityのAIツールは現在Beta版であり、料金体系や提供地域、クレジット制度などは今後変更される可能性がある。本稿は2026年8月24日時点で、実際の開発環境に表示された内容を記録したものである。

---

AIゲーム開発には「AIの稼働資源」が必要になる

今回の出来事は、単なるクレジット不足として片づけるべきではないと思う。

従来のゲーム開発でも、制作にはさまざまな資源が必要だった。

人員。

時間。

制作費。

コンピュータ。

ソフトウェア。

そしてAIを中心としたゲーム開発では、そこに新しく、

AIを稼働させるための資源

が加わる。

今回の実験では、一人の人間がプログラムを書かなくても、対話AIとUnity AI Agentを連携させることで、実際にゲームが形になっていった。

これは非常に大きな可能性である。

しかし、AIはいくらでも働いてくれるわけではない。

AI Agentに実際の制作作業を大量に任せれば、それに応じて利用可能なクレジットも消費される。

AIに何を任せるのか。

どの作業にAI Agentを使うのか。

限られたAI資源をどのように配分するのか。

これもまた、AI時代のゲーム開発では制作工程の一部として考える必要があるのかもしれない。

---

人間は観客になれたのか

今回の実験を始めてから、何度か冗談で、

「人間はもう観客である」

と言ってきた。

実際、今回も人間はColliderの数値を入力していない。

当たり判定のスクリプトも書いていない。

人間は何を作りたいのかを考え、対話AIであるArcと相談し、Unity AI Agentへ指示を渡し、実際にゲームを操作して結果を判断した。

そしてUnity AI Agentがゲームを実装した。

少なくとも今回の範囲では、

人間がコードを書かなくても、AIとの対話と判断によってゲーム制作を進めることができた。

この実験結果は変わらない。

ただし、一つだけ予想していなかったことが起きた。

人間が疲れて止まったのではない。

Unityのゲームが壊れて止まったのでもない。

AIのクレジットが先に尽きかけたのである。

---

今回の実験結果

今回、「森のどんぐり大作戦」では、パンタの籠とどんぐりの当たり判定が実装された。

これによって、

移動する。
どんぐりが降ってくる。
籠で受け止める。
どんぐりが消える。

というゲームの基本ループが実際に動き始めた。

同時に、AI Agentを実制作の中心に置いたゲーム開発では、AIクレジットという新しい制約が存在することも実体験として確認した。

これは予定していた実験ではない。

しかし実際にゲームを作ったからこそ見えてきた問題である。

ゲーム開発そのものは成功した。

そして成功して先へ進んだからこそ、次の問題が見えた。

これもまた、「AIゲーム開発研究室」で記録すべき重要な実験結果だと思う。

次回までの間は、Unity AI Agentのクレジットを温存しながら、ゲーム素材など今後の制作に必要な準備を進める。

そして9月2日。

新しいクレジットが利用可能になれば、

 

AI Agentによる「森のどんぐり大作戦」の開発を再開する。