「Claude Code サブエージェント」で1人10役 ─ 非エンジニアでもできる AI 分業設計

2026年4月22日

「ちょっと聞いてみたい」だけでもOK！ ツールや業務効率化についての相談をすべて1対1で丁寧にお答えします。まずはお気軽にメッセージをどうぞ！LINE公式アカウントはこちら！

「Claude Code」に調査も執筆も SEO も議事録も全部任せているうちに、途中で話が逸れる・さっき調べたことを忘れる・似たファイルを何度も読み直す──そんな場面に心当たりはありませんか。会話ログが肥大化していくと、返答の精度が落ちる一方で、月末のトークン請求だけがじわじわ増えていくという状態に陥りがちです。

● 1つのチャットに作業を詰め込みすぎて途中で迷子になる
● 「この話、さっきもしたよね？」が頻発する
● 請求額だけがじわじわ増えていく

本記事では、「Claude Code」の「サブエージェント（Subagent）」機能で AI を分業させる方法を、1人で記事執筆・講師業・塾運営を回しているある個人事業主の実運用（4役体制）を取材した結果をもとに解説します。写経するだけで、今日から1人4役が立ち上がる構成にしています。公式のヒューリスティクス、最小 YAML テンプレ、並列呼び出しの指示文例、セキュリティ注意点まで全部入りです。

1つの AI に全部任せると、作業は必ずどこかで壊れる

「Claude Code」を1つのチャットで使い続けると、あるタイミングから急に賢さが落ちた感覚に襲われます。原因の多くは「コンテキスト汚染」です。調査で読んだファイル・検索結果・会話履歴が会話の器に積み上がり続け、重要な指示が前後の情報に埋もれて見えなくなるのです。

典型的な症状は3つあります。1つ目はファイル数が20を超えたあたりから返答が揺らぎ始めること。2つ目はさっき調べたはずの内容を、毎回ゼロから調べ直していること。3つ目は請求額だけが伸びる一方で成果物の質は伸びないこと。どれも「1つの AI に仕事を詰め込みすぎたサイン」です。

別チャットを開いて「続き」を始めるのは対処療法にすぎません。根本解決は「役割を分ける」こと。そこで登場するのが、本記事の主役である「サブエージェント」です。

サブエージェントとは ─ 公式の定義を1分で押さえる

「サブエージェント」とは、独立したコンテキスト・ツール・モデルを持つ AI の分身のことです。~/.claude/agents/（ユーザー全体）または .claude/agents/（プロジェクト単位）にマークダウンファイルで定義すると、メインの「Claude Code」から呼び出せるようになります（公式日本語ドキュメント code.claude.com/docs/ja/sub-agents）。

分業で得られる価値は3つあります。

分業で得られるもの	何が変わるか
コンテキストを分ける	メインチャットに調査の生データが流入しない。返された結論だけが戻る
ツールを絞る	触れるツールを役割ごとに制限できる（事故防止・最小権限の原則）
モデルを選べる	軽い調査は Haiku、執筆は Sonnet、設計は Opus と使い分け（コスト最適化）

Anthropic は公式ドキュメントで「いつサブエージェントを使うべきか」のヒューリスティクスを提示しています。10ファイル以上を読む必要がある調査タスク、あるいは3つ以上の独立した作業が含まれるときは、サブエージェントに委譲する価値があるという目安です。この2つに当てはまらない軽いタスクは、メインの「Claude Code」にそのまま任せて構いません。

組み込みで最初から使えるサブエージェントも3種類あります。

組み込みサブエージェント	用途	特徴	最初に触るならこう使う
Explore	並列で広く調査	複数ファイル・Webを横断して読む	「このリポジトリの認証周りをExplore で調べて」
Plan	実装前の設計レビュー	手を動かす前に一呼吸置ける	「Plan で、この機能追加の設計を先に出して」
general-purpose	汎用・お試し	定義不要で呼べる	「general-purpose で、まず1回回してみて」

SKILL.md と同じく YAML フロントマターで設定しますが、サブエージェントには独自のフィールドがいくつかあります。

フィールド	意味	例
`name`	サブエージェント名（必須）	`wiggins`
`description`	いつ呼ばれるべきかを1〜2文で（必須）。自動委譲の判断に使われる	情報収集・機械的処理のスペシャリスト
`tools`	使えるツールを絞る（省略時は全継承）	`Read, Grep, WebSearch`
`model`	モデル指定（inherit／haiku／sonnet／opus）	`haiku`
`isolation`	ワークツリー分離（`worktree` 指定時は独立コピーで作業）	`worktree`

なお、「Claude Code 2.1.63」で従来の Task tool が Agent tool に改名されました。古い記事の「Task tool」と現在の「Agent tool」は同じ機能を指していると読み替えれば問題ありません。2026年4月時点でも、バックグラウンドサブエージェントの進捗レポート修正などが継続的に入っており、機能は活発に改善されています。

ある個人事業主の「4役 AI チーム」をそのまま公開する

本記事で取材したのは、1人で記事執筆・講師業・個人指導塾運営を回しているある個人事業主です。この事業主は「Claude Code」のサブエージェント機能をフル活用して、4役の AI チームで運用していました。ペルソナ名はシャーロック・ホームズのキャラクターからとっているとのこと。そのまま真似できるよう、役割・ツール・モデル・起動場所を一覧で開示します。

ペルソナ	役割	主な使用ツール	モデル	起動場所
Holmes（ホームズ）	調査・執筆の中心	Read／Write／Edit／Grep／WebSearch	Opus	メイン Vault（Claude Code デフォルト）
Moriarty（モリアーティ）	企画・設計・SEO・マーケ	Gemini 連携／競合分析	Gemini 2.x	`moriarty-workspace`
Wiggins（ウィギンズ）	情報収集・機械的処理	Grep／Glob／Bash／WebSearch（Edit は外す）	Haiku／Sonnet	Agent tool から呼び出し／`wiggins-workspace`
Watson（ワトソン）	Discord 窓口・人間との対話	Discord MCP／transcribe 系	Sonnet	`watson-workspace`（常駐 bot）

この表は、取材先の CLAUDE.md と AGENTS.md に書かれた「ツール分担」を許可を得てそのまま開示したものです。根拠が明示されているので、読者はこの構成をコピーして自分の環境にも落とせます。

4役にした理由は次のとおりです。

役	分離の理由
Holmes	実行の責任者を1人決めないと指示が迷子になる。どの役にも属さない中間タスクが発生した時の引き受け役
Moriarty	企画と SEO は思考の種類が違う（探索 vs 戦略）。メインを汚染させないために別モデル（Gemini）で分離
Wiggins	情報収集を分離するとメインのコンテキストが肥大化しない。Haiku で高速・安価に回せる
Watson	人間との対話窓口を専任化すると、他の役が作業に呼び戻されず集中できる

それぞれの最小 YAML をすべて公開します。.claude/agents/〜.md に貼って保存するだけで使える形です。

指示文例①（Holmes 定義・コピペ可）：

			
# ~/.claude/agents/holmes.md
---
name: holmes
description: 調査と執筆の責任者。ファイル読み書き・記事生成を中心に担う。判断が必要なタスクはまずこの役へ。
tools: Read, Write, Edit, Grep, Glob, WebSearch, WebFetch
model: inherit
---
あなたはホームズ。調査と執筆の責任者です。事実と推測を混同せず、根拠のある結論のみ返してください。情報収集は Wiggins に委ねる判断もしてください。

		

指示文例②（Wiggins 定義・コピペ可）：

			
# ~/.claude/agents/wiggins.md
---
name: wiggins
description: 情報収集・機械的処理のスペシャリスト。ファイル列挙・Grep・Web調査の初動を担う。本文の書き換えや解釈には踏み込まない。
tools: Read, Grep, Glob, Bash, WebSearch, WebFetch
model: haiku
---
あなたはウィギンズです。依頼された情報の「所在と概要」だけを返します。本文の解釈・執筆には踏み込みません。不明点は推測せず「不明」と返してください。

		

指示文例③（Moriarty 定義・コピペ可）：

			
# ~/.claude/agents/moriarty.md
---
name: moriarty
description: 企画・設計・SEO戦略の専門家。カニバリチェック・ブリーフ作成・構成案設計を担う。執筆本体には入らない。
tools: Read, Grep, Glob, WebSearch, WebFetch
model: inherit
---
あなたはモリアーティ。思考の焦点はマーケットの空白を探し、戦略的に埋めに行くことです。実装・執筆には踏み込まず、戦略ドキュメントのみ返してください。

		

Wiggins には Edit や Write を意図的に外してある点に注目してください。情報収集役が誤って本文を書き換える事故を防ぐための設計です。tools: を絞ることは「最小権限の原則」そのもので、AI 運用でも事故率を下げる最重要原則になります。

ふきだし（取材先の運用例）： 「調査は Wiggins に投げてください。Moriarty の企画書は明日読みます」——Holmes がこう言える状態を作ることが、4役体制のゴールだそうです。

`/agents` と Agent tool ─ 並列で動かす最小入門

サブエージェントを動かす手順はたった3ステップです。

ステップ	やること	コマンド／操作
① 定義	サブエージェントを作る	チャットで `/agents` を実行（対話UIが起動）／または手書きで `.md` を置く
② 確認	認識されているか確かめる	`/agents` で一覧表示。各エージェントの `description` が正しく表示されるか確認
③ 呼び出し	並列または委譲で走らせる	自然言語で指示。「3体並列で」「Wiggins で調べて」等

/agents は対話 UI になっていて、名前・description・使うツール・モデルを順番に聞いてきます。迷ったら description は動詞＋目的語で具体的に書くのがコツです。「調査をする」ではなく「情報収集・ファイル列挙・Web 調査の初動を担う」と書くと、メインの Claude が自動委譲の判断を正しく下せます。

サブエージェントの呼び出し方は、大きく分けて並列と委譲の2パターンあります。

呼び出し方	どんなとき	指示の書き方
並列	独立した複数タスクを同時進行	「3体並列で」と明示。1体ごとに担当範囲を指定
委譲	1つの重い作業を別コンテキストに出す	「Wiggins サブエージェントで〜してください」

並列で呼び出す最大のメリットは速度です。公開されているベンチ事例では、53回のツール呼び出しが約2分で並列完了したという報告があります（DevelopersIO「Claude Code の並列エージェント機能を試してみた」）。結果だけがメインコンテキストに返るので、会話ログが肥大化しない点も実務的な価値です。

指示文例④（並列呼び出し・コピペ可）： 「Wiggins サブエージェントを3体、並列で動かしてください。1体目は『Claude Code subagent』の SERP 上位5本の要点、2体目は『AIエージェント分業』の SERP 上位5本の要点、3体目は Anthropic 公式ドキュメントの sub-agents と agent-teams の差分。それぞれ400字以内で要約して返してください」

指示文例⑤（委譲・コピペ可）： 「Wiggins サブエージェントで、docs/ 配下から『顧客面談』を含むファイルを列挙し、日付と顧客名の一覧表だけ返してください。本文は読み込まず、ファイル名と1行目だけ確認してください」

並列のスケール感も確認しておきましょう。note の検証記事では、4並列から10並列まで段階的に拡張して100タスクを完走した事例が公開されており、並列度を明示しすぎない方が Claude 側の最適化が効いて効率的という知見もあります。ただし現状の並列上限は10でキュー制御はできないため、それ以上の同時実行は素直にバッチ分けするのが安全です。

出典	数値	何を示すか
DevelopersIO「並列エージェント機能」	53回のツール呼び出しが約2分で完了	体感の速さ
note（genaird 氏）	4並列→10並列へ段階的拡張、100タスク完走	スケール上限の目安
Qiita（nogataka 氏）	3役のトークン配分 10:35:55	役割ごとのコスト感
公式（agent-teams）	並列上限10・キュー制御不可	制約の注意喚起

よくある失敗3つと、回避する `description` の書き方

「サブエージェントを導入したら生産性が3倍」という景気のいい話の裏には、導入につまずいたケースも同数あるのが現実です。公開されている失敗談から、典型的な3つを表にまとめました。

失敗	何が起きるか	対処
役を増やしすぎる	Qiita事例では5分割でコスト爆発。役が多いほどトークン請求がかさむ	まず3〜4役。Wiggins のような情報収集の分離だけでも効果大
`description` が曖昧	自動委譲されず、結局メインがやる	「いつ呼ばれるべきか」を `description` に1文で書く
全ツールを継承させる	誤って Edit でファイルが書き換わる事故が起きる	`tools:` を絞る。`bypassPermissions` は使わない

2つ目の「description が曖昧」は、実は自動委譲が発火しない一番の原因です。書き方の Before／After を並べると違いが明確になります。

Before（曖昧）	After（具体）
「調査を手伝います」	「ファイル列挙・Grep・Web調査の初動を担当。10ファイル以上を読むタスクで呼ばれるべき」
「SEO の相談に乗ります」	「SERP 上位10本のタイトル・見出し比較と空白分析を担当。記事執筆前のカニバリチェックで呼ばれるべき」
「コードを書きます」	「テストコード生成とリファクタリングを担当。新機能追加ではなく既存コード整理で呼ばれるべき」

「何ができるか」ではなく「いつ呼ばれるべきか」を書く──これが自動委譲を効かせる一番のコツです。

3つ目の「全ツール継承」は事故の温床です。tools: を省略すると、サブエージェントはメインと同じ全ツールを使えるようになり、情報収集役が間違えて本文を上書きするといった事故につながります。bypassPermissions を有効にするのも同様に危険で、取材先でも意図的に一度も使わない運用を貫いていました。

段階論で考えると、Explore を1回使う → 自作1体（Wiggins 相当） → 2体連携 → 4体体制の4ステップが現実的です。いきなり最終形を目指さず、「情報収集の分離だけ」で1ヶ月運用してから次の役を足すくらいの速度がちょうど良い、というのが取材先の実感でした。

1人で10役回すのではなく、10体を1人が指揮する

AI 活用のゴールは、「作業者」を辞めて「指揮者」に立ち位置を変えることです。1人で10役を回そうとするから疲弊するのであって、10体の AI を1人が指揮する方向に転換すれば、同じ時間で倍の仕事が回ります。今回取材した個人事業主も、Holmes に全部任せていた時期から、Moriarty・Wiggins・Watson を分離した4役体制へと段階的に移行してきたのだそうです。

分業設計の本質は技術ではなく「何を分けるか」の判断にあります。サブエージェントはそれを技術的に支える道具にすぎません。どの作業を、どの役に、どのタイミングで渡すか──この判断こそが、非エンジニアでもできる AI 分業設計の核心です。

この記事が、あなたの AI 運用を一段階引き上げるきっかけになれば幸いです。

AI は1人に10役やらせる道具ではなく、10体を1人が指揮する仕組みです。今日から役を分けてみませんか。