この記事は Zenn と note にも同じ内容を載せています。Zenn: https://zenn.dev/suisei498/articles/c5067b2aedb44c ／ note: https://note.com/suisei498/n/na32bb3983827
2026年の6月から、自宅のPCで YouTube のショート動画を数チャンネル、毎日自動で作って投稿しています。組み立ても、壊れたときの調査も、ほとんど Claude Code と一緒にやりました。
「Claude Code で動画を全自動で作ってみた」という記事はたくさんありますが、作ったあと数か月回すと何が壊れるかの記録は少ないので、それを書きます。
壊れ方には共通点がありました。どれも「成功」を返していたことです。
全体の流れ
毎日決まった時刻に、Windows のタスクスケジューラから次の順で動きます。
- ネタ選びと台本（Claude の API）
- 読み上げ音声（VOICEVOX）
- 画像（ローカルGPUでの生成と、素材）
- ffmpeg で字幕・BGM・映像を合成
- 自動の品質チェック（Claude にサムネイル・映像のコマ・台本を見せて判定。不合格なら作り直し。上限あり）
- 非公開でアップロード（YouTube Data API）
- サムネイルの設定（YouTube Studio をブラウザで操作）
- スマホに通知。公開は人が見てから
通知には「作り直し」のボタンがあり、押すとPCで常駐しているプログラムが同じ工程をやり直します。
Claude Code の役割は、この各工程のスクリプトを書くことと、壊れたときに原因を突き止めることです。後者の方がずっと時間を使いました。
1. サムネイルが33本、設定されていなかった
8月下旬から9月初めの約2週間で、33本の動画にサムネイルが入っていませんでした。
奇妙だったのは、毎日の点検が「要修復 0本」と報告し続けていたことです。
原因は2つ
ひとつめは、画面の外に置いたブラウザが「手を抜いていた」ことでした。サムネイルの設定は、ブラウザ（Chrome）を自動操作して Studio の画面から行っています。作業中の画面のじゃまにならないよう、ウィンドウを画面の外に置いていました。
Chrome は、見えていないウィンドウの描画やタイマーを間引きます。Studio の保存処理は画面の中のスクリプトで動くので、間引かれると30秒の待ち時間に終わりません。Chrome の起動オプションに次の3つを足すと、同じ動画が30秒で失敗→18秒で成功に変わりました。
--disable-backgrounding-occluded-windows
--disable-renderer-backgrounding
--disable-background-timer-throttling
ふたつめは同時実行です。ブラウザの同じプロファイルを、5つのプログラムが開こうとしていました。失敗した時刻を並べると、複数のタスクが重なる時間帯に集中していました。プロファイルを使う前にロックを取るようにして解消しました。
点検が見つけられなかった理由
点検は、公開されているページのサムネイル画像のURLを見て判定していました。ところが、それで分かるのは「設定したのに YouTube が使っていない」状態だけで、「そもそも設定されていない」は区別できません。
YouTube Data API で動画の情報を取っても同じで、サムネイルが未設定でも、設定済みと同じ形のURLが返ってきます。手元の259本で確かめたところ、全部そうでした。
結局、Studio の一覧画面を読んで判定する点検を別に作りました。33本のうち32本を入れ直し、未設定が0本になったことを、その新しい点検で確かめています。
2. 音声の頭が0.8秒欠けていた
動画の最後に「チャンネル登録お願いします」のような締めの一言を入れています。これが毎回、頭の0.8秒ほど欠けて聞こえるという症状でした。
対症療法を重ねてしまった
最初は、音声の前に無音を足す、音量を上げる、BGMを下げる、といった手当てを Claude Code と一緒に何度も入れました。どれも決定打になりませんでした。
欠ける長さが、設定を変えても一定だったことが手がかりでした。音量や位置の問題なら、設定に応じて変わるはずです。一定なのは「時間がずれている」からでした。
真因
最後の合成で、BGMを混ぜる処理（amix）と映像のエンコードを、ffmpeg の同じコマンドで同時にやると、音声のサンプルが全体に約2%ずつ間引かれていました。37.45秒あるはずの音声が36.66秒になり、映像より約0.77秒短い。そのぶん締めの一言が前倒しで鳴り、頭が欠けたように聞こえていたのです。
厄介なのは、ファイルの情報（メタデータ）上の長さは正常な値を示していたことです。最初はその数字を比べて「差は18ミリ秒、正常」と判断し、見当違いの方向に進んでいました。実際の長さは、音声を最後までデコードして数えないと分かりませんでした。
直し方は、合成を2段に分けることでした。
- 音声とBGMだけを混ぜて、いったん WAV に書き出す
- 映像とその WAV を合わせる（ここでは混ぜる処理をしない）
音声と映像のずれは −769ミリ秒 → −2.8ミリ秒 になり、それまでに入れた手当ては全部取り除きました。
3. 同じ題材を、ほぼ毎日公開していた
雑学のチャンネルでは、過去に扱った題材と重ならないよう、台本を作るたびに重複を検知しています。重複していたら作り直します。
ログを読み返すと、検知はちゃんと働いていました。問題はその後で、作り直しを2回しても重複が残った場合は「そのまま続行（要確認）」として公開する作りになっていて、それがほぼ毎日起きていました。
原因は、作り直してもジャンルが同じままだったことです。同じジャンルのまま言い直させると、言語モデルは同じ題材の近くに戻ってきます。
- 作り直しの上限を 2回 → 4回に増やし、2回目からはジャンルごと変える
- ただしジャンルは「まだ試していないもの」から選ぶ（最初の実装では順番に進めたため、一周して元のジャンルに戻り、同じ題材に舞い戻った）
- それまでに不採用になった題材の語を全部まとめて次の指示に渡す
あわせて、検知の取りこぼし（送りがなを挟む「揚げ物」のような語を拾えていなかった）も直しました。実際に起きた重複5組で試して、5組とも検知できることを確かめています。
4. 「作り直し」ボタンが10日間、死んでいた
通知の「作り直し」ボタンを受け付ける常駐プログラムが、8月末から10日間、止まっていました。ボタンを押しても何も起きません。ただ、押す機会が少なかったので、しばらく気づきませんでした。
止まった原因は、今も分かっていません。対策として、1時間ごとに生きているかを確かめ、止まっていたら起動し直すタスクを足しました。原因が分からないものは、止まっても自動で戻る形にしておく、という割り切りです。
Claude Code と組んでみて
数か月やってみての実感です。
- 組み立ては速い。工程を1つずつ作って、つなぐところまでは、ほとんど詰まりませんでした
- 壊れたときに、対症療法を重ねやすい。音声の頭欠けがまさにそうで、「それらしい手当て」を何度も提案され、私もそれを受け入れていました。流れが変わったのは、測った数字を出してもらい、その数字で判断するようにしてからです
- 「成功」の戻り値を信じない。サムネイルの保存、APIの応答、点検の「0本」、ファイル上の長さ。今回の失敗は、どれも仕組みの側は成功と言っていたものでした。いまは、結果そのものを別の方法で数え直すことを、作業の最後に必ず入れています
定時のタスクが黙って動かなくなる件（ログオンしていないと起動しない、など）は、別の記事に書きました。