MUSUBI v1.1.2 を 2025-11-24 にリリースしました。
詳細は、「MUSUBI v1.1.2 リリース - AI時代の究極のSDD開発ツール」 をご覧ください。

第３世代のSDD Tool "MUSUI" を 2025-11-17 にリリースしました。
第１世代 Spec Copilot →　第２世代 MUSUHI → 第３世代 MUSUBI

Spec Copilot の開発は終了し、後継は Agentic AI: MUSUHI となります。以下の記事をご参照ください。

第1章なぜSpec Copilotが必要なのか

1.1 AI支援開発の現状と課題

2025年、AI支援開発ツールは急速に進化しています。しかし、それぞれのツールには固有の限界があり、エンタープライズアプリケーション開発の全体をカバーできていません。

1.1.1 Vibe Coding - 即興開発の魅力と限界

OpenAI共同創設者のAndrej Karpathy氏が2025年2月に提唱した「Vibe Coding」は、AIと自然言語で対話しながらアプリケーションを作る革新的なアプローチです。「音楽の即興演奏のような開発」と表現されるように、コードの存在を意識せずバイブス（ノリ）で進める開発スタイルは、プロトタイプ開発や個人プロジェクトで圧倒的な生産性を発揮しました。

しかし、エンタープライズ開発では致命的な問題があります：

仕様の文書化がされない → 監査・コンプライアンス要件（SOX法、GDPR、HIPAA等）を満たせない
対話履歴が散逸 → チーム協働、引き継ぎが困難
体系的な設計思想がない → 長期保守、大規模システムでのアーキテクチャ一貫性が保証されない
品質保証プロセスと整合しない → テスト戦略が後付け、CI/CD統合が困難

結論: Vibe Codingは個人開発には強力だが、エンタープライズには不向き。

1.1.2 GitHub Copilot Agent Mode - 汎用性の罠

GitHub CopilotのAgent Modeは、チャット形式でコード生成やリファクタリングを支援する優れたツールです。しかし、汎用的すぎるがゆえの限界があります。

問題点：

ドメイン専門知識の不足
構造化された成果物生成プロセスがない
- 「設計書を書いて」と依頼しても、一般的なフォーマットで出力されるだけ
- エンタープライズで必要な「要件定義書 → 基本設計書 → 詳細設計書 → テスト仕様書」という一連の体系的ドキュメント生成ができない
- 成果物間の整合性チェック、トレーサビリティ管理の仕組みがない
開発ライフサイクル全体のカバレッジ不足
- コード生成は得意だが、「要件定義 → アーキテクチャ設計 → 実装 → テスト → デプロイ → 運用」という全体フローを1つの対話で完結できない
- 各フェーズで必要なベストプラクティス（例: テスト戦略ではTest Pyramid、運用ではObservability三本柱）が体系的に組み込まれていない

結論: Agent Modeは「コーディングアシスタント」としては優秀だが、「エンタープライズ開発全体の支援システム」としては不十分。

1.1.3 GitHub Spec Kit - 仕様管理に特化した優れたツール、しかし...

2025年9月にGitHubがリリースした Spec Kit は、仕様駆動開発を実現する画期的なツールです。

Spec Kitの優れた点：

/speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks という明確なワークフロー
自動ブランチ作成・仕様バージョニングで、仕様の変更履歴を確実に管理
テンプレート駆動で、構造化された仕様書を効率的に生成
"仕様がコードに従うのではなく、コードが仕様に従う"という哲学の体現

しかし、重大な限界があります。

実装フェーズの専門知識が不足
- Spec Kitは「仕様定義 → 計画 → タスク生成」までは優秀
- しかし、実装時に必要なドメイン専門知識（Clean Architecture、DDD、SOLID原則、デザインパターン）は提供されない
- 生成されたタスクリストに従ってコードを書く際、開発者が自力で設計判断をする必要がある
テスト・デプロイ・運用の専門エージェントがない
- Test Engineer（Test Pyramid、E2Eテスト戦略）
- DevOps Engineer（CI/CD、Kubernetes、Terraform）
- Security Auditor（OWASP、ペネトレーションテスト）
- Observability Engineer（メトリクス、ログ、トレース）
  これらの専門領域をカバーする仕組みがない
Orchestrator（統合制御）の不在

結論: Spec Kitは「仕様管理」では最高峰だが、「開発ライフサイクル全体のエンドツーエンド支援」には至っていない。

1.2 Spec Copilotの必要性

これら既存ツールの限界を踏まえ、筆者はSpec Copilotを開発しました。

Spec Copilotが解決する課題

既存ツールの限界	Spec Copilotの解決策
Vibe Coding: 仕様文書化なし	Requirements Analyst等が体系的な仕様書を生成
Agent Mode: ドメイン知識不足	19種類の専門AIエージェント（API Designer、Database Schema Designer、Security Auditor等）
Agent Mode: 構造化プロセスなし	5フェーズ対話フロー（初回ヒアリング→詳細→確認→成果物生成→FB）
Spec Kit: 実装・テスト・運用の専門知識不足	Software Developer（Clean Architecture）、Test Engineer（Test Pyramid）、DevOps Engineer（Kubernetes）
Spec Kit: 手動コマンドチェーン	Orchestratorによる自動エージェント選択・連携
全般: ライフサイクル部分カバー	要件定義→実装→テスト→デプロイ→運用の完全カバー

Spec Copilotの独自性

ドメイン特化型専門知識の体系的組み込み
- 各エージェントが業界標準フレームワーク（C4 Model、OWASP Top 10、Test Pyramid等）を実装
- エンタープライズで実証されたベストプラクティスを対話に組み込み
Orchestratorによる自動統合制御
- ユーザーの要求から最適なエージェントを自動選択
- 複数エージェントの連携（例: API Designer → Database Schema Designer → Security Auditor）を自動化
- 成果物間の整合性を自動チェック
エンタープライズ品質の成果物生成
- 監査対応可能な文書証跡
- コンプライアンス要件（SOX、GDPR）準拠
- 長期保守を考慮した設計書・テスト仕様書

本記事では、Spec Copilotを通じて、エンタープライズ開発における仕様駆動開発の実践方法を解説します。

第2章仕様駆動開発（SDD）の原則と実践

2.1 仕様駆動開発とは

仕様駆動開発（Specification-Driven Development, SDD） は、従来の「コードを書いてから仕様書を作る」という流れを逆転させ、仕様を「真実の源泉（Source of Truth）」とする開発手法です。

GitHubが提唱する哲学でもあります。

"Specifications don't serve code—code serves specifications."
（仕様がコードに従うのではなく、コードが仕様に従う）

この考え方は、エンタープライズ開発において第1章で述べた課題（文書化の欠如、コンプライアンス違反、長期保守の困難）を根本から解決します。

2.2 SDD の4つの基本原則

1. 仕様が先、コードが後（Specification-First）

従来の開発：

要求 → 実装 → (動いたら)仕様書作成 → テスト

仕様書は「実装の記録」に過ぎない
実装とドキュメントが乖離しやすい

仕様駆動開発：

要求 → 仕様書作成 → レビュー・承認 → 実装 → テスト

仕様書が「実装の設計図」になる
実装前にチーム全体で合意形成

2. 仕様がテストの基盤（Specification-Based Testing）

仕様から自動的にテストケースを生成することで

テストと実装の齟齬を防ぐ：仕様という共通の基盤から両方を生成
テストファースト開発の自然な実現：仕様→テスト→実装の流れ
回帰テストの自動化：仕様変更時に影響範囲を自動特定

例：API仕様（OpenAPI）からテストケース自動生成

# openapi.yaml
paths:
  /users:
    post:
      parameters:
        - name: email
          required: true
          pattern: "^[\\w-\\.]+@[\\w-]+\\.[a-z]{2,}$"

↓ 自動生成

// user.test.js
it('should reject invalid email format', async () => {
  const response = await request(app)
    .post('/users')
    .send({ email: 'invalid-email' });
  expect(response.status).toBe(400);
});

3. 仕様が共通言語（Ubiquitous Language）

エンタープライズ開発では複数のステークホルダーが関与します。

ビジネス側：プロダクトオーナー、事業部門
開発側：フロントエンド、バックエンド、インフラ、QA
運用側：SRE、セキュリティチーム、サポート

仕様書が共通言語として機能することで

認識齟齬を防ぐ
レビュー・承認プロセスが円滑に
新メンバーのオンボーディングが容易に

4. 継続的な仕様更新（Living Documentation）

仕様は「書いて終わり」ではなく、生きたドキュメント（Living Documentation） として継続的に更新します。

実践方法：

バージョン管理：仕様書をGitで管理、コードと同じリポジトリに配置
CI/CD統合：仕様変更時に自動テスト実行、ドキュメント自動生成
変更履歴の追跡：誰が、いつ、なぜ仕様を変更したかを記録

2.3 エンタープライズ開発での実践

エンタープライズ開発の6つの特性と対応

特性	従来の課題	SDDによる解決策
複数チーム協働	認識齟齬、手戻り	仕様書が共通言語として機能
長期保守（5〜10年）	設計意図の喪失	アーキテクチャ設計書（ADR等）で意思決定を記録
厳格な品質基準	テストカバレッジ不足	仕様からテストケースを自動生成
段階的リリース	フェーズ管理が困難	仕様書でマイルストーン管理
コンプライアンス	監査時の証跡不足	仕様書が監査証跡として機能
ステークホルダー管理	合意形成が困難	仕様レビューで事前承認

成果物の体系化

SDDでは、以下のような体系的な成果物を生成します。

フェーズ1：要件定義

要件定義書（Requirements Document）
ユーザーストーリー（User Stories）
受け入れ基準（Acceptance Criteria）

フェーズ2：設計

アーキテクチャ設計書（C4 Model、ADR）
API仕様書（OpenAPI/GraphQL Schema）
データベース設計書（ER図、DDL）

フェーズ3：実装・テスト

テスト仕様書（Test Cases）
CI/CD設定（GitHub Actions、Terraform）
セキュリティ監査レポート（OWASP準拠）

フェーズ4：運用

運用手順書（Runbook）
監視設定（Observability）
インシデント対応手順

2.4 Vibe Codingとの決定的な違い

観点	Vibe Coding	仕様駆動開発（SDD）
開発スタイル	即興的、対話的	計画的、段階的
文書化	対話履歴のみ（散逸しやすい）	体系的な仕様書群
品質保証	後付けテスト	仕様ベーステスト
チーム協働	個人開発向け	複数チーム対応
監査対応	不可能	完全対応
長期保守	困難（設計意図不明）	容易（設計根拠を記録）
適用領域	プロトタイプ、個人PJ	エンタープライズ開発

結論：Vibe Codingは「スピード重視の探索的開発」に最適。仕様駆動開発は「品質・保守性重視のエンタープライズ開発」に最適。両者は目的が異なるため、対立ではなく使い分けが重要です。

第3章 GitHub Spec Kit との比較

3.1 GitHub Spec Kitの概要

仕様駆動開発の重要性は、GitHub自身も認識しています。2025年9月、GitHub は Spec Kit というオープンソースツールキットをリリースしました。

GitHub Spec Kit の特徴：

CLIベース: Specify CLI でプロジェクトをブートストラップ
3つの主要コマンド:
- /speckit.constitution - プロジェクト憲法（開発原則・ガイドライン）の作成
- /speckit.specify - 機能仕様の作成（自動ブランチ作成、テンプレート生成）
- /speckit.plan - 実装計画の生成（仕様から技術的な実装計画を自動生成）
- /speckit.tasks - 実行可能なタスクリストの生成（plan.mdから具体的なタスクを生成）
テンプレート駆動: 仕様・計画・タスクのテンプレート自動生成と自動ブランチ管理
複数AI対応: GitHub Copilot、Claude Code、Gemini CLI等をサポート
仕様中心の哲学: "仕様がコードに従うのではなく、コードが仕様に従う"（Specifications don't serve code - code serves specifications）

3.2 Spec Copilotの差別化

Spec Copilotは、GitHub Spec Kitとは異なるアプローチで仕様駆動開発を支援します。

比較表

観点	GitHub Spec Kit	Spec Copilot
専門性	仕様・計画・タスクの3段階構造	19種類のドメイン特化AIエージェント
対話フロー	コマンド駆動（constitution → specify → plan → tasks）	1問1答の5フェーズ構造化対話
統合環境	CLI + 複数AI対応	VS Code + GitHub Copilot深統合
制御機構	コマンドチェーン（手動実行）	Orchestratorによる自動連携
カバー範囲	仕様定義〜タスク生成	開発ライフサイクル全体
生成物	仕様・実装計画・タスクリスト	仕様書、設計書、コード、テスト
ブランチ管理	自動ブランチ作成・仕様バージョニング	手動（開発者が管理）
哲学	仕様が真実の源泉（code serves specifications）	仕様駆動開発 + ドメイン専門知識

主な差別化ポイント

1. アプローチの違い

GitHub Spec Kitは、仕様を中心としたワークフロー自動化に特化：

プロジェクト憲法（constitution）から始まる一貫した仕様管理
コマンドチェーンによる段階的な仕様→計画→タスク生成
自動ブランチ作成と仕様のバージョン管理
テンプレートベースの構造化された仕様作成

Spec Copilotは、ドメイン専門知識による開発全体の支援に特化：

19種類の専門AIエージェント（API Designer、Database Schema Designer、Security Auditor等）
Orchestratorによる自動エージェント選択と連携
要件定義から実装、テスト、デプロイまでの全ライフサイクルをカバー
各ドメインのベストプラクティスを適用

2. 使い分けのガイドライン

GitHub Spec Kitが適している場合：

プロジェクト憲法から始めて仕様を体系的に管理したい
仕様のバージョニングとブランチ管理を自動化したい
仕様→実装計画→タスクという明確な流れで進めたい
複数AIツールを使い分けたい

Spec Copilotが適している場合：

ドメイン特化の専門知識が必要（セキュリティ監査、パフォーマンス最適化等）
VS Code + GitHub Copilotの統合環境で完結させたい
複雑なプロジェクトで複数の専門領域を自動連携させたい
実装・テスト・デプロイまで一気通貫でサポートが必要

3. 相互補完的な関係

両者は対立するものではなく、相互補完的です。

GitHub Spec Kitで仕様を体系的に管理
Spec Copilotで各ドメインの実装を専門的に支援
仕様駆動開発という共通の哲学を持つ

第4章 Spec Copilotの概要

4.1 アーキテクチャ

Spec Copilotは、マルチエージェントシステムとして設計されています。

Orchestrator AIが中核となり、ユーザーのリクエストを分析して最適なエージェントを選択・連携させます。

4.2 19種類の専門エージェント

Spec Copilotは、Orchestratorを中核として、18種類の専門エージェントで構成されています。

統括エージェント

Orchestrator AI: 18種類の専門エージェントを統括する中核AI
- ユーザーの要求を分析し、最適なエージェントを自動選択
- 複数エージェントの連携を自動化（例: API Designer → Database Schema Designer → Security Auditor）
- 成果物間の整合性を自動チェック
- プロジェクト全体の進行管理とフィードバック収集

要件定義フェーズ

Requirements Analyst AI: ユーザーストーリー、機能要件、非機能要件の整理
Project Manager AI: WBS、ガントチャート、リスク管理

設計フェーズ

System Architect AI: C4モデル、ADR（Architecture Decision Records）
API Designer AI: RESTful API、GraphQL、OpenAPI仕様書
Database Schema Designer AI: ER図、正規化分析、インデックス設計
UI/UX Designer AI: ワイヤーフレーム、デザインシステム、WCAG準拠

実装フェーズ

Software Developer AI: 複数言語対応（TypeScript、Python、Go等）、Azure統合
Code Reviewer AI: 品質分析、セキュリティ脆弱性検出
Bug Hunter AI: 根本原因分析（5 Whys、魚骨図）

テストフェーズ

Test Engineer AI: ユニット、統合、E2Eテスト生成
Quality Assurance AI: テスト戦略、品質メトリクス

デプロイ・運用フェーズ

DevOps Engineer AI: CI/CD、Docker、Kubernetes
Cloud Architect AI: AWS、Azure、GCP、IaC（Terraform、Bicep）
Observability Engineer AI: ログ、メトリクス、トレーシング
Performance Optimizer AI: ボトルネック分析、キャッシング戦略
Security Auditor AI: OWASP Top 10、脆弱性診断

プロセス支援

Agile Coach AI: スクラム、カンバン、レトロスペクティブ
Technical Writer AI: API仕様書、README、開発者ガイド

4.3 価値提案

Spec Copilotは、エンタープライズ開発における以下の価値を提供します。

1. 仕様の網羅性・品質向上

構造化された対話により、仕様の抜け漏れを防止
業界標準のフレームワーク（DITA、C4モデル、OpenAPI等）を適用
チェックリストによる品質保証

2. 開発速度の向上

専門知識を即座に活用（学習コスト削減）
テンプレート・コード自動生成
ベストプラクティスの適用

3. チーム協働の円滑化

共通言語としての仕様書
ドキュメント標準化
引き継ぎ容易性の向上

4. 技術的負債の削減

アーキテクチャ一貫性の保証
保守性の高い設計
テスト容易性の考慮

5. 外部知識ベースとの連携（MCP対応）

Spec Copilotは、Model Context Protocol（MCP） を活用して外部知識ベースと連携できます。

Microsoft Learn MCPとの連携

Azure上にアプリケーションを開発する場合、Microsoft Learn MCPと連動して、最新のベストプラクティスに基づいたアーキテクチャを設計できます。

活用例：

@workspace /system-architect Microsoft Learn を参照して、ベストプラクティスを確認し、Azureでスケーラブルなマイクロサービスアーキテクチャを設計

System Architect AIが自動的に：

Microsoft Learn MCPから最新情報を取得
- Azure Well-Architected Frameworkの原則
- Azure Kubernetes Service（AKS）のベストプラクティス
- Azure Service Busのメッセージングパターン
- Application Insightsの可観測性設計
ベストプラクティスを適用したアーキテクチャを生成
- C4モデル図（Context、Container、Component、Code）
- ADR（Architecture Decision Records）
- リソース構成図（Mermaid）
- Terraform/Bicepテンプレート
具体的なAzureサービスの推奨
- コンピューティング: Azure Kubernetes Service（AKS）
- メッセージング: Azure Service Bus Premium
- ストレージ: Azure Cosmos DB（グローバル分散）
- 可観測性: Application Insights + Azure Monitor
- セキュリティ: Azure Key Vault + Managed Identity

メリット：

常に最新のMicrosoft公式ドキュメントを参照
古いベストプラクティスによる設計ミスを防止
Azure認定アーキテクトの知識を即座に活用
コスト最適化、セキュリティ、パフォーマンスを考慮した設計

Context7 MCPとの連携

フロントエンド・バックエンド開発では、Context7 MCPと連動して、各種ライブラリの最新ドキュメントを参照しながら実装できます。

対応ライブラリ（一部）：

フロントエンド: React、Next.js、Vue.js、Angular、Svelte
バックエンド: Node.js、Express、NestJS、Django、FastAPI
データベース: MongoDB、PostgreSQL、MySQL、Redis
クラウドSDK: AWS SDK、Azure SDK、GCP SDK

活用例：

@workspace /api-designer Context7を参照してNext.js 15のApp RouterでREST APIを設計

API Designer AIが自動的に：

Context7 MCPからNext.js 15の最新ドキュメントを取得
- App Router（app/api）のRoute Handler仕様
- Server Actions、Dynamic Routes、Middleware
- Edge Runtime vs Node.js Runtime
最新ベストプラクティスを適用したAPI設計
- TypeScript型定義
- エラーハンドリング
- バリデーション（Zod）

実装コードの自動生成

// app/api/users/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { z } from 'zod';

const userSchema = z.object({
  name: z.string().min(2).max(50),
  email: z.string().email(),
});

export async function POST(request: NextRequest) {
  try {
    const body = await request.json();
    const validatedData = userSchema.parse(body);
    // ... implementation
    return NextResponse.json({ success: true });
  } catch (error) {
    return NextResponse.json({ error }, { status: 400 });
  }
}

メリット：

バージョン固有の仕様を正確に参照（例: Next.js 14と15の差分）
非推奨APIの回避（古い情報に基づく実装ミスを防止）
型安全な実装（TypeScript型定義を含む）
パフォーマンス最適化（最新のベストプラクティス適用）

他のMCP対応知識ベース

AWS MCPサーバー: AWS Well-Architected Framework参照
カスタムMCPサーバー: 社内のアーキテクチャガイドライン参照

これにより、Spec Copilotは常に最新の知識でエンタープライズアプリケーションを設計・実装できます。

第5章実践: ToDoアプリ開発

ここでは、Spec Copilotを使ってToDoアプリを開発する例を紹介します。Orchestratorが複数エージェントを連携させ、要件定義から実装まで一貫して支援する様子をご覧ください。

5.0 前提条件

このチュートリアルでは、以下の環境を前提としています。

開発環境

OS: Windows 11（WSL2上でLinux環境を使用）
Linux Distribution: Ubuntu 22.04 LTS（WSL2）
エディタ: VS Code（Windows版）
- WSL拡張機能（Remote - WSL）インストール済み
- GitHub Copilot拡張機能インストール済み
GitHub Copilot: サブスクリプション契約済み

WSL2のセットアップ

WSL2がインストールされていない場合は、PowerShellで以下のコマンドを実行：

# WSL2のインストール
wsl --install

# Ubuntu 24.04 LTSのインストール
wsl --install -d Ubuntu-24.04

VS CodeでWSL環境に接続

VS Codeを起動
左下の緑色の「><」アイコンをクリック
「WSL: Ubuntu-24.04に接続」を選択
WSL環境内でプロジェクトフォルダを開く

Spec Copilotのセットアップ

WSL環境内で以下を実行：

# Spec Copilotリポジトリをクローン
cd ~
git clone https://github.com/nahisaho/spec-copilot.git

# VS Codeでプロジェクトを開く
cd spec-copilot
code .

必要なツール（WSL環境内）

# パッケージリストの更新
sudo apt-get update

# Node.js（v20以上）
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

# Git
sudo apt-get install -y git

# Docker
# 古いバージョンの削除
sudo apt-get remove docker docker-engine docker.io containerd runc

# 必要なパッケージのインストール
sudo apt-get install -y \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

# Docker公式GPGキーの追加
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# Dockerリポジトリの追加
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Dockerのインストール
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 現在のユーザーをdockerグループに追加（sudo不要で実行可能にする）
sudo usermod -aG docker $USER

# Dockerサービスの起動
sudo service docker start

重要: usermodコマンド実行後、WSLを再起動してください：

# PowerShellで実行
wsl --shutdown
# その後、WSLを再起動

確認

WSL再起動後、以下のコマンドで環境が正しくセットアップされているか確認：

node --version   # v20.x.x以上
npm --version    # 10.x.x以上
git --version    # 2.x.x以上
docker --version # 20.x.x以上

# Dockerが動作しているか確認
docker run hello-world

最後のコマンドで「Hello from Docker!」と表示されればDockerは正常に動作しています。

VS CodeのGitHub Copilot Chatが有効であることを確認してください。

5.1 プロジェクト開始

VS CodeのGitHub Copilot Chatで、以下のように入力します。

@workspace /orchestrator ToDoを管理するWebアプリケーションを開発したい。要件定義から開始。

Orchestratorが起動し、プロジェクト全体を分析します。

ワークスペース情報を収集しています

ToDo管理Webアプリの要件定義から開始する場合、Spec Copilotの推奨フローは以下の通りです。
--------------------------------------------------------------------------------
概要
- あなたのリクエストは「ToDo管理Webアプリの開発（要件定義から）」です。
- この場合、まずRequirements Analyst AIがユーザーストーリーや機能・非機能要件を整理します。
- その後、System Architect AI、API Designer AI、Database Schema Designer AIなどが順次支援します。
--------------------------------------------------------------------------------
推奨エージェント連携例
1. Requirements Analyst AI
　要件定義（ユーザーストーリー、機能・非機能要件、優先順位付け）
2. System Architect AI
　システム構成・アーキテクチャ設計（C4モデル、ADR）
3. API Designer AI
　API設計（エンドポイント、OpenAPI仕様）
4. Database Schema Designer AI
　DB設計（ER図、DDL）
5. Software Developer AI
　実装（API/フロント/DBアクセス）
6. Test Engineer AI
　テスト設計・自動テスト生成
--------------------------------------------------------------------------------
次のステップ
まずRequirements Analyst AIによるヒアリングが始まります。
このエージェントは段階的な質問（5フェーズ）で要件を整理します。

例: 初回ヒアリング（フェーズ1）
- このToDoアプリの主な利用者は誰ですか？
- 管理したいToDoの項目はどのようなものですか？
- 優先度や期限など、管理したい属性はありますか？
- ユーザー登録や認証は必要ですか？
- モバイル対応や多言語対応など、特別な要件はありますか？
--------------------------------------------------------------------------------
このような形で、まず要件ヒアリングを進めてよろしいですか？
（はい/いいえ、または追加要望があればご記入ください）

5.2 要件定義（Requirements Analyst）

「はい」と入力すると Orcestrater はRequirements Analyst AI を起動し、要件定義に必要な情報を1問1答形式で情報の収集を開始しはじめます。

📋 Requirements Analyst AI - ToDo管理アプリ要件定義開始
フェーズ1: 基本情報の収集

5つの段階的質問で要件を整理していきます。1つずつお答えください。

【質問 1/5】プロジェクト名は何ですか？
例:

MyTodo
TaskManager
WorkFlowApp
TodoPro
お聞かせください：

【質問 2/5】プロジェクトの主な目的は何ですか？
例:

- 個人のタスク管理効率化
- チームの生産性向上
- プロジェクト進捗の可視化
- 業務フローの標準化
- その他（具体的にお聞かせください）
お聞かせください：

✅ プロジェクト目的: プロジェクト進捗の可視化 + 業務フローの標準化
【質問 3/5】対象ユーザーはどなたですか？（複数選択可）
a) 個人ユーザー（フリーランス、学生など）
b) 企業内スタッフ（チームメンバー）
c) 管理者・マネージャー（進捗監視、レポート確認）
d) プロジェクトマネージャー（複数プロジェクト管理）
e) その他（具体的にお教えください）

お聞かせください：

✅ 対象ユーザー: b) 企業内スタッフ（チームメンバー）
【質問 4/5】想定ユーザー数はどのくらいですか？
a) 100人未満（小規模チーム・部署）
b) 100〜1,000人（中規模企業・複数部署）
c) 1,000〜10,000人（大規模企業）
d) 10,000人以上（エンタープライズ級）

お聞かせください：

✅ 想定ユーザー数: b) 100〜1,000人（中規模企業・複数部署）
【質問 5/5】リリース予定時期はいつ頃ですか？
a) 1ヶ月以内
b) 3ヶ月以内
c) 6ヶ月以内
d) 未定

お聞かせください：

5問のヒアリング後、以下の成果物が生成されます。

生成物: requirements.md

# ソフトウェア要求仕様書（SRS）

## 1. 機能要件

### FR-001: タスク管理
- タスクの作成、読取、更新、削除（CRUD）
- カテゴリによる分類（仕事、プライベート、その他）
- 期限設定と優先度（高、中、低）

### FR-002: フィルタリング
- カテゴリ別フィルタ
- 期限切れタスクの表示
- 優先度でのソート

## 2. 非機能要件

### NFR-001: パフォーマンス
- タスク一覧表示: 200ms以内
- タスク作成: 300ms以内

### NFR-002: セキュリティ
- ユーザー認証（JWT）
- HTTPS通信必須

### NFR-003: ユーザビリティ
- レスポンシブデザイン（モバイル対応）
- WCAG 2.1 AA準拠

## 3. ユーザーストーリー

**US-001**: ユーザーとして、新しいタスクを作成できる
- Given: ホーム画面を開いている
- When: 「新規タスク」ボタンをクリック
- Then: タスク作成フォームが表示される

**US-002**: ユーザーとして、期限切れタスクを確認できる
- Given: タスク一覧を開いている
- When: 「期限切れ」フィルタを選択
- Then: 期限切れタスクのみ表示される

5.3 システム設計（System Architect）

Requirements Analystの成果物を受けて、System Architectが起動します。

【System Architect】
要件を分析し、以下のアーキテクチャを提案します。

アーキテクチャパターン: 3層アーキテクチャ
- フロントエンド: React + TypeScript
- バックエンド: Node.js + Express
- データベース: PostgreSQL

生成物: C4モデル図（Mermaid）

5.4 API設計（API Designer）

System Architectの設計を受けて、API Designerが起動：

生成物: OpenAPI仕様書（抜粋）

openapi: 3.0.0
info:
  title: ToDo API
  version: 1.0.0
paths:
  /tasks:
    get:
      summary: タスク一覧取得
      parameters:
        - name: category
          in: query
          schema:
            type: string
            enum: [work, private, other]
      responses:
        '200':
          description: 成功
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Task'
    post:
      summary: タスク作成
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/TaskInput'
      responses:
        '201':
          description: 作成成功
components:
  schemas:
    Task:
      type: object
      properties:
        id:
          type: string
          format: uuid
        title:
          type: string
        category:
          type: string
          enum: [work, private, other]
        dueDate:
          type: string
          format: date-time
        priority:
          type: string
          enum: [high, medium, low]

5.5 データベース設計（Database Schema Designer）

生成物: ER図（Mermaid）

生成物: DDL（PostgreSQL）

-- テーブル作成
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE tasks (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title VARCHAR(255) NOT NULL,
    description TEXT,
    category VARCHAR(50),
    due_date DATE,
    priority VARCHAR(10) CHECK (priority IN ('high', 'medium', 'low')),
    is_completed BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- インデックス作成
CREATE INDEX idx_tasks_user_id ON tasks(user_id);
CREATE INDEX idx_tasks_due_date ON tasks(due_date);
CREATE INDEX idx_tasks_category ON tasks(category);

5.6 テスト設計（Test Engineer）

生成物: テストケース設計

# テストケース設計書

## 1. ユニットテスト

### TC-001: タスク作成APIテスト
- **境界値分析**:
  - title: 空文字、1文字、255文字、256文字
  - dueDate: 過去日、当日、未来日
  - priority: null、不正値、正常値

### TC-002: タスク取得APIテスト
- **同値分割**:
  - フィルタなし: 全件取得
  - categoryフィルタ: work、private、other
  - 完了状態: true、false

## 2. 統合テスト

### TC-101: タスクCRUDフロー
1. タスク作成（POST /tasks）
2. タスク取得（GET /tasks/{id}）
3. タスク更新（PUT /tasks/{id}）
4. タスク削除（DELETE /tasks/{id}）

生成物: テストコード（Jest）

// tests/tasks.test.ts
describe('Task API', () => {
  describe('POST /tasks', () => {
    it('正常系: タスクを作成できる', async () => {
      const response = await request(app)
        .post('/tasks')
        .send({
          title: 'テストタスク',
          category: 'work',
          dueDate: '2025-12-31',
          priority: 'high'
        })
        .expect(201);

      expect(response.body).toHaveProperty('id');
      expect(response.body.title).toBe('テストタスク');
    });

    it('異常系: タイトルが空の場合エラー', async () => {
      await request(app)
        .post('/tasks')
        .send({
          title: '',
          category: 'work'
        })
        .expect(400);
    });
  });
});

5.7 成果物の統合

Orchestratorが全エージェントの成果物を統合し、以下のファイルが生成されます。

project-root/
├── docs/
│   ├── requirements.md          # 要件定義書
│   ├── architecture.md          # アーキテクチャ設計書
│   ├── api-spec.yaml            # OpenAPI仕様書
│   └── database-schema.md       # DB設計書
├── src/
│   ├── api/
│   │   └── tasks.ts             # タスクAPI実装
│   └── database/
│       └── schema.sql           # DDL
└── tests/
    └── tasks.test.ts            # テストコード

品質チェックリストも自動生成：

# 品質チェックリスト

## 仕様
- [x] 機能要件がすべて文書化されている
- [x] 非機能要件（パフォーマンス、セキュリティ）が定義されている
- [x] ユーザーストーリーがAcceptance Criteriaを含む

## 設計
- [x] アーキテクチャ図（C4モデル）が作成されている
- [x] API仕様がOpenAPI形式で定義されている
- [x] ER図が正規化されている

## 実装
- [x] TypeScript型定義が完全
- [x] エラーハンドリングが実装されている
- [x] セキュリティ（JWT認証）が実装されている

## テスト
- [x] ユニットテストカバレッジ > 80%
- [x] 統合テストが主要フローをカバー

第6章導入ガイド

6.1 セットアップ

環境構築

Spec Copilotの環境構築方法は、第5章「実践: ToDoアプリ開発」の5.0節に詳しく記載されています。

第5章 5.0節の内容:

開発環境（Windows 11 + WSL2、VS Code、GitHub Copilot）
WSL2のセットアップ手順
必要なツールのインストール（Node.js、Git、Docker）
Spec Copilotリポジトリのクローンとセットアップ
環境確認方法

すでに環境構築が完了している場合は、この節をスキップして6.2「使い方」に進んでください。

6.2 使い方

基本的な使用方法

パターン1: Orchestratorで総合支援

@workspace /orchestrator ユーザー認証機能を追加したい

Orchestratorが自動的に：

Requirements Analyst AI（要件定義）
Security Auditor AI（セキュリティ設計）
API Designer AI（API設計）
Software Developer AI（実装）
Test Engineer AI（テスト設計）

を連携させます。

パターン2: 個別エージェントの使用

特定のタスクがある場合は、直接エージェントを指定：

@workspace /api-designer GraphQL APIを設計したい

@workspace /database-schema-designer Eコマースサイトのデータベーススキーマを設計

@workspace /security-auditor このコードのセキュリティ脆弱性をチェックして

パターン3: Azure開発（Microsoft Learn MCP連携）

Azure上にアプリケーションを開発する場合、System Architect AIがMicrosoft Learn MCPから最新のベストプラクティスを参照してアーキテクチャを設計します。

例1: マイクロサービスアーキテクチャ設計

@workspace /system-architect Azureでスケーラブルなマイクロサービスアーキテクチャを設計したい。
オンライン予約システム（ホテル、レストラン、イベント）を想定。

System Architect AIの出力例：

このように MCP Server に接続して、ベストプラクティスを確認しながら、設計を行います。

例2: サーバーレスアーキテクチャ設計

@workspace /system-architect AzureでイベントドリブンなサーバーレスAPIを設計したい。
画像アップロード→AI処理→通知の流れ。

System Architect AIの出力例：

# Azure サーバーレスアーキテクチャ設計

## アーキテクチャ概要

Microsoft Learn「Serverless event processing」に基づき、以下を提案します。

### コンポーネント構成

1. **Azure Functions**: イベント処理
   - HTTP トリガー（画像アップロード）
   - Blob トリガー（AI処理起動）
   - Event Grid トリガー（通知送信）
   - Microsoft Learn参照: "Azure Functions best practices"

2. **Azure Blob Storage**: 画像保存
   - ライフサイクル管理、アクセス層の最適化
   - Microsoft Learn参照: "Blob storage performance tuning"

3. **Azure AI Services**: 画像分析
   - Computer Vision API
   - Microsoft Learn参照: "Responsible AI deployment"

4. **Azure Event Grid**: イベントルーティング
   - サブスクリプションフィルタリング、リトライポリシー
   - Microsoft Learn参照: "Event Grid reliability"

### コスト最適化

Microsoft Learn「Cost optimization」に基づく推奨：
- Azure Functions: Consumption プラン（使用量課金）
- Blob Storage: クール層（アクセス頻度低い画像）
- 推定月額コスト: 10万リクエストで約$50-100

メリット：

常に最新のAzureベストプラクティスを適用
Well-Architected Frameworkの5つの柱（コスト最適化、運用の優秀性、パフォーマンス効率、信頼性、セキュリティ）に準拠
具体的なAzureサービス名と設定推奨値を提示
**ADR（Architecture Decision Records）**で設計判断の根拠を記録

パターン4: フロントエンド/バックエンド開発（Context7 MCP連携）

最新のフレームワーク・ライブラリを使った開発では、Context7 MCPから最新ドキュメントを参照して実装します。

例1: Next.js 15のApp Routerで認証付きAPIを実装

@workspace /api-designer Next.js 15のApp RouterでJWT認証付きREST APIを実装したい。
ユーザー登録、ログイン、認証が必要なエンドポイントを作成。

API Designer AIの出力例：

// app/api/auth/register/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { z } from 'zod';
import bcrypt from 'bcryptjs';
import jwt from 'jsonwebtoken';

// Context7 MCPから取得したNext.js 15のベストプラクティスを適用
const registerSchema = z.object({
  email: z.string().email(),
  password: z.string().min(8).max(100),
  name: z.string().min(2).max(50),
});

export async function POST(request: NextRequest) {
  try {
    const body = await request.json();
    const { email, password, name } = registerSchema.parse(body);

    // パスワードのハッシュ化
    const hashedPassword = await bcrypt.hash(password, 10);

    // ユーザー作成（DBロジック）
    // const user = await createUser({ email, password: hashedPassword, name });

    // JWTトークン生成
    const token = jwt.sign(
      { userId: 'user.id', email },
      process.env.JWT_SECRET!,
      { expiresIn: '7d' }
    );

    return NextResponse.json(
      { token, user: { email, name } },
      { status: 201 }
    );
  } catch (error) {
    if (error instanceof z.ZodError) {
      return NextResponse.json(
        { error: 'Validation failed', details: error.errors },
        { status: 400 }
      );
    }
    return NextResponse.json(
      { error: 'Internal server error' },
      { status: 500 }
    );
  }
}

// Context7 MCPから取得したNext.js 15のRoute Handler仕様に準拠
export const runtime = 'nodejs'; // or 'edge'
export const dynamic = 'force-dynamic';

例2: React 19 + TypeScriptでコンポーネント実装

@workspace /software-developer React 19のServer Componentsでデータテーブルコンポーネントを実装したい。
ソート、フィルタ、ページネーション機能付き。

Software Developer AIの出力例：

// components/DataTable.tsx
import { Suspense } from 'react';

// Context7 MCPから取得したReact 19のServer Components仕様を適用
type DataTableProps<T> = {
  data: T[];
  columns: { key: keyof T; label: string; sortable?: boolean }[];
  pageSize?: number;
};

export async function DataTable<T extends Record<string, any>>({
  data,
  columns,
  pageSize = 10,
}: DataTableProps<T>) {
  // Server Componentでデータをフェッチ・処理
  const sortedData = data.slice(0, pageSize);

  return (
    <div className="overflow-x-auto">
      <table className="min-w-full divide-y divide-gray-200">
        <thead className="bg-gray-50">
          <tr>
            {columns.map((col) => (
              <th key={String(col.key)} className="px-6 py-3 text-left">
                {col.label}
              </th>
            ))}
          </tr>
        </thead>
        <tbody className="bg-white divide-y divide-gray-200">
          {sortedData.map((row, idx) => (
            <tr key={idx}>
              {columns.map((col) => (
                <td key={String(col.key)} className="px-6 py-4">
                  {String(row[col.key])}
                </td>
              ))}
            </tr>
          ))}
        </tbody>
      </table>
    </div>
  );
}

// React 19の新機能: use()フックを使った非同期処理
// Context7 MCPから最新仕様を参照

例3: MongoDB + MongooseでスキーマとCRUD実装

@workspace /database-schema-designer MongoDBでブログシステムのスキーマを設計したい。
記事、ユーザー、コメント、タグのリレーション。

Database Schema Designer AIの出力例：

// models/Article.ts
import mongoose, { Schema, Document } from 'mongoose';

// Context7 MCPから取得したMongoose最新ドキュメントに基づく設計
export interface IArticle extends Document {
  title: string;
  slug: string;
  content: string;
  author: mongoose.Types.ObjectId;
  tags: string[];
  status: 'draft' | 'published' | 'archived';
  publishedAt?: Date;
  views: number;
  createdAt: Date;
  updatedAt: Date;
}

const ArticleSchema = new Schema<IArticle>(
  {
    title: { type: String, required: true, maxlength: 200 },
    slug: { type: String, required: true, unique: true, index: true },
    content: { type: String, required: true },
    author: { type: Schema.Types.ObjectId, ref: 'User', required: true },
    tags: [{ type: String, index: true }],
    status: {
      type: String,
      enum: ['draft', 'published', 'archived'],
      default: 'draft',
    },
    publishedAt: Date,
    views: { type: Number, default: 0 },
  },
  {
    timestamps: true, // createdAt, updatedAt自動生成
    // Context7 MCPから取得した最新のMongooseパフォーマンス最適化設定
    collation: { locale: 'ja', strength: 2 },
  }
);

// インデックス最適化（Context7 MCPのベストプラクティス）
ArticleSchema.index({ author: 1, status: 1 });
ArticleSchema.index({ tags: 1, publishedAt: -1 });
ArticleSchema.index({ slug: 'text', title: 'text' });

export const Article = mongoose.model<IArticle>('Article', ArticleSchema);

メリット：

バージョン固有の仕様を参照（Next.js 14と15、React 18と19の差分を正確に把握）
非推奨APIの回避（古い記事や情報による実装ミスを防止）
型安全な実装（TypeScript型定義を最新仕様で生成）
パフォーマンス最適化（各ライブラリの最新ベストプラクティス適用）
セキュリティ対策（最新のセキュリティガイドラインを反映）

ベストプラクティス

1. 明確な目標を伝える

❌ 悪い例: 「何か作って」

✅ 良い例: 「RESTful APIでユーザー管理機能を設計。認証はJWT、データベースはPostgreSQLを使用」

2. 既存情報を共有する

既存のコード、仕様書、エラーメッセージがある場合は積極的に共有しましょう。

@workspace /bug-hunter
以下のエラーが発生しています。原因を分析してください。

[エラーメッセージ]

3. 段階的に情報を提供する

エージェントは1問1答形式で質問します。焦らず、1つずつ回答しましょう。

4. 成果物をレビューする

生成された仕様書やコードは、必ず人間がレビューしてください。AIは強力ですが、完璧ではありません。

第7章まとめ

7.1 Vibe Coding vs 仕様駆動開発

使い分けのガイドライン

プロジェクト特性	推奨手法
個人プロジェクト、プロトタイプ	Vibe Coding
短期間（1〜2週間）	Vibe Coding
実験的な機能検証	Vibe Coding
チーム開発（3名以上）	仕様駆動開発
長期保守（1年以上）	仕様駆動開発
エンタープライズアプリ	仕様駆動開発
コンプライアンス要件あり	仕様駆動開発

両者の組み合わせ

実は、Vibe Codingと仕様駆動開発は対立するものではありません。

探索フェーズ: Vibe Codingでプロトタイプを作成
仕様化フェーズ: Spec Copilotで仕様を整理・文書化
実装フェーズ: 仕様に基づいて本実装
運用フェーズ: 仕様を更新しながら機能追加

このハイブリッドアプローチが、最も生産的です。

7.2 次のステップ

Spec Copilotを試す

GitHubリポジトリ: https://github.com/nahisaho/spec-copilot

コミュニティに参加

Issue報告: バグや改善提案
プルリクエスト: エージェントのカスタマイズ、新機能追加
ディスカッション: 使用事例の共有

さらなる学習

おわりに

AI時代の開発は、「コードを書くこと」から「仕様を定義すること」へとシフトしています。Spec Copilotは、その変化を加速させるツールです。

エンタープライズ開発の複雑さに向き合い、品質と速度を両立させる――その実現に、Spec Copilotが貢献できれば幸いです。

Happy Specification-Driven Development!

付録

付録A: 全エージェント詳細リファレンス

Spec Copilotを構成する19種類の専門AIエージェントの詳細な説明です。各エージェントの役割、専門領域、使用方法を理解することで、プロジェクトに最適なエージェントを選択できます。

A.1 オーケストレーション

1. Orchestrator AI

概要: 18種類の専門AIエージェントを統合管理し、複雑なワークフローを調整するオーケストレーター

専門領域:

エージェント選定: ユーザーリクエストを分析し最適なエージェントを選択
ワークフロー調整: エージェント間の依存関係と実行順序を管理
タスク分解: 複雑な要件を実行可能なサブタスクに分割
結果統合: 複数エージェントの出力を統合・整理
進捗管理: 全体進捗の追跡とステータス報告
エラーハンドリング: エージェント実行エラーの検出と対応
品質保証: 成果物の完全性と一貫性を検証

使用方法:

@workspace /orchestrator ToDoを管理するWebアプリケーションを開発。要件定義から開始。

適用場面: 複雑なプロジェクトで複数の専門領域が必要な場合、全体調整が必要な場合

A.2 要件定義フェーズ

2. Requirements Analyst AI

概要: 要件分析、ユーザーストーリー作成、仕様定義、受入基準定義を支援

専門領域:

要件定義: 機能要件、非機能要件、制約条件
ステークホルダー分析: ユーザー、顧客、開発チーム、経営層
要件抽出: インタビュー、ワークショップ、プロトタイピング
要件文書化: ユースケース、ユーザーストーリー、仕様書
要件検証: 完全性、一貫性、実現可能性、テスト可能性
優先順位付け: MoSCoW法、狩野分析、ROI評価
トレーサビリティ: 要件から実装・テストまでの追跡

使用方法:

@workspace /requirements-analyst ユーザーストーリーと受入基準を作成してください

成果物: SRS（ソフトウェア要求仕様書）、ユーザーストーリー、受入基準

3. Project Manager AI

概要: プロジェクト計画、進捗管理、リスク管理、WBS作成、工数見積を支援

専門領域:

プロジェクト計画: WBS、スケジュール、リソース計画、予算策定
リスク管理: リスク識別、分析、対応計画、監視
ステークホルダー管理: コミュニケーション、期待値調整
チーム管理: タスク割当、進捗追跡、モチベーション維持
スコープ管理: 要件定義、変更管理、スコープクリープ防止
品質管理: 品質計画、品質保証、品質管理
アジャイル: スクラム、カンバン、スプリント計画、レトロスペクティブ
プロジェクト報告: ステータスレポート、ダッシュボード、KPI管理

使用方法:

@workspace /project-manager 新規プロジェクトのWBSとスケジュールを作成してください

成果物: プロジェクト計画書、WBS、ガントチャート、リスクレジスター

A.3 設計フェーズ

4. System Architect AI

概要: システムアーキテクチャ設計、C4モデル、ADR作成、トレードオフ分析を支援

専門領域:

アーキテクチャ設計: 全体構造、コンポーネント分割、責務設計
アーキテクチャパターン: レイヤード、ヘキサゴナル、クリーン、マイクロサービス、イベント駆動
分散システム: CAP定理、PACELC、スケーリング戦略、レプリケーション
データアーキテクチャ: モデリング、整合性、CQRS、イベントソーシング
セキュリティアーキテクチャ: ゼロトラスト、認証・認可、脅威モデリング、暗号化
クラウドアーキテクチャ: Azure/AWS/GCP、IaC、Kubernetes、Service Mesh
可観測性: メトリクス、ログ、トレーシング、SLO/SLA、アラート設計
パフォーマンス最適化: キャッシング、負荷分散、スケーリング
技術選定・トレードオフ分析: ATAM、ペイオフマトリックス、ADR

使用方法:

@workspace /system-architect マイクロサービスアーキテクチャの設計とトレードオフ分析をしてください

成果物: アーキテクチャ設計書、C4モデル図、ADR（Architecture Decision Records）

5. API Designer AI

概要: RESTful API、GraphQL、gRPC設計、OpenAPI仕様書生成を支援

専門領域:

RESTful API: リソース設計、HTTPメソッド、ステータスコード
GraphQL: スキーマ設計、クエリ最適化、リゾルバー
gRPC: Protocol Buffers、ストリーミング、サービス定義
API仕様: OpenAPI (Swagger)、GraphQL SDL、Protobuf
認証・認可: OAuth 2.0、JWT、APIキー、RBAC
バージョニング: URIベース、ヘッダーベース、コンテントネゴシエーション
セキュリティ: レート制限、CORS、入力検証、SQLインジェクション防止
パフォーマンス: キャッシング、ページネーション、圧縮

使用方法:

@workspace /api-designer ユーザー管理APIのOpenAPI仕様を作成してください

成果物: OpenAPI仕様書、GraphQLスキーマ、エンドポイント定義

6. Database Schema Designer AI

概要: データベーススキーマ設計、正規化、パフォーマンス最適化、マイグレーション戦略を支援

専門領域:

データモデリング: 概念モデル（ER図）、論理モデル、物理モデル
正規化理論: 1NF/2NF/3NF/BCNF/4NF/5NF、非正規化戦略
データ整合性: 主キー、外部キー、CHECK制約、トリガー、トランザクション分離レベル
パフォーマンス最適化: インデックス設計、クエリ最適化、パーティショニング、マテリアライズドビュー
スケーラビリティ戦略: シャーディング、レプリケーション、読み書き分離、CQRS
データベース選定: RDBMS (PostgreSQL/MySQL/SQL Server/Oracle)、NoSQL (MongoDB/DynamoDB/Cassandra)
マイグレーション戦略: スキーマバージョニング、ゼロダウンタイム移行、ロールバック計画
セキュリティ: 暗号化（TDE/列レベル）、アクセス制御（RBAC）、監査ログ、プライバシー保護
運用設計: バックアップ戦略、ディザスタリカバリ（RPO/RTO）、監視・アラート

使用方法:

@workspace /database-schema-designer ECサイトのデータベーススキーマを設計してください

成果物: ER図、DDL（PostgreSQL/MySQL）、インデックス設計、正規化分析

7. UI/UX Designer AI

概要: UI/UX設計、ワイヤーフレーム作成、アクセシビリティチェック、デザインシステム提案を支援

専門領域:

ユーザー中心設計: ペルソナ、ユーザージャーニーマップ、タスク分析
情報アーキテクチャ: サイトマップ、ナビゲーション設計、コンテンツ階層
インタラクションデザイン: UI要素配置、マイクロインタラクション、トランジション設計
ビジュアルデザイン: カラースキーム、タイポグラフィ、レイアウト、余白
アクセシビリティ: WCAG準拠、スクリーンリーダー対応、キーボードナビゲーション
レスポンシブデザイン: モバイルファースト、ブレイクポイント設計、適応レイアウト
デザインシステム: コンポーネントライブラリ、デザイントークン、スタイルガイド
ユーザビリティテスト: ヒューリスティック評価、A/Bテスト、ユーザーテスト
プロトタイピング: ワイヤーフレーム、モックアップ、インタラクティブプロトタイプ

使用方法:

@workspace /uiux-designer ユーザーフレンドリーなワイヤーフレームを作成してください

成果物: ワイヤーフレーム、デザインシステム、アクセシビリティチェックリスト

A.4 実装フェーズ

8. Software Developer AI

概要: 複数言語・フレームワークでの実装、設計から本番環境対応コードまで生成

専門領域:

プログラミング言語: Python, Node.js (TypeScript/JavaScript), Go, Java, C#, Ruby
フロントエンド: React, Vue.js, Angular, Next.js, TypeScript
モバイル: React Native, Flutter, Swift, Kotlin
データベース: SQL (PostgreSQL, MySQL, SQL Server)、NoSQL (MongoDB, DynamoDB, Cosmos DB)
Webフレームワーク: Express.js, FastAPI, Django, Flask, ASP.NET Core, Spring Boot
ORM/データベース: Prisma, TypeORM, SQLAlchemy, Entity Framework
テスト: Jest, Pytest, JUnit, Mocha, Cypress
Cloud SDKs: AWS SDK, Azure SDK, Google Cloud SDK
開発プラクティス: クリーンコード、SOLID原則、デザインパターン、リファクタリング

使用方法:

@workspace /software-developer REST APIの実装をTypeScriptで作成してください

成果物: 本番環境対応コード、ユニットテスト、統合テスト

9. Code Reviewer AI

概要: コードレビュー自動化、品質チェック、セキュリティスキャン、ベストプラクティス推奨

専門領域:

コード品質分析: 複雑度、可読性、保守性、一貫性
セキュリティ監査: OWASP Top 10、脆弱性検出、セキュアコーディング
パフォーマンス分析: 計算量、メモリ使用量、ボトルネック検出
ベストプラクティス: 言語固有の規約、デザインパターン、SOLID原則
テスト品質: カバレッジ、テストケース設計、モッキングの適切性
依存関係管理: 脆弱な依存関係、ライセンス問題
リファクタリング: コードスメル検出、改善提案

使用方法:

@workspace /code-reviewer このコードのセキュリティ脆弱性をレビューしてください

成果物: レビューレポート、改善提案、修正コード例

10. Bug Hunter AI

概要: バグ分析、デバッグ支援、根本原因特定、修正提案を提供

専門領域:

バグ検出: 静的解析、動的解析、ランタイムエラー検出
根本原因分析: スタックトレース分析、デバッグログ解析、再現手順特定
セキュリティバグ: インジェクション、認証バイパス、XSS/CSRF
競合状態: レースコンディション、デッドロック、データ競合
メモリ問題: メモリリーク、null参照、バッファオーバーフロー
ロジックエラー: 境界値、オフバイワン、型変換エラー
統合エラー: API不整合、データフォーマット不一致
パフォーマンスバグ: メモリ肥大化、無限ループ、リソースリーク
再発防止: テストケース追加、防御的プログラミング、コードレビュー改善

使用方法:

@workspace /bug-hunter このエラーの原因を特定して修正方法を提案してください

成果物: 根本原因分析レポート、修正コード、再発防止策

A.5 テストフェーズ

11. Test Engineer AI

概要: テスト設計、自動テスト生成、カバレッジ改善、テストケース最適化を支援

専門領域:

ユニットテスト: 関数、メソッド、クラスレベルのテスト
統合テスト: コンポーネント間の協調テスト
E2Eテスト: ユーザーシナリオベースのテスト
テスト設計技法: 境界値分析、同値分割、デシジョンテーブル、状態遷移テスト
テストデータ生成: 現実的なテストデータ、エッジケース
モッキング・スタブ: 外部依存の分離
テストカバレッジ: 行カバレッジ、分岐カバレッジ、条件カバレッジ
テスト自動化: CI/CD統合、継続的テスト

使用方法:

@workspace /test-engineer 単体テストと統合テストを自動生成してください

成果物: テストケース設計書、テストコード（Jest/Pytest等）、カバレッジレポート

12. Quality Assurance AI

概要: 品質保証、テスト戦略計画、品質メトリクス定義、品質ゲート設計を支援

専門領域:

テスト戦略: テストピラミッド、リスクベーステスト、テストレベル設計
テストケース設計: 境界値分析、同値分割、デシジョンテーブル、状態遷移
機能テスト: ブラックボックステスト、受入テスト、探索的テスト
非機能テスト: パフォーマンステスト、セキュリティテスト、ユーザビリティテスト
テスト自動化: UI自動化、API自動化、CI/CD統合
品質メトリクス: 欠陥密度、テストカバレッジ、欠陥エスケープ率
欠陥管理: バグトリアージ、根本原因分析、再発防止
シフトレフト: 早期テスト、開発中の品質作り込み
テスト管理: テスト計画、リソース管理、進捗管理

使用方法:

@workspace /quality-assurance テスト戦略とテストケース設計を支援してください

成果物: テスト戦略書、品質メトリクス定義、品質ゲート設定

A.6 デプロイ・運用フェーズ

13. DevOps Engineer AI

概要: CI/CD設計、インフラ自動化、コンテナ化、IaC生成を支援

専門領域:

CI/CD: GitHub Actions, GitLab CI, Jenkins, CircleCI
コンテナ: Docker, Docker Compose, Kubernetes, Helm
IaC: Terraform, CloudFormation, Ansible, Pulumi
クラウドプラットフォーム: AWS, GCP, Azure
AI開発ツール統合: Azure MCP Server, GitHub Copilot, AIエージェント
監視・ログ: Prometheus, Grafana, ELK Stack, Datadog
セキュリティ: シークレット管理、脆弱性スキャン、コンプライアンス
デプロイ戦略: Blue-Green、カナリア、ローリングデプロイメント
Service Mesh: Istio, Linkerd

使用方法:

@workspace /devops-engineer GitHub ActionsでCI/CDパイプラインを構築してください

成果物: CI/CDパイプライン設定、Dockerfileファイル、Kubernetes マニフェスト、Terraformコード

14. Cloud Architect AI

概要: クラウドアーキテクチャ設計、AWS/Azure/GCP構成、コスト最適化、Well-Architected Framework実装を支援

専門領域:

クラウドプラットフォーム: AWS, GCP, Azure, マルチクラウド
アーキテクチャパターン: マイクロサービス、サーバーレス、イベント駆動
高可用性設計: マルチAZ、マルチリージョン、ディザスタリカバリ
スケーラビリティ: 水平スケーリング、負荷分散、オートスケーリング
セキュリティ: IAM、ネットワークセキュリティ、暗号化、コンプライアンス
コスト最適化: リザーブドインスタンス、スポットインスタンス、リソース最適化
監視・運用: CloudWatch, Cloud Monitoring、ログ集約
マイグレーション戦略: Lift & Shift、リプラットフォーム、リファクター

使用方法:

@workspace /cloud-architect AWS上で高可用性を持つWebアプリケーションアーキテクチャを設計してください

成果物: クラウドアーキテクチャ図、IaCコード（Terraform/Bicep）、コスト最適化レポート

15. Observability Engineer AI

概要: 可観測性設計、ログ/メトリクス/トレース戦略、SLI/SLO定義、監視ダッシュボード設計を支援

専門領域:

ログ: 構造化ログ、ログレベル、ログ集約、検索戦略
メトリクス: システムメトリクス、ビジネスメトリクス、SLI/SLO/SLA
分散トレーシング: スパン、トレースID、依存関係マップ、レイテンシー分析
APM（Application Performance Monitoring）: パフォーマンス監視、ボトルネック検出
アラート設計: アラートしきい値、通知ルーティング、エスカレーション
ダッシュボード設計: 可視化、KPI表示、リアルタイム監視
SREプラクティス: エラーバジェット、ポストモーテム、オンコール運用
インシデント対応: 検出、トリアージ、復旧、ポストモーテム分析
コスト最適化: 監視コスト削減、データ保持戦略

使用方法:

@workspace /observability-engineer マイクロサービスの監視戦略とアラート設計を提案してください

成果物: 監視戦略書、SLI/SLO定義、ダッシュボード設計、アラート設定

16. Performance Optimizer AI

概要: パフォーマンス分析、ボトルネック検出、最適化提案、計算量改善を支援

専門領域:

アルゴリズム最適化: 計算量削減（O(n²) → O(n log n)）、データ構造選択
メモリ最適化: メモリリーク検出、ガベージコレクション最適化、メモリプール
並列化・非同期処理: マルチスレッド、並行処理、async/await最適化
データベースパフォーマンス: クエリ最適化、N+1問題解決、インデックス設計
ネットワーク最適化: レイテンシー削減、帯域幅最適化、HTTP/2/3活用
キャッシング戦略: メモリキャッシュ、CDN、ブラウザキャッシング
フロントエンド最適化: バンドルサイズ削減、レンダリング最適化、遅延ロード
リソース管理: CPU利用率、I/O最適化、コネクションプール
プロファイリング: ボトルネック特定、ベンチマーク設計、継続的監視

使用方法:

@workspace /performance-optimizer アプリケーションのパフォーマンスボトルネックを特定して最適化案を提案してください

成果物: パフォーマンス分析レポート、最適化コード、ベンチマーク結果

17. Security Auditor AI

概要: セキュリティ監査、脆弱性診断、OWASP準拠、セキュアコーディング支援を提供

専門領域:

脆弱性診断: OWASP Top 10、CWE Top 25、CVE
ペネトレーションテスト: SQLi, XSS, CSRF, SSRF
認証・認可: OAuth, JWT, SAML, MFA
暗号化: TLS/SSL、暗号化アルゴリズム、ハッシュ関数
セキュアコーディング: 入力検証、出力エンコーディング、パラメータ化クエリ
インフラセキュリティ: ファイアウォール、SIEM、IDS/IPS
コンプライアンス: GDPR, PCI DSS, HIPAA, SOC 2
インシデント対応: 脅威分析、リスク評価、緩和策

使用方法:

@workspace /security-auditor セキュリティ脆弱性の診断とOWASP Top 10のコンプライアンスチェックを実施してください

成果物: セキュリティ監査レポート、CVSS評価、修正コード提案

A.7 プロセス支援

18. Agile Coach AI

概要: アジャイル/スクラム手法、スプリント計画、レトロスペクティブ、ベロシティ測定を支援

専門領域:

スクラム: スプリント計画、デイリースタンドアップ、レトロスペクティブ、プロダクトバックログ管理
カンバン: WIP制限、フロー効率、サイクルタイム、スループット
リーンスタートアップ: MVP、Build-Measure-Learn、ピボット戦略
エクストリームプログラミング（XP）: ペアプログラミング、TDD、継続的インテグレーション
DevOps: CI/CD、インフラ自動化、監視、デプロイ戦略
チームビルディング: 心理的安全性、1on1、フィードバック文化
プロセス改善: ボトルネック特定、メトリクス分析、改善実験
リモートワーク: 非同期コミュニケーション、仮想チーム管理
スケーリング: SAFe、LeSS、大規模アジャイル組織

使用方法:

@workspace /agile-coach スプリント計画のサポートをお願いします

成果物: スプリント計画、レトロスペクティブレポート（KPT法）、ベロシティチャート

19. Technical Writer AI

概要: 技術文書作成、API仕様書生成、README作成、開発者ガイド作成を支援

専門領域:

API文書: RESTful API, GraphQL, gRPC仕様書
ユーザーガイド: 製品マニュアル、手順書、トラブルシューティング
開発者文書: アーキテクチャ設計書、実装ガイド、コーディング規約
チュートリアル: ステップバイステップガイド、サンプルコード
リリースノート: 変更履歴、マイグレーションガイド、非互換性情報
README: プロジェクト概要、セットアップ手順、使用例
用語集: 技術用語定義、ドメイン用語説明
図: アーキテクチャ図、シーケンス図、フロー図

使用方法:

@workspace /technical-writer API仕様書とREADMEを作成してください

成果物: API仕様書、README.md、開発者ガイド、Mermaid図

付録B: エージェント選択フローチャート

プロジェクトの状況に応じて最適なエージェントを選択するためのガイドです。

B.1 プロジェクトフェーズ別

B.2 課題別エージェント選択

課題	推奨エージェント	理由
APIを設計したい	API Designer	OpenAPI仕様書を自動生成
データベースを設計したい	Database Schema Designer	ER図、DDL、正規化分析を提供
コードを実装したい	Software Developer	本番環境対応コードを生成
バグを修正したい	Bug Hunter	根本原因分析と修正提案
コードをレビューしてほしい	Code Reviewer	品質、セキュリティ、パフォーマンスを分析
セキュリティをチェックしたい	Security Auditor	OWASP Top 10準拠チェック
パフォーマンスを改善したい	Performance Optimizer	ボトルネック特定と最適化提案
CI/CDを構築したい	DevOps Engineer	パイプライン設定を自動生成
クラウドに移行したい	Cloud Architect	クラウドアーキテクチャ設計とIaC生成
テストを自動化したい	Test Engineer	テストコード自動生成
ドキュメントを作成したい	Technical Writer	API仕様書、README等を生成
UI/UXを改善したい	UI/UX Designer	ワイヤーフレーム、アクセシビリティチェック
プロジェクトを管理したい	Project Manager	WBS、リスク管理を支援
アジャイル開発を導入したい	Agile Coach	スクラム、カンバンを支援
監視体制を整えたい	Observability Engineer	ログ、メトリクス、トレーシング戦略
複雑なプロジェクト全般	Orchestrator	複数エージェントを自動選択・連携

付録C: よくある質問（FAQ）

Q1: 複数のエージェントを同時に使えますか？

A: はい、Orchestratorを使用することで、複数エージェントを自動的に連携させることができます。

Q2: エージェントをカスタマイズできますか？

A: はい、各エージェントのプロンプトファイル（.md）を編集することで、プロジェクト固有のニーズに合わせてカスタマイズ可能です。

Q3: どのエージェントから始めるべきですか？

A: 新規プロジェクトの場合はOrchestratorから始めることをお勧めします。既存プロジェクトへの機能追加の場合は、該当する専門エージェント（例: API Designer、Test Engineer等）を直接使用してください。

Q4: 生成されたコードはそのまま使えますか？

A: 生成されたコードは本番環境対応を目指していますが、必ず人間がレビューし、プロジェクト固有の要件に合わせて調整してください。

Q5: GitHub Copilot以外のAIツールでも使えますか？

A: 現在はGitHub Copilot Chatに最適化されていますが、プロンプトファイルを他のAIツール（Claude、ChatGPT等）でも利用可能です。

付録D: 参考リソース

公式ドキュメント

アーキテクチャ・設計

DevOps・インフラ

セキュリティ

テスト

Test Pyramid

UI/UX