サブエージェントの仕組みと使いどころ

《 Claude完全ガイド目次へ》

10秒でいうと

作業の一部を、別の机で働く担当に切り出す仕組みです。
散らかった作業の跡が本体の会話に戻ってこないのが、いちばんの効き目です。

No.22でレビュー役を分けたほうがよいと書きました。それを実際に成立させる仕組みが、サブエージェントです。

ここからClaude Code寄りの話になります。概念だけ押さえておけば、第5章で困りません。

別の机で働く
履歴を引き継ぐ形もある
どう作るか
上限がある
エージェントチームとの違い
つまずきポイント
まとめ
次に読む

別の机で働く

サブエージェントは、本体とは独立した作業机を持ちます。公式ドキュメントの言葉では、独立したコンテキストウィンドウ、独自の指示、限定した道具、独立した権限を持ちます。

効き目は4つです。

作業の跡が残らない。ファイルを50個読んで、ログを大量に出して、そのうち使うのは3行だった。その50個分が本体の机に載りません。返ってくるのは要約だけです。No.04の作業机の話が、そのまま効いています。

先入観が入らない。通常のサブエージェントは会話の履歴を持たずに始まります。本体でのやりとりも、すでに読んだファイルも見ていません。レビュー役として使うと、これが効きます。作った経緯を知らない人が見るからです。

同時に動ける。独立した作業なら、複数を並行させられます。

役ごとに設定を変えられる。使える道具、使うモデル、権限の強さを役ごとに決められます。読むだけのレビュー役に、書く道具を渡さない、といった形です。

履歴を引き継ぐ形もある

フォークと呼ばれる形は逆で、親の会話をまるごと引き継ぎます。

使い分けは単純です。

	引き継がない（通常）	引き継ぐ（フォーク）
何を持つか	頼んだ内容だけ	これまでの会話すべて
向く仕事	調査、レビュー、独立した作業	経緯が要る込み入った脇道
先入観	入らない	入る

レビューは引き継がないほうがよく、続きの相談は引き継ぐほうがよい。判断の軸はここです。

どう作るか

Markdownファイル1枚で作れます。先頭にYAMLで設定を書き、そのあとに指示を書く形です。

---
name: quote-checker
description: 見積の一覧表を検算する。表を作ったあとに使う
tools: Read, Grep
model: sonnet
---

あなたは見積の検算担当です。渡された表について、次を確認してください。
・行数が、元のPDFの枚数と一致しているか
・単価×数量が合計と合っているか
・空欄がどこにあるか

直さないでください。指摘だけを、優先度順に返してください。

置き場所は2つあります。.claude/agents/ に置けばそのプロジェクト用、~/.claude/agents/ に置けば全プロジェクト用です。プロジェクト用は、チームで共有できます。

tools で使える道具を絞っているのがポイントです。この検算担当は読むことしかできないので、間違って表を書き換えることがありません。No.21の「範囲を先に区切る」がここに効いています。

上限がある

公式ドキュメントに明記されている制限です。

同時に動かせるのは20個まで（設定で変更可）
入れ子は3階層まで（設定で変更可）
サブエージェントの机の広さは、本体ではなく自分のモデルのもの

最後の1つは見落としやすい。本体が広いモデルでも、サブエージェントに軽いモデルを指定すれば、その分の広さしかありません。大量の資料を読ませる役に軽いモデルを割り当てると、そこで詰まります。

エージェントチームとの違い

エージェントチームは別の仕組みです。サブエージェントが1つのセッションの中の担当なのに対して、エージェントチームは複数のセッションを立てて束ねる形になります。

規模が違うだけで、考え方は同じです。役を分け、渡すものを絞り、返ってくるものを要約にする。まずサブエージェントで感覚をつかんでから触るのが順当です。

やってみよう：レビュー役の指示書を設計する（5分）

実際に動かさなくても構いません。設計の練習です。

プロンプト
“`
私の仕事のレビュー役を、独立したエージェントとして設計します。
次を決めてください。
・何を確認させるか（5項目まで）
・使わせてよい道具（読むだけか、書けるか）
・返してほしい形式
・確認させないこと

仕事：（自分の仕事を書く）
“`

期待される結果：4つが具体的に決まる。「使わせてよい道具」が読むだけになっている。

うまくいかないとき：「確認させないこと」が出てこないなら、そこが一番大事な項目です。何でも見させると、指摘が散って使えなくなります。