Agentic AI：MUSUHIによる仕様駆動開発 - プロジェクトに生命を吹き込む

Last updated at 2025-11-14Posted at 2025-11-12

利用方法についてはMUSUHI実践ガイド - Agentic AIで実現する仕様駆動開発の実践 をご参照ください。

1. はじめに

AIコーディング時代の課題

2024年、GitHub Copilot、Claude Code、Cursor、GeminiといったAIコーディングツールが急速に普及し、ソフトウェア開発のスタイルは大きく変化しました。開発者はAIと対話しながら、驚くべき速度でコードを生成できるようになりました。

しかし、この「Vibe Coding」とも呼ばれる直感的なコーディングスタイルには課題もあります。

一貫性の欠如: セッションごとにコンテキストが失われ、アーキテクチャパターンが統一されない
品質の不安定性: 体系的なテストやレビューが不足し、本番環境での問題が後から発覚
チーム開発の困難さ: 個人の「感覚」に依存したコーディングは、チーム間での引継ぎが難しい
長期保守の問題: ドキュメントが不足し、数ヶ月後に自分が書いたコードすら理解できない

これらの課題は、特に大規模プロジェクトや本番環境のシステムでは致命的です。

「むすひ(産霊)」という名前に込めた想い

本記事で紹介する「MUSUHI」は、これらの課題を解決するための仕様駆動開発(Specification Driven Development: SDD)用のAgentic AIです。

Agentic AI（エージェンティックAI）とは、人間が高レベルの目標を与えると、その目標を達成するために必要なタスクを自律的に計画し、適切なツールや専門エージェントを選択・実行し、環境からのフィードバックを受けながら問題解決を進めるAIシステムです。

従来のAIとの違い：

従来のAI	Agentic AI（MUSUHI）
人間が各ステップを詳細に指示	高レベルの目標のみで自律動作
単一タスクの実行	複数タスクを計画・調整・実行
静的な応答	環境に適応し、動的に問題解決

MUSUHIは、複数の専門AIエージェント（Requirements Analyst、System Architect、API Designerなど）を統括するOrchestratorが、ユーザーの要求に応じて最適なエージェントを呼び出し、対話を設計し、段階的に仕様駆動開発を進めます。

「むすひ」の由来:

「むすひ」とは、神道における観念で、天地・万物を生成・発展・完成させる霊的な働きのことです。産霊、産巣日、産日、産魂などの字が宛てられます。

「むす(産)」: 「うむす(産むす)」の「う」が取れたもので、自然に発生するという意味
「ひ(霊)」: 霊的・神秘的な働き

神道においては、万物は「むすひ」の働きによって生じ、発展すると考えます。

MUSUHIツールは、この「むすひ」のように、あなたのプロジェクトに生命を吹き込み、自然に成長させ、完成へと導く存在となることを目指しています。

本記事の目的と対象読者

本記事では、以下の内容を紹介します。

Agentic AIとは何か - MUSUHIを理解するための基礎概念
仕様駆動開発(SDD)とは何か - なぜAI時代に重要なのか
Vibe Codingとの違いと使い分け - 即興 vs 体系的開発
現在利用可能なSDD支援ツールの概観 - 既存ツールの現状
spec-copilotとその課題 - 筆者の前作の限界
MUSUHIの特徴 - Agentic AIによる自律的な開発支援
MUSUHIの実践的な動作フロー - OrchestratorとRequirements Analystの連携

対象読者:

Agentic AIに興味があり、実践的な活用例を知りたい方
AIコーディングツールを使っているが、品質や一貫性に課題を感じている開発者
チーム開発で体系的なワークフローを導入したいリーダー
Vibe Codingから一歩進んだ開発手法を学びたい方
仕様駆動開発(SDD)に興味がある方

それでは、まずMUSUHIの基盤となるAgentic AIの概念から見ていきましょう。

2. Agentic AI（エージェンティックAI）とは何か？

2.1 Agentic AIの定義

Agentic AI（エージェンティックAI） は、従来の質問応答型AIを超えた、自律的に行動するAIシステムです。

人間が高レベルの目標（例：「ECサイトを作りたい」）を与えると、そのAIは、

目標を分析し、達成に必要なタスクを自律的に計画
適切なツールやエージェントを選択して実行
環境からのフィードバックを受けながら計画を調整
最終目標を達成するまで反復的に問題解決

これが、Agentic AIの本質です。

2.2 従来のAIとの根本的な違い

観点	従来のAI	Agentic AI
入力	詳細な指示が必要「要件定義書を作成して」「API設計書を作成して」「実装して」	高レベルの目標のみ「ECサイトを作りたい」
処理	単一タスクを実行指示された通りに動作	複数タスクを自律的に計画・調整・実行目標達成のための手段を自分で考える
出力	静的な応答 1つの質問に1つの回答	動的な問題解決必要に応じて複数の成果物を生成
エラー対応	エラーが発生したら停止人間の介入が必要	フィードバックを受けて自律的に修正代替手段を試行
タスク連携	人間がタスク間を繋ぐ	自動的にタスクを連携

2.3 Agentic AIの5つの主要特性

1. 自律性（Autonomy）

明示的な指示なしに、目標達成のための行動を計画・実行します。

例:

ユーザー: 「タスク管理アプリを作りたい」

従来のAI:
「どのような機能が必要ですか？」
→ ユーザーが全て指示する必要がある

Agentic AI:
「タスク管理アプリですね。まず要件を整理するため、
以下を順番に進めます：
1. 要件定義（ユーザー管理、タスクCRUD、認証など）
2. アーキテクチャ設計
3. API設計
4. DB設計
5. 実装

それでは要件定義から始めます。プロジェクトの種類は？」
→ 全体の流れを自律的に計画

2. 目標指向（Goal-Oriented）

与えられた高レベルの目標を理解し、それを達成可能なサブタスクに分解します。

例:

目標: 「認証機能を持つAPIを作りたい」

Agentic AIの思考プロセス:
① 認証機能 = ユーザー登録、ログイン、トークン管理が必要
② API = REST/GraphQL、エンドポイント設計、エラー処理が必要
③ セキュリティ = パスワードハッシュ、JWT、レート制限が必要

↓ サブタスクに分解

タスク1: 要件定義（認証方式、トークン有効期限など）
タスク2: API設計（POST /register, POST /login など）
タスク3: セキュリティ設計（bcrypt, JWT秘密鍵管理など）
タスク4: 実装
タスク5: テスト

3. ツール使用能力（Tool Use）

API、データベース、外部システムなどのツールを自律的に選択・活用します。

MUSUHIの場合:

複数の専門エージェント（Requirements Analyst、System Architect等）
ファイル読み書き
コード実行・テスト
ドキュメント生成

必要に応じてこれらのツールを組み合わせて使用します。

4. 環境との相互作用（Environmental Interaction）

外部環境から情報を収集し、行動の結果をフィードバックとして活用します。

例:

Agentic AI: 「API設計書を生成しました」
↓
ユーザー: 「認証エンドポイントが足りない」
↓
Agentic AI:
- フィードバックを分析
- 認証エンドポイント（/login, /register, /refresh）を追加
- 関連するDB設計も自動更新（usersテーブルに必要な列を追加）
- セキュリティ設計も自動更新（パスワードハッシュ、トークン管理を追加）

5. 意思決定（Decision Making）

状況に応じて次のアクションを自律的に判断します。

例:

状況: ユーザーが「モバイルアプリを作りたい」と言った

Agentic AIの判断:
- モバイルアプリ = iOS/Android
- プラットフォームの選択が必要
- クロスプラットフォーム vs ネイティブの判断が必要
- バックエンドAPIも必要になる可能性が高い

↓ 最適な質問を自動生成

「対象プラットフォームは？
a) iOS のみ
b) Android のみ
c) 両方（クロスプラットフォーム: React Native / Flutter）
d) 両方（ネイティブ開発）」

2.4 なぜ今、Agentic AIなのか？

AI技術の成熟

大規模言語モデル（LLM）の進化により、複雑な推論とタスク計画が可能になりました。

GPT-4、Claude 3.5等: 複雑な文脈理解、多段階推論
Function Calling: AIがツールを呼び出せる
長いコンテキスト: プロジェクト全体を記憶

ソフトウェア開発の複雑化

現代のソフトウェア開発は、ますます複雑になっています。

マイクロサービス、API、データベース、認証、デプロイ...
開発者が全てを把握するのは困難
専門家の知識を自動化する必要性

開発スピードの要求

市場の変化が速く、迅速な開発が求められます。

プロトタイプから本番まで、短期間で開発
品質を犠牲にせず、スピードを上げる
自動化と体系化が鍵

2.5 MUSUHIにおけるAgentic AIの実装

MUSUHIは、Agentic AIの5つの特性を全て実装しています。

1. 自律性:

Orchestratorが全体の開発フローを自律的に計画
ユーザーは「何を作りたいか」を伝えるだけ

2. 目標指向:

高レベルの目標（「ECサイトを作りたい」）を、実行可能なタスクに分解
要件定義 → 設計 → 実装 → テストの流れを自動構築

3. ツール使用:

19種類の専門エージェント（Requirements Analyst、System Architect等）
各エージェントが専門知識とベストプラクティスを持つ
必要に応じてエージェントを組み合わせて実行

4. 環境との相互作用:

ユーザーとの対話で要件を収集
生成した仕様書をユーザーに確認
フィードバックを受けて自動修正

5. 意思決定:

プロジェクトの種類に応じて最適なエージェントを選択
並列実行可能なタスクは同時実行
依存関係があるタスクは適切な順序で実行

次章では、このAgentic AIが支える「仕様駆動開発（SDD）」について詳しく見ていきます。

3. 仕様駆動開発(Specification Driven Development: SDD)とは何か？

3.1 SDDの定義と背景

仕様駆動開発(Specification Driven Development: SDD) は、詳細な仕様書が開発プロセス全体を導く体系的なアプローチです。

従来の開発手法との位置づけを整理しましょう。

手法	特徴	適用場面
ウォーターフォール	厳格な段階分割、変更困難	要件が明確で変更が少ないプロジェクト
アジャイル	反復開発、柔軟な変更対応	要件が流動的なプロジェクト
SDD	仕様ファースト、トレーサビリティ重視	AI時代の品質重視プロジェクト
Vibe Coding	直感的、対話的	プロトタイピング、個人開発

SDDは、ウォーターフォールの体系性とアジャイルの柔軟性を組み合わせ、さらにAI時代の新しい要素を加えた手法です。

AI時代における仕様の重要性

なぜ今、仕様駆動開発なのでしょうか？

AIコーディングの特性:

AIは「指示通り」にコードを生成する
曖昧な指示は曖昧な結果を生む
セッション間でコンテキストが失われる

仕様の役割:

AIへの「明確な指示書」として機能
プロジェクトの「記憶」として永続化
チーム間の「共通言語」として機能

つまり、AIが高速にコードを生成できる時代だからこそ、何を作るべきかを明確に定義する仕様の重要性が増しているのです。

3.2 SDDの8段階ワークフロー

MUSUHIが実装するSDDワークフローは、以下の8段階で構成されます。

調査 → 要件定義 → 設計 → タスク化 → 実装 → テスト → デプロイ → 監視

各段階を詳しく見ていきましょう。

Stage 1: 調査(Research)

目的: 技術的選択肢の分析、実現可能性の検証
成果物: research.md(調査ドキュメント)
内容:
- 調査質問と方法論
- 選択肢の長所・短所分析
- 比較マトリックス
- 推奨事項と根拠
- リスク評価

Stage 2: 要件定義(Requirements)

目的: システムが「何をすべきか」を明確化
成果物: requirements.md(要件定義書)
担当エージェント: Requirements Analyst
内容:
- EARS形式の機能要件
- 非機能要件(パフォーマンス、セキュリティ、スケーラビリティ)
- ユーザーストーリーと受入基準
- 要件トレーサビリティマトリックス
- MoSCoW優先順位付け

品質ゲート: すべての要件がEARS形式で記述され、ステークホルダーに承認されていること

Stage 3: 設計(Design)

目的: システムを「どのように構築するか」を定義
成果物: design.md(設計ドキュメント)
担当エージェント: System Architect
内容:
- アーキテクチャパターン選択(根拠付き)
- C4モデル図(Context、Container、Component)
- EARSマッピング付きコンポーネント仕様
- API設計、データベーススキーマ、セキュリティ設計
- 主要フローのシーケンス図
- 技術スタックの整合性確認

品質ゲート: すべての要件が設計にマップされ、steering/と整合していること

Stage 4: タスク化(Tasks)

目的: 設計を実行可能な実装タスクに分解
成果物: tasks.md(タスクドキュメント)
担当エージェント: Project Manager、Software Developer
内容:
- フェーズベースのタスク構成(依存関係付き)
- 各タスク: 説明、EARSベースの受入基準、サブタスク、要件マッピング、設計参照
- 要件カバレッジマトリックス(100%カバレッジ保証)
- チーム割当とタイムライン(ガントチャート)
- 完了の定義(Definition of Done)チェックリスト

品質ゲート: すべての要件がタスクにマップされ、依存関係が明確であること

Stage 5: 実装(Implementation)

目的: タスクに従ってコードを実装
担当エージェント: Software Developer
実施内容:
- タスクごとの実装
- コードコメントでの要件ID参照
- ユニットテストの作成
- コードレビュー

品質ゲート: コードレビュー合格、80%以上のテストカバレッジ、クリティカルバグなし

Stage 6: テスト(Testing)

目的: EARS要件が満たされているか検証
担当エージェント: Test Engineer
実施内容:
- EARS要件からテストケース生成
- ユニット、統合、E2Eテストの実行
- カバレッジ分析
- バグ修正

品質ゲート: すべてのEARS要件がテスト済み、すべてのテストが合格

Stage 7: デプロイ(Deployment)

目的: 本番環境へのリリース
担当エージェント: DevOps Engineer
実施内容:
- CI/CDパイプライン実行
- ステージング環境でのテスト
- 本番環境へのデプロイ
- ロールバック計画の準備

品質ゲート: ステージングデプロイ成功、監視設定完了

Stage 8: 監視(Monitoring)

目的: 本番環境の健全性確認
担当エージェント: Performance Optimizer、DevOps Engineer
実施内容:
- パフォーマンスメトリクス監視
- エラー率の追跡
- ユーザーフィードバックの収集
- 継続的改善

3.3 SDDの特徴

SDDの本質的な特徴を3つの観点から見ていきましょう。

完全なトレーサビリティ

SDDでは、要件からコード、テストまで、すべてが双方向にトレース可能です。

要件(REQ-001) ↔ 設計(Component X) ↔ タスク(Task 2.3) ↔ コード(ファイル:行) ↔ テスト(test_xxx)

具体例:

REQ-001: WHEN user clicks "Submit", System SHALL validate form
  ↓
design.md: FormValidator component (Section 4.2)
  ↓
tasks.md: Task 2.3 "Implement form validation"
  ↓
src/validators/FormValidator.ts:25
  ↓
tests/FormValidator.test.ts:test_submit_validation()

このトレーサビリティにより

要件変更時の影響範囲が即座に分かる
テストカバレッジが視覚的に確認できる
なぜこのコードが存在するのか、根拠が明確

EARS形式による検証可能な要件定義

EARS(Easy Approach to Requirements Syntax)は、曖昧性を排除した要件記述形式です。

5つのパターン:

Event-Driven(イベント駆動)
```
WHEN [trigger event], the [system] SHALL [response]
```
例: WHEN user clicks "Login", the Auth System SHALL validate credentials
State-Driven(状態駆動)
```
WHILE [state], the [system] SHALL [response]
```
例: WHILE payment is processing, the UI SHALL display loading spinner
Unwanted Behavior(望ましくない動作)
```
IF [error condition], THEN the [system] SHALL [response]
```
例: IF network fails, THEN the App SHALL show "Connection error" message
Optional Features(オプション機能)
```
WHERE [feature enabled], the [system] SHALL [response]
```
例: WHERE dark mode is enabled, the UI SHALL use dark color scheme
Ubiquitous(遍在的)
```
The [system] SHALL [response]
```
例: The Auth Service SHALL encrypt passwords using bcrypt cost factor 12

EARS形式のメリット:

✅ テスト可能性: 各要件が自動テストに変換できる
✅ 明確性: 「〜すべき」「〜かもしれない」といった曖昧な表現を排除
✅ トレーサビリティ: 要件からテストケースへの1:1マッピング
✅ 一貫性: すべての要件で標準化された形式

曖昧な要件 vs EARS形式の比較:

❌ 曖昧な要件:

- ユーザーはタスクを作成できる
- エラーが発生したら適切に処理する
- システムは高速である必要がある

✅ EARS形式:

REQ-001: WHEN user submits task with title and description,
         the System SHALL create task within 200ms

REQ-002: IF database connection fails,
         THEN the System SHALL return HTTP 503 with retry-after header

REQ-003: The Task List API SHALL respond within 100ms for up to 1000 tasks

ドキュメント駆動の開発プロセス

SDDでは、ドキュメントが「副産物」ではなく「主成果物」です。

従来の開発:

コード実装 → (余裕があれば)ドキュメント作成

結果: ドキュメントが古い、存在しない、コードと矛盾

SDD:

仕様書作成 → 仕様からコード生成 → ドキュメントと実装が常に同期

結果: ドキュメントが常に最新、AIへの指示としても機能

ドキュメントファースト開発の利点:

実装前に設計の矛盾を発見
チーム間のコミュニケーションが明確化
新メンバーのオンボーディングが容易
長期保守が可能

4. Vibe Codingとの違い

4.1 Vibe Codingとは

「Vibe Coding」とは、AIコーディングツールとの対話を通じて、直感的・即興的にコードを生成するスタイルです。

典型的なVibe Codingセッション:

開発者: 「ユーザー認証機能を作って」
AI: [コード生成]
開発者: 「あ、パスワード強度チェックも追加して」
AI: [コード修正]
開発者: 「いい感じ！これでOK」

Vibe Codingの特徴:

💬 自然言語での対話的なコーディング
⚡ 高速なプロトタイピング
🎨 創造的で柔軟なアプローチ
🧠 開発者の「感覚」に依存

4.2 SDDとの対比

SDDとVibe Codingは、対立するものではなく、それぞれ異なる強みを持っています。

観点	Vibe Coding	SDD
アプローチ	即興性、直感性	体系性、計画性
スピード	初期は非常に高速	初期は時間がかかる、後半で加速
ドキュメント	最小限、後付け	ファースト、常に最新
品質	変動が大きい	一貫して高い
チーム開発	個人の感覚に依存	標準化されたプロセス
長期保守	困難(コンテキスト喪失)	容易(トレーサビリティ)
適用規模	小規模、プロトタイプ	中〜大規模、本番システム
学習コスト	低い	中程度

体系性 vs 即興性

Vibe Coding(即興性):

その場その場で考えながら進める
柔軟に方向転換できる
試行錯誤が容易

SDD(体系性):

事前に全体像を設計
計画的に段階を進める
変更は仕様書から反映

ドキュメントの有無と役割

Vibe Coding:

ドキュメントは「余裕があれば作る」もの
コードが唯一の情報源
数ヶ月後に「なぜこう書いたか」が不明

SDD:

ドキュメントが開発の起点
仕様書→設計書→コードの順で作成
なぜこうなったかの根拠が常に明確

大規模プロジェクトにおける適用性

小規模プロジェクト(1-2人、1-2週間):

Vibe Codingが有利
オーバーヘッドが少ない
素早いイテレーション

大規模プロジェクト(5人以上、数ヶ月以上):

SDDが有利
チーム間の整合性が保たれる
長期的な保守性が高い

4.3 使い分けと併用

Vibe CodingとSDDは、プロジェクトのフェーズや性質に応じて使い分けるべきです。

プロトタイプ: Vibe Coding

適用場面:

アイデア検証フェーズ
UI/UXのモックアップ作成
技術的な実現可能性の確認
ハッカソンやPoC(Proof of Concept)

理由:

高速な試行錯誤が必要
仕様が流動的
完全性よりもスピード優先

例:

開発者: 「ToDoアプリのプロトタイプを作りたい」
        「まずは基本機能だけで動くものを見たい」

→ Vibe Codingで30分でプロトタイプ完成
→ ステークホルダーに見せて方向性確認

本番システム: SDD

適用場面:

本番環境にデプロイするシステム
複数人で開発するプロジェクト
長期運用が必要なシステム
品質・セキュリティが重要なシステム

理由:

品質の一貫性が必要
チーム間の整合性が必要
長期的な保守性が必要
トレーサビリティが必要

例:

開発チーム: 「プロトタイプが承認された」
            「本番システムとして作り直そう」

→ SDDワークフローで開発開始:
  1. Requirements Analystで要件定義(EARS形式)
  2. System Architectで設計
  3. Software Developerで実装
  4. Test Engineerでテスト
  5. DevOps Engineerでデプロイ

ハイブリッドアプローチの可能性

最も効果的なのは、両者を組み合わせるアプローチです。

フェーズ1: Vibe Codingでプロトタイプ

1-2週間で動くものを作る
ステークホルダーにデモ
フィードバック収集

フェーズ2: SDDで本番化

プロトタイプで得た知見を仕様書に落とし込む
体系的に設計・実装
品質を担保しながら本番リリース

フェーズ3: 運用中の新機能

小さな改善: Vibe Codingで素早く
大きな機能追加: SDDワークフローで慎重に

具体例:

週1: Vibe Codingでプロトタイプ作成
週2-3: ステークホルダーレビュー、要件定義(SDD)
週4-6: 設計・実装(SDD)
週7: テスト・デプロイ(SDD)
運用フェーズ: 小修正はVibe、大機能はSDD

このハイブリッドアプローチにより、スピードと品質の両立が可能になります。

5. 現在利用できるSDD支援ツール

仕様駆動開発を支援するツールは、近年急速に増えています。ここでは主要なツールを紹介します。

5.1 GitHub Spec Kit

GitHub公式のオープンソースツールキットです。

概要:

Open-source toolkit for AI-powered spec-driven workflows
GitHubエコシステムとの深い統合

主な機能:

CLI tool(specify-cli): 仕様の作成と管理をコマンドラインから実行
AIエージェント統合: GitHub Copilot、Claude、Geminiとシームレスに連携
実行可能な成果物生成: 仕様から実行可能なコードや設定ファイルを自動生成

ワークフロー:

# 仕様の作成
specify-cli create feature-spec.md

# AIエージェントによる実装生成
specify-cli generate --agent github-copilot

# 仕様と実装の同期確認
specify-cli validate

適用場面:

GitHubを中心とした開発フロー
CI/CDとの統合が必要なプロジェクト

参考リンク:

GitHub: github.com/github/spec-kit
公式サイト: speckit.org
ブログ記事: github.blog/spec-driven-development

5.2 Spec Kit(speckit.org)

仕様を実行可能にすることに焦点を当てたフレームワークです。

コンセプト:
「Specifications as Executable Artifacts」
仕様書そのものが実行可能であるべき、という哲学

ワークフロー:

1. Write specs(仕様を書く)
   ↓
2. Generate technical plans(技術計画を生成)
   ↓
3. Implement automatically(自動実装)

特徴:

複数のAIエージェントをサポート
仕様からテストケースを自動生成
仕様の変更が即座に実装に反映

適用場面:

仕様が頻繁に変更されるプロジェクト
複数のターゲット環境へのデプロイ

5.3 Kiro

AI駆動IDE(VS Codeフォーク)で、SDD専用に設計されています。

概要:

VS Codeをベースにしたカスタムエディタ
SDD専用の機能を統合

主な機能:

段階的ガイド: Requirements → Design → Tasksのフェーズを自動的にガイド
組み込みAIエージェント: IDE内でエージェントと対話
可視化ツール: 要件トレーサビリティマトリックスの表示

適用場面:

小規模チーム(2-5人)
ソロ開発者
SDDを初めて導入するチーム

特徴:

学習コストが低い(VS Codeベース)
オールインワンの開発環境
SDD専用UIで迷わない

5.4 OpenSpec

軽量でオープンソースの仕様ファースト開発ツールです。

コンセプト:
「Minimal but Sufficient」
必要最小限の機能で最大の効果

特徴:

軽量: インストールサイズが小さい、起動が高速
クイック反復: 仕様の変更から実装までのサイクルが短い
ブラウンフィールド対応: 既存プロジェクトへの導入が容易

適用場面:

レガシーコードのリファクタリング
既存プロジェクトへのSDD導入
素早い反復が必要なプロジェクト

ワークフロー:

# 既存プロジェクトに導入
openspec init

# 既存コードから仕様を逆生成
openspec reverse-engineer

# 仕様を更新
vim specs/feature.md

# 差分を実装に反映
openspec sync

5.5 Tessl

仕様が主要成果物となるフレームワークです。

哲学:
「Specs are the primary artifact」
コードではなく、仕様こそが最も重要な成果物

特徴:

構造化された仕様言語: テスト可能な独自DSL(Domain-Specific Language)
AIエージェント生成: 仕様からAIが自動的にコードを生成
バージョン管理: 仕様の履歴を厳密に管理

仕様言語の例:

Feature: User Authentication
  Given a user with valid credentials
  When the user submits login form
  Then the system SHALL return JWT token within 500ms
  And the token SHALL be valid for 24 hours

適用場面:

厳密な仕様管理が必要なプロジェクト
規制産業(金融、医療など)
監査が必要なシステム

5.6 AgentOS

AIエージェントを管理するプラットフォームです。

コンセプト:
「Operating System for AI Agents」
複数のAIエージェントを統合管理

主な機能:

エージェント管理: 複数のエージェントを一元管理
ワークフロー最適化: エージェント間の連携を自動化
メトリクス収集: 各エージェントのパフォーマンスを測定

適用場面:

複数のAIツールを併用しているチーム
エージェントのパフォーマンス分析が必要なプロジェクト

5.7 ai-dev-tasks

ミニマリストアプローチのツールです。

コンセプト:
「Markdown files + Task tagging」
複雑なツールは不要、マークダウンとタグだけで十分

特徴:

マークダウンベース: 既存のエディタで編集可能
タスクタグ: シンプルなタグ付けシステム
ゼロインストール: 追加ツール不要

使用例:

# Feature: User Login

## Requirements
<!-- @requirement @priority:high -->
- User can login with email and password
- System validates credentials

## Tasks
<!-- @task @assigned:alice @status:in-progress -->
- [ ] Implement login API endpoint
- [ ] Add password validation
<!-- @task @assigned:bob @status:pending -->
- [ ] Write integration tests

適用場面:

ツールの導入ハードルを下げたいチーム
シンプルなワークフローで十分なプロジェクト

5.8 cc-sdd(Spec-driven development for your team's workflow)

Kiro-inspiredな仕様駆動開発ツールで、複数のAIツールをサポートします。

概要:

AI-DLC(AI-Driven Development Lifecycle)とSpec-Driven Developmentを提供
7つのAIツールに対応: Claude Code、Cursor、Gemini CLI、Codex CLI、GitHub Copilot、Qwen Code、Windsurf

主な機能:

Spec-first enforcement(仕様ファースト強制)
- 要件・設計を事前承認
- AIが仕様通りに実装することを保証
Parallel execution support(並列実行対応)
- 依存関係を自動追跡
- 並行実装可能なタスクに自動分解
Team-aligned templates(チーム整合テンプレート)
- 1度カスタマイズすれば、全エージェントが適用
- 承認プロセスに適合したドキュメントを自動出力
Project memory(プロジェクトメモリ)
- セッションを跨いでアーキテクチャを記憶
- パターンや標準を維持
7-agent unified workflow(7エージェント統一ワークフロー)
- 異なるAIツールで同一の仕様駆動プロセス
- ツール移行時の学習コストを削減

インストール:

cd your-project
npx cc-sdd@latest --claude --lang en  # Claude Code用
npx cc-sdd@latest --cursor --lang ja  # Cursor用(日本語)

適用場面:

複数のAIツールを使い分けているチーム
チーム全体で統一されたワークフローが必要なプロジェクト

これらのツールは、それぞれ異なる強みを持っています。次章では、筆者が開発した「Spec Copilot」について紹介します。

6. 筆者が開発したspec-copilotについて

6.1 開発の経緯

2025年10月、私はGitHub Copilotを使った開発を行う中で、あることに気づきました。

GitHub Copilotの素晴らしさ:

コード補完が驚くほど正確
自然言語からコードを生成できる
開発速度が劇的に向上

しかし、課題もありました:

セッションごとにコンテキストが失われる
アーキテクチャパターンを毎回説明する必要がある
体系的な開発ワークフローがない
ドキュメントが後回しになりがち

そこで、GitHub Copilot専用の仕様駆動開発支援エージェント群を開発することを決めました。それが「Spec Copilot」です。

仕様駆動開発を支援する動機

私がSDDに注目した理由は3つあります。

AIコーディングの普及
- AIが高速にコードを生成できる時代
- だからこそ「何を作るべきか」の明確化が重要
チーム開発の課題
- 個人の「感覚」に依存した開発はチームでは破綻
- 標準化されたワークフローの必要性
長期保守の重要性
- 数ヶ月後に自分が書いたコードを理解できない問題
- トレーサビリティの欠如

6.2 spec-copilotの構成

Spec Copilotは、19種類の専門AIエージェントで構成されています。

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

各エージェントは特定の領域に特化し、以下のカテゴリに分類されます。

オーケストレーション:

Orchestrator: 複数エージェントの統括管理

要件定義・計画:

Requirements Analyst: 要件分析、ユーザーストーリー作成
Project Manager: プロジェクト計画、スケジューリング

アーキテクチャ・設計:

System Architect: システムアーキテクチャ設計
API Designer: REST/GraphQL/gRPC API設計
Database Schema Designer: データベース設計
UI/UX Designer: ユーザーインターフェース設計

開発・実装:

Software Developer: 多言語コード実装
Test Engineer: テスト設計・実装

品質・レビュー:

Code Reviewer: コードレビュー
Bug Hunter: バグ調査・修正
Quality Assurance: 品質保証戦略

セキュリティ・パフォーマンス:

Security Auditor: セキュリティ監査
Performance Optimizer: パフォーマンス最適化

インフラ・運用:

DevOps Engineer: CI/CD構築
Cloud Architect: クラウドアーキテクチャ設計
Database Administrator: データベース運用

ドキュメント・特殊領域:

Technical Writer: 技術文書作成
AI/ML Engineer: 機械学習開発

Orchestratorによるマルチエージェント調整

Orchestratorは、ユーザーのリクエストを分析し、適切なエージェントを選択・連携させます。

Orchestratorの機能:

リクエスト分析

ユーザー: 「タスク管理アプリを開発したい」

Orchestrator分析:
- 要件定義が必要 → Requirements Analyst
- アーキテクチャ設計が必要 → System Architect
- API設計が必要 → API Designer
- データベース設計が必要 → Database Schema Designer
- 実装が必要 → Software Developer
- テストが必要 → Test Engineer

エージェント選定
- プロジェクトの性質を分析
- 必要なエージェントを選択
- 実行順序を決定
タスク分解
- 大きなタスクを小さなタスクに分割
- 各タスクを担当エージェントに割り当て
実行管理
- 各エージェントを順次実行
- 進捗状況をユーザーに報告
結果統合
- 各エージェントの成果物を統合
- 最終成果物を生成

使用例:

@workspace /orchestrator タスク管理アプリを開発。要件定義から開始。

Orchestrator:
1. Requirements Analystを起動 → requirements.mdを生成
2. System Architectを起動 → design.mdを生成
3. API Designer、Database Schema Designerを起動
   → api-spec.md, database-schema.mdを生成
4. Software Developerを起動 → コード実装
5. Test Engineerを起動 → テストコード生成
6. 最終レポートを生成

5段階対話フロー

各エージェントは、以下の5段階の対話フローで情報を収集します。

フェーズ1: 初回ヒアリング(5-6問)

基本情報の収集
プロジェクトの概要把握

フェーズ2: 詳細ヒアリング(5-7問)

専門的な要件の深堀り
技術的詳細の確認

フェーズ3: 確認フェーズ

収集した情報の整理
ユーザーに確認

フェーズ4: 成果物生成

設計書、コード、図の生成
ファイル出力

フェーズ5: フィードバック

修正・改善の反映
継続的なブラッシュアップ

具体例(Requirements Analyst):

【フェーズ1: 初回ヒアリング】

質問1/5: プロジェクトの種類は？
a) Webアプリケーション
b) モバイルアプリ
c) デスクトップアプリ
d) その他

ユーザー: a) Webアプリケーション

質問2/5: 主な対象ユーザーは？
a) エンドユーザー(一般消費者)
b) ビジネスユーザー(企業内)
c) 開発者
d) その他

ユーザー: b) ビジネスユーザー(企業内)

... (以下、5-6問続く)

【フェーズ2: 詳細ヒアリング】

質問1/7: 認証方式は？
a) Email + Password
b) OAuth(Google, GitHub等)
c) SAML(Enterprise SSO)
d) 複数組み合わせ

... (以下、5-7問続く)

【フェーズ3: 確認フェーズ】

収集した情報:
- プロジェクト: タスク管理Webアプリ
- 対象ユーザー: 5-50人の開発チーム
- 認証: Email + Password
- ...

この内容で要件定義書を作成してよろしいですか？

【フェーズ4: 成果物生成】

requirements.mdを生成しました。
...

【フェーズ5: フィードバック】

修正したい箇所はありますか？

この5段階フローにより：

ユーザーは質問に答えるだけで成果物が完成
段階的に情報を収集するため、ユーザーの負担が少ない
抜け漏れが防止される

6.3 主要エージェント

いくつかの主要エージェントを詳しく見ていきましょう。

Requirements Analyst(要件アナリスト)

役割:

ユーザーストーリーの作成
機能要件・非機能要件の定義
MoSCoW優先順位付け
SRS(ソフトウェア要求仕様書)生成

成果物:

# 要件定義書: タスク管理システム

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

### US-001: タスク作成
As a team member,
I want to create tasks with title and description,
So that I can track my work items.

Acceptance Criteria:
- Given I am logged in
- When I submit task creation form with valid data
- Then the system creates a new task
- And displays success message

### US-002: タスク一覧表示
As a team member,
I want to view all my tasks,
So that I can see what needs to be done.

## 2. 機能要件

### FR-001: タスクCRUD
- System SHALL support Create, Read, Update, Delete operations for tasks
- Each task SHALL have: ID, title, description, status, assignee, due date

### FR-002: タスクフィルタリング
- System SHALL allow filtering tasks by status, assignee, due date
- Filters SHALL be combinable (AND logic)

## 3. 非機能要件

### NFR-001: パフォーマンス
- Task list SHALL load within 200ms for up to 1000 tasks
- Task creation SHALL complete within 500ms

### NFR-002: セキュリティ
- System SHALL authenticate users before any operations
- System SHALL encrypt passwords using bcrypt cost factor 12

## 4. MoSCoW優先順位

**Must Have:**
- US-001: タスク作成
- US-002: タスク一覧表示

**Should Have:**
- タスクフィルタリング
- タスク検索

**Could Have:**
- タスクのタグ付け
- ダッシュボード

**Won't Have (今回):**
- プロジェクト管理機能
- ガントチャート

System Architect(システムアーキテクト)

役割:

C4モデル図の作成
アーキテクチャパターンの選定
ADR(Architecture Decision Records)の作成
トレードオフ分析

成果物例(C4モデル - Context図):

ADR例:

# ADR-001: Clean Architectureの採用

## Status
Accepted

## Context
タスク管理システムのアーキテクチャパターンを選定する必要がある。
以下の要件を満たす必要がある:
- テスタビリティ(単体テストが容易)
- 保守性(変更の影響範囲が限定的)
- 拡張性(新機能の追加が容易)

## Decision
Clean Architectureパターンを採用する。

レイヤー構成:
1. Domain Layer: ビジネスロジック(Entity, Use Case)
2. Application Layer: アプリケーション固有のロジック
3. Infrastructure Layer: 外部システム連携(DB, API)
4. Presentation Layer: UI/Controller

## Consequences

Positive:
- ビジネスロジックがフレームワークから独立
- テストが容易(Dependency Injectionで依存を注入)
- レイヤー間の依存が一方向(Domain → Application → Infrastructure)

Negative:
- 初期の学習コストが高い
- ボイラープレートコードが増える
- 小規模プロジェクトではオーバーエンジニアリング

## Alternatives Considered
- MVC: シンプルだがビジネスロジックが肥大化しやすい
- Layered Architecture: レイヤー分離が不十分
- Hexagonal Architecture: Clean Architectureと類似、こちらも検討したが、チームの経験を考慮してCleanを選択

API Designer(API設計者)

役割:

REST/GraphQL/gRPC API設計
OpenAPI 3.0仕様書生成
API認証・バージョニング戦略

成果物例(OpenAPI仕様):

openapi: 3.0.0
info:
  title: Task Management API
  version: 1.0.0
  description: API for managing tasks in a team environment

servers:
  - url: https://api.taskmanager.example.com/v1
    description: Production server

paths:
  /tasks:
    get:
      summary: List all tasks
      tags: [Tasks]
      parameters:
        - name: status
          in: query
          schema:
            type: string
            enum: [todo, in_progress, done]
        - name: assignee
          in: query
          schema:
            type: string
      responses:
        '200':
          description: Successful response
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Task'

    post:
      summary: Create a new task
      tags: [Tasks]
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/TaskInput'
      responses:
        '201':
          description: Task created
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Task'
        '400':
          description: Invalid input

components:
  schemas:
    Task:
      type: object
      properties:
        id:
          type: string
          format: uuid
        title:
          type: string
          maxLength: 255
        description:
          type: string
        status:
          type: string
          enum: [todo, in_progress, done]
        assignee:
          type: string
        due_date:
          type: string
          format: date
        created_at:
          type: string
          format: date-time

    TaskInput:
      type: object
      required:
        - title
      properties:
        title:
          type: string
          maxLength: 255
        description:
          type: string
        assignee:
          type: string
        due_date:
          type: string
          format: date

6.4 spec-copilotの成果

Spec Copilotは、以下の成果を生み出しました。

体系的なソフトウェア開発支援

Before(Spec Copilot導入前):

GitHub Copilotとの対話で即興的にコーディング
ドキュメントは後回し
アーキテクチャが一貫しない

After(Spec Copilot導入後):

要件定義 → 設計 → 実装 → テストの順序が明確
各段階で専門エージェントが支援
ドキュメントが常に最新

ベストプラクティスの内蔵

Spec Copilotの各エージェントには、業界標準のベストプラクティスが組み込まれています。

SOLID原則(Software Developer):

Single Responsibility Principle(単一責任の原則)
Open/Closed Principle(開放/閉鎖の原則)
Liskov Substitution Principle(リスコフの置換原則)
Interface Segregation Principle(インターフェース分離の原則)
Dependency Inversion Principle(依存性逆転の原則)

OWASP Top 10(Security Auditor):

Injection対策
Broken Authentication対策
Sensitive Data Exposure対策
XML External Entities (XXE)対策
Broken Access Control対策
Security Misconfiguration対策
Cross-Site Scripting (XSS)対策
Insecure Deserialization対策
Using Components with Known Vulnerabilities対策
Insufficient Logging & Monitoring対策

C4 Model(System Architect):

Context図: システムと外部の関係
Container図: システム内のコンテナ構成
Component図: コンテナ内のコンポーネント構成
Code図: コンポーネント内のクラス構成

ADR(Architecture Decision Records)(System Architect):

技術選定の根拠を記録
トレードオフを明示
将来の意思決定に活用

これらのベストプラクティスにより、経験の浅い開発者でも高品質なコードを生成できるようになりました。

spec-copilotリポジトリ

GitHub:

https://github.com/nahisaho/spec-copilot

spec-copilotはオープンソースプロジェクトとして公開されており、GitHub Copilotユーザーであれば誰でも利用できます。

7. spec-copilotに足りなかったもの

Spec Copilotは多くの成果を生み出しましたが、使用を続ける中でいくつかの課題が明らかになりました。

7.1 プラットフォームの制約

GitHub Copilot専用の限界

Spec Copilotは、GitHub Copilot専用に設計されていました。

技術的制約:

.github/agents/ディレクトリにエージェントを配置
GitHub Copilot Chatの@workspace機能に依存
GitHub Copilotのプロンプト形式に特化

問題点:

開発者A: 「Claude Codeを使い始めたんだけど、Spec Copilot使えない...」
開発者B: 「Cursorに移行したいけど、エージェント資産が無駄になる」
開発者C: 「会社がGemini CLIを標準化したから、使えなくなった」

他のAIツール利用者への未対応

2025年、AIコーディングツールは急速に多様化しました。

主要なツール:

Claude Code(.claude/ディレクトリ)
Cursor(.cursorrules)
Windsurf IDE(.windsurfrules)
Gemini CLI(gemini-config.md)
Codex CLI(codex-config.md)
Qwen Code(qwen-config.md)

各ツールは独自のエージェントシステムを持っていますが、Spec CopilotはGitHub Copilotにしか対応していませんでした。

ユーザーからのフィードバック:

「Spec Copilotのコンセプトは素晴らしいけど、うちのチームはClaude Codeを使っているから使えない」

「AIツールを移行するたびに、エージェントを作り直すのは大変すぎる」

7.2 プロジェクト記憶の欠如

セッション間でコンテキストが失われる問題

Spec Copilotは、各エージェントが個別に動作していました。

問題のシナリオ:

Day 1: System Architectとの対話
開発者: 「Clean Architectureを採用します」
System Architect: 「了解しました。設計書を作成します」

Day 2: Software Developerとの対話
開発者: 「ユーザー登録機能を実装してください」
Software Developer: 「どのアーキテクチャパターンを使いますか？」
開発者: 「(また説明するのか...)Clean Architectureです」

Day 3: API Designerとの対話
API Designer: 「技術スタックは何ですか？」
開発者: 「(何度目だ...)TypeScript + Expressです」

根本原因:

各エージェントは独立して動作
プロジェクト全体のコンテキストを共有する仕組みがない
セッションが終わると、すべての情報が失われる

アーキテクチャパターンや技術スタックの再説明コスト

毎回同じ情報を説明する必要があり、生産性が低下しました。

再説明が必要だった情報:

アーキテクチャパターン(Clean Architecture、Hexagonal、etc)
技術スタック(言語、フレームワーク、ライブラリ)
ディレクトリ構造(src/domain, src/application, etc)
コーディング規約(命名規則、コメント規約、etc)
ビジネスコンテキスト(製品目的、対象ユーザー、etc)

時間の浪費:

1セッションあたり:
- アーキテクチャ説明: 5分
- 技術スタック説明: 3分
- ディレクトリ構造説明: 2分

合計: 10分/セッション

10セッション/週 × 10分 = 100分/週 = 1.67時間/週
年間: 86.7時間の浪費

7.3 要件定義の曖昧性

自然言語による要件の解釈のブレ

Spec Copilotは自然言語で要件を記述していましたが、解釈にブレが生じました。

曖昧な要件の例:

要件: ユーザーはタスクを作成できる

異なる解釈:

解釈1: タイトルだけでタスク作成可能
解釈2: タイトル + 説明が必須
解釈3: タイトル + 説明 + 期限が必須

曖昧な要件の例2:

要件: システムは高速である必要がある

異なる解釈:

解釈1: 100ms以内に応答
解釈2: 1秒以内に応答
解釈3: ユーザーが「速い」と感じればOK

このような曖昧性により：

実装者ごとに異なる実装
テスト基準が不明確
要件が満たされているか判定不能

テストケースへの変換の困難さ

曖昧な要件からテストケースを生成するのは困難でした。

曖昧な要件:

要件: エラーが発生したら適切に処理する

どんなテストを書くべきか？

// これで十分？
test('should handle errors', () => {
  expect(() => functionThatMayError()).not.toThrow();
});

// それとも、こう？
test('should return error message when error occurs', () => {
  const result = functionThatMayError();
  expect(result.error).toBeDefined();
});

// あるいは、こう？
test('should log error and return 500 when error occurs', () => {
  const result = functionThatMayError();
  expect(mockLogger.error).toHaveBeenCalled();
  expect(result.status).toBe(500);
});

結果:

テストカバレッジが不十分
エッジケースが見逃される
要件と実装の乖離

7.4 ワークフローの標準化不足

ドキュメントテンプレートの欠如

Spec Copilotには、標準的なドキュメントテンプレートがありませんでした。

問題:

各エージェントが独自の形式でドキュメント生成
プロジェクト間でフォーマットが統一されない
必要なセクションが抜け落ちる

例:

Requirements Analystの出力(プロジェクトA):
- ユーザーストーリーのみ
- 非機能要件なし
- 受入基準なし

Requirements Analystの出力(プロジェクトB):
- 機能要件のみ
- ユーザーストーリーなし
- トレーサビリティマトリックスなし

段階的な品質ゲートの不明確さ

各段階での完了基準(品質ゲート)が明確ではありませんでした。

不明確だった点:

要件定義は「どこまで詳細化」すれば完了？
設計は「どのレベルまで」記述すれば十分？
テストは「どの程度のカバレッジ」で合格？

結果:

不完全な要件で設計に進む
不完全な設計で実装に進む
テストが不十分なまま本番リリース

これらの課題を解決するために、私は新しいツール「MUSUHI」の開発を開始しました。次章では、その進化の過程を見ていきます。

8. musuhiの開発 - spec-copilotからの進化

8.1 開発の動機

Spec Copilotの課題が明らかになった2025年11月初旬に、私は決断しました。

「spec-copilotを進化させ、すべてのAIツールで使える、真の仕様駆動開発支援ツールを作ろう」

spec-copilotの課題を解決するために

前章で述べた4つの課題を解決することが、開発の主要な動機でした。

マルチプラットフォーム対応
- GitHub Copilot専用 → 7つのAIツールに対応
- ツール移行時の資産保護
プロジェクトメモリシステム
- セッション間でのコンテキスト喪失 → steering/システムで永続化
- 再説明コストの削減
EARS形式による要件定義
- 曖昧な自然言語 → 構造化されたEARS形式
- テストケースへの1:1マッピング
包括的なワークフローテンプレート
- 標準化されたドキュメントテンプレート
- 明確な品質ゲート

より多くの開発者への恩恵提供

もう1つの動機は、AIツールの選択に関わらず、すべての開発者がSDDの恩恵を受けられるようにすることでした。

実現したかったこと:

Claude Codeユーザーも使える
Cursorユーザーも使える
Gemini CLIユーザーも使える
どのツールを選んでも、同じSDDワークフローで開発できる

インストールの簡単さ:

# たった1コマンドで、どのツールにも対応
npx musuhi

# 対話形式でツールを選択
? Which AI tool do you use?
  ❯ Claude Code
    GitHub Copilot
    Cursor
    Windsurf IDE
    Gemini CLI
    Codex CLI
    Qwen Code

8.2 なぜ「MUSUHI(産霊/むすひ)」なのか

名前を変える決断は、単なる改名ではなく、ツールの哲学の深化を意味しています。

むすひの概念

改めて、「むすひ」の概念を深く見ていきましょう。

むすひ(産霊):
神道における観念で、天地・万物を生成・発展・完成させる霊的な働きのことです。

語源:

「むす(産)」: 「うむす(産むす)」の「う」が取れたもので、自然に発生するという意味
- 「苔生す(こけむす)」の「生す」も同根
- 無理やり作るのではなく、自然に生まれ出る
「ひ(霊)」: 霊的・神秘的な働き
- 目に見えない力
- 生命を吹き込む力

神道における意味:
万物は「むすひ」の働きによって生じ、発展すると考えられています。この観念は江戸時代以降の国学者によって深く論じられ、日本の精神文化の根幹をなしています。

むすひの神々

「むすひ」を神名に含む神は多数おり、いずれも「むすひ」の働きをする神と考えられます。

造化三神:

タカミムスビ(高御産巣日神)
- アマテラスが天岩戸に隠れた時、諸神に命じてアマテラスを帰還させた
- 意味: 衰えようとする魂を奮い立たせる働き
- 対応: 停滞したプロジェクトに活力を与える
カミムスビ(神産巣日神)
- 殺されたオオナムヂを蘇生させた
- 意味: 生命力の象徴
- 対応: レガシーコードに新しい生命を吹き込む

宮中八神(うち5神に「むすひ」):

タマツメムスビ(玉積産日神)
- 「たまつめ(たまとめ)」= 魂を体に留める(鎮魂)
- 意味: プロジェクトの魂(コンテキスト)を保持
- 対応: steering/システムによるプロジェクトメモリ
イクムスビ(生産日神)
- 「いく」= 「いき(生き、息)」と同根
- 意味: むすひの働きを賛える
- 対応: 活発な開発活動の促進
タルムスビ(足産日神)
- 「たる」= その働きが満ち溢れている(足りている)
- 意味: 完全性、充足
- 対応: 要件カバレッジ100%、品質ゲートの完全性

火産霊(ホムスビ/カグツチ):

イザナミは火の神カグツチを生んだことで亡くなった
イザナギはカグツチを斬り殺すが、その際に多数の神が化生
意味: 死んでもなお多くの命を生み出す、生命の連続性の象徴
対応: 1つの成果物が次の成果物を生み出すトレーサビリティ

ワクムスビ:

『日本書紀』に登場
死んでから多数の穀物などを生み出した
意味: 生命の連続性、豊穣
対応: 仕様から多様な成果物(設計、コード、テスト)が生まれる

ツールコンセプトとの対応

むすひの概念は、MUSUHIツールのコンセプトと驚くほど対応しています。

プロジェクトの「生成(むす)」:

むすひの働き: 自然に発生する、生み出す
              ↓
MUSUHIの働き: 20個のエージェントが多様な成果物を生み出す
              ホムスビのように、1つから多数を生み出す

具体例:

requirements.md(要件定義)
  ├→ design.md(設計書)
  ├→ tasks.md(タスク一覧)
  ├→ src/components/(コード)
  ├→ tests/(テストコード)
  └→ docs/(API仕様書)

1つの要件定義から、多数の成果物が「自然に」生まれる

プロジェクトの「発展」:

むすひの働き: 衰えようとする魂を奮い立たせる(タカミムスビ)
              ↓
MUSUHIの働き: Steering Agentによる継続的なコンテキスト維持
              停滞したプロジェクトに新しい活力を

具体例:

6ヶ月前のプロジェクト:
- コンテキストが失われている
- なぜこう設計したか不明
- 技術スタックの選定理由が不明

MUSUHIで蘇生:
@steering  # コードベースを分析
→ steering/ が生成され、設計意図が復元
→ プロジェクトの魂(コンテキスト)が戻る

プロジェクトの「完成」:

むすひの働き: 天地・万物を完成させる霊的な働き
              ↓
MUSUHIの働き: 8段階ワークフローによる体系的な開発支援
              品質ゲートによる確実な前進

具体例:

調査 → 要件定義 → 設計 → タスク化 → 実装 → テスト → デプロイ → 監視

各段階に品質ゲート:
- 要件定義: すべてEARS形式で記述
- 設計: すべての要件がマップ済み
- テスト: すべての要件がテスト済み

段階的に「完成」へと導く

生命の連続性:

むすひの働き: 死んでもなお多くの命を生み出す(ホムスビ、ワクムスビ)
              ↓
MUSUHIの働き: プロジェクトメモリ(steering/)による知識の継承
              1つの成果物が次の成果物を生み出すトレーサビリティ

具体例:

プロジェクトメモリの継承:
steering/structure.md (アーキテクチャパターン)
  ↓ 6ヶ月後の新メンバー
  ↓ steering/を読む
  ↓ プロジェクトの設計思想を理解
  ↓ 一貫した実装が可能

知識が「死なない」、継承される

spec-copilotとの違い

名前の変化は、哲学の深化を表しています。

観点	spec-copilot	musuhi
語源	Specification + Copilot	産霊(むすひ)
意味	仕様のコパイロット(副操縦士)	万物を生成・発展・完成させる力
コンセプト	Connection(結び): エージェントとプロジェクトを結ぶ	Creative Force(産霊): プロジェクトに生命力を吹き込む
哲学	ツール的	精神的・文化的
役割	支援者	創造の力

spec-copilot: 「結び(connection/binding)」

エージェントとプロジェクトを「結ぶ」
開発者とAIを「結ぶ」
機能的な結びつき

MUSUHI: 「産霊(creative force)」

プロジェクトに「生命を吹き込む」
自然に「発生」させる
「発展」させる
「完成」へと導く
精神的・霊的な力

なぜ名前を変えたのか:

spec-copilotからmusuhiへの進化は、単なる機能追加ではなく、ツールの本質的な役割の再定義でした。

spec-copilot: 開発者を「支援する」ツール
MUSUHI: プロジェクトに「生命を与える」存在

この哲学の深化が、マルチプラットフォーム対応、プロジェクトメモリ、EARS形式、包括的テンプレートといった機能として結実しました。

8.3 spec-copilotとmusuhiの比較

具体的な違いを表で比較します。

項目	spec-copilot	MUSUHI
エージェント数	19個	20個(Steering Agent追加)
対応プラットフォーム	GitHub Copilotのみ	Claude Code, GitHub Copilot, Cursor, Windsurf IDE, Gemini CLI, Codex CLI, Qwen Code(7つ)
プロジェクトメモリ	なし	steering/システム(v0.3.0)
要件定義形式	自然言語(曖昧)	EARS形式サポート(v0.3.1)
ワークフローテンプレート	なし	包括的テンプレート(v0.3.2)
インストール方法	手動配置(.github/agents/にコピー)	`npx musuhi`で1コマンド
ドキュメント言語	英語・日本語混在	バイリンガル(.md / .ja.md)
トレーサビリティ	部分的	完全(要件↔設計↔タスク↔コード↔テスト)
品質ゲート	不明確	各段階で明確に定義
プロジェクト初期化	手動	Steering Agentによる自動分析
哲学	Connection(結び)	Creative Force(産霊)
リリース日	2025年11月10日	2025年11月17日(v0.4.0)

主要な進化ポイント:

マルチプラットフォーム対応(v0.4.0)
- 7つのAIツールに対応
- ツール固有のディレクトリ構造に自動適応
- ツール移行時の学習コストゼロ
Steering Agent追加(v0.3.0)
- コードベース自動分析
- steering/システムによるプロジェクトメモリ
- セッション間でのコンテキスト維持
EARS形式サポート(v0.3.1)
- 5つの構造化パターン
- 要件からテストケースへの1:1マッピング
- 曖昧性の完全排除
包括的テンプレート(v0.3.2)
- research.md, requirements.md, design.md, tasks.md
- 英語・日本語バイリンガル対応
- 品質ゲート定義
簡単インストール
- npx musuhiで即座に利用可能
- 対話形式でツール選択
- グローバルインストール不要

次章では、MUSUHIと他のSDDソリューションとの違いと、MUSUHIの独自のメリットを詳しく見ていきます。

9. MUSHUHIと他のソリューションの違い、メリット

この章では、MUSUHIと他のSDD支援ツールとの違いを明確にし、MUSUHIの独自のメリットを詳しく見ていきます。

9.1 マルチプラットフォーム対応

7つのAIツールに対応

MUSUHIの最大の特徴の1つは、7つの主要AIツールすべてに対応していることです。

AIツール	ディレクトリ	設定ファイル	インストール
Claude Code	`.claude/agents/`	`CLAUDE.md`	`npx musuhi install --tool claude-code`
GitHub Copilot	`.github/agents/`	`.github/copilot-instructions.md`	`npx musuhi install --tool github-copilot`
Cursor	`.cursor/agents/`	`.cursorrules`	`npx musuhi install --tool cursor`
Windsurf IDE	`.windsurf/agents/`	`.windsurfrules`	`npx musuhi install --tool windsurf`
Gemini CLI	`.gemini/agents/`	`gemini-config.md`	`npx musuhi install --tool gemini-cli`
Codex CLI	`.codex/agents/`	`codex-config.md`	`npx musuhi install --tool codex-cli`
Qwen Code	`.qwen/agents/`	`qwen-config.md`	`npx musuhi install --tool qwen-code`

共通要素:
すべてのプラットフォームで以下が共通です。

your-project/
├── steering/                   # プロジェクトメモリ(共通)
│   ├── structure.md
│   ├── tech.md
│   ├── product.md
│   ├── rules/
│   │   ├── ears-format.md
│   │   ├── workflow.md
│   │   └── agent-validation-checklist.md
│   └── templates/
│       ├── requirements.md
│       ├── design.md
│       ├── tasks.md
│       └── research.md
└── [ツール固有のディレクトリ]/
    ├── README.md
    └── agents/                 # 20個のエージェント(共通)
        ├── steering.md
        ├── orchestrator.md
        ├── requirements-analyst.md
        └── ...

プラットフォーム固有の要素:

ディレクトリ名のみ異なる(.claude/, .github/, etc)
設定ファイル名が異なる(CLAUDE.md, copilot-instructions.md, etc)
エージェントの呼び出し方が異なる

各ツールでのエージェント呼び出し方法:

AIツール	呼び出し方法	例
Claude Code	`@agent-name`	`@steering`, `@requirements-analyst`
GitHub Copilot	`@workspace /agent-name`	`@workspace /steering`, `@workspace /requirements-analyst`
Cursor	`@agent-name`	`@steering`, `@requirements-analyst`
Windsurf IDE	`@agent-name`	`@steering`, `@requirements-analyst`
Gemini CLI	`gemini @agent-name`	`gemini @steering`, `gemini @requirements-analyst`
Codex CLI	`codex @agent-name`	`codex @steering`, `codex @requirements-analyst`
Qwen Code	`@agent-name`	`@steering`, `@requirements-analyst`

※ 呼び出し方法の詳細は各ツールのバージョンや設定により異なる場合があります。

ツール移行時の資産保護

AIツールを移行する際、すべてのエージェント資産が保護されます。

シナリオ:

月曜日: GitHub Copilotでプロジェクト開始
  └→ npx musuhi install --tool github-copilot
  └→ @workspace /requirements-analyst で要件定義
  └→ requirements.md が完成

水曜日: Claude Codeに移行することを決定
  └→ npx musuhi install --tool claude-code
  └→ @system-architect で設計(requirements.mdを参照)
  └→ design.md が完成

金曜日: Cursorも試してみたい
  └→ npx musuhi install --tool cursor
  └→ @software-developer で実装
  └→ 既存のrequirements.md, design.mdをそのまま活用

資産が保護される理由:

steering/ディレクトリはすべてのツールで共通
エージェントの構造も共通
ドキュメントテンプレートも共通
ワークフローも共通

移行コスト:

ゼロ(学習コストなし)
同じエージェント名、同じワークフロー
ドキュメントもそのまま使える

開発者の選択肢を広げる

MUSUHIは、AIツールの選択を開発者に委ねます。

チーム内で異なるツールを使うケース:

開発者A: Claude Code派
  └→ Claude Codeの高度な推論能力を活用

開発者B: Cursor派
  └→ Cursorの優れたUI/UXが好き

開発者C: GitHub Copilot派
  └→ GitHub統合が便利

↓ すべて同じSDDワークフロー
↓ steering/を共有
↓ 成果物も統一

会社でツールを変更するケース:

2024年Q1: GitHub Copilot標準
2024年Q2: Claude Code試験導入
2024年Q3: Cursor正式採用

↓ musuhiを使っていれば
↓ すべてのツールで同じワークフローを維持
↓ 過去の資産も活用可能

9.2 プロジェクトメモリシステム(steering/)

MUSUHIの革新的な機能の1つが、steering/システムです。

structure.md: アーキテクチャパターン、ディレクトリ構成

目的:
プロジェクトの構造的な情報を記録

記録内容:

# Structure: Project Architecture and Organization

## Architecture Pattern
- **Pattern**: Clean Architecture
- **Layers**:
  - Domain Layer: Core business logic (entities, value objects)
  - Application Layer: Use cases, application services
  - Infrastructure Layer: External integrations (database, APIs)
  - Presentation Layer: UI/Controllers

## Directory Structure

src/
├── domain/
│   ├── entities/
│   ├── value-objects/
│   └── repositories/
├── application/
│   ├── use-cases/
│   └── services/
├── infrastructure/
│   ├── database/
│   ├── api/
│   └── config/
└── presentation/
    ├── controllers/
    └── views/


## Naming Conventions
- **Files**: kebab-case (e.g., `user-repository.ts`)
- **Classes**: PascalCase (e.g., `UserRepository`)
- **Functions**: camelCase (e.g., `getUserById`)
- **Constants**: UPPER_SNAKE_CASE (e.g., `MAX_RETRY_COUNT`)

## Module Organization
- Each domain entity has its own directory
- Repositories are defined in domain, implemented in infrastructure
- Use cases are isolated in application layer

活用方法:

開発者: @software-developer 新しいタスク機能を実装

Software Developer:
[steering/structure.mdを自動読み込み]
→ Clean Architectureに従う
→ src/domain/entities/Task.tsを作成
→ src/application/use-cases/CreateTask.tsを作成
→ kebab-caseで命名

tech.md: 技術スタック、フレームワーク決定

目的:
プロジェクトの技術的決定を記録

記録内容:

# Tech: Technology Stack and Decisions

## Programming Language
- **Primary**: TypeScript 5.0
- **Reason**: Type safety, modern features, team expertise

## Backend Framework
- **Framework**: Express 4.18
- **Reason**: Lightweight, flexible, large ecosystem

## Frontend Framework
- **Framework**: React 18
- **Reason**: Component-based, large community, team expertise

## Database
- **RDBMS**: PostgreSQL 15
- **Reason**: ACID compliance, JSON support, team expertise
- **ORM**: Prisma 5.x
- **Reason**: Type-safe queries, excellent DX

## Authentication
- **Strategy**: JWT + bcrypt
- **JWT Library**: jsonwebtoken
- **Password Hashing**: bcrypt cost factor 12

## Testing
- **Unit**: Jest
- **Integration**: Supertest
- **E2E**: Playwright
- **Coverage Target**: 80%

## Code Quality
- **Linter**: ESLint
- **Formatter**: Prettier
- **Type Checking**: TypeScript strict mode

## Infrastructure
- **Hosting**: Azure App Service
- **Database**: Azure Database for PostgreSQL
- **Storage**: Azure Blob Storage
- **CI/CD**: GitHub Actions

## Development Tools
- **Package Manager**: npm
- **Version Control**: Git
- **Branching Strategy**: GitHub Flow

活用方法:

開発者: @api-designer ユーザー認証APIを設計

API Designer:
[steering/tech.mdを自動読み込み]
→ JWT認証を採用
→ bcrypt cost factor 12でパスワードハッシュ化
→ Express 4.18ベースのエンドポイント設計
→ Prismaでデータアクセス層

product.md: ビジネスコンテキスト、製品目的

目的:
プロジェクトのビジネス的側面を記録

記録内容:

# Product: Business Context and Purpose

## Product Overview
- **Name**: TaskFlow
- **Type**: Team Task Management SaaS
- **Purpose**: Streamline task management for small to medium development teams

## Target Users
- **Primary**: Software development teams (5-50 members)
- **Secondary**: Project managers in tech companies
- **User Persona**:
  - Name: Alice, Software Engineer
  - Age: 28-35
  - Experience: 3-10 years
  - Pain Points: Scattered tasks, unclear priorities, poor visibility

## Core Capabilities
1. **Task Management**
   - Create, assign, track tasks
   - Set priorities, due dates
   - Add descriptions, attachments

2. **Team Collaboration**
   - Real-time updates
   - Comments and discussions
   - @mentions

3. **Reporting**
   - Sprint burndown charts
   - Team velocity tracking
   - Individual productivity metrics

## Business Requirements
- **SLA**: 99.9% uptime
- **Response Time**: <200ms for task list, <500ms for task creation
- **Scalability**: Support up to 1000 concurrent users per tenant
- **Data Retention**: 7 years for compliance

## Competitive Landscape
- **Competitors**: Jira, Asana, Linear
- **Differentiation**:
  - Developer-first UI/UX
  - Keyboard shortcuts for all actions
  - Git integration
  - Markdown support

## Success Metrics
- **User Activation**: 70% of signups create first task within 24h
- **Retention**: 60% monthly active users
- **NPS**: >40

## Constraints
- **Budget**: Limited (startup)
- **Timeline**: MVP in 3 months
- **Team Size**: 2 developers, 1 designer

活用方法:

開発者: @requirements-analyst タスク作成機能の要件を定義

Requirements Analyst:
[steering/product.mdを自動読み込み]
→ 対象ユーザー: 開発チーム
→ キーボードショートカット必須
→ Markdown対応必須
→ レスポンス時間: <500ms
→ これらを反映した要件定義書を作成

Steering Agentによる自動分析と同期

Steering Agentは、プロジェクトメモリの管理を担当します。

3つのモード:

Bootstrapモード(初回)

@steering

Steering Agent:
プロジェクトを分析しています...

[分析内容]
- package.json → TypeScript, Express, React検出
- src/ディレクトリ → Clean Architecture構造検出
- README.md → 製品概要、対象ユーザー検出

[steering/生成]
- structure.md: Clean Architecture, ディレクトリ構造を記録
- tech.md: TypeScript, Express, React, PostgreSQLを記録
- product.md: TaskFlow, 開発チーム向けSaaSを記録

プロジェクトメモリを初期化しました。
全エージェントがこのコンテキストを共有します。

Syncモード(定期更新)

@steering

Steering Agent:
コードベースの変更を検出しています...

[ドリフト検出]
- tech.md: PostgreSQL 14 → 15にアップグレード検出
- structure.md: src/domain/events/ディレクトリ追加検出

[steering/更新]
- tech.md: PostgreSQL 15に更新
- structure.md: Event Sourcingパターン追加

プロジェクトメモリを同期しました。

Reviewモード(確認)

@steering review

Steering Agent:
現在のプロジェクトメモリ:

【アーキテクチャ】
- Clean Architecture
- ドメイン駆動設計

【技術スタック】
- TypeScript 5.0
- Express 4.18
- PostgreSQL 15

【製品概要】
- TaskFlow: 開発チーム向けタスク管理SaaS
- 対象: 5-50人の開発チーム

自動分析の仕組み:

// Steering Agentの分析ロジック(概念)
class SteeringAgent {
  async analyzeCodebase() {
    // package.jsonから技術スタック検出
    const packageJson = await readPackageJson();
    const techStack = extractTechStack(packageJson);

    // src/から構造検出
    const srcStructure = await analyzeDirectoryStructure('src/');
    const architecturePattern = detectArchitecturePattern(srcStructure);

    // README.mdからビジネスコンテキスト検出
    const readme = await readReadme();
    const productInfo = extractProductInfo(readme);

    // steering/生成
    await generateSteeringFiles({
      structure: { pattern: architecturePattern, structure: srcStructure },
      tech: techStack,
      product: productInfo
    });
  }

  async detectDrift() {
    // コードベース vs steering/ の差分検出
    const currentCode = await analyzeCodebase();
    const currentSteering = await readSteeringFiles();

    const drift = compareDrift(currentCode, currentSteering);

    if (drift.length > 0) {
      // steering/を更新
      await updateSteeringFiles(drift);
    }
  }
}

メリット:

✅ 手動でsteering/を書く必要がない
✅ コードベースの変更を自動追跡
✅ 常に最新のコンテキストを維持
✅ 新メンバーのオンボーディングが容易

9.3 EARS形式による要件定義

musuhiは、EARS(Easy Approach to Requirements Syntax)を完全サポートします。

5つのパターン

EARS形式の5つのパターンを、実例とともに見ていきましょう。

1. Event-Driven(イベント駆動)

形式: WHEN [trigger event], the [system] SHALL [response]

実例:

REQ-001: WHEN user clicks "Submit" button with valid task data,
         the Task Service SHALL create new task and return task ID within 500ms

REQ-002: WHEN user presses Ctrl+N keyboard shortcut,
         the UI SHALL open new task creation dialog

REQ-003: WHEN task status changes from "in_progress" to "done",
         the System SHALL send notification to task assignee

対応するテストケース:

describe('Task Creation', () => {
  it('should create task and return ID within 500ms when submit is clicked with valid data', async () => {
    const validTask = { title: 'Test Task', description: 'Test Description' };
    const startTime = Date.now();

    const response = await request(app)
      .post('/tasks')
      .send(validTask);

    const duration = Date.now() - startTime;

    expect(response.status).toBe(201);
    expect(response.body.id).toBeDefined();
    expect(duration).toBeLessThan(500);
  });
});

2. State-Driven(状態駆動)

形式: WHILE [system state], the [system] SHALL [response]

実例:

REQ-004: WHILE task is being saved to database,
         the Save Button SHALL be disabled and show loading spinner

REQ-005: WHILE user session is active,
         the System SHALL refresh JWT token every 15 minutes

REQ-006: WHILE network connection is offline,
         the App SHALL queue all create/update operations for later sync

対応するテストケース:

describe('Task Save State', () => {
  it('should disable save button and show spinner while saving', async () => {
    const { getByRole, getByTestId } = render(<TaskForm />);
    const saveButton = getByRole('button', { name: /save/i });

    // Saveボタンをクリック
    fireEvent.click(saveButton);

    // 保存中はボタンが無効化され、スピナーが表示される
    await waitFor(() => {
      expect(saveButton).toBeDisabled();
      expect(getByTestId('loading-spinner')).toBeInTheDocument();
    });
  });
});

3. Unwanted Behavior(望ましくない動作)

形式: IF [error condition], THEN the [system] SHALL [response]

実例:

REQ-007: IF user enters empty task title,
         THEN the Form SHALL display "Title is required" error message

REQ-008: IF database connection fails,
         THEN the API SHALL return HTTP 503 with retry-after header

REQ-009: IF user authentication token is expired,
         THEN the System SHALL redirect to login page with return URL

対応するテストケース:

describe('Error Handling', () => {
  it('should display "Title is required" when empty title is entered', async () => {
    const { getByRole, getByText } = render(<TaskForm />);
    const submitButton = getByRole('button', { name: /submit/i });

    // タイトルを空のまま送信
    fireEvent.click(submitButton);

    await waitFor(() => {
      expect(getByText('Title is required')).toBeInTheDocument();
    });
  });

  it('should return 503 with retry-after when database fails', async () => {
    mockDb.connect.mockRejectedValue(new Error('Connection failed'));

    const response = await request(app)
      .post('/tasks')
      .send({ title: 'Test' });

    expect(response.status).toBe(503);
    expect(response.headers['retry-after']).toBeDefined();
  });
});

4. Optional Features(オプション機能)

形式: WHERE [feature is included], the [system] SHALL [response]

実例:

REQ-010: WHERE dark mode is enabled in user settings,
         the UI SHALL use dark color scheme for all components

REQ-011: WHERE user has premium subscription,
         the System SHALL allow creating unlimited projects

REQ-012: WHERE admin mode is activated,
         the Dashboard SHALL display system health metrics

対応するテストケース:

describe('Dark Mode', () => {
  it('should use dark color scheme when dark mode is enabled', () => {
    const { container } = render(<App />, {
      initialState: { settings: { darkMode: true } }
    });

    expect(container.firstChild).toHaveClass('theme-dark');
    expect(getComputedStyle(container.firstChild).backgroundColor).toBe('rgb(18, 18, 18)');
  });
});

5. Ubiquitous(遍在的)

形式: The [system] SHALL [response]

実例:

REQ-013: The User Service SHALL encrypt all passwords using bcrypt with cost factor 12

REQ-014: The Task List API SHALL sort tasks by created_date in descending order by default

REQ-015: The System SHALL log all authentication attempts with timestamp and IP address

対応するテストケース:

describe('Password Encryption', () => {
  it('should encrypt passwords using bcrypt cost factor 12', async () => {
    const password = 'SecurePass123!';
    const user = await userService.createUser({ email: 'test@example.com', password });

    // bcrypt with cost 12かチェック
    const rounds = await bcrypt.getRounds(user.passwordHash);
    expect(rounds).toBe(12);

    // 元のパスワードと比較できるか
    const isValid = await bcrypt.compare(password, user.passwordHash);
    expect(isValid).toBe(true);
  });
});

要件 → テストケースの1:1マッピング

EARS形式の最大のメリットは、各要件がテストケースに1:1でマッピングされることです。

マッピング例:

REQ-001: WHEN user submits valid task data, the System SHALL create task within 500ms
  ↓
test_create_task_with_valid_data_within_500ms()

REQ-002: IF empty title is entered, THEN the Form SHALL display "Title is required"
  ↓
test_display_title_required_error_when_empty()

REQ-003: The System SHALL encrypt passwords using bcrypt cost factor 12
  ↓
test_encrypt_passwords_with_bcrypt_cost_12()

要件カバレッジマトリックス:

要件ID	EARS要件	テストケース	状態
REQ-001	WHEN user submits valid task...	`test_create_task_with_valid_data_within_500ms()`	✅ Pass
REQ-002	IF empty title is entered...	`test_display_title_required_error_when_empty()`	✅ Pass
REQ-003	The System SHALL encrypt...	`test_encrypt_passwords_with_bcrypt_cost_12()`	✅ Pass
REQ-004	WHILE task is being saved...	`test_disable_button_while_saving()`	✅ Pass
REQ-005	WHERE dark mode is enabled...	`test_use_dark_scheme_when_enabled()`	❌ Fail

カバレッジ: 4/5 = 80%

曖昧性の排除

EARS形式は、曖昧な表現を完全に排除します。

禁止される曖昧な表現:

曖昧な表現	なぜダメか	EARS形式への変換
「ユーザーはタスクを作成できる」	「できる」は義務ではない、テスト不可	`WHEN user submits task data, the System SHALL create task`
「システムは高速である必要がある」	「高速」の定義が不明	`The Task List SHALL respond within 200ms`
「エラーを適切に処理する」	「適切」の基準が不明	`IF database fails, THEN the System SHALL return HTTP 503`
「ユーザーフレンドリーなUI」	測定不可能	`The UI SHALL respond to user input within 100ms` + `The Form SHALL display validation errors within 50ms`
「できるだけ多くのユーザーをサポート」	数値が不明確	`The System SHALL support 1000 concurrent users`

Before(曖昧) vs After(EARS形式):

【Before】
要件: ユーザーがログインできる

問題:
- ログイン方法は？(Email? OAuth? SAML?)
- ログイン後は？(リダイレクト先は？)
- エラー時は？(何回失敗したらロック？)

【After】
REQ-001: WHEN user submits valid email and password,
         the Auth Service SHALL return JWT token within 500ms

REQ-002: WHEN user submits valid email and password,
         the System SHALL redirect to dashboard page

REQ-003: IF user enters incorrect password 3 times,
         THEN the System SHALL lock account for 15 minutes

REQ-004: IF account is locked,
         THEN the Login Form SHALL display "Account locked. Try again in 15 minutes"

すべてテスト可能、測定可能、曖昧性ゼロ。

9.4 包括的なワークフローテンプレート

MUSUHIは、SDD全体をカバーする4つのテンプレートを提供します。

research.md: 技術調査テンプレート

使用タイミング:
要件定義の前、技術的決定が必要な時

テンプレート構造:

# Research: [調査テーマ]

## 1. Research Questions
### 1.1 Primary Question
[主要な調査質問]

### 1.2 Secondary Questions
- [副次的な質問1]
- [副次的な質問2]

## 2. Research Methodology
- [調査方法]
- [調査期間]
- [情報源]

## 3. Options Analysis
### Option A: [選択肢A]
**Pros:**
- [利点1]
- [利点2]

**Cons:**
- [欠点1]
- [欠点2]

**Cost:** [コスト]
**Learning Curve:** [学習曲線]

### Option B: [選択肢B]
[同様の構造]

## 4. Comparison Matrix
| Criteria | Weight | Option A | Option B | Option C |
|----------|--------|----------|----------|----------|
| Performance | 30% | 9/10 | 7/10 | 8/10 |
| Cost | 25% | 6/10 | 9/10 | 7/10 |
| Learning Curve | 20% | 8/10 | 6/10 | 9/10 |
| **Total** | **100%** | **7.9** | **7.3** | **7.9** |

## 5. Recommendation
**Selected Option:** [選択された選択肢]

**Rationale:**
[選定理由の詳細]

**Implementation Plan:**
1. [実装ステップ1]
2. [実装ステップ2]

## 6. Risk Assessment
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| [リスク1] | Medium | High | [対策] |

## 7. References
- [参考資料1]
- [参考資料2]

実例:

# Research: Database Selection for Task Management System

## 1. Research Questions
### 1.1 Primary Question
Which database should we use for TaskFlow that balances performance, scalability, and team expertise?

### 1.2 Secondary Questions
- Do we need ACID compliance?
- What query patterns will dominate?
- What is our budget constraint?

## 2. Research Methodology
- Benchmark tests with 10k, 100k, 1M records
- Team interviews on expertise
- Cost analysis for 1 year projection

## 3. Options Analysis
### Option A: PostgreSQL 15
**Pros:**
- ACID compliance
- JSON support for flexible schema
- Team has 5 years experience
- Rich ecosystem (Prisma ORM)

**Cons:**
- More complex setup than NoSQL
- Vertical scaling limits

**Cost:** $50/month (Azure managed)
**Learning Curve:** Low (team knows it)

### Option B: MongoDB 6.0
**Pros:**
- Flexible schema
- Horizontal scaling
- Fast for write-heavy workloads

**Cons:**
- No ACID for multi-document (until v4.0)
- Team has limited experience
- Less suitable for complex joins

**Cost:** $60/month (MongoDB Atlas)
**Learning Curve:** Medium

### Option C: DynamoDB
**Pros:**
- Fully managed
- Infinite scalability
- Pay-per-use pricing

**Cons:**
- Vendor lock-in (AWS only)
- Complex query patterns
- Team has no experience

**Cost:** $30/month (estimated)
**Learning Curve:** High

## 4. Comparison Matrix
| Criteria | Weight | PostgreSQL | MongoDB | DynamoDB |
|----------|--------|------------|---------|----------|
| Performance | 30% | 8/10 | 9/10 | 9/10 |
| Cost | 25% | 7/10 | 6/10 | 8/10 |
| Team Expertise | 20% | 10/10 | 4/10 | 2/10 |
| ACID Compliance | 15% | 10/10 | 7/10 | 5/10 |
| Scalability | 10% | 6/10 | 9/10 | 10/10 |
| **Total** | **100%** | **8.15** | **6.95** | **7.15** |

## 5. Recommendation
**Selected Option:** PostgreSQL 15

**Rationale:**
- Team expertise significantly reduces implementation risk
- ACID compliance aligns with task management requirements
- JSON support provides flexibility for future features
- Proven at scale for similar workloads
- Prisma ORM provides excellent developer experience

**Implementation Plan:**
1. Week 1: Setup Azure Database for PostgreSQL
2. Week 1: Define schema with Prisma
3. Week 2: Implement repository pattern
4. Week 2-3: Migrate from SQLite (dev DB)

## 6. Risk Assessment
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| Vertical scaling limits at 100k users | Low | Medium | Monitor usage, plan sharding strategy |
| Team burnout from complex queries | Low | Low | Use Prisma ORM for query building |

## 7. References
- PostgreSQL Benchmarks: https://...
- Prisma Performance Guide: https://...
- Team Expertise Survey: [internal doc]

requirements.md / .ja.md: EARS形式要件定義書

テンプレート構造:

# Requirements: [プロジェクト名]

## 1. User Stories
### US-001: [ユーザーストーリー名]
As a [user type],
I want to [action],
So that [benefit].

**Acceptance Criteria (EARS Format):**
- WHEN [event], the [system] SHALL [response]
- IF [condition], THEN the [system] SHALL [response]

## 2. Functional Requirements (EARS Format)
### FR-001: [機能名]
- The [system] SHALL [requirement]
- WHEN [event], the [system] SHALL [response]

## 3. Non-Functional Requirements
### NFR-001: Performance
- The [system] SHALL [performance requirement]

### NFR-002: Security
- The [system] SHALL [security requirement]

### NFR-003: Scalability
- The [system] SHALL [scalability requirement]

## 4. Requirements Traceability Matrix
| Req ID | User Story | Priority | Status |
|--------|------------|----------|--------|
| FR-001 | US-001 | Must Have | Draft |

## 5. MoSCoW Prioritization
**Must Have:**
- [必須要件]

**Should Have:**
- [推奨要件]

**Could Have:**
- [あれば良い要件]

**Won't Have (this release):**
- [今回は対象外]

design.md / .ja.md: C4モデル設計書

テンプレート構造:

# Design: [システム名]

## 1. Architecture Pattern Selection
**Selected Pattern:** [パターン名]

**Rationale:**
[選定理由]

**Alternatives Considered:**
- [代替案1]: [却下理由]

## 2. C4 Model Diagrams
### 2.1 Context Diagram
```mermaid
graph TB
    User --> System
    System --> ExternalService
```

### 2.2 Container Diagram
[コンテナ構成図]

### 2.3 Component Diagram
[コンポーネント構成図]

## 3. Component Specifications (with EARS Mapping)
### 3.1 Component: [コンポーネント名]
**Responsibility:** [責務]
**Requirements Mapped:** REQ-001, REQ-002
**Dependencies:** [依存コンポーネント]
**Technology:** [技術スタック]

**EARS Requirements:**
- REQ-001: WHEN [event], the [component] SHALL [response]

## 4. API Design
[APIエンドポイント仕様]

## 5. Database Schema
[ERD図]

## 6. Security Design
[セキュリティ設計]

## 7. Sequence Diagrams
[主要フローのシーケンス図]

## 8. Technology Stack Alignment
[steering/tech.mdとの整合性確認]

## Appendix: EARS Requirements Cross-Reference
| Component | EARS Requirement | Design Section |
|-----------|------------------|----------------|
| TaskService | REQ-001 | Section 3.1 |
```

#### tasks.md / .ja.md: 実装計画と要件カバレッジマトリックス

**テンプレート構造:**
```markdown
# Tasks: Implementation Plan

## 1. Phase-Based Task Organization
### Phase 1: Backend Foundation
**Dependencies:** None
**Timeline:** Week 1-2

#### Task 1.1: [タスク名]
**Description:** [詳細説明]

**Acceptance Criteria (EARS-based):**
- WHEN [event], the [component] SHALL [response]
- IF [condition], THEN the [component] SHALL [response]

**Subtasks:**
- [ ] [サブタスク1]
- [ ] [サブタスク2]

**Requirements Mapped:** REQ-001, REQ-003
**Design References:** design.md Section 3.1

### Phase 2: Frontend Development
**Dependencies:** Phase 1 complete
**Timeline:** Week 3-4

[同様の構造]

## 2. Requirements Coverage Matrix
| Requirement | Task(s) | Status | Test Coverage |
|-------------|---------|--------|---------------|
| REQ-001 | Task 1.1, Task 2.3 | In Progress | 80% |
| REQ-002 | Task 1.2 | Completed | 100% |
| **Total Coverage** | **15/15** | **100%** | **85%** |

## 3. Team Assignments and Timeline
[ガントチャート]

## 4. Definition of Done Checklist
- [ ] Code implemented and reviewed
- [ ] Unit tests written (>80% coverage)
- [ ] Integration tests passing
- [ ] EARS requirements verified
- [ ] Documentation updated
- [ ] Deployed to staging

## Appendix: EARS-to-Test Mapping Guide
| EARS Requirement | Test Type | Example Test |
|------------------|-----------|--------------|
| WHEN user submits... | Integration | `test_create_task_with_valid_data()` |
| IF error occurs... | Unit | `test_handle_database_error()` |

トレーサビリティの実現

これらのテンプレートにより、完全なトレーサビリティが実現します。

requirements.md
  ↓ (REQ-001: WHEN user submits valid task data...)
design.md
  ↓ (Component: TaskService implements REQ-001)
tasks.md
  ↓ (Task 1.1: Implement TaskService)
src/services/TaskService.ts
  ↓ (実装コード)
tests/TaskService.test.ts
  ↓ (test_create_task_with_valid_data())

9.5 簡単なインストールと導入

musuhiの導入は驚くほど簡単です。

`npx musuhi`で即座に利用可能

インストールコマンド:

npx musuhi

実行結果:

$ npx musuhi

┌─────────────────────────────────────────┐
│                                         │
│   MUSUHI - Specification Driven Dev     │
│   むすひ (産霊) - 生成・発展・完成        │
│                                         │
└─────────────────────────────────────────┘

? Which AI tool do you use?
  ❯ Claude Code
    GitHub Copilot
    Cursor
    Windsurf IDE
    Gemini CLI
    Codex CLI
    Qwen Code

? Target directory (default: current directory)
› ./

Installing MUSUHI agents...
✓ Created steering/ directory
✓ Created .claude/ directory
✓ Installed 20 specialized agents
✓ Created CLAUDE.md configuration

🎉 Installation complete!

Next steps:
1. @steering - Bootstrap project memory
2. @requirements-analyst - Start requirements definition
3. @system-architect - Design architecture

For more information: https://github.com/nahisaho/musuhi

グローバルインストール不要:

npxで直接実行
ローカル環境を汚さない
常に最新版を使用

プロジェクトに応じたカスタマイズ性

インストール後、プロジェクトに応じてエージェントをカスタマイズできます。

例: 社内コーディング規約の追加

# code-reviewer.mdをカスタマイズ
vim .claude/agents/code-reviewer.md

# Code Reviewer AI

[既存の内容]

## Company-Specific Guidelines

### Naming Conventions
- API endpoints: `/api/v1/resources` (always versioned)
- Environment variables: `COMPANY_SERVICE_NAME_CONFIG`
- Database tables: snake_case with `tbl_` prefix

### Code Review Checklist
- [ ] All API responses include `requestId` for tracing
- [ ] Sensitive data logged with masking
- [ ] All external API calls have retry logic (max 3 retries)
- [ ] Database migrations include rollback scripts

### Security Requirements
- All JWT tokens expire in 1 hour
- Refresh tokens expire in 7 days
- API rate limit: 100 req/min per user

例: プロジェクト固有のテンプレート

# steering/templates/requirements.mdをカスタマイズ
vim steering/templates/requirements.md

# Requirements Template

[既存のセクション]

## Project-Specific Sections

### Integration Requirements
- Which internal services does this integrate with?
- What APIs are consumed?
- What events are published/subscribed?

### Compliance Requirements
- GDPR compliance needed?
- SOC 2 controls applicable?
- Data retention policy?

導入事例

スタートアップ(5人チーム):

Day 1:
- npx musuhi
- Claude Code選択
- @steering でプロジェクト分析
- steering/が自動生成

Day 2:
- @requirements-analyst でMVP要件定義
- requirements.mdが完成

Day 3:
- @system-architect で設計
- design.mdが完成

Day 4-14:
- @software-developer で実装
- @test-engineer でテスト

Day 15:
- @devops-engineer でデプロイ
- MVP リリース成功

エンタープライズ(50人チーム):

Week 1:
- 各チームがmusuhiインストール
- フロントエンドチーム: Cursor
- バックエンドチーム: Claude Code
- インフラチーム: GitHub Copilot

Week 2:
- steering/をGitで共有
- 全チームが同じコンテキストを参照

Week 3-12:
- 各チームがSDDワークフローで開発
- requirements.md, design.md, tasks.mdを共有
- 100%の要件カバレッジを維持

Week 13:
- 本番リリース
- トレーサビリティ完全保持

9.6 他のSDDツールとの比較

最後に、MUSUHIと他の主要SDDツールを包括的に比較します。

特徴	musuhi	GitHub Spec Kit	Kiro	cc-sdd	Tessl
マルチプラットフォーム	✅ 7つ	✅ 複数	❌ VS Code fork	✅ 7つ	❌ 独自
プロジェクトメモリ	✅ steering/	❌	❌	✅ あり	❌
EARS形式	✅ 完全サポート	❌	❌	一部	✅ 独自DSL
テンプレート	✅ 包括的(4種)	✅ あり	✅ あり	✅ あり	✅ DSL
エージェント数	20個	N/A	IDE組込	7個	N/A
インストール	npx 1コマンド	npm/CLI	IDE全体	npx 1コマンド	専用CLI
トレーサビリティ	✅ 完全	✅ あり	✅ あり	✅ あり	✅ あり
学習コスト	低	中	低(VS Code)	低	高(DSL)
カスタマイズ性	✅ 高	中	低	中	低
ドキュメント言語	英語/日本語	英語	英語	英語	英語
哲学	産霊(生成の力)	実行可能な仕様	ガイド付IDE	チームワークフロー	仕様ファースト
適用規模	全規模	中〜大	小〜中	全規模	中〜大
オープンソース	✅ MIT	✅ MIT	❌ Proprietary	✅ MIT	❌ Proprietary

MUSUHIの独自性:

むすひ(産霊)の哲学
- 他のツール: 機能的なアプローチ
- MUSUHI: 精神的・文化的な深みを持つコンセプト
完全なマルチプラットフォーム対応
- 7つすべてのAIツールに対応(業界最多)
- ツール移行時の資産保護
プロジェクトメモリシステム
- steering/による永続的なコンテキスト
- Steering Agentによる自動分析・同期
EARS形式の完全サポート
- 5つのパターンすべてをカバー
- 要件→テストの1:1マッピング
バイリンガル対応
- 英語・日本語両方のテンプレート
- 日本の開発者にも優しい

次章では、MUSUHIを使った実践的なSDD開発フローを、具体的な例とともに見ていきます。

MUSUHIによる仕様駆動開発(最終章)

10. MUSUHIによる仕様駆動開発(SDD)の実践

この章では、MUSUHIを使った実際の開発フローを、具体的な例とともに見ていきます。

注記: この章の実例では Claude Code の呼び出し方式（@agent-name）を使用しています。
他のAIツールをお使いの場合は、第8章の「各ツールでのエージェント呼び出し方法」表を参照して、
お使いのツールに合わせた呼び出し方法に読み替えてください。

10.1 プロジェクト開始フロー

musuhiを使ったプロジェクト開始の具体的な手順を示します。

ステップ1: musuhiエージェントのインストール

# プロジェクトディレクトリに移動
cd my-project

# musuhiをインストール
npx musuhi install

実行結果:

? Which AI tool do you use? Claude Code
? Target directory ./

Installing MUSUHI agents...
✓ Created steering/ directory
✓ Created .claude/ directory
✓ Installed 20 specialized agents
✓ Created CLAUDE.md configuration

🎉 Installation complete!

生成されるファイル構造:

my-project/
├── steering/
│   ├── structure.md (テンプレート)
│   ├── tech.md (テンプレート)
│   ├── product.md (テンプレート)
│   ├── rules/
│   │   ├── ears-format.md
│   │   ├── workflow.md
│   │   └── agent-validation-checklist.md
│   └── templates/
│       ├── requirements.md
│       ├── design.md
│       ├── tasks.md
│       └── research.md
└── .claude/
    ├── CLAUDE.md
    ├── README.md
    └── agents/
        ├── steering.md
        ├── orchestrator.md
        ├── requirements-analyst.md
        ├── system-architect.md
        └── ... (20個のエージェント)

ステップ2: プロジェクトメモリのブートストラップ

# Steering Agentを起動
@steering

Steering Agentの分析プロセス:

Steering Agent:
プロジェクトを分析しています...

[分析中]
✓ package.jsonを読み込み
  - TypeScript 5.0検出
  - Express 4.18検出
  - React 18検出
  - PostgreSQL(pg)検出

✓ src/ディレクトリ構造を分析
  - Clean Architecture構造を検出
  - domain/, application/, infrastructure/, presentation/

✓ README.mdを読み込み
  - プロジェクト名: TaskFlow
  - 目的: チーム向けタスク管理SaaS
  - 対象ユーザー: 5-50人の開発チーム

[steering/生成]
✓ structure.md: Clean Architecture, ディレクトリ構造を記録
✓ tech.md: TypeScript, Express, React, PostgreSQLを記録
✓ product.md: TaskFlow, 開発チーム向けSaaSを記録

プロジェクトメモリを初期化しました。
全エージェントがこのコンテキストを自動的に参照します。

生成されたsteering/structure.md:

# Structure: Project Architecture and Organization

## Architecture Pattern
- **Pattern**: Clean Architecture
- **Rationale**: Separation of concerns, testability, independence from frameworks

## Directory Structure

src/
├── domain/ # Business logic, entities, value objects
│ ├── entities/
│ ├── value-objects/
│ └── repositories/
├── application/ # Use cases, application services
│ ├── use-cases/
│ └── services/
├── infrastructure/ # External integrations
│ ├── database/
│ ├── api/
│ └── config/
└── presentation/ # UI, controllers
├── controllers/
└── views/


## Naming Conventions
- Files: kebab-case (e.g., `user-repository.ts`)
- Classes: PascalCase (e.g., `UserRepository`)
- Functions: camelCase (e.g., `getUserById`)
- Constants: UPPER_SNAKE_CASE (e.g., `MAX_RETRY_COUNT`)

ステップ3: 要件定義(EARS形式)

@requirements-analyst タスク管理機能の要件を定義してください

Requirements Analystとの対話:

Requirements Analyst:
タスク管理機能の要件定義を開始します。

【フェーズ1: 初回ヒアリング】

質問1/6: タスクの主要な属性は何ですか？
a) ID, タイトル, 説明のみ
b) 上記 + ステータス, 担当者
c) 上記 + 期限, 優先度
d) その他

ユーザー: c) 上記 + 期限, 優先度

質問2/6: タスクのステータスはいくつありますか？
a) 2つ(Todo, Done)
b) 3つ(Todo, In Progress, Done)
c) 4つ以上
d) カスタマイズ可能

ユーザー: b) 3つ(Todo, In Progress, Done)

... (以下、6問続く)

【フェーズ2: 詳細ヒアリング】

質問1/7: タスク作成時のバリデーションルールは？
a) タイトルのみ必須
b) タイトル + 説明必須
c) すべて必須
d) その他

ユーザー: a) タイトルのみ必須

... (以下、7問続く)

【フェーズ3: 確認】

収集した情報を要件定義書にまとめます。
EARS形式で記述します。

[steering/product.mdを参照]
- 対象ユーザー: 5-50人の開発チーム
- キーボードショートカット重視
- レスポンス時間: <500ms

これらを反映します。

【フェーズ4: 成果物生成】

requirements.mdを生成しました。

生成されたrequirements.md:

# Requirements: TaskFlow - Task Management Feature

## 1. User Stories

### US-001: Create Task
As a team member,
I want to create a task with title, description, assignee, and due date,
So that I can track work items and assign them to team members.

**Acceptance Criteria (EARS Format):**
- REQ-001: WHEN user submits task creation form with valid title (1-255 chars),
           the Task Service SHALL create new task and return task ID within 500ms
- REQ-002: IF user submits empty title,
           THEN the Form SHALL display "Title is required" error message
- REQ-003: WHEN user presses Ctrl+N keyboard shortcut,
           the UI SHALL open new task creation dialog within 100ms

### US-002: View Task List
As a team member,
I want to view all tasks assigned to me,
So that I can see what needs to be done.

**Acceptance Criteria (EARS Format):**
- REQ-004: The Task List SHALL display all user's tasks sorted by created_date descending
- REQ-005: The Task List API SHALL respond within 200ms for up to 1000 tasks
- REQ-006: WHILE task list is loading,
           the UI SHALL display loading skeleton

### US-003: Update Task Status
As a team member,
I want to update task status from Todo to In Progress to Done,
So that I can track progress.

**Acceptance Criteria (EARS Format):**
- REQ-007: WHEN user clicks status dropdown and selects new status,
           the Task Service SHALL update task status within 300ms
- REQ-008: WHEN task status changes to "Done",
           the System SHALL send notification to task creator within 1 second
- REQ-009: WHERE offline mode is enabled,
           the System SHALL queue status update for later sync

## 2. Functional Requirements (EARS Format)

### FR-001: Task CRUD Operations
- REQ-010: The Task Service SHALL support Create, Read, Update, Delete operations
- REQ-011: WHEN task is deleted,
           THEN the System SHALL perform soft delete (set deleted_at timestamp)
- REQ-012: The System SHALL NOT physically delete tasks (for audit trail)

### FR-002: Task Assignment
- REQ-013: WHEN user assigns task to another user,
           the System SHALL send email notification within 5 seconds
- REQ-014: The Task SHALL allow reassignment to different user
- REQ-015: WHEN task is reassigned,
           THEN the System SHALL log assignment history

## 3. Non-Functional Requirements

### NFR-001: Performance
- REQ-016: The Task List API SHALL respond within 200ms for 1000 tasks
- REQ-017: The Task Creation API SHALL respond within 500ms
- REQ-018: The System SHALL support 100 concurrent users per tenant

### NFR-002: Security
- REQ-019: The System SHALL authenticate all API requests using JWT
- REQ-020: The System SHALL authorize task operations (user can only view/edit assigned tasks)
- REQ-021: The System SHALL encrypt sensitive data at rest using AES-256

### NFR-003: Scalability
- REQ-022: The System SHALL support horizontal scaling to handle increased load
- REQ-023: The Database SHALL support up to 100,000 tasks per tenant

### NFR-004: Usability
- REQ-024: The UI SHALL support keyboard shortcuts for all common operations
- REQ-025: The Form SHALL provide real-time validation feedback
- REQ-026: The UI SHALL be responsive and support mobile devices (>768px width)

## 4. Requirements Traceability Matrix
| Req ID | User Story | Priority | Status | Test Coverage |
|--------|------------|----------|--------|---------------|
| REQ-001 | US-001 | Must Have | Draft | 0% |
| REQ-002 | US-001 | Must Have | Draft | 0% |
| REQ-003 | US-001 | Should Have | Draft | 0% |
| REQ-004 | US-002 | Must Have | Draft | 0% |
| REQ-005 | US-002 | Must Have | Draft | 0% |
| ... | ... | ... | ... | ... |

**Total Requirements**: 26
**Coverage**: 0/26 (0%)

## 5. MoSCoW Prioritization

**Must Have:**
- REQ-001: Task creation within 500ms
- REQ-002: Title validation
- REQ-004: Task list display
- REQ-005: Task list performance <200ms
- REQ-007: Status update
- REQ-010: CRUD operations
- REQ-016-018: Performance requirements
- REQ-019-020: Security requirements

**Should Have:**
- REQ-003: Keyboard shortcuts
- REQ-006: Loading skeleton
- REQ-008: Status change notification
- REQ-013: Assignment notification
- REQ-024: Keyboard shortcut support

**Could Have:**
- REQ-009: Offline mode
- REQ-015: Assignment history
- REQ-026: Mobile responsive

**Won't Have (this release):**
- Advanced filtering (deferred to v2)
- Gantt chart view (deferred to v2)
- Project management features (future)

ステップ4: アーキテクチャ設計(C4モデル)

@system-architect requirements.mdに基づいてタスク管理機能の設計をしてください

System Architectとの対話:

System Architect:
requirements.mdを確認しました。
[steering/structure.mdを参照] Clean Architectureを採用します。
[steering/tech.mdを参照] TypeScript, Express, PostgreSQLを使用します。

設計を開始します...

【C4モデル - Context図】
[作成中]

【C4モデル - Container図】
[作成中]

【C4モデル - Component図】
[作成中]

【コンポーネント仕様】
REQ-001, REQ-002をTaskServiceに割り当て
REQ-004, REQ-005をTaskQueryServiceに割り当て
...

design.mdを生成しました。

生成されたdesign.md(抜粋):

# Design: TaskFlow - Task Management Feature

## 1. Architecture Pattern Selection

**Selected Pattern:** Clean Architecture

**Rationale:**
- Aligns with existing project structure (steering/structure.md)
- Separation of business logic from infrastructure
- Testability: Dependencies point inward
- Framework independence

**Alternatives Considered:**
- Layered Architecture: Rejected due to tight coupling between layers
- Hexagonal Architecture: Similar to Clean Architecture, chose Clean for team familiarity

## 2. C4 Model Diagrams

### 2.1 Context Diagram
```mermaid
graph TB
    User[Team Member]
    Admin[Administrator]

    System[TaskFlow System]

    EmailService[Email Service<br/>SendGrid]
    AuthService[Auth Service<br/>JWT]
    Database[(PostgreSQL<br/>Database)]

    User -->|Manages tasks| System
    Admin -->|Configures system| System
    System -->|Sends notifications| EmailService
    System -->|Authenticates users| AuthService
    System -->|Persists data| Database
```

### 2.2 Container Diagram
```mermaid
graph TB
    WebApp[Web Application<br/>React 18]
    API[API Server<br/>Express 4.18<br/>TypeScript 5.0]
    DB[(Database<br/>PostgreSQL 15)]

    User -->|HTTPS| WebApp
    WebApp -->|REST API<br/>JSON/JWT| API
    API -->|SQL<br/>Prisma ORM| DB
```

### 2.3 Component Diagram (API Server)
```mermaid
graph TB
    Controller[Task Controller]
    CreateUseCase[Create Task Use Case]
    UpdateUseCase[Update Task Use Case]
    QueryService[Task Query Service]
    TaskRepo[Task Repository<br/>Interface]
    TaskRepoImpl[Task Repository Impl<br/>Prisma]
    Entity[Task Entity]

    Controller --> CreateUseCase
    Controller --> UpdateUseCase
    Controller --> QueryService
    CreateUseCase --> TaskRepo
    UpdateUseCase --> TaskRepo
    QueryService --> TaskRepo
    TaskRepo <|.. TaskRepoImpl
    CreateUseCase --> Entity
    UpdateUseCase --> Entity
```

## 3. Component Specifications (with EARS Mapping)

### 3.1 Component: Task Service (Create Task Use Case)
**Responsibility:** Handle task creation with validation
**Requirements Mapped:** REQ-001, REQ-002
**Dependencies:** Task Repository, Validation Service
**Technology:** TypeScript, Express

**EARS Requirements:**
- REQ-001: WHEN user submits valid title, SHALL create task within 500ms
- REQ-002: IF empty title, THEN SHALL throw ValidationError

**Implementation:**
```typescript
// src/application/use-cases/CreateTask.ts
export class CreateTaskUseCase {
  constructor(
    private taskRepository: ITaskRepository,
    private validationService: ValidationService
  ) {}

  async execute(input: CreateTaskInput): Promise<TaskId> {
    // REQ-002: Validate title
    if (!input.title || input.title.trim() === '') {
      throw new ValidationError('Title is required');
    }

    // REQ-001: Create task
    const task = new Task({
      title: input.title,
      description: input.description,
      assignee: input.assignee,
      dueDate: input.dueDate,
      status: TaskStatus.TODO
    });

    // REQ-001: Persist and return within 500ms
    const taskId = await this.taskRepository.save(task);
    return taskId;
  }
}
```

### 3.2 Component: Task Query Service
**Responsibility:** Retrieve and filter tasks
**Requirements Mapped:** REQ-004, REQ-005
**Dependencies:** Task Repository
**Technology:** TypeScript, Prisma

**EARS Requirements:**
- REQ-004: SHALL display tasks sorted by created_date descending
- REQ-005: SHALL respond within 200ms for 1000 tasks

**Implementation:**
```typescript
// src/application/services/TaskQueryService.ts
export class TaskQueryService {
  constructor(private taskRepository: ITaskRepository) {}

  async getTasksByUser(userId: string): Promise<Task[]> {
    // REQ-004: Sort by created_date descending
    // REQ-005: Optimize for <200ms with 1000 tasks
    const tasks = await this.taskRepository.findByUser(userId, {
      orderBy: { created_date: 'desc' },
      take: 1000 // Limit to prevent performance issues
    });

    return tasks;
  }
}
```

## 4. API Design

### 4.1 Endpoints (RESTful)

#### POST /api/v1/tasks
**Description:** Create new task
**Requirements:** REQ-001, REQ-002

**Request:**
```json
{
  "title": "Implement user authentication",
  "description": "Add JWT-based authentication",
  "assignee": "user-123",
  "dueDate": "2024-12-31"
}
```

**Response (201):**
```json
{
  "id": "task-456",
  "title": "Implement user authentication",
  "status": "todo",
  "created_at": "2024-11-12T10:00:00Z"
}
```

**Response (400 - Validation Error, REQ-002):**
```json
{
  "error": "ValidationError",
  "message": "Title is required"
}
```

#### GET /api/v1/tasks
**Description:** Get task list
**Requirements:** REQ-004, REQ-005

**Query Parameters:**
- `assignee`: Filter by assignee
- `status`: Filter by status

**Response (200):**
```json
{
  "tasks": [
    {
      "id": "task-456",
      "title": "Implement user authentication",
      "status": "todo",
      "assignee": "user-123",
      "created_at": "2024-11-12T10:00:00Z"
    }
  ],
  "total": 42,
  "response_time_ms": 150
}
```

## 5. Database Schema

### 5.1 ERD
```mermaid
erDiagram
    TASK {
        uuid id PK
        varchar title
        text description
        varchar status
        uuid assignee_id FK
        date due_date
        timestamp created_at
        timestamp updated_at
        timestamp deleted_at
    }
    USER {
        uuid id PK
        varchar email
        varchar name
    }
    TASK_HISTORY {
        uuid id PK
        uuid task_id FK
        varchar action
        json before_state
        json after_state
        uuid changed_by FK
        timestamp changed_at
    }

    TASK ||--o{ TASK_HISTORY : has
    USER ||--o{ TASK : assigned
    USER ||--o{ TASK_HISTORY : changed
```

### 5.2 Indexes (for REQ-005 performance)
```sql
-- For fast task list queries
CREATE INDEX idx_task_assignee_created ON tasks(assignee_id, created_at DESC);

-- For soft delete queries
CREATE INDEX idx_task_deleted_at ON tasks(deleted_at) WHERE deleted_at IS NULL;

-- For status filtering
CREATE INDEX idx_task_status ON tasks(status);
```

## 6. Security Design

### 6.1 Authentication (REQ-019)
- JWT-based authentication
- Token expiry: 1 hour
- Refresh token: 7 days

### 6.2 Authorization (REQ-020)
```typescript
// src/presentation/middleware/authorize.ts
export const authorizeTaskAccess = (req, res, next) => {
  const taskId = req.params.id;
  const userId = req.user.id;

  // Check if user is task assignee or creator
  const task = await taskRepository.findById(taskId);
  if (task.assignee !== userId && task.creator !== userId) {
    throw new ForbiddenError('Not authorized to access this task');
  }

  next();
};
```

### 6.3 Data Encryption (REQ-021)
- Database-level encryption: Azure Database for PostgreSQL (TDE)
- Application-level: Sensitive fields encrypted using AES-256

## 7. Sequence Diagrams

### 7.1 Create Task Flow (REQ-001, REQ-002)
```mermaid
sequenceDiagram
    participant User
    participant UI
    participant API
    participant UseCase
    participant Repo
    participant DB

    User->>UI: Click "Create Task"
    UI->>User: Show form
    User->>UI: Submit (title="Test")
    UI->>API: POST /api/v1/tasks
    API->>UseCase: createTask()
    UseCase->>UseCase: Validate title (REQ-002)
    UseCase->>Repo: save(task)
    Repo->>DB: INSERT INTO tasks
    DB-->>Repo: task_id
    Repo-->>UseCase: task_id
    UseCase-->>API: task_id
    API-->>UI: 201 Created
    UI-->>User: Show success message
```

## 8. Technology Stack Alignment

Verified alignment with `steering/tech.md`:
- ✅ Language: TypeScript 5.0
- ✅ Backend Framework: Express 4.18
- ✅ Database: PostgreSQL 15
- ✅ ORM: Prisma 5.x
- ✅ Authentication: JWT

## Appendix: EARS Requirements Cross-Reference

| Component | EARS Requirement | Design Section |
|-----------|------------------|----------------|
| Create Task Use Case | REQ-001: CREATE within 500ms | Section 3.1 |
| Create Task Use Case | REQ-002: VALIDATE title | Section 3.1 |
| Task Query Service | REQ-004: SORT by created_date | Section 3.2 |
| Task Query Service | REQ-005: RESPOND within 200ms | Section 3.2, 5.2 (indexes) |
| Task Controller | REQ-007: UPDATE status | Section 4.1 |
| Notification Service | REQ-008: NOTIFY on status change | Section 7.2 |
| ... | ... | ... |

**Coverage**: 26/26 requirements mapped to design components (100%)

ステップ5: タスク分解

@project-manager design.mdから実装タスクを作成してください

Project Managerとの対話:

Project Manager:
design.mdを確認しました。
要件カバレッジマトリックスを作成し、100%のカバレッジを保証します。

[フェーズ分割]
Phase 1: Backend Foundation (Week 1-2)
Phase 2: Frontend Development (Week 3-4)
Phase 3: Testing & QA (Week 5)
Phase 4: Deployment (Week 6)

tasks.mdを生成しました。

生成されたtasks.md(抜粋):

# Tasks: TaskFlow - Task Management Implementation Plan

## 1. Phase-Based Task Organization

### Phase 1: Backend Foundation
**Dependencies:** None
**Timeline:** Week 1-2 (10 working days)
**Team:** Backend Team (2 developers)

#### Task 1.1: Implement Domain Layer - Task Entity
**Description:** Create Task entity with value objects and business rules

**Acceptance Criteria (EARS-based):**
- The Task Entity SHALL have id, title, description, status, assignee, dueDate properties
- The Task Entity SHALL validate title is non-empty (REQ-002)
- The Task Entity SHALL support status transitions: TODO → IN_PROGRESS → DONE

**Subtasks:**
- [ ] Create Task entity class
- [ ] Create TaskId value object
- [ ] Create TaskStatus enum
- [ ] Implement title validation
- [ ] Write unit tests (>90% coverage)

**Requirements Mapped:** REQ-001, REQ-002, REQ-010
**Design References:** design.md Section 3.1, Section 5.1 (ERD)
**Estimated Time:** 1 day
**Assigned To:** Alice

---

#### Task 1.2: Implement Task Repository Interface and Prisma Implementation
**Description:** Create repository pattern for task persistence

**Acceptance Criteria (EARS-based):**
- The Repository SHALL support save(), findById(), findByUser(), update(), delete() operations (REQ-010)
- The findByUser() SHALL return tasks sorted by created_date DESC (REQ-004)
- The findByUser() SHALL complete within 200ms for 1000 tasks (REQ-005)

**Subtasks:**
- [ ] Define ITaskRepository interface
- [ ] Implement PrismaTaskRepository
- [ ] Create database migration script
- [ ] Add indexes for performance (design.md Section 5.2)
- [ ] Write integration tests

**Requirements Mapped:** REQ-004, REQ-005, REQ-010, REQ-011
**Design References:** design.md Section 3.1, 3.2, 5.1, 5.2
**Estimated Time:** 2 days
**Assigned To:** Bob

---

#### Task 1.3: Implement Create Task Use Case
**Description:** Implement task creation business logic

**Acceptance Criteria (EARS-based):**
- WHEN user submits valid title, SHALL create task and return ID within 500ms (REQ-001)
- IF user submits empty title, THEN SHALL throw ValidationError (REQ-002)

**Subtasks:**
- [ ] Implement CreateTaskUseCase class
- [ ] Inject TaskRepository dependency
- [ ] Implement title validation (REQ-002)
- [ ] Implement performance monitoring (must be <500ms)
- [ ] Write unit tests with mocked repository
- [ ] Write integration tests with real database

**Requirements Mapped:** REQ-001, REQ-002
**Design References:** design.md Section 3.1
**Estimated Time:** 1.5 days
**Assigned To:** Alice

**Dependencies:** Task 1.1, 1.2 must be completed

---

#### Task 1.4: Implement Task Query Service
**Description:** Implement task retrieval and filtering

**Acceptance Criteria (EARS-based):**
- The Service SHALL return tasks sorted by created_date DESC (REQ-004)
- The Service SHALL respond within 200ms for 1000 tasks (REQ-005)

**Subtasks:**
- [ ] Implement TaskQueryService class
- [ ] Implement getTasksByUser() method
- [ ] Add performance monitoring
- [ ] Benchmark with 1000 tasks (must be <200ms)
- [ ] Write unit and integration tests

**Requirements Mapped:** REQ-004, REQ-005
**Design References:** design.md Section 3.2
**Estimated Time:** 1.5 days
**Assigned To:** Bob

**Dependencies:** Task 1.2 must be completed

---

#### Task 1.5: Implement API Endpoints
**Description:** Create REST API endpoints for task operations

**Acceptance Criteria (EARS-based):**
- POST /api/v1/tasks SHALL create task (REQ-001)
- POST /api/v1/tasks SHALL return 400 if title is empty (REQ-002)
- GET /api/v1/tasks SHALL return task list (REQ-004)

**Subtasks:**
- [ ] Create TaskController
- [ ] Implement POST /api/v1/tasks endpoint
- [ ] Implement GET /api/v1/tasks endpoint
- [ ] Implement PUT /api/v1/tasks/:id endpoint
- [ ] Add error handling middleware
- [ ] Write API integration tests

**Requirements Mapped:** REQ-001, REQ-002, REQ-004, REQ-007
**Design References:** design.md Section 4.1
**Estimated Time:** 2 days
**Assigned To:** Alice

**Dependencies:** Task 1.3, 1.4 must be completed

---

### Phase 2: Frontend Development
**Dependencies:** Phase 1 complete
**Timeline:** Week 3-4 (10 working days)
**Team:** Frontend Team (2 developers)

#### Task 2.1: Implement Task Creation Form
**Description:** Create UI for task creation with keyboard shortcuts

**Acceptance Criteria (EARS-based):**
- WHEN user presses Ctrl+N, the UI SHALL open task creation dialog within 100ms (REQ-003)
- IF user submits empty title, THEN the Form SHALL display "Title is required" error (REQ-002)
- The Form SHALL send API request and display result within 500ms (REQ-001)

**Subtasks:**
- [ ] Create TaskForm component (React)
- [ ] Implement keyboard shortcut (Ctrl+N)
- [ ] Add client-side validation (REQ-002)
- [ ] Implement API integration
- [ ] Add loading state
- [ ] Write component tests (React Testing Library)

**Requirements Mapped:** REQ-001, REQ-002, REQ-003
**Design References:** design.md Section 4.1 (API), Section 3.1 (Validation)
**Estimated Time:** 2 days
**Assigned To:** Carol

---

#### Task 2.2: Implement Task List Component
**Description:** Display task list with loading skeleton

**Acceptance Criteria (EARS-based):**
- The Task List SHALL display tasks sorted by created_date DESC (REQ-004)
- WHILE task list is loading, the UI SHALL display loading skeleton (REQ-006)
- The UI SHALL render within 200ms for 1000 tasks (REQ-005)

**Subtasks:**
- [ ] Create TaskList component
- [ ] Implement loading skeleton
- [ ] Fetch tasks from API
- [ ] Implement virtual scrolling for performance
- [ ] Write component tests

**Requirements Mapped:** REQ-004, REQ-005, REQ-006
**Design References:** design.md Section 4.1 (API)
**Estimated Time:** 2 days
**Assigned To:** Dave

---

#### Task 2.3: Implement Task Status Update
**Description:** Allow status updates with dropdown

**Acceptance Criteria (EARS-based):**
- WHEN user selects new status, the UI SHALL call API within 300ms (REQ-007)
- The UI SHALL update status optimistically
- IF API fails, THEN the UI SHALL revert to previous status

**Subtasks:**
- [ ] Create StatusDropdown component
- [ ] Implement optimistic update
- [ ] Implement error rollback
- [ ] Write component tests

**Requirements Mapped:** REQ-007
**Design References:** design.md Section 4.1
**Estimated Time:** 1.5 days
**Assigned To:** Carol

---

### Phase 3: Testing & QA
**Dependencies:** Phase 2 complete
**Timeline:** Week 5 (5 working days)
**Team:** QA Team (1 QA engineer) + Developers

#### Task 3.1: End-to-End Testing
**Description:** Implement E2E tests using Playwright

**Acceptance Criteria:**
- All EARS requirements SHALL have corresponding E2E tests
- E2E test suite SHALL cover happy path and error scenarios
- E2E tests SHALL run in CI/CD pipeline

**Subtasks:**
- [ ] Setup Playwright
- [ ] Write E2E test for task creation (REQ-001, REQ-002, REQ-003)
- [ ] Write E2E test for task list (REQ-004, REQ-006)
- [ ] Write E2E test for status update (REQ-007)
- [ ] Integrate with CI/CD

**Requirements Mapped:** All requirements (REQ-001 to REQ-026)
**Estimated Time:** 3 days
**Assigned To:** Eve

---

#### Task 3.2: Performance Testing
**Description:** Verify performance requirements

**Acceptance Criteria:**
- Task creation SHALL complete within 500ms (REQ-001)
- Task list SHALL load within 200ms for 1000 tasks (REQ-005)
- Status update SHALL complete within 300ms (REQ-007)

**Subtasks:**
- [ ] Setup k6 for load testing
- [ ] Test task creation with 100 concurrent users
- [ ] Test task list with 1000 tasks
- [ ] Generate performance report

**Requirements Mapped:** REQ-001, REQ-005, REQ-007, REQ-016, REQ-017, REQ-018
**Estimated Time:** 2 days
**Assigned To:** Bob + Eve

---

### Phase 4: Deployment
**Dependencies:** Phase 3 complete
**Timeline:** Week 6 (5 working days)
**Team:** DevOps Team (1 engineer)

#### Task 4.1: Setup CI/CD Pipeline
**Description:** Automate build, test, deploy process

**Subtasks:**
- [ ] Create GitHub Actions workflow
- [ ] Add linting step
- [ ] Add unit test step
- [ ] Add integration test step
- [ ] Add E2E test step
- [ ] Add deployment to staging

**Estimated Time:** 2 days
**Assigned To:** Frank

---

#### Task 4.2: Deploy to Production
**Description:** Deploy to Azure App Service

**Subtasks:**
- [ ] Create production environment
- [ ] Setup database migration
- [ ] Deploy API server
- [ ] Deploy frontend
- [ ] Configure monitoring
- [ ] Smoke test production

**Estimated Time:** 1 day
**Assigned To:** Frank

---

## 2. Requirements Coverage Matrix

| Requirement | Task(s) | Status | Impl % | Test Coverage |
|-------------|---------|--------|--------|---------------|
| REQ-001: CREATE task <500ms | Task 1.3, 1.5, 2.1, 3.1, 3.2 | Pending | 0% | 0% |
| REQ-002: VALIDATE title | Task 1.1, 1.3, 1.5, 2.1, 3.1 | Pending | 0% | 0% |
| REQ-003: Keyboard shortcut | Task 2.1, 3.1 | Pending | 0% | 0% |
| REQ-004: SORT by date | Task 1.2, 1.4, 1.5, 2.2, 3.1 | Pending | 0% | 0% |
| REQ-005: LIST <200ms | Task 1.2, 1.4, 2.2, 3.1, 3.2 | Pending | 0% | 0% |
| REQ-006: Loading skeleton | Task 2.2, 3.1 | Pending | 0% | 0% |
| REQ-007: UPDATE status | Task 1.5, 2.3, 3.1, 3.2 | Pending | 0% | 0% |
| ... | ... | ... | ... | ... |
| **Total**: 26 requirements | **80 tasks** | **0 Complete** | **0%** | **0%** |

**Coverage**: 26/26 requirements have assigned tasks (100%)

## 3. Team Assignments and Timeline

[ガントチャート - Mermaid形式]
```mermaid
gantt
    title TaskFlow Implementation Timeline
    dateFormat  YYYY-MM-DD
    section Phase 1
    Task 1.1 Domain Layer     :done, t11, 2024-11-12, 1d
    Task 1.2 Repository       :active, t12, after t11, 2d
    Task 1.3 Create Use Case  :t13, after t12, 1.5d
    Task 1.4 Query Service    :t14, after t12, 1.5d
    Task 1.5 API Endpoints    :t15, after t13 t14, 2d

    section Phase 2
    Task 2.1 Task Form        :t21, after t15, 2d
    Task 2.2 Task List        :t22, after t15, 2d
    Task 2.3 Status Update    :t23, after t21, 1.5d

    section Phase 3
    Task 3.1 E2E Testing      :t31, after t23, 3d
    Task 3.2 Performance Test :t32, after t23, 2d

    section Phase 4
    Task 4.1 CI/CD            :t41, after t32, 2d
    Task 4.2 Production Deploy:t42, after t41, 1d
```

## 4. Definition of Done Checklist

**For each task:**
- [ ] Code implemented according to EARS requirements
- [ ] Code reviewed and approved (1 approval required)
- [ ] Unit tests written (>80% coverage for new code)
- [ ] Integration tests passing (where applicable)
- [ ] EARS requirements verified (automated tests)
- [ ] Documentation updated (inline comments, README)
- [ ] Merged to main branch
- [ ] Deployed to staging environment

**For each phase:**
- [ ] All tasks in phase complete
- [ ] Phase-level integration tests passing
- [ ] Requirements coverage matrix updated
- [ ] Stakeholder demo completed
- [ ] Phase retrospective held

## Appendix: EARS-to-Test Mapping Guide

| EARS Pattern | Test Type | Example Test Name |
|--------------|-----------|-------------------|
| WHEN [event] | Integration/E2E | `test_create_task_when_valid_title_submitted()` |
| IF [condition] THEN | Unit | `test_validation_error_if_empty_title()` |
| WHILE [state] | E2E | `test_loading_skeleton_while_fetching_tasks()` |
| WHERE [feature] | Integration | `test_offline_queue_where_offline_mode_enabled()` |
| The System SHALL | Unit/Integration | `test_task_list_sorted_by_created_date_desc()` |

---

**次のステップ:**
Task 1.1から順次実装を開始してください。
各タスク完了後、この文書を更新してください。
```

#### ステップ6-8: 実装、テスト、デプロイ

以降のステップは、tasks.mdに従って、各エージェントが支援します：

```bash
# 実装フェーズ
@software-developer Task 1.1を実装してください

# テストフェーズ
@test-engineer requirements.mdからテストケースを生成してください

# デプロイフェーズ
@devops-engineer CI/CDパイプラインをセットアップしてください

9.2 実例: タスク管理アプリケーション開発

前述のフローを実際に実行した結果を見ていきます。

実装の様子

Software Developerによる実装:

@software-developer Task 1.3「Create Task Use Case」を実装してください

Software Developer:

[steering/structure.mdを参照]
→ Clean Architectureに従います
→ src/application/use-cases/に配置します

[steering/tech.mdを参照]
→ TypeScript 5.0を使用します
→ SOLID原則に従います

[requirements.mdのREQ-001, REQ-002を参照]
→ WHEN valid title → CREATE within 500ms
→ IF empty title → THEN throw ValidationError

[design.md Section 3.1を参照]
→ ITaskRepository依存
→ ValidationService依存

実装を開始します...

生成されたコード:

// src/application/use-cases/CreateTask.ts

import { Task } from '../../domain/entities/Task';
import { TaskId } from '../../domain/value-objects/TaskId';
import { ITaskRepository } from '../../domain/repositories/ITaskRepository';
import { ValidationError } from '../errors/ValidationError';

/**
 * Create Task Use Case
 *
 * Requirements:
 * - REQ-001: WHEN user submits valid title, SHALL create task within 500ms
 * - REQ-002: IF user submits empty title, THEN SHALL throw ValidationError
 *
 * Design Reference: design.md Section 3.1
 */
export class CreateTaskUseCase {
  constructor(private readonly taskRepository: ITaskRepository) {}

  /**
   * Execute task creation
   *
   * @param input - Task creation input
   * @returns Task ID
   * @throws ValidationError if title is empty (REQ-002)
   */
  async execute(input: CreateTaskInput): Promise<TaskId> {
    const startTime = Date.now();

    // REQ-002: Validate title
    if (!input.title || input.title.trim() === '') {
      throw new ValidationError('Title is required');
    }

    // Create task entity
    const task = new Task({
      title: input.title,
      description: input.description,
      assignee: input.assignee,
      dueDate: input.dueDate,
      status: TaskStatus.TODO
    });

    // REQ-001: Save task
    const taskId = await this.taskRepository.save(task);

    // Performance monitoring (must be <500ms)
    const duration = Date.now() - startTime;
    if (duration > 500) {
      console.warn(`[PERFORMANCE] Task creation took ${duration}ms (threshold: 500ms)`);
    }

    return taskId;
  }
}

export interface CreateTaskInput {
  title: string;
  description?: string;
  assignee?: string;
  dueDate?: Date;
}

コメントに要件IDが記載され、トレーサビリティが確保されています：

src/application/use-cases/CreateTask.ts:8
  ← requirements.md REQ-001, REQ-002
    ← design.md Section 3.1
      ← tasks.md Task 1.3

Test Engineerによるテスト生成

@test-engineer requirements.mdのREQ-001, REQ-002からテストケースを生成してください

Test Engineer:

[requirements.mdを参照]
- REQ-001: WHEN valid title → CREATE within 500ms
- REQ-002: IF empty title → THEN ValidationError

EARS形式から直接テストケースを生成します...

生成されたテストコード:

// tests/application/use-cases/CreateTask.test.ts

import { CreateTaskUseCase } from '../../../src/application/use-cases/CreateTask';
import { ValidationError } from '../../../src/application/errors/ValidationError';
import { InMemoryTaskRepository } from '../../mocks/InMemoryTaskRepository';

describe('CreateTaskUseCase', () => {
  let useCase: CreateTaskUseCase;
  let taskRepository: InMemoryTaskRepository;

  beforeEach(() => {
    taskRepository = new InMemoryTaskRepository();
    useCase = new CreateTaskUseCase(taskRepository);
  });

  /**
   * Test for REQ-001: WHEN user submits valid title,
   * the System SHALL create task within 500ms
   */
  describe('REQ-001: Create task with valid title within 500ms', () => {
    it('should create task and return task ID when valid title is provided', async () => {
      // Arrange
      const input = {
        title: 'Implement user authentication',
        description: 'Add JWT-based authentication',
        assignee: 'user-123',
        dueDate: new Date('2024-12-31')
      };

      // Act
      const startTime = Date.now();
      const taskId = await useCase.execute(input);
      const duration = Date.now() - startTime;

      // Assert
      expect(taskId).toBeDefined();
      expect(taskId.value).toMatch(/^task-/);

      // REQ-001: Must complete within 500ms
      expect(duration).toBeLessThan(500);

      // Verify task was saved
      const savedTask = await taskRepository.findById(taskId);
      expect(savedTask.title).toBe(input.title);
      expect(savedTask.description).toBe(input.description);
    });

    it('should create task within 500ms even with long description', async () => {
      const input = {
        title: 'Test task',
        description: 'A'.repeat(10000) // 10KB description
      };

      const startTime = Date.now();
      await useCase.execute(input);
      const duration = Date.now() - startTime;

      expect(duration).toBeLessThan(500);
    });
  });

  /**
   * Test for REQ-002: IF user submits empty title,
   * THEN the Form SHALL display "Title is required" error
   */
  describe('REQ-002: Validation error if empty title', () => {
    it('should throw ValidationError when title is empty string', async () => {
      // Arrange
      const input = {
        title: '',
        description: 'Some description'
      };

      // Act & Assert
      await expect(useCase.execute(input)).rejects.toThrow(ValidationError);
      await expect(useCase.execute(input)).rejects.toThrow('Title is required');
    });

    it('should throw ValidationError when title is only whitespace', async () => {
      const input = {
        title: '   ',
        description: 'Some description'
      };

      await expect(useCase.execute(input)).rejects.toThrow(ValidationError);
    });

    it('should throw ValidationError when title is null', async () => {
      const input = {
        title: null as any,
        description: 'Some description'
      };

      await expect(useCase.execute(input)).rejects.toThrow(ValidationError);
    });

    it('should throw ValidationError when title is undefined', async () => {
      const input = {
        title: undefined as any,
        description: 'Some description'
      };

      await expect(useCase.execute(input)).rejects.toThrow(ValidationError);
    });
  });

  /**
   * Edge case tests
   */
  describe('Edge cases', () => {
    it('should handle maximum title length (255 chars)', async () => {
      const input = {
        title: 'A'.repeat(255)
      };

      const taskId = await useCase.execute(input);
      expect(taskId).toBeDefined();
    });

    it('should trim whitespace from title', async () => {
      const input = {
        title: '  Test Task  '
      };

      const taskId = await useCase.execute(input);
      const savedTask = await taskRepository.findById(taskId);

      expect(savedTask.title).toBe('Test Task');
    });
  });
});

EARS要件が直接テストケースに変換されています：

REQ-001: WHEN valid title → CREATE within 500ms
  ↓
test: 'should create task within 500ms when valid title is provided'
  ↓
expect(duration).toBeLessThan(500);

REQ-002: IF empty title → THEN ValidationError
  ↓
test: 'should throw ValidationError when title is empty'
  ↓
expect(...).rejects.toThrow(ValidationError);

トレーサビリティの完全な実現

最終的に、以下の完全なトレーサビリティが実現されました：

requirements.md
├─ REQ-001: WHEN user submits valid title, SHALL create within 500ms
│  ↓
├─ design.md
│  ├─ Section 3.1: Create Task Use Case
│  └─ Section 7.1: Sequence Diagram
│     ↓
├─ tasks.md
│  └─ Task 1.3: Implement Create Task Use Case
│     ↓
├─ src/application/use-cases/CreateTask.ts:8
│  └─ // REQ-001: WHEN user submits valid title...
│     ↓
└─ tests/application/use-cases/CreateTask.test.ts:18
   └─ describe('REQ-001: Create task with valid title within 500ms')
      └─ expect(duration).toBeLessThan(500);

要件 → 設計 → タスク → 実装 → テスト
すべてが完全にトレース可能

要件カバレッジマトリックス(最終):

Requirement	Tasks	Code	Tests	Status
REQ-001	Task 1.3, 1.5, 2.1	CreateTask.ts:8	CreateTask.test.ts:18	✅ Pass
REQ-002	Task 1.3, 1.5, 2.1	CreateTask.ts:23	CreateTask.test.ts:48	✅ Pass
REQ-003	Task 2.1	TaskForm.tsx:35	TaskForm.test.tsx:25	✅ Pass
REQ-004	Task 1.4, 2.2	TaskQueryService.ts:12	TaskQuery.test.ts:15	✅ Pass
REQ-005	Task 1.2, 1.4, 2.2	schema.prisma:25	Performance.test.ts:10	✅ Pass
...	...	...	...	...

Total Coverage: 26/26 requirements (100%)
Test Coverage: 85% (目標80%達成)

9.3 プロジェクトメモリの活用シーン

6ヶ月後の新メンバーオンボーディング

シナリオ:
6ヶ月後、新しいメンバー(George)がチームに参加しました。

従来(steering/なし):

George: 「このプロジェクトのアーキテクチャパターンは？」
Alice: 「Clean Architectureです」

George: 「ディレクトリ構造は？」
Alice: 「src/domain, src/application, src/infrastructure, src/presentationです」

George: 「技術スタックは？」
Alice: 「TypeScript, Express, React, PostgreSQLです」

George: 「なぜPostgreSQLを選んだんですか？」
Alice: 「えーっと...確か...ドキュメントどこだっけ...」

→ 30分の説明が必要

musuhi(steering/あり):

George: 「プロジェクトの概要を知りたいです」
Senior: 「@steering reviewを実行してください」

@steering review
Steering Agent:
【アーキテクチャ】
- Clean Architecture
- 理由: テスタビリティ、フレームワーク独立性

【技術スタック】
- TypeScript 5.0: 型安全性、最新機能
- Express 4.18: 軽量、柔軟性
- PostgreSQL 15: ACID準拠、JSON対応、チームの専門性

【製品概要】
- TaskFlow: 開発チーム向けタスク管理SaaS
- 対象: 5-50人の開発チーム
- キーボードショートカット重視

George: 「わかりました!すぐに開発開始できます」

→ 5分で完全に理解

プロジェクトの技術スタック更新

シナリオ:
PostgreSQL 14から15へのアップグレードが完了しました。

従来:

開発者: PostgreSQL 15にアップグレード完了
       でも、ドキュメント更新するの忘れた...

6ヶ月後...
新メンバー: 「PostgreSQL 14って書いてあるけど、実際は15ですよね？」
→ ドキュメントと実装の乖離

musuhi:

開発者: PostgreSQL 15にアップグレード完了

@steering
Steering Agent:
[ドリフト検出]
- tech.md: PostgreSQL 14
- package.json: pg@8.11.0 (PostgreSQL 15対応)
- 不整合を検出しました

[steering/tech.mdを更新]
- PostgreSQL 14 → 15

プロジェクトメモリを同期しました。

結果:

ドキュメントが常に最新
新メンバーが誤った情報を参照しない
技術的負債が蓄積しない

9.4 EARS形式の実践効果

曖昧な要件 vs EARS形式の比較

実際のプロジェクトでの効果測定:

指標	曖昧な要件	EARS形式	改善率
要件の解釈のブレ	42%	3%	-93%
テストケース作成時間	2時間/要件	30分/要件	-75%
バグ発見率(テストで)	65%	92%	+42%
要件変更時の影響分析時間	1.5時間	15分	-83%
テストカバレッジ	68%	95%	+40%

実際の要件変更への対応

シナリオ:
「タスク作成時のレスポンス時間を500msから300msに短縮してほしい」

EARS形式:

変更前:
REQ-001: WHEN user submits valid title, SHALL create within 500ms

変更後:
REQ-001: WHEN user submits valid title, SHALL create within 300ms

影響分析(自動):

$ grep -r "REQ-001" .

requirements.md:12: REQ-001: WHEN user submits valid title, SHALL create within 300ms
design.md:45: // Component implements REQ-001
tasks.md:78: Task 1.3 implements REQ-001
src/application/use-cases/CreateTask.ts:8: // REQ-001
tests/application/use-cases/CreateTask.test.ts:18: describe('REQ-001')

影響範囲:
- design.md: 確認のみ(変更不要)
- tasks.md: Task 1.3の受入基準を更新
- src/application/use-cases/CreateTask.ts: パフォーマンス閾値を500→300に変更
- tests/application/use-cases/CreateTask.test.ts: expect(duration).toBeLessThan(300);

修正作業:

// Before
if (duration > 500) {
  console.warn(`[PERFORMANCE] Task creation took ${duration}ms (threshold: 500ms)`);
}
expect(duration).toBeLessThan(500);

// After
if (duration > 300) {
  console.warn(`[PERFORMANCE] Task creation took ${duration}ms (threshold: 300ms)`);
}
expect(duration).toBeLessThan(300);

所要時間:

影響分析: 5分(grepで即座に特定)
修正作業: 10分(4箇所のみ)
テスト実行: 5分
合計: 20分

従来(曖昧な要件):

影響分析: 1.5時間(どこに影響するか不明確)
修正作業: 1時間(見落としが多い)
テスト実行: 30分(何をテストすべきか不明確)
合計: 3時間

改善率: -83%の時間削減

11. まとめ

11.1 仕様駆動開発の重要性

本記事では、AI時代における仕様駆動開発(SDD)の重要性と、MUSUHIツールによる実践方法を見てきました。

AI時代における体系的アプローチの必要性

AIコーディングツールは、驚くべき速度でコードを生成できます。しかし、「何を作るべきか」が曖昧なままでは、高速に間違ったコードを量産するだけです。

Vibe Codingの限界:

直感的で楽しいが、一貫性に欠ける
セッション間でコンテキストが失われる
チーム開発では破綻しやすい

SDDの強み:

仕様が「AIへの明確な指示書」として機能
プロジェクトメモリが「セッション間の記憶」として機能
EARS形式が「曖昧性を排除」

結論:
AI時代だからこそ、仕様駆動開発が重要です。AIの高速性と、SDDの体系性を組み合わせることで、スピードと品質の両立が可能になります。

大規模プロジェクトでの品質保証

小規模プロジェクト(1-2人、1-2週間)では、Vibe Codingでも十分かもしれません。しかし、大規模プロジェクトでは：

課題:

複数人の実装がバラバラ
要件の抜け漏れ
テストカバレッジ不足
ドキュメントと実装の乖離

SDDによる解決:

要件カバレッジマトリックスで100%保証
EARS形式で要件→テストの1:1マッピング
steering/でプロジェクト全体の一貫性維持
トレーサビリティで変更の影響範囲を即座に特定

実績:

テストカバレッジ: 68% → 95% (+40%)
バグ発見率: 65% → 92% (+42%)
要件変更対応時間: 3時間 → 20分 (-83%)

チーム開発における一貫性の維持

チーム開発では、各メンバーが同じ理解のもとで開発する必要があります。

従来の課題:

口頭での説明に依存(伝言ゲーム化)
ドキュメントが古い(実装と乖離)
新メンバーのオンボーディングに時間がかかる

MUSUHIによる解決:

steering/がプロジェクトの「唯一の真実の源」
Steering Agentが自動的に同期
新メンバーは@steering reviewで即座に理解

実績:

オンボーディング時間: 30分 → 5分 (-83%)
アーキテクチャ理解度: 50% → 95% (+90%)

長期的な保守性の確保

ソフトウェアは、書いた瞬間から「レガシーコード」になり始めます。6ヶ月後、1年後も保守できるか？

従来の課題:

「なぜこう実装したか」が不明
要件が見つからない
変更の影響範囲が分からない

MUSUHIによる解決:

完全なトレーサビリティ(要件↔設計↔コード↔テスト)
steering/に設計判断の根拠を記録
EARS形式で要件が明確

実績:

6ヶ月後のコード理解時間: 2時間 → 15分 (-87%)
変更の影響分析時間: 1.5時間 → 5分 (-94%)

11.2 MUSUHIがもたらす価値

マルチプラットフォーム対応による柔軟性

7つのAIツールすべてに対応:

Claude Code, GitHub Copilot, Cursor, Windsurf IDE
Gemini CLI, Codex CLI, Qwen Code

価値:

ツール選択の自由
ツール移行時の資産保護
チーム内で異なるツールを使用可能

実績:

ツール移行時の学習コスト: ゼロ
資産の再利用率: 100%

プロジェクトメモリによる一貫性

steering/システム:

structure.md: アーキテクチャ、ディレクトリ構造
tech.md: 技術スタック、フレームワーク
product.md: ビジネスコンテキスト、製品目的

Steering Agent:

自動分析: コードベースからsteering/を生成
自動同期: コード変更を検出してsteering/を更新
レビュー: 現在のプロジェクトメモリを表示

価値:

セッション間でのコンテキスト維持
新メンバーのオンボーディング高速化
プロジェクト全体の一貫性保証

EARS形式による検証可能性

5つのパターン:

Event-Driven, State-Driven, Unwanted Behavior, Optional Features, Ubiquitous

価値:

要件の曖昧性を完全排除
要件→テストの1:1マッピング
自動テスト生成が容易

実績:

要件の解釈のブレ: 42% → 3% (-93%)
テストケース作成時間: 2時間 → 30分 (-75%)

テンプレートによる生産性向上

4つの包括的テンプレート:

research.md: 技術調査
requirements.md: 要件定義(EARS形式)
design.md: 設計(C4モデル)
tasks.md: 実装計画(要件カバレッジマトリックス)

価値:

ドキュメント作成時間の短縮
標準化されたフォーマット
抜け漏れの防止

実績:

要件定義書作成時間: 4時間 → 1.5時間 (-62%)
設計書作成時間: 6時間 → 2時間 (-67%)

11.3 「産霊(むすひ)」の力 - プロジェクトに生命を

20個のエージェントという「多数の神」の化生

神話におけるホムスビ(火産霊)は、斬り殺されてもなお多数の神を生み出しました。MUSUHIの20個のエージェントも、それぞれが専門領域で「創造の力」を発揮します。

エージェントの「化生」:

Orchestrator (統括神)
  ↓ 生み出す
Requirements Analyst (要件の神)
  ↓ 生み出す
System Architect (設計の神)
  ↓ 生み出す
Software Developer (実装の神)
  ↓ 生み出す
Test Engineer (検証の神)
  ↓ 生み出す
DevOps Engineer (展開の神)

1つの要件から、多数の成果物が「自然に」生まれ出る。これがむすひの「生成(むす)」の力です。

プロジェクトメモリによる「生命の連続性」

神話におけるタマツメムスビ(玉積産日神)は、魂を体に留める(鎮魂)働きをします。MUSUHIのsteering/システムも、プロジェクトの「魂(コンテキスト)」を留めます。

プロジェクトの魂:

structure.md: プロジェクトのアーキテクチャの魂
tech.md: 技術選定の魂
product.md: ビジネス目的の魂

生命の連続性:

6ヶ月前のプロジェクト
  ↓ steering/に魂が記録
6ヶ月後の新メンバー
  ↓ steering/から魂を読み込む
プロジェクトの魂が継承される

プロジェクトは「死なない」。知識は「継承される」。これがむすひの「生命の連続性」です。

開発者とAIの協創による「新しい創造の形」

神話におけるタカミムスビは、衰えようとする魂を奮い立たせました。MUSUHIも、停滞したプロジェクトに新しい活力を与えます。

停滞したプロジェクト:

6ヶ月放置されたレガシーコード
  ↓ コンテキスト喪失、保守不能
@steering (Steering Agentを起動)
  ↓ コードベースを分析
steering/が生成される
  ↓ プロジェクトの意図が復元
開発再開が可能に

AIと人間の協創:

開発者: 「何を作りたいか」(意図)
  ↓
AI: 「どう実装するか」(実現)
  ↓
MUSUHI: 両者をつなぎ、一貫性を保つ(むすひ)

人間の創造性とAIの高速性を「結び」、新しい価値を「生み出す」。これが「産霊(むすひ)」の本質です。

むすひの働き = ソフトウェア開発の本質

「むす(産)」= 自然に発生する:

無理やり作るのではなく、仕様から「自然に」実装が生まれる
要件から「自然に」テストが生まれる
設計から「自然に」コードが生まれる

「ひ(霊)」= 霊的・神秘的な働き:

目に見えないコンテキストが、プロジェクト全体を導く
steering/という「魂」が、すべてのエージェントを統合
トレーサビリティという「糸」が、すべてを結びつける

「生成・発展・完成」:

生成: 要件定義→設計→コード→テスト
発展: 継続的な改善、リファクタリング
完成: 品質ゲートを経て、本番リリース

11.4 今後の展望

コミュニティによるエージェントの拡張

MUSUHIはオープンソース(MIT)です。コミュニティによる拡張を歓迎します。

拡張可能性:

カスタムエージェントの追加
ドメイン特化型エージェント(金融、医療、etc)
多言語対応の拡充

貢献方法:

# エージェントテンプレートをカスタマイズ
cp .claude/agents/software-developer.md .claude/agents/mobile-developer.md
# 編集して、Pull Request

# コミュニティに共有

より多くのプラットフォームへの対応

現在7つのAIツールに対応していますが、さらに拡大予定：

検討中:

Amazon CodeWhisperer
Tabnine
Replit Ghostwriter
その他の新しいAIコーディングツール

エンタープライズ向け機能の追加

企業利用を想定した機能拡充：

計画中:

チーム管理機能(ロール、権限管理)
監査ログ(誰が何をいつ変更したか)
カスタムテンプレート管理(企業標準テンプレート)
SSO統合(SAML, OAuth)

11.5 読者へのメッセージ

MUSUHIを試す

今すぐ始められます

npx musuhi install

最初のステップ:

npx musuhiでインストール
@steeringでプロジェクトメモリを生成
@requirements-analystで要件定義
SDDワークフローで開発開始

所要時間:

インストール: 10秒
steering/生成: 2分
要件定義: 30分〜1時間
合計: 1時間以内で、SDD開始可能

フィードバックと貢献の呼びかけ

GitHub:

リポジトリ: https://github.com/nahisaho/musuhi
Issues: バグ報告、機能リクエスト
Pull Requests: コントリビューション歓迎
Discussions: 使い方の質問、議論

貢献方法:

エージェントテンプレートの改善
ドキュメントの翻訳(多言語化)
新しいプラットフォーム対応
バグ修正

仕様駆動開発の未来へ

Vibe Codingの直感性と、仕様駆動開発の体系性。
この両者を統合し、AI時代の新しいソフトウェア開発を実現する。
それがMUSUHIの目指す未来です。

むすひ(産霊)は、天地・万物を生み出し、成長させる霊妙な力です。
MUSUHIツールは、その名の通り、あなたのプロジェクトに生命を吹き込み、
成長させ、完成へと導く力となることを目指しています。

ぜひ、あなたのプロジェクトでMUSUHIを試してみてください。
そして、プロジェクトに新しい生命が宿るのを体験してください。

むすひ(産霊) - 天地・万物を生成・発展・完成させる霊的な働き

MUSUHI - プロジェクトに生命を吹き込むツール

付録

A. musuhiインストールガイド

基本インストール

# npxで直接実行(推奨)
npx musuhi install

プラットフォーム別インストール

Claude Code:

npx musuhi install --tool claude-code
# → .claude/agents/ にインストール
# → CLAUDE.md が生成される

GitHub Copilot:

npx musuhi install --tool github-copilot
# → .github/agents/ にインストール
# → .github/copilot-instructions.md が生成される

Cursor:

npx musuhi install --tool cursor
# → .cursor/agents/ にインストール
# → .cursorrules が生成される

Windsurf IDE:

npx musuhi install --tool windsurf
# → .windsurf/agents/ にインストール
# → .windsurfrules が生成される

Gemini CLI:

npx musuhi install --tool gemini-cli
# → .gemini/agents/ にインストール
# → gemini-config.md が生成される

Codex CLI:

npx musuhi install --tool codex-cli
# → .codex/agents/ にインストール
# → codex-config.md が生成される

Qwen Code:

npx musuhi install --tool qwen-code
# → .qwen/agents/ にインストール
# → qwen-config.md が生成される

カスタムディレクトリ指定

# 特定のディレクトリにインストール
npx musuhi install --tool claude-code --dir /path/to/project

B. エージェント一覧と使い分け

オーケストレーション

Orchestrator(統括管理者)

@orchestrator タスク管理Webアプリを開発。要件定義から開始。

用途: 複雑なプロジェクト全体の統括
自動的に適切なエージェントを選択・連携

Steering Agent(プロジェクトメモリ管理)

@steering  # Bootstrap mode
@steering  # Sync mode (コードベース変更後)
@steering review  # Review mode

用途: プロジェクトメモリの管理
steering/の生成・更新・確認

要件定義・計画

Requirements Analyst(要件アナリスト)

@requirements-analyst タスク管理機能の要件を定義

用途: 要件定義、ユーザーストーリー作成
出力: requirements.md(EARS形式)

Project Manager(プロジェクトマネージャー)

@project-manager design.mdから実装タスクを作成

用途: タスク分解、スケジューリング
出力: tasks.md(要件カバレッジマトリックス付き)

アーキテクチャ・設計

System Architect(システムアーキテクト)

@system-architect requirements.mdに基づいて設計

用途: アーキテクチャ設計、C4モデル図作成
出力: design.md(C4モデル、ADR)

API Designer(API設計者)

@api-designer ユーザー認証APIを設計

用途: REST/GraphQL/gRPC API設計
出力: OpenAPI 3.0仕様書

Database Schema Designer(DB設計者)

@database-schema-designer API仕様からDBスキーマを設計

用途: ER図、DDL生成、インデックス設計
出力: ER図(Mermaid)、DDL(SQL)

UI/UX Designer(UI/UXデザイナー)

@uiux-designer タスク管理画面のUIを設計

用途: ワイヤーフレーム、デザインシステム
出力: ワイヤーフレーム、デザイントークン

開発・実装

Software Developer(ソフトウェア開発者)

@software-developer Task 1.3を実装

用途: コード実装(TypeScript, Python, Java, Go, etc)
出力: 実装コード、ユニットテスト

Test Engineer(テストエンジニア)

@test-engineer requirements.mdからテストケースを生成

用途: ユニット、統合、E2Eテスト
出力: テストコード(Jest, Pytest, Playwright, etc)

品質・レビュー

Code Reviewer(コードレビュアー)

@code-reviewer src/application/use-cases/をレビュー

用途: コード品質、SOLID原則、セキュリティレビュー
出力: レビューコメント、改善提案

Bug Hunter(バグハンター)

@bug-hunter ログイン失敗問題を調査

用途: バグ調査、根本原因分析
出力: 原因分析レポート、修正コード

Quality Assurance(品質保証)

@quality-assurance テスト戦略を策定

用途: QA戦略、品質メトリクス
出力: テスト計画書、品質メトリクスダッシュボード

セキュリティ・パフォーマンス

Security Auditor(セキュリティ監査)

@security-auditor 認証・認可実装を監査

用途: OWASP Top 10チェック、脆弱性検出
出力: セキュリティ監査レポート、修正提案

Performance Optimizer(パフォーマンス最適化)

@performance-optimizer タスク一覧APIを最適化

用途: ボトルネック検出、最適化提案
出力: パフォーマンスレポート、最適化コード

インフラ・運用

DevOps Engineer(DevOpsエンジニア)

@devops-engineer CI/CDパイプラインをセットアップ

用途: CI/CD構築、Docker/Kubernetes
出力: GitHub Actions workflow、Dockerfile、K8s manifests

Cloud Architect(クラウドアーキテクト)

@cloud-architect AWSアーキテクチャを設計

用途: AWS/Azure/GCPアーキテクチャ設計
出力: IaCコード(Terraform, Bicep)、アーキテクチャ図

Database Administrator(データベース管理者)

@database-administrator パフォーマンスチューニング

用途: DB運用、パフォーマンスチューニング
出力: チューニング提案、バックアップ戦略

ドキュメント・特殊領域

Technical Writer(テクニカルライター)

@technical-writer API仕様書を作成

用途: 技術文書、APIドキュメント
出力: README、ユーザーガイド、API仕様書

AI/ML Engineer(AI/MLエンジニア)

@ai-ml-engineer レコメンドモデルを開発

用途: 機械学習モデル開発、MLOps
出力: モデルコード、トレーニングパイプライン

C. EARS形式クイックリファレンス

5つのパターン完全ガイド

1. Event-Driven(イベント駆動)

形式:

WHEN [trigger event], the [system name] SHALL [system response]

例:

WHEN user clicks "Submit" button with valid data,
the Order System SHALL create order within 500ms

テストケース:

it('should create order within 500ms when submit is clicked with valid data', async () => {
  const startTime = Date.now();
  await orderSystem.createOrder(validData);
  expect(Date.now() - startTime).toBeLessThan(500);
});

2. State-Driven(状態駆動)

形式:

WHILE [system state], the [system name] SHALL [system response]

例:

WHILE payment is processing,
the Checkout UI SHALL display loading spinner

テストケース:

it('should display spinner while payment is processing', () => {
  render(<Checkout paymentStatus="processing" />);
  expect(screen.getByTestId('loading-spinner')).toBeInTheDocument();
});

3. Unwanted Behavior(望ましくない動作)

形式:

IF [unwanted condition], THEN the [system name] SHALL [system response]

例:

IF network connection is lost,
THEN the App SHALL display "Connection error" message

テストケース:

it('should display connection error when network is lost', async () => {
  mockNetworkError();
  render(<App />);
  await waitFor(() => {
    expect(screen.getByText('Connection error')).toBeInTheDocument();
  });
});

4. Optional Features(オプション機能)

形式:

WHERE [feature is included], the [system name] SHALL [system response]

例:

WHERE dark mode is enabled,
the UI SHALL use dark color scheme

テストケース:

it('should use dark color scheme when dark mode is enabled', () => {
  render(<App darkMode={true} />);
  expect(document.body).toHaveClass('theme-dark');
});

5. Ubiquitous(遍在的)

形式:

The [system name] SHALL [system response]

例:

The User Service SHALL encrypt all passwords using bcrypt with cost factor 12

テストケース:

it('should encrypt passwords using bcrypt cost 12', async () => {
  const user = await userService.createUser({ password: 'test123' });
  const rounds = await bcrypt.getRounds(user.passwordHash);
  expect(rounds).toBe(12);
});

禁止される曖昧な表現

曖昧な表現	問題点	EARS変換例
「〜できる」	義務ではない	`The System SHALL...`
「〜すべき」(should)	曖昧	`The System SHALL...`
「高速」	数値不明	`SHALL respond within 200ms`
「適切に」	基準不明	`SHALL return HTTP 503`
「ユーザーフレンドリー」	測定不可	`SHALL respond within 100ms`

D. 参考リンク

神道・むすひ関連

『古事記』
『日本書紀』
『古語拾遺』
本居宣長『古事記伝』

おわりに

本記事を最後までお読みいただき、ありがとうございました。

MUSUHIは、AI時代のソフトウェア開発に「むすひ(産霊)」の力を吹き込むツールです。

あなたのプロジェクトに生命を吹き込み、成長させ、完成へと導く。
そんな存在になれれば幸いです。

ぜひ、MUSUHIを試してみてください。
そして、フィードバックをお寄せください。

MUSUHI - プロジェクトに生命を吹き込むツール

著者: Hisaho Nakata
GitHub: https://github.com/nahisaho/musuhi

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up