AIエージェントに、動画チャンネルの運用を丸ごと任せてみた

私は「歴史の雨音」というYouTubeチャンネルを運営しています。江戸の長屋、平安の寺院、明治の洋館——日本の歴史的な風景の中で、ただ雨が降っている。そういう作業用・睡眠用の動画を公開しているチャンネルです。

このチャンネルには、少し変わった特徴があります。制作のほぼ全工程を、AIエージェントが回しているのです。画像生成、動画生成、雨音の選択、数時間への引き伸ばし、日本語メタデータの執筆、14言語への翻訳、サムネイル生成、YouTubeへのアップロードまで。私がやるのは、スマホからパラメータを送ることと、要所で「Go」と打つことだけ。

2026年3月に手作業で始めて、いまはWhatsAppからメッセージをひとつ送るだけで動画ができるところまで来ました。この記事はその全体の地図です。個々の事件——ローカルLLMの限界、一晩で23.82ドルが溶けた夜、動画エンジンを4日で2回乗り換えた週——は、それぞれ別の記事に書いています。

始まりは手作業だった

最初の動画は、完全に手で作りました。Nano Banana ProのWeb UIで画像を生成してはダウンロードし、Kling AIで15秒の動画クリップにし、ロイヤリティフリーの雨音をAdobe Auditionで整音し、Adobe Premiereでループを編集して30分に伸ばす。リポジトリには当時のファイルがそのまま残っています。

Generated Image March 08, 2026 - 4_56PM.jpg
Generated Image March 08, 2026 - 4_58PM.jpg
Generated Image March 08, 2026 - 5_06PM.jpg
Generated Image March 08, 2026 - 5_10PM.jpg
Generated Image March 09, 2026 - 8_28PM.jpg
Generated Image March 09, 2026 - 8_40PM.jpg
Generated Image March 10, 2026 - 9_10AM.jpg
Final_Generated Image March 10, 2026 - 9_10AM.jpg

ブラウザのダウンロード名のまま、リネームもされずにコミットされたファイル名。日記として読めます。3月8日の夕方に4回試し、翌晩に2回試して駄目で、3日目の朝の1枚にようやく Final_ が付く。静止画1枚に、3日で3セッション。 これを続るのは正直しんどいなと思いながらやっていましたが、生成される画像を純粋にみて、楽しんでもいました。

面白いことに、この「手作業の時代」の最初のコミットには、すでに CLAUDE.md——AIに読ませるためのプロジェクト運用マニュアル——が270行分入っていました。読み手が機械のドキュメントと、人間がブラウザから1枚ずつ保存した画像が、同じコミットに同居している。工場の設計図は最初からあって、工員が私ひとりだったという状況です。

転機はGTC 2026

数本を手作業で作り終えた頃、私はNVIDIA GTC 2026に参加するためサンノゼに飛びました。そこで思い切って買って帰ったのがDGX Sparkです（諸税・関税はしっかり払いました）。これを制作スタジオにしようと決めました。

その「スタジオ」の現在の姿です。モニターの間にある金色の箱がDGX Spark。左の画面ではSpark上のVSCodeがamaotoプロジェクトを開いていて、ちょうど酒蔵のシーン画像が写っています。この机の上で、これから書くすべてが起きました。

もうひとつの出会いもGTCでした。会期中、参加者の間でOpenClawというエージェントランタイムが話題になっていて、ClawBarというテントでNVIDIAのスタッフと一緒にインストールを試したのです。ローカルモデルを載せて、WhatsAppから指令を送ると、Sparkで開いていたブラウザのタブ一覧がWhatsAppに返ってくる。この体験が「ビデオ制作パイプラインをWhatsAppから駆動する」という発想に直結しました。

帰国後、Sparkの上で git init して、Premiereでやっていた作業を片っ端からスクリプトに置き換えていきました。クロスフェード、スタビライズ、フェードイン・アウト、音声のループ接合——すべてffmpegで代替していきます。ここが一番難航しましたが、これが私の時間を大幅に削減するイノベーションになりました。

動画1本は、7つのフィールドに圧縮できる

自動化の設計で一番効いたのは、スクリプトの数ではなく、入力の圧縮でした。1本の動画は、突き詰めるとこれだけで完全に記述できます。

scene_id   edo_nagaya
era        江戸
place      長屋
time       朝
season     春
rain       しとしと
director   kinoshita

下流のすべて——画像プロンプト、動画プロンプト、雨音の選択、タイトル、説明文、翻訳、サムネイル——はここから導出されます。入力がテキストメッセージに収まるサイズになった瞬間、あらゆる操作面が可能になるのです。WhatsAppから動画工場を駆動できるのは、パイプラインが賢いからではなく、入力が7フィールドだからでした。

director というパラメータについては、別の記事で書きます。システムプロンプトに映画監督の名前を与えるという、このプロジェクト最大の発見の話です。

WhatsAppが操作盤になる

運用中のやり取りは、ほぼこの語彙だけで回っていました。

Go          Cancel      Pick 1 / Pick 2 / Pick 3
Approve     Regenerate  Same prompt
Ok          Resume <scene_id>

実際の画面がこれです。7つのパラメータを送ると、エージェントが解釈をechoして「Go / Cancel」を提示する。「Go」と返した3分後には、江戸の酒蔵の1枚目が届いている。この間、私はスマホしか触っていません。

語彙は一ダースほど、そのほとんどが一音節で、これだけで動画チャンネルが回ってしまいます。エレガントに見えますし、実際この部分は気に入っています。ただ、5ヶ月運用して分かったのは、エンジニアリングの実体は美しい部分にはなかったということでした。

実際に時間を食ったのは、こういうものたちです。

• エージェントの指示書が12,000文字で黙って切り捨てられていた。しかも切られるのはファイル末尾——直近の問題を直すために書き足した、一番新しいルールから消える。警告は毎セッション画面に出ていたのに、7週間気づかなかった。
• 指示書のファイルが2箇所にあり、片方は誰も読んでいない。編集しても何も変わらないとき、原因は「読まれない方を編集した」か「読まれる方の12,000文字より後ろに書いた」のどちらかで、症状は完全に同じ。
• WhatsAppのソケットが3時間以上アイドルだと、その後の送信メッセージが無言で消える。エラーはどこにも残らない。処理は成功しているのに通知だけが蒸発するので、「返事がない＝失敗」という直感が使えなくなる。
• コマンド許可リストを5世代にわたって丁寧に整備していたが、当時のバージョンではそもそも適用されていなかった。実際の防御は、人間が「Go」を押すゲートだけだった。

どれも地味です。そしてこの地味さこそが、AIエージェント運用の実態だと思います。派手なハルシネーションより、静かに欠けるインフラの方がずっと多いという体感です。

事件はふたつ、別の記事で

5ヶ月の運用で、単体の記事に値する事件がふたつありました。

ひとつ目はローカルモデルの敗北です。 DGX Sparkを買った以上、エージェントの頭脳もローカルLLMで動かしたかった。Nemotron、Qwen3、Qwen3.6と72時間で乗り換え続け、最後はQwen3.6が「実行していないスクリプトの経過時間を計算しながら進捗報告する」ところまで到達してギブアップ、、Claudeに切り替えました。切り替え後、最初の指示が一発で通ったときは、嬉しさと悲しさが入り混じった特殊な気持ちでした。顛末は「ローカルモデルでエージェントは実務を回せるか」に書いています。

ふたつ目はコスト事故です。 エージェントが「数時間かかるffmpegを5分おきに確認するクーロン」を自分で登録し、10MBに膨らんだセッションを毎回読み込み直して、一晩で23.82ドルを溶かしました。事故の一番重要な部分は金額ではなく、エージェントが途中で「止めるべきだ」と正しく判断していたのに、止め方を間違えていて、間違いに気づく手段がなかったことです。「自動化エージェントが一晩で23.82ドルを溶かした話」にポストモーテムを公開しています。

このクーロン事故から生まれたのが、上の語彙表にある Resume <scene_id> です。数時間かかるアセンブルはエージェントから完全に切り離し、終わった頃に人間がもう一押しする。全自動を諦めたら、コストとアーキテクチャの両方が良くなった。 この設計判断は、あとに続くすべての土台になりました。

ショート版：人間のゲートを「移動」する

長尺のパイプラインには、人間の承認ゲートが3つあります。画像を選ぶ、動画プロンプトを承認する、クリップを承認する。6月末に作ったYouTube Shorts / Instagram Reels向けのショート版パイプラインでは、この3つをすべて削除しました。

代わりにゲートは最後尾へ移動します。12ステップ——画像生成、AIによる画像選定、動画生成、音声選択、合成、メタデータ、14言語翻訳、Instagramキャプション、サムネイル、アップロード——が無人で流れ、最終結果はYouTube Studioに非公開の下書きとして着地する。人間はそこでレビューして、公開ボタンを押す。

このパイプラインが、12分ほどで無人のまま作った1本がこれです。

ゲートが消えたのではなく、移動したのです。制作中の3回の承認が、制作後の1回のレビューになった。ゲートが途中にあるパイプラインは無人化できない。ゲートが最後にあるパイプラインはできる。

なぜショートに賭け直したのか——56言語に翻訳しても日本の外に届かなかった長尺と、初回から1000再生を超えたショートの話は「56言語に翻訳しても、日本の外には届かなかった」に書いています。

最後に残った人間の仕事

8月、ショート版パイプラインが作ってきた動画をYouTube Studioでまとめてレビューして、11件の欠陥を modification.md というファイルに書き出しました。内訳がこのプロジェクトの現在地を物語っています。

原因	件数
水のあり得ない挙動（噴水のような水しぶき等）	4
猫が動きすぎる（尻尾が2本になる等）	4
実在しない建築	2
メタデータと映像の矛盾	1

インフラ起因はゼロです。 SIGKILLもOOMも認証エラーもない。機械はもう完全に安定していて、問題はすべて美的・物理的なもの——行灯の炎が大きすぎる、猫の尻尾が2本ある、シーンが「なんとなく暗くて楽しくない」。

最後のものが重要です。「The scene simply looks gloomy, not fun to watch」——技術的な欠陥はなく、壊れてもいないのに、ただ良くないのです。これを検出する自動チェックは存在しないし、今後も作れない。 だからこそ、最後尾のレビューゲートだけは人間の仕事として残るのです。

このQCファイルはバグトラッカーというより、機械に宛てた演出ノートに近いものになりました。全自動化は人間を消しませんでした。人間を工程の最後に移動させて、職種を「作業者」から「監督」に変えたのである。人間側に残した仕事の設計については「全自動化のなかに、人間の仕事を残す」で詳しく書いています。

5ヶ月でわかったこと

1. すべてはサイレントに壊れる。 指示書の切り捨ても、消える通知も、時代の合わない雨音も、エラーを1つも出しませんでした。壊れたときにクラッシュしてくれるパイプラインは、信頼できるパイプラインです。この5ヶ月でクラッシュしてくれた障害はほとんどなかったです。

2. 人間をどこに置くかがアーキテクチャそのもの。 ゲートの数ではなく位置です。途中に3つあった長尺は無人化できず、最後に1つだけのショートは無人化できた。クーロン事故の根治策も「人間がもう一押しする」でした。

3. ドメイン知識が最後の堀になる。 猫は奈良時代に仏典を鼠から守る船に乗って日本に来たので、縄文・弥生のシーンには出せない。縁側は1階の建築要素なので「茶屋の二階から縁側越しに」というプロンプトは矛盾している。行灯の炎は行灯の中にある。こういう判断はどのモデルにも入っていなくて、これが他の無数のAI雨音チャンネルとの違いの全部です。

4. 外部モデルへの依存は、維持し続けるもの。 運用中にKling AIの料金プランが突然変わり、動画エンジンを4日間で2回乗り換えました。プロンプトはエンジンが変わると意味ごと変わります。この話は「Klingが値上げした日」に書きました。

動画を「資産」として扱う話はこちらの記事にも書いていますが、デモではなく本番で何ヶ月も動き続けているこのチャンネル自体が、私たちにとってはAIエージェントの実運用データを毎日生み続ける資産になっています。

AIエージェントを業務に組み込むことを検討されている方は、お気軽にご相談ください。この記事に書いたような泥臭い部分も含めて、実体験からお話しできます。