この記事の結論と対象読者
本業の傍らで発信や事業を1人で回している方に向けて、Claude Codeのサブエージェントを複数組み合わせ、調査・下書き・検品を連携させる組織設計の手順をまとめました。結論として、組織化のカギは人格作りではなく、descriptionの書き分けと呼び出し連鎖の設計にあります。この記事だけで最小構成から複数体の連携、安全な運用まで完了できるように書きました。
サブエージェントで何ができて何ができないか
サブエージェントとは、自分専用の文脈（コンテキストウィンドウ）で作業し、要約だけを本体の会話に返す専門のAIです。検索結果やログの中身を本体の会話に流し込まずに済むため、長時間の作業でも文脈が圧迫されにくくなります。サブエージェントの定義はYAMLフロントマター付きのMarkdownで、プロジェクト用は.claude/agents/、全プロジェクト用は~/.claude/agents/に置きます。
組み込みのサブエージェントにはExplore（読み取り専用のコード検索）、Plan（Plan mode中の調査）、general-purpose（調査と変更の両方）があります。Claudeは各サブエージェントのdescriptionを見て任せるかどうかを判断します。名前を文章で書けば任せるかはClaudeが決め、@でメンションすればそのサブエージェントが確実に動きます。以前あった/agentsの作成ウィザードは廃止されているため、Claudeに作ってもらうか、ファイルを直接書くことになります。
1人で複数の役割を兼ねている副業・ひとり起業の読者にとって、サブエージェントは「自分の代わりに下調べや検品だけを黙々とやってくれる担当」という位置づけが実態に近い理解です。人格を持った組織図を再現する機能ではなく、あくまで文脈を分離するための仕組みとして捉えると失敗しません。
判断基準:サブエージェントを使うべきかCLAUDE.mdやスキルで足りるか
すべての作業をサブエージェント化する必要はありません。まず、どの手段を選ぶかを整理します。
| 場面 | 適した手段 | 理由 |
|---|---|---|
| 毎回同じ手順を繰り返すだけ | スキル(Skills) | 呼ばれたときだけ読み込まれ、文脈を圧迫しない |
| プロジェクト共通のルールを常に守らせたい | CLAUDE.md(Memory) | 毎回の会話開始時に自動で読み込まれる |
| 大きな変更の前に計画だけ立てさせたい | Plan mode(Permission modes) | 承認するまでファイルを編集しないため、実行前に方向性を合意できる |
| 長い調査やログ確認を本体の会話から切り離したい | サブエージェント(Sub-agents) | 自分専用の文脈で作業し、要約だけを返すため本体の文脈を消費しない |
この上で、サブエージェントに任せるかどうかは次の基準で振り分けます。
- 出力が長くなる調査やログ確認は任せる(本体の文脈を消費しないため)
- 最終判断が必要な作業は任せない(承認は自分が行う)
- 同時に動かす本数は多くても3〜4本程度に抑える(管理できる範囲に留める)
- 繰り返し使う手順はスキル化してから、そのスキルをサブエージェントに呼ばせる
再現手順:役割を分けた複数サブエージェントを組み立てる
組織として機能させるには、1本ずつ役割の異なるファイルを作り、descriptionで得意分野を書き分けることが要になります。副業のブログ運用を例にした手順です。
- プロジェクト直下に
.claude/agents/フォルダを作成します - 役割ごとにファイルを分けます。例として
researcher.md(調査専門)、draft-writer.md(下書き専門)、quality-checker.md(検品専門)の3本を作ります - それぞれのフロントマターの
descriptionに「いつ呼ばれるべきか」を具体的に書きます。descriptionが曖昧だと、Claudeが自動で任せる判断を誤りやすくなります - 呼び出し連鎖は、本体の会話の指示文で「researcherの結果をdraft-writerに渡し、その結果をquality-checkerに渡す」という順序を明示します。サブエージェント同士が直接呼び合う機能ではなく、本体の会話が仲介役になる点を踏まえて指示を書きます
- 返ってきた要約だけを見て、必要な部分だけ本体の作業に反映します
3本のサブエージェントのファイル例です。descriptionの書き分けに注目してください。
---
name: researcher
description: 競合記事や外部情報を読み取り専用で調査するときに使う。下書きや検品は行わない
---
# 手順
1. 指定されたURLまたはキーワードで情報を確認する
2. 事実と主張を分けて整理する
3. 300字以内で要約し、出典を添えて返す
---
name: draft-writer
description: researcherが集めた要約をもとに下書きの文章を作るときに使う。事実確認や検品は行わない
---
# 手順
1. 渡された要約をもとに指定の文字数で下書きを作る
2. 出典が必要な主張には出典を残す
3. 完成した下書きをそのまま返す
---
name: quality-checker
description: draft-writerが作った下書きを検品するときに使う。新しい文章の作成や調査は行わない
---
# 手順
1. 誇大表現(必見・保証・断定的な成果表現)がないかを確認する
2. 事実として書かれている内容に出典があるかを確認する
3. 見出しが体言止めになっているかを確認する
4. 指摘事項を箇条書きで返す
貼ってそのまま使える、3本を連携させる指示文の例です。
@researcher で今月のYouTube定点観測フォルダの中身を確認し、
伸びている動画の共通点を箇条書き5個以内で要約してください。
次に、その要約を@draft-writer に渡し、
メルマガの下書きを400字程度で作成してください。
最後に、その下書きを@quality-checker に渡し、
誇大表現の有無・事実確認・見出しの体言止めをチェックしてもらってください。
この流れであれば、調査→下書き→検品という役割分担を、本体の会話が仲介する形で1人でも再現できます。ただし最終的な公開判断は自分で行う前提を崩さないようにします。
この図は、調査担当から下書き担当、検品担当へと作業がどの順序で渡っていくかを軸に示しています。矢印の向きに沿って、researcher→draft-writer→quality-checker→自分の承認という順番で作業が進む流れを確認し、次に自分のプロジェクトではどの工程を分割できるかを書き出してみてください。
具体例:descriptionの書き分けで自動委任の精度を上げる
descriptionを「〇〇をする担当」とだけ書くと、似た役割のサブエージェントが複数あるときにClaudeがどれに任せるか迷いやすくなります。「いつ使うか」と「何をしないか」の両方を書くと、自動委任の判断が安定します。
例えば検品担当のdescriptionを「文章をチェックする」とだけ書くより、「draft-writerが作った下書きを検品するときに使う。新しい文章の作成や調査は行わない」と書いたほうが、調査依頼を誤って検品担当に渡してしまう事態を防げます。この書き方は、複数本のサブエージェントを組織として運用し始めてから特に効いてくる工夫です。
失敗例と対策
- 失敗例:サブエージェントを5本以上同時に動かして、どれが何をしているか分からなくなった
- 対策:同時に動かすのは3〜4本までに抑え、
/contextで文脈の使用量を確認しながら進めます
- 対策:同時に動かすのは3〜4本までに抑え、
- 失敗例:検品役に具体的な基準を渡さず「いい感じにチェックして」と指示し、精度がばらついた
- 対策:禁止事項と完了条件を数値や具体的な条件で書き、曖昧な指示を避けます
- 失敗例:サブエージェントがBashコマンドでファイルを変更した後、その変更を巻き戻したくなった
- 対策:チェックポイントの巻き戻しは、Bashコマンドで変更したファイルには効きません。サブエージェントに直接ファイルを変更させる作業は、事前にバックアップを取るか、変更後に自分の目で差分を確認してから次へ進みます
- 失敗例:外部情報を読み込むMCPサーバーの出力をそのままサブエージェントの調査結果として信用した
- 対策:MCPは外部の内容を取り込むサーバーにプロンプトインジェクションの危険があるため、信頼できるサーバーだけをつなぎ、出力が10,000トークンを超えて警告が出た場合は内容を絞って渡し直します
- 失敗例:サブエージェントに任せた後、途中経過を確認せずに公開まで進めてしまった
- 対策:検品担当を通した後も、最終的な表示や内容は自分の目で確認してから公開します
初心者向け最小構成
いきなり複数のサブエージェントを作る必要はありません。最初は以下の1本だけで十分です。
.claude/agents/checker.mdを1つだけ作り、記事や台本の誤字脱字と事実確認だけを任せる- 本体の会話では、書いた文章を渡して「@checkerでチェックして」と呼ぶだけにする
- 慣れてきたら、調査用のサブエージェントを1本追加する
この最小構成であれば、.claude/agents/フォルダとMarkdownファイル1つだけで始められます。
中上級者向け応用:CLAUDE.mdとスキルとの併用
サブエージェントを増やしていくと、共通のルールを毎回書き直す手間が出てきます。ここで役立つのがCLAUDE.mdです。CLAUDE.mdはプロジェクト直下の./CLAUDE.mdか./.claude/CLAUDE.mdに置くと、毎回の会話の開始時に自動で読み込まれます。1ファイル200行未満を目安にし、同じミスが2回起きたら追記するという運用が公式にも案内されています。
さらに、繰り返し使う手順はスキルとしてSKILL.mdに切り出すと、呼ばれたときだけ読み込まれるため文脈を圧迫しません。サブエージェントの手順の中身をスキル化しておけば、複数のサブエージェントから同じスキルを呼び出す形にでき、手順の重複を防げます。以下はスキルの記述例です。
---
name: sns-draft-review
description: SNS投稿の下書きを検品し、誇大表現と事実確認の抜けを指摘する
---
# 手順
1. 誇大表現(必見・保証・断定的な成果表現)がないか確認する
2. 事実として書かれている内容に出典があるか確認する
3. 指摘事項を箇条書きで返す
複数のサブエージェントとスキルを組み合わせるようになったら、どこで会話を整理するかも判断基準になります。会話が長くなり文脈が圧迫されてきたら/compactで要約し、別の作業に移るなら/clearで新しい会話を始めます。直前の会話は/resumeで戻せるため、/clearを使うことにためらいは不要です。
この図は、作業の場面ごとにどの整理コマンドを選ぶべきかを軸にした分岐を示しています。今の作業が「同じテーマの続き」か「まったく別の作業」かを自分に問いかけ、矢印の先に書かれたコマンドをそのまま次の一手として打ち込んでみてください。
一般的なやり方と運営者の運用の比較
| 項目 | 一般的な手順 | 運営者の運用と理由 |
|---|---|---|
| 役割分担の作り方 | まとめて1つのAIに全工程を依頼する | 調査・下書き・検品をサブエージェントで分担。同時に動かすのは3〜4本までに制限。理由は、担当を分けないと自分がいない間に作業が止まってしまうため |
| ルールの置き場所 | 毎回チャットで同じ指示を書き直す | 再発した指摘はCLAUDE.mdへ昇格させ、頻度の高い手順はスキル化。61本のスキルを作り、コンテンツ販売系と台本系で名前の付け方を分けて管理している |
| 定期作業の頻度確認 | 「毎日」「週1」など感覚で運用する | 定期タスクの実行一覧で実測を確認してから頻度を決めている。過去に台本で話していた頻度が実測とずれていたため、2026年9月7日時点の実行一覧で確認した値だけを使う |
実践で分かったこと
運用の中で具体的に効果があった工程を2つ紹介します。
1つ目は、定期タスクの頻度を実測で決め直したことです。以前は台本の中で「毎日」「週1」と話していた頻度が、実際の実行一覧と食い違っていました。そこで2026年9月7日に実行一覧を確認し、週1コーチングの録画文字起こしは毎週月曜7:30に取り込み、YouTubeの伸びている動画の定点観測は3日に1回9:00、外部動画冒頭のリサーチは毎月1日と15日の11:00、月1のFAQ更新は毎月1日13:00のリマインドで人が実行、という形に固定しました。感覚ではなく実測値で頻度を管理したことで、実際には動いていない定期タスクを「動いている前提」で放置するミスを防げています。副業で本業と並行して運用する場合、この確認作業を怠ると「自動化したつもり」の穴が生まれやすいため、実行一覧の確認は定期的に行う価値があります。
2つ目は、競合リサーチをサブエージェントに任せる際の基準を数値で固定したことです。YouTube Data APIで動画を集める際、「再生数が登録者数の3倍以上・投稿から90日以内・5分超・5,000再生以上」を満たすものだけを伸びている動画として扱うという条件を決めています。この基準をサブエージェントへの指示にそのまま渡すことで、「なんとなく伸びていそうな動画」を毎回目視で選び直す手間を防げています。数値基準を持たずにAIへ調査を任せると、担当者や依頼のたびに基準がぶれてしまうため、副業のように時間が限られる運用ほど、最初に数値の判断基準を決めておく効果が大きいと感じています。
FAQ
Q. サブエージェントとスキルはどう使い分ければいいですか。
A. スキルは「手順」を呼び出す仕組み、サブエージェントは「文脈を分離した担当」を呼び出す仕組みです。繰り返す作業手順はスキルにまとめ、そのスキルを使う担当をサブエージェントとして分離する組み合わせが扱いやすいです。
Q. 複数のサブエージェントを連携させるとき、descriptionはどこまで具体的に書けばいいですか。
A. 「何をするときに使うか」と「何をしないか」の両方を書くことをおすすめします。似た役割のサブエージェントが複数あるほど、Claudeが自動で任せる判断の精度がdescriptionの具体性に左右されます。
Q. サブエージェントを使うと料金は増えますか。
A. トークンは文脈の大きさに比例するため、使い方次第で増減します。使用量の確認は/usageで今のセッション分を確認でき、Pro・Maxなどのサブスクでは使用量はプランに含まれる形で画面に表示されます。
Q. サブエージェントを削除したり編集したりするにはどうすればいいですか。
A. .claude/agents/または~/.claude/agents/にあるMarkdownファイルを直接編集・削除します。専用のウィザードは廃止されているため、ファイル操作かClaudeへの依頼で対応します。
Q. 1人で複数のサブエージェントを管理しきれるか不安です。
A. 最初から複数本を並行させる必要はありません。まずは検品担当1本から始め、慣れてから増やす進め方であれば、副業で本業と並行していても無理なく運用できます。
まとめ
サブエージェントの組織化は、人格を作り込むことではなく、descriptionの書き分けと呼び出し連鎖の設計で成り立ちます。最初は検品担当1本の最小構成から始め、慣れてきたら調査・下書き・検品の3本にdescriptionを書き分けて連携させ、CLAUDE.mdとスキルを組み合わせて繰り返す手順を積み上げていく進め方が無理のない流れです。数値の判断基準を決めてから任せることと、定期作業の頻度は実測で確認することの2点は、運用を続ける中で特に効果を感じた部分です。
より具体的な手順書やテンプレートをまとめて確認したい方は、公式LINEで「Claude Code×ひとり起業 10大キット」を無料で受け取れます。この記事で紹介したサブエージェントの組織設計を、自分の作業に落とし込む次の一歩としてご活用ください。
公式LINEで「Claude Code×ひとり起業 10大キット」を無料で受け取る
コメント