本記事は連載 「AI駆動開発実践シリーズ」 の第3回です。
#1「バイブコーディングとAI駆動開発は何が違うのか」では個人開発でspec駆動へ移った話、#2「組織でAI駆動開発を回すための方法論」では、その型をチームへ広げる話を書きました。今回は、セッションとサブエージェントへの仕事の分け方を紹介します。

はじめに — サブエージェントは増やせばいいわけではなかった

個人のiPhoneアプリ開発で、コードレビュー、問題作成、専門監修、7言語の確認などをAIへ分業しました。当初は、人間の最終判断者1人、3つのセッション、15体のサブエージェントによる計19体の体制でした。

初稿作成や観点別レビューは速くなりました。しかし、人数を増やすほど次の問題も大きくなりました。

処理時間とコストが増える — 各エージェントが資料を読み直し、返却結果をセッションが統合するためです。
受け渡しで品質が崩れる — 各担当の確認は通っても、成果物全体の対応関係がずれるためです。

そこで、3つのセッションは残し、サブエージェントを合計5〜7体へ絞りました。

大切なのはエージェント数ではなく、文脈、権限、成果物、完了条件、最終判断を分けることです。

以下は自作アプリでの実例を、ほかのプロジェクトにも使える形へ一般化したものです。

まず用語を、普通の組織に置き換える

仕組み	組織に例えると	役割
セッション	担当チーム	責務ごとに文脈を分け、計画・統合・最終確認を行う
Skills	業務マニュアル	セッションやサブエージェントへ作業手順を持たせる
サブエージェント	専門担当者	限定された仕事を独立した文脈で処理し、結果を返す
agent teams	複数チームの共同体制	現時点では利用できない実験的機能。本記事では扱わない

Skillsは単体では動きません。 セッションまたはサブエージェントへ読み込ませて使う手順書です。Skillsを増やしても作業者は増えませんが、サブエージェントを増やすと作業者と文脈が増えます。

19体から5〜7体へ — Before / After

図中のPMは役職名ではなく、人間側の最終判断者を表します。個人開発なら開発者本人です。

BeforeとAfterで変えていないのは、最終判断者と3つのセッションです。変えたのは、各セッションの配下で動くサブエージェントです。

セッション	Before	After
アプリ開発	コードレビュー1体	同じ1体を維持
出題制作	問題初稿＋専門レビュー6体	必要な4〜6体だけを選ぶ
販売戦略	言語別レビュー7体	常設せず、セッションが直接処理する

Afterでは、3セッションを合わせて5〜7体です。最終QAもサブエージェントへ委譲せず、成果物を担当するセッションが直接行います。

1. セッションでは「大きな文脈」を分ける

設計、コンテンツ制作、販売戦略を1つの会話へ詰め込むと、目的と判断基準が混ざります。セッションはツール別ではなく、参照する正本と完了条件で分けると整理しやすくなります。

セッション	主な正本	完了条件
アプリ開発	要件・設計・ソース	ビルド、テスト、設計整合
出題制作	出題基準・用語集・原典	構造、意味、著作権、可読性
販売戦略	商品資料・実績・サイト設計	訴求根拠、導線、公開範囲

「Claude Code用」「Cowork用」ではなく、「何を根拠に、何ができたら終わりか」で切るのがポイントです。

2. Skillsは「手順」、サブエージェントは「担当者」

使い分けは次の3つで十分です。

やり方を揃えたい → Skillにする。
重い作業を別の文脈へ分けたい → サブエージェントへ渡す。
手順と担当を固定したい → Skillをサブエージェントへ読み込ませる。

たとえば、投稿前チェックはSkillに向きます。大量ログの解析や読み取り専用のコードレビューは、主文脈から分離できるサブエージェント向きです。

同じセッション内で手順を揃えるだけなら、サブエージェントを増やす必要はありません。Claude Codeでも、CLAUDE.md、Skills、サブエージェント、Hooksは別の目的を持つ仕組みとして整理されています（Extend Claude Code）。

3. サブエージェントには「狭く完結する仕事」を渡す

サブエージェントは独立したコンテキストで開始します。呼び出し元の会話履歴や、すでに読んだ資料をすべて知っているわけではありません（Create custom subagents）。

そのため、依頼には必要な前提を含めます。向いているのは、次のような仕事です。

変更差分だけを読むコードレビュー
指定した出題意図と原典からの初稿作成
原典との表現の近さだけを調べる著作権確認
文章長と画面収まりだけを見る可読性確認

反対に、「実装、テスト、レビュー、文書更新をすべて行う」のような依頼は範囲が広すぎます。作る役割と見る役割を分けるほうが、判定基準を明確にできます。

4. 委譲は「6ブロックの契約」にする

依頼の書式を固定すると、説明漏れと勝手な推測を減らせます。

【役割】コードレビュー担当。実装は変更しない
【目的】変更が設計と品質基準を満たすか判定する
【正本】docs/architecture.md §3、CLAUDE.md
【境界】src/feature-a/** のみ。全ファイル変更禁止
【出力】High / Medium / Low、根拠となる行、問題なければPASS
【完了条件】設計・回帰・テスト不足を確認。未確認はUNABLE_TO_VERIFY

重要なのは、目的、正本、変更境界、出力形式、完了条件を明示することです。Anthropicのマルチエージェント研究システムでも、委譲が曖昧だと作業の重複や抜けが起きると説明されています（How we built our multi-agent research system）。

5. 並列化は「独立・非競合・統合可能」の時だけ

条件	意味
独立	片方の結果を待たずに進められる
非競合	同じファイルや正本を同時に変更しない
統合可能	返却形式が揃い、結果を比較できる

読み取り専用の観点別レビューや、独立した調査は並列化に向きます。同じファイルの同時修正や、前の判断を待つ逐次作業は向きません。

私の環境では、並列数を原則3以下にしています。これは製品仕様ではなく、返却結果を追跡して確認できる範囲として決めた運用ルールです。

6. 失敗①：人数を増やすほど、遅く・高くなった

サブエージェントを1体増やすたびに、次の作業も増えます。

資料の読み直し
依頼内容と完了条件の説明
返却結果の確認と統合
判断が割れた時の追加調査

並列化で待ち時間が短くなる場面はありますが、全体のトークン消費と統合作業は増えます。Claude Codeの公式ドキュメントでも、独立したエージェントを増やすほどトークン使用量が増えると案内されています（Manage costs effectively）。

これは普通の組織と同じです。1人の「スーパーマン」にすべてを任せるより、役割の分かれたチームのほうが安定します。一方、担当を細かく分けすぎると、引き継ぎばかりが増えます。

最も機能したのは、全体を統合するセッションと、共通のSkills・正本・完了条件で動く少数の専門サブエージェントでした。

7. 失敗②：観点別レビューだけでは全体を保証できなかった

意味、倫理、著作権、誤答品質、可読性を別々に確認しても、次の不整合が残りました。

選択肢を直した後、解説だけが古いまま残る。
原文の修正が、一部の翻訳へ反映されない。
各ファイルは正しいが、ファイル間の対応がずれる。

各レビュアーは担当範囲を確認していました。しかし、変更前後や言語間を通して確認する役割がありませんでした。

レビュー数を増やすより、受け渡しを減らし、成果物全体を見る担当セッションを決めるほうが効果的でした。サブエージェントのPASSは一次判定であり、リリース判定ではありません。

8. 実例：大量翻訳は小さなバッチへ分ける

多言語の問題文、選択肢、解説を言語別担当へ分けたところ、量が増えるにつれて次の問題が起きました。

言語混入: 別言語や原文の一部が混ざる。
文章切れ: 問題文や解説が途中で終わる。
意味ずれ: 自然な文章でも、原文と違う内容になる。
追従漏れ: 原文を直しても、一部言語だけ古い内容が残る。

対策は、担当者を増やすことではなく、確認までの間隔を短くすることでした。

20問前後の小さなバッチに分ける。
バッチごとに原文、翻訳、データ構造を照合する。
言語混入、文章切れ、正答、解説の対応を確認する。
問題があれば次へ進まず、修正して検査条件を更新する。
原文変更時は、影響する翻訳を再確認する。

AI翻訳そのものを否定する話ではありません。構造を持つ大量データでは、言語別の並列数より、バッチの小ささと確認頻度が品質に効いたという実例です。

9. 再設計：「初稿」は任せ、「最終品質」は戻す

仕事	サブエージェントへ	セッション・人へ
初稿作成	初稿まで	方針と採否の判断
調査・ログ要約	候補整理まで	原文と出典の確認
限定観点レビュー	一次判定まで	観点をまたいだ統合
大量翻訳	小バッチの初稿まで	原文との意味・構造の照合
正本変更	提案まで	承認と反映
削除・公開・課金・移行	原則任せない	人が明示承認
リリース前QA	候補検出まで	担当セッションが全体確認

この分け方なら、AIの速度を使いながら、最終判断の空白を防げます。

10. CLAUDE.md、Skills、サブエージェント、Hooksを混ぜない

仕組み	置くもの	例
`CLAUDE.md`	毎回必要な短いルール	正本、禁止事項、読む順序
Skills	必要時に使う再利用手順	テスト、翻訳、投稿前校正
サブエージェント	独立文脈の限定ロール	コードレビュー、ログ解析
Hooks / CI	必ず守らせる条件	lint、test、secret検出
人の承認	価値判断と外部影響	公開、削除、課金、リリース

自然言語の禁止事項は、決定論的な強制ではありません。絶対に止めたい操作は、権限制限、Hooks、CIでも防ぎます。Anthropicのガイドでも、特定タイミングで必ず実行したい処理はHooksへ移すことが案内されています（How Claude remembers your project）。

11. 最小構成から始める

導入時は、次の6点で十分です。

最終判断する人を1人置く。
最初は1セッションで始め、正本と完了条件が異なる仕事だけを分ける。
繰り返す手順を1つだけSkillにする。
「作る役割」と「見る役割」を分ける。
並列化は読み取り専用の仕事から始める。
サブエージェントのPASSだけでリリースを決めない。

必要性が確認できてから役割を追加するほうが、体制を小さく保てます。

まとめ

セッションは、正本と完了条件で分ける。
Skillsは単体で動かない作業手順として使う。
サブエージェントには、狭く完結する仕事を渡す。
並列化は、独立・非競合・統合可能な仕事に限る。
大量データは、担当を増やす前に小さなバッチへ分ける。
最終QAと外部影響のある判断は、担当セッションと人へ戻す。
最適解は万能な1体でも大量の担当者でもなく、統制された少数精鋭である。

AIプロジェクトの成熟度は、エージェント数では測れません。

誰が、どの正本を見て、どこまで変更でき、何をもって完了とし、最後に誰が判断するのか。

この問いに答えられる状態が、AI駆動開発の「体制」です。

次回予告（#4）：「ループエンジニアリングとは何か — バイブコーディング・Spec駆動開発との違い」。役割分担を整えた次に、Spec → 実装 → 検証 → 学習 → Spec更新をどう循環させるかを書きます。更新に気づけるよう、フォロー・ストックしておいてもらえると嬉しいです。