はじめに
動画を 1 本作るには、情報収集・分析・台本・映像設計・品質確認・サムネイル制作という異なる認知作業が積み重なる。これをひとつの AI エージェントに「動画を作ってください」と渡したらどうなるか。
答えは単純で、どこかが薄くなる。台本の論理構成に集中しすぎると映像設計が雑になる。見た目の調整に入ると今度は数値の正確さが落ちる。長いタスクほど前半の判断が後半に引きずられる「コンテキスト汚染」も起きやすい。八雲の動画制作システム Montage を設計する中で、この問題に何度もぶつかった。
課題: 単一エージェントで全部やる限界
AI にひとつのロールをすべて担わせると、次の 3 つの問題が出てくる。
深度が均一になる。 情報収集フェーズと映像設計フェーズは、求められる思考の種類がまったく異なる。前者は事実の網羅・検証、後者はビジュアル構成の創造的判断だ。同じエージェントが両方をやると、どちらも「それなり」の品質に収束しやすい。
責任の境界がない。 品質に問題が出たとき、どの判断が原因かを特定できない。「台本が悪いのか、映像設計が悪いのか、データが悪いのか」が一塊で埋まってしまう。修正の起点が曖昧になる。
コンテキストが飽和する。 決算資料・市場データ・過去動画・ナレーション設定・レイアウト規約……これらを全部 1 エージェントが抱えると、コンテキストウィンドウの圧迫が避けられない。後半の判断品質が落ちる。
アプローチ: 役割を分けたパイプライン
Montage では動画制作を 6 つのロールに分割している。
Researcher → Analyst → Scriptwriter → Composer → Reviewer → Thumbnailer各ロールはひとつのことだけを行い、前ロールの出力を受け取り、次ロールへの入力を生成する。ロール間の境界が明確なため、問題が起きたとき「どこまでは正しくて、どこから崩れたか」がファイルレベルで追跡できる。
各役割の入出力
| ロール | 入力 | 出力 | モデル |
|---|---|---|---|
| Researcher | ticker / 企業名 | input.json（決算・IR・マクロ指標の生データ） | Sonnet |
| Analyst | input.json | analysis.json（洞察・ストーリーライン・強調数値） | Sonnet |
| Scriptwriter | input.json + analysis.json | scripted.json（章立て・シーン構成・ナレーション・字幕） | Sonnet |
| Composer | scripted.json | composed.json（レイヤーベースのシーン映像設計） | Opus |
| Reviewer | final.json + MP4 スクリーンショット | review-result（OK / NG + 原因分類） | Sonnet |
| Thumbnailer | final.json | thumbnail.json（サムネイル構成・インパクト数値選定） | Sonnet |
Researcher は Bash ツールのみを持ち、単一スクリプトで全リサーチを完結させる。Analyst と Scriptwriter は Read / Write のみで、過去の実行ログを汚染しない設計だ。Composer だけは Opus を使う——映像設計はレイアウト選択・チャート選択・アニメーション設計の創造的判断が集中するため、最も推論品質を要求するロールだからだ。
Reviewer はスクリーンショットを目視確認し、NG の原因を scene-layout / narration / duration / rendering-bug / brand-mismatch に分類して出力する。この分類が、後述するリトライ先の判断に直結する。
producer エージェントが指揮、config/pipelines/*.json で構成
6 つのロールを誰が呼び出すのか。Montage では producer エージェントがパイプラインの指揮者を担う。
producer は config/pipelines/long-video.json を読み込み、「どのエージェントを、どの順で、何を渡して起動するか」の実行計画をメインスレッドに返す。実際の呼び出しはメインスレッドが Agent ツールで行う——Claude Code では sub-agent が更に sub-agent を spawn できない制約があるため、producer はアドバイザとして計画を立て、実行はメインスレッドに委ねる設計になっている。
long-video.json の構造はシンプルだ。
{
"steps": [
{ "phase": 1, "name": "researcher", "input": "...", "output": "input.json" },
{ "phase": 2, "name": "analyst", "input": "input.json", "output": "analysis.json" },
{ "phase": 3, "name": "scriptwriter", ... },
{ "phase": 4, "name": "composer", ... },
{ "phase": 7, "name": "reviewer", "retry": { "rules": [...], "maxRetries": 3 } },
{ "phase": 8, "name": "thumbnailer", ... }
]
}Reviewer フェーズには retry.rules があり、NG 原因に応じた差し戻し先が定義されている。scene-layout なら Composer へ、narration なら Scriptwriter へ、rendering-bug なら system-developer へ。最大 3 回リトライして解消しなければユーザーに報告して停止する。
パイプラインの定義を JSON に外出しすることで、チャンネルごとの挙動変更（Composer の並列起動・使用モデルの切り替え・リトライ条件）をコード変更なしに調整できる。
運用してわかった効果と落とし穴
効果
品質劣化の原因が特定できる。 「この動画の説明が浅い」という指摘が来たとき、analysis.json を開けば原因が Researcher なのか Analyst なのかすぐわかる。修正のループが小さくなった。
ロールごとにモデルを最適化できる。 Researcher は決定論的なスクリプト実行が主体なので Sonnet で十分。Composer の映像設計だけ Opus に振る——という判断がロール分割によって可能になった。コスト効率と品質のバランスが取りやすい。
並列化の下地ができた。 producer に parallelMode: "auto" を設定すると、Composer の章単位並列起動が有効になる。5 章以上の動画では各章を独立したエージェントが担当し、処理時間を大幅に短縮できる。これはロール境界が明確でないと成立しない。
落とし穴
Composer に渡すコンテキストの設計が難しい。 block-schemas.md は巨大で、全部渡すとトークンを無駄に消費する。必要なブロック定義のみを参照させる運用ルールを整備するまで、コスト管理が難しかった。
Reviewer の NG 分類精度がリトライ効率に直結する。 分類が scene-layout なのに Scriptwriter に戻すと、同じ NG が繰り返される。ルーブリック（specs/quality/rubrics.json）の粒度が甘いと原因分類もブレる。品質基準の整備は地道な作業だ。
「エージェントを追加すれば解決」思考のリスク。 問題が出るたびに新しいロールを挿入したくなるが、ロールを増やすほど接続点が増えてデバッグが複雑になる。「このロールの責務を明確に定義できるか」を常に自問する必要がある。
まとめ
Montage のパイプライン設計を一言で表すなら「認知作業の分業化」だ。データ収集・分析・台本・映像設計・品質確認・サムネイル制作——それぞれ異なる種類の判断を要求する作業を、専用ロールに分割することで品質と追跡性を両立している。
重要なのは config 駆動の構造だ。どのロールを・どの順で・どのモデルで動かすかを JSON に外出しすることで、チャンネル特性に応じた調整がコードに触れずに行える。
パイプライン設計の考え方は Yakumo の AI 駆動開発のリアル に、エージェント組織の委任構造については 領域責任者エージェントパターン に詳しく書いている。コンテンツ生成に限らず、複数の AI が連携するシステムを設計する際の参考になれば幸いだ。