AI・テクノロジー

Claude Code サブエージェント活用術——マルチエージェント構成とワークツリー並列実行の実践

anchang info 約1分で読めます
# Claude Code # サブエージェント # マルチエージェント # ワークツリー # 2026

Claude Codeのサブエージェントは、特定の役割に特化したAIを親エージェントから呼び出す仕組みです。役割ごとに指示・ツール権限・コンテキストを分離することで、大規模タスクを安定して回せるようになります。本記事では構成パターンと実運用のコツをまとめます。

結論：サブエージェントは「人間の組織」と同じ設計で使う

  • 1つの大きなタスクを抱え込むより、役割別に分担したほうが精度が上がる
  • コンテキスト汚染を避けられるため、長時間作業でも破綻しにくい
  • ワークツリー分離と組み合わせると並列実行も可能

サブエージェントとは

サブエージェントは .claude/agents/ 配下に Markdown ファイルとして定義します。親エージェント（メインスレッド）から @agent-name の形式で呼び出され、独立したコンテキストでタスクを遂行してから結果を返します。

ディレクトリ構造

.claude/
└── agents/
    ├── explore.md           # 組み込み相当（調査特化）
    ├── plan.md              # 組み込み相当（計画立案）
    ├── code-reviewer.md     # 組み込み相当（レビュー）
    ├── frontend-developer.md # カスタム
    ├── backend-architect.md  # カスタム
    └── reality-checker.md    # カスタム

組み込み系エージェントの活用

Explore：調査・情報収集に専念

既存コードベースの理解、依存関係の把握、ライブラリ仕様の調査などに使います。読み取り権限のみに絞ることで、誤って破壊的操作をしてしまうリスクをゼロにできます。

Plan：実装計画の立案

仕様・既存コード・制約を総合して、実装手順と影響範囲を設計します。/ultraplan と組み合わせると、実装前のレビューが挟めるため手戻りが激減します。

Code Reviewer：PR・差分のレビュー

変更内容に対し「ロジック」「命名」「テスト」「セキュリティ」の観点でレビューコメントを返します。CIに組み込めば、人のレビュー前の1次チェックとして機能します。

カスタムサブエージェントの作成方法

基本テンプレート

---
name: frontend-developer
description: UI/UX実装を担当するフロントエンド開発エージェント
tools:
  - Read
  - Edit
  - Write
  - Bash
  - Grep
  - Glob
---

# Frontend Developer

あなたはフロントエンド実装に特化したエージェントです。

## 責務
- React / Vue コンポーネントの実装
- CSS設計（Tailwind優先）
- アクセシビリティ対応（WAI-ARIA準拠）

## 禁止事項
- バックエンドAPIの仕様変更
- インフラ設定の変更

## 出力
- 実装したファイルの絶対パス
- 変更内容のサマリー
- 動作確認手順

ポイントは以下の3点です。

  1. tools で権限を最小化：調査系ならReadのみ、実装系なら書き込み権限を付与
  2. 責務と禁止事項を明記：役割の越境を防ぐ
  3. 出力フォーマットを指定：親エージェントが結果を処理しやすくなる

実践的なマルチエージェント構成パターン

パターン1：オーケストレーター型（直列）

@orchestrator
  ↓ 呼び出し
@product-manager → @architect → @developer ↔ @qa-reviewer

親（@orchestrator）がフェーズ管理を行い、各段でサブエージェントを呼び出します。developer↔qa-reviewer はループ構造にし、QAがPASSするまで実装をやり直させるのがポイントです。

パターン2：並列調査型

@research-lead
  ├─ @library-researcher（ライブラリ比較）
  ├─ @security-researcher（脆弱性調査）
  └─ @performance-researcher（ベンチマーク）

独立した観点の調査を並列実行し、結果を親エージェントで統合します。各サブエージェントのコンテキストが独立しているため、情報が混ざらず精度が保てる利点があります。

パターン3：専門家パネル型

実装方針を複数の専門家視点でレビューするパターン。セキュリティエンジニア、パフォーマンスエンジニア、DBAなどを並列に呼び出し、コンセンサスを取ります。

ワークツリー分離による並列実行

Gitのワークツリー機能と組み合わせると、複数エージェントが同じリポジトリで衝突せずに並列作業できます。

# タスクごとにワークツリーを作成
git worktree add ../knock-knock-feat-auth feat/auth
git worktree add ../knock-knock-feat-search feat/search

# それぞれのワークツリーで別エージェントを起動
cd ../knock-knock-feat-auth && claude
cd ../knock-knock-feat-search && claude

活用シーン

  • 大規模機能を機能単位で分割実装：認証・検索・通知を並列開発
  • リファクタと新機能を同時進行：mainブランチのリファクタと別ブランチの機能追加を衝突なく進行
  • A/B実装の比較：同じ仕様を異なる方針で2つ実装し、結果を比較

注意点

  • 共有リソース（DB、ポート）の競合に注意：環境変数で分離する
  • 依存インストールがワークツリーごとに必要：node_modules 等は個別に解決
  • マージ戦略を事前に決める：並列作業ほど統合時のコンフリクトが起きやすい

運用のコツ

  • 1エージェント1責務：兼任させない。迷ったら分割する
  • 親エージェントのログを確認する習慣：サブエージェントの挙動は親のコンテキストに要約されて戻るため、ログ記録（.claude/hooks/log-status.sh など）を仕込んでおく
  • プロジェクト横断の共通エージェントは ~/.claude/agents/ へ：個人ユーティリティとして使い回す
  • 頻繁に使うパターンはCLAUDE.mdに起動コマンド例を書く：チームでの再現性を担保

まとめ

サブエージェントは「AIに任せる」から「AIチームを組む」への進化点です。役割分担・権限最小化・並列実行の3つを意識するだけで、作業の規模と安定性が大きく向上します。まずは code-reviewer のようなレビュー系から導入し、徐々にオーケストレーター型に発展させていくのが現実的です。

関連記事