生成AI研修
Part 6: AI × 開発 応用

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サブエージェント1タスク: 複数の責務を持たせない
  2. 明確なアウトプット定義: 何を返すかを事前に決める
  3. 独立性: 他のサブエージェントの結果に依存しない設計にする
  4. タイムアウトを考慮: 長時間実行は避け、分割する

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 レビューワークフローの基本形です。

On this page