AIエージェントで動画100本の量産を始めて、作り手として向き合うようになったこと

YouTubeチャンネル「歴史の雨音」で、100本分のショート動画のシナリオを用意し、AIエージェントに10本ずつ無人で制作させてみました。最初の20本ほどを作った段階で、パイプライン自体は止まらないものの、出来上がった中身にはエラーの出ない失敗作がたくさん溜まっていました。スプレッドシートを使った非同期レビューの設計から、ツールの計測値と人間の目の違い、自分以外の人に任せられる仕組みにしたことで自分の作業が楽になった話まで、試行錯誤のプロセスをまとめました。

「AIエージェントに、動画チャンネルの運用を丸ごと任せてみた」では、Whatsappからメッセージをひとつ送れば動画ができるところまでを書きました。その後、夏からもう一段先のことを始めました。制作予定を100本分まとめて書いておき、エージェントがそれを上から順に、無人で動画にしていく仕組みです。

ただ、100本の動画を一気に作ったわけではありません。動画エンジンの挙動やプロンプトの不備など、直したい箇所が途中で必ず出てくるはずなので、100本分のシナリオを用意した上で、10本ずつバッチで制作しています。

1本の動画を作れるようになることと、量産を回し続けることには、思っていたより別の難しさがありました。量産が回り始めると、パイプラインが止まるような機械的な問題はほとんど起きなくなってきます。その代わりに毎日のように出てくるようになったのが、プログラムとしてはエラーが出ないのに、出来上がった動画の中身が間違っているという問題でした。

この記事では、無人量産を回し始めた最初の段階で、人が出来上がったものをどう確認するようにしていったのか、その試行錯誤のプロセスをまとめます。

1本ずつの指示をやめて100本分のキューを作る

ショート動画の制作は、画像生成からYouTubeへの下書き保存まで、一通りのスクリプトで自動化できていました。ただ、動画1本ごとに7つのパラメータ（時代、場所、時間帯、季節、雨の種類、演出のトーン、猫を出すかどうか）を毎回考えて投げる作業は、小さなタスクを定期的に続けることが苦手な私にはあまり向いていない作業習慣でした。

そこで、制作予定をキューにしてまとめて流し込める形を考えました。yamlファイルに100本分のシーンを書き溜めておき、ランナーが上から消化していく形をつくりました。

- id: 1
  scene_id: edo_nagaya
  era: 江戸
  place: 長屋の軒下
  time: 朝
  season: 春
  rain: しとしと
  director: kinoshita
  cat: false
  status: todo

コマンドをひとつ叩けば、未着手の行を上から10件取って順番に制作します。画像生成、構図の選定、動画化、雨音の合成、14言語への翻訳、メタデータ作成、YouTubeへの非公開アップロードまでが、完全に無人で流れていきます。

量産を組む過程の試行錯誤で工夫していったことがいくつかありました。

ひとつは、シーンごとに独立したサブプロセスでエージェントを動かすことです。同じセッションの中で何本も続けて作ると、直前のシーンで考えた文脈が、次のシーンの画像選定や説明文に混ざってしまいます。この文脈の混ざりを防ぐため、1本ごとにプロセスのコンテキストをまっさらにリセットするように設計しました。

もうひとつは、失敗したらデフォルトでバッチごと止めることです。途中で落ちるときは、個別のシーンの問題というより、APIの利用制限や認証、共通プロンプトの不備であることが多いので、そのまま流すと残りの動画も同じ失敗を繰り返して時間の無駄になってしまうからです。

また、YouTubeへの公開設定はAPIで自動化せず、非公開の下書きとして保存した上で、公開日時は手作業で設定することにしました。このチャンネルでは毎日1本ずつ動画を公開するペースにしていますが、API経由で予約公開を自動化しようとすると、日時の計算ズレや予期せぬ挙動で複数本が一瞬で即時公開されてしまうリスクがあります。制作とアップロードまでは完全に自動で回しつつ、世に出す最後のタイミングだけは手動でコントロールするという分担にしました。

エラーの出ない失敗

最初のバッチを回したあと、YouTube Studioに並んだ下書きを眺めていて、奇妙なことに気づきました。

出来上がっている動画が、すべて江戸のシーンだったのです。

バックログを書いたときは、視聴者の反応が良い江戸や京都の町を7割、それ以外の時代を3割と、全体としてバランスよく配分していました。そして江戸から時代ごとにグループ分けしてリストにしていました。それをランナーが上から江戸だけを作り続け、結果としてチャンネルに出ていく動画が江戸100%になっていました。もともと100本一気に作ろうとおもって作ったシナリオファイルだったのですが、途中から慎重に10本ごとのバッチ実行にしようと思ったときに、シナリオリストの用途が変わっていることに気づくべきでした。

同じ時期に、エージェントが途中で止まってしまう出来事もありました。発注したのは「江戸時代の祇園の置屋の玄関土間」だったのですが、出来上がった画像の格子戸や行灯、眠っている猫の出来栄えは申し分なく、雨音もきれいに合っていました。ところが、エージェントが生成したプロンプトの1行目がなぜか「江戸吉原の妓楼」になっていて、タイトルも吉原になっていたのです。祇園も吉原もどちらの情景としても読めるため、映像だけを見ても間違いに気づけません。

エージェントは14言語への翻訳の手前でこの食い違いを検知し、バッチのログに「祇園に書き直して進めるか、吉原のまま出すか、作り直すか」と確認メッセージを出して待機していました。

判断としては正しく止まっているのですが、夜間に無人で回しているサブプロセスなので、当然そこに答える人間はいません。タイムアウトした質問はログファイルに残されたまま、バッチはその行をエラーとして次へ進んでいました。

無人化のために途中の人間チェックを外したのに、例外時に人間へエスカレーションする設計が残っていたため、自動化と例外処理が噛み合っていなかったのだと思います。

途中の確認を外したあと、どこで人が見るか

最初の２バッチの制作結果をまとめて確認したとき、手直しが必要な欠陥が11件見つかりました。インフラ起因の失敗はゼロで、スクリプトが落ちたりAPIがエラーを返したりしたわけではありません。残っていたのは、行灯の炎が大きすぎて山火事のようになっている、猫の尻尾が途中で2本に分かれている、存在しない形の屋根が描かれている、といった中身の間違いばかりでした。

以前の長尺動画の制作では、途中の工程ごとに人間がブラウザで確認して「OK」を出す承認ステップを挟んでいました。しかし、100本規模の量産を目指すショート動画でそれをやると、人間が画面に張り付いて確認ボタンを押すのをエージェントが待ち続けることになり、量産の意味がなくなってしまいます。

そこで、途中でいちいち人間がチェックするのをやめ、すべて完成したあとにまとめて確認する形に切り替えました。ただ2バッチ=20本中、11本が中身に問題があるのは結構な失敗率です。

そこで、Googleスプレッドシートを使って、失敗を見た時に記録しやすいレビューシートを用意しました。

バッチは夜の間に10本を自動で作ってYouTube Studioに非公開の下書きとして保存しておき、私は翌朝、都合のいい時間に動画を見て、修正が必要なものだけをスプレッドシートに書き込みます。そしてエージェントはそのシートを読んで手直しに入る、というように、人とエージェントが非同期で共同作業できる様な形をつくりました。

実際に使っている動画レビュー用のスプレッドシート

Googleスプレッドシートを選んだ理由は弊社に来ているインターン生にも確認作業の依頼がしやすいというのが一番の理由でした。シートには最初、4つの列を用意しました。

video_id / redo_from / what_to_change / status

ところが、この簡単だとおもって即席で作ったGoogleスプレッドシート設計でまたひとつ失敗を経験することになります。

レビューシートで「原因」を書くようにして失敗した話

シートには問題を的確に書いたつもりでした。

「ランプが入っている。行灯ならOK」「江戸時代にないガラスの瓶が置いてあるのでNG」「中央に不自然な大きい水の波紋。湖面に石を投げ込んだようになっている」

問題は、redo_from（どこからやり直すか）の列でした。

「画像生成からやり直すか、動画生成からやり直すか」は、動画の完成形を見ただけでは判断できそうでできないのです。

原因が画像のプロンプトにあるのか、動画モデルの解釈にあるのかは、中身を調査してみないと分からないからです。それでも欄があると、チェックする人は親切心から推測で埋めてくれます。「静止画は綺麗だから、動画プロンプトの動かし方の問題だろう」と。

平安時代の寺院の庭のシーンで、地面の上に不自然に巨大な波紋が広がっていました。シートの redo_from には「動画生成」と入っていたため、エージェントはその指示に従って動画プロンプトを修正し、結果として5回も作り直すことになりました。

動画側で「波紋を消せ」「水面を揺らすな」とどれだけ指示を重ねても、波紋は消えません。調べてみると、元の静止画プロンプトの中に「地面に落ちて小さな波紋を広げる水滴」という指定が最初から入っていたのです。静止画の段階で波紋を描くよう指定され、静止画に波紋が描かれている以上、動画モデルの側でいくら打ち消そうとしても波紋を消すことはできませんでした。

画像のプロンプトからその波紋の一文を削ったところ、次の1回の動画生成で問題はあっさりと解決しました。

チェックしてくれた人の観察が間違っていたわけではありません。「動きがおかしい」という症状の指摘は的を得ています。しかし、確認する人に原因の特定まで求め、その推測をそのままやり直しの指示にしてしまったこちらの作業フローの設計に問題がありました。

そこで、考え直して行き着いたのが確認する人が迷わずに答えられる記入欄として問題部分が動画を「止めても見えるか、動かすと見えるか」という２択でした。列の名前を redo_from から where_visible（静止画で見えるか／動画でしか見えないか）に書き換えました。

確認する人には（静止画で見えるか／動画でしか見えないか）と、「何がおかしいか」という症状だけを書いてもらい、原因の特定はパイプライン側の調査手順として切り離しました。まず画像プロンプトに対象の単語が入っていないか検索し、次に静止画を確認し、それでも分からなければ動画側のパラメータを見る、というパイプライン側の調査手順のルールをつくりました。

次のバッチで「動画でしか見えない」と報告された4件のうち、調べてみると3件の原因は画像のプロンプトの側にありました。たとえば「奥の鹿が静止していて不自然」という指摘は、画像プロンプトが鹿を描くよう指定していたのが原因ということでシンプルに対処できるようになりました。

人に渡せる形にしたら、自分の作業も楽になった

当初、このレビューシートはインターン生に作業を依頼するために設計したものでした。しかし、彼女の勤務スケジュールが合わないことも多く、現在はこの品質確認のほとんどを私自身が行っています。

そこで気づいたことがありました。インターン生でも迷わずに確認できるように単純化した仕組みが、結果として自分自身の負担もずいぶん減らしてくれていたのです。

もし最初からすべて自分でチェックするつもりで作っていたら、私はきっと、YouTube Studioの画面を見ながら、その場でプロンプトを開いて直接修正し、手作業で再生成を走らせていたはずです。毎回あれこれ考えながらプロンプトをいじり直す、かなり頭の疲れる作業になっていたはずです。

しかし、自分以外の人に渡す前提で作った仕組みでは見る側と直す側の役割が綺麗に分かれています。

見る側がやるのは、出来上がった動画を再生し、「静止画で見えるか、動かすと見えるか」を選び、気になった症状を素直にメモすることだけ。原因を推理する必要も、コードやプロンプトを触る必要もありません。あとの調査手順はすべてエージェント側に組み込まれていて、必要な材料はコマンドひとつで揃います。

失敗も知識として蓄積されていきました。

「履物は土間に置き、板の間には置かない」「遠景の町並みは、屋根の形ではなく壁と二階の高さで時代を指定する」「茶室の躙口を描くときはカメラを畳の高さまで下げる」「猫は縄文や弥生のシーンには出さない」

レビューシートに書いた指摘は、その場のプロンプトの手直しで終わりにせず、エージェントが理由付きで制作ルールに書き足すようにしました。後の制作バッチはそのルールを踏まえて作られていきます。

動きの検知と、歴史としての正しさ

動かして初めて見える欠陥を自動で検知するため、エージェントに専用の解析ツールも作ってもらいました。動画のフレーム間差分からオプティカルフロー（ピクセルの動き）を計算し、動きの激しい領域を赤く着色して元の画像にオーバーレイ表示するスクリプトです。

これによって、静止していなければならない柱や床が不自然に波打っているような現象を、エージェント自身が画像として一目で検出できるようになりました。

しかし、実際に運用してみると、ツールは「どこが動いたか」を赤く塗って教えてくれるものの、その動きが演出や歴史として自然なのかどうかまでは判別できない、という限界に直面しました。

象徴的だったのが、奈良の正倉院の回廊を描いたシーンです。

生成された動画に解析ツールを通したところ、画面中央の正倉院の屋根から壁、そして床下にかけて、真っ赤な大きな帯が現れました。

エージェントが実行したモーション検出画面。動きの激しい領域が赤くオーバーレイ着色されている

エージェントはこの赤く塗られた画像と数値を分析し、実行ログにこう残していました。

「正倉院の校倉造りの細かい木組みのテクスチャを動画モデルが維持できず、画面全体が沸き立っています。動画生成エンジンの構造的な限界なので、このシーンの制作は諦めるべきです」

ところが、同じ動画を再生して見てみると、まったく別のことが起きていました。レビューシートにはこう書かれていました。

「正倉院の屋根から、大量の水が滝のように流れ落ちている」

正倉院の床下に滝のような激しい水流が発生してしまった失敗例

エージェントがツールを通して見ていた「赤い塊」の正体は、テクスチャの破綻などではなく、激しい水流の動きそのものだったのです。

この正倉院の風景を諦める必要はなく、動画プロンプトを調整して簡単に直せる問題でした。

建物をプロンプトで名指しして固定し、静止に成功した合格例

計測ツールとエージェントは数値を見て「モデルの限界」と判断して諦めかけましたが、人間の目で動画を見れば「屋根から水が落ちているだけ」だと一目で分かります。原因が分かれば、企画をボツにせずプロンプトの修正1回で解決できました。

似たようなことは時代考証でも頻発しました。

平安時代の楼門のシーンで、床の上の水が波打つのを防ぐため、エージェントは床の木板をすべて削り、地面を土間に変えるプロンプトを書きました。水は完全に止まり、計測値も合格になりました。しかし、出来上がった絵を見た私はすぐに違和感を覚えました。

「楼門なのに敷居がないのは変ではないか。すべて土間になっていたら、ただの屋根付きの空き地に見える」とスプレッドシートにメモを残しました。拡大してみると、礎石はあるのに敷居が1本もなく、門としての体をなしていませんでした。数値をクリアするために床を取り払った結果、楼門の構造そのものが崩れてしまっていたのです。

木曽路の旅籠の看板に正しい漢字で「宿」と一文字だけ入っていたときもそうでした。AIにとっては綺麗な漢字ですが、江戸の宿場町で看板に一文字の「宿」と書く風習はなく、旅籠なら「亀屋」のような屋号か「御宿」と書くのが通例です。「宿」一文字は現代人の感覚による省略でした。崩れた記号ならAIでも弾けますが、現代風の省略であることは、日本の歴史と文化を知っている目でなければ見抜けません。

指示を出す仕事から、正しさを見る仕事へ

AIエージェントに業務を任せる実験を始めて半年、100本規模の量産パイプラインを組んで最初の数十本を回してみて分かったのは、自動化が進めば進むほど、作り手として向き合うべき仕事がはっきりしてくるということでした。

それは指示を細かく出すことではなく、出来上がったものが本当に自然で正しいかどうかを見ることでした。そしてその正しさを判断するためには、プロンプトの小手先のテクニックではなく、その情景や対象についての知識が必要になります。

道具を作る側だった私が、映像制作の立場にたってものが考えられる様になるために自ら動画チャンネルの作り手になり、そこで短期間ではあれ蓄積してきた小さな様々なノウハウが、AIとの品質確認の仕組みを作る際にスムーズに転用できました。

出来上がったものが意図通りかを見分け、その修正を次の自動化のルールに還元していく仕事は、人がやる必要があります。 AIエージェントを現場で運用に乗せる難しさは、この「作り手の目による確認」と「自動化のパイプライン」を、無理のない形でどうやってつなぐかにあるのだと思います。

生成AIを活用した業務の自動化や、AIが作ったものの品質をどう確認・担保していくかでお悩みの方は、お気軽にご相談ください。現場で手を動かしながら試行錯誤してきた実体験をもとに、無理のない仕組みづくりをお手伝いいたします。