チーム開発で「Claude Code」を使い倒す 5つの勘所：「AIはただのコード補完」はもう古い 速習・実践「Claude Code」（2）（3/4 ページ）

[高江 賢（著）／監修：山田祥寛（WINGSプロジェクト），＠IT]

3．「1人に任せきりで、会話も品質も安定しない」　抱え込ませず、役割で分ける

　調べ物もレビューも実装も、全て1つの会話に抱えさせると、画面はログで膨らみ、本題を見失います。品質の確認も、コードを書いた本人による自己採点になりがちです。こういうときに役立つのが、サブエージェント（Subagent）です。

調査やレビューはサブエージェントへ切り出す

　サブエージェントは、作業を別のコンテキストへ切り出す仕組みです。手間のかかる調査やレビューを任せ、メインのClaudeは結果の要約だけを受け取ります。こちらが指示しなくても、切り出せる作業だと判断すればClaudeが自分でサブエージェントを起動します。

　別のコンテキストで動くため、元の会話にログや検索結果が流れ込みません。読み取り専用で調査に特化したExplore、計画づくりのPlanなどが用意されています。これとは別に、用途に合わせて自分で定義するカスタムサブエージェントも作成できます。

サブエージェントは別のコンテキストで動き、メインの会話へは結果の要約だけが出力される

生成と検証は別にする

　中でも切り出す価値が大きいのが、検証です。実装したClaude自身にレビューさせると、どうしても甘くなります。コードを書いたときの前提をそのまま引き継ぐので、同じところを見落としやすいのです。

　そこで、確かめる作業をサブエージェントに分けます。実装のいきさつを知らない分、第三者の目で粗を拾うことができます。コード生成と評価を切り離し、フィードバックまで別のエージェントに任せる進め方は、Anthropicも有効な設計の一つとして紹介しています。

　Anthropicの公式ブログの記事「How Anthropic runs large-scale code migrations with Claude Code」では、次のような大規模なコード移行の取り組みが公開されています。

• 2週間足らずで100万行の移行コードを生成した事例
• 実装の分担にSonnetのサブエージェントを12個使った、別プロジェクトの移行事例

　記事で示された工程によると、実装は小さいモデルのエージェントに分担させて、レビューは別のコンテキストを持つ大きいモデルを利用。レビュワーの判断が割れたら、第3のエージェントが判定していたとのこと。

　テストコードは記述された範囲しか検証できないため、Anthropicでは検証専用エージェントを組み合わせた多重チェックに取り組んでいました。実際、100万行のコード移行時にはCIテストを全件パスした状態でも19件の不具合が発生しました。しかし、100万行規模でわずか19件に抑えられた実績は、コード生成と検証のコンテキストを分離する設計の有効性を示しています。

検証専用のカスタムサブエージェントを定義して回す

　検証専用のカスタムサブエージェントは、次のように定義します。

---
name: verifier
description: 実装の検証だけを行う。コードは書き換えない
tools: Read, Grep, Bash
model: sonnet
---
実装を検証する専門のエージェントです。
テストの実行だけで済ませず、依頼や計画と実装を突き合わせて検証します。
仕様の読み違い、境界値や異常系の考慮漏れといった、テストに現れない食い違いも指摘します。
判定はPASS（合格）かNEEDS_REVISION（要修正）の二択。指摘にはファイルと行番号を必ず添えます。
コードの修正や新機能の提案はしません。

［リスト5］検証専用のカスタムサブエージェント例

　ツールは読み取りとテスト実行に絞り、EditやWriteの編集ツールは渡していません。ただし、テスト実行用に残したBashからはファイルを書き換えられるため、これは技術的な強制ではありません。定義の本文で修正しないと宣言させるのも、あくまで約束にとどまります。

　確かめるエージェントが自分でコードを直してしまっては検証にならないので、厳密に禁じたいなら、書き込みを制限した実行環境を使うか、Gitのworktreeで作業領域ごと隔離して、変更がメインの作業場所へ及ばないようにします。

　モデルに指定した「Claude Sonnet」は、上位の「Claude Opus」に次ぐ標準グレードのClaudeモデルです。検証は実装のたびに何度も走らせるものなので、速くて安いモデルが向くという考えです。先ほどのブログ記事でAnthropicはレビューを大きいモデルに任せることを推奨しています。微妙なバグの追跡や設計の判断が必要そうであれば、上位モデルを検討してみてください。

　後は、第1回で紹介したPlan Modeを使ってメインの会話で計画を立て、実装は作る側のサブエージェント、検証は先ほど定義したverifierと役割を決めて回していきます。

　計画・実装・検証がそれぞれ別になり、作って、確かめて、ダメなら差し戻す、という流れが一周します。メインの会話に出力されるのは最終的な判定だけ。途中のログは各サブエージェントのコンテキストに収まります。

　ただし、役割を分けるほど動くエージェントは増え、トークンの消費もかさみます。定型の編集や単発の調査なら、サブエージェントは1つで十分です。検証まで分けるのは、本番の機能追加のように、手戻りの影響が大きいものに絞るのが現実的です。

いまのうちに試しておく、2つの勘所

　残る2つは、エージェント同士を直接組ませる「Agent Teams」と、離席を前提にした非同期の仕組みです。実験段階やプレビュー段階のものが中心ですが、今のうちに試して勝手を知っておく価値があります。

4．「分担しても、担当同士は話せない」　エージェント同士を直接組ませるAgent Teamsを試す

　フロントエンド、バックエンド、テストを同時進行させる際、サブエージェントの分担だけでは、担当間の調整がメインの会話を経由する伝言になります。名前を付けて起動したサブエージェント同士なら短いメッセージを交わせるようになりましたが、誰が何を受け持ち、どこまで終わったかを取りまとめるのは、あくまでメインの会話です。

　実験段階のAgent Teamsでは、複数のClaudeを独立したメンバーとして組ませます。決定的に違うのは、メンバー同士が直接やりとりできる点です。

サブエージェントとAgent Teamsのやりとりの流れ

　サブエージェントがメインの会話から作業を割り振られて結果を返す関係なのに対し、Agent Teamsではメンバーが互いの出力結果を突き合わせ、食い違いをその場で直せます。

　バックエンド担当エージェントがAPIの返却形式を変えたら、フロント担当エージェントが「その形では一覧画面が壊れる」と差し戻し、直した形式に合わせてテスト担当エージェントがテストを更新します。間に立って伝言する役が不要となります。

観点	サブエージェント	Agent Teams（実験段階）
やりとり	結果をメインの会話へ返す（名前付き同士ならメッセージも可）	メンバー同士が直接やりとりできる
取りまとめ	メインの会話が割り振りと集約を担う	共有のタスクリストを軸にメンバーが自分で作業を取る
事前準備	組み込みは準備不要（カスタムは定義が必要）	明示的な有効化が必要
向く場面	調査・レビューや役割分担	フロントエンド・バックエンド・テストの同時並行
コストの目安	タスクごとに起動し、終われば閉じる分、控えめ	メンバーごとに別コンテキストで大きい
サブエージェントとAgent Teamsの違い

　迷ったら、まずサブエージェントで十分です。簡単な作業に、いきなり複数のエージェントを組ませる必要はありません。分担した方が明らかに速い大仕事に出会ったときが、Agent Teamsの使いどきです。

　役割分担とゴールの定義は、現時点では人間の役割です。同じファイルを複数のメンバーが同時に編集すると競合しやすいので、担当ごとに受け持つファイルを分けておくというのも人間の仕事です。

　Agent Teamsを試すこと自体は簡単です。実験段階の機能なので既定では無効ですが、settings.jsonに以下の設定を追加すると有効化されます。

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

［リスト6］Agent Teamsを有効にする設定（settings.jsonの抜粋）

　Agent Teamsを呼び出す場合、特別なコマンドは不要で、次のように普通の言葉で頼むだけで済みます。

> フロント・バック・テストの3人に、frontend・backend・testerと名前を付け、Agent Teamsでチームを組ませて、ToDoアプリの検索機能を分担して実装して

［リスト7］Agent Teamsを試すプロンプト例

　メンバーに名前を付けておくと、あとから個別に呼びかけやすくなります。Agent Teamsと明示しているのは、明示しないとサブエージェントの分担で済ませてしまうことがあるためです。

　本番に乗せるのは急がず、まずはこうした短時間の検証で動きを確かめておきましょう。