Claude Code Agent Teamsで「1人出版社」を回す｜PMBOK-AI制作の実践記録

書籍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は「一緒にプロジェクトを回すチーム」だ。

コンテンツ制作のように、複数の成果物が相互に依存し、品質の整合性が必要な作業にはAgent Teamsが圧倒的に向いている。

解決したかった問題

PMBOK-AIの動画コンテンツ制作には、1章あたり以下の成果物が必要になる。

問題は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に削減推奨」のように、具体的な修正案を添える。

ファイル所有権マトリックス

チーム設計の肝は、このマトリックスだ。

書籍原稿（*_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エージェントでコンテンツ制作を回す」ための仕組みだ。

ポイントを整理する。

1. ロール設計: 各エージェントに明確な責任範囲を定義する
2. ファイル所有権: 書き込み可能なファイルを排他的に割り当てる
3. 品質ゲート: qa-reviewer（読み取り専用）による段階的な品質検証
4. Plan Mode: 創造的タスク（台本・スライド）は構成を先に合意する
5. Gold Standards: 品質基準を参照ファイルとしてエージェント定義に埋め込む

MCPサーバーの記事では「AIの手足を拡張する」話をした。Agent Teamsは「AIのチーム構造を設計する」話だ。どちらも、PMの仕事が「作業する」から「設計・判断する」に移行していることを示している。

PMBOK-AIの全14章、残り10本の動画制作は、このチーム体制で進めていく。