サブエージェントとは

最終更新: 2026年8月12日

1つの仕事を役割ごとに分けて、それぞれを別のAIに担当させる設計です。 作る役、確かめる役、調べる役。人間のチームの分業と同じ発想です。

いちばんよく挙がる形が「作る役と確かめる役を分ける」。 理由は単純で、作った本人は自分の失敗に気づきにくいからです。

1体に全部やらせると、何が起きるか

禁止されているわけではありません。単純な仕事なら1体で十分です。 問題が出るのは、次の3つが同時に起きるときです。

1. 指示が肥大化する

調べ方の指示、書き方の指示、点検の観点、出力の形式。 全部を1つの指示文に書くと、数千トークンの巨大な指示になります。 そして長い指示ほど、後半が効かなくなります。

2. 前の作業に引きずられる

自分で書いた文章を、自分で点検する。 人間でも難しいことですが、AIでも同じです。 会話に「これを書いた」という履歴が残っている状態で 「これを厳しく点検して」と頼んでも、甘くなります。

確かめる役に作る過程を渡さないのが、この設計の肝です。 要件と成果物だけを渡すと、思い込みなしで見られます。 「誰が書いたか知らない文章を点検する」状態を人工的に作るわけです。

3. 費用が積み上がる

1体で長い会話を続けると、過去のやりとりを毎回送り直すぶんが 積み上がります。役割で区切れば、そこで履歴がリセットされます。

前提：1発言300トークン、返答800トークン、単価は仮に入力$3・出力$15 （100万トークンあたり）。呼び出し回数は同じ20回です。

同じ仕事量でも約58.3%安くなりました。 「分けると呼び出しが増えて高くなる」と思われがちですが、 実際には毎回送り直す量が減るぶんで逆転することが多くあります。 仕組みはコンテキストエンジニアリングで計算しています。

よく使われる分け方

全部を用意する必要はありません。 まず「作る役」と「確かめる役」の2つから始めるのが現実的です。 これだけで、見落としはかなり減ります。

分けるときに決めること

1. それぞれに何を渡すか。 全部を渡すと分けた意味がなくなります。 確かめる役には過程を渡さない。調べる役には書き込む道具を持たせない。 渡さないものを決めるのが設計です。
2. 何を返させるか。 調べる役が検索結果の全文を返すと、まとめ役のコンテキストが一気に膨らみます。 要点だけを決まった形式で返させます。
3. やり直しは何回までか。 確かめる役が不合格を出したら作る役に戻す、という往復は 上限を決めないと止まりません。2〜3回が現実的です。
4. 合格の基準は何か。 「良い感じか」では毎回ブレます。判定できる条件を書きます。 ここは評価（Evals）の考え方がそのまま使えます。

分けないほうがいい場合

単純な仕事を分けても、遅くなるだけです。 呼び出しの回数だけ待ち時間が増え、役の間で情報が欠ける事故も起きます。 次のどれかに当てはまるなら、1体のままにしておきます。

• 1〜2往復で終わる仕事
• 点検する基準がまだ言葉にできていない（分けても確かめる役が機能しません）
• 指示文がまだ短く、後半が効かなくなる兆候もない
• 返答の速さが重要な用途

分けるのは症状が出てからで間に合います。 指示が長くなってきた、点検が甘い、費用が伸びている。 このどれかを感じたときが、分ける時期です。

グラフとの違い

よく似ていますが、見ている単位が違います。

• サブエージェントは役割の分け方の話。 誰に何を担当させ、何を渡すかを決めます。
• グラフはつなぎ方の話。 どういう順で流し、どこで分岐し、失敗したらどこへ戻るかを決めます。

役を分けたら、その役どうしをどうつなぐかという問題が出てきます。 そこでグラフの出番になる、という順番です。 分け方だけ決めて、つなぎ方を決めていない状態がいちばん壊れやすいところです。

層のなかでの位置づけ

• AIエージェント設計の5階層マップ — 用語の位置づけを1枚で
• グラフエンジニアリング — 分けた役をどうつなぐか
• Evals（評価） — 確かめる役の基準をどう作るか
• コンテキストエンジニアリング — 何を渡し、何を渡さないか

本記事は2026年8月時点で見られる設計パターンを整理したものです。用語の使われ方や具体的な実装はツールによって異なります。記載した費用は、示した前提とトークン単価にもとづく概算です。特定のフレームワークやサービスを推奨するものではありません。