書籍14章。YouTube動画14本分のスライドと台本。ブログ19本。企業サイト10ページ。
これが、いま1人で制作・運用しているコンテンツの全量だ。PMBOK-AIという書籍プロジェクトを軸に、動画・Web・SEOまで含めた「1人出版社」を回している。
Claude Code MAXの月額$200で開発チームを組めることは以前の記事で書いた。だが、コンテンツ制作になると話が変わる。台本を書きながらスライドを作り、同時にSEOを整える——1つのAIセッションでは手が足りない。
そこで導入したのがClaude Code Agent Teamsだ。
Agent Teamsとは何か
Agent Teamsは、Claude Codeの実験的機能で、複数のClaude Codeセッションをチームとして協調させる仕組みだ。
通常のSubagent（サブエージェント）との違いを整理する。
| Subagent | Agent Teams | |
|---|---|---|
| コンテキスト | 呼び出し元に結果を返すだけ | 完全に独立したセッション |
| 通信 | 親エージェントにのみ報告 | チームメイト同士で直接やりとり |
| 協調 | 親が全体を管理 | 共有タスクリストで自律的に動く |
| 適した作業 | 結果だけ欲しい短い調査 | 議論・レビュー・並行制作 |
Subagentは「調べて報告してくれ」という使い捨ての部下。Agent Teamsは「一緒にプロジェクトを回すチーム」だ。
コンテンツ制作のように、複数の成果物が相互に依存し、品質の整合性が必要な作業にはAgent Teamsが圧倒的に向いている。Claude Codeの運用設計全般と組み合わせることで、より体系的な運用が可能になる。
解決したかった問題
PMBOK-AIの動画コンテンツ制作には、1章あたり以下の成果物が必要になる。
| 成果物 | ファイル | 制約 |
|---|---|---|
| 書籍原稿 | book/XX_chapterXX_new.md | 原典。編集しない |
| スライド指示書 | book/video/chXX/script.md | スライド18枚の仕様 |
| HTMLスライド | book/video/chXX/slides/slide01-18.html | 880px高さ制約厳守 |
| YMM4台本 | book/video/chXX/ymm/chXX_ymm.txt | 300-350行、キャラ設定あり |
| YouTube説明文 | book/video/chXX/youtube.md | タイトル60文字以内 |
| スライドPNG | book/video/chXX/png/slide01-18.png | Playwrightで自動生成 |
問題は3つあった。
1. 直列のボトルネック。台本を書き終わらないとスライドが作れない。スライドが完成しないとスクリーンショットが撮れない。1章の制作に丸1日かかっていた。
2. 整合性の崩壊。台本で「80%削減」と言っているのに、スライドでは「70%短縮」と表示されている。書籍原稿との数値のずれが後工程で発覚し、手戻りが頻発していた。
3. コンテキストの消耗。1つのセッションで台本→スライド→SEOと順番にやると、後半でコンテキストウィンドウが限界に達する。品質が明らかに落ちる。
チーム設計：4つのロール
PMとしてチームを設計する際、まず考えたのはファイルの競合を起こさないことだ。2つのエージェントが同じファイルを同時に編集すれば、片方の変更が消える。
4つのロールを定義し、それぞれに書き込み可能なファイルを排他的に割り当てた。
script-writer（台本担当）
YMM4台本の作成・校閲を担当する。千葉哲也（専門家）と四国めたん（聞き手）の2キャラで、キャラ名「セリフ」 形式の台本を書く。
- 書き込みファイル:
ymm/chXX_ymm.txt,script.md - 品質基準: 総行数300-350行、同一キャラ連続5行以内、用語統一
- Plan Mode: あり（構成を先に設計→承認後に執筆）
台本のキャラ設定はエージェント定義ファイル（.claude/agents/script-writer.md）に埋め込んでいる。口調、NGパターン、テンポのルールまで定義することで、毎回の指示が不要になった。
slide-designer（スライド担当）
1920×1080のHTMLスライド18枚を設計・作成する。最大の制約はコンテンツ領域880pxの高さ制限だ。overflow: hidden が設定されているため、超過分は警告なく切り捨てられる。
- 書き込みファイル:
slides/slide*.html,thumbnails/ - 品質基準: 全スライド880px以内、CSS変数のみ使用、PNG視覚検証
- Plan Mode: あり（高さ計算を先に設計→承認後にHTML化）
Plan Modeを必須にしている理由は、880pxの計算ミスが後工程の手戻りに直結するからだ。「font-size 56px × line-height 1.5 = 84px」のような計算を事前に行い、リードが承認してからHTMLを書く。
web-editor（Web編集担当）
ブログ記事のMDX執筆、ページのSEOメタデータ最適化、YouTube投稿メタデータの作成を担当する。
- 書き込みファイル:
src/content/blog/*.mdx,src/app/**/page.tsx,youtube.md - 品質基準: frontmatter全フィールド必須、description 120文字以内、内部リンク2つ以上
- Plan Mode: なし（定型タスクが主）
qa-reviewer（品質保証担当）
読み取り専用のレビュー専門エージェント。台本×スライド×書籍原稿の三者間整合性、用語統一、880px制約、ビルド検証、SEO検証を行う。
- 書き込みファイル: なし（全ファイル読み取り専用）
- 出力: PASS / CONDITIONAL / FAIL の品質レポート
- Plan Mode: なし
qa-reviewerは問題を検出するだけで、修正は行わない。問題を見つけたら該当チームメイトにDMでフィードバックする。「slide07が880px超過。padding 40px→24pxに削減推奨」のように、具体的な修正案を添える。
ファイル所有権マトリックス
チーム設計の肝は、このマトリックスだ。
| ファイル | 書き込み所有者 |
|---|---|
ymm/chXX_ymm.txt | script-writer |
script.md | script-writer |
slides/slide*.html | slide-designer |
thumbnails/* | slide-designer |
src/content/blog/*.mdx | web-editor |
src/app/**/page.tsx | web-editor |
youtube.md | web-editor |
book/*_new.md | 誰も編集しない |
common.css | 誰も編集しない |
書籍原稿（*_new.md）と共通CSS（common.css）は「参照のみ」として明示的にロックしている。これらは全チームメイトが参照するマスターデータだ。ここを変更すると全体に波及するため、チーム作業中は触らない。
タスクフロー：1章の制作
新しい章（例: CH05）を制作する際のフローは5フェーズで構成される。
Phase 1: 並行制作
3つのチームメイトが同時に動き出す。
- script-writer: 書籍原稿を読み、台本の構成を設計（Plan Mode → リード承認）
- slide-designer: script.mdを読み、18枚のレイアウトを設計（Plan Mode → リード承認）
- web-editor: YouTube投稿メタデータ（タイトル・説明文・タグ）を作成
Plan Modeのチームメイトは、設計案をリードに送って承認を待つ。リードが「台本はH2の構成を変えたほうがいい」と判断すれば、フィードバックを返して修正させる。ここで方向性のずれを早期に潰す。
Phase 2: 実装
承認後、script-writerとslide-designerが本格的に制作に入る。
- script-writer: YMM4台本を全文執筆（300-350行）
- slide-designer: HTMLスライド18枚を作成し、
node screenshot_chXX.jsでPNG生成
この2つは互いに独立して進められる。台本は書籍原稿ベース、スライドはscript.mdベースで、入力ソースが別だからだ。
Phase 3: 品質検証
制作物が揃ったら、qa-reviewerが横断レビューを実施する。
- 台本×スライド×書籍原稿の三者間整合性チェック
- 用語統一のGrep横断検索（「ピンボック エイアイ」の表記ゆれなど）
- 全スライドの880px制約検証
npm run buildによるビルド確認
レポートはPASS / CONDITIONAL / FAILの3段階で出力される。CONDITIONALの場合、指摘事項の一覧と推奨アクションが添えられる。
Phase 4: フィードバック対応
qa-reviewerの指摘を受けて、各チームメイトが修正する。
- script-writer: モノローグ違反（5行連続超え）の分割、用語の修正
- slide-designer: 880px超過スライドのpadding/font-size削減、PNG再生成
ここでのポイントは、qa-reviewerがチームメイトに直接DMすることだ。リードを経由しないため、フィードバックループが速い。
Phase 5: 最終確認
qa-reviewerが再レビューし、PASS判定が出たら完了。リードに完了報告が送られる。
チーム起動のプロンプト例
Agent Teamsの起動は自然言語で行う。
Create a site-ops team for CH05 production:
- script-writer: CH05台本をbook/05_chapter5_new.mdから作成（plan approval required）
- slide-designer: CH05スライド18枚をscript.mdから作成（plan approval required）
- web-editor: CH05のYouTube投稿メタデータを作成
- qa-reviewer: 完成後に三者間整合性+880px+ビルド検証
これだけで、4つのClaude Codeセッションが起動し、共有タスクリストで協調しながら作業を進める。
用途に応じてチーム構成を変えることもできる。
# ブログ記事制作（2名で十分）
Create a site-ops team for new blog post:
- web-editor: ブログ記事をMDXで作成
- qa-reviewer: SEO検証+ビルド確認
# 複数章の並行制作（スケールアウト）
Create a site-ops team for CH05-CH06 parallel production:
- script-writer-1: CH05台本
- script-writer-2: CH06台本
- slide-designer: CH05-CH06スライド
- qa-reviewer: 横断レビュー
エージェント定義ファイルの設計
チームの品質を決めるのは、エージェント定義ファイル（.claude/agents/*.md）だ。ここにロール、ツール、制約、ワークフローを定義する。
script-writer.mdの構成を例に取る。
# Script Writer Agent
## Role — 何をするエージェントか
## Model — sonnet（コスト効率重視）
## Tools — Read, Write, Edit, Bash, Grep, Glob
## Character Settings — キャラクターの口調・性格・NGパターン
## Format Rules — 出力形式（キャラ名「セリフ」）
## Notation Standards — 表記統一テーブル
## Gold Standards — 品質基準の参照ファイル
## Script Structure — 18スライド構成の行数目安
## Workflow — 新規作成/校閲/部分修正の手順
重要なのはGold Standardsセクションだ。過去に品質が確認済みの台本（CH01、CH02）をゴールドスタンダードとして指定しておくと、エージェントはそのトーン・テンポ・構成を自動的に踏襲する。
SubagentとAgent Teamsの使い分け
実際の運用では、両方を併用している。
Subagentを使う場面:
- 特定のファイルの内容を調べて報告してほしい
- 1回の調査で完結する作業（「CH03の台本は何行？」）
- 結果だけ欲しくて、途中経過は不要
Agent Teamsを使う場面:
- 複数の成果物を並行で制作する
- チームメイト同士のレビューが必要
- 品質ゲートを設けて段階的に進めたい
- ファイル間の整合性を担保する必要がある
判断基準はシンプルだ。「チームメイト同士が会話する必要があるか」。あるならAgent Teams、ないならSubagent。
設計から学んだこと
ファイル所有権は妥協しない
最初は「柔軟にやればいい」と思っていたが、2つのエージェントが同じファイルを触った瞬間に片方の変更が消えた。所有権マトリックスを定義してからは一度も起きていない。
Plan Modeは創造的タスクに必須
台本やスライドのように「正解が1つではない」タスクでは、Plan Modeで方向性を先に合意することが重要だ。いきなり全文を書かせると、書き直しのコストが大きい。
qa-reviewerは読み取り専用にする
品質保証と修正を同じエージェントにやらせると、自分で書いたものを自分でレビューすることになる。検出と修正を分離することで、見落としが減った。
チームサイズは3-5名が最適
2名だと並行のメリットが少ない。6名以上だとコミュニケーションのオーバーヘッドが増える。PMBOK-AIの制作では4名体制がちょうどいい。
手が回らないからとエージェントを増やしたのに、報告と擦り合わせばかり増えて、かえって全体が遅くなる。
制約と注意点
Agent Teamsは実験的機能であり、いくつかの制約がある。
- セッション復帰が効かない:
/resumeで復帰してもチームメイトは戻らない。新しいチームを再起動する必要がある - トークン消費が大きい: 各チームメイトが独立したコンテキストウィンドウを持つため、トークン使用量はチームメイト数に比例する
- 同時編集はできない: ファイル所有権で防止しているが、仕組みとして排他制御があるわけではない。運用ルールでカバーしている
- 環境設定が必要:
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMSを有効にする必要がある
まとめ
Agent Teamsは、「1人のPMが複数のAIエージェントでコンテンツ制作を回す」ための仕組みだ。
ポイントを整理する。
- ロール設計: 各エージェントに明確な責任範囲を定義する
- ファイル所有権: 書き込み可能なファイルを排他的に割り当てる
- 品質ゲート: qa-reviewer（読み取り専用）による段階的な品質検証
- Plan Mode: 創造的タスク（台本・スライド）は構成を先に合意する
- Gold Standards: 品質基準を参照ファイルとしてエージェント定義に埋め込む
MCPサーバーの記事では「AIの手足を拡張する」話をした。Agent Teamsは「AIのチーム構造を設計する」話だ。どちらも、PMの仕事が「作業する」から「設計・判断する」に移行していることを示している。AIに任せる範囲とPMの判断軸については別途まとめている。
PMBOK-AIの全14章、残り10本の動画制作は、このチーム体制で進めていく。