最初のプロトタイプまで3Dアセットを100% AI生成したゲーム、Bloom Garden
あらかじめ用意した素材はひとつも使わず、遊べる最初のプロトタイプに届くまで3Dアセットを100% PicoBerryで生成しました。 かかった期間はおよそ2週間です。そのあとにゲームシステムとUIの実装、そして最適化が続きました。その過程で実際に何が必要だったのかを、AIが解けなかった部分まで含めて整理しました。
AIで生成した3Dアセットだけで、実際のモバイルゲームを作れますか？
Bloom GardenはGoogle Playで配信中で、そこに出てくる花も小物も背景オブジェクトも、すべてPicoBerryで生成したものです。絵を描くスキルを持たない開発者が進めました。遊べる最初のプロトタイプまでは、用意した素材を一切使わずに3Dアセットを100% AIで生成しています。ここまでがおよそ2週間でした。そこから先は、もう少し具体的に答える必要があります。アセットを作ることと、ゲームを仕上げることは別の仕事だからです。UIは人のフィードバックを何度も挟まなければなりませんでしたし、シーンに繰り返し置かれるオブジェクトのポリゴンは、結局アートディレクションと最適化で解くしかない性能の問題になりました。アセットの工程は生成がかなりの部分を担います。ただしシーンの予算とUI、そして最後の仕上げは、今も人の仕事です。
Bloom Gardenはどんなゲームですか？
何もない野原を、花の商いで少しずつ育てていくガーデン経営ゲームです。
植えて、育てて、収穫する
いろいろな花を植えて育て、庭が生気を取り戻していく様子を眺めながら収穫します。
商品を作って注文をさばく
収穫した花を商品に加工して村人の注文をこなし、その報酬で次の拡張に備えます。
片づけて、直して、広げる
伸びた草を刈り、壊れた機械や建物を修理しながら、庭を蘇らせて広げていきます。
開発はどう進みましたか？
企画から配信まで、実際にたどった順に整理します。
- 開発人数
- 1名UModeler所属のゲーム開発者
- 期間
- 約4週間作業20日 · 1日8時間ほど
- プロトタイプ到達
- 約2週間生産・販売・アップグレード・クエスト・シネマティック
- 事前に用意した素材
- なし3DアセットはできるかぎりPicoBerryで生成
目標ははっきりしていました。用意した素材を使わずに、経営シミュレーションを一本最後まで作ってみることです。
では、残りの2週間は何に使ったのですか？
- 指標トラッキングの設定 — Google Playでの配信に必要な数値が実際に見えるよう、SDKをつないで設定しました。
- 60 FPSの死守 — 普及帯の端末でフレームが崩れないよう、ポリゴンとテクスチャの予算を組み直しました。
- UI/UXの詰め — アイコン・間隔・整列など、一度では決まらないものを何度も直しました。
- テスト — 実機でビルドを動かしながら、残った問題を潰していきました。
プロトタイプまでが半分で、残りの半分が配信までの作業でした。
企画とプロトタイプ
手堅いジャンルの上で、PicoBerryアセットがどこまで使えるかを試しました。
作ると決めたのは、生産 → 販売 → 収益を再投資してさらに生産 → 自動化とつながっていく経営シミュレーションです。モバイルで長く定着しているジャンルなので、すでに検証済みの面白さの上で試すのに向いていると考えました。似たゲームを調べて、コアループとシステムを参考にしています。
プロトタイプに必要なアセットは、用意したものを使わずすべてPicoBerryで調達しました。おかげで約2週間で、生産・販売・アップグレード・クエスト・シネマティックまで揃った、実際に遊べるプロトタイプに到達しています。
アセットパイプラインの構築
3Dへ直行せず、まず画像から流れを組み立てました。
すべてのモデルをPicoBerryで生成したので、序盤は流れを固めること自体が課題でした。機能に必要なオブジェクトをコンセプトに合わせてまず画像で生成し、ゲームに使えそうな見え方になるまで画像の段階で方向を詰めてから3Dへ移しています。
- 試行錯誤 — 画像1枚では形が立たないキャラクターがありました。以降はそうしたオブジェクトに限って、背面や側面の画像も一緒に作り、複数の角度を与えた状態で生成しています。
- ポリゴンの方針 — 基本は最小限に抑えて生成し、形が複雑なものだけ少し数を増やしました。
ゲーム実装とUI
システムのロジックは任せられましたが、UIは事情が違いました。
ゲームシステムとUIの実装には、コーディングAI（Claude Code）を使いました。とくにHUDはUnity UI Toolkitで作ったのですが、AIはリファレンス画像を読み取ったり、要望をUIに正確に反映したりするのが意外と苦手でした。
リファレンス画像を渡しても各要素の比率がうまく合わず、望む結果が出るまで、UI画像とフィードバックを何度も渡し直す必要がありました。ここはまだ、人が方向と要望を具体的に示さなければならない領域に見えます。
配信と外部テスト
最適化を後回しにしたつけを、終盤で払いました。
終盤で足を引っ張ったのはSDK連携と最適化です。開発中は比較的性能の良い環境でテストしていたため、PicoBerryで作った数千ポリゴン規模のメッシュが問題として表に出ていませんでした。
実機環境ではその負荷がすぐに現れ、そこへSDK連携の問題も重なって、配信と外部テストを控えた最後の局面に作業が集中してしまいました。
3Dアセットはどう作りましたか？
ゲームに入った花や小物、背景オブジェクトを生み出した繰り返しの流れです。
花の形を画像で生成
メッシュを作る前に、画像生成で花の形の候補をいくつも作って見比べます。ゲームでは花を集めて花束になるので、花と花束の形が自然につながっている必要があります。
花束の画像を生成
選んだ花の画像を参考に花束の画像を生成します。3Dへ移る前に、色と形はこの段階で確定させます。
メッシュ + テクスチャ
確定した花束の画像をPicoBerryで3Dにし、メッシュ生成とテクスチャを同時に進めます。一度で完璧を狙うより、生成・比較・選択を繰り返しました。
Unityで組み立て
アセットを取り込んで配置し、ゲームシステムにつなぎます。シーンの予算が実際に決まるのはここです。
生成したアセットは磨いて使う出発点であって、仕上がったゲームコンテンツではありません。上の小物もすべて、選別と補正を経てからシーンに居場所を得ています。
① 花の形 候補A
細い枝に小さな花が密集した形の候補。
② 花の形 候補B — 採用
輪郭のはっきりした花の形。この画像をリファレンスに選びました。
③ 花束の画像を生成
選んだ花を参考に生成した花束の画像。
④ メッシュ + テクスチャ
この画像からメッシュとテクスチャを同時に作った結果。
新しいモデルでローポリのアセットを直接生成する
プロジェクト後半に導入した新しい生成モデルは、結果の品質でも、ローポリ生成の品質でも改善が見られました。ハイポリで作ってから削るのではなく、最初から目標ポリゴン数で生成する道が開けたわけで、この事例はこのページでいちばん実用的な部分です。
このページに何度も出てくる花束が、その事例です。ゲームでもっとも頻繁に置かれる小物なので、ポリゴンの負担がとくに大きいものでした。
最初は約5,000ポリゴンで生成したモデルを、そのまま1,000ポリゴンまでリメッシュしました。ところが一度に大きく削ったせいで形が崩れ、面が破綻しました。包装紙とリボンが潰れ、花の形も鈍く固まってしまいました。
方針を変えて、ハイポリから削るのではなく、image-to-3Dの段階で最初からポリゴン数を低く設定して生成しました。結果はローポリでも形を保っていて、そのあとUModeler Xで細部を少し手直しし、ゲームで使える形に整えています。
生成を何度も繰り返しましたが、待ち時間は負担になりませんでした。1回およそ2分なので、ポリゴン設定を変えながら結果を見比べて選ぶ繰り返しが現実的に回せます。
AIでゲームを開発するときのコツは？
同じやり方を試す方が、そのまま持ち帰れる実務の勘どころをまとめました。
実際にやってみていちばん強く残った感覚はひとつでした。AIの生成物は「参考資料さえ渡せば汲み取ってくれるだろう」では望む結果になりません。スタイルと役割、構造を先に明示し、複数枚を生成して見比べ、実際に動かして検証する。この繰り返しを前提にして、はじめて使える結果が出ました。
3Dアセット生成のコツ
3Dを直接生成しません。画像が先です。
画像を先に生成し、その画像から3Dオブジェクトを作る順番です。画像のスタイルを一定に保つと、3Dの結果も似た雰囲気で出せました。だからこそ、ゲーム全体で共通に使うリファレンス画像1枚、あるいはプロンプト1行を決めておくことが効いてきます。
ハイパーカジュアルのスタイルを考えずに、ただ「機械を描いて」と頼んだところ、複雑すぎて本当に動きそうな機械が出てきました。
機械的なディテールを削り、ハイパーカジュアルのトーンに合うようプロンプトを修正。以降ほかの機械にもそのプロンプトを使い回し、動作を描かずに役割の違いだけが出るように頼んだところ、修正の回数がぐっと減りました。
テクスチャとスタイルの統一
生成モデルをひとつに固定することが、まず第一の条件でした。
- モデルを固定 複数のモデルを見比べ、作りたいスタイルにいちばん近いものをひとつ選んで最後まで使い続けました。
- リファレンス画像でばらつきを抑える 同じモデルでも結果がぶれるときはリファレンス画像で抑えました。単に「建物」「物」と言うのではなく、「このキャラクターが住みそうな建物」「このキャラクターが使いそうな物」のように、決めておいたリファレンス画像とプロンプトを組み合わせて文脈を与えるやり方です。
AIコーディングツールの使い方
数値を渡せばコードは直ります。UIはそうではありませんでした。
システム開発はほとんどAIコーディングツールで進めました。ただしメッシュをすべてAIで生成したので、最適化は必須です。
- 最適化 — うまくいったやり方 プロファイリングの結果をそのままAIツールに渡し、その数値を根拠に原因を突き止めてコードを改善させ、もう一度測って確かめる。この繰り返しです。
- UI — うまくいかなかったやり方 ゲーム内のHUDをUI Toolkitで作ったのですが、配置の比率や整列が一度では決まりませんでした。リファレンス画像とおおまかな説明を足しても望む構成にならず、何度も繰り返したり、USS・UXMLを直接直したり、間違っている箇所を自分で指摘したりすることが多くありました。
人が必ず見なければならないところ
「この程度の資料があればうまくやるだろう」が失敗でした。
- 役割と構造を先に 振り返ると、UIでの失敗はまさにそうやって任せてしまったことでした。各要素の役割と構造を先に正確に理解させてから進めるべきでした。
- 実行環境 アルゴリズム上は問題なく見えても、実際の実行環境やUnityアプリの特性によっては問題になるコードが出てきます。こうした部分は結局、テストで動かして確かめ、直していく過程が常に必要でした。
同じものをもう一度作るなら
- 開始の段階で実行性能を正確に見極め、ポリゴンとアセットの基準を立てます。 今回は正確な計測をせずに進めたため、あとからアセットを直したり、思わぬところで動作がもたついたりしました。
- 最終段階では、プロファイリングとビルドテストで最適化を十分に回します。 細かい背景オブジェクトは開発の後半でしか置けず、それまで存在しなかったオブジェクトが一気に増えたことで、負荷が遅れて表に出ました。
- 画像は1枚ずつではなく、2〜4枚まとめて出して見比べます。 AIの生成結果は一度で望むものにならないことが多く、これだけでも作業がかなり楽になりました。
AIはどこまでやり、どこで止まりましたか？
この事例で役に立つのは成功談ではなく、この境界線です。
AI生成が担えた範囲
- 専任のアート人員なしで、ゲームに使えるだけの数の小物を確保できました。絵を描くスキルのない開発者でも進められます。
- プロトタイプと外部テストビルドを、実際に遊べる状態まで持っていけました。
- 見え方を素早く試し直せました。高価なアセット1点に縛られず、複数の候補を生成して見比べ、選ぶやり方が取れます。
- 後半に導入した新しいモデルは、結果の品質でもローポリ生成の品質でも、はっきりと改善していました。
人の手が必要だった範囲
- UIのデザインと配置は、人のフィードバックを何度も挟む必要がありました。意図とリファレンス画像、ゲームの文脈が一度で正確に反映されるわけではありません。
- シーン単位の予算 — ポリゴン、影、テクスチャ、積み上がるオブジェクトは、AI生成が代わりに決めてくれるものではありません。
- ユーザーが仕上がりとして感じ取る部分では、人によるアートディレクションが必要でした。
- 性能の検討です。コーディングAIは画面に機能が出ることを優先するので、性能の設計方針は、人か別のレビュー体制が早い段階で示す必要がありました。
- ゲーム内の演出に合わせる最小限のメッシュ・テクスチャ修正は、人がUModeler Xで直接手を入れました。
ポリゴン予算から何を学びましたか？
このプロジェクトでもっとも広く応用できる教訓と、それをPicoBerryの中でどう解いたかです。
繰り返し配置は静かに掛け算になる
花束1個はポリゴンが多くても、それ単体では問題なく見えます。ところがゲームが進んで数が積み上がると、同じアセットが数十万ポリゴンを同時に描くことになります。悪くなったのはアセットではなくシーンでした。
リメッシュより「最初からローポリで生成」
ハイポリで作ってからリメッシュで削ると形が損なわれる危険が大きく、作業時間もばらつきました。決め手になったのは、PicoBerryに追加されたローポリ生成に強い新しいモデルです。これで最初から低いポリゴン数で生成すると、従来比で10分の1以下に減らしながら形を保てて、メッシュを作ってから削る道より結果が良くなりました。
小さく見えるなら軽く描いてよい
画面で小さく繰り返されるオブジェクトまで3Dの複雑さを保つ必要はありません。テクスチャによる表現や単純なメッシュ、ビルボードへの切り替えをまず比べてから、精密な版にこだわるべきです。
予算は作る前に決める
最適化が締め切り間際まで押しやられたせいで、影やテクスチャ、積み上がったオブジェクトを調整する余裕が足りませんでした。着手の時点でポリゴンと性能の予算を立て、締め切りではなく途中にプロファイリングを置くのが解です。
計測環境は普及帯のAndroid端末 Galaxy A16（解像度2340×1080）です。最適化前はシーンによって 10〜30 FPS まで落ちましたが、下の対応を経たあとは 60 FPS で安定しました。
| 対象 | 対応前 | 対応後 |
|---|---|---|
| 倉庫の花束36個 | 約400,000ポリゴン | 約18,000ポリゴン |
| バラ畑の成長・収穫（バラ25×6 = 150個） | 約750,000ポリゴン | 約75,000ポリゴン |
| テクスチャ（カラーパレットに統合） | 2048サイズを数十枚 | 512サイズを1枚 |
同じオブジェクトでも、シーンに数十・数百個が積み上がればポリゴンは掛け算で膨らみます。個々のアセットのポリゴンを減らし、複数のテクスチャをひとつのカラーパレットにまとめたところ、普及帯の端末でもフレームが安定しました。
① リメッシュで削った最初のやり方
約5,000ポリゴンのモデルを一度に1,000ポリゴンまでリメッシュしたところ、包装紙と花の形が崩れました。
② 最初からローポリで生成
image-to-3Dの段階でポリゴン数を低く設定して生成すると、ローポリでも形を保てました。
③ UModeler Xで整える
生成結果をUModeler Xで少し手直しし、ゲームで使える形に仕上げました。
エディターではどんな作業をしましたか
生成したアセットをUnityのシーンに置き、システムへつないでいく、人の手が入った工程です。
エディターでの作業
Unityエディターでタウンホール関連オブジェクトのインスペクター値を設定している作業画面です。
実際に動いている様子は？
配信中のビルドのプレイ画面です。生成したアセットがUnityでそのまま動いています。
よくある質問
Bloom Gardenはどんなゲームですか？
Google Playで配信中のガーデン経営ゲームで、開発はUModelerです。花を植えて収穫し、村人の注文に合う商品に加工しながら、伸びた草を刈り、施設を直して庭を広げていきます。3DアセットはPicoBerryで生成し、ゲーム本体はUnityで作りました。
アセット制作にPicoBerryのどの機能を使いましたか？
リファレンスの見え方を決める画像生成、その画像をもとにした3Dモデル生成、そして生成したモデルのテクスチャ作業です。プロジェクト後半には、ローポリの結果がより良い新しいモデルも併せて使いました。
ゲームのアセットをすべて作るのにクレジットはいくらかかりましたか？
合計で82,280クレジットです。ただしこの数字をそのまま見積もりに使わないでください。実際にゲームへ入った分ではなく、使わなかった候補まで全部含んだ数字です。画像514枚と3Dモデル153個を作っていて、モデル1個あたり平均3枚以上の画像を出した計算になります。このページが繰り返し勧めている「一度で完璧を狙わず、複数枚を出して見比べる」やり方のコストが、まさにこの数字です。規模感で言えば、開発者1名が1か月ほどでゲーム一本に必要な3Dアセットをすべて、サブスクリプション1か月分の範囲で賄えたことになります。初めて組むパイプラインで試行錯誤の割合が大きかったので、流れが固まったあとならもっと下がります。
AIがゲーム全体を作ったのですか？
いいえ。PicoBerryが作ったのは3Dアセットです。ゲームのシステムとUI、シーンの組み立てと性能の作業は、チームがUnityで直接行いました。生成物を仕上がったゲームコンテンツとして読むと、この事例を読み違えることになります。
このやり方を使うにはアーティストである必要がありますか？
プロトタイプやテストビルドまでなら、その必要はありません。絵を描くスキルを持たない開発者が、このやり方でゲームに使えるだけの数の小物を作りました。ただしユーザーが感じ取る仕上がりの領域では、アートディレクションが必要でした。入口の敷居を下げてくれるだけで、目利きと確認をなくしてくれるわけではない、というのが正直な答えです。
AIで生成したアセットで性能を落とさないためには？
生成したあとではなく、生成する前にポリゴン予算を決めてください。ハイポリの結果を無理にリメッシュすると形が損なわれることがあるので、目標ポリゴン数に合わせて生成するか、ローポリの品質が良いモデルを使うほうが確実です。そして繰り返し置かれるオブジェクトは、シーンの問題として扱う必要があります。画面の占有率と数量、影、テクスチャ、LODやビルボードへの切り替えを合わせて設計してください。
ハイポリのアセットをリメッシュで削ればよいのでは？
うまくいくこともありますが、このプロジェクトでは頼りにしづらいものでした。大きく削るとシルエットが損なわれる危険があり、作業時間もばらついてスケジュールに組み込みにくかったためです。最初から目標の密度で生成するほうが効率的でした。
次のプロジェクトでは何を変えますか？
着手の時点で性能とアセットの基準を決め、プロファイリングとビルドテストを締め切りではなく途中の段階に置きます。配信前の最適化とQAのために独立した時間を確保し、UIとゲームプレイのコードは画面に見える結果だけでなく、更新のコストと性能まで含めてレビューします。