0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Claude Codeのサブエージェントを実務で使い倒す — タスク分割・並列実行・親子設計の型

0
Posted at

Claude Codeで大きめのタスクを1セッションで丸ごとやらせると、だいたいこうなります。

  • 途中で前半の決定を忘れる
  • ファイルをまたいだ修正で一貫性が崩れる
  • コンテキストが溢れて精度が落ちる
  • 「結局1ファイルずつ自分で指示し直す」羽目になる

原因はモデルの賢さではなく、1つのコンテキストに全部を詰め込む設計にあります。

これを解決するのがサブエージェントです。タスクを分割して別々のコンテキストで並列に走らせることで、親セッションを軽く保ったまま大きな仕事を片付けられます。

この記事では、サブエージェントを「機能として知っている」状態から「実務で使い倒せる」状態に進めるための、具体的な型を5つ紹介します。すべてコピペして今日から試せます。


そもそもサブエージェントとは

サブエージェントは、親セッションから切り離された独立したコンテキストを持つ別のClaudeです。

親セッション(あなたが話している相手)
 ├─ サブエージェントA(独立コンテキスト)
 ├─ サブエージェントB(独立コンテキスト)
 └─ サブエージェントC(独立コンテキスト)

重要なのは次の2点です。

  1. サブエージェントの作業履歴は親のコンテキストを消費しない — 各サブエージェントは自分のウィンドウで作業し、親には「結果(最終報告)」だけを返す
  2. 複数を並列で走らせられる — 独立タスクなら同時に投げて待ち時間を圧縮できる

つまりサブエージェントは「並列処理」であると同時に、コンテキストの分散投資でもあります。ここを理解しているかどうかで使い方が変わります。


型1: 「調査」と「実装」を必ず分ける

一番効果が出るのに、一番やられていないのがこれです。

大きなタスクの最初には必ず「コードベースを読んで現状を把握する」フェーズがあります。ここで読み込んだファイルの中身は、実装フェーズではほとんど不要です。にもかかわらず、同じセッションで続けると調査時の大量のファイル内容が親コンテキストに残り続けます。

Before(1セッションで全部):

「認証まわりをリファクタリングして。まず src/auth/ 配下を全部読んで、
 現状を把握してから実装して」
→ src/auth/ の全ファイル内容が親コンテキストに居座る
→ 実装に入る頃にはもう半分埋まっている

After(調査をサブエージェントに委任):

「サブエージェントで src/auth/ 配下を調査してください。
 報告してほしいのは次の3点だけ:
  1. 現在の認証方式(JWT / セッション等)
  2. トークンの保存場所と有効期限
  3. リファクタリングで壊れそうな依存箇所のリスト」

サブエージェントは大量のファイルを読みますが、親に返るのは要約された3点だけです。親コンテキストは数十行しか消費しません。その後、この要約をもとに実装を指示します。

ポイント: サブエージェントへの指示には「何を報告してほしいか」を必ず書く。これがないと、サブエージェントは読んだもの全部を長文で返してきて、せっかくの分離効果が薄れます。


型2: 独立タスクは並列で投げる

互いに依存しないタスクは、まとめて並列起動するのが定石です。

「以下の3つを、それぞれ別のサブエージェントで並列実行してください。
 互いに依存はありません。

 1. src/components/UserList.tsx を実装
    (props: users: User[] / クリックで onSelect(id) を呼ぶ)
 2. src/api/users.ts に GET /api/users エンドポイントを追加
    (Prisma で全ユーザー取得、ページネーションは page/limit クエリ)
 3. tests/users.test.ts に上記APIのテストを作成
    (正常系 + page/limit のバリデーション異常系)」

逐次でやれば3タスク分の時間がかかるところを、並列なら最も遅い1タスク分の時間で終わります。

並列にしてはいけないケースもあります。タスク間に依存があるとき(Bの実装結果をCが参照する等)は、並列にすると片方が未完成のまま進んでしまいます。その場合は依存の順に逐次で投げてください。

判断基準はシンプルです。

状況 投げ方
タスク同士が独立(同じファイルを編集しない・出力を参照し合わない) 並列
BがAの成果物を使う 逐次(A完了 → B起動)
同じファイルを複数タスクが編集 逐次(並列だと競合する)

型3: サブエージェントへの指示は「契約」として書く

サブエージェントは親の会話の流れを共有していません。あなたが10往復かけて積み上げた前提を、サブエージェントは何も知らない状態でスタートします。

だから指示は**それ単体で完結する「契約書」**として書く必要があります。最低限、次の4要素を入れてください。

【タスク】 何を作る/調べるか(1行で)
【入力】  読むべきファイル・前提条件
【制約】  守るべきルール・禁止事項
【出力】  何を成果物として返すか(ファイル / 報告形式)

具体例:

【タスク】 src/api/users.ts にユーザー検索エンドポイントを追加
【入力】  既存の src/api/users.ts と prisma/schema.prisma を参照
【制約】
  - Zod で必ずクエリパラメータをバリデーション
  - 内部エラーをそのままレスポンスに出さない
  - 既存のエンドポイントのコードスタイルに合わせる
【出力】
  - 編集後の src/api/users.ts
  - 追加したエンドポイントの仕様を3行で報告

この型を守るだけで、サブエージェントの「勝手な解釈による暴走」が激減します。逆に、雑な一言(「ユーザー検索を追加して」)で投げると、前提を知らないサブエージェントは想像で埋めてしまいます。


型4: 親は「設計と統合」、子は「作業」に役割を固定する

サブエージェントを使い始めると、つい親セッションにも作業をさせたくなります。これがコンテキストを溢れさせる落とし穴です。

役割を明確に分けます。

親セッション(あなたが直接話す)
  └ 役割: タスク分割・指示・成果物のレビュー・統合
     → コードの実装そのものはやらせない

サブエージェント
  └ 役割: 実際のファイル読み込み・実装・テスト作成
     → 重い作業はすべてここに寄せる

親が直接ファイルを大量に読んだり長いコードを書いたりすると、結局親コンテキストが膨らみ、サブエージェント化の意味が薄れます。**「親は司令塔、子が実働」**を徹底するのがコツです。

実務フローにするとこうなります。

1. 親: タスクを3つに分割し、それぞれ契約書を書く
   ↓
2. 親: 3つをサブエージェントに投げる(独立なら並列)
   ↓
3. 子: 各自実装し、要約を親に返す
   ↓
4. 親: 3つの成果物を統合・整合性チェック
   ↓
5. 親: 矛盾があれば該当サブエージェントだけ再実行

型5: サブエージェントの結果は鵜呑みにせず親で検証する

サブエージェントは独立コンテキストで動くぶん、親が把握していない前提のズレを起こすことがあります。

  • AとBが同じ関数名を別の意味で実装してしまう
  • 共通の型定義について、それぞれ別の解釈をする
  • 片方が変更したファイルを、もう片方が古い前提で参照する

これを防ぐには、統合フェーズで親に明示的に検証させます。

「3つのサブエージェントの成果物を統合します。次を確認してください:
 1. 3者間で型定義・関数シグネチャに矛盾がないか
 2. import パスの整合性
 3. 同じ責務が重複実装されていないか
 矛盾があれば、どのサブエージェントを再実行すべきか提案して」

「並列で速い」のメリットは、この検証フェーズを省くと簡単に吹き飛びます。速さと正しさはセットで設計してください。


まとめ: サブエージェント設計の5つの型

要点
1. 調査と実装を分ける 調査はサブエージェントに委任し、要約だけ親に返す
2. 独立タスクは並列 依存がなければ同時起動、依存があれば逐次
3. 指示は契約書 タスク/入力/制約/出力の4要素を必ず書く
4. 親は司令塔・子が実働 親に重い作業をさせない
5. 結果は親で検証 並列の速さを正しさで裏付ける

サブエージェントは「機能を知っている」だけでは効果が出ません。タスクをどう切り、どう契約を書き、どう統合するかという設計があって初めて、親コンテキストを軽く保ったまま大きな仕事を回せます。

ここで挙げた5つの型は、すべて今日のセッションから試せます。まずは「型1: 調査と実装を分ける」だけでも、コンテキストの持ちが体感で変わるはずです。


補足: 試すための無料リポジトリ

この記事のサブエージェント設計を実際のプロジェクトで試すには、土台となるCLAUDE.mdとフォルダ構成があるとスムーズです。私が使っているスターター構成を無料で公開しています。

無料スターター(GitHub):
https://github.com/noguso245-jpg/claude-code-skills-starter

CLAUDE.mdテンプレート・Hooksサンプル・基本のフォルダ構成が入っています。まずはこれを土台に、上の型1から試してみてください。

さらに踏み込んで、サブエージェント分割・並列実行・契約設計などを「実行可能なスキルファイル」としてまとめたパッケージも用意しています。手元で /コマンド として呼び出せる形になっており、毎回プロンプトを書き直す手間が省けます。

まずは無料リポジトリから試して、もっと体系的に使いたくなったら検討してもらえれば十分です。記事の型だけでも効果は出ます。


最新のTipsはXでも発信しています: @k___n___t_1125

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?