AIで3Dゲームは作れる。ただしモデルとモーションだけは別の手当てがいる

私が3Dを触ったときにやったのは、大きく2つでした。コードはClaude Codeに書かせる。モデルとモーションは既成のアセットとモーション集を使う。この分け方に落ち着いたのは、途中でAIに3Dモデルを作らせてみて品質が低かったからです。見た目は「それっぽい」のに、品質としては使えるものになりませんでした。モーションも同じで、AIに作らせたものは不自然でした。

一方でコードは違いました。仕様を伝えれば動くものが出てきて、動かなければエラーが返ってきて、直せば直ります。この差は感覚の問題ではありません。後の章で見るように、コードには「コンパイルが通るか」「テストが通るか」という機械的な合否判定があり、3Dモデルとモーションにはそれが無いからです。GDC 2026 State of the Game Industry(2,300人超が回答)では、生成AIを業務で使っていると答えたのは36%で、用途の上位はリサーチ・ブレインストーミングが81%、日常業務が47%、コード補助が47%、プロトタイピングが35%でした。最終的なアセット制作は上位に並んでいません。私の実感は、私ひとりの偏りではないようです。

だからこの記事の主張はこうです。AIで3Dゲームは作れます。ただしモデルとモーションだけは「AIに作らせる」のをやめて、「調達して規格を合わせる」に切り替えたほうが早い。ひとつ条件を先に書いておきます。この手当てが素直に効くのは人型のキャラクターです。動物やモンスターを主役にするなら、後述する自動リギングもUnityのHumanoidリターゲットも外れるので、手動リギングという工程が残ります。

2Dの弾幕回避ゲーム『HITLESS』をSteamで出したときは、この問題に当たりませんでした。そもそも3Dのモデルとモーションという工程が無かったからです。2Dでは生成物がそのまま最終成果物になりうるのに対し、3Dは事情が違います。以降では、その違いの正体と、埋め方を順に書いていきます。なお本記事の情報は2026年9月時点のもので、料金体系や無料枠の条件は特に変動が速い領域です。エンジンは特定の1本に絞らず、選び方として扱います。

まず、AIが実際に戦力になっている範囲を確認します。コードは筆頭です。Anthropicの公式ページはClaude Codeを、複数ファイルの編集、テストの実行、数時間規模のリファクタや移行、リポジトリをまたいだimportの追跡ができるエージェントとして説明しています。ゲーム開発に特化した機能があるわけではありませんが、ゲームのコードもコードです。私がやったのもこれで、サイト構築をAIエージェントに任せた話や、Claude Codeの自動モード設定と地続きの作業でした。

エンジン側もAIの受け入れ口を作っています。ただし提供元と成熟度はバラバラなので、2026年9月時点の状況を書き分けます。Unityはエンジン一次提供で、Unity 6.0以降にAI Assistant・AI Gateway・MCPサーバーが入りました。外部のAIエージェントをエディタにつなぐAI GatewayとMCPサーバーはUnityのクレジットを消費しません。ただしこれは「Unity側で追加課金が発生しない」という意味であって、自分が契約しているAIサービスの費用は別途かかります。エディタ内のAI Assistantは試用期間のあと有料で、公式自身が「オープンベータであり、機能・挙動・提供可否は予告なく変更されうる」と明記しています。Unreal Engine 5.8には公式の実験的MCPプラグインが入りましたが、こちらも公式が「多くの機能が未完成または欠落しており、APIとデータ形式は随時変更される」と書いています。Godotにはエンジン公式のMCPが無く、使われているのはコミュニティ製のアドオンです。

シェーダーやレベル設計も研究レベルでは動いています。音声合成や楽曲生成も、生成物がそのまま最終成果物になります。これらに共通しているのは、出力が「テキスト」か「ピクセル/波形」で完結していることです。コードはコンパイルできる。シェーダーは適用して目で見られる。音は聴けば判断できる。つまり検証ループが回る。AIは間違えますが、間違いがすぐ跳ね返ってくる領域なら、その間違いは修正できます。3Dモデルとモーションだけ、このループが回りません。

理由の第一は、3Dモデルの出力が「見た目」ではなく「構造化された制約の束」だからです。Tencentの研究チームによるHunyuan3D Studioの論文は、ゲームエンジン向けアセットの要件として、頂点数が低いこと、変形を考慮した整ったエッジフロー、テクセル密度の要件を満たすUV分割、ジョイント配置とボーン階層の推定、頂点ウェイトの算出を挙げています。そのうえで序論と第6節の本文で、拡散モデル由来の高精細ジオメトリは「大量の汚い三角形」から成り、下流工程にそのまま使うのは難しいと述べ、既存の手法の多くはパイプラインの孤立した一部しか扱っていないと指摘しています。AIを作っている側の研究者が、見た目は作れてもgame-readyにはならないと認めている構図です。

しかもこの要件は感覚ではなく数値で決まっています。Unityでヒューマノイドとして認識されるには最低15ボーンが必要で、Avatarを作るにはキャラクターがT-poseである必要があります。ソフトバインド時の1頂点あたりの影響ボーン数は4が既定の上限です。Unrealでは標準で4または8、ソースデータの格納方式の都合で実質12が上限になります。glTF 2.0では、1セットあたり1頂点に影響するジョイントは4つまでと仕様で決まっていて、ウェイトの合計が1.0からズレると、その差がジョイント位置に乗って頂点が意図せず動いたり伸び縮みしたりします。AIが「だいたい正しい」メッシュを出しても、この離散的な合格ラインを外すと再生時に破綻します。Unity公式が、自動スキニングを助けるために穴を塞ぎ、頂点を溶接し、見えない面を削除せよと書いているのも同じ話です。AI生成メッシュがいちばん苦手なのが、まさにこの掃除です。

第二の理由は学習データの桁です。2023年に公開されたObjaverse-XLで1,000万オブジェクト。当時最大級の3Dデータセットです。同論文自身が、自然言語処理や2D画像が学習データの拡大で進歩した一方、3Dビジョンは同じ進歩を遂げていない、その一因は高品質な3Dデータ取得の難しさにあると述べています。モーションはさらに厳しく、2019年に公開された代表的なデータセットAMASSは40時間超のモーション、300人超の被験者、11,000以上のモーションという規模です。画像データセットの規模とは桁が違います。AMASSの論文も、既存のmocapデータセットは小さく動きも限定的で、人の動きのモデルを学習する進歩を妨げていると明言しています。その後もデータは増えていますが、画像との桁の差は埋まっていません。

第三に、モーション生成は物理制約を明示的に持ちません。Morphの論文は、現在の多くのモーション生成手法が物理制約を無視しており、浮き(floating)やフットスライドといった目立つアーティファクトを伴う物理的にありえないモーションをしばしば生じる、と述べています。足が地面を滑る、接地しているはずの足が浮く。私が「不自然」と感じたものの正体は、たいていこれです。ただし公平に書いておくと、この壁は今まさに各社が潰しにかかっている場所でもあります。2026年9月21日、TripoがモデルP2.0をリリースし、ネイティブなクアッドトポロジーの生成への対応を発表しました。同社チーフサイエンティストのYanpei Cao氏は、トポロジーこそがAI生成3Dと実制作の間の壁だった、と述べています。「AIは3Dモデルを作れない」のではなく、「AIの出力をそのまま載せる工程が長く壁になっていて、今それが崩されつつある」というのが2026年9月の正確な現在地です。

いちばん安全で速いのは、ライセンスが明快な無料アセットから入ることです。Kenneyのゲームアセットはすべてパブリックドメイン(CC0)で配布されていて、商用プロジェクトでも制限なく使えます。クレジット表記も不要です(任意で記載してもかまいません)。ただしKenneyのロゴ自体は使えません。ライセンス文書を読む時間すら惜しいなら、まずここから触るのが合理的です。背景・小物・ライティングを一気に揃えたいなら、CC0でHDRIとテクスチャと3Dモデルを配っているPoly Havenも定番ですが、こちらはリグ付きのキャラクターを扱っていないので、キャラは別で調達することになります。

ローポリでスタイライズされたモデルを幅広く配っているQuaterniusは、2026年8月に重要な変更がありました。これまでのCC0をやめ、独自のQuaternius Asset License v1.0に移行しています。個人・教育・商用のプロジェクトで無料利用でき、クレジット表記も不要という使い勝手は変わりませんが、知的財産権はQuaternius側が保持し、アセットを単体で抽出して再パッケージ・再配布・販売することは禁止されました。同ライセンスの規定により、取得した時点で有効だったライセンス版が適用され、変更は遡及しません。ネット上のまとめ記事の多くがまだ「CC0」と書いているので、いま取得するものについては必ず公式のライセンスページを見てください。キャラクターパックの多くにリグ済み・リターゲット可能のタグが付いていて、キャラクターパック横断で使えるUniversal Animation Libraryも用意されている点は、モーション側の悩みも同時に軽くしてくれます。

日本の個人開発者にとって現実的な選択肢がVRoid Studioです。無料で使えて、作ったモデルはVRM形式で書き出せます。公式FAQは、特別な利用条件が表示される場合を除き、個人・法人を問わずモデルデータの販売および商用利用が可能としていて、用途としてゲームやアプリケーションを明示的に挙げています。ただし重大な落とし穴が1つあります。VRoid Studio内で作られたメッシュやテクスチャを変形・結合して構成されるモデルやアイテムを「生成または出力できるアプリケーション」を作ることは、公式FAQで明確に禁止されています。完成したキャラクターをゲームに出すのは問題ありませんが、プレイヤーがゲーム内でVRoid由来のパーツを組み替えられるキャラクリ機能を実装しようとすると、ここに直撃します(そのプログラムを自分だけが使う場合は適用されません)。

そのうえでAIの3D生成ツールです。以下は2026年9月時点の条件で、ここは各社とも変更が速い領域です。Meshyは無料プランがあり、生成物はCC BY 4.0で提供されます。つまり無料でも商用利用は可能で、条件はMeshyへのクレジット表記です。公式は「Model created with Meshy – CC BY 4.0 License」のような表記例を示しています。表記を外したい場合は有料プランで、そちらでは生成物を自分が所有し、配布・販売の権利を持ち、帰属表示は不要になります。一方Tripoは、無料プランの生成物が公開扱いかつ非商用とされています。同じ「無料枠あり」でも条件は真逆です。ただしTripo側は公式ページと規約で記述が揃っていないという指摘もあるので、使う前に必ず自分で公式を確認してください。

AI生成を選んだ場合、生成した直後にもう一工程あります。AI生成メッシュの典型的な問題として公式チュートリアルが挙げているのは、ポリゴン密度が不均一で関節を曲げたときに変形が崩れること、UVのシームが予測不能でテクスチャが伸びること、最適化されていない高密度メッシュがシーンを重くすることの3点です。そこでリトポロジーを通します。MeshyのRemeshは目標ポリゴン数を指定でき、クアッド主体か三角形かを選べて、Meshy外で作ったGLB/OBJ/FBX/STLにもブラウザ上で適用できます。そのうえで、公式チュートリアル自身が推奨しているのは「まず自動リトポ、変形がシビアな箇所だけ手作業」というハイブリッドです。前章で挙げた穴埋め・頂点の溶接・不可視面の削除は、無料のBlenderでできます。ここまでを工程として見込んでおけば、AI生成も選択肢になります。

ローカルで動かすオープンモデルもあります。ただし「ライセンス料が無料」と「タダで動く」は別物です。Hunyuan3D-2.1は形状生成に10GB、テクスチャ生成に21GB、合計で29GBのVRAMを要求します。しかもライセンスはApache 2.0ではなく独自のTencent Hunyuan 3D 2.1 Community License Agreementで、EU・英国・韓国は対象地域から除外され、月間アクティブユーザーが100万を超える場合は別途許諾が必要です。MITライセンスのTRELLIS.2は最低24GBのGPUメモリとLinux環境が前提で、テキストからの生成には対応せず画像→3D専用です。8GBから16GBのGPUでWindowsを使っている個人開発者にとっては、現実的な選択肢とは言いにくいのが正直なところです。解説記事の「オープンソース」という表現を鵜呑みにせず、リポジトリのLICENSEファイルを直接読むのが確実です。

最後に決め方を書きます。迷ったら、リグ済み・リターゲット可能なキャラクターが無料・商用可・クレジット表記不要で揃うQuaterniusから入ってください。日本語圏の見た目が要るならVRoid Studio。背景と小物はPoly Haven。ここで足りない固有のモデルだけをAI生成に回す、という順番が最短です。分岐条件はひとつだけで、キャラクターの見た目そのものが企画の核である場合は、調達では足りません。そのときは有償パックか外注を検討してください。

モーションの調達には大きく3つのルートがあり、先に位置づけを宣言しておきます。既成のモーション集が土台、動画からのモーキャプが差分、物理ベースのツールが仕上げです。まず土台から。私が使ったのもこの既成のモーション集という手段でした。どのサービスかにかかわらず、この手段が一番早かった、というのが実感です。以下は、いま無料で選べる調達先を調べ直したものです。

調べた範囲で無料の定番はAdobeのMixamoで、Adobe IDがあれば無料で使え、Creative Cloudの契約は要りません。公式FAQは、キャラクターもアニメーションも個人・商用・非営利のプロジェクトでロイヤリティフリーに使えるとしていて、ビデオゲーム制作を明示的に挙げています。ただし注意点が3つあります。自動リギングは二足歩行の人型専用で、動物や乗り物には対応しません。Enterprise IDとFederated IDでは利用できず、国コードが中国のユーザーも使えません。そして最大の懸念として、この公式FAQページには「Last updated on Sep 14, 2021」と表示されていて、約5年更新されていません。2025年6月中旬にはログイン・アップロード・ダウンロードが壊れたという報告が公式コミュニティに複数立ちました。サービス終了の公式発表は2026年9月時点で確認できませんが、パイプラインの前提に据えるのは危険です。公式FAQ自身がリグ付きキャラのローカル保存を推奨しているので、使うなら必ず落として手元に保管してください。代替は具体名で決めておきます。リグ済みキャラごと差し替えるならQuaterniusのUniversal Animation Library、Unrealを使うなら後述のFab公式サンプル、固有の動きが要るなら後述のRokokoです。

エンジンが公式に配っているものも見逃せません。Unreal Engineの「Game Animation Sample Project」はUE 5.8に完全対応した最新版が2026年8月に公開され、500点を超えるゲーム対応アニメーションを含みます。配布はFab経由で無料です。しかも眺めるだけではなく、Animation SequenceアセットをMigrateで他プロジェクトに書き出したり、Exportでプロジェクト外に保存したりできます。自分のキャラクターに使う場合は、IK RigアセットとIK Rig Retargeterアセットを作ってリターゲットする手順が公式ドキュメントに載っています。Unity側にもUnity Technologies公式の無料パッケージ「First Person + Third Person | Character Controllers」があり、2026年9月にも更新されています。こちらは歩行・走行などの基本動作が入ったプロトタイプ用という位置づけです。Unrealは公式無料パックが500点超と数を明示しているのに対し、Unity公式パッケージは収録数が公開されていないので、数では比較できません。

2つ目が動画からのモーションキャプチャです。Rokokoの動画モーキャプはVision 3.0世代でWebカメラのライブキャプチャとデュアルカメラ撮影が廃止され、動画ファイルをアップロードする単一動画ワークフローに一本化されました。古い解説記事の内容はもう通りません。2026年9月時点で、無料のStarterプランでも動画処理が月30秒ほど使えて、しかもFBXで書き出せます。ただし月30秒は数カットぶんなので、モーションの主軸ではなく「既成のモーション集に無い固有の動きを数カット足す」用途と考えてください。量が要るなら有料に上げるか、既成のモーション集側で賄うことになります。公式FAQには、Text-to-MotionとVideo-to-Motionで生成したデータはすべて商用利用可能と明記されています。ただしこれはFAQの記載であって利用規約本文ではないので、商用前提で使うなら公式の利用規約を自分で確認してください。書き出しのスケルトンプリセットにMixamoが含まれているので、Mixamoでリグ付けしたキャラにそのまま載せる導線が作れます。比較が効くのはここで、DeepMotionのAnimate 3Dは無料プランが個人利用・非商用に限定されていて、公式に「ライセンスされたアニメーションを得るにはプレミアムのサブスクリプションプランが必要」と書かれています。無料で作れても、そのままゲームに載せられるとは限りません。

3つ目が物理ベースのアニメーションツールです。Cascadeurは物理的な補正やAI補間でポーズ付けを助けるツールですが、2026年9月時点の無料版の条件は必ず確認してください。無料プランは非商用利用のみで、書き出しは独自の.casc形式だけです。.fbxと.daeは使えません。さらに1シーンあたり300フレーム・120ジョイントの制限があります。つまり無料版の成果物はそもそもゲームエンジンに持ち込めません。商用利用は収益条件付きのIndie以上で、書き出し形式もそこから広がります。そして肝心のAutoposingとリターゲット機能はPro以上でないと使えません。ただし回避策はあります。リターゲットがPro限定でも、Indieで書き出したFBXをBlender・Unity・Unrealのリターゲット機能に通せば別キャラに載せられます。有料のリターゲット機能を買わなくても、次章の無料の標準機能で足ります。なお将来の話としては、2026年2月18日にEpic GamesがMeshcapade(マックス・プランク知能システム研究所発、SMPLベースで動画から3Dアバターを生成)を買収しました。技術はMetaHumanやUnreal Engineへの統合が見込まれていますが、時期や形は2026年9月時点で未発表です。

決め方はこうです。まず既成のモーション集で骨格を固めます。Unrealを使うならFabのGame Animation Sample、それ以外ならQuaterniusかMixamo。次に、そこに無い固有の動きだけを動画モーキャプで足します。物理ベースのツールは最後です。この順番を守れば、無料の範囲でもモーションは形になります。

調達したモデルとモーションをエンジンに載せる段階が、いちばん事故が起きます。中間フォーマットとして広く使われるglTF 2.0は、Khronos Groupのロイヤリティフリー仕様で、2022年にISO/IEC 12113:2022として国際標準化されました。座標系は右手系・+Yが上・+Zが前で、アセットの正面は+Zを向きます。ここで重要なのは、仕様自身が「glTFはオーサリングフォーマットではない」「ランタイム効率を保つため3Dオーサリング情報を意図的に保持しない」と明記していることです。制作の中間ハブにするものではなく、最終的な配信形式だと理解しておくと、後の混乱が減ります。もう一方の定番であるFBXはAutodeskの独自フォーマットで、仕様が完全には公開されていません。

エンジンごとの事情はかなり違います。UnityではglTFast(com.unity.cloud.gltfast)が公式パッケージとして提供され、Built-in・URP・HDRPのすべてに対応します。ただし公式の既知の制約として、アニメーションクリップはMecanim互換でインポートできるものの割り当てはされず、追加の作業なしには再生できないと明記されています。これは実務上かなり効く落とし穴です。素直な運用は「キャラクターはFBXで入れる、背景や小物はGLBで入れる」という使い分けになります。GodotはglTF 2.0を推奨フォーマットとしていて、4.3以降はFBXも内蔵のufbxライブラリで読み込まれるため、外部コンバータのダウンロードは不要になりました。OBJはピボット・スケルトン・アニメーション・UV2・PBRマテリアルに対応しないので、AI生成モデルがOBJで出てきた場合はアニメーションが載りません。.blendの直接インポートはBlender本体のインストールが前提で、Android版とWeb版のエディタでは使えません。なおGodotには、ノード名のサフィックス(-colで三角形メッシュの静的コリジョン、-convcolで凸形状、-colonlyで見た目を消してコリジョンだけ、-navmeshでナビゲーションメッシュ、-rigidでRigidBody)でインポート時の挙動を指定できる仕組みがあり、モデル側の命名だけでコリジョン設定の手作業がほぼ消えます。サフィックスは - / $ / _ のいずれでも使え、大文字小文字は区別されません。

リグの吸収も各エンジンが手段を持っています。UnrealのIK Retargeterは、ボーン数・ボーン名・ボーンの向きが異なるスケルトン間でアニメーションを転送でき、必要ならIKで手足の接地点を維持できます。リターゲットチェーンを開始ボーンと終了ボーンで定義するので、間のボーン数が違っても成立します。チェーン名の候補にはTailやTentacleが並んでいるので、尻尾のようなチェーンも定義できます。pelvisボーンを指定すればルートモーションを比例転送できますし、AポーズとTポーズのようにレストポーズが食い違う場合はカスタムのリターゲットポーズで解消します。Unityのリターゲティングは、各モデルのAnimation TypeをHumanoidにしてAvatarを設定すれば、骨の作り直しやリネームなしに同じアニメーションを別モデルへ適用できます。ただしHumanoid Avatarという仕組みが前提なので、人型でないキャラクターは別の手段が必要です。四足などはAnimation TypeをGenericにしてRoot nodeを指定することになります。GodotではSkeletonProfileHumanoidとBoneMapでボーンを対応付け、Rest FixerのOverwrite Axisでレストポーズの軸を統一します。公式はこれをGodot 4でアニメーションを共有するうえで最も重要なオプションとしつつ、外部で設定されたBone Restが重要な場合はひどい結果になりうるとも警告しています。

ここが本題です。「モデルはAで調達、モーションはBで調達」としたとき、最初に詰まるのはAとBのリグが揃っていないことです。AI生成ツールの自動リグが作るボーン階層と、既成モーション集のヒューマノイドリグは、ボーン名も親子関係も一致しません。スケッチから3Dキャラを作る工程を検証した記事(zenn.dev/hibari_inc/articles/sketch_to_3d)では、MeshyのAutoRigが生成したボーン階層とMixamoのHumanoidリグでボーン名・親子関係が異なり、Unityのアニメーションリターゲティングが正しく機能しなかったと報告されています。同じ検証では、非人型キャラの自動リギングが「Pose estimation failed」で失敗し、Blenderでの手動スケルトン入力が必要だったとも書かれています。ここで効くのが、いま挙げた3つのリターゲット機能です。UnityならRigタブをHumanoidにしてAvatarを作り直す。UnrealならIK RigとIK Retargeterでチェーンを手動で対応付ける。GodotならBoneMapで対応付ける。これらは「別々の場所から来たリグの不一致を吸収するための道具」であって、飾りではありません。ここを通す前提で計画してください。

ではエンジンをどう選ぶか。私はまだ決めていませんが、選び方の軸は書けます。第一に、モーション資産の厚みで選ぶ。公式無料パックが500点超と数を明示しているUnrealは、ここでは確度が高いです。第二に、AIエージェントとの相性で選ぶ。Godotはシーンファイル .tscn がほぼ人間が読めるテキスト形式で、バージョン管理システムで扱いやすいと公式が説明しています。Unityもアセットのシリアライズが既定でForce Text(YAML)なので、エージェントが差分を読めます。第三に、日本語での調達経路で選ぶ。VRoidで作ったVRMをUnityに持ち込む導線は、UniVRM(MITライセンス)が整えています。Godotにもコミュニティ実装のVRMインポータがあります。第四に、Blenderを中間ハブとして挟めるか。Blender公式の拡張機能サイトには無料のリターゲットアドオン(GPL v3)があり、Mixamo・Unreal・VRoid・MMD・Daz・Auto-Rig Pro向けのプリセットを備えています。この記事で挙げた調達手段とそのままつながる導線です。ただしBlender 5.0以降専用(2026年9月時点の現行版は5.2 LTS)なので、4.x系を使っているなら使えません。同じくMixamo用の一括インポートアドオンも対応上限が5.0で、現行の5.2では公式に非対応です。

コードはAIが得意な領域だと書きましたが、3D特有の詰まり方はあります。まず回転です。Unityは左手系で、+xが右、+yが上、+zが前です。回転は内部的にクォータニオンで保持されていて、公式はその理由を、クォータニオン回転は計算が効率的で安定しているからだと説明しています。ここでAIエージェントが書きがちなのが、オイラー角の1軸だけをその場で読み書きして代入し直すコードです。Unity公式のスクリプトリファレンスは、eulerAnglesの軸を個別に設定してはいけない(公式の例示は eulerAngles.x = 10;)、ドリフトや意図しない回転を招く、と明確に禁じています。読み返した値は代入した値とかなり異なる場合があるとも書かれています。回転を徐々に加算する用途では、別のVector3変数に値を保持してまとめて適用するのが公式の推奨です。

次に物理です。Unity公式はRigidbodyについて、Transformプロパティの代わりにシミュレートされた力とトルクでGameObjectを動かし、結果は物理エンジンに計算させることを推奨しています。Is Kinematicを有効にすると力では動かせなくなり、Transform経由でのみ移動・回転します。AIに「キャラを前に動かして」と頼むと、Rigidbodyが付いているのにtransform.positionを直接書き換えるコードが出てくることがあります。動いているように見えて、当たり判定がすり抜けたりジッタが出たりします。Godotでも同じ論点があり、_process()は描画フレームごとに可変で呼ばれ、_physics_process()は既定で毎秒60回の固定間隔で呼ばれます。公式は、ゲーム世界と衝突するキャラクターの移動など各物理ステップの前に必ず起きなければならない計算には後者を使えとしていて、移動速度には必ずdeltaを掛けるべきだと明記しています。

3つ目がアニメーションのステート管理です。ここは「AIにコードを書かせる」という発想がそもそも噛み合いません。UnityのAnimator ControllerはMecanimのステートマシンで、公式はこれをノードと接続線からなるフローチャートに似たグラフだと説明しています。GodotのAnimationTreeも自前でアニメーションを持たず、AnimationPlayerのアニメーションを参照するグラフです。遷移タイプはImmediate・Sync・At Endの3種で、遷移条件はAdvance ConditionやAdvance Expressionで書きます。つまりロジックの実体はコードファイルではなくアセットの中にあります。救いは、Unityのアセットシリアライズが既定でForce Text、つまりYAMLなので、.controllerや.prefabの差分をエージェントが読めることです。ただし手書きでの直接編集は壊しやすいので、読ませるのは良くても書かせるのは慎重にしてください。

最後にパフォーマンスです。Unity公式のプログラミングベストプラクティスは、GetComponentのような重い処理をUpdateから繰り返し呼ばず、Awakeで取得して参照をキャッシュすることを推奨しています。またフレームごとのメモリ確保を最も重要なパフォーマンスリスクのひとつとし、リストの再利用、非確保版APIの使用、UpdateなどのホットパスでのLINQ回避、文字列連結の繰り返し回避を挙げています。AIは動くコードを書きますが、毎フレームの確保を避けるような配慮は明示的に指示しないと入りません。キャラクターまわりでは、FBXインポーターのRigタブでOptimize Game Objectsを有効にするとTransform階層がAvatar内部に格納され、パフォーマンスが向上します。外部から参照したいボーンだけExtra Transforms to Exposeで個別に公開します。この手の「エンジン側の設定で解決する話」は、コードをいくら磨いても出てこないので、人間側が知っておく必要があります。

個人開発で見落とされがちなのが、ストアへの申告です。2026年9月時点のSteamworks公式のコンテンツサーベイは、AI生成コンテンツを2つに分けて申告させます。ひとつがPre-Generated Content、つまり開発中にAIツールの助けで作られ、ゲームに同梱されてプレイヤーが消費するコンテンツ。もうひとつがLive-Generated Content、ゲーム実行中にAIツールの助けで作られるコンテンツです。後者については、違法なコンテンツを生成させないためのガードレールの内容も追加で申告する必要があります。そしてValveは同じドキュメントで、多くの現代的な開発環境にAI搭載ツールが組み込まれていることは承知しており、これらのツールによる効率化はこのセクションの対象ではない、と明記しています。

この線引きは個人開発者にとって非常に実用的です。Claude Codeにコードを書かせること自体は、出力がプレイヤーに直接届くアセットではないので申告の対象外と読めます。一方、AI 3D生成ツールで作ったモデルやテクスチャ、AI生成の音をゲームに同梱するなら申告対象です。注意点が3つあります。ひとつ、対象はゲーム内アセットだけではなく、ストアページのマーケティング素材やコミュニティページの素材も含まれます。個人開発者ほどストア用のスクリーンショットやトレーラーをAIで作りがちなので、ここは見落とさないでください。ふたつ、製品内でプレイヤーに提示されていないコンテンツでも、AIで作ったものは申告が必要だと公式は書いています。試しに作って没にしたAIモデルをプロジェクトに残したまま提出するケースは踏みやすいところです。みっつ、申告内容はストアページ上で購入前に見える形になり、Valveはリリース前審査でAI生成コンテンツを非AIコンテンツと同じ基準で評価し、ゲームが開示どおりかも確認します。なおValveは現時点ではLive-Generatedの成人向け性的コンテンツを配信したくないという方針も示しています。ポリシーは改定されるので、提出前に必ず自分の目でサーベイ画面を確認してください。

他のプラットフォームは論点が違います。Google Playの生成AIポリシーは、生成AIが中心機能となるアプリを対象としていて、事前生成のアセットを同梱しただけのゲームは明示的には対象に挙げられていません。ただしPlay Console側には別途、ストアリスティングやプロモーション素材について個別にAI生成を申告する仕組みがあり、申告されたアセットにはストア上でAIラベルが付きます。App Storeの審査ガイドラインには、Steamのようなアセット開示義務は見当たりません。代わりに5.1.2(i)で、個人データが第三者(third-party AIを含む)と共有される場所を明確に開示し、事前に明示的な許可を得ることが求められています。つまりAppleが見ているのは生成物の同梱ではなく、ランタイムのデータ送信です。iOSアプリを出したときに通った審査とは別の論点なので、AI機能をアプリ内に入れる場合は改めて読む価値があります。

ライセンスの帰属表示も忘れずに。無料枠でCC BY 4.0のAI生成モデルを使うなら、クレジット表記が商用利用の条件です。公式が示す表記例をそのまま使うのが確実です。無料アセットサイトのCCライセンスは混在しているので、NC系は商用不可、ND系は改変不可でリトポロジーもリスケールも改変にあたるためゲーム用途では実質使えない、という2点だけは押さえてください。そして名指しで書いておきます。Unity Asset StoreのEULAは、アセットを「電子アプリケーションまたはデジタルメディアへの組み込み部品」としてライセンスしており(2.2.1(a))、抽出して他のゲームエンジンや開発プラットフォームで使うことはできません。Unityで買ったアセットでUnrealやGodotのゲームは作れない、ということです。同じ条項では、アセットが成果物の実質的な大部分を構成してはならないとも定められています。「素材を買ったから自由に使える」ではありません。

最後に、AI利用の開示が売上に与える影響について。2025年1〜10月にSteamでリリースされた9,879本を分析した調査では、開発者経験・パブリッシャー・ジャンル・リリース時期を統制したうえでも、AI利用を開示したゲームはレビュー数が約53%少なかったと報告されています。ただし同じ調査の感度分析では、マーケティング予算のない未経験の開発者では、売上への悪影響がほとんど見られませんでした。数字だけ切り取ると悲観的になりますが、実態はもう少し込み入っています。逆に、生成AIを一切使っていないのにAI使用を疑われて低評価を受けたスタジオもあり、開発の実態を自ら公開して反論した結果、レビューが好転した例もあります。使った所と使っていない所を自分から明示することは、規約対応であると同時に、自分の作品を守る手段でもあります。

整理します。AIは、検証ループが回る領域では実戦で使えます。コードはコンパイルとテストで合否が出ます。シェーダーは適用して見られます。音は聴けば判断できます。ここはClaude Codeのようなエージェントに任せて、人間はレビューに回るのが速いです。私が実際にやったのもこの分担でした。

一方で3Dモデルとモーションは、出力が構造化された制約の束です。最低15ボーン、T-pose、影響ボーン数の上限、ウェイトの合計、UVの分割。これらは感覚ではなく数値で合否が決まります。学習データも桁が足りず、モーションには物理制約が入っていません。だから浮きも足滑りも出ます。AI 3D生成ツールを作っている側の研究者自身が、見た目は作れてもgame-readyにはならないと書いています。この壁は今まさに崩されつつありますが、2026年9月時点では、まだ人間が調達と規格合わせをする前提で計画を立てるのが現実的です。

埋め方はこうです。モデルはライセンスが明快な無料アセットから入り、足りない分をAI生成で補い、無料枠の商用可否と帰属表示の要否を必ず公式で確認する。AI生成を選んだらリトポロジーと掃除の工程を見込んでおく。モーションは既成のモーション集を軸に、動画モーキャプで足りない動きを足し、エンジン側のリターゲット機能で自分のキャラに載せる。接続部では、別々の場所から来たリグはボーン名も親子関係も揃っていないことを前提にし、キャラはFBX、背景や小物はGLBという使い分けを基本にする。OBJにアニメーションが載らないことも覚えておく。コードはAIに書かせつつ、回転・物理・アニメーションステート・毎フレームの確保という4か所だけは人間が目を光らせる。公開前にはストアの申告とライセンスの帰属表示を通す。

この順番で進めれば、3Dのゲームは個人でも十分に開発できます。ただし冒頭に書いた条件をもう一度だけ。素直に効くのは人型のキャラクターです。動物やモンスターを主役にするなら、自動リギングもHumanoidリターゲットも外れるので、手動リギングという工程が残ります。そこを織り込んだうえでなら、AIに全部やらせようとせず、得意なところだけ任せて、苦手な2か所を別ツールで補えばいい。それだけの話です。なお本記事の料金体系・無料枠・サービスの提供状況は2026年9月時点のもので、この領域はどれも変更が速いです。実際に手を動かす前に、必ず各公式ページで最新の条件を確認してください。