サブエージェント設計｜ディレクターとワーカーの分け方

サブエージェント設計とは、判断を担うディレクターと、手を動かすワーカーへ役割を分ける構成です。何を渡し、何体まで並列で動かし、結果をどう統合するかを決めないまま始めると、重複作業や抜けが起きます。本記事は、公式ドキュメント5件と自社の委譲ルールの実例から、判断基準を1本にまとめます。

01結論：サブエージェント設計は、判断をディレクター1体に残し、作業をワーカーへ渡す設計です

結論は3点です。

1. サブエージェント設計は、何を渡すかより先に「何を渡さないか」を決める設計です。判断・突合・人間ゲートの管理はディレクターに残します。
2. 並列数は多いほど速いとは限りません。目安の本数を超えると、統合の手間が並列化の利益を上回ります。
3. 統合時の失敗は、重複・抜け・上書きの3パターンに集約できます。パターンごとに対策が違います。

Anthropicは、中央のLLMがタスクを動的に分解し、ワーカーLLMへ委譲する構成を提唱しています（出典: Anthropic公式）。その中央LLMが結果まで統合する形を「オーケストレーター・ワーカー」パターンと呼びます。本記事はこの構成を、ディレクターとワーカーという呼び方で扱います。

02サブエージェントはどう役割分担するのか｜ディレクターとワーカーの違い

Claude Codeの公式ドキュメントは、サブエージェントを独自のコンテキストウィンドウを持つ存在と定義しています（出典: Claude Code公式）。専用のシステムプロンプトとツールアクセス、独立した権限で動く点も明記されています。親の会話とは別の文脈で動き、要約だけを返す設計です。

コンテキストを分ける理由は、コストにも表れます。Anthropicの計測では、マルチエージェント構成は通常のチャット対話に比べて約15倍のトークンを消費します（出典: Anthropic公式）。ディレクターが全文を読み込むのではなく、ワーカーが自分の担当範囲だけを読み、要点だけを返す設計にするのはこのためです。

委譲の形にも種類があります。OpenAI Agents SDKは、2つの委譲パターンを区別しています（出典: OpenAI公式）。司令塔役が主導権を握ったまま専門エージェントを道具として呼ぶ「manager pattern」と、主導権そのものを渡す「handoffs」です。サブエージェント設計は前者に近く、成果を返した後もディレクターが主導権を握り続けます。

この構成には、事前に決めた手順どおり並列で流す「parallelization」との違いもあります。Anthropicは、オーケストレーター・ワーカーパターンは、どう分割するかを中央のLLMが実行のたびに動的に決める点で異なると説明しています（出典: Anthropic公式）。事前に必要なサブタスクを予測できない、複雑な調査やコーディングに向くという整理です。

AIエージェントそのものの定義は『AIエージェントとは｜そう呼べる3条件と、呼べない境界』で扱っています。本記事は、AIエージェントを複数体で動かすときの役割分担だけに絞ります。

03サブエージェント設計の判断基準｜ワーカーへ委譲する4つの条件

委譲するかどうかは、作業の性質で決めます。判断や設計そのものが要る仕事はディレクターに残し、作業量が支配的な仕事はワーカーへ渡します。

委譲した先が空振りしない条件は、公式ドキュメントでも一致しています。Anthropicは、各ワーカーに「目的・出力形式・使うツールと情報源の指針・タスクの境界」の4点を与えるべきだと述べています（出典: Anthropic公式）。境界を渡さないまま「半導体不足を調べて」とだけ指示すると、範囲がぶれます。

WEBMARKSの委譲ルールは、この4点をさらに実務の型に落としています。委譲プロンプトには次の6項目を含めます。

1. ゴール：何を作るか、何を調べるかを1文で渡す
2. スコープ：やってよい範囲とやってはいけない範囲を明示する
3. 入力：読むべきファイルパスやURL、前提条件を具体的に渡す
4. 出力形式と保存先：どの形式で、どこに置くかまで指定する
5. 制約：人間ゲート・未確認の数字の扱い・機密の扱いを明記する
6. 返し方：作った成果物の場所と要点だけを返させ、全文を再掲させない

判断に迷ったときの目安は、手戻りコスト×不確実性です。設計や曖昧さの解消が要る仕事はディレクターに残し、作業量が支配的な仕事はワーカーへ渡します。人間ゲートに触れる操作の線引きは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱っています。

04並列数の決め方｜サブエージェントを同時に何体動かすか

並列数は、多ければ速いという単純な関係にありません。Anthropicの実測では、Opusをリード役・Sonnetをワーカーに使う構成が、単体のOpusを90.2%上回りました（出典: Anthropic公式）。同じ資料は別の実測として、リードを3〜5体並列起動しツールも並列で呼ぶ設計に変えたところ、複雑な調査の所要時間を最大90%短縮したとも報告しています。単純な事実確認なら1体で3〜10回の道具呼び出しに収まり、複雑な調査でも「明確に役割を分けた10体超」を上限の目安に挙げています。

一方で、増やしすぎたときの副作用も明記されています。同資料は、ワーカー同士が調整できず、1体の完了待ちで全体が止まる問題を指摘しています（出典: Anthropic公式）。Claude Codeのチーム機能に関する公式ドキュメントも、チームサイズは「3〜5体から始める」ことを推奨しています（出典: Claude Code公式）。「集中した3体のワーカーは、散漫な5体より成果を出すことが多い」とも述べています。

WEBMARKSの委譲ルールも、同じ結論に達しています。独立したタスクを並列で投げるとき、同時最大で実務上4〜6本を目安としています（2026-07-24制定の社内ルールより）。多すぎる場合は、統合コストが並列化の利益を上回ると判断しているためです。社外の公式資料と自社の運用目安が、ほぼ同じ本数に収れんしている点は、この目安がどちらか一方の癖ではないことを示します。

タスクの量とワーカー数の比率にも目安があります。Claude Codeの公式ドキュメントは、1ワーカーあたり5〜6件のタスクを持たせると、手待ちが減ると説明しています（出典: Claude Code公式）。15件の独立タスクなら、まず3体で始める計算になります。

05サブエージェントの結果統合で起きる3つの失敗パターン

結果統合は、並列化の恩恵をそのまま受け取れる工程ではありません。Anthropicは、初期の構成で「ワーカーがタスクを誤解する」「複数のワーカーが全く同じ調査を繰り返す」という重複が起きたと報告しています（出典: Anthropic公式）。同資料はさらに、ワーカーが作業を重複させたり、抜けを残したり、必要な情報を見つけられなかったりする失敗を総称しています。

失敗はもう1種類あります。ファイルの奪い合いです。Claude Codeのチーム機能に関する公式ドキュメントは「2体のワーカーが同じファイルを編集すると上書きが起きる。各ワーカーが違うファイル群を担当するよう分割すべきだ」と明記しています（出典: Claude Code公式）。

自社でも同種の事故が実際に起きています。姉妹メディアのAIO Journalでは、監視用の常駐プロセスと本体セッションが同じ記事ファイルへ同時に書き込む事故が起きました（メディア設計書に記録・2026-07-28時点）。結果として、記事3本が上書きされました。

原因は、範囲の宣言なしに複数の実行主体が同じ対象へ手を出したことです。以後は、着手前に範囲を宣言するファイルを作り、宣言のない範囲には着手しない運用に変えています。

3パターンに共通するのは、統合の直前ではなく、委譲の設計段階にすでに原因があることです。統合で気づいて直すのではなく、委譲時に境界を決め切ることが、統合を壊れにくくする唯一の方法です。

06子エージェントへの委譲設計｜本メディアの執筆・原典照合・批評をどう分担しているか

本メディア自体が、この分業の実例です。WEBMARKSの委譲ルールは、上位モデルをディレクターに固定する構成を定義しています（2026-07-24制定）。実働は、日本語ドラフトの執筆・Vault内外の裏取り・機械的な整形という3種類の子エージェントへ渡します。

この記事自体も、その1本です。ディレクターが記事IDとテーマを委譲プロンプトの形で渡し、執筆役の子エージェントである本稿の書き手が、公式ドキュメントを実際に取得しながら書いています。品質ラインの中身は『AIが書いた記事をAIが差し戻す｜公開前チェック5段階の中身』で開示しています。

規模も実測できます。本記事の執筆時点で _work/02_記事/ には記事ファイルが積み上がっており、直近の実測（2026-07-28、ファイル一覧のカウント）では20本を超えていました。複数の執筆ワーカーが並行して書き込んでいるため本数は数えるたびに変わり、確定値は公開直前に数え直します。第1弾50本という計画に対し、複数の執筆役を順に投入して積み上げている途中の状態です。

WEBMARKSのAI社員体制は、7部署・30体の役割定義を2026-06-24に統合したものです。実働の子エージェントには、次の権限を渡していません。

• 削除・強制上書きにつながるコマンドを実行する権限
• 送信・公開・決済など対外的に確定する操作の権限
• 人間ゲートを経由せずに正式版へ書き込む権限

権限を絞る設計は、Claude Codeの公式ドキュメントが示す考え方と一致します。サブエージェントの定義ファイルは、許可するツールを一覧で絞り込むtoolsフィールドを持ち、指定しなければ利用可能な全ツールを継承します（出典: Claude Code公式）。次はその考え方を一般化した例です。

---
name: research-worker
description: 一次情報の裏取りに使う。書き込みはしない
tools: Read, Grep, Glob, WebFetch
---

WriteやEditをtoolsに含めなければ、このワーカーはファイルを書き換えられません。権限は後から広げるのではなく、最初から狭く始めるのが安全な設計です。

07サブエージェントの委譲でつまずきやすい3つの点

1つ目は、判断そのものをワーカーへ渡してしまうことです。委譲先の設計や成果の突合まで任せると、誰も全体を見なくなり、矛盾に気づく人がいなくなります。

2つ目は、並列数を増やしただけで安心することです。公式ドキュメントは、テストと隔離環境での確認を欠かさないよう注意を促しています（出典: Anthropic公式）。本数を増やす前に、1体あたりの委譲プロンプトが4条件を満たしているかを先に確認します。

3つ目は、ディレクター自身が手を動かし始めてしまうことです。Claude Codeの公式ドキュメントも、リード役が委譲を待たずに実装を始めてしまう傾向に注意を促し、待つよう指示し直す運用を挙げています（出典: Claude Code公式）。

4つ目は、渡した権限を後から広げてしまうことです。WEBMARKSの委譲ルールは、実働の子エージェントに人間ゲート級の権限を後から足さないことを明記しています（2026-07-24制定）。最初に狭く決めた境界を、動作確認のたびに緩めていくと、設計した意味そのものが薄れます。

08サブエージェント設計を始めるチェックリスト

• ディレクターとワーカーの役割を、判断と作業で明確に分けたか
• 各ワーカーへの委譲プロンプトに、ゴール・スコープ・入力・出力形式・制約・返し方の6点があるか
• 並列数は目安の範囲（4〜6体前後）に収め、統合コストが利益を上回っていないか
• ワーカーの成果を、ディレクターが必ず突合してから統合しているか
• 複数の実行主体が同じ対象へ同時に手を出さないよう、範囲を宣言する仕組みがあるか
• ワーカーに送信・公開・削除・決済などの人間ゲート級の権限を渡していないか
• 統合後の成果物に、重複・抜け・上書きが残っていないか確認したか

09FAQ