Claude Codeのサブエージェント入門。並列で走らせて調べ物を任せる

Claude Codeを毎日使っていると、あるところで頭打ちになります。調べ物を頼み、その結果を踏まえて別のことを頼み、また別のファイルを読ませる。会話が長くなるほど反応が鈍くなり、最初のほうに伝えた前提を忘れはじめる。

この頭打ちを外してくれるのがサブエージェントです。うちではブログ記事の一括執筆やサイトの監査を、複数のサブエージェントに並列で任せています。慣れると、待ち時間の感覚がかなり変わります。

**この記事の結論：**サブエージェントは、親が指揮して子が別の作業場で動く仕組みです。並列で走るから速く、親の会話に余計な情報が混ざらないから精度も保てます。向くのは横断調査と独立した並列作業、向かないのは連続した判断が要る仕事です。

この記事で分かること：

• サブエージェント（Subagents）とは何か、通常の依頼と何が違うのか
• なぜ使うと速いのか
• 向いている仕事と、向いていない仕事
• 実務での使い方の流れと、指示の書き方
• 任せるときの注意点

1. サブエージェントとは — 親が指揮して、子が別の作業場で動く

普段のClaude Codeは、一つの会話の中で作業が進みます。あなたが指示を出し、Claudeがファイルを読み、結果を返す。この読んだ内容はすべて、同じ会話の中に積み上がっていきます。

サブエージェントは、この作業を別の場所に切り出す仕組みです。親（あなたが話している本体）が「この調査をやってきて」と子に投げると、子は自分専用の作業場を持って動き、終わったら結論だけを親に返します。子が途中で読んだ大量のファイルの中身は、親の会話には入ってきません。

会社に例えると分かりやすいです。あなたが上司で、Claude Codeが部下のリーダー。リーダーが調査員を何人か送り出して、報告書だけ受け取る。調査員がどの棚の何冊目を開いたかまでは報告されません。

呼び方は「サブエージェント」「Sub agents」「Subagents」など揺れがありますが、指しているものは同じです。

2. なぜ速くなるのか — 理由は2つ

並列で走る

一番分かりやすい効果です。3つの独立した調査があるとき、順番にやれば3回分待ちます。3体のサブエージェントに同時に投げれば、一番遅い1つが終わるまでの時間で済みます。

うちだとサイトの監査がこれです。表示速度、内部リンクの構造、メタ情報の抜け、構造化データの妥当性。それぞれ独立して調べられるので、まとめて投げてしまいます。順番に頼んでいたころと比べて、待っている時間の体感がまるで違います。

親のコンテキストが汚れない

こちらのほうが実は重要です。

Claudeが一度に扱える情報量には上限があります。調査のために30個のファイルを読ませると、その中身が全部いまの会話に積み上がります。積み上がるほど、本来やりたかった作業に使える余白が減り、最初に伝えた前提が薄まっていきます。長く使っていると出力がだんだん雑になるのは、これが原因のことが多いです。

サブエージェントに任せると、30ファイルを読むのは子のほうです。親には要約された結論だけが返る。親の会話は、判断に必要な情報だけの状態を保てるわけです。速さより、この「散らからない」効果のほうを僕は評価しています。

親に直接頼む場合と、サブエージェントに任せる場合の違いです。

3. 向いている仕事・向いていない仕事

ここを間違えると、かえって遅くなります。

向いていない仕事の代表はデバッグです。エラーを見て、仮説を立てて、試して、違ったら次を試す。この連続した判断の流れは、途中経過を全部見ている親が続けてやったほうが速いです。子に投げると、親は結論しか見られないので、外していたときに何がどう外れたのか分かりません。

小さな修正も向きません。「この行のタイポを直して」に子を立てるのは、書類1枚を運ぶために人を雇うようなものです。子を立ち上げて指示を書く手間のほうが大きくなります。

逆に、「調べて報告して」の形に書ける仕事は、ほぼ全部任せられます。うちがブログ記事の一括執筆を任せているのもこの形です。1記事ずつが独立していて、書き上がったものを最後に僕が読んで判断する。途中の相談は要りません。

Claude Code全般の使い方については、こちらに実運用の記録をまとめています。

あわせて読みたいClaude Codeの使い方 — 会社まるごとAIで回して分かった導入から実運用まで

4. 実務での使い方の流れ

うちがやっている手順はこうです。

1. 仕事を独立した単位に割る — 互いの結果を待たなくていい形に分ける。ここが一番大事で、ここを雑にやると子どうしで矛盾した結果が返ってきます
2. 子ごとに指示を書く — それぞれが単独で読んで意味が通る文章にする（次の章で詳しく書きます）
3. まとめて投げる — 独立しているものは同時に走らせる
4. 返ってきた報告を親でまとめる — 矛盾や重複をここで潰す
5. 人が最終確認する — 事実、数字、リンク、意図とのズレを自分の目で見る

指示の出し方は普通の日本語で構いません。「この3つのテーマについて、それぞれ別のサブエージェントで調べて」と頼めば、親が振り分けてくれます。専用の記法を覚える必要はほとんどありません。

サブエージェントは、あらかじめ役割を決めた「型」として用意しておくこともできます。調査担当、レビュー担当、といった具合です。ただし、この定義の置き場所やファイルの書き方はバージョンによって変わるので、実際に作るときは公式ドキュメントで最新の手順を確認してください。

指示を書くときに外せない要点です。

5. 指示の書き方 — 子は親の会話を知らない

サブエージェントで一番つまずくのがここです。

**子は、あなたと親がここまで話してきた内容を知りません。**別の作業場で動くというのは、そういうことです。親の頭の中にある「さっき決めた方針」「前提として共有した資料」は、明示的に渡さないかぎり届きません。

だから指示は自己完結させます。

• 「さっきの方針で調べて」ではなく、方針をその指示の中にそのまま書く
• 「例のファイルを見て」ではなく、読ませたいファイルのパスを書く
• 「いつもの形式でまとめて」ではなく、見出し・箇条書き・結論の3部構成、と形を指定する
• 「よさそうな順に並べて」ではなく、アクセス数の多い順、同数なら更新日が新しい順、と基準を書く

書いていて回りくどく感じるくらいでちょうどいいです。新しく入った人に、引き継ぎ資料だけ渡して作業をお願いするときと同じだと考えると外しません。何を読めばいいか、何を判断基準にするか、どんな形で返してほしいか。この3つを書いておけば、だいたい期待通りのものが返ってきます。

もう一つ、返してほしい形を指定しておくと後がぐっと楽になります。「箇条書きで5つ以内」「該当ファイルのパスを添えて」のように出力の形を決めておくと、複数の子から返ってきた報告を並べて比較できます。

6. 注意点 — 任せる前に知っておくこと

結果の検証は人がやる

サブエージェントは、親が結論だけを受け取る仕組みです。つまり、途中で何を見落としたかは親にも分かりません。「調べました、問題ありませんでした」という報告が本当かどうかは、報告だけでは判断できない。重要な調査なら、報告の根拠（どのファイルを見たか、どこにその記述があるか）を書かせて、抜き取りで自分の目で確認してください。

投げすぎると管理できなくなる

同時に走らせる数を増やせば増やすほど速くなる、とはなりません。返ってくる報告が増えるほど、まとめる側の負荷が上がります。矛盾した内容が混ざっていても気づきにくくなる。うちの感覚では、一度に扱えるのはせいぜい数体までです。それ以上は、まとめる作業のほうが本業になってしまいます。

タスクを分け間違えると手戻りになる

「前の結果を踏まえて次を決める」形の仕事を無理に並列にすると、噛み合わない報告が並びます。分けられるかどうか迷ったら、順番にやったほうが結局早いことが多いです。

**注意：**サブエージェントの細かい仕様（設定ファイルの置き場所、指定できる項目、同時に走らせられる上限、使えるモデルの種類）は、バージョンによって変わります。この記事では、変わりにくい考え方の部分だけを書きました。実際に設定を書くときは、必ず公式ドキュメントで現在の仕様を確認してください。ネット上の解説記事は、書かれた時点の仕様のまま残っていることがよくあります。

コストは増える

子を並列で走らせれば、そのぶん処理量は増えます。速さと引き換えに使用量が伸びるので、上限のあるプランを使っているなら、重い並列作業は時間帯を分けるなどの工夫が要ります。

サブエージェントに任せる前に押さえておく注意点です。

よくある質問

サブエージェントとスラッシュコマンドやスキルは何が違いますか

大まかに言うと、スラッシュコマンドやスキルは「やり方をあらかじめ書いておく」仕組みで、サブエージェントは「別の作業場で走らせる」仕組みです。目的が違うので、組み合わせて使えます。たとえば、決まった手順を書いておいて、それをサブエージェントに実行させる、という形です。ただし呼び方や機能の境目はバージョンで変わることがあるので、最新の定義は公式ドキュメントを見てください。

何体まで同時に走らせるのが現実的ですか

技術的な上限とは別に、人がまとめられる数が実質的な上限になります。うちは数体までにしています。それ以上に増やすと、返ってきた報告を突き合わせる作業に時間を取られて、並列にした意味が薄れました。増やすより、一つひとつの指示を具体的にするほうが効きます。

エンジニアでなくても使えますか

使えます。うちが任せているのは、調べ物、記事の下書き、サイトの点検といった仕事で、コードを書かせるものばかりではありません。「調べて報告して」の形に書ける仕事なら分野は問いません。むしろ非エンジニアの業務のほうが、横並びで独立した調査が多いので相性はいいと思っています。

まとめ

• サブエージェントは、親が指揮して子が別の作業場で動く仕組み。返るのは結論だけ
• 速いのは並列だからだけでなく、親のコンテキストが汚れないから
• 向くのは横断調査・複数ファイルの分析・独立した並列作業。向かないのは連続した判断とデバッグ、小さな修正
• 子は親の会話を知らないので、指示は自己完結させる
• 報告の正しさは人が確認する。細かい仕様はバージョンで変わるので公式ドキュメントで確認する

うちは記事の一括執筆とサイト監査で毎週使っていますが、効いているのは速度そのものより、親の会話を判断だけに使える状態を保てることでした。長時間の作業で出力が雑になっていく感覚がある人ほど、試す価値があると思います。

AIをどう業務に組み込むか整理したい方は、お問い合わせからどうぞ。

関連記事：AIで業務を効率化する。どの仕事から渡すかの決め方と、うちの実例／Discord月次報告の自動化実録 — AIがスクショを読んで集計まで全自動