結論
GPT Image 2.5を用いて生成したスプライトシートを均等なグリッドで分割してアニメーション化すると、キャラクターが水平方向に最大104ピクセル、垂直方向に最大48ピクセル揺れる現象が発生します。
このジッター（位置ズレによる揺れ）の原因はモデルの作画精度ではなく、生成される画像の寸法仕様およびフレーム配置の偏りに起因しています。検証によって判明した事実は以下の通りです。
- 解像度の固定仕様: 要求解像度（1280x720など）に関わらず、GPT Image 2.5 FlareおよびSunburstの出力は1672x941ピクセルで返却されます。
- 配置の非均等性: 水平方向のフレーム開始位置や各コマの描画幅が不均等であり、計算上の均等セル幅（418ピクセル）と実際の描画位置に最大51ピクセルの乖離が生じます。
- 垂直解像度の端数: 941ピクセルを2行で割ると470.5ピクセルとなり、ピクセル単位での均等グリッド分割が数学的に成立しません。
- ポーズの重複: 4x2の8フレーム構成で生成を要求した場合、下段のフレームは上段フレームと酷似した重複ポーズになります（MAD測定で4.95〜7.21）。
この問題を解決するためには、均等グリッドによる機械的な分割を避け、各フレームのバウンディングボックス（描画境界）を個別に検出して切り出し、接地位置（足元のベースライン）を基準に再配置する必要があります。
バウンディングボックス検出、足元アライメント、および共有64色パレットを用いたGIF生成を適用することで、垂直方向の揺れを0ピクセル、水平方向のズレを1ピクセルに抑え、ファイルサイズを611,294バイトから130,635バイトまで削減できることを確認しました。
検証環境と測定手法
本検証は2026年9月13日に実施しました。検証に使用した環境および条件は以下の通りです。
- 生成プラットフォーム: GPT Image 2.5生成ツール
- 使用モデル・チェックポイント:
- GPT Image 2.5 Flare（OpenAIによる位置付け: 日常的な利用に適した高速チェックポイント）
- GPT Image 2.5 Sunburst（OpenAIによる位置付け: 編集精度を最重視し、生成時間がより長いチェックポイント）
- 入力設定: アスペクト比 16:9、解像度 1K指定、参照画像なし
- 変換・測定ツール: Python画像解析スクリプト、ffmpeg
生成プロンプトには、レイアウトの均等性と背景の平坦性を指示する以下の英文を使用しました。
A 2D pixel-art sprite sheet of one character: a green-hooded courier with a brown satchel, side view facing right, running cycle, 4 frames in a single horizontal row, evenly spaced with equal margins on a flat mid-grey background, identical character height, proportions and colour palette in every frame, crisp 1px outlines, limited 16-colour palette, no text, no frame numbers, no grid lines, no drop shadows, no background scenery.
寸法測定ログ：要求サイズと出力サイズの乖離
WebUI上のコンポーザーでは解像度（1K/2K/4K）とアスペクト比（1:1、2:3、3:2、3:4、4:3、9:16、16:9、Auto）を選択可能です。16:9比率の1K指定（1280x720相当）で3回生成を行ったところ、得られた画像ファイルの寸法はすべて1672x941ピクセルでした。
この出力寸法に対して均等グリッドを適用した場合の幾何学的な不整合は以下の通りです。
- 水平方向: 1672ピクセル ÷ 4列 = 418.0ピクセル（整数値）
- 垂直方向: 941ピクセル ÷ 2行 = 470.5ピクセル（非整数値）
さらに、各フレームの描画開始位置（X座標）および描画幅をピクセル単位で測定した結果、モデル内部でのキャラクター配置は均等ではありませんでした。
フレーム開始位置と間隔の測定値
| スプライトシート | 1行目のフレーム開始X座標 | 開始位置の間隔（ピクセル） | 均等グリッド時のセル幅 | 測定結果の差異 |
|---|---|---|---|---|
| Flare（8フレーム） | 145, 554, 928, 1295 | 409, 374, 367 | 418 | 第4フレームで51ピクセルの位置ズレが発生 |
| Sunburst（8フレーム） | 139, 539, 905, 1322 | 400, 366, 417 | 418 | 生成ごとに異なる間隔の偏りが発生 |
| Flare（4フレーム） | 113, 514, 908, 1305 | 401, 394, 397 | 418 | 8フレーム構成より安定するが非均等 |
キャラクター描画幅の測定値
単一シート内におけるキャラクター本体の描画幅（左右の外輪郭間の幅）にもばらつきが確認されました。
- Flare（8フレーム構成）: 最小167ピクセル 〜 最大206ピクセル（差: 39ピクセル）
- Sunburst（8フレーム構成）: 最小181ピクセル 〜 最大212ピクセル（差: 31ピクセル）
- Flare（4フレーム構成）: 最小227ピクセル 〜 最大229ピクセル（差: 2ピクセル）
均等な幅（418ピクセル）で機械的にクロップした場合、キャラクターのバウンディングボックスがセルの中央に位置しないため、セル中央を基準に再生すると大きな揺れが発生します。
アライメント検証：均等グリッド vs 検出ベースライン補正
ジッターを解消するための実装アルゴリズムは以下の通りです。
- バウンディングボックス検出: 背景色（グレー）と異なるピクセル領域を走査し、各フレームの描画境界（上下左右端）を特定します。
- トリミング: 検出した境界線に沿って、各スプライトを個別に切り出します。
- キャンバス配置: 共通サイズのキャンバスを用意し、各フレームを配置します。
- 接地合わせ（ベースライン整列）: 水平方向はキャンバス中央にセンタリングし、垂直方向はキャラクターの足元の最下部ピクセル（ベースライン）をキャンバス底面に合わせます。
クロップ手法による位置ズレ（ドリフト）の比較
| クロップ手法 | 水平方向のズレ | 垂直方向のズレ | アニメーションへの影響 |
|---|---|---|---|
| 均等4x2グリッド | 104 px | 48 px | コマごとにキャラクターが上下左右に大きく揺れる |
| 検出バウンディングボックス ＋ 足元アライメント（8フレーム） | 19 px | 0 px | 上下の揺れが完全に消失。水平ズレは歩幅動作のみ残存 |
| 検出バウンディングボックス ＋ 足元アライメント（4フレーム） | 1 px | 0 px | 完全な定位置でのループアニメーションが成立 |
8フレーム全体をオニオンスキン合成（平均化合成）した画像において、均等グリッド切り出し（左）では輪郭全体が激しくブレていますが、足元アライメントを適用した切り出し（右）では胴体と頭部が固定され、四肢の動きのみがブレとして現れていることが確認できます。
フレーム類似度測定：8フレーム指定時の重複問題
4x2の8フレーム構成を指定した場合、上段の4コマと下段の4コマでポーズの重複が発生します。画像間の類似性を評価するため、ピクセルごとの平均絶対差（Mean Absolute Difference: MAD）を測定しました。数値が小さいほど2枚の画像が同一であることを示します。
上段・下段対応フレームのMAD測定値
- ペア1（フレーム3 vs フレーム7）: 4.95 MAD
- ペア2（フレーム2 vs フレーム6）: 5.62 MAD
- ペア3（フレーム4 vs フレーム8）: 5.73 MAD
- ペア4（フレーム1 vs フレーム5）: 7.21 MAD
これに対し、明らかに異なるポーズ間のMAD測定値は最小でも12.36であり、重複ペアの数値はその半分以下でした。下段の各フレームは上段の対応するフレームの微細なバリエーションに留まっています。
また、Sunburstチェックポイントでは行内および行間でのポーズ重複が確認され、フレーム開始位置の間隔も400、366、417ピクセルと不規則でした。
単一水平行の4フレーム構成（1x4）を選択した場合、フレーム開始位置のばらつきは7ピクセル以内（401、394、397）、描画幅の差は2ピクセル（227〜229ピクセル）、アライメント後の水平ズレは1ピクセルに収まりました。
パレット最適化とGIFビルド
GPT Image 2.5から出力される生画像は約48,000色のカラー情報を含んでいます。GIF形式の最大色数は256色であるため、フレームごとに個別のパレットを生成すると背景色の量子化誤差によりフリッカー（チラつき）が発生します。
安定したGIFを生成するため、全フレームから共通の64色パレットを生成し、ディザリングなしで適用するffmpegコマンドを使用します。
パレット生成コマンド
ffmpeg -i frame-%02d.png -vf "palettegen=max_colors=64:stats_mode=diff" -update 1 palette.png
GIFビルドコマンド
ffmpeg -framerate 12 -i frame-%02d.png -i palette.png -lavfi "paletteuse=dither=none" run-cycle.gif
生成設定によるファイルサイズと品質の比較
| 生成条件 | ファイルサイズ | 特徴 |
|---|---|---|
| 均等グリッド分割 ＋ 各フレーム個別パレット | 611,294 bytes | 位置ズレと背景チラつきが最大 |
| アライメント補正済み ＋ 各フレーム個別パレット | 241,987 bytes | 位置補正により差分が減少しサイズが約60%削減 |
| アライメント補正済み ＋ 共通64色パレット（8フレーム） | 165,345 bytes | 背景フリッカーが消失しサイズがさらに削減 |
| 4フレーム構成 ＋ アライメント補正済み ＋ 共通64色パレット | 130,635 bytes | 最適化された出力 |
フレーム位置を整列させ、全コマ共通のパレットを適用することで、ファイルサイズは初期状態の611,294バイトから130,635バイトまで圧縮されます。
代替手法との比較：動画生成モデルの利用
スプライトシートを直接切り出す手法の代替として、シートを参照画像として動画生成モデルに入力し、出力動画をGIF化するアプローチを検証しました。
4フレームのスプライトシートを参照画像としてSeedance 2.0 Mini（480p設定）に入力したところ、93秒で864x496ピクセル、121フレームの動画クリップが出力されました。
スプライト切り出しと動画モデル変換の比較
| 評価項目 | スプライトシート切り出し（本手法） | 動画生成モデル経由（Seedance 2.0 Mini） |
|---|---|---|
| 生成コスト比率 | 1x（基準） | 約19x |
| フレームの制御性 | 承認済みの4フレームを保持 | モデルが再描画した121フレーム |
| 1フレームあたりの色数 | 64色（指定可能） | 7,433 〜 8,194色 |
| 同一幅でのGIFファイルサイズ | 130,635 bytes | 530,249 bytes |
| 接地位置のズレ（ドリフト） | 0 px | 3 px |
動画モデル経由の手法は5秒間で3ピクセルのドリフトに収まり接地安定性は高いものの、コスト比率が約19倍となるほか、ドット絵のピクセル情報が再レンダリングされ、色数や形状が元画像から変化します。元のピクセルアートを厳密に保持したい用途には、直接切り出しとアライメント補正を行うパイプラインが適しています。
既存ツール利用時の注意点とモデルの制約事項
ブラウザベースの分割ツールにおける問題
ezgifのスプライトカッターなど、行数と列数を指定して画像を等分割する一般的なWebツールでは、GPT Image 2.5の配置特性に対応できません。均等に格子状分割を行うと、キャラクターの輪郭が切り欠かれたり中心位置がずれたりし、前述の104ピクセルの横ズレおよび48ピクセルの縦揺れが発生します。
GPT Image 2.5固有の仕様制限
本検証において確認された、切り出しスクリプト側では根本回避できないモデル側の仕様制限は以下の3点です。
- 背景色の微細な変動: プロンプトで中間グレーを指定しても、生成ごとに背景のRGB値が変動します（実測例: RGB 122,121,122、RGB 127,126,125、RGB 130,129,130）。単一のカラーコードによる単純なクロマキー透過処理は行えません。
- 出力フォーマットの制限: ダウンロード形式がJPGに固定されており、PNG形式や透過レイヤーを持った状態での直接取得はできません。
- 複数行指定時のポーズ重複: 前述の通り、2行以上の多フレーム構成を指定すると、下段が上段のポーズの複製になります。
まとめ
GPT Image 2.5を用いたスプライトアニメーション作成における推奨フローは以下の通りです。
- プロンプト設計: 8フレーム（2行）ではなく、単一水平行の4フレーム構成（1x4）を指定する。
- 寸法処理: 要求解像度を基準にせず、出力画像の実サイズ（1672x941）を読み取る。
- フレーム切り出し: 均等グリッド分割を行わず、ピクセル走査によるバウンディングボックス検出を行う。
- アライメント: 各スプライトの最下部ピクセル（足元）を基準線として整列させる。
- GIFエンコード: 全フレームから抽出した共通の64色パレットを適用し、フリッカーの防止とサイズ軽量化を行う。
Seadanse（筆者が開発に関わっているサービス）
筆者はGPT Image 2.5を提供するGPT Image 2.5の開発に関わっており、本稿の検証は同環境で実施しました。なお、検証手順および測定データの評価において特定の結果を誘導する処理は含んでいません。