「この作業、サブエージェントに投げてしまっていいんでしょうか」。手元でAIエージェントを動かし始めた人から、いちばんよく出る質問です。
渡せば速くなりそうな気はする。けれど、渡した先で何をされるかは分からない。結局ぜんぶ自分で抱えたまま、AIエージェントは相談相手の位置で止まっている。そういう状態でこの記事にたどり着いた方も多いはずです。
この記事は、サブエージェント設計を「何を渡すか」からではなく「何を渡さないか」から組み立てます。根拠は公式ドキュメント5件と、運営元WEBMARKSが実際に使っている委譲ルールです。用語そのものの整理は、別記事『AIエージェントとは｜3条件で見分け、任せる前に決める3つ』が引き受けます。
こんなふうに調べていませんか
- サブエージェントに投げていい仕事と、自分に残す仕事の線が引けない
- 何体まで並列で動かしていいのか、判断する材料を持っていない
- 並列で走らせたら成果がぶつかった。次にどう防ぐかが分からない
この記事を読み終えたときに手に入るもの
- ディレクターに残す判断と、ワーカーへ渡す作業を線引きできるようになります
- 並列数を、速さと統合コストの両方から決められるようになります
- 統合が壊れる3つの型を、委譲の設計段階でつぶせるようになります
結論30秒でわかる、この記事の結論
- サブエージェント設計は、何を渡すかより先に「何を渡さないか」を決める設計です。
- 判断・突合・人間ゲートの管理はディレクターに残し、作業量が支配的な仕事をワーカーへ渡します。
- 統合の失敗は重複・抜け・上書きの3つ。原因はどれも統合ではなく、その手前の設計にあります。
進行役は3人です。若葉さん（Web担当2年目）が用語のそもそもを聞き、高梨課長（情シス）が自分の手で動かす立場から聞き、鈴木さん（本誌監修）が答えます。
01サブエージェント設計は、AIエージェントを何と何に分ける設計なんですか？
若葉さんサブエージェントって、自分の代わりに動いてくれるAIですよね。設計と言われると、何を決める話なのか分かりません。
鈴木さん編集部を思い浮かべると近いかもしれません。デスクが台割を決めて、記者は担当面だけを書く。もしデスクが原稿も全部書き始めたら、台割は誰も見ていない状態になりますよね。その線を先に引くのが設計です。
分けるのは、判断と作業です。判断をディレクター1体に残し、手を動かす部分をワーカーへ渡します。
Anthropicは、中央のLLMがタスクを動的に分解し、ワーカーLLMへ委譲する構成を示しています（出典: Anthropic公式）。その中央のLLMが結果まで統合する形が「オーケストレーター・ワーカー」パターンです。本記事はこれを、ディレクターとワーカーという呼び方で扱います。
似た形に「parallelization」があります。事前に決めた手順どおりに並列で流すやり方です。Anthropicは、オーケストレーター・ワーカーは、どう分割するかを中央のLLMが実行のたびに動的に決める点が違うと説明しています（出典: Anthropic公式）。事前にサブタスクを予測できない、複雑な調査やコーディングに向くという整理です。
この章のまとめ
サブエージェント設計は、作業の分担表ではありません。判断をどこに集めるかを決める設計です。
02サブエージェントのディレクターとワーカーで、AIエージェントの何が違うんですか？
Claude Codeの公式ドキュメントは、サブエージェントを独自のコンテキストウィンドウを持つ存在と定義しています（出典: Claude Code公式）。専用のシステムプロンプトとツールアクセス、独立した権限で動く点も明記されています。親の会話とは別の文脈で動き、要約だけを返す設計です。
文脈を分ける理由は、コストにも表れます。Anthropicの計測では、マルチエージェント構成は通常のチャット対話に比べて約15倍のトークンを消費します（出典: Anthropic公式）。ディレクターが全文を読み込むのではなく、ワーカーが担当範囲だけを読んで要点を返す。その形にする理由がここにあります。
| 観点 | ディレクター | ワーカー |
|---|---|---|
| 担う判断 | タスク分解・委譲先の決定・成果の突合 | 割り当てられた1タスクの実行 |
| 保持する文脈 | セッション全体の文脈を保持する | 独立したコンテキストウィンドウのみ持つ |
| 使う権限 | 人間ゲートの管理を含む広い権限 | 用途ごとに絞った最小限のツールのみ |
| 失敗時の影響範囲 | 止まると全体の進行が止まる | そのワーカーの担当範囲に閉じる |
違いは能力ではなく、見えている範囲です。持ち場を仕上げる腕がどれだけ上がっても、全体の寸法を確かめる役は移りません。
この章のまとめ
ワーカーが賢くなっても、判断は移りません。全体が見えている側に残ります。
03サブエージェントというAIエージェントに仕事を渡すとき、主導権はどちらが持つんですか？
若葉さん一度渡したら、そのあとは向こうが決めるんですよね。途中で方針を変えたくなったら、どうするんでしょう。
鈴木さん渡し方が2つあるんです。主導権ごと渡す形と、道具として呼ぶ形。ここで扱っているのは後者なので、手綱は握ったままです。返ってきたものを見てから次を決められます。
OpenAI Agents SDKは、2つの委譲パターンを区別しています（出典: OpenAI公式）。司令塔役が主導権を握ったまま専門エージェントを道具として呼ぶ「manager pattern」と、主導権そのものを渡す「handoffs」です。
サブエージェント設計は前者に近い形です。成果が返ってきた後も、ディレクターが主導権を握り続けます。どちらを選ぶかで、途中で方針を変えられるかどうかが変わります。
この章のまとめ
主導権ごと渡すのか、道具として呼ぶのか。サブエージェント設計が選ぶのは後者です。
04サブエージェント設計では、どの仕事をワーカーへ渡していいんですか？
高梨課長渡していい仕事の見分け方が知りたいです。調査と資料づくりは投げたいのですが、どこまでが安全なのか判断できません。
鈴木さん作業量が支配的な仕事は、渡してよい側です。逆に、設計そのものと、曖昧さを潰す作業は手元に残します。迷ったら、手戻りしたときの痛みと、やってみないと分からない度合い。この2つで置き場所を決めてみてください。
作業の性質で分けると、次のようになります。
| 作業の性質 | ディレクターが担うか | ワーカーへ渡すか |
|---|---|---|
| 複数ファイルの通読・横断調査 | 担わない | 渡す（調査系ワーカー） |
| まとまった文章のドラフト執筆 | 担わない | 渡す（執筆系ワーカー） |
| 決まった型への大量整形 | 担わない | 渡す（雑務系ワーカー） |
| 委譲先の設計・成果の突合・最終判定 | 担う | 渡さない |
| 送信・公開・削除・決済などの人間ゲート | 担う | 渡さない |
下の2行は、技術的にできないから残しているのではありません。ここを渡すと、全体を見る人がいなくなるためです。人間ゲートに触れる操作の線引きは『AIエージェントの承認ゲート｜止める操作4種と3層の選び方』で扱っています。
実務では、表に無い仕事のほうが多く出てきます。そのときは2軸で位置を決めます。どちらも低ければ、そのまま渡せます。どちらも高ければ、ディレクターが持ちます。片方だけ高い仕事は、渡す前に何かを1つ決めてから渡す形になります。
この章のまとめ
渡してよいかどうかは、仕事の難しさでは決まりません。手戻りの痛みと、やってみないと分からない度合いで決まります。
05サブエージェント設計の委譲プロンプトの6項目は、AI社員に何を保証してくれるんですか？
委譲した先が空振りしない条件は、公式ドキュメントでも一致しています。Anthropicは、各ワーカーに「目的・出力形式・使うツールと情報源の指針・タスクの境界」の4点を与えるべきだと述べています（出典: Anthropic公式）。境界を渡さないまま「半導体不足を調べて」とだけ指示すると、範囲がぶれます。
WEBMARKSの委譲ルールは、この4点を実務の型に落としています。AI社員へ渡す委譲プロンプトには、次の6項目を含めます。
- ゴール：何を作るか、何を調べるかを1文で渡す
- スコープ：やってよい範囲とやってはいけない範囲を明示する
- 入力：読むべきファイルパスやURL、前提条件を具体的に渡す
- 出力形式と保存先：どの形式で、どこに置くかまで指定する
- 制約：人間ゲート・未確認の数字の扱い・機密の扱いを明記する
- 返し方：作った成果物の場所と要点だけを返させ、全文を再掲させない
6項目が保証するのは、成果の質そのものではありません。戻ってきたものを突合できる状態です。保存先が決まっていなければ探すところから始まり、返し方が決まっていなければ全文が返ってきて、結局ディレクターが読み直すことになります。
この章のまとめ
委譲プロンプトは、ワーカーを賢くする道具ではありません。返ってきたものを突合できる形にそろえる道具です。
06サブエージェントは、同時に何体まで動かすと速くなるんですか？
高梨課長独立した作業が15件あります。全部いっぺんに投げたら、その分だけ速くなりますか。
鈴木さんそこは比例しません。増やすほど速いなら上限の話は出てこないはずですが、公式資料にも自社の運用にも、だいたい同じあたりに目安が置かれています。まず少なく始めて、手待ちが出るかどうかを見るのが早いです。
Anthropicの実測では、Opusをリード役・Sonnetをワーカーに使う構成が、単体のOpusを90.2%上回りました（出典: Anthropic公式）。同じ資料は別の実測として、リードを3〜5体並列で起動しツールも並列で呼ぶ設計に変えたところ、複雑な調査の所要時間を最大90%短縮したとも報告しています。
同じ資料には、上限側の目安もあります。単純な事実確認なら1体で3〜10回の道具呼び出しに収まり、複雑な調査でも「明確に役割を分けた10体超」を上限の目安に挙げています。
Claude Codeのチーム機能に関する公式ドキュメントは、チームサイズを「3〜5体から始める」ことを勧めています（出典: Claude Code公式）。「集中した3体のワーカーは、散漫な5体より成果を出すことが多い」とも述べています。
WEBMARKSの委譲ルールも、近い結論に達しています。独立したタスクを並列で投げるとき、同時最大で実務上4〜6本を目安としています（2026-07-24制定の社内ルールより）。それを超えると、統合コストが並列化の利益を上回るという判断です。公式資料と自社の目安がほぼ同じ本数に収れんしている点は、これが一方の癖ではないことを示します。
タスクの量とワーカー数の比率にも目安があります。Claude Codeの公式ドキュメントは、1ワーカーあたり5〜6件のタスクを持たせると手待ちが減ると説明しています（出典: Claude Code公式）。15件の独立タスクなら、まず3体で始める計算になります。
この章のまとめ
並列数は、体数の希望からではなくタスクの本数から決めます。1ワーカーが持てる件数で割ると、最初の体数が出ます。
07サブエージェントを増やしすぎると、AIエージェントの現場では何が起きるんですか？
増やしすぎたときの副作用も、公式資料に明記されています。Anthropicは、ワーカー同士が調整できず、1体の完了待ちで全体が止まる問題を指摘しています（出典: Anthropic公式）。
現場で先に効いてくるのは、速さではなく手間のほうです。並列を増やすと、ディレクターが突合する対象がその数だけ増えます。返ってきた成果が互いに食い違っていれば、どちらを採るかを決める作業も足されます。
見分けるのは体数ではなく、タスクの形です。本当に独立していて、担当ファイルが重ならず、粒度がそろっているなら、増やした分だけ効きます。逆に、同じ資料を全員が読む、1体の結果を待たないと次が決まらない、粒度がばらばら。どれかがあると、増やすほど遅くなります。
この章のまとめ
並列数の上限を決めているのは、モデルの性能ではありません。ディレクターが突合できる量です。
08サブエージェント設計で、結果統合はどこから壊れるんですか？
Anthropicは、初期の構成で「ワーカーがタスクを誤解する」「複数のワーカーが全く同じ調査を繰り返す」という重複が起きたと報告しています（出典: Anthropic公式）。同じ資料は、ワーカーが作業を重複させたり、抜けを残したり、必要な情報を見つけられなかったりする失敗も挙げています。
もう1種類あります。ファイルの奪い合いです。Claude Codeのチーム機能に関する公式ドキュメントは「2体のワーカーが同じファイルを編集すると上書きが起きる。各ワーカーが違うファイル群を担当するよう分割すべきだ」と明記しています（出典: Claude Code公式）。
自社でも同種の事故が起きています。姉妹メディアのAIO Journalでは、監視用の常駐プロセスと本体セッションが、同じ記事ファイルへ同時に書き込む事故が起きました（メディア設計書に記録・2026-07-28時点）。結果として、記事3本が上書きされました。原因は、範囲の宣言なしに複数の実行主体が同じ対象へ手を出したことです。以後は、着手前に範囲を宣言するファイルを作り、宣言のない範囲には着手しない運用に変えています。
| 失敗パターン | 症状 | 主な原因 | 対策 |
|---|---|---|---|
| 重複作業 | 同じ調査・同じ執筆を複数ワーカーが繰り返す | タスクの境界が曖昧なまま並列投入した | 委譲時にスコープを明示し、重ならないよう分割する |
| 抜け（ギャップ） | どのワーカーも担当していない範囲が残る | 分解時に境界を決めず、感覚で割った | 分解の合計が元タスクを覆っているかを突合する |
| 上書き | 同じファイルを複数の実行主体が同時に書き換える | 範囲宣言なしに複数が同じ対象へ触れた | 着手前に範囲を宣言し、宣言のない範囲は触らない |
3つに共通するのは、原因が統合の直前ではなく、その手前にあることです。表の右端に並べた対策は、どれも分解と委譲の工程で打つものになっています。土台に近いところほど、先に決めておきます。
この章のまとめ
統合は、失敗が現れる場所です。生まれる場所は分解と委譲なので、直す手も同じ場所に打ちます。
09サブエージェント設計で、ワーカーの権限はAI社員として最初にどこまで絞るんですか？
権限は、後から広げるのではなく、最初から狭く始めます。
Claude Codeの公式ドキュメントによると、サブエージェントの定義ファイルは、許可するツールを一覧で絞り込むtoolsフィールドを持ちます（出典: Claude Code公式）。指定しなければ、利用可能な全ツールを継承します。次は、その考え方を一般化した例です。
---
name: research-worker
description: 一次情報の裏取りに使う。書き込みはしない
tools: Read, Grep, Glob, WebFetch
---WriteやEditをtoolsに含めなければ、このワーカーはファイルを書き換えられません。調べるだけの仕事に書き込みを渡さない、という線引きが、そのまま設定になります。
WEBMARKSでは、実働のAI社員に次の権限を渡していません。
- 削除・強制上書きにつながるコマンドを実行する権限
- 送信・公開・決済など対外的に確定する操作の権限
- 人間ゲートを経由せずに正式版へ書き込む権限
渡してよい仕事かどうかと、権限を絞れる仕事かどうかは、別の軸です。両方を満たしたところが、今日そのまま任せられる範囲になります。片側だけの仕事は、渡す前に決めることが1つ残っています。
この章のまとめ
権限設計は、事故が起きてから足す機能ではありません。委譲プロンプトを書くのと同じタイミングで決めます。
10本誌のAI活用では、サブエージェント設計をどう分担しているんですか？
本メディア自体が、この分業の実例です。WEBMARKSの委譲ルールは、上位モデルをディレクターに固定する構成を定義しています（2026-07-24制定）。実働は、日本語ドラフトの執筆・Vault内外の裏取り・機械的な整形という3種類の子エージェントへ渡します。
この記事も、その1本です。ディレクターが記事IDとテーマを委譲プロンプトの形で渡し、執筆役の子エージェントが公式ドキュメントを実際に取得しながら書いています。品質ラインの中身は『AI記事の品質管理｜5段階で差し戻された15件と、漏れた数字』で開示しています。
規模も実測できます。直近の実測（2026-07-28、記事フォルダのファイル一覧のカウント）では20本を超えていました。複数の執筆ワーカーが並行して書き込むため本数は数えるたびに変わり、確定値は公開直前に数え直します。第1弾50本の計画に対して、積み上げている途中です。
WEBMARKSのAI社員体制は、7部署・30体の役割定義を2026-06-24に統合したものです。ただし、体制図があることと分業が回っていることは、別に数えます。
11サブエージェントの委譲で、つまずきやすいのはどの4点ですか？
1つ目は、判断そのものをワーカーへ渡してしまうことです。委譲先の設計や成果の突合まで任せると、誰も全体を見なくなり、矛盾に気づく人がいなくなります。
2つ目は、並列数を増やしただけで安心することです。公式ドキュメントは、テストと隔離環境での確認を欠かさないよう促しています（出典: Anthropic公式）。増やす前に、委譲プロンプトが4点を満たしているかを確かめます。
3つ目は、ディレクター自身が手を動かし始めてしまうことです。Claude Codeの公式ドキュメントも、リード役が委譲を待たずに実装を始めてしまう傾向に注意を促し、待つよう指示し直す運用を挙げています（出典: Claude Code公式）。
4つ目は、渡した権限を後から広げてしまうことです。WEBMARKSの委譲ルールは、実働の子エージェントに人間ゲート級の権限を後から足さないと明記しています（2026-07-24制定）。動作確認のたびに境界を緩めると、設計した意味が薄れます。
12AI導入の前に、サブエージェント設計で何を確認しておきますか？
増やすかどうかの判断は、次の順で回します。1体で通してから足す、足したら統合まで含めて測る、上回ったら戻す。この往復を1周させてから体数を決めます。
着手前の確認は、次の項目で足ります。
- ディレクターとワーカーの役割を、判断と作業で分けたか
- 委譲プロンプトに、ゴール・スコープ・入力・出力形式・制約・返し方の6項目があるか
- 並列数は目安の範囲に収め、統合コストが利益を上回っていないか
- ワーカーの成果を、ディレクターが突合してから統合しているか
- 複数の実行主体が同じ対象へ同時に触れないよう、範囲を宣言する仕組みがあるか
- ワーカーに送信・公開・削除・決済などの人間ゲート級の権限を渡していないか
- 統合後の成果物に、重複・抜け・上書きが残っていないか確認したか
13よくある質問
サブエージェント設計は何体から始めればいいですか
1体からで構いません。委譲プロンプトの4点（目的・出力形式・情報源の指針・境界）を満たせるかを、まず1体で確認してから並列数を増やすほうが安全です。1体で通ったプロンプトを型にしてから増やしてください。
ディレクターとワーカーは別のAIモデルを使う必要がありますか
必須ではありません。同じモデルでも役割は分けられます。ただし判断が要る工程に上位モデル、作業量が支配的な工程に下位モデルを割り当てると、コストを抑えやすくなります。Anthropicの実測でも、リード役とワーカーでモデルを分ける構成が報告されています（出典: Anthropic公式）。
サブエージェントとエージェントチームは何が違いますか
報告先が違います。サブエージェントは結果をディレクターへ返すだけですが、エージェントチームはワーカー同士が直接やり取りします（出典: Claude Code公式）。調整が要らない仕事はサブエージェント、議論が要る仕事はチームが向きます。
並列数を増やせば増やすほど速くなりますか
いいえ。目安の本数を超えると、調整のやり取りが増え、1体の遅れが全体を止める場面も出てきます。まず4〜6本前後で試し、統合にかかる時間を測ってから増減を判断してください。測るときは、並列で走っている時間ではなく、突合を終えるまでを1本の時間として見ます。
ワーカーに渡す権限はどう決めればいいですか
最初から狭く始めます。読み取りと調査だけで足りる仕事には、書き込み権限を渡しません。人間ゲートに触れる操作は、権限をどれだけ広げてもワーカーには渡しません。仕事の性質で渡す先を決め、次にその仕事に要る最小限のツールだけをtoolsに並べる順番です。
14まとめ｜今日やる3つのこと
分け目は、判断をどこに集めるかでした。並列数はタスクの本数から決め、統合の壊れ方は委譲の段階でつぶします。次の順で進めてください。
今日この順で手をつけます
渡さないものを先に書き出す
判断・突合・人間ゲートが手元に残ります
委譲プロンプトを1体ぶんだけ書く
6項目が埋まるかで、タスクの割り方の粗さが分かります
統合にかかった時間を測る
並列数を増やすか戻すかは、この数字で決まります
AI検索では、こう聞かれています
サブエージェントには、どこまで仕事を渡していいんですか？
「サブエージェント設計では、どの仕事をワーカーへ渡していいんですか？」の章で説明しています
AIエージェントは、同時に何体まで動かせるんですか？
「サブエージェントは、同時に何体まで動かすと速くなるんですか？」の章に目安があります
並列で動かした結果は、どうやってまとめるんですか？
「サブエージェント設計で、結果統合はどこから壊れるんですか？」の章で3つの型に整理しています
ワーカーに渡す権限は、どこまで絞ればいいんですか？
「サブエージェント設計で、ワーカーの権限はAI社員として最初にどこまで絞るんですか？」の章で扱っています
次に読むなら、この記事です
