ClaudeCodeの代表的な概念として「サブエージェント」がある。
これは、メインのClaudeが作業の一部を別のAIに切り出して任せる仕組みのこと。
これをフル活用していくことが結構ClaudeCodeの主流な使い方だったんだけど、最近、Anthropicがこの方針に異を唱えている。
Building agents: When to fold subagents into your main agent loop
今回はこの記事をなぞりながら、ClaudeCodeの直近のベストプラクティスを考えていきたい。
結論としては「役割ごとにサブエージェントを増やす前に、まずメインエージェント1つ＋Skills・Toolsを検討する」と言うもの。
単に公式の記事を和訳するだけじゃなくて、実際にそれを業務に落とし込んだ場合、どんな挙動になるのか、個人ユーザーがどんな使い方をするべきなのかと言うところを紹介できればと思う。
より進んだClaudeCodeの探究をしたい人、ClaudeCodeのサブエージェントに興味がある人、最新のClaudeCodeニュースを追っている人などの参考になれば幸い。
そもそもサブエージェントとは？
サブエージェントは、メインのClaudeから作業の一部を任されるAIのこと。
普段ClaudeCodeで会話しているのはメインエージェント。サブエージェントはそこから作業を任されて、自分専用のコンテキストで作業する。そして、結果の要約だけをメインに返す。
公式ドキュメントでは、主な使いどころとして次のようなものが挙げられている。
- コンテキストの節約：大量の検索結果やログをメインの会話に持ち込まない
- ツールの制限：読み取り専用にするなど、使えるツールを絞れる
- 設定の再利用：一度作れば全プロジェクトで使い回せる
- コスト管理：軽い作業はHaikuなどの安いモデルに回せる
実際にこれは僕もやっていて、メインのAIを「AIマネージャー」として、複数の「AI社員」を操り、アウトプットを管理してもらうことをやっていた。
作り方
ここではざっくりとサブエージェントをどうやって作るのかを紹介する。設定方法のイメージを持ってくれると幸い。
作り方はシンプルで、Markdownファイルを1つ置くだけ。
- プロジェクト専用：
.claude/agents/に置く - 全プロジェクト共通：
~/.claude/agents/に置く
中身はこんな感じ。先頭に名前・説明・使えるツール・モデルを書いて、その下に役割を書く。
---
name: researcher
description: 市場調査や競合調査を担当する。調査系の依頼で使用。
tools: Read, Grep, Glob, WebSearch
model: sonnet
---
あなたは調査担当です。……このサブエージェントを役割ごとに作って、「調査担当」「企画担当」「執筆担当」と並べていく。これがここしばらくの定番の使い方だった。
今回の公式記事の概要
ここからは、今回の公式記事の中身をざっくり紹介していく。
記事はAnthropicのDiane Sarkis氏によるもので、2026年10月22日に公開された。
Building agents: When to fold subagents into your main agent loop
結論から言うと、主張は次の3つ。
- 役割ごとにサブエージェントを増やす前に、まずメインエージェント1つ＋Skills・Toolsで組めないかを考える
- そのほうがエージェント間の情報の取りこぼし・遅延・管理の手間が減り、品質やコストも改善しやすい
- ただし単一構成が常に正解ではない。実際のタスク達成率で比べて決める
ここで大事なのは、サブエージェントを否定する記事ではないということ。記事の冒頭でも、サブエージェントは検証・並列作業・権限管理に有効で、Anthropic自身も多くのエージェントで使っていると書かれている。
ただ、企業のエージェント導入では、サブエージェントを統合したほうが品質を保ったままコストと遅延を下げられた例が増えている。今回の記事はその話だ。
従来の話
従来のやり方は、司令塔のAIが仕事を振り分けるマルチエージェント方式だ。
ルーター（振り分け役）、計画担当、分野ごとの専門サブエージェントがいて、司令塔が「これは調査担当へ」「これは執筆担当へ」と回していく。会社の組織図みたいなイメージで、直感的にはわかりやすい。
ただ、記事ではこの構成でよく起きる問題として、次のようなものが挙げられている。
- 文脈の欠落：エージェント間の引き継ぎで細かい情報が抜け落ちる
- 遅延：AIの呼び出し回数が増えて、その分だけ遅くなる
- サブエージェントの乱立：似た役割のものが増えて重複し、どれが何を担当しているのかわからなくなる
- 指示の矛盾：後から指示を継ぎ足していくうちに、ルール同士が矛盾する（記事では「Frankenprompt」と呼んでいる）
記事は企業での導入を想定していて、下の2つは本来「部署ごとにサブエージェントを作るから乱立する」「各部署が指示を足すから矛盾する」という話だ。ただ、個人でも思いついたときにエージェントや指示を足していけば、同じことが起きると思う。
僕もサブエージェントを使っていて「文脈の欠落」はかなり気になる。何を引き継いでいて、何が抜け落ちているのかという部分がいまいち分かりづらい。
あと、サブエージェントを作ることにハマっていた時期もあるんだけど、一つのタスクに必要以上に時間がかかることが多くて、単一のチャットで試したら、時間も短くてアウトプットも良くなったこともある。
記事では、多くの場合「モデルが自力でできることまで、仕組み側で肩代わりしている」と指摘されている。昔のモデルには役割分担というお膳立てが必要だったけど、今はそこまでしなくていい、という話だ。
今回の構成
ここでは、記事が推している新しい構成を解説していく。
一言で言うと、1つのメインエージェントが、同じ会話の中で「計画→ツール実行→結果確認→計画修正」を繰り返す形だ。
計画を立てるAIと実行するAIが同じなので、途中で想定外のことが起きてもその場で計画を変えられる。引き継ぎがないから、情報も落ちない。
段階的開示（progressive disclosure）
「全部1つのAIにやらせたら、指示が膨らんでパンクするんじゃないの？」と思った人は鋭い。
そこで出てくるのが段階的開示という考え方だ。SkillsやToolsは、普段は短い説明文だけをAIに見せておく。そして、必要になったものだけ中身を読み込む。
こうすると、巨大なシステムプロンプトを抱えなくて済む。記事によると、ClaudeCode自体もより高度なモデル向けにシステムプロンプトを80%以上削減したそうだ。
また、Opus 4.5以降のモデルなら、従来の想定よりも多くの仕事を1つのループで管理できるようになったとも書かれている。
Skills・Tools・Knowledge Baseの役割分担
サブエージェントに書いていた中身は、次の3つに振り分ける。
- Skills：仕事の進め方。手順、ルール、判断基準。従来は専門サブエージェントのプロンプトに書いていた部分
- Tools／MCP：実際の操作。外部サービスの操作、最新データの取得、権限チェックなど
- Knowledge Base：たまにしか使わない参照資料。ポリシー、指標の定義、製品仕様など
記事では、資料を「検索用のツールから呼び出す」か「Skillの中に参照ファイルとして置く」形が勧められている。ClaudeCodeで言うと、Skillのフォルダに資料のMarkdownを入れておくか、Notionなどに置いてMCP経由で検索させる形になる。
逆に、資料を最初から全部プロンプトに貼り付けておくやり方は避けるべきとされている。
ツールについては、定義が30〜50個を超えると選択の精度が落ちやすい、という注意書きもある。ツールもSkillsも、増やせばいいというものではない。
移行の手順
記事では、いきなり全部を統合するのではなく、段階的に進める方法が紹介されている。
ここら辺は気になる人は公式の記事を確認しながら詳細を調べてみて欲しい。
- まず小さなテストを用意する：理想の回答例を10件ほど用意して、AIの出来を採点できるようにする
- サブエージェントを1つずつSkills・Toolsに置き換える：一緒に呼ばれることが多いもの、同じデータを扱うものから始める
- 置き換える前と後で結果を比べる：品質・速度・コストに加えて、どのタスクが成功から失敗に（またはその逆に）変わったかまで確認する
- 同じテストを何回か回す：1回だけでは出てこない失敗もあるから
サブエージェントは無くなるのか
結論、無くならない。
記事では、次のどれかに当てはまるならサブエージェントを残す価値があるとしている。
- コンテキストが膨らんで、単一エージェントの性能が実測で落ちる
- 独立した複数のタスクを、別々のコンテキストで並列に処理したい
- 単一エージェントだとツール選びに迷う、または指示同士が矛盾する
ポイントは、「担当業務の種類」を基準として分けないという部分。「調査だから調査担当」ではなく、「文脈が独立しているか」「並列にしたいか」「実測で性能が落ちるか」で判断する。
残す場合も、独立した作業を任せて結果だけ返してもらう形にする。ユーザーとの対話は原則メインが担う。
ただ、統合すれば何でも良くなるわけではない。記事では、サポート対応のAIでサブエージェントを1つ統合したら、速くはなったものの、触っていないはずの部分が壊れた例が紹介されている。それまでは配送日の確認をきちんと担当のサブエージェントに回していたのに、統合後はそれをしなくなったそうだ。
つまり、1か所を変えただけで、別のところの動きまで変わってしまうことがある。
Xでサブエージェントはオワコンみたいな煽り方をしているインフルエンサーいるけど、全部インプレッション稼ぎなので注意を。
具体的な実践方法
ここからは、個人ユーザーがClaudeCodeでどう取り入れるかを紹介していく。
結論、僕のおすすめは「個人ユーザーは無理してサブエージェントを作らなくていい」だ。
理由はシンプルで、基本はメインエージェント1つの単一ループで解決するから。そして、詰まったところだけSkillsで対策すればいい。
異論は認めるけど、非エンジニアの用途でサブエージェントを大規模に構築するのはいらないんじゃないかなというのが僕のポジションになる。
サブエージェントは処理が長く、追いづらい
サブエージェントを使うと、やたら処理が長くなる。引き継ぎのたびにAIの呼び出しが増えるからだ。
さらに、挙動が複雑になって追うのが難しくなる。どのAIが何を受け取って、どこで情報が抜けたのか。結果がいまいちだったときに、原因を探すのがめちゃくちゃ大変だ。
一方で、単一ループなら全部が1つの会話に残る。何を考えて、何をしたのかをそのまま追える。
詰まったところはSkillsで対策する
単一ループで回していると、「この作業だけいつも上手くいかない」という箇所が出てくる。そこだけSkillを作ればいい。
たとえば調査のやり方が毎回ブレるなら、researcher というサブエージェントを作るのではなく、「調査の手順」をSkillとして書いておく。メインのAIは必要なときにそのSkillを読み込んで、同じ会話の中で作業を進める。
こうすると、調査で見つけた細かい情報をその後の作業にそのまま活かせる。サブエージェント経由だと要約しか返ってこないので、ここが一番の差だと思う。
最初からSkillsを作り込む必要もない。詰まったら足す、くらいで十分だ。
ナレッジはNotionに持たせる
ナレッジ（参照資料や事業の情報）は、Notionに持たせておくのが便利だ。
というのも、Notionに置いておけばスマホからもPCからもアクセスできるから。ローカルのファイルだと、PCの前にいないと見れない。
ClaudeCodeからは、Notion MCPでつないで参照させる。
注意点として、CLAUDE.mdにNotionのURLを書くだけでは足りない。URLは場所を示すだけで、非公開ページへのアクセス権は付与されないからだ。
接続は、Claudeのデスクトップアプリからやるのが一番簡単だ。ターミナルでコマンドを打つ必要もない。
- デスクトップアプリのCodeタブでセッションを開き、入力欄の横にある「＋」をクリックする
- 「Add connectors」を選び、一覧からNotionを選んで認証する
- 「Notionから○○を検索して要点を教えて」と頼んで、つながっているか確認する
CLAUDE.mdに、どのページをどんなときに参照するかを書く
つないだコネクタは、デスクトップアプリの「Settings > Connectors」から管理・解除できる。
ターミナル派の人は、次のコマンドでも登録できる（登録後にClaudeCodeで /mcp を実行して認証する）。
claude mcp add --transport http --scope user notion https://mcp.notion.com/mcpCLAUDE.mdには、こんな感じで最小限だけ書いておけばいい。
# 業務ルール
- 事業や案件の一次情報源はNotionとする。
- 案件について作業するときはNotion MCPで該当ページと必要な子ページを検索・取得する。
- Notionで確認した事実と、AIによる提案・推測を分ける。
- Notionの更新・削除・共有は事前に確認する。
## 参照先
- Claude Code運用ノート：（NotionページのURL）Notionの中身を全部ローカルにコピーする必要はない。案件名で検索して、関連ページだけ取ってくる運用で十分だ。
ただ、つないだからといって毎回必ずNotionを見てくれるとは限らない。大事な作業なら「最初にNotionの最新情報を確認して」と明示しておくのが確実だ。
サブエージェントを足すのはこんなとき
サブエージェントは、実際に必要になってから足せば十分。目安は記事の3条件そのままで、個人だとこんな場面になると思う。
- 大量のファイルやWebページを調べさせて、メインの会話を散らかしたくないとき
- 独立した作業を同時に進めたいとき
- 作業の一部だけ、使えるツールを絞りたいとき
ただ、最初の2つは、ClaudeCodeに最初から組み込まれているサブエージェントで足りることも多い。自分で専用のサブエージェントを作るのは、その後でいい。
まとめ -サブエージェントは「足す」ものになった-
最後に、今回の内容を振り返っておく。
- 公式は「サブエージェントを増やす前に、まずメインエージェント1つ＋Skills・Toolsを検討する」という方針
- 個人ユーザーは、無理してサブエージェントを作らなくていい。基本は単一ループで解決する
- 詰まったところはSkillsで対策し、ナレッジはNotionに持たせる
- サブエージェントは無くならない。必要になったときに足せばいい
正直、サブエージェントを使いこなすのってガチ勢っぽい。AIが組織立って動いている感じもあって、めちゃくちゃドーパミンが出る。僕もそれでハマっていた。
ただ、個人的にはあまり本質じゃない気がしている。大事なのは仕組みの格好良さじゃなくて、アウトプットが良くなるかどうかだと思う。
ClaudeCodeの運用を見直すきっかけになれば嬉しい。
出典：
- Anthropic「Building agents: When to fold subagents into your main agent loop」（2026年10月22日公開、2026年10月25日時点で確認）
- Claude Code公式：サブエージェント（2026年10月25日時点）
- Claude Code公式：MCP（2026年10月25日時点）
- Notion公式：Notion MCPをClaude Codeに接続
