Chapter 33: AI エージェント開発
サブエージェント・チーム構成・自律開発ループ
33.1 AI エージェントとは
AI エージェントとは、目標を与えられると自律的にツールを使いながら複数ステップにわたるタスクを遂行する AI システムです。単発の質問に答えるだけのチャット AI とは根本的に異なります。
エージェントの特徴:
| 特性 | 説明 |
|---|---|
| 自律性 | 次のアクションを自分で決定する |
| ツール使用 | ファイル操作・コード実行・Web検索などを呼び出す |
| ループ実行 | 結果を見て再試行・方針変更ができる |
| 状態保持 | セッション内でコンテキストを維持する |
エージェントの実行モデル
Claude Code はこのループを内部的に実行しており、ユーザーが与えた目標に向けてツールを組み合わせながら自律的に作業を進めます。
33.2 サブエージェントの設計
メインセッションのコンテキストウィンドウは有限です。複雑なタスクではサブエージェントに作業を委譲することで、メインのコンテキストをクリーンに保ちつつ並列作業が可能になります。
サブエージェントの用途
- 調査・探索: コードベース解析、外部 API 仕様の調査
- 並列分析: 複数ファイルの同時レビュー
- 専門タスク: 型チェック・テスト生成・ドキュメント生成
Task ツールによるサブエージェント起動
メインエージェントから Task ツールを使ってサブエージェントを起動する:
Task: {
description: "src/auth/ ディレクトリの全ファイルで JWT 検証ロジックを確認し、
脆弱性があれば報告してください",
output: "脆弱性レポート(severity, file, line, description 形式)"
}サブエージェントの設計原則
- 1サブエージェント1タスク: 複数の責務を持たせない
- 明確なアウトプット定義: 何を返すかを事前に決める
- 独立性: 他のサブエージェントの結果に依存しない設計にする
- タイムアウトを考慮: 長時間実行は避け、分割する
33.3 チーム構成
複数の専門エージェントを組み合わせたエージェントチームは、単一エージェントでは不可能な複雑なワークフローを実現します。
チーム定義の実装例
.claude/agents/ にエージェントを定義し、オーケストレーターが Task ツールで各エージェントを起動するパターン:
<!-- .claude/agents/backend-developer.md -->
---
name: backend-developer
description: Node.js/TypeScript でバックエンド API を実装する専門エージェント
---
## 役割
REST API のエンドポイント実装、ビジネスロジック、データアクセス層の実装を担当する。
## 制約
- テストを必ず書く(Vitest、カバレッジ 80% 以上)
- エラーは Result 型で返す(throw 禁止)
- Prisma を使ってデータアクセスする
## 出力
実装したファイルの一覧と、実行したテストの結果を報告する。チームの制限事項
- ネスト不可: Teammate が自分のチームを作ることはサポートされていない
- 1セッション1チーム: セッションをまたいだチームの再利用は実用的でない
- チームデータの場所:
~/.claude/teams/に作られる(プロジェクトの.claude/teams/ではない)
33.4 並列タスク実行
エージェントチームの真価は並列実行にあります。順次実行では数時間かかる作業を、並列化することで大幅に短縮できます。
並列実行の実装パターン
オーケストレーターが複数の Task を同時に起動する例:
以下の3つのレビューを並列で実行してください:
1. Task(code-reviewer): src/ のコード品質を評価
2. Task(silent-failure-hunter): エラーハンドリングの漏れを検出
3. Task(pr-test-analyzer): テストカバレッジの品質を評価
全て完了したら、結果を統合して総合判定を出してください。依存関係の管理
全タスクが並列可能なわけではありません。依存関係のある場合は段階的に実行します:
33.5 自律的な開発ループの構築
自律開発ループは、Issue 作成からマージまでを人間の介入なしに完走させる仕組みです。
自律ループのスクリプト例
#!/bin/bash
# auto-dev-loop.sh
ISSUE_NUMBER=$1
BRANCH="feat/${ISSUE_NUMBER}-$(gh issue view $ISSUE_NUMBER --json title -q '.title' | tr ' ' '-' | tr '[:upper:]' '[:lower:]')"
# ブランチ作成
git checkout -b "$BRANCH"
# Claude Code での実装
# 注意: CLAUDECODE 環境変数が設定されている場合は env -u で除去する
env -u CLAUDECODE claude -p "
GitHub Issue #${ISSUE_NUMBER} の内容を実装してください。
- ブランチ: $BRANCH
- テストを書いて全パスさせること
- コミットメッセージに (#${ISSUE_NUMBER}) を含めること
" --output-format stream-json | jq -r '.message.content[0].text // empty'
# PR 作成
gh pr create \
--title "$(gh issue view $ISSUE_NUMBER --json title -q '.title') (#$ISSUE_NUMBER)" \
--body "Closes #$ISSUE_NUMBER"33.6 エージェント設計パターン集
パターン1: 検証ループ(Verify Loop)
実装 → テスト → 失敗時は修正 → を繰り返すパターン。CI が通るまで自律的に動く。
パターン2: 専門家評議会(Expert Council)
異なる専門を持つエージェントが同じ対象を独立評価し、オーケストレーターが統合判断するパターン。
パターン3: パイプライン(Pipeline)
各エージェントの出力が次のエージェントの入力になるパターン。データ変換・ETL・ドキュメント生成に有効。
パターン4: フォールバック(Fallback)
プライマリエージェントが失敗した場合にセカンダリエージェントが引き継ぐパターン。高可用性が必要な場合に使う。
パターン5: ヒューマン・イン・ザ・ループ(Human-in-the-Loop)
エージェントが「これは人間の判断が必要」と判断したタイミングで処理を停止し、確認を求めるパターン。本番環境への変更や金銭が絡む処理に必須。
TODO: あとで実際のスクリーンショットに置き換え - Claude Code でエージェントチームが並列タスクを実行している様子
各パターンは組み合わせて使えます。例えば「専門家評議会 → フィードバックを受けて実装 → 検証ループ」という複合パターンが PR レビューワークフローの基本形です。