タスクをチームにアサインすると何が嬉しいのかーAgentTeamsを実務に組み込むノウハウ

Classmethod主催ウェビナー「Claude Codeセミナー 実践編｜マルチエージェント協調とAgent Teams活用」で発表した資料です。
https://classmethod.jp/seminar/260401-claude-code-webinar/

【概要】
・タスクをチームにアサインするメリット
・Agent Teamsの使いどころ
・３つのスキルで開発プロセスを効率化する
・Agentをチームで機能させるための運用の工夫

Transcript

1. タスクをチームにアサインすると何が嬉しいのか？ ー Agent Teams を実務に組み込むノウハウ 2026/04/01 リテールアプリ共創部 マッハチーム 金城秀哉
3. 1 年ほど前 横で見ていないとタスクを完遂 できない 誤った方向に進みがち AI とペアプロしながら実装 現在 Plan で方向性を合わせれば最 後まで実装を完遂 少し修正すればそのまま PR を あげられる品質 AI に作業を任せている間に、 人間は別の作業を進める 設計・開発は AI コーディングエージェント主体に 3
4. 機能 A・B・C と、常に複数のタスクを並行で回している。 日々の開発: 複数タスクを並行で進めている
5. コンテキストの分離 精度低下・要約による情報損失を 防ぐ 観点の分離 実装とレビューのバイアスを分離 並列実行 複数レビュワーを同時に走らせる 1 つのタスクを複数エージェントで担当する 5
6. 人間が中継しながら、複数タスクを回すと・・ エージェントを分けて複数タスクを並列実行
7. 承認依頼・完了報告が同時に飛んでくる 結果を確認して次の指示を出す中継に追われる 自分のコンテキストスイッチで全部中途半端に エージェントを並列にできても、人間は並列になれない 開発生産性が頭打ちになる 人間がハブになると何が起きるか 7
8. AI エージェントは並列で動かしたい でも自分は 1 つの作業に集中したい
9. サブエージェントや Agent Teams を使うと？
10. Before: 人間がエージェント間のハブ
11. タスクごとにチームリーダー エージェント間の橋渡しはリー ダーが担う Agent Teams はチームメンバ ー間協調して動作可能 人間は要件の言語化と最終判断 だけに集中 After: タスクの 1 つ 1 つをチームに任せる 11
12. 1. タスクをチームにアサインする ← 今お話ししました 2. Agent Teams の使いどころ 3. 3 つのスキルで作る開発プロセス 4. チームを機能させる運用の工夫 本日お話しすること 12
13. Agent Teams の使いどころ
14. リサーチ・レビュー: 複数メンバーが異なる観点で並列調査 新モジュール/機能: 各自が独立した部分を担当 デバッグ: 仮説を並列に検証して収束を早める クロスレイヤー: フロント/バック/テストを並列実装 共通点: 並列に探索・実装することで価値が出る場面 公式ドキュメントが挙げるユースケース 14
15. 複数人でプロジェクトを進めている 人間によるコードレビューを行っている PR サイズは大きくても 1000 行程度に抑えたい 大量の PR / 大量のコード変更はレビュワーを逼迫する 大規模な並列開発以外に何か使えないか？ 我々のチームの場合 15
16. チーム内で AI レビュー・トリアージ・修正まで完結させる 成果物を人間がレビューする前に品質をできるだけ高める どうしても判断が必要なところだけ人間が関与する リーダーを常に応答可能にし AI が作業中の待ち時間を減らす 並列で AI を動かしながら、人間は一つの作業に集中する Agent Teams をローカル開発プロセスの効率化に使う 16
17. 3 つのスキルで作る開発プロセス
18. 人間介入ポイントを減らすため、3 つのフェーズをスキルにした。 .claude/ ├── agents/ │ └── plan-reviewer.md └── skills/ ├── plan-and-review/SKILL.md # 1. 計画→AIレビュー ├── team-impl/SKILL.md # 2. 実装→AIレビュー→修正 └── team-review-fix/SKILL.md # 3. 人間レビュー指摘の並列対応 開発プロセスをスキル化 18
19. Plan 作成はメインセッションで壁打ち → AI レビュー → 指摘反映 → 人間最終確認 チーム内協調が不要 → サブエージェントで十分 最終成果物: AI レビュー済みの Plan 1) plan-and-review（サブエージェント） 19
20. # Plan: 受注確定後のメール通知実装 (TASK-142) ## Context 受注確定後に顧客へ確認メールを送信する機能を実装する。 現在メール送信ハンドラーはスタブ（ログ出力のみ）。 ## 方針決定事項 - メールテンプレート: order_confirmed / order_shipped - 送信キュー: リアルタイム/バッチ分離 ## 実装ステップ ### Step 1: メール送信キューの分離（インフラ） ### Step 2: メールテンプレートエンジンの実装 ### Step 3: 受注イベントハンドラーの接続 ... plan-and-review: 最終成果物 plan.md 20
21. # Plan Review Result 指摘数: High: 1 件 / Medium: 2 件 / Low: 1 件 ## [High-1] 送信失敗時のリトライ仕様が要件定義と齟齬 要件書では「3 回リトライ後に DLQ へ」と記載されているが、 Plan では「失敗時はログ出力のみ」となっている。 → 推奨: 要件書の仕様に合わせてリトライ設計を追記すること ## [Medium-1] バッチ処理時の送信上限が未記載 → 推奨: 1 バッチあたりの最大件数と分割方針を明記すること plan-and-review: AI レビュー結果 21
22. # Review Decisions ## 反映済み - [Medium-1] バッチ上限 → 「500 件/バッチで分割」を追記 - [Medium-2] テスト容易性 → DI パターンに変更 - [Low-1] 変更対象ファイルパスを明記 ## ユーザー判断が必要 - [High-1] リトライ仕様 → 要件書と実装方針が矛盾 → 選択肢 A: 要件書通り 3 回リトライ / 選択肢 B: 要件書を修正してログのみ 人間はこの「判断が必要」リストだけ見ればよい plan-and-review: レビュー判断 → Plan に反映 22
23. Developerが並列実装 観点別レビュワーが並列レビュー 指摘 → 修正 → 再レビューを全 員承認まで繰り返す 実装者とレビュワーで直接会話 FBループをコンテキストを引き 継いだ同じAIが担当 2) team-impl（Agent Teams） 23
24. # Code Review Notes — Plan: 受注メール通知実装 ## サマリ - 影響範囲: handler（パラメータ追加）、use-case（送信ロジック）、テスト（12 件追加） ## ビジネスロジック正当性 指摘なし（フィルタロジック・オーケストレーション・境界ケースすべて問題なし） ## 規約・型安全性 ### [Should Fix] スキーマでバリデーションに transform を使用していない → 対応不要（設計判断として Plan 通り。handler 層でのパースを維持する） ### [Nit] テストケース命名が規約プレフィックスなし → 対応しない（純粋ユーティリティ関数のため） ## テスト品質 不足テストケース: なし / Nit 1 件（対応済み: ダミーデータ共通化） ## 最終判定 - business-logic-reviewer: Approved - standards-reviewer: Approved（Should Fix 1 件 → 対応不要判断） - test-quality-reviewer: Approved（Nit 1 件 → 対応済み） team-impl: 最終成果物 review-notes.md 24
25. 開発者 2 名のみ → リーダーがレビュー指摘を即時振り分け 待たずに次の指摘を投入可能 → 「指摘して待つ」を「指摘し続け る」に変える → コードレビューに集中 3) team-review-fix（Agent Teams） 25
26. チームを機能させる運用の工夫
27. リーダーがプレイングマネージャー化 → チーム全体が止まる リーダーの禁止事項をスキルに明示 コード実装・修正・調査・レビュー・テスト実行を禁止 役割を「調整・判断補助」に限定する リーダーに作業を持たせない 27
28. Pull 型（自由取得）→ ファイル競合・タスク重複・進捗が散らば る Push 型（リーダー割当）に変更 依存関係と影響範囲を見て先に担当を決める コンフリクト発生時はリーダーが即調整 Push 型のタスク割り当て 28
29. ビルトイン TaskList だけでは誰が何をしているか見えない 外部 Markdown（status-board / task-log）で状況を共有 # Status Board ## 開発者 A - ステータス: 完了 - 作業: レビュー指摘 3 件対応 ✓ - ファイル: auth.ts, repository.ts, util.ts ## 開発者 B - ステータス: 作業中 - 作業: validEndDate non-nullable 化 - ファイル: schema.ts, handler.ts # Task Log ### Task 23: CI Lint 修正 - 担当: 開発者 B / 完了 ### Task 24: 型定義修正 - 担当: 開発者 B / 作業中 - 内容: nullable → non-nullable に変更 use-case のマッピングも対応 Markdown でタスクと進捗を可視化 29
30. 実際の運用画面
31. 完了報告をリーダーが見逃す → お互い待ちのデッドロック 軽量モデル（haiku）+ /loop で毎分 status-board.md を監視 一定時間以上「作業中」のタスクを検出 → リーダーに通知 コミュニケーション抜けやメンバー停止を早期発見 監視エージェントを置く 31
32. Agent Teams はサブエージェントよりコストが高い Agent Teams を並列で動かすと Max $100 でも数十分でレート リミットに到達 日常タスクは単一・サブエージェント中心で十分 協調価値が高いフェーズだけ Agent Teams を使う コストとの向き合い方 32
33. まとめ
34. エージェントの並列化はできても、人間の並列化はできない エージェント間のハブ役をチームリーダーに委譲する 開発プロセスを 3 つのスキルに分けて、サブエージェントと Agent Teams を使い分ける チームを機能させるにはリーダー設計・可視化・監視が鍵 人間がハブにならない仕組みを作ると、エージェントも人間も本来の 仕事に集中できる 今日お伝えしたこと 34
35. スキルの詳細はブログにまとめています https://dev.classmethod.jp/articles/optimize- agent-teams-dev-process/ こちらのブログもご覧ください 35
39. ありがとうございました！ 39