本記事は連載 「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更新をどう循環させるかを書きます。更新に気づけるよう、フォロー・ストックしておいてもらえると嬉しいです。