Sub Agent
サブエージェントの設計
サブエージェントは「AIを増やす」仕組みではなく、「文脈を分ける」仕組みです。調べる係とまとめる係を分ける、作る係と見る係を分ける。人の組織と同じで、分ける単位を間違えると逆に遅くなります。
運用 ・ 読了目安 約9分
サブエージェントとは
親のエージェントが、独立した文脈を持つ子のエージェントに作業を任せる仕組みです。 子は自分の会話履歴を持ち、作業が終わると結果だけを親に返します。子が読んだ大量の資料は、親には流れ込みません。
これが効くのは、調査のように「読む量は多いが、必要な結論は短い」作業です。 親が自分で読むと、その後の判断が大量の情報に引きずられます。子に読ませて結論だけ受け取れば、判断が濁りません。
並列実行も同じ仕組み
向く仕事・向かない仕事
| 仕事の種類 | 判定 | 理由 |
|---|---|---|
| 調査・情報収集 | 向く | 出力が長くなりがち。別文脈でやらせて結論だけ受け取ると、親側の判断がぶれない。 |
| レビュー・チェック | 向く | 作った本人とは別の視点が要る作業。「作る側」と「見る側」を分けられる。 |
| 同じ処理の大量繰り返し | 向く | 1件ずつ独立しているので並列に投げられる。時間が大きく縮む。 |
| 方針の決定 | 向かない | 全体の文脈が要る。切り出すと前提を見落とす。親が判断する。 |
| 連続して状態が変わる作業 | 向かない | 前の結果に次が依存する処理は、分けると整合が壊れる。 |
| 顧客への送信・確定処理 | 向かない | 取り消せない操作。人の確認を挟む位置に置く。 |
定義ファイルの書き方
サブエージェントの定義は、Skill とよく似た形をしています。frontmatter に「誰か・いつ呼ぶか・何を使えるか」、 本文に「どう振る舞うか」を書きます。次の例は、見積書の金額をチェックする係です。
---
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か月動かして、どこで間違うかの傾向を掴みます。
- 2
書き込み先を1か所に限定する
書き込みを許すときは、出力先のフォルダを1つに固定します。「下書きは drafts/ にだけ書く」と決めておけば、間違っても本番データに届きません。
- 3
止まる条件を先に書く
「情報が足りなければ推測せず質問して止まる」「金額に差異があれば処理を続けず報告する」。止まる条件がないエージェントは、迷ったときに勝手に決めます。
- 4
結果の受け取り方を固定する
表形式、箇条書き、決まったキー名のリストなど、返す形を決めます。形が決まっていると、人の確認が数秒で済みます。
取り消せない操作は子に渡さない
実務で使える3つの型
型1: 調べる係を分ける
「この分野の情報を集めて要点だけ返す」係を作ります。集めた生データは子の文脈に留まり、親には結論だけが渡ります。親の判断材料が散らからないのが利点です。
例: 競合の料金体系を調べて、自社と違う点を3つだけ挙げる
型2: 見る係を分ける
作った本人とは別のサブエージェントにチェックさせます。同じ文脈にいると自分の出力を肯定しがちなので、あえて分けることに意味があります。
例: 見積書の金額チェック、文面の忌み言葉チェック、入力漏れの確認
型3: 同じ処理を並べる
対象がN件あって、それぞれ独立しているなら、同じ定義のサブエージェントをN個走らせます。1件ずつ順にやるより大幅に速くなります。
例: 50件の問い合わせメールを、それぞれ分類して要約する
やりがちな失敗
やりがちな失敗
とりあえず何でもサブエージェントに投げる。
こうする
切り出すたびに文脈の受け渡しコストが発生します。親が自分でやったほうが速い作業は切り出しません。
やりがちな失敗
子に「よろしく」と丸投げして、返す形を決めない。
こうする
返却形式を定義に書きます。形が決まっていないと、毎回違う形で返ってきて確認に時間がかかります。
やりがちな失敗
子に全ツールの権限を渡す。
こうする
その仕事に必要な道具だけを渡します。読むだけの係に書き込み権限は不要です。
やりがちな失敗
子の結果をそのまま信じて次に進む。
こうする
子も間違えます。重要な判断の前には、親側で数値や事実を1つだけでも突き合わせる工程を入れます。
やりがちな失敗
子から親に大量のログを返させる。
こうする
結論と根拠だけを返させます。全部返すと、文脈を分けた意味がなくなります。
やりがちな失敗
子が迷ったときの挙動を決めていない。
こうする
「不明なら推測せず報告して止まる」を明示します。書かないと、もっともらしい推測で進みます。
設計チェックリスト
- その仕事は、独立して判断できる単位になっているか
- description に「いつ呼ぶか」が書かれているか
- 渡すツール(権限)を必要最小限に絞ったか
- 返してほしい形式を具体的に指定したか
- 情報が足りないときに止まる条件を書いたか
- 取り消せない操作(送信・確定・削除)を子に含めていないか
- 結果を人が確認する場所と担当を決めたか
Next
続けて読む
AGENTS.md の書き方
AIコーディングエージェントに渡す共通指示ファイル。何を書き、何を書かないかを、実際に貼れる雛形つきで解説します。
Agent SkillSkill(SKILL.md)の作り方
「毎回同じ説明をしている作業」を手順ファイルとして資産化する方法。frontmatter の書き方と段階的読み込みの考え方を扱います。
MCPMCP で社内システムにつなぐ
2026-07-28 版仕様を前提に、AIツールから社内データへ安全につなぐ手順と、やってはいけない構成を整理します。
Prompt実務プロンプトの型
コツ集ではなく、業務で再利用できる4つの型。案内文・議事録・項目抽出・仕分けの実例で示します。