Claude Codeで解説動画を作り続ける：スキルで制作を任せる仕組み

はじめに

YouTube の解説チャンネル「まどろみ研究所」の動画は、Markdown の脚本から自動で作っています。

動画を作る仕組みは Remotionを使わずに動画を自動生成する：Next.js＋Playwright＋ffmpeg
ナレーションの声は Style-Bert-VITS2 で自分の声を学習させたもの（Style-Bert-VITS2で自分の声を学習する）

この記事は、その仕組みを誰が動かしているかの話です。

答えは、ほとんど Claude Code です。題材の調査、読み物の下書き、脚本、図、ナレーションの合成、撮影、撮る前の検査、投稿文の下書きまで、1本の動画の作業の大半を Claude Code に任せています。これまでに100本以上を、Claude Code と一緒に作ってきました。

ただ、最初からうまく任せられたわけではありません。この記事では、任せられるようになるまでに作ったものを書きます。

人と Claude Code の分担（何を任せて、何を手放さないか）
制作の手順を「スキル」にする
指示文を5版まで直した経緯
落とし穴を、決まった書式で溜め続ける
「仕組み」と「中身」の境目を決めておく
次にやることを、ファイルに書き戻す

1. 人と Claude Code の分担

まず、分担はこうなっています。

人がやること	Claude Code がやること
題材を選ぶ	題材の調査（論文や一次情報を読んで、出典と一緒にまとめる）
読み物（下書き）を読んで、直させる	読み物の下書き、脚本、図、ナレーションの合成
動画を見て、出すかどうかを決める	撮影、撮る前の検査、投稿文の下書き
コミットする	ファイルの編集まで（git は触らない）

線を引いた考え方は、制作の設計を書いた文書の最初にある一文に集約されています。

担当をスキルに分けてよい。ただし「承認」だけは絶対に渡さない。

作業は渡す。判断は渡さない。 書くのも、それを精査するのも AI になったら、人間が1本も触っていない動画ができてしまいます。それは、ただのテンプレートの量産です。

だから、「どれをやるか」「何を落とすか」「出すかどうか」は人が決めます。速くしなくていい部分です。
逆に、候補を並べる・下書きを書く・決まった演出を当てる・検査する、といった作業は、速いほどいいので任せます。

git もその1つです。リポジトリの CLAUDE.md に「Claude はリポジトリの状態を変える git 操作を一切しない」と書いてあり、Claude Code が変えるのはファイルの中身だけです。何をどの単位でコミットするかは、人が差分を見て決めます。

2. 制作の手順を「スキル」にする

Claude Code には、作業手順を .claude/skills/<名前>/SKILL.md に書いておくと、関係する作業のときに自動で読み込む仕組み（スキル）があります。
動画1本を作る手順は、episode というスキルにまとめました。

---
name: episode
description: >-
  apps/* のチャンネルで動画を1本作るときの手順と規則。
  題材が決まってから投稿の清書を書き戻すまで。
  「動画を作る」「脚本を書く」「図を足す」「ナレーションを付ける」
  「投稿の準備をする」ときに使う。
---

description に「どんな言葉で頼まれたら使うか」を書いておくのがポイントです。「脚本を書いて」と頼むだけで、この手順が読み込まれます。

本文は、通しの手順の表から始まります。

段	やること
1	調査して `research.md` に溜める
2	脚本 `script.md` を書く
3	その回だけの図を書き、チャンネルに登録する
4	組み立てて、撮らずに検査する
5	無音で撮って、人に見せる
6	ナレーションを合成し、実測で尺を引き直す
7	音付きで撮る
8	投稿の準備をする
9	サムネイルを撮る
10	次にやることを書き戻す（7章）

各段のコマンドも表に書いてあるので、Claude Code は順にコマンドを叩いていけば1本ができます。

スキルには「踏んで直したこと」だけを書く

スキルの冒頭には、こう書いてあります。

ここに書いてあるのは、実際に踏んで撮り直した結果だけ。推測で足さない。

たとえば、脚本の数字の書き方です。台詞に漢数字で書くと字幕に漢数字が出る、アラビア数字で書くと読み違える。そこで、アラビア数字にルビ（読みがな）を振る書き方に決めました。

書き方	字幕	読み上げ
`四十パーセント`	❌ 四十パーセント	⭕
`40パーセント`	⭕	❌ 読み違える
`40《よんじゅっ》パーセント`	⭕	⭕

「石けん」が「イシケン」と読まれた、という失敗も、そのまま規則になっています（漢字とひらがなが混ざった語は、漢字だけ訓読みされる）。

こういう規則は、一般論として書いても AI は守りません。どの回で何が起きて、どう直したかまで書くと、次の回で同じことをしなくなります。スキルは、1本作るごとに少しずつ増えていきます。

3. 脚本の前に「読み物」を挟んだ

途中で、手順を1段増やしました。調査と脚本のあいだに、ブログ記事のような読み物（article.md）を書かせる段です。

きっかけは、人の確認がつらかったことです。
それまでは、脚本から3分の無音の動画を撮って、それを見て「出せるか」を判断していました。動画を見ながら中身の正しさと分かりやすさを判断するのは、思った以上に疲れます。

読み物にすると、こうなりました。

読むだけで判断できる。 分かりにくい所に赤を入れるのも簡単
直しが安い。 撮る前なので、何度書き直させても時間がかからない
脚本が読み物から起こせる。 中身が固まってから、台詞と図に分ける

ある回では、読み物を2回書き直させました。1回目は専門用語が残って難しく、2回目は「小学5年生でも分かるくらいに」と頼んで、専門の名前を外し、自転車の空気入れやスプレー缶のような身近な体験に置き換えてもらいました。

いまの指示文が「research.md と article.md はできています」から始まるのは、この段を経ているからです。

4. 指示文を5版まで直した

1本作るたびに Claude Code に渡す指示文は、5回書き直しました。版ごとの違いはこうです。

版	変えたこと
1	思いついた順に頼んでいた（脚本を作る、図はたくさん動かす、色を多用する、声は学習させた声で…）
2	手順を番号付きにし、「途中で止まらずに最後まで」「迷ったら自分で決めて、理由を報告」を入れた。図の作り込みを数で書いた
3	画面の向こうの一人に話しかける形と、効果音を足した
4	写実の見た目にするため、「脚本より先に、実物の写真を見て寸法と材質を書き留める」段を足した
5	3D の道具を替える試みに合わせて、先に読む文書の一覧を足した

この中で、効いたことが3つあります。

形容詞を、数に直す

1版目は「図は過剰に動くようにする」「いろんな色を多用してみてください」のような頼み方でした。これだと、どこまでやれば足りるのかが伝わりません。

2版目からは、数に直しました。

・過剰に動かす。止まっている場面を1つも作らない。どの場面にも、ひとりでに動き続ける物を3つ以上置く。
・カメラも止めない（寄る・引く・回り込む・人の目から見る）。5秒以上、画面が変わらない所を作らない。
・いろんな色を使う。場所ごとに色の組み合わせを変え、どの画面にもはっきり違う色を5色以上入れる。

「3つ以上」「5秒以上」「5色以上」と書けば、Claude Code は自分で数えて確かめられます。人も、できあがったものを同じ基準で見られます。

止まらずに最後まで進め、迷ったら理由を残させる

下の1〜5を、途中で止まらずに最後まで進めてください。
迷ったところは自分で決めて、決めた理由を最後の報告に書いてください。

1本の制作は長いので、迷うたびに止まって質問されると、その間ずっと待つことになります。
「自分で決めていい。ただし理由を残す」にすると、最後まで走ったうえで、判断の中身はあとから確かめられます。おかしな決め方をしていたら、そこだけ直させればいい。

「最後の報告」の中身を決めておく

指示文の最後には、報告に入れてほしいものを並べています。

最後の報告
・動画の場所と尺
・登場人物と舞台の一覧（その人たちにした理由）
・全場面の静止画を並べた画像
・直したこと、残っている問題、git add するファイルの一覧

いちばん効いたのは「全場面の静止画を並べた画像」です。動画を頭から見なくても、1枚の画像で全体の出来がだいたい分かります。
「git add するファイルの一覧」があるので、コミットするときに、関係のないファイルを混ぜずに済みます。

5. 落とし穴を、決まった書式で溜める

CLAUDE.md には、こう書いています。

どのチャンネルでも起こりうる事象を踏んだら、そのとき書く。後でまとめて書かない。

置き場所は docs/platform/pitfalls.md という1つのファイルで、1件をこの5行で書きます。

### N. 一行で言うと何が起きるか

- **症状:** ログや画面に何が出るか（コピペで検索できる文字列を入れる）
- **原因:** なぜ起きるか
- **対処:** どうすれば直るか（コマンドやファイル名まで）
- **該当:** どのチャンネルが該当するか
- **記録:** YYYY-MM-DD ／ 出典（実測したファイルや行）

ファイルの頭には「症状から引く索引」の表があり、エラーメッセージや見えている現象から、該当する項目を探せます。
実装で詰まったら、Claude Code はまずこのファイルを見ます。同じエラーを前に直していれば、そこで解決します。

いまは157件たまっています。

「推測は書かない」

このファイルのルールで、いちばん大事なのはこれです。

推測は書かない。実際に踏んで、直して、直ったことを確認したものだけ。

AI に調べさせると、「たぶんこれが原因」という推測が、もっともらしい文章で出てきます。それを溜めると、次に読んだ AI がその推測を事実として扱います。
だから、原因が分からないものは「分からない」と書かせています。実際、撮り直すたびにハッシュが変わる件は、「原因は特定できていない。分かっているのは範囲だけ」と書いたまま残っています。

書式を5行に揃えているのには、もう1つ理由があります。たまった項目を、あとでそのままスキルに切り出せるようにするためです。溜まってから整形するのではなく、書くときに整形させています。

6. 「仕組み」と「中身」の境目を決めておく

リポジトリは、動画を作る仕組み（packages/）と、チャンネルの中身（apps/）に分けています。

置き場	持つもの	持たないもの
`packages/renderer/`	脚本を読む・撮る・音を混ぜる	特定の回の絵
`apps/<チャンネル>/episodes/`	脚本と、その回だけの図	仕組み
`apps/<チャンネル>/scenes/`	図の登録と、何度も使う舞台	—

どちらに置くか迷ったときの判定は、一言で決めています。

「2チャンネル目でも、そのまま使うか？」
使う → packages/。使わない → apps/<チャンネル>/。

AI に作業を任せていると、この境目がいちばん崩れやすいところです。その回の絵を描くついでに、仕組みの側に特定の回の都合を書き込んでしまう。それが積み重なると、仕組みが特定の回の事情だらけになります。

境目を一言で書いておくと、Claude Code はファイルを置く前にこの問いで判断できます。
図の種類を足すときも、「チャンネル側の2か所（schemas.ts と views.tsx）に登録するだけで、仕組み側は触らない」と決めてあるので、1本の回の作業が仕組みを壊すことがありません。

7. 次にやることを、ファイルに書き戻す

Claude Code は、会話が変わると前の作業を覚えていません。
そこで、1本作り終えるたびに、docs/youtube/next-actions.md に「次にやること」を書き戻させています。スキルの手順の最後の段です。

スキルには、こう書いてあります。

次にやることを書き戻す。忘れると次の回で止まる。

サムネイルの差し替えをどこまで試したか、予約済みの回がどれか、といったことは、ここにしか残りません。次の会話の Claude Code は、まずここを読んでから始めます。

人にとっても便利です。数日あいても、このファイルを読めばどこまで進んでいたかが分かります。

8. 任せきれなかったこと

正直に書いておくと、任せきれていないこともあります。

耳で聞かないと分からない読み違い。 合成の前の読みを機械で確かめても、声にすると違って読まれることがありました。これは人が通しで聞いて見つけるしかありません
出来の良し悪し。 「つまらない」と判断して没にした回があります。検査で測れるのは文字の重なりや尺までで、面白いかどうかは人が見て決めています
道具の選び直し。 3D の道具を Unreal Engine に替える試みは、2本作って撤退しました。撤退の判断は、Claude Code の報告の数字を見て人がしました（この話は別の記事で書く予定です）

AI に任せる範囲が広がるほど、人の仕事は「1本ずつ作る」から「型を直す」と「1本ずつ承認する」に移っていきました。

おわりに

Claude Code に動画制作を任せて分かったのは、AI に渡すべきなのは「頼みごと」ではなく、型だということです。

手順はスキルにして、踏んで直したことだけを書く
指示文は、形容詞ではなく数で書き、報告の中身まで決めておく
落とし穴は、推測を混ぜずに、決まった書式で溜める
仕組みと中身の境目を、一言で書いておく
次にやることは、会話ではなくファイルに残す

そして、出すかどうかの判断だけは、人が持ち続けます。

この連載では、最後に、3D の回を Godot でコードだけで撮っている話を書く予定です。
作った動画は「まどろみ研究所」で公開しています。