サブエージェント（公式の用語では subagent）に任せると、何が守れて何が壊れるか
Claude Code には、仕事の一部を別のエージェントに任せる機能があります。サブエージェント（公式の用語では subagent）です。
私は一人会社を Claude で運用していて、ほぼ毎日サブエージェントを使っています。使い方は3つです。
調べものを任せる
いくつも同時に走らせる
書いたものを、書いた者とは別の者に確かめさせる
便利な反面、並列で走らせて壊れかけたこともありました。なので公式の資料が何と書いているかを確かめ、うちの記録と並べました。2026年10月12日に、Claude Code のドキュメント2ページと、Anthropic の記事2本を開いて読んでいます。
公式の説明
Claude Code のドキュメント「Create custom subagents」では、サブエージェントは特定の種類の仕事を受け持つ AI アシスタントだと説明されています。
要点は、それぞれが自分専用の文脈（コンテキストウィンドウ）で動くことです。会話を引き継ぐ fork という例外を除けば、親の会話の履歴も、親がすでに読んだファイルも見えません。親が書いた依頼文から始めて、終わったら要約を返します。
定義は Markdown のファイル1枚です。置き場所は、プロジェクトごとのフォルダと、自分の全プロジェクトで使うフォルダなどに分かれています。
Anthropic の記事「Effective context engineering for AI agents」（2025年9月29日）でも、サブエージェントの構成は文脈の上限への対処の1つとして挙がっています。サブエージェントが数万トークン以上を使って調べても、返すのは凝縮した要約で、多くは1,000〜2,000トークンだと書かれています。
メリット1：調べものを任せると、親の文脈が残る
ドキュメントが特に効く使い方の1つとして挙げているのは、テストの実行やログの処理のような、出力の多い作業を切り離すことです。
うちでは2026年8月31日に、調べものはできるだけサブエージェントに任せる、と決めました。親のセッションが自分で調べると、ファイルの中身や検索結果で文脈が埋まります。親に残したいのは、判断と相談のための余地です。
任せるときは「調査のみ・変更禁止」と書き、返してほしい形も指定します。生のデータを長々と返されると、切り離した意味がなくなるからです。
文脈が埋まったときにセッションごと交代させる話は、別に書いています。
https://note.com/bebsite/n/n9dcf91d1b8e6
メリット2：並列で調べると速い
ドキュメントには、互いに依存しない調べものを、複数のサブエージェントに同時にさせる使い方も載っています。
Anthropic の「How we built our multi-agent research system」（2025年6月13日）は、マルチエージェント（公式の記事では multi-agent system）で調査機能を作った話です。Claude Opus 4 を親、Claude Sonnet 4 をサブエージェントにした構成が、社内の調査用の評価で Opus 4 単体を 90.2% 上回ったと書かれています。
デメリット1：費用が膨らむ
同じ記事には、欠点もはっきり書かれています。Anthropic のデータでは、エージェントはふだんチャットのおよそ4倍、マルチエージェントはおよそ15倍のトークンを使う、という数字です。
なので、仕事の価値が増えた費用に見合うときに使うもの、とされています。コーディングの仕事の多くは、調査ほど本当に並列にできる部分が多くない、とも書かれていました。
ドキュメントにも、サブエージェントの利用は親の会話と同じ利用上限に数えられるとあります。
デメリット2：同じ作業場所を取り合う
うちで実際に起きたのはこちらです。
2026年10月8日、ある下書きを8つに分けて、並列で作らせました。そのうち2つのエージェントが、作業用の一時フォルダにある同じ名前のスクリプトを、互いに上書きしていました。
うちの環境では、サブエージェントは親と同じ一時フォルダを使っていました。「extract」のような一般的な名前は、並列で走る全員が選びがちです。
しかも、上書きされてもエラーは出ません。ファイルはあるので読めます。中身が別物になるだけです。
このときは2つとも自分で気づいて、名前を変えていました。ただ、気づかなければ片方の結果が静かに壊れていたと思います。
それ以来、並列で3つ以上走らせるときは、作業ファイルの名前に担当名を入れるよう依頼文に書いています。出力するファイルも1エージェントに1つにして、ほかのファイルを触らないと明記します。
公式には、サブエージェントに git の worktree（リポジトリの写し）を割り当てて分ける設定があります。ただ、うちの作業ディレクトリは git の管理下に無いので、この設定はそのままは使えません。なので依頼文の決まりで防いでいます。
3つ目の使い方：別の者に確かめさせる
Claude Code のドキュメント「Best practices for Claude Code」には、書き手と確かめ役を分ける型（公式のドキュメントでは Writer/Reviewer pattern）が載っています。新しい文脈なら、書いたばかりのものに引きずられない、という理由です。この型はドキュメントでは別のセッションどうしの例として書かれていて、サブエージェントで同じことをする手順は別の節（公式のドキュメントでは adversarial review step）に載っています。
確かめ方の1つとして、"the agent doing the work isn't the one grading it" とも書かれています。働いたエージェントが自分の採点をしない、という意味です。
うちでも2026年10月12日に使いました。解説記事の1本目を公開する前に、書いた者とは別のサブエージェントに、記事の主張を一次資料と突き合わせさせました。
13件の事実の主張は、すべて一致しました。ただ、結論の1つにしていた「harness の意味が記事によって3通りある」は言い過ぎだと指摘されました。2本の記事は同じものを別の言い方で書いていて、別物は2つだったんですよね。その節は書き直してから公開しています。
この照合役は、ページを読む道具が「印字どおりに書き出して」という依頼を注入と読んで断る場面に当たり、言い方を変えて読み直したうえで、生の HTML でも確かめていました。
その記事は別に書いています。
https://note.com/bebsite/n/nbd46a14a4599
指摘も、そのまま受け入れない
ただ、確かめ役の指摘が正しいとは限りません。
ベストプラクティスのページにも注意書きがあります。穴を探せと頼まれた確かめ役は、作業がまともでもたいてい何か報告してくる。全部を追うと作り込みすぎになる、という内容です。
うちにも逆の例があります。別のセッションから「渡した一覧の436行が列ずれしている」と指摘されました。測り直すと、898行すべて列数はそろっていました。436は、カンマを含むため正しく引用符で囲まれた行の数でした。読み方の違いだったわけです。
指摘をそのまま受けて直すと、壊れていないものを壊します。間違った原因が、次からの決まりとして残ることもあります。なので、指摘も実物で測り直してから受け入れています。
合う使い方
ドキュメントの切り分けに、私の読みを添えます。
出力が多くて、要約だけ返せば済む調べものは、サブエージェントに向いています
やり取りしながら詰める作業や、計画から実装まで同じ前提を使う作業は、親の会話でやるほうが良いとされています
互いに依存しない調べものは並列に。作業ファイルの名前と出力先は、依頼文で分けておくのが良さそうです
書き終えたものは別の者に確かめさせ、指摘は採る前に測り直す
効果は比べられる形で測っていないので、まだ数字では言えません。
この記事に書いた機能と数字は、2026年10月12日に本文を読んで確かめた範囲のものです。機能は版で変わるので、日付を入れています。
この記事の仕組みを、業務に合わせて組むところまでをココナラで引き受けています。
