自分がボトルネックにならない開発プロセスを Agent Teams で作る

こんにちは。リテールアプリ共創部マッハチームのきんじょーです。

ここ数年でシステム開発における設計・実装フェーズはすっかり AI コーディングエージェント主体で進める形にシフトしています。一昔前は隣で様子を見ていないと AI がタスクを完遂できなかったり誤った方向に進んでしまうことも多く、AI とペアプロしながら実装を進めていました。しかし、最近はしっかり Plan ファイルで方向性の認識を合わせてさえいれば、最後まで実装を完遂してくれ、何点か修正すればそのまま Pull Request をあげられる品質のコードを書いてくれるようになりました。

ただ、AI が優秀になり設計・実装が早くなっても、開発プロセス全体で見ると自分自身がボトルネックになり生産性が頭打ちするのを感じていました。エージェントは並列で動かしたいけど、自分としては 1 つの作業に集中したい。複数ターミナルでエージェントを並列に動かしても、自分のコンテキストスイッチが増えるだけ。この課題を Claude Code の Agent Teams で解消できないかと、開発プロセスに組み込んだ方法をご紹介します。

Agent Teams とは

Claude Code の Agent Teams は、メインのセッション（チームリーダー）が複数のエージェント（チームメンバー）をスポーンし、チームとして並列にタスクを進める機能です。フロントエンド・バックエンド・テストなど職能でチームを組んだり、観点別にレビュワーを立てて並列レビューしたりといった使い方ができます。

ただし、私たちのチームでは人間によるコードレビューを行っており、1 つの Pull Request は大きくても 1000 行程度に収めるようにしています。大量に PR を作るとレビュワーの作業を逼迫しますし、大量のコード変更が入った PR はまともにレビューできません。

そうすると、フロントエンド・バックエンドを並列に実装するような大規模な並列開発は Agent Teams の使い所としてはあまり合いません。ではどんなユースケースがあるのかと考えたとき、ローカルでやっている開発プロセスの中で人が介入しているポイントを Agent Teams で減らす方向で使ってみることにしました。

開発プロセスにおける人間の役割の変化

これまで: 人間がエージェント間のハブになっている

AI コーディングエージェントで開発を進めていると、1 つの開発プロセスの中で複数のエージェントを使い分ける場面が増えてきます。実装者のコンテキストとレビュワーのコンテキストを分けて別の観点からレビューしたり、コンテキストウィンドウを効率よく使うために設計と実装でセッションを分けたりします。

こうなると、エージェント間を繋ぐのは人間の仕事になります。

Plan を作ったら別のターミナルでレビューして、レビュー結果を元のエージェントに伝えて修正させる。実装が終わったらまた別のターミナルでレビューして、指摘を伝えて直させる。これらのやりとりを人間を経由します。さらに、エージェントが作業している待ち時間に別の仕事を進めようとすると、人間のスイッチングコストがかかります。実装タスクを対応してもらっている間に別の設計を進めたり、顧客への返信をしたり...結局どの作業も中途半端になりがちでした。

エージェントの並列化はできているが人間側の並列化はできていない、という課題がありました。

Agent Teams 導入後: 人間はリーダーとだけ話す

Agent Teams を導入すると、チームリーダーがエージェント間のハブ役を引き受けてくれます。人間はリーダーとだけやりとりすれば済みます。

人間の介入ポイントは「要件・方向性を伝える」「最終的な判断をする」だけ。エージェント間の調整、レビュー結果の伝達、修正の指示は全てチームリーダーとメンバーの間で完結します。人間は 1 つのセッションとだけやりとりすれば済むので、1 つの作業に集中できる状態を保ったまま、裏で開発プロセスが並列に進みます。

この Before → After を実現するために、開発プロセスを 3 つのフェーズに分けてスキル化しました。フェーズごとにサブエージェントと Agent Teams を使い分けています。

開発プロセスを 3 つのスキルに分割

ローカルで行う開発プロセスを、「設計」「実装」「セルフレビュー」の 3 つのフェーズに分けて、それぞれスキル化しました。

.claude/
├── agents/
│   └── plan-reviewer.md          # Planレビュー用サブエージェント
└── skills/
    ├── plan-and-review/SKILL.md   # 1. 計画→AIレビュー
    ├── team-impl/SKILL.md         # 2. 実装→AIレビュー→修正サイクル
    └── team-review-fix/SKILL.md   # 3. 人間レビュー指摘の並列対応

スキル 1: plan-and-review（サブエージェント）

計画フェーズを 1 つのスキルにまとめました。

Phase 1-2: Plan作成   — メインエージェントとユーザーで1対1の壁打ち
Phase 3:   AIレビュー  — サブエージェントがバックグラウンドでレビュー
Phase 4-5: 仕分け・確認 — レビュー指摘を判断しplanに反映

Plan は一番大事な箇所なので、メインエージェントと 1 対 1 で壁打ちしながら仕様を固めます。Plan に対するレビューはレビュー結果だけ取得できればよく、実装レビューと違い複数観点のクロスレビューも不要です。エージェント間の協調も不要なため、ここではサブエージェントを使っています。サブエージェントはメインのコンテキストから分離して一発限りのタスクをこなし結果を返してくれる仕組みで、バックグラウンドで作業中もメインエージェントと会話を続けられます。

SKILL 化する前は Plan ファイルの結果を、人間がレビューするとともに別のセッションでレビューエージェントに渡していました。
SKILL 化したことで人間がレビューするのは一度 AI レビューが通った後の計画ファイルのみとなり、精度の上がった計画ファイルをレビューすることができます。

スキル 2: team-impl（Agent Teams）

計画をもとに実装から AI レビューまでを 1 チームで完結させます。こちらもチーム内でレビューが通った品質の高い成果物だけを人間に渡すのがコンセプトです。

Phase 1: 準備        — plan読み込み、並列度分析、共有ファイル準備
Phase 2: チーム作成   — Developer(s) + Reviewer(s) をスポーン
Phase 3: 実装        — Developer(s) が plan に沿って並列実装
Phase 4: AIレビュー   — Reviewer(s) が観点別に並列レビュー
Phase 5: 修正サイクル  — 指摘修正→再レビュー（全員承認まで繰り返し）
Phase 6: 完了報告     — ユーザーに報告

チーム構成

• Developer: 最大 2 名。plan を分析して並列実装可能な箇所を特定し動的に決定
• business-logic-reviewer: ビジネスロジック正当性（plan との整合性、データフロー、エラーケース）
• standards-reviewer: 規約・型安全性（命名、型安全性、DI）
• test-quality-reviewer: テスト品質（分類、カバレッジ、不足/過剰テスト）
• schema-api-reviewer: スキーマ-API 整合性（スキーマ変更がある場合のみ）

レビュワーをそれぞれ観点別にエージェントとして立てることで、1 人のレビュワーでは偏りがちな視点をカバーできます。
チーム内レビューが通ったコードと、人間の判断が必要とされた事項のリストが成果物として上がってきます。

なぜサブエージェントではなく Agent Teams か

このフェーズではサブエージェントではなく Agent Teams を使っています。理由は 3 つあります。

メンバーがお互いを意識して協調できる。 チームリーダーは Plan ファイルを読み、タスクの依存関係や影響範囲を考慮して Developer 2 名にタスクを割り当てます。しかし、お互いの影響範囲が被らないように割り当てても、作業状況によっては別の Developer の作業でテストが壊れたり静的解析が落ちたりすることがあります。サブエージェントはお互いの存在を知らないためこの問題に対処できませんが、Agent Teams であれば Developer 同士がお互いの作業状況を認識でき、問題発生時にはリーダーに報告して協調して動けます。

リーダーにハブ役を任せられる。 チームを協調して動かすにはリーダーの手を空ける必要があります。リーダーが自分で実装やレビューをするのではなく、これまで人間が担っていたエージェント間のハブ役に徹してもらう。これが Agent Teams を選ぶ最大の理由です。

必要なときに人間が介入できる。 Agent Teams の作業中、人間は別のことをしていたい。チームメンバーの作業を逐一監視するつもりはありません。ただ、サブエージェントと違ってチームメンバーの各セッションが TUI で見えるので、リーダーが困っていたら人間が介入して助けることができます。

スキル 3: team-review-fix（Agent Teams）

人間の PR レビュー指摘を効率よく並列処理するスキルです。

Phase 1: チーム作成  — Developer 2名をスポーン
Phase 2: 対話ループ  — ユーザーの指摘を受けて Developer に振り分け（繰り返し）
Phase 3: 完了       — 全指摘対応完了

チーム構成は Developer 2 名のみ。Reviewer は不要です。このタイミングでは人間がレビュアーだからです。

リーダーが窓口に徹し、依頼を受けたら即座に「振り分けました」と返答。ユーザーは次の指摘を続けられるようにしています。実はここが SKILL 化して一番嬉しく感じているポイントです。

単一のエージェントにコードレビュー指摘を投げていると指摘対応が終わるまで待つ必要があり、別の TODO リストを管理したり待ち時間に別のことをしたりと面倒でした。
リーダーは作業を持たない形にしたことで、コードレビューに集中して気づいた指摘をいつでも放り込むことができます。

修正依頼だけでなく、調査や質問、対応要否の壁打ちなどに対応できるようにしています。

チームを機能させる仕組み

2 つのスキルで Agent Teams を使っていますが、メンバーをスポーンしてタスクを渡すだけではチームはうまく回らないことに気づきました。実際の開発チームと同じように、役割の明確化、状況の共有、問題の検知が必要でした。

最後に、Agent Teams をうまく回すための工夫をご紹介します。

リーダーは作業を持たない

公式ドキュメントにも以下の記載があります

時々、リーダーはチームメンバーを待つ代わりに、タスク自体を実装し始めます。これに気付いた場合は、以下を実行してください。
Wait for your teammates to complete their tasks before proceeding

チームリーダーがタスクを持ってしまうとメンバーが遊んでしまったり、メンバーをうまく使いこなせなくなります。リーダーにはチームを回すことに専念させるのが大事です。スキルの定義でリーダーの禁止事項を明示しています。

• コード実装・修正
• コード調査・読み取り
• コードレビュー
• テスト実行

リーダーの仕事はユーザーの要望を汲み取ること、タスクを管理してメンバーにアサインすること、メンバーが困っていたらサポートすること、判断が必要なものはユーザーに確認すること。これだけです。

Markdown ファイルでタスクと進捗を可視化

Agent Teams は Claude Code のビルトインの TaskList を利用することができ、チームで共有するタスクは~/.claude/tasks/{team-name}/ で管理されます。

{
  "id": "4",
  "subject": "タイトル",
  "description": "説明",
  "owner": "worker-a",
  "status": "completed",
  "blocks": [],
  "blockedBy": []
}

タスクの説明とステータス、所有者や依存関係を管理でき、シンプルなタスクを消化させるだけなら十分ですが、実際の開発プロセスで使うには 2 つの課題がありました。

• 拡張性がない

  • 固定スキーマ（subject, description, status, owner, blockedBy）のみで、開始時刻、影響ファイル一覧、依存関係の詳細など、チームで協調するために必要な情報を表現できません。

• 人間や監視エージェントから参照しにくい

  • ビルトイン TaskList の状態は ~/.claude/tasks/ 配下の JSON で管理されており、チームリーダーのセッションで ctrl + g を実行するとリストのチェック状況が見えますが、それ以外に全体状況を確認する手段がありません。監視エージェントが定期的にタスク状況をチェックする用途にも向きません。

そこで、作業ディレクトリに共有の Markdown ファイルを置いてタスクとステータスを管理しています。

• status-board.md: 各メンバーのステータス・現在のタスク・触っているファイルを記録
• task-log.md: 全タスクの一覧、担当、ステータス、結果を一元管理

以下のようなイメージです。

Markdown ファイルなので好きな列を自由に追加でき、人間はエディタやターミナルからパッと確認できます。リーダーはメンバーの作業状況を一目で把握でき、メンバー同士も他の作業を理解した上で動けるので、同じファイルを同時に編集してしまう事故も防げます。

現在はチーム開発の仕組みを改善しながら作業を進めているため、Agent Teams のペインを分割して個々のメンバーも表示していますが、安定してきたらチームリーダーに管理を任せ、人が監視するのはタスクリストとステータスボードにしたい狙いもあります。

その他にもレビューエージェントからのレビュー指摘や修正ログなどは、メンバー同士のメールボックスのやり取りだけでは情報共有が難しいため、専用のマークダウンファイルを介したやりとりにしています。

タスクの割り当て方式

タスクの割り当て方式についてはリーダーが事前に割り振る方式（Push 型）が最も安定しました。

メンバーが自由に取る方式（Pull 型）にした場合、排他制御が甘く作業の重複が発生することがありました。
タスクを取る際にチームメンバー同士でメッセージをブロードキャストする方式も試してみましたが、隣にいる同僚に話しかけるのとは違い、作業途中のエージェントはメッセージを受け取れるタイミングが限られており、コミュニケーションがうまくいかないことがありました。

さらに、実際の開発タスクをこなす場合、作業の依存関係や影響範囲などを考えてタスクを取る必要があります。全てをタスクボードを見ればわかる状態にするのもなかなか難しいので、リーダーから Push する形にして、コンフリクトなどが発生した場合はリーダーがチームメンバー間のタスクを調整する形にしました。

監視エージェント

メンバーがエラーで止まったり応答しなくなることや、完了報告がメンバーからリーダーに届かずに、コミュニケーションミスによりリーダーが待ち状態になってしまうことがありました。
この問題を解消するために、haiku モデルの軽量な監視エージェントを別のチームメンバーとして立ててみました。

監視エージェントは /loop で毎分 task-board.md を読み、「作業中」のまま一定時間以上経過しているタスクがあればリーダーに通知します。

監視エージェントが task-board.md を Read して開始時刻と現在時刻を比較するだけでよく、ビルトイン TaskList の JSON ではこうした外部からの参照が難しくなるため、専用の Markdown ファイルを用意する形をとっています。

ボトルネックをチームリーダーに肩代わりしてもらう

Claude Code を並列で動かして作業を進めていると、各ターミナルから通知のラッシュが飛んできて、自分がボトルネックになり作業効率が頭打ちするのと、1 つの作業に集中できない課題を感じていました。

複数の Claude Code セッションのオーケストレーションを Agent Teams のリーダーに委譲することで、人間が介入するポイントを減らし、Claude Code の応答を待つことなくリーダーにタスクを放り込めるようになりました。計画フェーズはサブエージェントがバックグラウンドでレビューしてくれる。実装フェーズはチームが自律的にレビューまで完結してくれる。人間レビューの指摘対応は並列で処理される。その間、人間は要件の言語化や計画の方向性の判断、人間にしかできないレビューなど、本来集中すべき仕事に時間を使えるようになりました。

まだこの方式で開発を始めて間もなく、タスク管理やチーム間の調整は試行錯誤の段階です。また Agent Teams は現在実験的機能のため、ツールが成熟すればタスクの割り当てやメンバー間のコミュニケーションが標準機能として改善されていくと思います。今回スキルに書いている運用上の工夫の多くは、いずれ不要になるかもしれません。

マルチエージェントを協調して動かす体験は、見ているだけでも単純に面白いです。
「エージェントは並列で動かしたいけど、自分は 1 つの作業に集中したい」と感じている方は、Agent Teams を試してみてはいかがでしょうか。

以上。リテールアプリ共創部のきんじょーでした。