キャラクター原画からアニメーションフレームシーケンスへ

47 分で読了 #ゲーム開発

このページの目次

目標は「動きそうに見える」動画を作成することではなく、ゲームランタイムで安定して参照・切り替え・再現可能なアニメーションリソースのセットを得ることです。

この手法は、完全なキャラクター原画をアイデンティティの基準とし、Gemini Omni Flash を用いて短時間のアニメーション動画を生成し、その動画を固定キャンバス、固定アンカー、固定フレーム数の透明 WebP アトラスに圧縮します。実際の作業負荷はモデル呼び出しそのものよりも、生成前の制約設定、アクションウィンドウの選択、アルファ抽出、フレーム抽出、スケール正規化、そしてフレームごとの検収にあります。

最終的なパイプラインは以下の通りです。

適用範囲の明確化

このアプローチが適しているのは以下の場合です：

ゲーム内で表示されるサイズが小〜中程度の2Dキャラクター；
待機、攻撃、被弾、転倒などの短時間のアクション；
アクション終了後に静的な待機状態に戻るか、最終フレームで停止する演出；
骨格の精度よりも原画のスタイルが重要であり、予算がフレームごとの手描きアニメーションを賄えないプロジェクト。

一方、以下の場合には直接適さないため、この手法のみでは対応できません：

近接のヒーロー演出や、フレームごとの顔の描写が重要なカット；
最初と最後のフレームがピクセルレベルで完全に一致する必要がある長時間のループ；
武器が正確な軌道で指定座標に命中する必要があるアクション；
多数のオクルージョン、グリップ、二人の格闘、または複雑な布の相互作用；
各フレームの輪郭や人体構造に対して厳格な美術修正が求められるプロジェクト。

重要な認識として、動画モデルが提供するのは時間的に連続した「アクション素材」であり、そのまま納品できるアニメーションではありません。完成品は、その後のフィルタリングと正規化によって生まれます。

なぜ画像から動画への生成（Image-to-Video）を選ぶのか

最も直感的なアプローチは、キーポーズをリストアップし、各フレームを個別に生成することです。しかし、実際には通常以下の3つの問題が発生します：

フレームごとにキャラクターが再解釈され、顔、衣服の層数、鎧のプレート、武器の長さ、身体比率がわずかに変化します；
単一のフレームを拡大して見れば問題なく見えますが、連続再生すると明らかなちらつきが発生します；
各フレームの生成ごとに新しいアイデンティティの分岐が生じ、最終的には大量の手作業による修正で整合性を保つ必要があります。

画像から動画への生成の利点は、単一フレームの美しさではなく、同じ生成プロセス内の隣接フレームが時間的な文脈を共有することです。詳細の再描画は行われますが、独立した画像生成に比べてドリフト（逸脱）が小さく、また長い出力の中から最も安定した 0.5〜1.5 秒だけを切り出すことができます。

したがって、このパイプラインは以下の2つの原則に従います：

1本の動画は1つの主要アクションのみを担当する；
動画全体を完璧にすることを目指さず、アイデンティティが安定し、アクションが明確な使用可能なウィンドウを探す。

もう一つの完全な検証を経たアプローチとして、キャラクターをまず Meshy を用いて3Dメッシュモデルに変換し、Blender でバッチレンダリングしてフレームを抽出する方法があります。この手法はモデリング、リギング、アニメーション、アトラス生成のすべての工程で機能しますが、最終的なレンダリングは2D美術の品質基準を満たしませんでした。メインのワークフローを中断しないよう、完全な試験の振り返りは後述します。

キャラクターアイデンティティカードの準備

原画の要件

キャラクター原画は、以下の条件を満たしていることが望ましいです：

頭から足元まで完全であり、靴底、武器、長い衣の裾が切り詰められていない；
ゲームで定められた統一された方向を向いている（例：すべて右向き）；
顔、髪型、衣服の層、象徴的な小道具が明確；
姿勢がニュートラルな守りの状態に近く、四肢が互いに大きく重なっていない；
キャラクターの周囲に安全領域があり、特に長兵器や転倒アクションのために横方向のスペースが確保されている；
シーン、投影、パーティクル、テキスト、UI が含まれていない。

もし半身の立ち絵しかない場合は、まず完全なアイデンティティのマスター画像を作成してください。動画モデルに動作中に足、靴、武器の先端を自行補完させることは、アイデンティティの逸脱をほぼ確実に招きます。

なぜ単色背景を使用するのか

多くの動画モデルは、直接使用できる安定したアルファチャンネルを出力しません。複雑なシーンに対して事後に汎用的な背景除去を行うよりも、入力とプロンプトの両方にアルファ抽出の条件を組み込む方が効率的です。

検証では、キャラクターの主体が暖色系の茶、黒灰、暗赤を主とし、青色との距離が大きいことを利用し、高彩度の #005AF9 青を使用しました。この色が唯一の正解ではありません。キャラクター自体に青い服、冷たい光エフェクト、またはシアン色の縁取りがある場合は、緑、マゼンタ、または主体のカラーパレットから遠い別のキー色に変更する必要があります。

アイデンティティカードは 1280×720 の不透明キャンバスを推奨します：

元の RGBA 原画を保存し、マスター画像上で直接色を変更しない；
キャラクターを選択したキー色の上に合成する；
完全に不透明な PNG としてエクスポートする；
ファイルを再読み込みし、キャンバスサイズ、アルファ、縁の色が変更されていないことを確認する。

透明な PNG をモデルに直接渡し、透明領域が保持されると想定しないでください。モデルは透明領域を黒背景、チェッカーボード、白縁、または新しいシーンとして解釈する可能性があります。

画面構成

アイデンティティカードはキャラクターの制約のみを担当し、最終的なアトラスのサイズは担当しません。キャラクターがカード全体に貼り付いているのは避けてください：攻撃では武器が伸び、被弾では後方に倒れ、転倒では縦長の輪郭が横長の輪郭になります。入力段階でスペースを残しておくことは、生成後に手足を切り詰めてから补救するよりもはるかに信頼性が高いです。

まず、以下の3つの不変量を規定することを推奨します：

統一されたソースの向き；
統一された足元の位置；
統一された立っているキャラクターの可視身長範囲。

これら3つの値は、後処理においてアトラスリストの一部となります。

Gemini Omni Flash を用いたアクションソース動画の生成

本稿で使用しているモデルは Gemini Omni Flash で、モデルコードは gemini-omni-flash-preview です。これは公式の Gemini Interactions API を介して画像から動画への機能を提供しています。モデルはプレビュー段階にあり、本番環境ではモデルコードと生成日付を記録する必要があります。「Gemini」とだけ書くことはできません。

公式 SDK をインストールします：

python -m pip install -U google-genai

秘密鍵は環境変数 GEMINI_API_KEY に設定し、スクリプト、プロンプト、生成記録に書き込まないでください。以下は最小限の公式 API 呼び出しの骨格です：

import base64
from pathlib import Path

from google import genai


client = genai.Client()
reference = base64.b64encode(Path("character-key-card.png").read_bytes()).decode()

interaction = client.interactions.create(
    model="gemini-omni-flash-preview",
    input=[
        {
            "type": "image",
            "data": reference,
            "mime_type": "image/png",
        },
        {
            "type": "text",
            "text": Path("attack-prompt.txt").read_text(encoding="utf-8"),
        },
    ],
    response_format={
        "type": "video",
        "aspect_ratio": "16:9",
    },
    generation_config={
        "video_config": {
            "task": "image_to_video",
        }
    },
)

Path("attack-source.mp4").write_bytes(
    base64.b64decode(interaction.output_video.data)
)

出力が大きい場合は、公式ドキュメントに従って URI delivery に切り替え、生成完了後にローカルに即時ダウンロードしてください。一時的なダウンロードURLはアセットの保存手段ではありません。

プロンプトはアクション名ではなく、制約リストである

「キャラクターに攻撃させろ」とだけ書くのは不十分です。モデルは独自のカメラワーク、敵、パーティクル、2回目の攻撃、衣装変更などを追加する可能性があります。効果的なプロンプトには、少なくとも6層の情報が必要です：

アイデンティティのロック⁠：顔、髪型、体格、衣服の色と層、象徴的な小道具；
画風のロック⁠：入力画像の2Dイラストレーション言語を継続し、リアルアクション、3D、または別のレンダリングスタイルに変換しない；
画面のロック⁠：単一ショット、固定カメラ、全身、統一された向きと安全領域；
背景のロック⁠：キー色が最初から最後まで均一であり、床、影、景物、エフェクトが表示されない；
タイムライン⁠：保持、準備、アクション、終了ポーズ、回復、または最終フレームでの保持；
失敗禁区⁠：余分な肢体、2本目の武器、回転、衣装変更、ぼやけ、画面外への逸脱、反復アクション。

以下の匿名化されたテンプレートから始めることができます：

10-second, 16:9, single continuous shot for a 2D game character action.
Treat the input image as an immutable character model sheet and color key.

Keep exactly the same face, hairstyle, body proportions, garment colors,
garment layers, footwear, and signature prop in every frame. Preserve the
same hand-painted 2D illustration style. Never turn the character into live
action, 3D, cel animation, or a different costume.

The full body and the complete prop remain inside the central safe area.
The character faces screen-right for the entire clip. The camera is locked:
no pan, tilt, zoom, shake, lens change, perspective change, or scene cut.
The background remains a perfectly uniform solid key color. No floor,
shadow, particles, blood, text, logo, watermark, attacker, or projectile.

[0.0-1.5s] Hold the input guard pose with only subtle breathing.
[1.5-2.0s] Prepare one clear action while keeping both feet controlled.
[2.0-2.7s] Perform exactly one readable action toward screen-right.
[2.7-3.3s] Hold the completed action pose briefly.
[3.3-4.8s] Recover along a physically plausible reverse path.
[4.8-10.0s] Return as closely as possible to the input guard pose and hold.

Use sharp outlines and a high-shutter look. No motion blur, depth of field,
compression smearing, extra limbs, duplicated props, costume recoloring,
face redesign, body-scale change, background flicker, or second action.
No dialogue, voice, music, or sound effects.

攻撃、被弾、転倒は、動詞を置き換えるだけでは不十分です。各アクションタイプに対して、身体の受力、小道具の状態、終了時の挙動を再規定する必要があります：

攻撃⁠：能動的なアクションは1回のみ発生させ、方向、武器、力の経路、収めを明記する；
被弾⁠：攻撃は画面外から来るものとし、攻撃者や投射物は表示しない。キャラクターは反撃せず、その後待機に戻る；
転倒⁠：まずバランスを崩し、次に沈み込み、最後に停止する。最終段階では起き上がったり、守りの姿勢に戻ったりしない；
待機⁠：呼吸、髪先、衣の裾の微細な動きのみを許可し、歩行、回転、カメラドリフトは許可しない。

Gemini Omni Flash には、独立したネガティブプロンプト、システムインストラクション、temperature、top_p の制御がありません。すべての禁止事項は通常のプロンプト内に記述する必要があります。公式ドキュメントでも、単一ショットとカットなしを明確に記述することを推奨しており、記述しない場合、モデルは複数のショットを構成する傾向があります。

1本の動画で1つの一時的アクションのみを実行

1本の動画で待機、攻撃、被弾、転倒を連続して実行させないでください。一見すると呼び出し回数を節約したように見えますが、実際には以下の3つの問題を拡大します：

モデルがアイデンティティを長時間維持する必要が生じる；
アクションの間に瞬時の切り替え、回転、または2番目の衣装の出現が発生しやすい；
いずれかのアクションが失敗すると、動画全体が影響を受ける。

より確実な単位は「1キャラクター × 1つの一時的アクション」です。攻撃、被弾、転倒は個別に生成し、待機は優先的に、アイデンティティ審査済みのソース動画の安定した保持セクションから派生させます。

動画からのアクションフレームの抽出

まずアクションウィンドウを選び、全フレームを処理する

MP4 を受信したら、すぐにフルフレームレートでアルファ抽出を行わないでください。まず 2–4 FPS で接触表（コンタクトシート）を生成し、動画全体を素早くチェックします：

アクションが実際にどのフレームから始まるか；
2回目の攻撃や余分な回復が発生していないか；
顔、衣装、小道具が変更される箇所；
画面外攻撃者、光エフェクト、代役、または誤った投射物が生成されていないか；
転倒後に再び立ち上がったり、突然別の転倒姿勢に切り替わったりしていないか；
実機サイズで最も明確に見えるセクション。

ウィンドウの選択では、短くても構いません。モデルの出力時間を満たすために無用なフレームを残さないでください。ゲーム内の攻撃は通常1秒未満で十分です。モデルが提供する長い保持セクションは、安定した入り口と出口を見つけるためだけのものです。

例えば、アクションウィンドウを選択した後、候補フレームを抽出します：

ffmpeg -y \
  -i attack-source.mp4 \
  -ss 1.40 \
  -t 2.40 \
  -vf "fps=16" \
  candidate/frame-%03d.png

アイデンティティのドリフトが発生した場合は動画全体を廃棄

以下のいずれかが使用可能なウィンドウ内で明瞭に変化する場合、再生成する必要があります：

顔、年齢感、または髪型；
主体の衣の色、襟、袖口、衣服の層数；
鎧プレートの配置、ショルダーガードの構造、マントの模様；
武器の長さ、容器の数、紐、または象徴的なアクセサリー；
身体比率、指の本数、または四肢の接続関係。

アイデンティティがわずかに異なる2本の動画からそれぞれ半分ずつ取り出してアクションを拼接しないでください。静止した接触表では問題が見えない場合でも、連続再生すると、単一の動画のわずかなドリフトよりも明瞭なジャンプとして現れます。

ブルーバックのアルファ抽出とデスペル（色溢れ除去）

単に「青に近い」ピクセルを削除すると、髪、衣の裾、武器の縁に青い縁取りが残ったり、半透明の筆致が飲み込まれたりします。より確実な処理は2段階で行います。

ステップ1：色距離を用いてソフトアルファを生成する。

現在のパixelを C、推定された背景色を B とします：

d = ||C - B||
t = clamp((d - low) / (high - low), 0, 1)
alpha = smoothstep(t)

背景色は、クリーンなフレームの縁のパixelの中央値から取得できます。low と high は、完全に透明な領域と完全に不透明な領域の間の遷移幅を決定します。単一の閾値ではなくソフトアルファを使用することで、髪の毛や絵画の縁を保持できます。

ステップ2：縁に含まれる背景汚染を逆算して除去する。

アンチエイリアス処理された縁は、すでに前景とブルーバックの混合色です。合成式に従って近似逆算できます：

observed = alpha * foreground + (1 - alpha) * background

foreground ≈
    (observed - (1 - alpha) * background) / max(alpha, epsilon)

逆算後、残存する青の優勢を抑制する必要があります。そうしないと、高速動作中の青い縁取りが追加のエフェクトのように見えてしまいます。ここではキャラクターのカラーパレットと組み合わせなければなりません。キャラクター自体にキー色が大量に含まれている場合、自動デスペルは主体を誤って傷つける可能性があるため、事後に閾値を積み重ねるのではなく、生成前にキー色を変更すべきです。

運動量に基づいたフレーム抽出

均一なフレーム抽出では、静止セクションに多くのフレーム数を浪費し、同時に最も速い攻撃フェーズでは差異の大きい数フレームしか残らなくなります。より良い方法は、累積運動量に基づいてフレームを割り当てることです。

実用的な実装は以下の通りです：

まず 12–24 FPS で候補フレームを抽出する；
各フレームを低解像度の RGBA 特徴マップに縮小する；
アルファを乗算し、透明背景が差分計算に参加しないようにする；
隣接する特徴マップ間の平均絶対差を計算する；
各隣接区間に非常に小さな基本重みを加え、静止セクションでフレームが完全に消失しないようにする；
重みを累積し、等分された累積運動量に基づいて目標フレームを選択する；
アクションウィンドウの最初と最後のフレームを強制保持する。

擬似コードは以下の通りです：

energy[i] = base + mean(abs(signature[i] - signature[i - 1]))
cumulative = prefix_sum(energy)
targets = linspace(0, cumulative.last, wanted_frame_count)
selected = nearest_indices(cumulative, targets)

これにより、素早い振り動作にはより多くのフレームが割り当てられ、短い停止でも保持され、最終的な再生は同じフレーム数の均一サンプリングよりも滑らかになります。

以下の仕様は出発点として使用できますが、万能な標準ではありません：

アクション	成品フレーム数	再生フレームレート	時間	終了時の挙動
待機	18	10 FPS	1.8 秒	ループ
攻撃	24	30 FPS	0.8 秒	待機に戻る
被弾	18	24 FPS	0.75 秒	待機に戻る
転倒	30	24 FPS	1.25 秒	最終フレームで停止

フレーム数はアクションの可読性とランタイムの拍子に従うべきであり、「より滑らかに」と機械的に増加させるべきではありません。ソース動画の詳細は元々時間的にわずかに再描画されており、フレームを密にしすぎると容量が増加するだけで、視覚的な印象が向上するとは限りません。

安定したウィンドウを用いた待機ループの構築

動画モデルは通常、動画の最初または最後に近似静止状態を維持できますが、動画の最初と最後は同じ画像ではありません。最初と最後を直接接続すると、明瞭なジャンプが発生します。

低コストな方法として、すでに審査済みのソース動画の最初から10枚の安定した微動フレームを切り取り、往復ループを作成します：

forward  = [0, 1, 2, ..., 9]
backward = [8, 7, 6, ..., 1]
idle     = forward + backward

2つの転向端点を繰り返さないでください。そうすると、端点が2拍留まることになります。このピングポング（往復）は、呼吸、髪先、衣の裾など、可逆的な微動に適しています。歩行、振り動作、布の落下など、明確な時間方向を持つアクションは、逆再生してループにすることはできません。

待機は、攻撃と同じく審査済みのソース動画から派生させ、同じクリッピング、スケール、足元基準線を再利用するのが最善です。待機動画だけを別途生成すると、別の顔や別の衣装が生成される可能性があります。

統一されたキャンバスとランタイム座標

統一されたクリッピング、スケール、足元基準線

透明なフレームを抽出した後、最も過小評価されやすい問題はキャンバスの揺れです。各フレームが独自のバウンディングボックスに基づいて中央揃えされ、スケーリングされると、キャラクターは原地で忽大忽小（大きく小さく）し、身体の中心も左右にドリフトします。

正しい方法は、「アクション」を正規化の単位として扱うことです：

選択された全フレームのアルファバウンディングボックスを計算する；
これらバウンディングボックスの結合範囲を求める；
クリッピングとスケーリングを1回だけ計算する；
全フレームが同じクリッピング、スケーリング、水平位置を使用する；
各フレームは足元の位置に基づいて限定的な垂直アライメントのみを行う；
結果を同じサイズの透明なセルに貼り付ける。

検証では 1024×1024 のセルと統一された足元基準線を使用しました。具体的なピクセル値は変更可能ですが、同じプロジェクトでは1つの明確な規約のみを使用する必要があります。

立っているアクションは同じスケールグレードを共有する

攻撃は通常、最も完全な立っている状態の運動範囲を提供するため、そのクリッピング、スケーリング、基準線をキャラクターの立っているスケールグレードとして保存できます。待機と被弾はこのスケールグレードを再利用し、3つのアクション間でキャラクターの身長が突然変化しないようにします。

各アクションごとにキャンバスを「一杯に埋める」ために再計算しないでください。アトラスが個別に見え大きく見えるからといって、戦闘シーンに配置するのが正しいとは限りません。

転倒アクションは結合クリッピングを使用する

転倒は縦長の輪郭から横長の輪郭に変化するため、立っているクリッピングを強制的に適用すると、頭、足、マント、または武器が切り取られる可能性があります。転倒アクションは独自の結合バウンディングボックスを使用する必要があります。

結合クリッピングにより、立っている開始部分はわずかに小さく見えます。ランタイムでは、有界の display.scale とオフセットを提供し、立っているアクションに近い可視身長を回復できます。この補正は結合クリッピングによる版面の差異を解決するのみであり、切断された肢体、切り詰められた武器、または誤った構図を隠すものではありません。

足元が必ずしもアルファの最低点ではない

短い衣装と通常の武器を持つキャラクターは、アルファバウンディングボックスの底部を足元と近似できます。長槍、床に垂れるマント、尾、または吊り下げられた容器は足よりも低い位置にある場合があり、その場合は追加の足元マスクまたは手動アンカーが必要です。誤ったアンカーは、キャラクターが小道具の整列のために上下に跳ねる原因となります。

ソースの向きを固定し、ランタイムでミラーリングを決定する

すべてのソースフレームは同じ向きを採用する必要があります（例：すべて画面右向き）。各アクションリストには sourceFacing を明示的に記録し、ランタイムでキャラクターの站位に基づいてミラーリングするかどうかを決定します。

生成段階で一部のアクションを左向き、他のアクションを右向きにし、ファイル名や目視で推測させないでください。攻撃の方向、武器の握り方、被弾後の後傾が混在すると、ランタイムでの二重反転は非常にトラブルシューティングが困難になります。

アトラスとアクションリストのパッケージング

ランタイムでは、Animated WebP に依存せず、通常の静的 WebP アトラスを使用します。静的アトラスはプリロードが容易で、フレームごとの参照、指定フレームでの一時停止が可能であり、通常の動作と reduced motion（動き軽減）モード間でリソースを共有しやすいという利点があります。

単純なディレクトリ構造は以下の通りです：

animations/
└── actor-a/
    ├── idle/
    │   ├── manifest.json
    │   └── sheet.webp
    ├── attack/
    │   ├── manifest.json
    │   └── sheet.webp
    ├── hit/
    │   ├── manifest.json
    │   └── sheet.webp
    └── death/
        ├── manifest.json
        └── sheet.webp

アクションリストには少なくとも以下が含まれている必要があります：

{
  "schema": 1,
  "id": "actor-a.attack",
  "actor": "actor-a",
  "action": "attack",
  "sourceFacing": "right",
  "sheet": "./sheet.webp",
  "frame": {
    "width": 1024,
    "height": 1024
  },
  "grid": {
    "columns": 6,
    "rows": 4
  },
  "playback": {
    "frames": 24,
    "fps": 30,
    "loop": false,
    "end": "return-idle"
  },
  "cues": {
    "anticipationEnd": 8,
    "contact": 13,
    "recoverStart": 17
  }
}

cues は「このアニメーションの合計ミリ秒数」よりも重要です。戦闘ロジックは、ダメージ、ヒットエフェクト、被弾反応、サウンド効果を、アクションの中間点を推測するのではなく、contact フレームに合わせるべきです。アニメーションの速度は後で調整可能であり、フレームと時間の関係のみを再解釈すればよく、戦闘結果を変更する必要はありません。

アトラスの隣には、生成期間中の3つの成果物を保持する必要があります：

接触表⁠：全フレームを一度に閲覧し、アイデンティティと衣装のドリフトを審査する；
実機プレビュー：実際の背景、実際の表示サイズ、実際の再生速度で確認する；
マシンレポート⁠：フレーム抽出のタイムスタンプ、クリッピング、スケーリング、基準線、指標、出力ハッシュを記録する。

これらは生産証拠であり、すべてをランタイムリソースディレクトリに含める必要はありません。

品質検収

自動チェックは構造的エラーの発見に適している

元の動画の長さ、解像度、フレームレート、デコード状態；
目標フレーム数が完全かどうか；
各セルのキャンバスサイズとアトラスの列・行数が一致しているか；
アルファバウンディングボックスがキャンバスの端に触れていないか；
正規化後の足元のドリフト；
隣接フレーム間のキャラクター重心移動の平均、P95、最大値；
隣接する輪郭の IoU（Intersection over Union）；
アクションウィンドウの平均シャープネスと、元の原画に対する損失；
キー色背景の時間的な色のドリフト；
最初と最後のフレームの輪郭と色の差異から、ループ条件を満たすかどうかの判断；
WebP が対象ブラウザで実際にデコードできるか。

足元のドリフトは、まず 1024² セルに対して ≤2 px を目標とし、その後キャラクターのサイズと美術スタイルに基づいて調整します。重心移動と輪郭 IoU には、アクションを横断する統一閾値を設定すべきではありません。高速な振り動作、制約された被弾、転倒は本来異なる運動分布を持っており、同種のアクションのベースラインと比較する方が適しています。

美術品質は依然として手動でのフレームごとの審査が必要

顔、髪型、年齢感が同じキャラクターであるか；
衣服の主色、襟、袖口、層数が変化していないか；
鎧プレート、マントの破れ、模様、アクセサリーが再描画されていないか；
武器、容器、紐などの小道具が増減、湾曲、または持ち手が入れ替わっていないか；
指、関節、四肢の接続が接触フレームで崩壊していないか；
アクションが1回のみであり、方向と受力がゲームプレイに適合しているか；
余分な攻撃者、投射物、パーティクル、または代役が出現していないか；
ゲームの実際のサイズにおいて、準備、接触、終了ポーズが一目で認識できるか。

審査の順序は、まず接触表を閲覧し、次にループ再生を確認し、最後に実際の戦闘シーンに配置するのが推奨されます。透明な大きな画像だけを見ると、実機に影響を与えない詳細が強調され、体験に影響を与える実際のスケールのジャンプや拍子問題が見逃される可能性があります。

一般的な失敗と対処

モデルが連続して2回の攻撃を行った。

プロンプトで「全編を通じて唯一のアクション」と明確に指定しても、モデルは時間枠を満たすために2回目の攻撃を追加することがあります。動画全体を無理に使用せず、2回目のアクションを切り捨ててください。1回目のアクションが不完全な場合は、再生成してください。

被弾時に攻撃者や光弾が空中に出現する。

プロンプトでダメージが画面外から来ることを明確にし、攻撃者、武器、投射物、エフェクトを禁止してください。幻覚がアクションウィンドウの前後にのみ現れる場合は、時間窓を短縮できます。接触フレームを覆う場合は、動画全体を廃棄してください。

衣服の色や鎧の構造がアクション中に変わる。

アイデンティティの説明を「同じキャラクター」から個別の衣装リストに変更し、入力画像が変更不可能なキャラクター設定稿およびカラーキーの両方であることを宣言してください。それでもドリフトする場合、再生成し、悪い動画から数フレームを補って使用しないでください。

縁に青い光輪が現れる。

ソフトアルファとデスペルの両方を処理してください。プロンプトでも、エフェクト、アクションの弧、背景のグラデーションを禁止してください。モデルは青い動作の残影を主体の一部として描画する可能性があるためです。

フレームごとに個別に切り取ると、キャラクターが忽大忽小する。

動画全体で結合クリッピングと1回のスケーリングを共有するように変更してください。フレームごとのスケーリングは許可せず、限定的なアンカーの平行移動のみを許可します。

長兵器やマウント物が立っているクリッピングを超える。

アイデンティティカードの安全領域またはアクションセルを優先的に拡大してください。キャラクターのスケール自体が正しく、少数のフレームでのみ小道具がわずかに越境している場合は、人物のスケーリングを変えずに、全フレームに対して有界な平滑移動を行うことができます。武器に合わせて人物全体を縮小してはいけません。

転倒アクションの末尾で再び立ち上がる。

転倒のプロンプトで、最終段階が持続的に保持されることを明確にし、後処理でも「起き上がり」の前に切り捨てる必要があります。ランタイムでは最終フレームを hold に設定し、転倒シーケンス全体をループしないでください。

待機ループで最初と最後にジャンプする。

生成された動画の最初と最後を直接接続しないでください。内部の安定した保持セクションを選択し、端点を重複させない往復ループを使用してください。アクションに不可逆的な運動がある場合は、この素材を放棄し、静的な待機または骨格の微動を使用してください。

拡大するとわずかな再描画があるが、実機では正常。

納品サイズを確認してください。小サイズの戦闘キャラクターは、アイデンティティの認識に影響を与えない局所的な筆触の変化を許容できますが、顔、衣装の輪郭、象徴的な小道具はドリフトしてはいけません。品質基準は使用シーンを中心に据えるべきであり、各フレームが独立してキャラクター原画として機能することを追求すべきではありません。

Meshy + Blender 3D中間状態パイプラインの振り返り

3Dルートがより安定したシーケンスフレームを提供できるかを確認するため、以下の生産パイプラインを完全に検証しました：

キャラクター原画
  → 標準 T-pose 多視点
  → Meshy によるテクスチャ付き3Dキャラクターの生成
  → 標準2足リギングの自動適用
  → アクションの生成または再利用と武器の個別マウント
  → Blender による固定カメラでのバッチレンダリング
  → 透明フレーム、WebP アトラス、アクションリスト

この検証はモデルのプレビューで終わっていません。試験では実際にリギング可能なモデル、待機、攻撃、被弾、転倒の4つのアクションを産出し、両手武器のマウント、正交カメラの自動フレーミング、透明背景レンダリング、ブラウザプレビューを完了しました。4つのアトラスは合計31フレームで、すべて統一された 1280×720 キャンバスに入り、安全マージンのチェックを通過しました。アクションは認識可能で、フレーム間の構造は安定しており、オフラインでの再レンダリングも再現可能です。エンジニアリングの結果として、このパイプラインはすでに機能しています。

しかし、最終的にこれらのフレームを採用しなかったのは、美術品質基準を通過しなかったためです。

パイプラインは通過したが、完成品は通過しなかった

検収層	実際の結果	判断
モデルとテクスチャ	多視点入力から使用可能なメッシュが正常に生成され、正面、側面、背面の構造が完全	通過
リギングとアクション	4つのアクションタイプすべてが再生可能で、攻撃アクションと両手武器の関係を認識可能	通過
レンダリングとパッケージング	固定カメラ、透明フレーム、統一アンカー、アトラス、アクションリストがすべて出力済み	通過
実機同サイズ比較	キャラクターのアイデンティティ、輪郭の雰囲気、絵画の質感が原画よりも明らかに劣る	不通過

この結果は「アニメーションが確かに動いている」という事実に隠れがちです。3D候補だけを単独で見れば、それは完全なゲームキャラクターです。しかし、原画アセットと同じシーン、同じ着地線、同じ表示サイズで比較すると、ギャップが集中的に露呈します。原画は幅が広く低い戦闘輪郭を持ち、暗部が充実し、衣甲の縁には損傷、飛白、不規則な欠けがあります。一方、3D候補はより直立し、対称的で、服装の層が整然としており、輪郭が連続し、受光とマテリアルもより均一です。アクションの意味は保持されていましたが、キャラクターの視覚的アイデンティティはありませんでした。

最初の品質損失はモデリング以前に発生する

自動モデリングとリギングの成功率を高めるために、入力はまず標準的な2足キャラクターに整理する必要があります：T-pose または A-pose、四肢が明確で、正面、側面、背面が一貫しており、武器、マント、飄帯、複雑なオクルージョンが除去されています。これは合理的な3D生産入力ですが、必ずしも原画に忠実な入力ではありません。

原画で最も識別度が高い部分は、往々にしてこれらの「非標準」な情報です：偏った重心、武器によって撑開された構図、壊れた鎧、互いに重なり合うプレート、誇張された手足の比率、そして現在の視点でのみ成立する墨塊。キャラクターをクリーンなニュートラルな立ち姿勢に整理する際、最初に削除されるのはノイズではなく、輪郭の言語です。多視点を補完しても、追加される背面と側面は視点の一貫性を保証するだけで、すでに正規化されてしまったデザインを自動的に取り戻すことはできません。

これが、「複数の視点を与える」ことが最終的な問題を解決しない理由です。多視点は3D再構築の曖昧さを減らしますが、新しい設定が依然として原画の表現力を保持していることを保証するものではありません。

2番目の品質損失は2Dから3Dへの翻訳中に発生する

試験の多視点入力と Meshy モデルの比較から、衣装の大まかな種類、鎧の位置、人物の比率は基本的に保持されていますが、詳細は継続的に平均化されています：顔は一般的なテンプレートに近づき、鎧プレートと衣服のひだの層が減少し、縁は断裂した筆致から連続した表面になり、汚れと局所的な色差はより均一なテクスチャに圧縮されています。メッシュはアクション中に非常に安定していますが、それはすでにより一般的なキャラクターに安定しているということです。

これは3D再構築と2Dイラストレーションの目標が異なるために生じます。自動モデリングは、閉じており、連続しており、テクスチャ可能で、リギング可能な表面を見つけることを優先します。一方、原画は缺口、虚辺、大きな暗部、視点限定の誇張に依存して成立します。前者は後者の絵画的手法を幾何学またはテクスチャとして解釈し、決定できない部分を正規化します。フレーム間の安定性を増しても、この部分の情報損失を補うことはできません。

3番目の品質損失は実機サイズで拡大される

Blender レンダリングはすでに透明背景、固定正交カメラ、階調圧縮、統一ダウンサンプリングを使用していますが、これらの処理は出力仕様を統一するだけであり、3D表面を原画の筆致に戻すことはできません。ゲーム内の実際のサイズに縮小すると、顔と細かなテクスチャはほとんど見えなくなり、視覚的な印象を決定するのは外側の輪郭、明暗の塊、アクションの重心です。原画はこの3項目において明確なデザインを持っていますが、3D候補はクリーンで連続し、標準的なゲームモデルに近い視覚言語を示しているため、同じ画面の2Dキャラクターとは別の素材庫から来たように見えます。

アウトライン、紙の質感、カラーグレーディング、または NPR マテリアルはレンダリング表面を変更できますが、入力段階で削除されてしまった鎧の形状を補うことはできず、原画の欠けた縁、非対称な色塊、顔の表情を自動的に再構築することもできません。同じ品質に達するには、キャラクターレベルでメッシュを修正し、テクスチャを再描画し、専用マテリアルを設計し、キーフレームを手動で修正する必要があります。それは有効な 3D から 2D への美術パイプラインとなり得ますが、「原画を Meshy に渡し、その後 Blender でフレームを抽出する」という自動ソリューションではありません。

このルートが依然として適しているのはどのような場合か

今回の試験では、アクションマスター、武器の軌道、カメラ、アトラスツールは引き続き使用価値があります。3Dの結果は以下に適しています：

アクションの拍子と重心の参考；
両手武器の握点と軌道の検証；
カメラ、プレースホルダー、当たり範囲のプリビジュアライゼーション；
最終的な画風がすでに 3D、2.5D、または統一された NPR を受け入れているプロジェクト。

しかし、手描き2D原画をアイデンティティの基準とする最終的なピクセルに対して、検収の順序は「まずそのキャラクターに似ているか、次にアクションが安定しているか」であるべきです。この3D候補はちょうど逆で、アクションとエンジニアリング仕様は合格していますが、キャラクター自体の視覚的品質は明らかに低下しています。したがって、アクションの研究として保持され、正式なアセットには含まれませんでした。この失敗は、今後のワークフローの検収優先順位を明確にしました：まずキャラクターのアイデンティティと2D画風を保持し、次にフレーム間の安定性を処理する。

生産記録と匿名化

将来の再現のために、以下を保存することを推奨します：

モデルコード、生成日付、公式 SDK バージョン；
匿名化されたプロンプトテンプレートとアクションごとの差異；
入力アイデンティティカードと元の動画のコンテンツハッシュ；
採用と廃棄の理由；
最終アクションの時間窓と候補のフレーム抽出レート；
キー色、アルファ抽出の閾値、デスペルのバージョン；
クリッピング、スケーリング、足元基準線、ソースの向き；
フレーム数、再生フレームレート、アクションのキュー、アトラスハッシュ；
手動審査の結論と目標ランタイムのスクリーンショット。

入力原画は、自作品または明確なライセンスを取得した素材のみを使用してください。公式に生成された動画には不可視の SynthID 出所マークが含まれています。内部生産記録では、モデルと入力出所を継続的に保持し、「すでにフレームに抽出されているから」という理由で出所情報を破棄する理由にはしないでください。

公開された経験文書では、以下を保存する必要はありません：

API キー、認証ヘッダー、一時的なダウンロードURL；
外部タスクID、内部プロジェクトID、サプライチェーンルーティング；
実際のキャラクター名、世界観用語、未公開アセットのパス；
単回費用、アカウント情報、プライベートストレージアドレス；
未公開内容を逆推論できる完全なプロンプトと元の画像。

プロジェクト内部では完全な生産記録を保持できますが、公開ドキュメントにはメソッド、境界、移植可能なパラメータのみを抽出します。

最小限の検収チェックリスト

生成前：

原画が完全であり、足、衣の裾、小道具が切り詰められていない；
キー色とキャラクターの主カラーパレットに十分な距離がある；
アイデンティティカードが完全に不透明であり、キャラクターが安全領域にある；
プロンプトがアイデンティティ、画風、カメラ位置、背景、タイムライン、禁区を個別にロックしている；
各動画には主要アクションが1つだけ割り当てられている。

処理時：

まず低フレームレートの接触表を閲覧し、アクションウィンドウを決定する；
アイデンティティまたは衣装のドリフトがあるウィンドウは全体を廃棄する；
ソフトな色キーとデスペルを使用し、ハード閾値でのアルファ抽出は行わない；
累積運動量に基づいてフレームを抽出する；
同じアクションに対してクリッピングとスケーリングは1回だけ計算する；
立っているアクションはスケールグレードを共有し、転倒アクションは結合クリッピングを使用する；
ソースの向き、足元基準線、終了時の挙動をリストに記録する。

納品前：

接触表で顔、衣服、鎧、小道具をフレームごとにチェックする；
アトラスのフレーム数、グリッド、リストが一致している；
切断された肢体、切り詰められた武器、青い縁取り、透明な汚れ点がない；
実際の背景と実際の表示サイズで再生が通過する；
攻撃の接触フレーム、被弾反応、転倒の停止フレームがランタイムの拍子に適合する；
ブラウザが WebP をデコードでき、失敗時には静的なフォールバックフレームがある。

結び：最終的な成果物はアクション契約である

動画モデルが解決するのは「同じ2Dキャラクターに連続した運動を発生させること」です。ゲーム生産はさらに「どのフレームが使用可能か、どのようにアライメントするか、どのように再生するか、いつヒットするか、失敗時にどのようにフォールバックするか」を解決する必要があります。

真に再利用可能な成果物は、特定の生成動画ではなく、この安定した制約のセットです：

同じアイデンティティカード；
1アクション1ソース動画；
クリーンな時間窓；
適応型フレーム抽出；
統一されたスケールとアンカー；
明示的な再生リスト；
自動指標と手動アイデンティティ審査。

この契約が安定していれば、動画モデルはアップグレードでき、アクション数を増やすことができ、ランタイムもそれに合わせて書き換える必要はありません。

参考

Keywords: ゲーム開発, キャラクターアニメーション, アクションフレーム, シーケンスフレーム, スプライトシート, 画像から動画へ, Gemini Omni Flash, クロマキー, 適応型フレーム抽出, 足元基準線, アクションアトラス, WebP