コンテンツにスキップ

Claude Code 完全ガイド

AIエージェント開発チーム構築フレームワーク ― Claude Sub-Agentによるスクラム自動化の実践

1. はじめに：AI-Firstスクラムへの転換

従来のスクラム開発では、人間が全ての役割を担い、多くの時間を定型的な作業に費やしていました。2025年、Claude CodeのSub-Agent機能の登場により、これらの役割をAIエージェントが代替し、人間はより戦略的な意思決定に集中できる新しい開発パラダイムが実現可能になりました。

本記事では、3レイヤー7タイプのエージェント構成による最小限のフレームワークを提案し、その実装方法と運用指針を解説します。

2. フレームワーク全体像

2.1 基本コンセプト

  • 人間の役割を最小化：承認、方向修正、リスク判断のみに集中
  • Hooks/ポリシーで強制＋Sub-Agentで自動化：AIは提案・実行を担当、承認は人間が行う
  • メトリクス駆動の改善：継続的な測定とデータに基づく改善提案

2.2 3レイヤー構造

graph TB
    subgraph "方向＆改善レイヤー"
        A[Strategy Agent]
        B[Flow Optimizer]
    end

    subgraph "バックログレイヤー"
        C[Spec Curator]
    end

    subgraph "実装レイヤー"
        D[Dev-Frontend]
        E[Dev-Backend]
        F[Quality Guardian]
        G[Release Coordinator]
    end

    H[Librarian] --> A
    H --> B
    H --> C
    H --> D
    H --> E
    H --> F
    H --> G

    style H fill:#f9f,stroke:#333,stroke-width:4px

3. 各エージェントの詳細設計

3.1 エージェント役割マトリクス

レイヤーエージェント主な機能対応する従来ロールClaude Sub-Agent設定例
方向＆改善Strategy Agent目的/OKR更新・価値仮説検証・ロードマップ調整プロダクトオーナーname: strategy-agent
tools: browser,llm
prompt: 事業指標を週次で確認しOKRを更新せよ
Flow Optimizerボトルネック検出・プロセス実験提案・メトリクス可視化スクラムマスターname: flow-optimizer
tools: git,analytics,llm
prompt: CycleTime↑・DefectRate↓を目標に提案
バックログSpec Curator要件→ユーザーストーリー化、優先順位付け、DoR/DoD管理PO補佐／BAname: spec-curator
tools: editor,llm
prompt: requirements.mdを保守/tasks.md分解
実装Dev-Frontend
Dev-Backend		コード生成・ユニットテスト・ドキュメント開発者name: dev-frontend
tools: editor,test,llm
Quality Guardian静的解析・セキュリティ・コードレビューQA／Reviewername: quality-guardian
tools: bash,test-runner
Release CoordinatorCI/CD実行・バージョン付与・リリースノート生成Release Mgrname: release-coordinator
tools: git,ci
横断Librarian決定事項・仕様の差分同期 (SSOT)ドキュメント管理name: librarian
tools: editor,llm

3.2 エージェント権限境界

許可ツールと禁止操作の明確化

エージェント許可ツール禁止操作承認必須項目
Strategy Agentbrowser(読取専用)
llm
analytics-api		git push
生産環境アクセス
財務データ書き込み		OKR変更
戦略方針変更
Flow Optimizergit log/status(読取専用)
analytics
llm		git push -f
ブランチ削除
データ削除		プロセス変更提案
Spec Curatoreditor(仕様ファイルのみ)
llm
mcp_github_issues		コード編集
デプロイ		優先順位大幅変更
Dev Agentseditor
test
llm
git add/commit		git push --force
秘密情報書き込み
スキーマ変更		アーキテクチャ変更
Quality Guardianbash(テスト実行のみ)
test-runner
security-scan		コード修正
マージ		セキュリティ例外承認
Release Coordinatorgit tag
gh release
ci-tools		git push -f
手動デプロイ
ロールバック		本番リリース
Librarianeditor(ドキュメントのみ)
llm
mcp_drive		コード編集
外部公開		-

最小権限の原則

各エージェントには役割に必要最小限の権限のみを付与し、リスクの高い操作は明示的に禁止します。

3.3 エージェント定義例

# .claude/agents/strategy-agent.yml
name: strategy-agent
description: 事業戦略とOKRの管理を担当するエージェント
tools:
  - browser
  - llm
  - analytics-api
system_prompt: |
  あなたは事業戦略を管理するStrategy Agentです。
  週次で以下のタスクを実行してください：
  1. KPIダッシュボードから最新の事業指標を取得
  2. 目標達成状況を分析し、OKRの修正案を作成
  3. ユーザーフィードバックを収集し、価値仮説を検証
  4. 次スプリントの優先順位提案をSpec Curatorに連携
triggers:
  - cron: "0 9 * * MON"  # 毎週月曜9時
  - event: "okr-review-requested"

4. 週次イテレーションサイクル

4.1 標準的な1週間の流れ

曜日・時間アクティビティ担当エージェント人間の関与
月曜 09:00Strategy SyncStrategy AgentOKR承認
月曜 10:00Backlog RefreshSpec Curator-
火-木開発フェーズDev Agents-
継続的品質チェックQuality Guardian-
木曜 17:00Demo & ReviewLibrarian動作確認
金曜 10:00RetrospectiveFlow Optimizer改善承認

4.2 自動化されたワークフロー例

sequenceDiagram
    participant H as Human
    participant SA as Strategy Agent
    participant SC as Spec Curator
    participant DA as Dev Agents
    participant QG as Quality Guardian
    participant RC as Release Coordinator

    Note over SA: 月曜 09:00
    SA->>H: OKR修正案を提示
    H->>SA: 承認
    SA->>SC: 優先順位更新を指示

    Note over SC: 月曜 10:00
    SC->>SC: requirements.md更新
    SC->>SC: tasks.md再生成
    SC->>DA: タスク割当

    Note over DA: 火-木
    loop 開発サイクル
        DA->>DA: コード生成
        DA->>QG: コミット時フック
        QG->>DA: レビュー結果
        DA->>RC: ステージング展開
    end

5. 実装ガイド

5.1 最小構成での開始手順

  1. Spec-Drivenリポジトリの準備

    # Kiroテンプレートを使用（推奨）
kiro init my-project --template=spec-driven

# または手動で作成
mkdir -p .claude/agents
touch requirements.md design.md tasks.md

  2. 初期3体のエージェント定義

    # .claude/agents/minimal-setup.yml
agents:
  - strategy-agent    # 戦略管理
  - spec-curator      # 仕様管理
  - dev-generalist    # 汎用開発

  3. 段階的な拡張基準

  4. Cycle Time > 3日 → flow-optimizerを追加
  5. Defect Rate > 5% → quality-guardianを追加
  6. リリース頻度 > 週2回 → release-coordinatorを追加

5.2 Hookによる品質ゲート実装（強制力あり）

# .claude/hooks/quality-gates.yml
hooks:
  # 書き込み前の強制チェック
  pre-write:
    - name: sensitive-file-protection
      command: |
        # 機密ファイルへの書き込みをブロック
        if [[ "$FILE_PATH" =~ (credentials|secrets|.env) ]]; then
          echo "ERROR: 機密ファイルへの書き込みは禁止されています"
          exit 1
        fi
      blocking: true  # 通らないと進めない

  # 編集後の必須チェック
  post-edit:
    - name: quality-enforcement
      command: |
        # テスト/静的解析/フォーマッタを必須実行
        npm test || exit 1
        eslint . || exit 1
        prettier --check . || exit 1
      blocking: true

  # コミット前の強制ゲート
  pre-git-commit:
    - name: commit-quality-gate
      command: |
        # 署名/規約チェック
        git config --get user.signingkey || exit 1

        # 未解決のTODOチェック
        if grep -r "TODO:" .; then
          echo "ERROR: 未解決のTODOがあります"
          exit 1
        fi

        # 仕様とコードの差分チェック
        claude-agent run librarian --check-sync || exit 1
      blocking: true

  post-merge:
    - name: update-metrics
      command: |
        # メトリクス更新
        claude-agent run flow-optimizer --update-dashboard

品質ゲートの強制力

blocking: true の設定により、これらのチェックを通過しない限り次のステップに進めません。 企業環境ではEnterprise管理ポリシーで一括適用可能です。

5.3 メトリクス設定例（DORA準拠）

# .claude/metrics.yml
metrics:
  # DORAメトリクス
  deployment_frequency:
    target: > 3 per week
    measure: deployments_to_production
    description: "展開頻度 - コードが本番環境にデプロイされる頻度"

  lead_time_for_changes:
    target: < 2 days
    measure: commit_to_deploy_time
    description: "変更リードタイム - コミットから本番展開までの時間"

  change_failure_rate:
    target: < 5%
    measure: failed_deployments / total_deployments
    description: "変更失敗率 - デプロイの失敗率"

  mean_time_to_recovery:
    target: < 1 hour
    measure: incident_to_recovery_time
    description: "MTTR - 障害からの復旧時間"

  # 追加メトリクス
  spec_coverage:
    target: > 95%
    measure: documented_features / total_features
    description: "仕様カバレッジ - ドキュメント化された機能の割合"

# AI導入効果の参考値（DORA Report 2024基準）
ai_impact:
  productivity_improvement: "2.1% (中程度の改善が現実的)"
  note: "AI導入で大幅な効果を得るには、仕事の再設計が必須"

6. 実践的な考察と推奨事項

6.1 このフレームワークの利点

  1. 認知負荷の削減
  2. 人間は戦略的判断のみに集中

  3. 定型作業からの解放

  4. 24/7の開発サイクル

  5. エージェントは休まず作業可能

  6. タイムゾーンに依存しない開発

  7. 一貫性の向上

  8. プロセスの標準化
  9. 属人性の排除

6.2 導入時の課題と対策

課題対策
エージェントの暴走権限を最小限に制限、承認フローの実装
コンテキスト喪失Librarianによる知識の一元管理
品質の不安定性Quality Guardianの段階的強化
チーム文化の変化人間の新しい役割の明確化と教育

6.3 ガバナンスとリスク管理

AIリスク管理フレームワーク（AI RMF/ISO 42001準拠）

# .claude/governance.yml
policies:
  # 人間の承認必須項目（HITLポイント）
  approval_required:
    - production_deployment       # 本番デプロイ
    - okr_changes                # OKR変更
    - architecture_decisions     # アーキテクチャ変更
    - schema_migrations          # スキーマ変更
    - cost_threshold_exceeded    # コスト闾値超過
    - destructive_operations     # 破壊的操作
    - external_api_changes       # 外部API変更

  # エージェント制限
  agent_restrictions:
    dev-agents:
      - no_production_access
      - no_credential_access
      - no_financial_data
    quality-guardian:
      - read_only_code_access
      - no_code_modification

  # 監査証跡と説明責任
  audit_trail:
    - all_agent_actions
    - decision_rationale
    - data_classification
    - third_party_sharing

  # データ分類と取り扱い
  data_classification:
    public: "一般公開可能な情報"
    internal: "社内のみ共有"
    confidential: "機密情報（エージェントアクセス禁止）"

  # コストガード
  cost_management:
    daily_limit: 100  # USD
    alert_threshold: 80  # %
    auto_stop_threshold: 120  # %

    # /cost コマンド相当の可視化
    monitoring:
      command: "/cost"
      schedule: "0 */4 * * *"  # 4時間ごと
      alert_channels: ["slack", "email"]

    # 閾値超過時の自動停止
    auto_actions:
      - threshold: 80%
        action: "alert_only"
      - threshold: 100%
        action: "pause_non_critical"
      - threshold: 120%
        action: "stop_all_agents"

セキュリティ基準の統合（NIST SSDF/SLSA）

# .claude/security.yml
security_framework:
  # NIST SSDF (Secure Software Development Framework)
  ssdf_practices:
    - code_review: "Quality Guardianが全コミットを自動レビュー"
    - vulnerability_scan: "毎日定期スキャン実行"
    - sbom_generation: "リリース時にSBOM自動生成"

  # SLSA (Supply-chain Levels for Software Artifacts)
  slsa_requirements:
    level: 2  # SLSA Level 2相当を目指す
    build_requirements:
      - signed_provenance: true      # プロベナンスに署名
      - isolated_builds: true        # 分離されたビルド環境
      - reproducible_builds: false   # Level 3以上で必要
    release_coordinator_dod:
      - generate_provenance           # プロベナンス生成
      - sign_artifacts                # 成果物への署名
      - verify_dependencies           # 依存関係の検証

6.4 RACI責任分担表（人間↔エージェント）

タスク/活動人間(PO)人間(SM)StrategySpecDevQAReleaseLibrarian
価値仮説策定A/CIRI---I
OKR設定/更新ACRI---I
バックログ管理CIIRI--R
スプリント計画IACRC--I
コード実装---IRC-I
品質保証-I--CRI-
リリースAI--ICRI
プロセス改善CA/RIIIIII
ドキュメント管理--ICIIIR

凡例: R=実行責任 / A=説明責任(承認) / C=相談 / I=情報共有

HITL（Human-in-the-Loop）の重要性

完全自動化ではなく、重要な意思決定ポイントでは必ず人間の承認を経ることで、 リスクを管理しつつAIの利点を最大化します。

6.5 危険変更の型と自動監査

危険変更パターンとHITL条件

# .claude/dangerous-changes.yml
dangerous_patterns:
  # 強制的にHuman-in-the-Loop（HITL）が必要な変更
  schema_changes:
    pattern: "*.sql|migration/*"
    approval: required
    canary_deployment: true

  secret_management:
    pattern: "*secret*|*credential*|*.env"
    approval: required
    audit: enhanced

  destructive_commands:
    pattern: "DROP|DELETE|TRUNCATE|rm -rf"
    approval: required
    dry_run: mandatory

  cost_impacting:
    pattern: "scale|instance_type|replica"
    approval: required_if_cost_increase > 20%

  external_api:
    pattern: "webhook|integration|third_party"
    approval: required
    sandbox_test: mandatory

サプライチェーン自動監査

# .claude/supply-chain-audit.yml
supply_chain_monitoring:
  # OpenSSF Scorecard を週次で自動実行
  scorecard:
    schedule: "0 0 * * SUN"  # 毎週日曜日
    agent: flow-optimizer
    actions:
      - run_scorecard_check
      - compare_with_baseline
      - generate_improvement_tasks

  minimum_scores:
    Maintained: 7
    Code-Review: 8
    Vulnerabilities: 9
    Binary-Artifacts: 10
    Signed-Releases: 8

  # Flow Optimizerの改善対象に自動追加
  auto_improvement:
    enabled: true
    priority: high
    assign_to: spec-curator

7. 将来展望と拡張可能性

7.1 次世代への進化

  • マルチエージェント協調の高度化
  • 自己改善型エージェントの導入
  • ドメイン特化エージェントの追加

7.2 他のツールとの統合

graph LR
    A[Claude Sub-Agents] --> B[GitHub Actions]
    A --> C[Jira/Linear]
    A --> D[Slack/Discord]
    A --> E[Monitoring Tools]
    A --> M[MCP Servers]

    B --> F[Automated Deployment]
    C --> G[Task Tracking]
    D --> H[Team Communication]
    E --> I[Performance Analytics]
    M --> J[External Knowledge]

MCPの活用位置

# .claude/mcp-integration.yml
mcp_servers:
  # Spec CuratorとLibrarianの外部ナレッジ接続
  github_integration:
    server: "@modelcontextprotocol/server-github"
    agents: [spec-curator, librarian]
    purpose: "Issue/PR情報の取得と仕様同期"

  drive_integration:
    server: "@modelcontextprotocol/server-gdrive"
    agents: [librarian, strategy-agent]
    purpose: "設計ドキュメントとOKR資料の管理"

  database_integration:
    server: "@modelcontextprotocol/server-postgres"
    agents: [flow-optimizer]
    purpose: "メトリクスデータベースへのアクセス"

# 文脈再現の標準化
context_restoration:
  spec_curator:
    - fetch_open_issues
    - load_requirements_history
    - sync_with_design_docs

  librarian:
    - load_decision_log
    - fetch_documentation_updates
    - maintain_knowledge_graph

8. まとめ

Claude Sub-Agentを活用したAIエージェント開発チームフレームワークは、従来のスクラム開発を根本的に再定義します。人間が本来注力すべき創造的な意思決定に集中できる環境を実現し、開発効率と品質の両立を可能にします。

導入のポイント

  1. 最小構成から開始：3体のエージェントでスタート
  2. メトリクス駆動：データに基づいた段階的拡張（DORA準拠）
  3. 人間の役割再定義：承認と戦略的判断に特化（HITLポイントの明確化）
  4. 継続的改善：エージェントによる改善提案と人間による最終判断

現実的な期待値設定

AI導入効果の実態

DORA Report 2024によると、AI導入による生産性向上は平均2.1%程度が現実的です。 大幅な効果を得るためには「仕事の再設計」が必須であり、本フレームワークはその再設計の一例です。 過度な期待は避け、段階的な改善を積み重ねることが成功への鍵となります。

このフレームワークは、AI時代の新しい開発文化を形作る重要な一歩となるでしょう。実装を進めながら、コミュニティと共に洗練させていくことが重要です。

参考資料

Claude Code関連

  1. Sub agents - Anthropic Documentation
  2. Hooks Guide - Anthropic Documentation
  3. How I'm Using Claude Code Sub Agents As My Coding Army - Medium
  4. How I Built Scrum Master AI Agent - Medium

セキュリティ・ガバナンス基準

  1. NIST SSDF - Secure Software Development Framework
  2. SLSA - Supply-chain Levels for Software Artifacts
  3. AI Risk Management Framework (AI RMF 1.0) - NIST
  4. ISO/IEC 42001:2023 - AI management systems

メトリクス・パフォーマンス

  1. DORA Report 2024 - Google Cloud
  2. State of DevOps Report 2024
  3. OpenSSF Scorecard

関連ツール

  1. Model Context Protocol - MCP
  2. From Challenges to Clarity: How Amazon Kiro Can Empower Program Managers - LinkedIn