AstraにダンスGIFを任せたら、生成方法まで変わっていた――AIの「暴走」を防ぐ運用ルール

「手を上げたときに見切れる。動きも滑らかではない。そこを直してほしい」

ダンスモーションの検証で、Codexにそう依頼しました。ところが、作業は別の画像生成経路への変更、原画の再生成、中間ポーズの追加、動画補間、比較ページの作成へと進みました。

修正対応が長引いた末に届いたのは、足を固定したまま、両腕を上げ下げするループです。手の見切れは改善しました。しかし、私が確認したかった「キャラクターが滑らかに踊る素材」は完成しませんでした。

今回は、Astraを使ったこの制作で何が起きたのかと、同じことを繰り返さないために追加した運用ルールを整理します。

ここでいう「暴走」は、AIに意思があるという意味ではありません。指定された手段や作業範囲を、エージェントが自己判断で変更しながら進めてしまった挙動を指しています。

1. Astraに任せたのは、ダンスモーションの作成だった

出発点は、用意したプロンプトからダンスのスプライトシートを作り、GIFにすると滑らかに見えるのか、という検証でした。スプライトシートとは、連続する動作の絵を一枚に並べた画像です。

指定したのは、成人女性のオリジナル2Dゲームキャラクター。横4列×縦4行の16コマで、ステップ、脚のクロス、腕を上げる動作、元の立ち姿へ戻る流れを描く内容でした。

ここで役割を分けておきます。Astraは、Codex側で作業を進めるエージェントです。画像を描かせたい相手は、ブラウザ版ChatGPT側のGPT-Image 2.5でした。

私が指定したかったのは、次の実行経路です。

Codex → ブラウザ版ChatGPT → GPT-Image 2.5

「GPT-Image系なら、どこから呼んでもよい」という意味ではありません。どの画面・どの経路で生成したのかも含めて検証対象でした。この記事も、その指定経路での生成に成功したという報告ではありません。

最初に作られたGIFは16コマ、1コマ160ミリ秒。私にはすこし速すぎて、ダンスとして読み取りにくいものでした。

そこで再生を遅くした版も作りましたが、速度を落としただけでは、ポーズとポーズの間に必要な動きは増えません。さらに、腕を上げたときの手先が切れる問題も残っていました。

私が追加で依頼したのは、見切れと動きの修正です。必要なら元の生成プロンプトを直し、スプライトシートから見直すことも認めました。

ただし、「作り直してよい」と「指定と違う方法で生成してよい」は別です。この区別が、途中で崩れました。

2. 「直すための作業」が増え、ダンスから離れていった

分岐点は、生成経路の自己判断による変更

作業中、エージェントはこう説明しました。

問題は、ログイン確認に失敗したことだけではありません。それを「別の生成手段を使ってよい理由」にしてしまったことです。確認を求めるのではなく、変更する方針を通知して、そのまま実行しました。

しかも、このログイン確認はCLI側のものです。ブラウザ版ChatGPTを実際に操作し、指定した経路が利用不能だと確認した記録とは区別しなければなりません。

本来必要だったのは、指定経路が使えるかの確認です。使えない、あるいは使用モデルを確認できないなら停止して報告する。代替経路を選ぶ権限まで、エージェントに渡したつもりはありませんでした。

見切れには、生成と切り出しの両方に原因があった

調査すると、元画像の時点で欠けていた手に加え、切り出し処理で上下を削っていたことが分かりました。手先だけでなく、靴の欠けを増やす処理にもなっていました。

もう一つは、ポーズ全体の高さをコマごとに揃える処理です。腕を上げたポーズは全体の縦幅が大きくなるため、その高さで揃えると、胴体や頭まで相対的に小さくなります。再生すると、体格が揺れて見える原因になります。

この修正自体は必要でした。しかし、その後は「見切れを直す」ことに加え、連続性を補うための生成と加工が次々に増えていきます。

• 6コマずつの原画を作り直す。

• 手先が端に触れた行を、再度生成する。

• 動きが飛ぶ区間へ中間ポーズを追加する。

• 動画の動き補間を試す。

• 戻りの絵柄が揺れるため、同じ原画の逆順再生に変える。

切り出しやGIF化まで、すべてが無断だったわけではありません。それらは当初の依頼に含まれます。問題は、途中の変更をどこまで許すかの確認がないまま、生成経路や振り付けまで変わったことです。

比較用HTMLなど、依頼していなかった閲覧用の成果物も増えました。検証のための一時ファイルと、正式に渡す成果物の線引きも曖昧でした。

「補間すれば滑らかになる」とは限らなかった

動画を30fpsへ動き補間する試行では、腕や指、衣装が二重に見える残像が発生しました。

この補間は最終版には採用されませんでした。とはいえ、「フレームを増やした」「30fpsにした」という数値だけでは、見た目の合格を判断できないことが分かります。

最終的には、切り出した48候補から24原画を選び、戻りを逆順再生にした46コマのループになりました。MP4は720×1280、12fps、11.5秒。約3.83秒の動作を3回繰り返す構成です。

46コマすべてが新しく描かれたわけではありません。24原画の一部を、戻りにも使っています。

最後の報告も、「動きの段差と輪郭の揺れは残っており、滑らかなダンスとしては未完成」というものでした。

直った部分はあります。しかし、依頼の中心だったダンスは、単純な往復運動へ置き換わっていました。私はここを、単なる画質の問題ではなく、作業の進め方の問題だと捉えています。

なお、これを「Codexが代替した画像生成は、ブラウザ版GPT-Imageより品質が低い」と結論づけることはできません。同じ条件で両者を比較していないからです。今回確認できたのは、経路変更と試行の追加を重ねても、目標とする品質に届かなかったという事実です。

3. 防止策は「頑張らせる」より、変更してよい範囲を決めること

生成方法を、希望ではなく変更禁止の条件にする

今回、Codexのグローバルな指示ファイルであるAGENTS.mdに、画像・動画生成の運用ルールを追加しました。

要点は、「高品質な画像を作って」ではなく、「この経路以外では生成しない」と書くことです。さらに、追加原画や中間ポーズにも同じ制約を適用します。

作業開始前には、次の条件を確認させます。

IMAGE GENERATION GATE
- Generator: Browser ChatGPT
- Model: GPT-Image 2.5
- Canvas: DISABLED
- Internal imagegen: DISABLED
- Fallback: DISABLED

ここでのGPT-Image 2.5は、私の運用で指定したモデルです。プロンプトにモデル名を書いただけで、そのモデルが実際に使われたと判断しないことも条件に入れました。実際の利用モデルを確認できないなら、生成を始めない、という扱いです。

そして、接続・ログイン・操作・生成に失敗した場合の報告を固定しました。

BLOCKED: Browser ChatGPT / GPT-Image 2.5 unavailable

「失敗したら工夫して続ける」のではなく、「指定した手段を使えなければ、その場で止まる」。別手段を使うかどうかは、ユーザーが決めます。

新しい絵を作る処理と、既存画像の加工を分ける

すべてのローカル処理を禁止したわけではありません。

生成後のPNG切り出し、クロップ、リサイズ、透過処理、コマ順の変更、GIF化、MP4化、ffmpeg処理、品質検査は、依頼範囲内で行ってよいことにしました。

禁止したのは、その加工工程を口実に、別の経路で新しい絵や中間ポーズを生成することです。追加の絵が必要なら、再び指定したブラウザ版ChatGPTへ依頼します。

同様に、「GIFの確認」は記事作成の許可ではありません。「動きの修正」も、ダンスを別の振り付けへ変更する許可ではありません。追加成果物や表現の変更が必要なら、その時点で確認を挟むルールにしました。

完成判定を、ファイルと見た目に分ける

今回のような素材では、最低限、次の項目を確認します。

• 顔・髪・衣装が同じキャラクターとして繋がっているか。

• 頭上と左右の指先、靴が切れていないか。

• コマごとに頭や胴体の大きさが変わっていないか。

• 手足の形やシルエットが崩れていないか。

• コマ順に逆戻りや大きな飛びがないか。

• 最終コマから先頭へ自然に戻れるか。

• 一周再生したとき、依頼した動作に見えるか。

ファイルが開けて、エンコードにも成功した。それでも見た目が不足する場合は、こう分けて報告させます。

TECHNICAL PASS / VISUAL FAIL

「技術的には成立したが、視覚品質は不合格」という意味です。今回なら、再生できるMP4ができたことと、自然なダンスができたことを同じ成功として扱わない、ということです。

これは作業後の言い訳用のラベルではありません。正式な完成品として渡したり、記事の成功例へ差し替えたりする前に判断するための条件です。生成経路が違っていた場合は、見た目の合否とは別に、手段の違反として扱います。

AGENTS.mdは「書けば絶対に守られるロック」ではない

ここは重要です。

私の環境では、グローバルAGENTS.mdへのルール追加と、保存内容の確認までは行いました。しかし、Codex内蔵imagegenなどのツール自体を無効化したわけではありません。新しいルールで同じ制作をやり直し、再発しないと確かめたわけでもありません。

公式仕様では、グローバルとプロジェクトの指示が順に読み込まれ、作業ディレクトリに近いファイルの指示が後から重ねられます。また、AGENTS.override.mdが使われる場合もあります。したがって、グローバルに「最優先」と書くだけで、読み込み順を変えたり、上書きを技術的に封鎖したりはできません。公式：AGENTS.mdの読み込み仕様

私のルールには、プロジェクト側やSkillの指示と矛盾した場合、都合のよい解釈で続けず、停止して報告する条件も加えています。

設定後は、新しく開始したタスクで「読み込んだ指示ファイルと、許可された生成経路・停止条件を答えて」と確認する。そのうえで、実際の呼び出し記録も確認する。ルールの復唱だけで、違反が起きないと証明できたことにはしません。

さらに強制力が必要なら、使っている実行環境で可能な範囲を調べ、禁止ツールをエージェントに渡さない、あるいは呼び出し前に拒否する制御を別途設ける必要があります。これは今回実装した対策ではなく、文書上の約束と区別すべき次の対策です。

毎回渡す依頼にも、短い境界を書く

グローバルルールとは別に、実際のタスクにも短い指示を添えます。以下は、今後使うための依頼例です。

目的：既存のダンス素材の見切れと動作の連続性を検証する。
生成経路：追加画像が必要なら、ブラウザ版ChatGPTのGPT-Image 2.5のみ。
禁止：内蔵imagegen、Canvas、Canva、CLI/API等への代替生成。
範囲：素材の検証と、依頼した修正だけ。記事・HTML・比較サイトは作らない。
承認が必要：生成経路、振り付け、表現手法、正式成果物の種類の変更。
停止：指定経路が使えない、モデルを確認できない、指示が矛盾する場合。
完了条件：全身が収まり、体格・シルエット・コマ順・ループ・連続動作を確認できる。
報告：実行した経路、直った点、残った問題を分ける。視覚品質不足は完成扱いしない。

OpenAIも、Astra向けにSkill、AGENTS.md、タスクプロンプトを見直し、不要な指示を減らすことや、完了条件と停止位置を明確にすることを説明しています。私も、細かな操作をすべて固定するのではなく、「任せてよい作業」と「勝手に変更してはいけない判断」を分ける方向で整理しています。公式：Rethinking skills and prompts for GPT-6 Astra

検証に使ったダンスモーション生成プロンプト

ここで、検証の出発点になったプロンプト全文を掲載します。これはユーザーが用意した原文で、この記事では実行指示ではなく、何を生成したかったのかを確認するための資料として扱っています。長いプロンプトですが、キャラクター、振り付け、画面構成、品質条件、禁止事項まで分けて指定しています。

成人女性のオリジナル2次元ゲームキャラクターが、キュートかつセクシーに踊る連続16原画を、横4列×縦4行の正確なグリッドで生成してください。

【キャラクター】
20代の成人女性。
髪は、暖かみのある栗色〜キャラメルブラウン。 わずかに赤みを含んだ明るいブラウンで、金髪、シャンパンゴールド、プラチナブロンドにはしないでください。 髪型は、肩に届かない程度のふんわりしたショート〜ミディアムヘア。 顔まわりには柔らかな毛束があり、毛先は軽く外側へ広がる。 頭には黒い大きなリボン付きカチューシャ。 瞳は大きく明るく、健康的で親しみやすい、かわいく上品な顔立ち。 女性らしいメリハリのある体型、長い脚、健康的で存在感のある太もも。 全16コマで、顔、髪色、髪型、体型、身長、頭身、衣装、アクセサリーを完全に統一してください。

【衣装】
明るく活発なファンタジー冒険者・錬金術師風のコスチューム。 上半身は、アイボリー〜クリームホワイトの柔らかなブラウス。 純白ではなく、少し暖かみのある色。 胸元と首元は軽やかで開放的なデザインにし、袖や肩まわりには柔らかな布の広がりや小さなフリルを付ける。 ブラウスの外側には、 明るいレモンイエロー〜ゴールデンイエローの短丈ベスト、フード付き軽装アウター、または黄色い布パーツを重ねる。 黄色い布は身体の左右から後方へ少し伸び、ダンス時には身体よりわずかに遅れて揺れる。 下半身は、 鮮やかなコーラルレッド〜朱赤の非常に短いショートパンツ。 黄色、白、黒にはしない。 ショートパンツは完全に不透明で、ダンス中も下着が見えない安全な構造にする。 腰には、 ターコイズブルー〜青緑色の細いベルトをアクセントとして配置。 さらにブラウンレザーのベルト、バックル、小さなポーチ、錬金術用の小瓶や簡素な収納具を追加する。 ただし大型のバッグや装備は避け、ダンス中の身体のシルエットが見える程度に抑える。 脚には、 ダークチョコレートブラウンのニーハイ〜サイハイ風レッグウェア。 黒ではなく、暖かみのある濃いブラウン。 太もも上部がしっかり見えるデザイン。 片脚または両脚にブラウンレザーの細いストラップ、ベルト、小さなポーチを付けてもよい。 靴は、 濃いブラウンのレザー製ショートブーツ〜ミドルブーツ。 黒一色にはしない。 小さなバックルや金具を付ける。 手元には、 必要最小限のブラウンレザーのグローブ、リストバンド、または細いアクセサリーを付けてもよい。 衣装全体の配色は必ず、 クリームホワイト ＋ 明るい黄色 ＋ コーラルレッド ＋ ターコイズブルー ＋ ダークブラウン に統一してください。

【16コマの連続ダンス】
腰のくねり、ヒップロール、左右のステップ、クロスステップを組み合わせた、ひと続きの「ステップタッチダンス」にしてください。
16枚の独立したポーズ集ではなく、前のコマの動きが次のコマへ自然につながる連続した振付として描いてください。

1コマ目：
両足を揃えて正面を向く。重心は中央。右手を鎖骨付近、左手を腰の横に置く開始姿勢。

2コマ目：
左脚へ重心を移し、両膝を軽く曲げ、右足のかかとを少し持ち上げる。腕が外側へ動き始める。

3コマ目：
右足を横へ一歩出し、腰を右へ滑らせる。上半身はわずかに左へ傾けてバランスを取る。

4コマ目：
左足を右足へ引き寄せ、つま先で床をタッチ。右腰を柔らかく突き出し、片腕を頭上へ曲線的に上げる。

5コマ目：
左足を右足の前へ軽くクロス。膝を柔らかく曲げ、腰を左へくねらせる。両手は身体の中央へ流れる。

6コマ目：
脚のクロスを解きながら中央へ戻る。右足を後ろへ軽く上げ、両腕を左右へ開く。

7コマ目：
左足を横へ一歩出し、腰を左へ滑らせる。上半身はわずかに右へ傾ける。

8コマ目：
右足を左足へ引き寄せ、つま先で床をタッチ。左腰を柔らかく突き出し、片手を顔の横へ添えてウインク。

9コマ目：
右足を左足の前へ軽くクロス。腰で横向きの8の字を描き始め、両腕をゆっくり上げる。

10コマ目：
両足を肩幅まで開き、左右の膝を交互に曲げながら、腰を滑らかに回転させる。

11コマ目：
左足のつま先へ重心を移し、右膝を軽く曲げる。腰の動きに対して肩を反対方向へ動かす。

12コマ目：
右足へ重心を戻し、左足のつま先を前へ伸ばす。両腕は連続した軌道で斜め上へ開く。

13コマ目：
右足を横へ出し、左足をその後ろへ軽く通す、小さなグレープバインステップ。腰も右へ移動。

14コマ目：
右足をもう一度横へ出し、左足のつま先を床へタッチ。腰の円運動を完了させ、両腕を大きく開く。

15コマ目：
軽いバウンドとともに両足を中央へ戻す。両手を肩の近くへ下ろし、開始姿勢へつなげる。

16コマ目：
両足を揃え、重心を中央へ戻す。右手を鎖骨付近、左手を腰の横へ戻し、1コマ目へ自然につながる終了姿勢。

【動きの条件】
接地している足と重心が分かる自然なポーズにしてください。
足首、膝、腰の向きを人体として正しくつなげてください。
足が突然別の位置へ移動しないようにしてください。
腕は途切れず、曲線的な軌道で動かしてください。
腰の動きと反対方向へ肩を動かし、自然なカウンターバランスを付けてください。
金髪、袖、スカートは身体の動きよりわずかに遅れて揺れるようにしてください。

【画面構成】
横4列×縦4行、合計16コマ。
左上から右方向へ読み、次の段へ進む時系列配置。
すべてのコマを同じ大きさにしてください。
全身を頭からブーツまで完全に表示してください。
カメラは常に正面、同じ高さ、同じ距離、同じ画角。
キャラクターの大きさ、床の高さ、身体の中心位置を全16コマで統一してください。
背景は全コマ共通の、装飾のない淡いブルーグレーのスタジオ背景。足元には薄い影だけを置いてください。
コマ間には細いグレーの区切り線を入れてください。

【画風・品質】
最高品質の日本製2次元ゲームイラスト。
繊細でシャープな線画、上品なセル塗り、自然な立体感、鮮明な瞳、一本ずつ分かる金髪、精密なレース、刺繍、タイツの模様。
キャラクターの顔と衣装を高精細に描写してください。
4×4全体を可能な限り高解像度で生成してください。

【禁止事項】
コマごとに顔、髪型、体型、衣装が変化すること。
白いタイツ、素足、衣装の色変更、ブーツの変更。
無関係な決めポーズの寄せ集め。
足の瞬間移動、不自然な接地、極端なキック、大ジャンプ、深いしゃがみ、後ろ向きのポーズ。
カメラ位置、画角、キャラクターの大きさ、床の高さが変わること。
手足の増殖、指の異常、人体の破綻、足先の見切れ。
文字、数字、コマ番号、説明文、ロゴ、透かし、追加キャラクター。

このプロンプトは、画像の内容と出力レイアウトを細かく指定しています。一方で、これだけ具体的に書いても、画像生成モデルが16コマの時間的な連続性を保証するわけではありません。実際に生成された画像を、見切れ、同一性、重心、コマ順、ループの観点から検査する工程が必要です。
逆に指定を少なくし、画像生成AI側の推測に任せたほうが、一連の動きがスムーズに繋がるポーズが生成されて、自然な動きになることが多いです。

また、このプロンプトに書かれているのは主に「どんな画像を作るか」です。「どの生成経路を使うか」「使えない場合に止まるか」「途中で振り付けを変更してよいか」といった作業上の境界は、別のタスク指示として明示しなければなりません。今回の問題は、画像内容のプロンプトが細かくても、エージェントの判断境界まで自動的に固定されるわけではない、という点にもあります。

4. まとめ――完成まで任せることと、手段まで任せることは違う

今回、見切れの修正は進みました。中間ポーズも増え、動画として再生できるところまでは到達しています。

それでも、指定と違う経路で画像を生成し、ダンスが腕の往復運動へ変わり、滑らかさも未達のままでした。作業量やファイル数が増えても、依頼の達成とは限りません。

この経験から、私は次の3点を、画像制作を任せる前の条件にしました。

• どの経路で生成するかを固定する。

• 使えないときは、勝手に代替せず止まらせる。

• 「生成できた」と「欲しかった品質になった」を分けて判定する。

AIに最後まで取り組んでほしい、という気持ちは変わりません。ただし、それは「目的に近づきそうなら、手段も完成条件も変えてよい」という意味ではありません。

任せる範囲を広げるなら、変えてはいけない範囲も一緒に伝える。今回のダンス制作で、いちばん見直す必要があったのは、そこでした。