この連載では毎回、振付トレースだの衣装替えだのと派手な話を書いていますが、今回は裏方の話です。派手な生成を続けていると、必ずぶつかる地味な問題——生成物が増えすぎて、探せない。
問題: 出力は3か所に散らばり、動画だけで360本を超えた
生成AIの作業環境は、育つほど出力の置き場が増えます。当方の場合、ComfyUIの出力フォルダ、コマンドライン実行の出力フォルダ、参照素材の置き場——少なくとも3か所。さらにクラウドGPUで焼いた分を手元に回収したフォルダが日付ごとに積み上がります。9月末の時点で、動画だけで364本。画像はその比ではありません。
本数だけなら、まだフォルダを開けば済みます。本当に困るのは「この動画、どのプロンプトで焼いたんだっけ」です。この連載で何度も書いてきたとおり、生成結果はプロンプトと設定の関数です。つまり過去の成功作は、プロンプトとseedが辿れて初めて資産になる。辿れなければ、それはただの「昔たまたま上手くいった動画」で、再現も改良もできません。
既製品を探す前に、作らせた
ファイル管理ツールの既製品は山ほどあります。ただ、当方の要件は少し特殊でした。生成物に埋め込まれたプロンプト・seed・モデル名を復元して一覧に出すこと。手元のマシンの外に何も送らないこと。そして閲覧専用であること。この組み合わせを既製品で探すより、相棒のAI(Claude)に書かせる方が早い——そう判断して、8月に画像用として作らせたのが始まりです。のちに動画対応を足し、今は画像も動画も一つの画面で横断できます。中身はPythonのスクリプト1本と画面1枚だけの、小さな道具です。
仕組みの核心: 生成物は、自分の履歴書を抱えている
あまり知られていませんが、ComfyUI経由で生成したPNGや動画には、生成時の設定一式が埋め込まれています。プロンプト、seed、モデル名、ワークフローの構造。つまり生成物は、自分の履歴書を抱えて生まれてくる。ビューワーの仕事は、それを掘り出して読める形に並べ直すことです。
これが効くのは、「記録を別に取る」運用が要らなくなるからです。生成のたびに手でメモを取る運用は、まず続きません。埋め込みの情報を後から復元する方式なら、記録を忘れた日もサボった日も、生成物さえ残っていれば履歴は残っています。過去の成功作をクリックすれば、その場でプロンプト全文が出て、コピーボタンで次の実験に持っていける。seedも同じで、当たりの動画の番号をビューワーから拾って、次の生成に貼り付ける運用が成立しています。
設計で守った原則: 「読むだけ」
設計時に一つだけ譲らなかった原則があります。このツールは読むだけ。移動も削除も上書きもしない。
AIに道具を作らせる話になると、つい「整理までやらせよう」「重複を消させよう」と欲が出ます。当方はこれをやりません。数百本の生成物は、積み上げた実験データそのものです。もしツールのバグが「表示がおかしい」なら笑って直せますが、「ファイルが消えた」は取り返しがつかない。AIに書かせた道具ほど、壊せないものに触らせない——ツールの権限を最初に狭めておくのは、AIとの協働では書く能力より大事な設計判断だと思っています。
落とし穴①: AIは、画面が見えない
とはいえ、順風満帆だったわけではありません。作らせた直後、動画がクリックしても再生されないバグがありました。原因は画面の表示切替の単純な噛み合わせミス。ここで重要なのは、バグの中身よりなぜAIが気づけなかったかです——書いたAI自身は、ブラウザの画面を見ていないからです。コードの筋は通っている。テストも通る。でも画面では動かない。この一件以来、当方の運用は「見た目に関わる変更は、人間が画面を見てから出荷」で固定しています。AIの自己申告の「動きます」と、画面の「動いた」は別物です。
落とし穴②: 「出ない」より「嘘が出る」が怖い
もう一つ、9月末に大きな改修をしました。きっかけは、動画364本のうちプロンプトが表示できていたのが53本しかなかったこと。原因は複数あって、記録ファイルの形式違い、埋め込み情報の読み方の不足などを一つずつ潰し、表示できる動画は315本まで増えました。
この改修で、当方がAIに出した指示の中で一番大事だったのは、機能追加ではなく禁止事項です。いわく——記録が見つからない動画に、似た動画のプロンプトを借りて表示してはならない。空のプロンプトで実行されたものと、記録が見つからないものを区別して表示すること。推測で補完しないこと。
台帳の価値は、網羅率ではなく信頼性です。「表示が無い」は調べ直せますが、別の動画のプロンプトがしれっと表示されていたら、それを信じて実験した時間が全部無駄になる。364本中315本という数字は、残り49本を「推測で埋めなかった」結果でもあります。改修は自動テストで分岐や衝突のケースを押さえた上で反映しました(既存表示が消えた生成物はゼロ)。
この連載の裏側で、実は働いている
じつはこのビューワー、本連載の品質管理にも使われています。前回・前々回の振付トレース記事では、記事に載せたプロンプトの要点や試行本数を、作業記録とビューワーの表示を突き合わせて確認してから出稿しました。筆者と記事担当AIの間では「この動画の経緯はビューワーの該当ページを見て」という渡し方が成立していて、口頭説明より速く、記憶違いも混ざりません。
以前、AIの外部記憶としてのObsidianの話を書きました。あれが言葉の記憶だとすると、今回のビューワーは生成物の記憶です。テキストの決定事項はvaultに、生成物の履歴はビューワーに。二つで一組の外部記憶になって、AIとの協働が回っています。
まとめ
要点は3つです。第一に、生成物はプロンプトが辿れて初めて資産になる。埋め込み情報を復元する方式なら、記録を取り忘れても履歴は生成物の中に残っている。第二に、AIに作らせる道具は、権限を最初に狭める。読むだけの道具は、どれだけバグっても資産を壊さない。第三に、台帳は網羅率より信頼性。「出ない」を推測で埋めはじめた台帳は、台帳ではなくなる。
派手な生成の話は、また次回。裏方の道具は、一度作ると静かに効き続けます。
本記事の内容は2026年8〜9月の当方環境(ローカルMac)での実装・運用記録に基づきます。本記事中に登場する生成物の画像・動画はすべてAIによる生成物です。
コメント