プロデューサー方式のマルチエージェント分業で、個人開発の動画制作を“録画ボタンを押すだけ”にした話

はじめに

個人開発の動画制作を、AIの分業体制で “録画ボタンを押すだけ” にしました。問題作成・画面開発・録画・編集・アップロード・告知——全部AIに役割分担し、自分はコードを一行も書いていません。3年間あきらめ続けていたチャンネルが、その体制でようやく動き出しました。

ここに至るまでの話を、まず時系列で振り返ります。

2022年、NodeCGという技術に出会いました。クイズ画面を作り、ライブ配信で視聴者がコメントで回答する——テレビの「オールスター感謝祭」のようなものが作れると思いました。コンテンツは基本情報技術者試験の勉強に役立つクイズを考えていました。

当時の試作チャンネル: www.youtube.com/@hfcit250

しかし NodeCG は Vue.js など周辺知識が必要で、独学は難航しました。そのまま停滞してしまいます。

2024年、ChatGPT が広まって再始動しました。コードを作ってもらい、おおよその形にはなりました。ただし HTML / CSS のデザインがうまく反映されず、修正のやり取りに時間がかかります。そのころ双子が生まれ、また頓挫しました。

2025年12月、停滞していたシステムを流用し、今度は双子のための学習コンテンツとしてチャンネルを再始動しました。これが StepQ の始まりです。ターゲットも資格試験から1〜2歳向け語彙クイズへ変わりました。

ChatGPTでも動くものはできました。ただし2つの問題が残ります。

修正のやり取りに時間がかかる — 1回の会話で完結せず、何往復もする
問題作成の精度が低い — Excelの問題集に誤りが多く、何度も作り直す

2026年4月、Claude Code を学んだことで状況が変わりました。以前この記事を書いています。

Claude Codeを120%使いこなす設定3選【ECC・Memory.md・Obsidian連携】

前記事の3設定をひとことで: ECC（エージェントを役割テーブルで自動起動する仕組み）、Memory.md（セッションの長期記憶ファイル）、Obsidian連携（Markdownナレッジベースの共有）

問題作成・画面開発・動画編集・アップロードをセッションに委譲できるようになり、自分がやることは「何を作るか」の判断だけになっていきました。

そもそも、双子の育児と本業の合間に、自分でコードを書く時間はありません。だから「判断だけして実装はAIに渡す」体制にせざるを得ませんでした。結果的にそれが、属人化しない分業設計につながりました。

この記事は、その3設定を実際のプロダクトに投入した結果として、5つの専門セッション＋指揮役のプロデューサーセッション という体制がどう生まれ、どう機能しているかの話です。

この記事でわかること

Claude Code を複数セッションに分業させる設計方法（プロデューサー方式）
指示書・報告書（ハンドオフ文書）によるセッション間連携の実例 — 実物サンプル付き
1つのセッションで解決できなかった問題を、AI同士の連携で解決させた実例
マルチセッション構成でも残る「穴」と、その見つけ方

想定読者: Claude Code を使っているが1セッションで完結させている人 / 個人開発で「作りたいけど手が足りない」人 / 育児や本業の合間に開発している人

StepQとは

双子の子どもの成長に合わせて、一緒に作り続けているYouTubeチャンネルです。

1〜2歳向けに語彙クイズ動画を届けています。「くだもの」「どうぶつ」「のりもの」などの画像クイズを2択形式で出題します。選択肢2つ・タイマー12秒・1Partあたり3〜5問という設計は、幼児言語発達の研究文献を参照して決めました（後述します）。

チャンネル: ステップQ | 年齢と一緒に育つクイズ

現在公開中のカテゴリ：くだもの / のりもの / どうぶつ / どうぶつのおと

数字で言うと、パイプラインを組んでから約1ヶ月半で 公開動画15本＋公開待ちの完成動画が約18本。問題集のExcelは baby 向け全6カテゴリ × Part①②③ に加えて、おとクイズ・フラッシュカード形式まで自動生成で揃っています。ChatGPT時代は1本の動画に何日もかかっていたのが、いまは「問題データとOP素材があれば、録画開始から YouTube への非公開アップロードまで人の手はゼロ」です。

前回の3設定は実際にどう機能しているか

まず、前回紹介した設定がこのプロジェクトで実際にどう使われているかを説明します。

Memory.md ——各セッションの「個人の記憶」として

前回紹介したMemory.mdは、今回も各セッション固有の情報を保持するために使っています。セッションごとに担当領域が違うため、それぞれが自分の状態を記憶するための場所として機能しています。

claude-automation/Memory.md       ← スクリプト一覧・launchd設定・既知の問題
quiz-bundle/Memory.md             ← NodeCG構成・Replicant一覧・未解決問題
StepQ問題作成/memory/MEMORY.md    ← 問題集の生成手順・カテゴリ一覧
video-design/Memory.md            ← 生成済みOP/ED・ffmpeg設定メモ
StepQ-SNS/memory/MEMORY.md        ← 投稿スケジュール・Postiz設定

（命名が Memory.md 形式と memory/MEMORY.md 形式で揺れているのは、セッションを立てた時期の差です。実態に忠実に書いています。）

各セッションは自分のMemory.mdを読んで「自分が今どこにいるか」を把握します。セッションが長期になっても、前回の続きから始められます。

Obsidian連携 ——プロジェクト全体のナレッジ共有として

前回はZenn/Qiitaのニュース収集が主な用途でした。今回はStepQ全体に関わる知識の共有場所として活用しています。

claude-automation/docs/AI-DataBase/projects/StepQ/knowledge/ 以下に調査資料を蓄積しており、どのセッションからも参照できます。

language-learning/ — 幼児言語発達の研究知見（小椋/神戸大・WHO・文科省等）
recording/ — macOS での録画の落とし穴と解決策
ffmpeg/ — ffmpeg の挙動調査と比較結果

タイマー12秒・選択肢2択・1Partあたり3〜5問という設計値はすべてこのナレッジベースの研究知見から来ています。

ECC ——実際に呼ばれているエージェント

前回「CLAUDE.mdに役割テーブルを書けば自動で呼ばれる」と紹介しました。実際に稼働しているものを挙げます。

エージェント	使われるタイミング
`code-reviewer`	スクリプト・コードを新規作成・修正したとき
`security-reviewer`	認証情報・API・外部通信に関わるコードを触ったとき
`planner`	複数ファイルにまたがる新機能を実装するとき（実装前）
`tdd-guide`	バグ修正・新機能追加のとき（実装前）

特に planner は重宝しています。「Excelの問題集を読み込んで録画して編集してアップロードする」というパイプラインを設計するとき、実装前に全体像を整理してもらいました。

指揮系統の一元化——プロデューサーセッションの役割

体制の全体像を先に示します。実働する5つの専門セッションと、それらを指揮するプロデューサーセッションの計6つです。

セッション	役割
StepQ問題作成	問題データ（Excel）の生成
video-design	OP/ED動画・サムネイル画像の生成
quiz-bundle	クイズ配信画面（NodeCG）の開発
claude-automation	録画・編集・YouTubeアップロードの自動化
StepQ-SNS	X投稿の作成・スケジュール登録
StepQProject（プロデューサー）	全体の指揮。コードは書かない

専門セッションが並立しているだけでは機能しません。今回の設計の核心は、すべての指示と報告を1つのセッションに集約することです。

この設計を採用したのは、こちらの記事の考え方を参考にしたからです。

設計書・コード・テストを全部AIに書かせて半年間開発してみたよ

記事の4.3設計では、プロンプトを直接入力するのではなくプロンプトファイル（指示書）を通じて作業させることで、以下の利点があると述べられています。

属人化の防止 — アウトプットの品質が個々人のプロンプト作成能力に依存しなくなる
ノウハウの蓄積 — 指示書が積み重なることでチームの知見が資産化される
知識の移転 — 開発完了後にそのノウハウを他チームにそのまま移転できる

この考え方をそのまま採用しました。プロデューサーを通じた指示書・報告書の蓄積が、属人化しない開発体制を作ります。

プロデューサーの役割はシンプルです。

ユーザーから「やりたいこと」を受け取る
各専門セッションへの指示書を作成して渡す
各セッションから完了報告書を受け取る
報告内容を確認して次の判断を下す

コードは書きません。設計と判断に専念します。

ユーザー
  ↓「のりものの動画を作りたい」
プロデューサー
  ↓ 指示書を作成
  ├─ 問題作成セッション：「のりもの Excel を生成して」
  ├─ video-design セッション：「のりもの OP を生成して」
  └─ automation セッション：「録画・編集・アップロードして」
  ↑ 各セッションから完了報告書が届く
プロデューサー
  ↓ 内容確認・次の指示
ユーザーへ報告

この構成の利点は、ユーザーが各セッションの詳細を把握しなくてよい点です。「のりものの動画を作りたい」とプロデューサーに伝えるだけで、あとは指示書が各セッションに届きます。

現在は、指示書が作成された後にユーザーが各セッションを開いて「指示書を確認して作業してください」と伝えています。ただし「指示書が届いたら自動的に作業を開始する」という自動化は技術的に可能です。Claude Code にはヘッドレスモード（claude -p "プロンプト" で非対話実行）があるため、指示書ファイルの作成を検知して各セッションを起動する仕組みは launchd や hooks で組めます。今後の拡張として考えています。

セッション間の連携設計——ハンドオフ文書

プロデューサーと各セッション間のやりとりは、すべて Markdownファイル（ハンドオフ文書） で行います。

docs/handoff/
├── 2026-06-09_from-producer_to-automation_vehicle-recording.md  ← 指示書
├── 2026-06-09_from-automation_to-producer_vehicle-recording.md  ← 完了報告書
└── ...

命名規則: YYYY-MM-DD_from-<送付元>_to-<宛先>_<トピック>.md

この形式で運用した結果、ハンドオフ文書は 150件を超えました。これがそのままプロジェクトの開発ログ兼ノウハウ資産になっています。

指示書には以下を書きます。

背景と目的
実行するコマンド（コピペできる形式）
完了報告書のパスと記載すべき内容

実物の指示書（短縮版）を1つ載せます。サムネイル生成スクリプトのバグ修正を automation セッションに依頼したものです。

# 指示書: サムネイル生成バグ修正 + YouTube更新
**宛先**: claude-automation セッション
**優先度**: 高（非公開動画の公開前に要対応）

## 修正対象ファイル
scripts/generate_thumbnail.py

## バグ一覧と修正内容
### Bug 1: フラッシュカードのタイトルが "クイズ" になる
現状（line 95–96）:
    quiz_word = "のおとクイズ" if is_oto else "クイズ"
修正:
    is_flashcard = sidecar.get("quiz_type") == "flashcard"
    quiz_word = "のおとクイズ" if is_oto else ("フラッシュカード" if is_flashcard else "クイズ")

（…Bug 2〜6 が同形式で続く…）

## 完了報告
作業完了後、docs/handoff/ に以下を記載した報告書を作成:
- 修正したバグと対応内容
- YouTubeに設定したサムネイル一覧（video_id + 成否）

ポイントは、修正箇所を行番号つきで特定し、修正後のコードまで書いてしまうことです。プロデューサーが調査して指示書に落とし、専門セッションは実行に集中する。報告書のフォーマットまで指示書側で指定するので、報告の品質も安定します。

完了報告書には以下を書かせます。

実行結果（成功・失敗）
変更したファイル・生成した成果物
発生した問題・気になった点

「発生した問題・気になった点」の報告がとくに重要で、プロデューサーが気づけなかった問題をセッションが発見・報告することがあります。

AIが一人で解決できなかった問題——私が調査せずにAI同士で解決した話

5セッション体制で運用しているうちに、印象的なことが起きました。

あるとき video-design セッションがOP動画のアニメーション実装で詰まりました。静止画にズームをかける ffmpeg の zoompan フィルタが意図通りに動かず、あるパターンでは 10秒のはずのOPが2500秒の動画として生成される という奇妙な現象まで起きていました。私はプロデューサーに状況を伝え、「別のセッションに関連情報を調べてもらえないか」と依頼しました。自分で原因を調査したわけではありません。

プロデューサーは claude-automation セッションへの調査指示書を作成しました。automation はウェブリサーチに加えて3パターンの実機テストを行い、原因を特定します。zoompan の d パラメータは「1入力フレームあたりの出力フレーム数」であり、映像入力に適用すると 入力フレーム数 × d 倍の動画が生まれる（250フレーム × d=300 = 75,000フレーム = 2500秒）。静止画に -loop 1 を付けた場合だけ意図通りに動く——という仕様レベルの話でした。

プロデューサーはその調査結果を「パターンA（-loop 1 + zoompan）を使うこと」という video-design への指示書に変換し、video-design が最終的に問題を解決しました（さらに自律的な改善まで行いました）。調査結果は共有ナレッジベースにも保存され、以降のOP生成すべてに適用されています。

この流れを整理するとこうなります。

私：「video-design が詰まっている。別セッションに調べてもらって」
        ↓
プロデューサー：automation に調査の指示書を作成
        ↓
automation：実機テスト＋リサーチで原因を特定・報告
        ↓
プロデューサー：調査結果を video-design への指示書に変換
        ↓
video-design：解決（さらに自律的な改善も実施）

私がやったのは「詰まっていることをプロデューサーに伝え、別セッションへの調査依頼を提案する」だけです。原因の特定も、解決策の立案も、実装も、すべてAIが行いました。

人間のチームで言えば「エンジニアが詰まった → マネージャーに相談 → 調査担当が動く → 解決」とまったく同じ構造です。私はマネージャーへの相談役に徹しただけで、技術的な問題に自分で介入する必要はありませんでした。

1つのセッションでは解決できなかった問題が、役割の異なるAI同士の連携で解決できた。 これがマルチセッション構成で一番伝えたいことです。

指揮系統の一元化が問題発覚に役立った話——ファイル名衝突の事例

5セッション体制の利点がもう一つあります。各セッションが報告書に問題を記録してくれることで、プロデューサーが気づけない問題が浮かび上がります。

あるとき automation セッションに「複数の動画を録画・アップロードしてください」と指示しました。指示書には具体的なコマンドが記載されており、セッションは忠実に実行しました。

その完了報告書にこう書かれていました。

「同日・同問題数の動画を処理したところ、X投稿の下書きファイルが同名になり上書きされました」

指示書には「下書きを生成せよ」とだけ書いてあり、ファイル名の衝突については言及していませんでした。セッションは指示通りに動作したうえで、問題点を正直に報告してくれたのです。

この報告がなければ、ファイルが静かに上書きされたまま気づかずにいたはずです。

原因はファイル名の生成ロジックが YYYY-MM-DD_part-5q.md という形式だったことで、同日・同問題数の動画が2本あると上書きされていました。YouTube動画IDはグローバルにユニークであることを利用して YYYY-MM-DD_<video_id>.md に変更し、以降は重複しなくなりました。

指示書を通じた作業と報告書による返答という形式が、セッションが問題を隠さず報告する文化を自然に作っています。

それでも穴は残る——デーモン再起動の見落とし

きれいな成功談ばかりではありません。マルチセッション構成でも防げなかった失敗を1つ書いておきます。

録画フォルダを監視して自動処理する常駐デーモン（watchdog ベースの Python スクリプト）があります。あるバグ修正で、セッションはスクリプトを正しく修正し、報告書も問題なく提出しました。ところがその後に録画した動画が、修正前の旧コードで処理されてしまったのです。

原因は単純です。常駐デーモンは起動時にコードを読み込むため、ファイルを修正してもプロセスを再起動しない限り旧コードのまま動き続けるのです。コードを直したセッションも、指示書を書いたプロデューサーも、再起動の必要性を指摘しませんでした。

指示書は「コードを直せ」までしかカバーしていなかった
セッションは指示書どおり完璧に作業した
それでも運用知識（デーモンは再起動が要る）の穴はすり抜けた

発覚後は「常駐スクリプト修正後はプロセス再起動必須」をプロデューサーの Memory に記録し、以降の指示書には再起動手順まで含めるようにしました。指示書の品質はプロデューサーの知識の上限に縛られる——これがマルチセッション構成の限界で、失敗のたびに Memory へ還元して上限を上げていくしかありません。

パイプライン全体像

制作の流れをセッション順に並べるとこうなります。

StepQ問題作成（Excel生成） ─┐
video-design（OP/ED生成）  ─┤
                            ↓
quiz-bundle（NodeCGで画面表示）
                            ↓
claude-automation（録画 → 編集 → サムネイル生成 → YouTubeアップロード）
                            ↓
StepQ-SNS（告知投稿のスケジュール登録）

「問題データとOP素材を用意すれば、録画ボタンを押すだけで動画がYouTubeに上がる」という状態です。録画開始から非公開アップロード完了の Slack 通知まで、人の手は入りません（公開ボタンだけは最終確認のため手動で押しています）。

まとめ

前回の記事で紹介した3設定（ECC・Memory.md・Obsidian連携）は、実際のプロダクト制作でこう機能しています。

前回紹介した設定	今回の使われ方
Memory.md	各セッションが自分の状態を記憶するための個人ノート
Obsidian連携	プロジェクト全体で共有するナレッジベース
ECC	code-reviewer / planner 等が各セッションで実際に呼ばれている

加えて今回学んだことをまとめます。

指揮系統を一元化する——ユーザーが各セッションに直接命令するのではなく、プロデューサーを通じて指示・報告を集約する
指示書と報告書を文書化する——セッションが「指示通りに動いたが問題があった」を正直に報告できる仕組みになる
詰まったら調査を別セッションに分離する——人間チームの問題解決と同じ構造で機能する
それでも穴は残る——指示書の品質はプロデューサーの知識に縛られる。失敗のたびに Memory へ還元して上限を上げる

なお、この体制は Claude Code の Pro プラン1つで運用しています。セッションは同時並行ではなく「プロデューサーで指示書を作る → 専門セッションを開いて作業させる」と順番に開くため、Pro 1契約で回ります。

Claude Code のマルチセッション構成は、ツールの設定の話というよりもチーム設計の話です。

この記事の要点（引用・拡散歓迎）

個人開発の動画制作を、Claude Code 6セッション（専門5＋プロデューサー1）の分業で“録画ボタンを押すだけ”にした
やりとりは全部 Markdown の「指示書」と「完了報告書」。150件超が積み上がり、そのまま開発ログ兼ノウハウ資産になった
1つのAIセッションでは解けなかった問題が、役割の違うAI同士の連携で解決した（人間のチームと同じ構造）
それでも穴は残る。指示書の品質は、プロデューサーの知識の上限に縛られる

チャンネルはこちらです。

記事で説明したパイプラインの“出力”がこれです。設計の答え合わせとして覗いてみてください。お子さんがいる方は、ぜひ一緒に。

ステップQ | 年齢と一緒に育つクイズ

もし「自分の開発も分業させてみたい」と思ったら、ストックしておくと指示書の型を見返せます。
あなたはAIに、どこまで任せていますか？どこから先は自分でやりますか？コメントで教えてください。