SASmall AI System

Sub Agent

サブエージェントの設計

サブエージェントは「AIを増やす」仕組みではなく、「文脈を分ける」仕組みです。調べる係とまとめる係を分ける、作る係と見る係を分ける。人の組織と同じで、分ける単位を間違えると逆に遅くなります。

運用 ・ 読了目安 約9

サブエージェントとは

親のエージェントが、独立した文脈を持つ子のエージェントに作業を任せる仕組みです。 子は自分の会話履歴を持ち、作業が終わると結果だけを親に返します。子が読んだ大量の資料は、親には流れ込みません。

これが効くのは、調査のように「読む量は多いが、必要な結論は短い」作業です。 親が自分で読むと、その後の判断が大量の情報に引きずられます。子に読ませて結論だけ受け取れば、判断が濁りません。

並列実行も同じ仕組み

2026年時点で主要なコーディングエージェントは複数の子を同時に走らせられます。 独立した作業がN件あるなら、順番にやる理由はありません。

向く仕事・向かない仕事

仕事の種類判定理由
調査・情報収集向く出力が長くなりがち。別文脈でやらせて結論だけ受け取ると、親側の判断がぶれない。
レビュー・チェック向く作った本人とは別の視点が要る作業。「作る側」と「見る側」を分けられる。
同じ処理の大量繰り返し向く1件ずつ独立しているので並列に投げられる。時間が大きく縮む。
方針の決定向かない全体の文脈が要る。切り出すと前提を見落とす。親が判断する。
連続して状態が変わる作業向かない前の結果に次が依存する処理は、分けると整合が壊れる。
顧客への送信・確定処理向かない取り消せない操作。人の確認を挟む位置に置く。

定義ファイルの書き方

サブエージェントの定義は、Skill とよく似た形をしています。frontmatter に「誰か・いつ呼ぶか・何を使えるか」、 本文に「どう振る舞うか」を書きます。次の例は、見積書の金額をチェックする係です。

.claude/agents/price-checker.md
---
name: price-checker
description: 見積書のドラフトを読み、料金表と照合して金額の誤りを指摘する。金額チェック、見積もり確認を頼まれたときに使う。修正はしない。指摘のみ返す。
tools: Read, Grep, Glob
model: sonnet
---

あなたは見積書の金額チェック担当です。

## 参照する資料
- `data/price-table.csv` — 正となる料金表
- `docs/discount-rules.md` — 割引の適用条件

## 手順
1. 渡された見積書から、品目・単価・数量・小計をすべて抽出する。
2. 料金表と1行ずつ照合する。
3. 割引が適用されている行は、適用条件を満たしているか確認する。
4. 合計金額を再計算し、記載値と一致するか確認する。

## 返すもの
以下の形式のみを返す。文章での説明や感想は書かない。

| 行 | 品目 | 記載値 | 正しい値 | 問題 |
|----|------|--------|----------|------|

問題が1件もなければ「差異なし」とだけ返す。

## 禁止事項
- 見積書を書き換えない。指摘だけを返す。
- 料金表にない品目を推測で埋めない。「料金表に該当なし」と書く。
- 判断に迷ったら指摘として挙げる。黙って見逃さない。

「修正はしない。指摘のみ返す」を書く理由

チェック係に修正権限を与えると、指摘せずに直してしまい、何が問題だったのかが記録に残りません。 役割を1つに絞ることで、結果が検証可能になります。

権限と停止条件

  1. 1

    読み取りだけで始める

    最初のサブエージェントには、ファイルの読み取りと検索だけを許可します。書き込み・削除・送信は与えません。1か月動かして、どこで間違うかの傾向を掴みます。

  2. 2

    書き込み先を1か所に限定する

    書き込みを許すときは、出力先のフォルダを1つに固定します。「下書きは drafts/ にだけ書く」と決めておけば、間違っても本番データに届きません。

  3. 3

    止まる条件を先に書く

    「情報が足りなければ推測せず質問して止まる」「金額に差異があれば処理を続けず報告する」。止まる条件がないエージェントは、迷ったときに勝手に決めます。

  4. 4

    結果の受け取り方を固定する

    表形式、箇条書き、決まったキー名のリストなど、返す形を決めます。形が決まっていると、人の確認が数秒で済みます。

取り消せない操作は子に渡さない

メール送信、請求確定、ファイル削除、外部への公開。これらは人の確認を挟む位置に置きます。 自動化の効果が大きいのは事実ですが、事故の規模も同じだけ大きくなります。

実務で使える3つの型

型1: 調べる係を分ける

「この分野の情報を集めて要点だけ返す」係を作ります。集めた生データは子の文脈に留まり、親には結論だけが渡ります。親の判断材料が散らからないのが利点です。

例: 競合の料金体系を調べて、自社と違う点を3つだけ挙げる

型2: 見る係を分ける

作った本人とは別のサブエージェントにチェックさせます。同じ文脈にいると自分の出力を肯定しがちなので、あえて分けることに意味があります。

例: 見積書の金額チェック、文面の忌み言葉チェック、入力漏れの確認

型3: 同じ処理を並べる

対象がN件あって、それぞれ独立しているなら、同じ定義のサブエージェントをN個走らせます。1件ずつ順にやるより大幅に速くなります。

例: 50件の問い合わせメールを、それぞれ分類して要約する

やりがちな失敗

やりがちな失敗

とりあえず何でもサブエージェントに投げる。

こうする

切り出すたびに文脈の受け渡しコストが発生します。親が自分でやったほうが速い作業は切り出しません。

やりがちな失敗

子に「よろしく」と丸投げして、返す形を決めない。

こうする

返却形式を定義に書きます。形が決まっていないと、毎回違う形で返ってきて確認に時間がかかります。

やりがちな失敗

子に全ツールの権限を渡す。

こうする

その仕事に必要な道具だけを渡します。読むだけの係に書き込み権限は不要です。

やりがちな失敗

子の結果をそのまま信じて次に進む。

こうする

子も間違えます。重要な判断の前には、親側で数値や事実を1つだけでも突き合わせる工程を入れます。

やりがちな失敗

子から親に大量のログを返させる。

こうする

結論と根拠だけを返させます。全部返すと、文脈を分けた意味がなくなります。

やりがちな失敗

子が迷ったときの挙動を決めていない。

こうする

「不明なら推測せず報告して止まる」を明示します。書かないと、もっともらしい推測で進みます。

設計チェックリスト

  • その仕事は、独立して判断できる単位になっているか
  • description に「いつ呼ぶか」が書かれているか
  • 渡すツール(権限)を必要最小限に絞ったか
  • 返してほしい形式を具体的に指定したか
  • 情報が足りないときに止まる条件を書いたか
  • 取り消せない操作(送信・確定・削除)を子に含めていないか
  • 結果を人が確認する場所と担当を決めたか