[!IMPORTANT]
この記事は AI（Antigravity / Gemini）によって執筆され、Qiita API を通じて自動投稿されたものです。

個人開発中のRPG（Lost Historia）で、AIを使って**「1枚の静止画イラストから、部位ごとに自動で切り抜き、背後を自動補完し、Spineでヌルヌル動かす」**という完全自動化パイプラインを構築しようとしました。

結論から言うと、**この試みは失敗（開発凍結）**に終わりました。
しかし、その過程で得られた知見と、「なぜ2Dのまま処理するのを諦めて、3Dモデル化に方針転換したのか」というプロセスが面白かったので、記録として残します。

1. 当初の目標：2Dアニメーションの完全自動化

ゲーム開発において、敵キャラクターを魅力的に見せるためにはアニメーションが不可欠です。しかし、個人開発で何十体ものキャラクターを部位ごとに手作業で切り分け、背後を描き足し、Spineでセットアップするのは途方もない作業量になります。

そこで、昨今の強力な生成AIやセグメンテーションモデルを組み合わせて、この工程を全自動化するパイプラインを構築しました。

構築したパイプラインの構成

VLMによる部位計画 (GPT-4o / Qwen-VLなど)
- 画像を解析させ、「頭」「胴体」「右腕」「左腕」「武器」などのパーツ構成と、それらを抽出するためのテキストプロンプト（例: green goblin torso）を自動生成。

Grounding DINOによる矩形検出
- VLMが生成したテキストプロンプトを元に、画像内のどこにそのパーツがあるかをバウンディングボックス（矩形）で検出します。

SAM3 (Segment Anything Model 3) によるピクセル単位の切り抜き
- 矩形情報をヒントに、対象パーツのピクセルレベルの高精度なマスクを生成します。

LaMaによる背後領域の自動補完 (Inpaint)
- 手前のパーツ（例えば右腕）を切り抜いた後、その後ろに隠れている胴体の領域をAIで自動的に描き足す。
Spine用JSONの出力
- 切り抜いた各パーツ画像と、重ね順（Z-order）を含んだ構成をそのままSpineへインポート可能な形式で出力。

一見すると、これで完璧に自動化できそうに思えました。実際、スクリプトはエラーなく完走し、パーツごとの画像が出力されるところまでは到達しました。

2. なぜ失敗したのか？直面した「3つの構造的限界」

パイプライン自体は技術的に動作しましたが、出てきた結果をゲームに組み込もうとしたとき、**「2D画像を2Dのまま分割・推論することの構造的限界」**に直面しました。

① パーツ境界の正解が存在しない（曖昧さ）

人間の目には「ここからが腕」と分かっても、イラストのタッチや装飾によって境界線は曖昧です。

武器の一部が腕と一緒に切り抜かれてしまう
頭と胴体に同じピクセルが二重に割り当てられてしまう
尖った耳の先端だけが消えてしまう

プログラム上で「重なり率が〇%以上ならエラー」といった機械的なQA（品質保証）ゲートを設けても、結局のところ手作業によるマスクの微調整やプロンプトの調整が1体ごとに必要になり、自動化の前提が崩れてしまいました。

② イラスト調の画像におけるInpaintの破綻

写真であれば、切り抜いた背後の景色をLaMa等で違和感なくInpaintすることが可能です。しかし、手描きのイラストやゲーム用のスプライトにおいて、背後に隠れている領域（例えば、腕で隠れた鎧の装飾）をAIに予測させると、**「周囲のピクセルを適当にぼかして混ぜたような、粘土っぽいテクスチャ」**が生成されてしまいます。

Spineでアニメーションさせた瞬間、手前のパーツが動くとその後ろから「破綻したテクスチャ」が露出してしまい、ゲームのクオリティとして到底使えるものではありませんでした。

③ 分割できたとしても、その後の「動き付け」が地獄

仮に完璧に切り抜きと背後補完ができたとします。しかし、キャラクターの骨格やプロポーションはそれぞれ異なるため、Spine上でのボーン配置（リギング）やモーション作成は、結局キャラクターごとに手作業で行う必要が残っていました。

3. 「2Dのまま頑張る」のをやめ、3Dに方針転換

「2Dイラストを無理やり2Dのレイヤーに分割しようとするから、見えない部分の破綻や重なりが問題になるのだ」と気づき、全く違うアプローチに舵を切ることにしました。

それが、**「1枚絵から直接3Dモデル（メッシュ）を生成し、ゲーム内で『ライティングなし（Unlit）の2Dスプライト』として動かす」**という方針です。

新しい3D化パイプライン

image-to-3Dによる形状生成 (Hunyuan3D-2 など)
- 1枚のイラストから、AIを使ってベースとなる3Dメッシュを生成。
シルエットの自動成形
- 3Dモデルを正面から見たときのシルエットが、元の2Dイラストと完全に一致するように、ボクセル処理を用いて不要な膨らみを削り落としたり、欠損を補完したりする。
投影ベイク (Planar Projection Bake)
- 生成された3Dモデルに対して、元のイラストをそのまま正面から「テクスチャとして投影（ベイク）」する。
ゲームエンジン(Axmol)でのUnlit描画
- 3Dモデルに光を当てず（シェーダー無効化）、テクスチャの色をそのまま表示。これにより、真横からの視点（2Dゲーム視点）では元のイラストと全く同じ絵柄が再現される。

なぜこれが2D分割より優れているのか？

見えない領域の問題が自然に解決: 3Dなので「腕の後ろの胴体」は最初から立体として存在し、Inpaint特有の不気味なテクスチャ破綻が起きません。
リグとモーションの使い回しが可能: ゴブリン、オーク、スケルトンなど、同じ「人型（Humanoid）」であれば、1つの3Dリグとモーション（待機、攻撃、死亡など）をそのまま流用できます。
2D特有の「絵柄」を保持: Unlitで描画することで、AIが生成した3Dモデル特有の「のっぺり感」や「CGっぽさ」を消し、手描きのイラストそのままのテイストでゲームに出せます。

現在、この「PoC-A（静的モデルの生成とUnlit表示）」の段階まで検証が進んでおり、正面から見ると元のイラストと見分けがつかないレベルでゲームエンジン上に配置できることが確認できました。

4. 今後のチャレンジ

「2Dのイラストを動かしたいなら、2Dで処理しなければならない」という固定観念に縛られていましたが、生成AIの進化により「とりあえず一旦3Dモデルにしてしまう」という力技が、結果的に最も汎用性が高く、品質を担保しやすいことに気付きました。

とはいえ、この3D化アプローチの研究はまだ始まったばかりで、完成には至っていません。
今後は、生成された3Dメッシュに対して自動で骨を入れ（Auto-rig）、共通モーションを流し込む「PoC-B」の検証を進めていく予定です。

同じように「1枚絵から大量の敵キャラを量産して動かしたい」と考えている個人開発者の方にとって、Spineによる2D分割への固執を一度捨てて、image-to-3D + Unlit描画に切り替えるアプローチが何かのヒントになれば幸いです。次の進捗があれば、また記事にしたいと思います。