サブエージェントは、増やすほど会社が速くなる機能に見えます。 検索して出てくる解説も「作り方」「おすすめ構成」が中心で、専門の担当者を何体も並べた図がよく出てきます。ところが、うちで実際に動いているのは3体だけです。
スキルのほうは、同じ説明を3回書くたびに1個増やしていったら十数個まで増えました。同じ勢いで作っていたら、サブエージェントも同じ数になっていたはずです。そうならなかったのは、途中で「増やさない基準」を先に決めたからでした。
スキルと何が違うのか
違いは「何を書くか」ではなく、どこで動くかでした。
スキルは、いまの会話の中で開かれる手順書です。開いた内容も、途中の作業も、全部そのまま会話に残ります。サブエージェントは違って、別の会話で動く担当者です。本体とは切り離された場所で調べものをして、終わったら結論だけを持って帰ってきます。
| CLAUDE.md | Skills | サブエージェント | |
|---|---|---|---|
| 読まれるタイミング | 毎回、必ず全文 | 関連する依頼のときだけ | 明示的に呼んだときだけ |
| 書くもの | 会社の前提・禁止事項 | 特定の仕事の手順と判断基準 | 役割と判定基準（担当者の職務記述書） |
| 動く場所 | いまの会話 | いまの会話 | 切り離された別の会話 |
| 途中で質問 | — | できる | できない |
| 向く仕事 | 全体の地図 | 手順が決まっている仕事 | 大量に読んで、短く答える仕事 |
最後の2行が、判断のほぼ全部です。切り離されているから大量に読ませても本体が重くならない。切り離されているから途中で確認が取れない。 この2つは同じ性質の裏表で、片方だけ都合よく手に入れることはできません。
実際に動いている3体
うちで動いている3体は、こういう中身です。
| 名前 | やること | 持たせた道具 | 定義の行数 |
|---|---|---|---|
prospect-researcher | 営業リストの候補企業を1社ずつ検証し、対象内か対象外かだけ返す | Web検索・ページ取得・ファイル読み | 78行 |
meeting-researcher | 商談の前に相手企業の公開情報を調べ、提案の材料として返す | Web検索・ページ取得・ファイル読み | 87行 |
consistency-checker | サイト・提案資料・応募文の間で、数字やブランド名が食い違っていないかを監査する | ファイル読み・検索（書き換え権限なし） | 54行 |
3体に共通しているのは、読む量が返す量より圧倒的に多いことです。営業リストの検証は1社あたり数ページを読んで「対象内／対象外」の1行を返します。監査役は社内のファイルを横断で検索して、食い違った箇所だけを数行で返します。読んだページを全部会話に持ち込まずに済むのが、そのままメリットになっています。
consistency-checker に書き換えの権限を持たせていないのは意図的です。修正までやらせると、直したのか直していないのかを結局こちらが読み直すことになります。指摘だけ返させて、直すかどうかは人が決める。 監査役はこの形が一番使いやすいという結論になりました。
4つ全部を満たさないと作らない
作りたくなる場面は、実際にはかなり頻繁に来ます。「この作業、専任にしたほうが速いのでは」と思う瞬間です。そこで止まれるように、社内のルールとして4つの条件を書きました。
| # | 条件 | 落ちるとどうなるか |
|---|---|---|
| 1 | 反復がある（同じ形の作業を3回以上見た、または1タスク内に10回以上繰り返す） | 1回きりの作業に専任を置くことになり、設計の手間のほうが高くつく |
| 2 | 指示書1枚で任せられる（判断基準を文章で書き切れる） | 基準が空のまま手順だけが書かれ、それらしい嘘が返ってくる |
| 3 | 途中の確認が要らない | 質問できないので、迷った場所を勝手に埋めて進む |
| 4 | 読む量 ≫ 返す量 | 切り離す意味がない。スキルで足りる |
4つのうち、実際に一番多くの案を落としているのは3番でした。たとえば「提案資料を作る」は、反復もあるし手順も書けます。それでも任せられません。相手にいくらで出すか、どの実績を載せるか——途中で必ず人に聞くことが出てくるからです。聞けない相手に任せると、聞かずに決めてしまいます。
逆に1番と4番を両方満たしたのが、営業リストの個社検証でした。100社の候補を1社ずつ見る作業は、同じ形が100回続きます。しかも1社ぶんの結論は1行です。実際には10〜15社ずつ束ねて複数体に同時に投げていて、営業リストを作った記録で書いた工程のうち、この検証の部分だけが切り出されています。
4体目を作りかけて、やめた
正直に書くと、4体目を作りかけたことはあります。
商談の前に「相手の競合が何を打ち出しているか」を横並びで比べたい場面が続いて、競合分析の専任を作ろうとしました。ただ、書き始めてすぐ気づいたのは、調べる先も読むページも、既にいる meeting-researcher とほとんど同じだということでした。違うのは出力の形だけです。
結局、新しく作らずに meeting-researcher の定義に「競合分析モード」を足しました。冒頭に「こう呼ばれたらAモード、こう呼ばれたらBモード」という表を1つ置いただけです。
似た役割を2つ並べると、呼び分けを間違えます。これはスキルのほうでも同じ失敗をしていて、そのときは互いの説明文に相手の名前を書いて排他にしました。役割が重なるなら、増やさずに既存を書き足す。 サブエージェントでも同じルールを適用しています。
自分の会社で判定するには
これから1体目を考えるなら、「読む量 ≫ 返す量」だけを先に当ててみるのが一番速いはずです。反復も指示書も後から整えられますが、この条件だけは仕事の性質そのもので、後から変えられません。
競合サイトを20件見て一言でまとめる、届いたメールを全部読んで要対応だけ抜く、書類を突き合わせて食い違いだけ挙げる——このあたりは、どの会社にも1つはあるはずです。
会社の前提そのものがまだファイルになっていないなら、サブエージェントより先にCLAUDE.mdを書くほうが効きます。手順の切り出しから始めたい場合はSkillsが、役割の設計から入りたい場合はAI社員のつくり方が入口になります。Claude Code自体をこれから触る段階であれば、Claude Codeとはから順に読んでいただくのが早いかもしれません。
冒頭の問いに戻ります。サブエージェントは、増やすほど速くなるのか。うちで速くなったのは、増やしたときではなく、増やさない基準を決めたときでした。 3体のままで足りているのか——これは正直、まだ答えを出せていません。増やす理由が4つ揃った日に、4体目を作ることになります。