Agent Teams+Skillsでエージェント3体と1週間働いたら、"自分の仕事"が再定義された
「AIに指示を出す側」のつもりが、自分がボトルネックだった
Claude Codeを使い始めて半年、自分は「AIを使いこなしている側」だと思っていました。プロンプトを書いて、コードを生成させて、レビューして、マージする。効率は確かに上がっていた。
でも、ある日気づいたんです。毎回同じレビュー指摘を口頭で伝えている自分がいることに。AIに「レビューして」と頼んでも、観点がブレる。テストを書かせても、戦略がない。結局、自分がすべての判断を下していて、AIは「ちょっと賢いコード生成機」止まりだった。
そこで試したのが、Agent TeamsとSkillsを組み合わせた運用です。1週間実務に投入した結論から言うと、変わったのはツールじゃなくて、自分の仕事の定義でした。
Agent Teamsとは?
Agent Teamsは、複数のClaude Codeインスタンスが1つのチームとして協調動作する仕組みです。従来のClaude Codeは1つのセッションで1体のAIと対話するスタイルでしたが、Agent Teamsでは「リード+複数のチームメイト」という構成で、メンバーがそれぞれ独立したコンテキストを持ちながら並列に作業します。
アーキテクチャ
| 要素 | 役割 |
|---|---|
| Team lead | メインセッション。チームの作成・タスク割り当て・成果の統合を担う |
| Teammates | 独立したコンテキスト窓を持つワーカーインスタンス。それぞれが専門領域を担当 |
| Task list | メンバー全員が参照する共有タスクリスト。pending → in-progress → completedで進捗管理 |
| Mailbox | メンバー間の直接メッセージング。レビュー依頼や質問をメンバー同士でやりとり |
ポイントは、各メンバーが独立したコンテキスト窓を持つこと。人間のチーム開発と同じで、実装担当が黙々とコードを書いている間に、レビュアーが別のファイルをチェックし、テスト設計者がテスト戦略を練る──これが本当に並列で進むわけです。
サブエージェントとの違い
Claude Codeには従来から「サブエージェント」(.claude/agents/ で定義するカスタムエージェント)がありますが、Agent Teamsとは根本的に別の仕組みです。
| サブエージェント | Agent Teams | |
|---|---|---|
| コミュニケーション | 親に結果を返すだけ(一方向) | メンバー同士がMailboxで直接やりとり |
| タスク管理 | 親がすべて管理・割り当て | 共有タスクリストで自己調整 |
| コンテキスト | 親セッション内で動作 | 各メンバーが独立したコンテキスト窓 |
| カスタマイズ |
.claude/agents/ にMarkdownで事前定義 |
プロンプトで自然言語的に動的生成 |
| 並列性 | 逐次実行(バックグラウンド実行は可) | 真の並列実行 |
| メモリ |
memory フィールドでセッション跨ぎの蓄積可 |
セッション内のみ(永続化なし) |
| 安定性 | 安定版 | 実験的機能 |
| トークンコスト | 低い | 高い(各メンバーが独立インスタンス) |
使い分けの目安:
- サブエージェント向き: 結果だけ欲しい定型タスク(ファイル探索、単体レビュー、テスト実行など)
- Agent Teams向き: メンバー間の議論・協調が必要な複雑作業(機能開発、リファクタリング、並列レビューなど)
この記事ではAgent Teams + Skillsの組み合わせに集中して、1週間の実験結果をお伝えします。
実験設計:3体のエージェントチーム
今回はこの3体構成で1週間回しました。
- Implementer(実装担当): コードを書く主力
- Reviewer(レビュアー): セキュリティ・パフォーマンス観点でレビュー
- Tester(テスト設計者): テスト戦略の立案と実装
単に「3人チームを作って」と指示するだけじゃなく、Skillsでチームメイトの判断基準を整備し、Agent Teamsで自然言語でチーム構成を指示する──この組み合わせがポイントです。
Step 1: Skillsでレビュー基準とテスト戦略を定義する
CLAUDE.mdに全部書くと肥大化するし、チームメイトごとに必要な知識が違います。Skillsを使えば、必要な知識だけを整理して共有できます。SkillsはAgent Teamsのチームメイトにも継承されるため、チーム全体の共通資産になります。
.claude/skills/review-checklist/SKILL.md:
---
name: review-checklist
description: コードレビューの基準チェックリスト
user-invocable: false
---
## レビューチェックリスト
### セキュリティ
- [ ] ユーザー入力のバリデーション・サニタイズ
- [ ] SQLインジェクション対策(パラメータバインディング)
- [ ] XSS対策(出力エスケープ)
- [ ] 認証・認可チェックの漏れ
- [ ] 機密情報のハードコード(APIキー、パスワード)
### パフォーマンス
- [ ] N+1クエリの有無
- [ ] 不要な再レンダリング(React: useCallback/useMemo)
- [ ] 大量データの非効率な処理(メモリ内ソート等)
- [ ] インデックスなしのDBクエリ
### 保守性
- [ ] 関数・変数の命名が意図を表しているか
- [ ] 1関数が50行を超えていないか
- [ ] マジックナンバーの排除
- [ ] 重複コードの有無
.claude/skills/test-strategy/SKILL.md:
---
name: test-strategy
description: テスト設計の方針と基準
user-invocable: false
---
## テスト設計方針
### カバレッジ目標
- ユニットテスト: 80%以上
- 統合テスト: 主要なユースケースをすべてカバー
- E2Eテスト: クリティカルパスのみ
### 優先すべきテスト観点
1. 正常系の主要フロー
2. バリデーションエラー(入力の境界値)
3. 認証・認可の境界(未ログイン、権限不足)
4. 非同期処理のエラーハンドリング
5. Race conditionが起きうる箇所
### テストの書き方
- Arrange-Act-Assert パターンで統一
- テスト名は「何をしたら何が起きるか」を日本語で書く
- モックは最小限に(外部API・DB接続のみ)
user-invocable: false にしているのがポイントで、これはユーザーが /review-checklist で呼ぶものではなく、エージェントに自動注入される専門知識として使います。Agent TeamsのチームメイトにはプロジェクトのSkillsとして継承されます。
Step 2: Agent Teamsを有効化して起動する
settings.json でAgent Teamsを有効化します。
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
そしてAgent Teamsを起動するプロンプト:
エージェントチームを作成して、認証モジュールのリファクタリングに取り組んでください。
3人のチームメイトを生成:
- 実装担当: src/auth/ 配下のリファクタリング。JWT処理の簡素化とエラーハンドリングの統一を担当
- レビュアー: シニアコードレビュアーとして振る舞う。review-checklist Skillに従い、セキュリティ(OWASP Top 10)・パフォーマンス(N+1、メモリリーク)・保守性の3観点でレビュー。Critical / Warning / Suggestion の3段階で報告すること
- テスト設計者: テスト設計の専門家として振る舞う。test-strategy Skillに従い、ユニットテスト→統合テスト→E2Eの優先順でテスト戦略を立案・実装する
実装担当のタスクを以下に分割:
1. JWT検証ロジックの共通化
2. エラーレスポンスの統一
3. トークンリフレッシュ処理の改善
4. ログアウト処理の簡素化
5. 型定義の整理
各メンバーはお互いの進捗を共有し、問題があれば議論してください。
レビュアーは plan approval を必須とし、実装前にレビューを通すこと。
Day 1-3:動き始めて見えたSkillsの威力
Skillsが効いた瞬間
一番「おっ」となったのは、レビュアーがSkillsのチェックリストに沿って構造化されたレビューを返してきたときです。
## Critical
- src/auth/login.ts:42 - パスワードのハッシュ比較がタイミング攻撃に脆弱
→ crypto.timingSafeEqual() を使用してください
## Warning
- src/auth/token.ts:15 - JWTの有効期限が24hは長すぎる
→ アクセストークンは15分、リフレッシュトークンは7日を推奨
## Suggestion
- src/auth/middleware.ts:8 - 認証ミドルウェアの関数名 `check` が曖昧
→ `requireAuthentication` に変更を提案
Skillsを注入しなかったときは「全体的にいい感じです。いくつか改善点があります」みたいなふわっとしたレビューだったのが、チェックリストがあるだけで具体性が段違いになりました。
Day 4-5:チームワークの最適化
delegate modeで人間は「方向だけ決める」
エージェント同士の議論が活発になると、人間が全体を把握しづらくなります。ここで効いたのが delegate mode(Shift+Tab)です。
リードエージェントを調整役に専念させて、人間は Shift+Up/Down でメンバーを選んで直接指示を出す。この運用にしてから「人間=タスクを実行する人」から「人間=方向を決めて品質を判断する人」に完全に移行できました。
並列レビューのSkill化
PRレビューが特に効果的だったので、繰り返し使えるようにSkill化しました。
.claude/skills/parallel-review/SKILL.md:
---
name: parallel-review
description: PRを3つの観点から並列レビューするエージェントチームを起動する
disable-model-invocation: true
---
PRをレビューするエージェントチームを作成してください。
3人のレビュアーを生成:
- セキュリティ担当: OWASP Top 10の観点でレビュー
- パフォーマンス担当: N+1クエリ、メモリリーク、不要な再レンダリングをチェック
- テスト担当: テストカバレッジの検証、エッジケースの漏れを指摘
対象: $ARGUMENTS
各レビュアーはreview-checklist Skillの基準に従い、Critical / Warning / Suggestion の3段階で報告すること。
レビュー完了後、リードが3つの観点を統合してサマリーを作成してください。
これで /parallel-review #142 と打つだけで、3観点の並列レビューが走ります。disable-model-invocation: true にしているので、自分が明示的に呼んだときだけ起動します。
Agent Teamsの主な制限事項(執筆時点)
- セッション再開不可: in-processで生成されたTeammatesはセッション終了で消滅します。途中から再開はできません
- 1セッション1チーム: 同時に複数のチームを作成・運用することはできません
- ネスト不可: Teammates(メンバー)が自らチームを作ることはできません。チームを作れるのはリードのみです
- リード固定: リードエージェントの昇格・移譲はできません。リードは常にチームを作成したエージェントです
- VS Code Terminal等でのペイン分割非対応: Agent TeamsのUIはClaude Code CLIでの利用を前提としています
Day 6-7:振り返り ── 人間がやるべき仕事は何だったか
1週間やってみて、人間の仕事が明確に変わりました。
| これまで | これから |
|---|---|
| コードを書く | Agent Teamsのチーム構成を設計し、Skillsで判断基準を定義する |
| レビュー基準を口頭で伝える | Skillsにチェックリストを書く |
| 1人で順番にレビューする | Agent Teamsで並列実行させて結果を選ぶ |
特に実感したのは、「たくさん作る力」から「どの未来を選ぶかを設計する力」への転換です。AIが3つの実装案を出してくれる。人間は「どれを選ぶか」「なぜそれを選ぶか」を判断する。この**「選ぶ力」**こそが、エージェント時代に最も価値を持つスキルだと感じました。
明日から始める2ステップ
Step 1: Skillsに判断基準を切り出す
CLAUDE.mdに全部書くのをやめて、Skillsに分離しましょう。必要な知識を整理して共有することで、チームメイトのアウトプットの質が段違いに上がります。
.claude/
└── skills/
├── review-checklist/
│ └── SKILL.md # レビュー基準
└── test-strategy/
└── SKILL.md # テスト方針
Step 2: Agent Teamsで並列化する
Skillsが安定したら、Agent Teamsで並列化してみてください。チームメイトはプロンプトで自然言語的に役割を指示して動的に生成します。Step 1で整備したSkillsはチームメイトにも継承されるため、そのまま活用できます。繰り返し使うパターンはSkill化(/parallel-review など)しておくと、コマンド一発で起動できます。
まとめ
1週間の実験で学んだことはシンプルです。
-
CLAUDE.mdだけに頼らない。
.claude/skills/に判断基準を切り出せば、チームメイト全員が同じ品質基準で動ける - Agent Teamsは「人間が選ぶ」ための仕組み。並列に動かして、人間は結果を見て判断する
変わったのはツールではなく「自分の仕事の定義」でした。コードを書く人から、チームの専門性を設計し、結果を選ぶ人へ。最初は戸惑いますが、この体験は不可逆です。
Discussion