要約

いまよくある入り方は、ChatGPT Images 2.5 に ChatGPT のスプライトシート を出させることだ。Sunburst は、編集の精度寄りに置かれた API 側の区分である。OpenAI の開発者フォーラムでは、Developing sprite sheets with gpt-image-2 が、一発の格子とポーズ転写をめぐって何ヶ月も続いた。同じコミュニティのあとからの記録、AI Game Studio Dev Log (by Platypus) が、実際に持ちこたえた工程を書いた。

  1. GPT Image モデルでキャラクター設定図を出す（当時のテストはまだ GPT-Image-2）。
  2. MiniMax H3 Max で 3–5 秒の動作クリップを出す。
  3. ffmpeg でフレームを抜き、大きさとキャラクター位置を直して動きを連続させる。
  4. Aseprite でスプライトシートを編集し続ける。スプライト資産の管理にあたる。
  5. 音は ElevenLabs を使う。

この工程は走らせられる。スプライトシートに要るのは、複数のツールが美術の文脈を共有できる Harness である。ChatGPT の独立したセッションでは、その文脈を渡せない。制作の経路にはしない。

その記録で持ちこたえたもの

画像生成だけでは持ちこたえなかった。行と列のある PNG 一枚は、一回に載せすぎる。フレーム間の滑らかさと揃えが、同時に出なければならない。前の画像で次のフレームを条件付けても、位置はまだずれた。そのスプライトシートのスレッドでの Platypus の返信は、より軽い「フレームの展開」だった。画像モデルの一回で完成した格子を出すと、一連の動作を同じ一枚に押し込むことになる。

使えた代替は、先に動画、それからフレームである。キャラクターの参照は GPT Image モデルから出た。短い動作クリップは MiniMax H3 Max から出た。フレームの切り出し、拡大縮小、位置の揃え直しは ffmpeg で行った。シートは Aseprite に入り、手直しされた。身元の細部はまだ落ちる。名札が一部のフレームで消え、描き戻す必要があった。GPT Image 2.5 の透明は、動画のあとのクロマキーを省かなかった。

ChatGPT Image のスプライトを使えるようにする は、最初のビットマップとあとの保全生成をすでに分けて書いてある。この記録は同じ切れ目で、文脈を共有しないツールの列として書かれている。

あとの二点：複数のビュー、開始と終了のフレーム

同じ記録のあと、使い勝手のメモが二点続いた。

キャラクターを出すとき、同じキャラクターの揃った複数ビューがあるとよい。横、正面、背面が、別角度のシーケンスのための一貫した参照になる。ベースライン揃えは以前よく崩れた。GPT Image 2.5 では、その隙間はほぼ埋まっている。横だけから正面と背面のアニメーションを伸ばすこともできる。細部は流れやすい。名札が消える、髪色がわずかに変わる。参照フレームを足すと、角度が変わっても同一の身元が保ちやすい。

二点目は、アニメーションを出すときに開始フレームと終了フレームを条件にすることだ。完璧にループする待機なら、最初のフレームと最後のフレームが重なる必要がある。北を向いてから横に戻る動作なら、最後のフレームもその横に着地する必要がある。

この二点で、短いクリップはループしやすく、見た目も揃いやすい。ツールチェーンの残りには、まだ共有できる資産の記録がない。

動画コメント欄で議論されたレイヤー分割

探索の過程を動画としてよく更新しているので、議論や意見も多く返ってくる。例えばある動画サイトの下に、次のようなやり取りが出ていた。

  • 無意味だ。Seedream 5.0 Pro はすでに画像のレイヤー分割に対応している。API 一回のことだ。
  • その Seedream のレイヤー分割は、どこで使うのか。
  • こうする。DeepSeek のサイトを開き、DeepSeek harness を入れ、登録してキーを取り、harness のチャットで DeepSeek に小さなレイヤー分割ツールを作らせ、ByteDance の Seedream 5.0 Pro の API につなぎ、API ドキュメントは自分で調べさせる。
  • 車輪の再発明、という言い方がある。それでも、その方法がコメントに出たのは動画のおかげだ。

一度きりのレイヤー分割スクリプトは、平面を分割できる。AI でスプライトシートを生成する は、分類、構造、メタデータをあとの摩擦としてすでに書いてある。API 一回では、それらは運ばれない。

キャラクターのスプライトは、スクリプト一つより広い需要である

SpriteCook のような製品は、すでにキャラクターのスプライトと、その周りの画像資産に乗っている。その範囲は ChatGPT の格子一枚より広く、Seedream のレイヤー分割スクリプトより広い。下にある需要には、少なくとも次が含まれる。

  1. 出したスプライトのあとの保全。元のサイズで再生成し、プロンプトと揃え続ける。
  2. 同じページでスプライト資産を速く編集する。
  3. キャラクター画の一括生成。
  4. キャラクターごとに持続し、安定したプロンプトの Harness。

どれもばらばらのツールで組める。量、一括の安定、あとの管理、チームの資産ライブラリでは、いまの VberAI Studio の工程のほうが近い。切り出し、書き出し、エンジンのフォルダ構成での書き出しはすでに存在する。完成したチーム用ライブラリは、まだない。

まとめ

ChatGPT Image 2.5 Sunburst にスプライトシートを任せる想定では、あとから長い Harness を組み、美術の処理も残る。より近い起点は、Codex のプロジェクトから Figma の MCP を呼び、この一括の美術を共有できるファイルに置くことだ。ゲームエンジンとの同期は、まだその先である。ファイルはエンジンのフォルダ構成で書き、レイヤーの文脈は対応したままにする必要がある。Figma to Godot の importer は一方向 は、その隙間をすでに書いている。

ChatGPT のなかでスプライトシートを直接出すと、最初のビットマップが手に入る。そのあとは、複数の生成源のあとのデータをスケジュールし、同期することである。