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による「森のどんぐり大作戦」の開発を再開する。

AIゲーム開発研究室

ゲーム開発ドキュメント

Unity AI Agentによるゲームシステム実装

AIに「どんぐり工場」を作らせる

前回の実験では、Unity AI Agentによってパンタのアニメーションとプレイヤー操作を実装した。

パンタは待機時には正面を向いて小さく動き、右へ移動すると右向きのアクションへ切り替わる。

左へ移動するときには右向きアニメーションを反転して使用し、キーを離すと再び正面の待機状態へ戻る。

さらに、

左右矢印キー

A・Dキー

の両方で操作でき、画面外へ出ないようにする制御も実装された。

これによって、パンタはゲーム画面に置かれた一枚の画像から、

プレイヤーが操作できるゲームキャラクター

になった。

次はいよいよ、ゲームそのものを動かしてみる。

「森のどんぐり大作戦」は、空から落ちてくるどんぐりを、キャラクターが籠で受け止めるゲームである。

まず必要なのは、

どんぐりを空から落とすこと

である。

---

最初のどんぐりを落とす

いきなり大量のどんぐりを出現させるのではなく、最初は1個だけ落としてみることにした。

使用するのは、すでに制作してUnityへ読み込んである、

Acorn_01.png

である。

Unity AI Agentへ、

画面上部にどんぐりを1個出現させ、2D物理を使用して自然に落下させる

よう指示した。

さらに、

落下しながら回転すること

画面下へ完全に出たら削除すること

も要求した。

ただし、この段階では、

キャッチ判定も、

得点も、

連続出現も、

まだ実装しない。

まず、

「どんぐりが1個落ちる」

という最小単位だけを作る。

---

どんぐりが落ちた

Unity AI Agentによる実装が完了した。

Playする。

画面上部から、

どんぐりが1個落ちてきた。

しかも、回転しながら落下している。

そして画面下へ出ると、自動的に削除された。

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

さらに、どんぐりの表示サイズについても、こちらから具体的な数値は指定していなかった。

指示したのは、

パンタとゲーム画面に対して適切な大きさにすること

だけである。

実際に表示されたどんぐりを見ると、特に修正する必要のない大きさになっていた。

---

人間が動きを判断する

一方、実際に落下するどんぐりを見ると、少し気になるところがあった。

ゲーム画面は上下に前景の枝葉と草が配置されているため、実際にどんぐりを追いかけられる空間はそれほど広くない。

そのため、最初の落下速度では少し速く感じられた。

また、どんぐりの回転については、もう少しはっきり回転してもよいように感じた。

そこでUnity AI Agentへ、

どんぐりの大きさは変更しない

落下速度だけ少し遅くする

回転は少し強くする

よう指示した。

ここでも具体的な数値は指定していない。

AIが数値を変更し、人間が実際の画面を見て判断する。

再びPlayする。

今度は、落下速度も回転も自然に感じられた。

この状態を採用することにした。

---

「どんぐり工場」を作る

1個のどんぐりが正常に落下することが確認できた。

次は、これを連続して出現させる。

ただし、同じ場所から落ち続けるのではゲームにならない。

そこでUnity AI Agentへ、

画面上部のランダムなX位置から、一定間隔でどんぐりを1個ずつ生成し続ける

よう指示した。

すでに完成している、

どんぐりの大きさ

落下速度

回転

画面外での削除

については変更しないようにした。

AIは、どんぐりを生成するための仕組みを構築した。

Playする。

今度は、

次々とどんぐりが降ってきた。

しかも毎回同じ位置ではなく、画面上部の異なる位置から出現する。

ここで、どんぐりを継続的にゲーム画面へ供給する基本システムが完成した。

制作中、これを私たちは、

「どんぐり工場」

と呼ぶことにした。

---

実際にパンタを動かしてみる

まだキャッチ判定は実装していない。

そのため、パンタをどんぐりの下へ移動させても、どんぐりはそのまま通過して画面下へ落ちていく。

それでも、パンタを左右へ操作しながら、ランダムに落ちてくるどんぐりを追いかけてみた。

すると、一つの問題が見えてきた。

思ったより難しい。

画面の上下には枝葉と下草があり、実際にプレイヤーが認識して移動できる空間は広くない。

そこで、

パンタをもう少し小さくするか。

どんぐりの落下速度をさらに遅くするか。

ゲーム画面そのものを考え直すか。

いくつかの可能性を検討した。

しかし、ここで別の考え方が出てきた。

---

そもそも全部取る必要があるのか

「森のどんぐり大作戦」は、

落ちてくるすべてのどんぐりを取らなければならないゲームではない。

取れないどんぐりがあってもよい。

プレイヤーは、

これは取れる。

あれは間に合わない。

次のどんぐりを狙おう。

と判断しながらキャラクターを動かす。

そう考えると、すべてのどんぐりを簡単に取れるようにする必要はない。

むしろ、全部取れてしまう方がゲームとして単調になる可能性がある。

---

キャラクターによってゲームが変わる

さらに、これから実装する5人のキャラクターには、それぞれ違った特徴を持たせる予定である。

移動速度についても、

高速

標準

低速

の3段階を基本とすることにしている。

現時点では、

リン＝高速

パンタ＝標準

ポン＝低速

を想定している。

すると、同じ速度で落ちてくる同じどんぐりでも、キャラクターによって遊び方が変わる可能性がある。

リンなら、素早く走って画面の端に落ちてくるどんぐりまで追いかけられるかもしれない。

パンタなら、取れるどんぐりを判断しながら普通に追いかける。

ポンは移動が遅いため、どんぐりを追いかけるより、

「ここへ落ちてくるだろう」

と予測して待ち伏せする遊び方になるかもしれない。

そしてコンタには、移動すると少し滑るという特徴を持たせる予定である。

どんぐりを見つけて走り出したものの、

止まりたい場所で止まれない。

結果、

全然取れない。

ということも起こるかもしれない。

しかし、それも失敗ではなく、

コンタというキャラクターで遊ぶ面白さ

になる可能性がある。

---

難易度を今は決めない

そこで今回は、現時点で難易度調整を行わないことにした。

どんぐりの落下速度も、

パンタの大きさも、

出現間隔も、

ゲーム画面の構成も、

ひとまず現在の状態を維持する。

5人のキャラクターが実装された段階で、実際にそれぞれを操作してからゲーム全体のバランスを判断する。

これは、単純にゲームを「簡単にする」「難しくする」という調整ではない。

キャラクターの個性によって、同じゲームの遊び方そのものが変わる。

その可能性を残しておくためである。

---

AIがゲームシステムを作り始めた

今回、人間はどんぐりの落下スクリプトを書いていない。

2D物理コンポーネントも設定していない。

画面外へ出たどんぐりを削除する処理も書いていない。

ランダムな位置から継続的にどんぐりを生成するシステムも、人間が実装したものではない。

人間が行ったのは、

どんぐりを落としたい。

もう少しゆっくり落としたい。

もう少し回転させたい。

今度はランダムな場所から連続して落としたい。

という目的と判断を伝えることだった。

Unity AI Agentは、それをUnity上の具体的なシステムへ変換した。

前回までAIが作っていたのは、主としてキャラクターの動きだった。

今回は、

ゲーム世界そのものを動かすシステム

をAIが作り始めたことになる。

---

人間は、ますます観客になっていく

パンタが動き、

どんぐりが降ってくる。

画面を見ながらパンタを左右へ動かしていると、ゲームの形が急速に見え始めた。

そして今回も、人間がUnity上で直接行う作業は非常に少なかった。

AIへ指示を渡す。

必要に応じて操作を許可する。

Playする。

見る。

遊ぶ。

そして、

「これはいい」

「これは少し速い」

「このままで行ってみよう」

と判断する。

実装の主体がAIへ移るほど、人間はますます、

ゲームを作っている人というより、ゲームが作られていくところを見ている観客

のようになっていく。

もちろん、その観客は作品の方向を決める。

しかし、目の前でAIが次々とUnityを実装していく様子を見ると、

「人間はもう観客なのではないか」

と思えてくる。

そして、それが意外なほど楽しい。

---

今回の到達点

今回の実験によって、

どんぐり1個の生成

2D物理による落下

落下中の回転

画面外へ出たどんぐりの自動削除

落下速度と回転の調整

ランダムなX位置からの出現

一定間隔での連続生成

まで実装された。

パンタはすでにプレイヤーの操作によって左右へ動く。

その頭上から、今度はどんぐりが次々と降ってくる。

まだ、どんぐりを取ることはできない。

パンタの前を通過して、そのまま地面の下へ消えていく。

しかし、

キャラクターが動き、ゲーム世界からオブジェクトが生成される。

ここまで来たことで、「森のどんぐり大作戦」は静的なゲーム画面から、明確にゲームシステムを持つ世界へ変わり始めた。

次はいよいよ、

パンタの籠で、どんぐりを受け止める。

どんぐりが籠に入った瞬間に消える。

その瞬間、

落ちてくる
↓
追いかける
↓
キャッチする

という「森のどんぐり大作戦」の最初のゲームループが完成する。

 

どんぐり工場は、無事に稼働を開始した。 🌰

AIゲーム開発研究室

ゲーム開発ドキュメント

Unity AI Agentによるキャラクター実装

AIはゲームキャラクターを動かし、自ら問題を診断できるのか

前回の実験では、Unity AI Agentを使用して、「森のどんぐり大作戦」の背景、上部前景、下部前景、そしてパンタをUnity上へ配置した。

それまで別々の画像素材として制作してきたものが、初めて一つのゲーム画面として組み合わされた。

しかし、まだパンタは動かない。

今回は、いよいよパンタをゲームキャラクターとして動かしてみる。

ここでも基本方針は変わらない。

人間がUnityのInspectorを操作し、スクリプトを書き、Animatorを設定するのではなく、

人間と対話AIが実装内容を検討し、その指示をUnity AI Agentへ渡す。

Unity AI Agentは、その指示をもとに実際のUnityプロジェクトを構築する。

---

まず、パンタのアニメーションを作る

パンタの待機時のアクションには、すでに制作済みの3枚の画像素材がある。

Panta_Catch_Up_01.png
Panta_Catch_Up_02.png
Panta_Catch_Up_03.png

この3枚を、

01 → 02 → 03

の順番で切り替えることによって、パンタがその場で小さく動くアクションになる。

Unity AI Agentへ、この3枚からSprite Animationを作成するよう指示した。

AIはAnimation ClipとAnimator Controllerを作成し、既存のPanta GameObjectへ設定した。

Playしてみる。

パンタが動いた。

画像は、

01 → 02 → 03

の順番で正常に切り替わっている。

ところが、一つ問題があった。

---

素材にあるはずの上下動が消えた

3枚の画像素材には、パンタの上下位置そのものに差をつけてある。

つまり、Unity側でPanta GameObjectを上下させなくても、画像を順番に切り替えるだけでパンタが小さく上下して見えるように制作している。

しかし、Unity上では画像は切り替わっているものの、その上下動がほとんど見えない。

なぜなのか。

ここで人間がSprite Editorを開き、原因を調べることもできる。

しかし今回は、それをしなかった。

Unity AI Agentへ、

「アニメーションは正常に動いているが、元画像に含まれている上下動が見えない。原因を調査してほしい。ただし、まだ修正はしないこと」

と指示した。

---

Unity AI Agentが原因を調査する

Unity AI Agentは、元となった3枚のPNG画像とUnity側のSprite設定を調査した。

その結果、原因が判明した。

3枚の画像は、すべて同じ

200 × 349 pixel

のキャンバスで制作されていた。

そして元画像を調べると、パンタが描画されている位置には実際に差があった。

2枚目では1枚目より約36pixel上へ移動し、3枚目では約13pixel上へ移動している。

つまり、

元画像には確かに上下動が存在していた。

問題はUnity側にあった。

UnityへSpriteとして取り込む際、透明部分を含む共通キャンバス全体ではなく、実際にキャラクターが描画されている領域を基準として扱い、それぞれのSpriteが再び中央へ揃えられていた。

その結果、

画像素材の中に存在していた位置の差が相殺されていた。

Unity AI Agentは、ここまで自ら調査して原因を報告した。

---

AIに自分の実装を修正させる

原因が分かった。

そこで今度はUnity AI Agentへ修正を指示した。

ただし、

「2枚目を36pixel上げる」

「3枚目を13pixel上げる」

とは指示していない。

人間側から数値を与えるのではなく、

元の200×349pixelの共通キャンバスに含まれている位置情報を維持すること

を要求した。

Unity AI AgentはSpriteの設定を修正した。

再びPlayする。

今度は、

パンタが小さく上下した。

元画像に仕込まれていた動きが、Unity上でも正しく再現された。

さらに驚いたことに、アニメーション速度についても特に調整する必要がなかった。

そのままで自然な動きになっていた。

---

足元の見え方を調整する

アニメーション自体は完成した。

しかし実際に動いているパンタを見ると、足の動きの一部が下部前景の草に隠れすぎているように感じられた。

そこでUnity AI Agentへ、

着地時には足の一部が草に隠れる。しかし上へ動いたときには足の動きが見える位置

になるよう、パンタ全体のY位置を少しだけ上へ調整するよう指示した。

ここでも具体的なY座標は指定しない。

Unity AI Agentが位置を調整し、人間が実際の画面を見て判断する。

その結果、パンタが森の地面に立っている感じを残しながら、動きもよく見える位置になった。

---

プレイヤーがパンタを動かす

次に、パンタをプレイヤーが操作できるようにする。

Unity AI Agentへ、

左右矢印キー、またはA・Dキーでパンタを左右へ移動させる

よう指示した。

AIは必要なスクリプトを作成し、Panta GameObjectへ設定した。

Playする。

右へ動く。

左へ動く。

矢印キーでも、A・Dキーでも正常に操作できた。

さらに、パンタが画面外へ出ないようにする制御も実装されていた。

これによって、パンタは単なるアニメーション画像ではなく、

プレイヤーが操作するゲームキャラクター

になった。

---

キャラクターの速度を考える

パンタ単体で操作すると、最初に設定された移動速度でも問題はなかった。

しかし「森のどんぐり大作戦」では、最終的に5人のキャラクターが登場する。

そこで移動速度について、

高速

標準

低速

の3段階を基本とすることにした。

現時点では、

リン＝高速

パンタ＝標準

ポン＝低速

を予定している。

そのため、パンタの移動速度を最初の状態より少し遅くし、

ゲーム全体の標準速度

として使える操作感へ調整した。

コンタとミミについては、速度だけではなく、それぞれ別の動作特性も含めて今後検討する。

---

右を向いて動く

ここまでのパンタは、左右へ移動することはできるものの、待機用の正面アニメーションのまま横へ移動していた。

そこで次に、右移動用として制作していた、

Panta_Catch_Right_01.png
Panta_Catch_Right_02.png
Panta_Catch_Right_03.png

を使用する。

待機アニメーションで発生した問題を踏まえ、今回は最初から、

元画像の共通キャンバスに含まれる位置情報を維持すること

をUnity AI Agentへ指示した。

さらに、

停止中 → Panta_Catch_Up

右移動中 → Panta_Catch_Right

となるようAnimatorと移動制御を連携させる。

実装後にPlayすると、

右キーを押した瞬間にパンタが右向きのアクションへ切り替わり、そのまま右へ移動した。

キーを離すと停止し、正面向きの待機アクションへ戻る。

成功である。

---

左移動に新しい画像は作らない

左移動については、新しい画像素材を用意しなかった。

完成した右移動用アニメーション、

Panta_Catch_Right

をそのまま使用し、左へ移動するときだけSpriteを左右反転させる。

Unity AI Agentへその処理を指示した。

結果、

停止中 → 正面

右入力 → 右を向いて移動

左入力 → 左を向いて移動

キーを離す → 正面へ戻って待機

という一連の動作が完成した。

---

AIは実装するだけではなかった

今回、最も興味深かったのは、パンタが動いたことだけではない。

途中で、

「元画像に存在する上下動がUnity上では消えてしまう」

という、事前には想定していなかった問題が発生した。

そこで人間がUnityの設定を調べて修正したのではない。

Unity AI Agentへ問題を伝えた。

AIは、

元画像を調査し、
Unity側の設定を調査し、
両者を比較し、
原因を特定し、
その結果を人間へ報告した。

そして修正を指示すると、その問題も解決した。

つまり今回確認されたのは、

AIによる実装

だけではない。

AIによる実装結果の診断と修正

まで含まれている。

---

人間は何をしていたのか

今回、人間はC#スクリプトを書いていない。

Animator Controllerも作っていない。

SpriteのPivotも修正していない。

Transformへ移動速度の数値を入力したわけでもない。

人間が行ったのは、

動きを見る。

違和感を見つける。

どのような動きにしたいかを判断する。

AIから求められた操作許可を確認する。

完成した結果を採用するか判断する。

ということである。

実装作業のかなりの部分をAIが担当するようになると、人間の役割は、

「作る人」から「見て、判断する人」へ

少しずつ移動していく。

実際、今回の制作中、

「もう人間は観客ではないか」

と思うほど、Unity AI Agentが次々と実装を進めていった。

しかし、その「観客」は何もしない観客ではない。

どの動きがかわいいのか。

どの速度がキャラクターに合っているのか。

足がどの程度草に隠れるべきなのか。

ゲーム全体としてキャラクター間の速度差をどう設計するのか。

そうした判断は、依然として人間が行っている。

---

今回の到達点

今回の実験によって、パンタには、

待機アニメーション

左右移動

右向き移動アニメーション

左向き移動アニメーション

停止時の待機状態への復帰

矢印キー／A・Dキーによる操作

画面外への移動制限

標準キャラクターとしての移動速度

が実装された。

前回、森の中に立ったパンタが、

今回は自分で動き始めた。

そしてUnity AI Agentは、単に指示された実装を行うだけではなく、途中で発生した問題について、自らプロジェクト内部を調査し、原因を特定するところまで行った。

ここまで来ると、

「AIはUnityを操作できるのか」

という最初の問いから、研究は明らかに次の段階へ進んでいる。

次に試すのは、

ゲームシステムそのものをAIに作らせること

である。

パンタは動けるようになった。

次は――

空から、どんぐりが落ちてくる。

 

「森のどんぐり大作戦」が、いよいよゲームとして動き始める。