musubix 3.6.0 → 3.6.1

package/docs/MUSUBIXv2.2.0-Manual.md

@@ -0,0 +1,3123 @@
+# MUSUBIX: Neuro-Symbolic AI Coding システムによるエンタープライズアプリケーション開発入門
+
+:::note info
+**Version**: 2.2.0 | **Date**: 2026-01-09 | **Author**: MUSUBIX Development Team
+:::
+
+---
+
+## 目次
+
+- [Part 1: イントロダクション](#part-1-イントロダクション)
+  - [1. 従来のAIコーディングの限界](#1-従来のaiコーディングの限界)
+  - [2. SDD（Specification Driven Development）の課題](#2-sddspecification-driven-developmentの課題)
+  - [3. MUSUBIXとは](#3-musubixとは)
+  - [4. エンタープライズ開発に必要な要素](#4-エンタープライズ開発に必要な要素)
+- [Part 2: 経費精算システム開発](#part-2-経費精算システム開発)
+  - [5. プロジェクト初期化](#5-プロジェクト初期化)
+  - [6. 要件定義](#6-要件定義)
+  - [7. 設計](#7-設計)
+  - [8. タスク分解](#8-タスク分解)
+  - [9. コード生成](#9-コード生成)
+  - [10. セキュリティ分析](#10-セキュリティ分析)
+  - [11. 形式検証](#11-形式検証)
+  - [12. テスト生成](#12-テスト生成)
+  - [13. トレーサビリティ](#13-トレーサビリティ)
+- [Part 3: 高度な機能](#part-3-高度な機能)
+  - [14. 説明生成](#14-説明生成)
+  - [15. 自己学習システム](#15-自己学習システム)
+  - [16. オントロジー](#16-オントロジー)
+  - [17. プログラム合成](#17-プログラム合成)
+  - [18. ライブラリ学習](#18-ライブラリ学習)
+- [Part 4: チーム開発・運用](#part-4-チーム開発運用)
+  - [19. KGPR（知識グラフPull Request）](#19-kgpr知識グラフpull-request)
+  - [20. REPL対話モード](#20-repl対話モード)
+  - [21. 学習データの共有](#21-学習データの共有)
+- [Part 5: まとめ](#part-5-まとめ)
+  - [22. MUSUBIXで実現するエンタープライズ品質](#22-musubixで実現するエンタープライズ品質)
+  - [23. 次のステップ](#23-次のステップ)
+- [付録](#付録)
+  - [A. MUSUBIX 9条憲法](#付録a-musubix-9条憲法)
+  - [B. CLIコマンド完全リファレンス](#付録b-cliコマンド完全リファレンス)
+  - [C. EARSパターン早見表](#付録c-earsパターン早見表)
+  - [D. プロジェクト構成](#付録d-プロジェクト構成)
+  - [E. 設計パターンカタログ](#付録e-設計パターンカタログ)
+  - [F. トレーサビリティID体系](#付録f-トレーサビリティid体系)
+  - [G. SMT-LIB2 / Z3 クイックリファレンス](#付録g-smt-lib2--z3-クイックリファレンス)
+  - [H. 用語集](#付録h-用語集)
+  - [I. トラブルシューティング](#付録i-トラブルシューティング)
+
+---
+
+# Part 1: イントロダクション
+
+## 1. 従来のAIコーディングの限界
+
+### 1.1 Vibe Coding（雰囲気コーディング）の問題点
+
+「Vibe Coding」とは、明確な仕様や設計なしに、AIに対して曖昧な指示を与えてコードを生成するスタイルです。
+
+```
+ユーザー: 「いい感じの経費精算システム作って」
+AI: （なんとなく動くコードを生成）
+```
+
+**問題点:**
+
+| 問題 | 説明 | エンタープライズへの影響 |
+|------|------|------------------------|
+| **再現性がない** | 同じ指示でも異なるコードが生成される | 品質管理が不可能 |
+| **仕様が不明** | 何を作ったのか後から分からない | 保守・引継ぎ困難 |
+| **監査不可** | なぜその実装になったか説明できない | コンプライアンス違反 |
+| **テスト困難** | 仕様がないのでテストケースが書けない | バグの見逃し |
+| **変更影響不明** | 要件変更時の影響範囲が分からない | 予期せぬ障害 |
+
+**実例: Vibe Codingの危険性**
+
+```
+ユーザー: 「経費の承認機能を追加して」
+
+AIの出力（問題あり）:
+- 承認上限金額のチェックなし
+- 自己承認が可能な実装
+- 監査ログなし
+- 承認済み経費の編集が可能
+
+→ 内部統制違反、不正の温床に
+```
+
+### 1.2 GitHub Copilot単体の限界
+
+GitHub Copilotは優れたコード補完ツールですが、エンタープライズ開発には不十分です。
+
+**Copilotの強み:**
+- コード補完が高速・高精度
+- 多言語対応
+- IDE統合が優秀
+
+**エンタープライズでの限界:**
+
+| 機能 | Copilot | エンタープライズ要件 |
+|------|---------|-------------------|
+| 要件管理 | ❌ なし | 形式的な要件定義必須 |
+| トレーサビリティ | ❌ なし | 要件↔コード追跡必須 |
+| 設計検証 | ❌ なし | SOLID原則等の検証必須 |
+| セキュリティ分析 | ⚠️ 限定的 | 網羅的な脆弱性検出必須 |
+| 形式検証 | ❌ なし | ビジネスルールの数学的証明 |
+| 監査証跡 | ❌ なし | 変更履歴・理由の記録必須 |
+| 知識蓄積 | ❌ なし | プロジェクト固有パターンの学習 |
+
+### 1.3 Claude Code / Cursor の課題
+
+Claude CodeやCursorは、より高度なAIコーディング体験を提供しますが、根本的な課題は解決していません。
+
+**Claude Codeの強み:**
+- 長いコンテキスト理解
+- マルチファイル編集
+- 高度な推論能力
+
+**Cursorの強み:**
+- IDE統合が優秀
+- 高速なレスポンス
+- チャット履歴管理
+
+**共通する限界:**
+
+```mermaid
+flowchart TB
+    subgraph Claude["Claude Code / Cursor の構造"]
+        subgraph Neural["Neural（LLM）のみ"]
+            subgraph Inference["確率的な推論"]
+                PM[パターンマッチング]
+                SP[統計的な予測]
+                PO[「それっぽい」出力]
+            end
+        end
+        Missing["❌ 欠けている要素"]
+    end
+    
+    Missing --> M1["❌ 形式的な知識グラフ"]
+    Missing --> M2["❌ 論理的な検証機構"]
+    Missing --> M3["❌ 学習データの永続化"]
+    Missing --> M4["❌ トレーサビリティ"]
+    Missing --> M5["❌ 品質ゲート"]
+    
+    style Claude fill:#f9f9f9,stroke:#333
+    style Neural fill:#e3f2fd,stroke:#1976d2
+    style Missing fill:#ffebee,stroke:#c62828
+```
+
+### 1.4 なぜエンタープライズ開発には不十分なのか
+
+エンタープライズアプリケーションには、以下の特性があります。
+
+| 特性 | 説明 | 従来AIツールの対応 |
+|------|------|-------------------|
+| **内部統制** | 承認ワークフロー、権限分離 | ❌ 考慮なし |
+| **監査要件** | 変更履歴、アクセスログ | ❌ 対応なし |
+| **コンプライアンス** | 法規制、業界標準準拠 | ❌ 検証不可 |
+| **長期保守** | 10年以上の運用 | ❌ 仕様不明で困難 |
+| **大規模チーム** | 100人以上での開発 | ❌ 知識共有なし |
+| **ミッションクリティカル** | 24/365稼働 | ❌ 形式検証なし |
+
+---
+
+## 2. SDD（Specification Driven Development）の課題
+
+### 2.1 SDDとは
+
+SDD（Specification Driven Development）は、仕様書を起点とした開発手法です。
+
+```mermaid
+flowchart LR
+    subgraph Traditional["従来のSDD"]
+        A[仕様書] --> B[設計書] --> C[実装] --> D[テスト]
+        A1[手動] -.-> A
+        B1[手動] -.-> B
+        C1[手動] -.-> C
+        D1[手動] -.-> D
+    end
+    
+    style Traditional fill:#fff3e0,stroke:#e65100
+    style A1 fill:#ffccbc,stroke:#bf360c
+    style B1 fill:#ffccbc,stroke:#bf360c
+    style C1 fill:#ffccbc,stroke:#bf360c
+    style D1 fill:#ffccbc,stroke:#bf360c
+```
+
+**SDDの利点:**
+- 仕様が明確
+- トレーサビリティ確保
+- 品質管理が可能
+
+### 2.2 SDDの課題
+
+しかし、従来のSDDには重大な課題があります。
+
+| 課題 | 説明 | 影響 |
+|------|------|------|
+| **手動作業が多い** | 仕様書↔コードの同期が手動 | 工数増大、同期ズレ |
+| **AIとの統合が弱い** | AIは仕様を理解しない | AI活用の恩恵が限定的 |
+| **形式化が困難** | 自然言語仕様は曖昧 | 解釈の齟齬 |
+| **変更追従が困難** | 仕様変更時の影響分析が手動 | 変更コスト高 |
+| **知識の断絶** | プロジェクト間で学習が活かせない | 車輪の再発明 |
+
+### 2.3 SDDツールの現状
+
+これらの課題を解決するため、SDDをAIと統合したツールが登場しています。
+
+:::note info
+**EARS（Easy Approach to Requirements Syntax）とは？**
+要件を曖昧さなく記述するための形式言語です。「WHEN [条件] THE SYSTEM SHALL [動作]」のような5つのパターンで要件を構造化し、検証可能な形式にします。詳細は[6.2 EARS形式](#62-musubixが実行する処理)で解説します。
+:::
+
+| ツール | 提供元 | 特徴 | リリース |
+|--------|--------|------|----------|
+| **AWS Kiro** | Amazon Web Services | VS Code系IDE、EARS記法、requirements/design/tasks.md、Agent Hooks | 2025年 |
+| **GitHub Spec Kit** | GitHub Next | 仕様書からのコード生成、Copilot統合（実験中） | 2025年（Preview） |
+| **Cursor Rules** | Cursor | .cursorrules による開発ルール定義、カスタムプロンプト | 2024年〜 |
+| **Claude Projects** | Anthropic | Project Knowledge による文脈管理、Memory機能 | 2024年〜 |
+
+#### AWS Kiro
+
+AWS Kiroは、Amazonが提供するSpec-Driven Development特化のAI IDE（VS Code互換）です。
+
+**主な機能:**
+- **EARS記法サポート**: 要件を`WHEN [条件] THE SYSTEM SHALL [動作]`形式で記述
+- **3ファイル構成**: `requirements.md`、`design.md`、`tasks.md`による構造化
+- **Agent Hooks**: ファイル保存時にテスト生成やドキュメント更新を自動実行
+- **Steering Files**: プロジェクト固有のルールやコーディング標準を定義
+- **Claude Sonnet 4.5採用**: 高度な推論能力を持つLLMを搭載
+
+```
+Kiroのワークフロー:
+  自然言語 → requirements.md → design.md → tasks.md → 実装
+```
+
+:::note info
+Kiroは「Vibe Coding（雰囲気コーディング）からViable Code（実用コード）へ」をスローガンに、AI生成コードの品質向上を目指しています。
+:::
+
+#### GitHub Spec Kit（実験的プロジェクト）
+
+GitHub Nextが開発中のSpec Kitは、仕様書からコードを生成する実験的プロジェクトです。GitHub Copilotとの統合を前提に設計されており、仕様とコードの双方向同期を目指しています。
+
+#### その他のアプローチ
+
+| アプローチ | ツール | 概要 |
+|-----------|--------|------|
+| **ルールベース** | Cursor Rules、Windsurf Rules | `.cursorrules`等で開発ルールを定義 |
+| **知識ベース** | Claude Projects | プロジェクト文脈をKnowledgeとして管理 |
+| **エージェント型** | Devin、OpenHands | 自律的にタスクを実行するAIエージェント |
+
+### 2.4 既存SDDツールの限界
+
+これらのツールは従来のAIコーディングより進歩していますが、依然として課題があります。
+
+:::note info
+**この表に登場する専門用語**
+- **C4モデル**: システム設計を4つのレベル（Context/Container/Component/Code）で階層的に表現する手法
+- **Z3 SMTソルバー**: Microsoftが開発した形式検証ツール。数学的にプログラムの正しさを証明できる
+- **YATA**: MUSUBIXの知識グラフシステム。プロジェクトの知識を構造化して保存・推論する
+- **トレーサビリティ**: 要件↔設計↔コード↔テストの対応関係を追跡できること
+- **KGPR**: Knowledge Graph Pull Request。知識グラフの変更をGitのPRのように管理する仕組み
+:::
+
+| 観点 | 既存SDDツール | MUSUBIX |
+|------|-------------|---------|
+| **要件形式** | EARS（一部）、自由形式 | EARS完全サポート + 検証 |
+| **設計パターン** | 限定的 | C4モデル + 設計パターン検出 |
+| **形式検証** | ❌ なし | ✅ Z3 SMTソルバー統合 |
+| **知識グラフ** | ❌ なし | ✅ YATA統合 |
+| **トレーサビリティ** | 限定的 | ✅ 要件↔設計↔コード↔テスト完全追跡 |
+| **自己学習** | ❌ なし | ✅ パターン学習・フィードバック |
+| **チーム共有** | 限定的 | ✅ KGPR（知識グラフPR） |
+
+### 2.5 AIコーディングとSDDの溝
+
+```mermaid
+flowchart LR
+    subgraph AI["AIコーディング"]
+        AI1["✅ 高速"]
+        AI2["✅ 柔軟"]
+        AI3["❌ 仕様不明"]
+        AI4["❌ 再現性なし"]
+    end
+    
+    subgraph SDD["SDD"]
+        SDD1["✅ 品質管理"]
+        SDD2["✅ トレーサビリティ"]
+        SDD3["❌ 低速"]
+        SDD4["❌ 硬直的"]
+    end
+    
+    AI <--> |溝| SDD
+    
+    MUSUBIX["🔗 この溝を埋めるのが\nMUSUBIX"]
+    AI --> MUSUBIX
+    SDD --> MUSUBIX
+    
+    style AI fill:#e3f2fd,stroke:#1976d2
+    style SDD fill:#fff3e0,stroke:#e65100
+    style MUSUBIX fill:#c8e6c9,stroke:#388e3c,stroke-width:3px
+```
+
+---
+
+## 3. MUSUBIXとは
+
+### 3.1 Neuro-Symbolic AI統合
+
+:::note info
+**Neuro-Symbolic AIとは？**
+- **Neural（ニューラル）**: LLM（大規模言語モデル）による確率的・創造的な処理。パターン認識や自然言語理解が得意
+- **Symbolic（シンボリック）**: 知識グラフや論理規則による厳密な推論。一貫性保証や形式検証が得意
+- 両者を組み合わせることで、LLMの創造性とシンボリック推論の厳密性を両立させます
+:::
+
+MUSUBIXは、**Neural（LLM）** と **Symbolic（知識グラフ）** を統合した次世代AIコーディングシステムです。
+
+```mermaid
+flowchart TB
+    subgraph MUSUBIX["MUSUBIX"]
+        subgraph Neural["Neural（LLM）"]
+            N1[創造的生成]
+            N2[自然言語理解]
+            N3[パターン認識]
+            N4[柔軟な対応]
+        end
+        
+        subgraph Symbolic["Symbolic（YATA）"]
+            S1[知識グラフ]
+            S2[論理推論]
+            S3[形式検証]
+            S4[一貫性保証]
+        end
+        
+        Neural <--> Symbolic
+        
+        subgraph Engine["統合推論エンジン"]
+            E1[信頼度評価]
+            E2[最終決定]
+        end
+        
+        Neural --> Engine
+        Symbolic --> Engine
+    end
+    
+    style MUSUBIX fill:#f5f5f5,stroke:#333,stroke-width:2px
+    style Neural fill:#e3f2fd,stroke:#1976d2
+    style Symbolic fill:#fff3e0,stroke:#e65100
+    style Engine fill:#c8e6c9,stroke:#388e3c
+```
+
+### 3.2 信頼度評価ルール
+
+MUSUBIXは、NeuralとSymbolicの結果を以下のルールで統合します。
+
+| シンボリック結果 | ニューラル信頼度 | 最終決定 |
+|-----------------|-----------------|---------|
+| invalid（無効） | - | ニューラル結果を**棄却** |
+| valid（有効） | ≥0.8 | ニューラル結果を**採用** |
+| valid（有効） | <0.8 | シンボリック結果を**優先** |
+
+:::note warn
+**なぜこのルールか**
+- シンボリック（形式論理）は「絶対に正しい」ことを保証
+- ニューラルが生成しても、論理的に誤りなら却下
+- 論理的に正しく、かつAIの確信度が高い場合のみ採用
+:::
+
+### 3.3 MUSUBIXの構成要素
+
+| コンポーネント | 役割 |
+|---------------|------|
+| **EARS検証** | 要件を5つの形式パターンで検証 |
+| **C4モデル** | 4レベルの設計構造化 |
+| **YATA** | 知識グラフによる推論・検証 |
+| **Z3統合** | SMTソルバーによる形式検証 |
+| **自己学習** | パターン抽出・蓄積・適用 |
+| **トレーサビリティ** | 要件↔設計↔コード↔テストの追跡 |
+| **9条憲法** | 開発ルールの強制 |
+
+### 3.4 開発フローの変革
+
+```mermaid
+flowchart TB
+    subgraph Traditional["従来"]
+        T1[自然言語] --> T2[AI] --> T3["コード（品質不明）"]
+    end
+    
+    subgraph MUSUBIX["MUSUBIX"]
+        M1[自然言語]
+        M2[EARS形式化]
+        M3["要件（検証済み）"]
+        M4[C4設計]
+        M5["設計（パターン適用済み）"]
+        M6[コード生成]
+        M7["コード（静的解析済み）"]
+        M8[形式検証]
+        M9[検証済みコード]
+        M10[テスト生成]
+        M11[テスト付きコード]
+        M12["✅ 完全なトレーサビリティで追跡可能"]
+        
+        M1 --> M2 --> M3 --> M4 --> M5 --> M6 --> M7 --> M8 --> M9 --> M10 --> M11 --> M12
+    end
+    
+    style Traditional fill:#ffebee,stroke:#c62828
+    style MUSUBIX fill:#e8f5e9,stroke:#2e7d32
+    style T3 fill:#ffcdd2,stroke:#b71c1c
+    style M12 fill:#a5d6a7,stroke:#1b5e20,stroke-width:2px
+```
+
+### 3.5 動作環境と推奨構成
+
+MUSUBIXは、MCP（Model Context Protocol）に対応した様々なAIコーディングツールで利用可能です。
+
+#### 対応AIコーディングツール
+
+| ツール | 対応状況 | 備考 |
+|--------|---------|------|
+| **GitHub Copilot Agent mode** | ✅ 推奨 | VS Code拡張、MCPサポート |
+| **Claude Code** | ✅ 対応 | ターミナルベース |
+| **Cursor** | ✅ 対応 | Agent mode + MCP |
+| **Windsurf** | ✅ 対応 | MCP対応 |
+| **その他MCP対応ツール** | ✅ 対応 | MCP経由で連携 |
+
+#### 推奨構成: GitHub Copilot Enterprise + Claude Opus 4.5
+
+:::note info
+**なぜこの組み合わせがおすすめか**
+
+**GitHub Copilot Enterprise**を選ぶ理由：
+- VS Codeとのシームレスな統合
+- Agent modeによるツール呼び出し（MCP）が安定
+- 企業向けセキュリティ・コンプライアンス対応
+- チーム間でのナレッジ共有機能
+
+**Claude Opus 4.5**を選ぶ理由：
+- 長いコンテキスト（200Kトークン）の理解に優れる
+- 複雑な推論タスクで高い精度
+- **出力コンテキストが上限を超える場合、大きなコンテキストを扱える他のLLMに切り替え可能**
+- コード生成の品質が高い
+
+**組み合わせのメリット:**
+- MUSUBIXの長い要件定義書・設計書を正確に理解
+- 大規模なコードベースでも文脈を維持
+- LLMの出力制限に縛られない柔軟な運用
+- エンタープライズグレードのセキュリティ
+:::
+
+#### 推奨OS環境: WSL（Windows Subsystem for Linux）
+
+:::note warn
+**Windows環境では WSL の使用を強く推奨します**
+
+**WSLを推奨する理由:**
+1. **コマンド実行の安定性**: MUSUBIXのCLIツールはLinux環境で最も安定動作
+2. **Z3インストールの容易さ**: `apt install z3`で形式検証ツールを簡単導入
+3. **ファイルシステムの互換性**: Unix系パス表記でトラブル回避
+4. **開発ツールチェーン**: npm、Node.js、Gitなどの動作が安定
+5. **本番環境との一貫性**: 多くのサーバーがLinux環境
+
+**WSL2セットアップ（Windows 10/11）:**
+```bash
+# PowerShellを管理者権限で実行
+wsl --install -d Ubuntu-22.04
+
+# WSL内でNode.js環境をセットアップ
+curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
+sudo apt install -y nodejs
+
+# Z3（形式検証）のインストール
+sudo apt install -y z3
+```
+:::
+
+#### 最小システム要件
+
+| 項目 | 最小要件 | 推奨 |
+|------|---------|------|
+| **Node.js** | 20.0.0以上 | 22.x LTS |
+| **npm** | 10.0.0以上 | 最新 |
+| **メモリ** | 8GB | 16GB以上 |
+| **OS** | Windows 10 (WSL2), macOS 12+, Ubuntu 20.04+ | Ubuntu 22.04 (WSL2) |
+
+---
+
+## 4. エンタープライズ開発に必要な要素
+
+### 4.1 MUSUBIXが提供する価値
+
+エンタープライズアプリケーション開発では、単に「動くコード」を作るだけでは不十分です。内部統制、監査対応、コンプライアンス遵守など、ビジネス上の厳格な要件を満たす必要があります。
+
+MUSUBIXは、これらのエンタープライズ要件に対して、AIコーディングの利便性を維持しながら対応する唯一のソリューションです。
+
+| エンタープライズ要件 | MUSUBIXの対応 |
+|---------------------|---------------|
+| **内部統制** | EARS形式で承認ルールを形式化、Z3で正当性証明 |
+| **監査要件** | 完全なトレーサビリティ、変更履歴自動記録 |
+| **コンプライアンス** | 9条憲法による品質ゲート強制 |
+| **長期保守** | 明確な仕様、設計パターンの文書化 |
+| **大規模チーム** | KGPR（知識グラフPR）でチーム知識共有 |
+| **ミッションクリティカル** | 形式検証、セキュリティ分析 |
+
+:::note info
+**従来のAIコーディングとの違い**
+- **Vibe Coding**: 「なんとなく動く」→ 監査で説明不能
+- **MUSUBIX**: 「なぜこう実装したか」を要件IDで追跡可能 → 監査対応可能
+:::
+
+### 4.2 本マニュアルで構築するシステム
+
+**経費精算システム（Expense Management System）**
+
+このマニュアルでは、実際に経費精算システムを構築しながら、MUSUBIXの全機能を体験します。
+
+```mermaid
+flowchart TB
+    EMS["経費精算システムの要素"]
+    
+    EMS --> A[経費申請・登録]
+    EMS --> B[多段階承認ワークフロー]
+    EMS --> C[予算チェック]
+    EMS --> D[領収書管理]
+    EMS --> E[監査ログ]
+    EMS --> F[レポート生成]
+    
+    B --> B1[金額による承認ルート分岐]
+    B --> B2[上長・経理の段階承認]
+    
+    style EMS fill:#e1f5fe,stroke:#0277bd,stroke-width:2px
+    style B fill:#fff3e0,stroke:#e65100
+```
+
+**なぜ経費精算システムか:**
+
+経費精算システムは、エンタープライズアプリケーションの典型的な要素を網羅しています。承認ワークフロー、金額計算、監査要件、セキュリティなど、MUSUBIXの各機能を実践的に学ぶのに最適な題材です。
+
+また、多くの企業で実際に使われているシステムであるため、学んだ内容をすぐに実務に活かすことができます。
+
+| 要素 | MUSUBIX機能との対応 |
+|------|-------------------|
+| 承認ワークフロー | EARS形式、状態遷移、形式検証 |
+| 金額ルール | Z3による数学的検証 |
+| 監査要件 | トレーサビリティ、監査ログ |
+| セキュリティ | 金額改ざん検知、認可チェック |
+| 経費カテゴリ | オントロジーによる階層表現 |
+
+:::note info
+**このマニュアルで得られるスキル**
+- EARS形式での要件定義
+- C4モデルでの設計
+- トレーサビリティを維持したコード生成
+- Z3による形式検証
+- MUSUBIXの自己学習システムの活用
+:::
+
+---
+
+**次のセクションでは、実際にプロジェクトを初期化し、経費精算システムの開発を開始します。**
+
+---
+
+# Part 2: 経費精算システム開発
+
+## 5. プロジェクト初期化
+
+それでは、実際にMUSUBIXプロジェクトを作成しましょう。
+
+### 5.1 環境の準備
+
+#### Step 1: WSL Ubuntuにアクセス
+
+Windowsターミナル（またはWindows Terminal）を起動し、WSLのUbuntuにアクセスします。
+
+```bash
+# Windowsターミナルで新しいタブを開き、Ubuntuを選択
+# または、PowerShellから以下を実行
+wsl -d Ubuntu
+```
+
+#### Step 2: プロジェクトディレクトリの作成と移動
+
+```bash
+# プロジェクト用ディレクトリを作成
+mkdir -p ~/projects/expense-management-system
+
+# ディレクトリに移動
+cd ~/projects/expense-management-system
+
+# VS Codeでプロジェクトを開く
+code .
+```
+
+:::note info
+VS Codeが起動したら、GitHub Copilot拡張機能がインストールされていることを確認してください。Agent modeを使用する場合は、Copilot Chatパネルで`@workspace`を使用できます。
+:::
+
+### 5.2 MUSUBIXプロジェクトの初期化
+
+VS Code上でGitHub Copilot Agent modeを使用して、プロジェクトを初期化します。
+
+AIエージェントは内部で以下のコマンドを実行します。
+
+```bash
+npx musubix init expense-management-system --name "経費精算システム"
+```
+
+### 5.3 実行結果
+
+```
+{
+  success: true,
+  projectPath: '/tmp/expense-management-system',
+  filesCreated: [
+    'steering/',
+    'steering/rules/',
+    'storage/',
+    'storage/specs/',
+    'storage/archive/',
+    'storage/changes/',
+    '.github/',
+    '.github/prompts/',
+    '.github/skills/',
+    'musubix.config.json',
+    'steering/rules/constitution.md',
+    'steering/product.md',
+    'steering/tech.md',
+    'steering/structure.md',
+    'AGENTS.md',
+    'storage/archive/.gitkeep',
+    'storage/changes/.gitkeep'
+  ],
+  message: "MUSUBIX project '経費精算システム' initialized successfully!"
+}
+```
+
+### 5.4 生成されたプロジェクト構造
+
+```mermaid
+flowchart TB
+    subgraph Project["expense-management-system/"]
+        subgraph GitHub[".github/"]
+            GP["prompts/ - AIプロンプトテンプレート"]
+            GS["skills/ - エージェントスキル定義"]
+        end
+        
+        subgraph Steering["steering/ - プロジェクトメモリ"]
+            SR["rules/constitution.md - 9条憲法"]
+            SP["product.md - プロダクト情報"]
+            ST["tech.md - 技術スタック"]
+            SS["structure.md - アーキテクチャ構造"]
+        end
+        
+        subgraph Storage["storage/ - 成果物保存"]
+            SSp["specs/ - 要件・設計・タスク"]
+            SA["archive/ - アーカイブ"]
+            SC["changes/ - 変更履歴"]
+        end
+        
+        AG["AGENTS.md - AIエージェント向けガイド"]
+        CF["musubix.config.json - プロジェクト設定"]
+    end
+    
+    style Project fill:#f5f5f5,stroke:#333
+    style Steering fill:#e8f5e9,stroke:#2e7d32
+    style Storage fill:#e3f2fd,stroke:#1976d2
+```
+
+### 5.5 設定ファイル（musubix.config.json）
+
+```json:musubix.config.json
+{
+  "version": "1.1.6",
+  "project": "経費精算システム",
+  "steeringDir": "./steering",
+  "storageDir": "./storage",
+  "llm": {
+    "provider": "anthropic",
+    "model": "claude-sonnet-4-20250514",
+    "maxTokens": 4096,
+    "temperature": 0.7
+  },
+  "yata": {
+    "transport": "stdio",
+    "server": "yata-mcp",
+    "timeout": 30000
+  },
+  "integration": {
+    "neuralThreshold": 0.7,
+    "symbolicThreshold": 0.8,
+    "defaultStrategy": "neural-validated",
+    "gracefulDegradation": true
+  }
+}
+```
+
+**設定項目の説明:**
+
+| 項目 | 説明 |
+|------|------|
+| `llm.provider` | 使用するLLMプロバイダー（anthropic） |
+| `llm.model` | 使用するモデル（Claude Sonnet 4） |
+| `integration.neuralThreshold` | ニューラル信頼度閾値（0.7以上で採用検討） |
+| `integration.symbolicThreshold` | シンボリック検証閾値（0.8以上で確定） |
+| `integration.defaultStrategy` | デフォルト戦略（neural-validated: Neural生成→Symbolic検証） |
+
+### 5.6 steering/（プロジェクトメモリ）の役割
+
+:::note info
+**steering/とは？**
+AIエージェントが参照する「プロジェクトの記憶」です。船の操舵（steering）に由来し、プロジェクトの方向性を定めます。技術スタック、アーキテクチャルール、プロダクト情報を格納し、AIが文脈を理解した上でコードを生成できます。AWS Kiroも同様の概念を採用しています。
+:::
+
+MUSUBIXの特徴的な概念である **steering/** ディレクトリは、AIエージェントが参照する「プロジェクトの記憶」です。
+
+```mermaid
+flowchart TB
+    subgraph Steering["steering/ - プロジェクトメモリ"]
+        R["rules/"]
+        R --> C["constitution.md - 絶対に守るべき9つのルール"]
+        P["product.md - このプロダクトは何か"]
+        T["tech.md - どの技術を使うか"]
+        S["structure.md - どのような構造で作るか"]
+    end
+    
+    style Steering fill:#e8f5e9,stroke:#2e7d32
+    style C fill:#ffcdd2,stroke:#c62828,stroke-width:2px
+```
+
+**9条憲法（constitution.md）** は、すべての開発活動を統治する不変のルールです。AIエージェントは、コード生成前に必ずこのファイルを参照し、ルールに違反する出力を行いません。
+
+:::note info
+📖 詳細は [付録A: MUSUBIX 9条憲法](#付録a-9条憲法constitutional-articles) を参照
+:::
+
+---
+
+## 6. 要件定義
+
+MUSUBIXでは、作りたいシステムを自然言語で指示するだけで、AIエージェントが対話を通じてユーザーの要件を確認し、EARS形式の要件定義書を自動作成します。
+
+従来の要件定義では、ドキュメント作成に多大な時間がかかりましたが、MUSUBIXを使えば対話しながら要件を明確化し、形式化された要件定義書を短時間で作成できます。
+
+```mermaid
+flowchart LR
+    A[自然言語で指示] --> B[AIが要件を生成]
+    B --> C[ユーザーがレビュー]
+    C --> D{修正が必要?}
+    D -->|はい| E[修正指示]
+    E --> B
+    D -->|いいえ| F[要件定義完了]
+    
+    style A fill:#e3f2fd,stroke:#1976d2
+    style F fill:#c8e6c9,stroke:#388e3c,stroke-width:2px
+```
+
+AIエージェントが作成した要件定義書をユーザーがレビューし、修正が必要な箇所があればフィードバックを伝えます。このレビューと修正のサイクルを、修正の必要がなくなるまで繰り返すことで、高品質な要件定義書が完成します。
+
+### 6.1 自然言語での指示
+
+プロジェクト初期化後、AIエージェントに対して自然言語で要件を伝えます。
+
+> 「経費精算システムの要件を定義してください。
+> 
+> 主な機能:
+> - 経費の申請・登録
+> - 多段階承認ワークフロー（申請者→上長→経理）
+> - 金額による承認ルート分岐（10万円以上は部長承認必要）
+> - 経費カテゴリ管理（交通費、宿泊費、交際費など）
+> - 予算チェック
+> - 領収書の添付
+> - 監査ログの記録
+> - レポート出力」
+
+### 6.2 MUSUBIXが実行する処理
+
+MUSUBIXは、この自然言語を**EARS形式**（Easy Approach to Requirements Syntax）に変換します。
+
+:::note info
+**EARS形式の背景**
+EARSは2009年にRolls-Royce社のAlistair Mavin氏らが提唱した要件記述法です。航空宇宙産業で的確な要件定義が求められる中、5つのパターンで要件の曖昧さを排除します。AWS KiroもEARSを採用しており、業界標準となりつつあります。
+:::
+
+**EARS形式とは:**
+
+| パターン | 構文 | 用途 |
+|---------|------|------|
+| Ubiquitous | `THE [system] SHALL [requirement]` | 常に満たすべき要件 |
+| Event-driven | `WHEN [event], THE [system] SHALL [response]` | イベント発生時の要件 |
+| State-driven | `WHILE [state], THE [system] SHALL [response]` | 特定状態での要件 |
+| Unwanted | `THE [system] SHALL NOT [behavior]` | 禁止事項 |
+| Optional | `IF [condition], THEN THE [system] SHALL [response]` | 条件付き要件 |
+
+:::note info
+📖 詳細は [付録C: EARSパターン](#付録c-earsパターン) を参照
+:::
+
+### 6.3 AIエージェントによるEARS変換
+
+AIエージェント（GitHub Copilot Agent mode + MUSUBIX）は、自然言語の要件をEARS形式に変換して要件定義書を作成します。
+
+**変換例:**
+
+| 自然言語 | EARSパターン | EARS形式 |
+|---------|-------------|----------|
+| 「ユーザーが経費を申請すると通知が送られる」 | Event-driven | WHEN a user submits an expense entry, THE System SHALL send notification to the approver. |
+| 「10万円以上は部長承認が必要」 | Optional | IF an expense amount exceeds 100,000 JPY, THEN THE System SHALL require Director approval. |
+| 「自分の経費は自分で承認できない」 | Unwanted | THE System SHALL NOT allow users to approve their own expense entries. |
+| 「すべての操作は監査ログに記録」 | Ubiquitous | THE System SHALL log all operations with timestamp and user ID. |
+| 「7日以上承認待ちならリマインダー」 | State-driven | WHILE an expense is pending for more than 7 days, THE System SHALL send daily reminders. |
+
+### 6.4 生成された要件定義書
+
+AIエージェントが生成した要件定義書の一部を示します。
+
+```markdown
+## 経費申請（Expense Submission）
+
+### REQ-EXP-001: 経費登録
+**[Ubiquitous]**
+> THE Expense Management System SHALL allow authenticated users to create 
+> expense entries with date, amount, category, and description.
+
+**優先度**: P0（必須）
+
+### REQ-EXP-002: 領収書添付
+**[Event-driven]**
+> WHEN a user creates an expense entry, THE Expense Management System SHALL 
+> allow attachment of receipt images in JPEG, PNG, or PDF format.
+
+**優先度**: P0（必須）
+```
+
+```markdown
+## 承認ワークフロー（Approval Workflow）
+
+### REQ-APR-002: 金額別承認ルート
+**[Optional]**
+> IF an expense amount exceeds 100,000 JPY, THEN THE Expense Management System 
+> SHALL require additional Director approval before Finance approval.
+
+**優先度**: P0（必須）
+
+### REQ-APR-006: 自己承認禁止
+**[Unwanted]**
+> THE Expense Management System SHALL NOT allow users to approve their own 
+> expense entries.
+
+**優先度**: P0（必須）
+```
+
+### 6.5 要件検証の実行
+
+要件定義書をEARS形式で検証します。
+
+**自然言語での指示:**
+> 「作成した要件定義書のEARS形式を検証してください」
+>  　　　　　or
+> 「要件定義定義書をレビュー」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix requirements validate storage/specs/REQ-EXP-001-requirements.md
+```
+
+**実行結果:**
+```json
+{
+  "success": true,
+  "valid": true,
+  "issues": [],
+  "summary": { "errors": 0, "warnings": 0, "info": 0 },
+  "message": "✅ All requirements are valid"
+}
+```
+
+### 6.6 要件サマリー
+
+| カテゴリ | P0（必須） | P1（重要） | 合計 |
+|---------|----------|----------|------|
+| 経費申請 | 3 | 1 | 4 |
+| 承認ワークフロー | 5 | 2 | 7 |
+| 予算管理 | 2 | 1 | 3 |
+| 監査・コンプライアンス | 3 | 0 | 3 |
+| レポート | 0 | 3 | 3 |
+| セキュリティ | 4 | 0 | 4 |
+| **合計** | **17** | **7** | **24** |
+
+### 6.7 なぜEARS形式が重要か
+
+自然言語で書かれた要件は、読み手によって解釈が異なる可能性があります。「通知する」と書かれていても、「いつ」「誰に」「どのように」通知するのかが不明確です。
+
+EARS形式を使うことで、要件の曖昧さを排除し、誰が読んでも同じ解釈ができる要件定義書を作成できます。さらに、形式化された要件は自動検証やテストケース生成にも活用できます。
+
+| 観点 | 自然言語 | EARS形式 |
+|------|---------|----------|
+| **曖昧さ** | 「通知する」→ いつ？誰に？ | WHEN [trigger], SHALL [action] で明確 |
+| **検証可能性** | テストケース作成困難 | パターンから自動生成可能 |
+| **トレーサビリティ** | 要件↔コードの対応不明 | REQ-ID で追跡可能 |
+| **形式検証** | 数学的検証不可 | Z3/SMTソルバーで証明可能 |
+
+:::note info
+**エンタープライズ開発でのメリット**
+- 監査時に「この機能はどの要件に基づいているか」を即座に説明可能
+- 要件変更時の影響範囲を自動分析
+- テストケースの網羅性を要件IDで保証
+:::
+
+---
+
+## 7. 設計
+
+### 7.1 自然言語での指示
+
+要件定義が完了したら、設計フェーズに進みます。
+
+> 「経費精算システムの設計を作成してください。
+> C4モデルで構造化し、適切な設計パターンを適用してください。」
+> 　　　　or
+> 「設計書を作成」
+
+### 7.2 MUSUBIXが実行する処理
+
+MUSUBIXは、要件定義書を入力として**C4モデル**に基づく設計を生成します。
+
+:::note info
+**C4モデルの背景**
+C4モデルはSimon Brown氏が提唱したソフトウェアアーキテクチャの可視化手法です。「地図のズーム」のように、4つのレベルでシステムを階層的に説明します。経営層にはContext、技術リーダーにはContainer、開発者にはComponent/Codeと、対象者に合わせた説明が可能です。
+:::
+
+**C4モデルとは:**
+
+| レベル | 説明 | 対象読者 |
+|-------|------|---------|
+| **Context** | システム境界と外部アクター | 経営層、ステークホルダー |
+| **Container** | 技術選択、コンテナ構成 | アーキテクト、技術リーダー |
+| **Component** | コンテナ内部構造 | 開発者 |
+| **Code** | 実装詳細 | 開発者 |
+
+### 7.3 生成された設計書
+
+#### Context Diagram（システムコンテキスト）
+
+```mermaid
+flowchart TB
+    subgraph Actors["External Actors"]
+        EMP["👤 Employee<br/>(申請者)"]
+        MGR["👤 Manager<br/>(上長)"]
+        DIR["👤 Director<br/>(部長)"]
+        FIN["👤 Finance<br/>(経理)"]
+    end
+    
+    EMS["📦 Expense Management System<br/>経費精算システム"]
+    
+    subgraph External["External Systems"]
+        EMAIL["📧 Email Server"]
+        LDAP["🔐 LDAP/AD<br/>(認証)"]
+        ACC["💰 Accounting System"]
+    end
+    
+    EMP --> EMS
+    MGR --> EMS
+    DIR --> EMS
+    FIN --> EMS
+    
+    EMS --> EMAIL
+    EMS --> LDAP
+    EMS --> ACC
+    
+    style EMS fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
+    style Actors fill:#e8f5e9,stroke:#2e7d32
+    style External fill:#fff3e0,stroke:#e65100
+```
+
+#### Container Diagram（コンテナ図）
+
+```mermaid
+flowchart TB
+    subgraph EMS["Expense Management System"]
+        subgraph Frontend["Frontend Layer"]
+            WEB["🌐 Web Frontend<br/>(React/Next.js)"]
+            MOB["📱 Mobile App<br/>(React Native)"]
+        end
+        
+        GW["🚪 API Gateway"]
+        
+        subgraph Services["Service Layer"]
+            EXPS["Expense<br/>Service"]
+            APRS["Approval<br/>Service"]
+            BUDS["Budget<br/>Service"]
+        end
+        
+        DB[("🗄️ PostgreSQL DB")]
+        
+        WEB --> GW
+        MOB --> GW
+        GW --> EXPS
+        GW --> APRS
+        GW --> BUDS
+        EXPS --> DB
+        APRS --> DB
+        BUDS --> DB
+    end
+    
+    style EMS fill:#f5f5f5,stroke:#333,stroke-width:2px
+    style Frontend fill:#e3f2fd,stroke:#1976d2
+    style Services fill:#fff3e0,stroke:#e65100
+    style GW fill:#c8e6c9,stroke:#388e3c
+    style DB fill:#f3e5f5,stroke:#7b1fa2
+```
+
+### 7.4 設計パターンの適用
+
+AIエージェントは、要件に基づいて適切な設計パターンを自動選択・適用します。
+
+| パターン | 適用箇所 | 選択理由 |
+|---------|---------|---------|
+| **Repository** | ExpenseRepository | REQ-AUD-001の監査要件に対応、データアクセス抽象化 |
+| **Service** | ApprovalService | REQ-APR-001〜007の承認ロジック集約 |
+| **Factory** | ExpenseFactory | REQ-EXP-001の経費作成ルールカプセル化 |
+| **Observer** | NotificationObserver | REQ-APR-003の承認通知を疎結合に実現 |
+| **Strategy** | ApprovalStrategy | REQ-APR-002の金額別承認ルート切り替え |
+| **State** | ExpenseState | REQ-APR-007のステータス遷移管理 |
+
+### 7.5 状態遷移設計
+
+経費のステータス遷移を設計します。
+
+```
+Draft → Submitted → ManagerApproved → [DirectorApproved] → FinanceApproved
+                  ↘               ↘                    ↘
+                    Rejected       Rejected              Rejected
+```
+
+**有効な状態遷移テーブル:**
+
+| 現在の状態 | 可能な次の状態 |
+|-----------|---------------|
+| Draft | Submitted, Cancelled |
+| Submitted | ManagerApproved, Rejected |
+| ManagerApproved | DirectorApproved, FinanceApproved, Rejected |
+| DirectorApproved | FinanceApproved, Rejected |
+| FinanceApproved | （最終状態） |
+| Rejected | （最終状態） |
+
+### 7.6 トレーサビリティ（要件→設計）
+
+| 要件ID | 設計ID | コンポーネント |
+|--------|--------|--------------|
+| REQ-EXP-001 | DES-SVC-001, DES-ENT-001 | ExpenseService, Expense |
+| REQ-APR-001 | DES-SVC-002, DES-ENT-002 | ApprovalService, Approval |
+| REQ-APR-002 | DES-DOM-001 | ApprovalStrategy |
+| REQ-APR-006 | DES-SVC-002 | ApprovalService.validateSelfApproval() |
+| REQ-BUD-001 | DES-SVC-003, DES-ENT-003 | BudgetService, Budget |
+| REQ-AUD-001 | DES-SVC-005, DES-ENT-004 | AuditService, AuditLog |
+
+---
+
+## 8. タスク分解
+
+設計フェーズが完了したら、実装前に**タスク分解**を行います。これはMUSUBIXの推奨ワークフローにおける重要なフェーズです。
+
+:::note info
+**なぜタスク分解が必要か？**
+設計書をそのまま実装に移すと、全体像が大きすぎて作業が困難になります。タスク分解により：
+- 作業を適切なサイズ（2-4時間程度）に分割
+- 依存関係を明確化し、実装順序を決定
+- 進捗管理が容易に
+- テスト駆動開発（Red-Green-Blue）サイクルの単位を明確化
+:::
+
+### 8.1 自然言語での指示
+
+> 「設計書に基づいて、実装タスクを分解してください。
+> 各タスクは2-4時間で完了できるサイズにしてください。
+> 依存関係と実装順序も明示してください。」
+> 　　　　or
+> 「タスク分解を実行」
+
+### 8.2 MUSUBIXが実行する処理
+
+```bash
+npx musubix design tasks storage/design/expense-design.md
+```
+
+MUSUBIXは以下の観点でタスクを分解します。
+
+1. **設計コンポーネントの依存関係分析**
+2. **タスクサイズの適正化**（2-4時間を目安）
+3. **実装順序の決定**（依存関係に基づく）
+4. **トレーサビリティID（TSK-*）の付与**
+
+### 8.3 生成されるタスク分解書
+
+```markdown:storage/tasks/expense-tasks.md
+# 経費精算システム - タスク分解書
+
+## 概要
+
+| 項目 | 値 |
+|------|-----|
+| 設計ID | DES-EXP-001 |
+| 総タスク数 | 12 |
+| 見積工数 | 32時間 |
+| 優先度 | P0 |
+
+## タスク一覧
+
+### Phase 1: ドメイン層（Value Objects）
+
+| タスクID | タスク名 | 設計ID | 見積 | 依存 |
+|----------|----------|--------|------|------|
+| TSK-001 | Amount Value Object実装 | DES-VO-002 | 2h | - |
+| TSK-002 | ExpenseStatus Value Object実装 | DES-VO-003 | 2h | - |
+| TSK-003 | ExpenseId Value Object実装 | DES-VO-001 | 1h | - |
+
+### Phase 2: ドメイン層（Entities）
+
+| タスクID | タスク名 | 設計ID | 見積 | 依存 |
+|----------|----------|--------|------|------|
+| TSK-004 | Expense Entity実装 | DES-ENT-001 | 3h | TSK-001, TSK-002, TSK-003 |
+| TSK-005 | Approval Entity実装 | DES-ENT-002 | 2h | TSK-004 |
+
+### Phase 3: ドメイン層（Services）
+
+| タスクID | タスク名 | 設計ID | 見積 | 依存 |
+|----------|----------|--------|------|------|
+| TSK-006 | ExpenseService実装 | DES-SVC-001 | 4h | TSK-004 |
+| TSK-007 | ApprovalService実装 | DES-SVC-002 | 4h | TSK-005 |
+| TSK-008 | ApprovalStrategy実装 | DES-DOM-001 | 3h | TSK-007 |
+
+### Phase 4: インフラ層
+
+| タスクID | タスク名 | 設計ID | 見積 | 依存 |
+|----------|----------|--------|------|------|
+| TSK-009 | ExpenseRepository実装 | DES-REPO-001 | 3h | TSK-004 |
+| TSK-010 | AuditService実装 | DES-SVC-005 | 3h | TSK-006, TSK-007 |
+
+### Phase 5: 統合
+
+| タスクID | タスク名 | 設計ID | 見積 | 依存 |
+|----------|----------|--------|------|------|
+| TSK-011 | Use Case層実装 | DES-UC-001 | 3h | TSK-006, TSK-007, TSK-009 |
+| TSK-012 | 統合テスト | - | 2h | TSK-011 |
+```
+
+### 8.4 タスク依存関係の可視化
+
+```mermaid
+flowchart TD
+    subgraph Phase1["Phase 1: Value Objects"]
+        TSK001[TSK-001<br/>Amount VO]
+        TSK002[TSK-002<br/>ExpenseStatus VO]
+        TSK003[TSK-003<br/>ExpenseId VO]
+    end
+
+    subgraph Phase2["Phase 2: Entities"]
+        TSK004[TSK-004<br/>Expense Entity]
+        TSK005[TSK-005<br/>Approval Entity]
+    end
+
+    subgraph Phase3["Phase 3: Services"]
+        TSK006[TSK-006<br/>ExpenseService]
+        TSK007[TSK-007<br/>ApprovalService]
+        TSK008[TSK-008<br/>ApprovalStrategy]
+    end
+
+    subgraph Phase4["Phase 4: Infrastructure"]
+        TSK009[TSK-009<br/>ExpenseRepository]
+        TSK010[TSK-010<br/>AuditService]
+    end
+
+    subgraph Phase5["Phase 5: Integration"]
+        TSK011[TSK-011<br/>Use Case層]
+        TSK012[TSK-012<br/>統合テスト]
+    end
+
+    TSK001 --> TSK004
+    TSK002 --> TSK004
+    TSK003 --> TSK004
+    TSK004 --> TSK005
+    TSK004 --> TSK006
+    TSK005 --> TSK007
+    TSK007 --> TSK008
+    TSK004 --> TSK009
+    TSK006 --> TSK010
+    TSK007 --> TSK010
+    TSK006 --> TSK011
+    TSK007 --> TSK011
+    TSK009 --> TSK011
+    TSK011 --> TSK012
+```
+
+### 8.5 トレーサビリティ（設計→タスク）
+
+| 設計ID | タスクID | コンポーネント |
+|--------|----------|--------------|
+| DES-VO-001 | TSK-003 | ExpenseId |
+| DES-VO-002 | TSK-001 | Amount |
+| DES-VO-003 | TSK-002 | ExpenseStatus |
+| DES-ENT-001 | TSK-004 | Expense |
+| DES-ENT-002 | TSK-005 | Approval |
+| DES-SVC-001 | TSK-006 | ExpenseService |
+| DES-SVC-002 | TSK-007 | ApprovalService |
+| DES-DOM-001 | TSK-008 | ApprovalStrategy |
+| DES-REPO-001 | TSK-009 | ExpenseRepository |
+| DES-SVC-005 | TSK-010 | AuditService |
+| DES-UC-001 | TSK-011 | UseCase層 |
+
+### 8.6 セルフレビューとユーザー確認
+
+タスク分解が完了したら、MUSUBIXはセルフレビューを実施します。
+
+**レビュー観点:**
+- 設計との対応確認（DES-* → TSK-*）
+- タスクサイズの適切性（2-4時間）
+- 依存関係・実行順序の妥当性
+- 工数見積もりの現実性
+
+```
+📋 **レビュー結果**
+
+| 観点 | 状態 | 詳細 |
+|------|------|------|
+| トレーサビリティ | ✅ OK | DES-001→TSK-001〜012 完了 |
+| タスクサイズ | ✅ OK | 各2-4時間で適切 |
+| 依存関係 | ✅ OK | Phase 1→5の順序が明確 |
+| 工数見積 | ⚠️ 確認 | 合計32時間（4人日相当） |
+
+👉 **次のアクションを選択してください:**
+- 「修正」/ 具体的な修正指示 → 修正して再提示
+- 「承認」/「OK」/「進める」 → コード生成フェーズへ
+```
+
+:::note warn
+**重要**: タスク分解の承認を得てから、コード生成フェーズに進みます。各タスクは **Red-Green-Blue** サイクル（テスト作成→実装→リファクタリング）で実装します。
+:::
+
+---
+
+## 9. コード生成
+
+### 8.1 自然言語での指示
+
+設計が完了したら、コード生成フェーズに進みます。
+
+> 「設計書に基づいてTypeScriptコードを生成してください。
+> まずはドメイン層（エンティティ、Value Object）から始めてください。」
+
+### 8.2 MUSUBIXが実行する処理
+
+MUSUBIXは設計書を入力として、以下の順序でコードを生成します。
+
+:::note info
+**ドメイン駆動設計（DDD）の基本用語**
+- **Value Object**: 金額、日付などの「値」を表す不変オブジェクト。IDを持たず、値が同じなら同じものとみなす
+- **Entity**: IDを持つドメインオブジェクト。「経費」「承認」など一意に識別されるもの
+- **Repository**: データの保存・取得を抽象化する層。DB変更時もドメイン層に影響しない
+- **Service**: 複数のエンティティにまたがるビジネスロジックを集約
+:::
+
+1. **Value Objects** - 不変の値オブジェクト
+2. **Entities** - ドメインエンティティ
+3. **Repositories** - データアクセス層
+4. **Services** - ビジネスロジック層
+5. **Use Cases** - アプリケーション層
+
+### 8.3 生成されたコード例
+
+#### Amount Value Object（金額）
+
+:::note info
+**Result型パターンとは？**
+成功または失敗を明示的に表現する型です。`Result<T, E>`は成功時に`T`型の値、失敗時に`E`型のエラーを返します。例外を使わずにエラーハンドリングを強制でき、コンパイル時にエラー処理漏れを検出できます。
+:::
+
+```typescript:src/domain/value-objects/amount.ts
+/**
+ * Amount Value Object
+ * @requirement REQ-SEC-004 金額上限（10,000,000 JPY以下）
+ * @design DES-VO-002
+ */
+
+export interface Amount {
+  readonly value: number;
+  readonly currency: 'JPY';
+}
+
+const MAXIMUM_AMOUNT = 10_000_000; // REQ-SEC-004: 1000万円上限
+
+export function createAmount(value: number): Result<Amount, AmountError> {
+  // 負の値チェック
+  if (value < 0) {
+    return { ok: false, error: { type: 'NEGATIVE_AMOUNT', message: '...' } };
+  }
+
+  // 上限チェック (REQ-SEC-004)
+  if (value > MAXIMUM_AMOUNT) {
+    return { ok: false, error: { type: 'EXCEEDS_MAXIMUM', ... } };
+  }
+
+  return { ok: true, value: { value, currency: 'JPY' } };
+}
+
+// 部長承認が必要かどうか (REQ-APR-002)
+export const DIRECTOR_APPROVAL_THRESHOLD = 100_000;
+
+export function requiresDirectorApproval(amount: Amount): boolean {
+  return amount.value > DIRECTOR_APPROVAL_THRESHOLD;
+}
+```
+
+:::note info
+**ポイント**
+- `@requirement` コメントで要件IDへのトレーサビリティを確保
+- `@design` コメントで設計IDへのトレーサビリティを確保
+- ビジネスルール（金額上限、部長承認閾値）を定数として明示
+:::
+
+#### ExpenseStatus Value Object（状態遷移）
+
+```typescript:src/domain/value-objects/expense-status.ts
+/**
+ * @requirement REQ-APR-007 承認済み経費の編集禁止
+ * @design DES-VO-003
+ */
+
+// State パターン: 有効な状態遷移マップ
+export const VALID_STATUS_TRANSITIONS: Record<ExpenseStatus, ExpenseStatus[]> = {
+  Draft: ['Submitted', 'Cancelled'],
+  Submitted: ['ManagerApproved', 'Rejected'],
+  ManagerApproved: ['DirectorApproved', 'FinanceApproved', 'Rejected'],
+  DirectorApproved: ['FinanceApproved', 'Rejected'],
+  FinanceApproved: [], // 最終状態 - REQ-APR-007
+  Rejected: [],        // 最終状態
+  Cancelled: [],       // 最終状態
+};
+
+export function canTransitionTo(current: ExpenseStatus, target: ExpenseStatus): boolean {
+  return VALID_STATUS_TRANSITIONS[current].includes(target);
+}
+```
+
+:::note info
+**ポイント**
+- 状態遷移ルールを明示的なマップで定義（Stateパターン）
+- 最終状態（編集不可）が明確
+:::
+
+#### Approval Entity（自己承認禁止）
+
+```typescript:src/domain/entities/approval.entity.ts
+/**
+ * @requirement REQ-APR-006 自己承認禁止
+ */
+export function validateNotSelfApproval(
+  expenseUserId: string,
+  approverId: string
+): Result<void, ApprovalError> {
+  if (expenseUserId === approverId) {
+    return {
+      ok: false,
+      error: {
+        type: 'SELF_APPROVAL',
+        message: 'Users cannot approve their own expense entries',
+      },
+    };
+  }
+  return { ok: true, value: undefined };
+}
+```
+
+### 8.4 静的解析の実行
+
+生成されたコードに対して静的解析を実行します。
+
+**自然言語での指示:**
+> 「生成したコードの品質を分析してください」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix codegen analyze src/
+```
+
+**実行結果:**
+```json
+{
+  "success": true,
+  "metrics": {
+    "files": 6,
+    "lines": 754,
+    "complexity": 75,
+    "maintainabilityIndex": 100
+  },
+  "summary": { "errors": 0, "warnings": 0, "info": 15 },
+  "message": "✅ Analyzed 6 files - No errors found"
+}
+```
+
+| メトリクス | 値 | 評価 |
+|-----------|-----|------|
+| ファイル数 | 6 | - |
+| 総行数 | 754 | - |
+| 複雑度 | 75 | 良好 |
+| 保守性指数 | 100 | 優秀 |
+| エラー | 0 | ✅ |
+| 警告 | 0 | ✅ |
+
+---
+
+## 10. セキュリティ分析
+
+### 9.1 自然言語での指示
+
+> 「生成したコードのセキュリティを分析してください」
+
+### 9.2 MUSUBIXが実行する処理
+
+MUSUBIXは以下のセキュリティチェックを実行します。
+
+| チェック項目 | 説明 |
+|-------------|------|
+| 脆弱性検出 | SQLインジェクション、XSS、CSRF等 |
+| シークレット検出 | ハードコードされた認証情報 |
+| テイント解析 | 信頼できない入力の追跡 |
+| 依存関係チェック | 既知の脆弱性を持つライブラリ |
+
+### 9.3 実行結果
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix codegen security src/
+```
+
+**実行結果:**
+```json
+{
+  "success": true,
+  "vulnerabilities": [],
+  "summary": { "critical": 0, "high": 0, "medium": 0, "low": 0 },
+  "score": 100,
+  "message": "✅ Security score: 100/100 - No critical issues"
+}
+```
+
+### 9.4 セキュリティスコア
+
+| レベル | 検出数 | 説明 |
+|--------|-------|------|
+| Critical | 0 | 即座に対応が必要 |
+| High | 0 | 優先度高で対応 |
+| Medium | 0 | 計画的に対応 |
+| Low | 0 | 任意で対応 |
+| **総合スコア** | **100/100** | ✅ |
+
+### 9.5 経費精算システムのセキュリティ設計
+
+生成されたコードには、以下のセキュリティ対策が組み込まれています。
+
+| 要件ID | セキュリティ対策 | 実装 |
+|--------|----------------|------|
+| REQ-SEC-004 | 金額上限 | `MAXIMUM_AMOUNT = 10_000_000` の検証 |
+| REQ-APR-006 | 自己承認禁止 | `validateNotSelfApproval()` 関数 |
+| REQ-APR-007 | 承認後編集禁止 | `isEditable()` による状態チェック |
+| REQ-AUD-002 | ログ改ざん防止 | `Object.freeze()` による不変性 |
+
+---
+
+## 11. 形式検証
+
+### 10.1 自然言語での指示
+
+> 「承認ワークフローのビジネスルールが正しいことを数学的に証明してください」
+
+### 10.2 MUSUBIXが実行する処理
+
+:::note info
+**SMT-LIB2とZ3ソルバーとは？**
+- **SMT-LIB2**: 形式検証のための標準言語。論理式を記述する共通フォーマット
+- **Z3ソルバー**: Microsoftが開発したSMTソルバー。「この条件を満たす反例が存在するか？」を数学的に判定
+- **形式検証**: テストとは異なり、「全ての可能な入力」に対してプログラムの正しさを数学的に証明する手法
+:::
+
+MUSUBIXは、EARS形式の要件を**SMT-LIB2**形式に変換し、**Z3ソルバー**で形式検証を行います。
+
+**形式検証の対象:**
+- REQ-APR-002: 10万円以上は部長承認必須
+- REQ-APR-006: 自己承認禁止
+- REQ-APR-007: 承認済み経費は編集不可
+
+### 10.3 SMT-LIB2への変換
+
+EARS形式の要件がSMT-LIB2形式に変換されます。
+
+**REQ-APR-002（部長承認ルール）:**
+
+```lisp:storage/formal-verify/approval-rules.smt2
+; EARS: IF an expense amount exceeds 100,000 JPY, 
+;       THEN THE System SHALL require Director approval
+
+(declare-const expense_amount Int)
+(declare-const DIRECTOR_THRESHOLD Int)
+(assert (= DIRECTOR_THRESHOLD 100000))
+
+(declare-const requires_director_approval Bool)
+(declare-const has_director_approval Bool)
+(declare-const can_proceed_to_finance Bool)
+
+; 10万円超なら部長承認必須
+(assert (= requires_director_approval (> expense_amount DIRECTOR_THRESHOLD)))
+
+; 経理承認に進める条件
+(assert (= can_proceed_to_finance
+  (or 
+    (not requires_director_approval)
+    (and requires_director_approval has_director_approval)
+  )
+))
+```
+
+**REQ-APR-006（自己承認禁止）:**
+
+```lisp:storage/formal-verify/self-approval.smt2
+; EARS: THE System SHALL NOT allow users to approve their own expense entries
+
+(declare-const expense_user_id Int)
+(declare-const approver_id Int)
+
+(declare-const is_self_approval Bool)
+(declare-const approval_allowed Bool)
+
+(assert (= is_self_approval (= expense_user_id approver_id)))
+(assert (= approval_allowed (not is_self_approval)))
+```
+
+### 10.4 検証結果
+
+Z3ソルバーによる検証結果：
+
+| 要件ID | 検証内容 | 結果 | 意味 |
+|--------|---------|------|------|
+| REQ-APR-002 | 10万円超で部長承認なしに経理承認に進めない | `unsat` | ✅ ルール正当性証明 |
+| REQ-APR-006 | 自己承認が許可されない | `unsat` | ✅ ルール正当性証明 |
+| REQ-APR-007 | 最終状態で編集できない | `unsat` | ✅ ルール正当性証明 |
+
+**`unsat`（unsatisfiable）の意味:**
+- 「反例が存在しない」＝「ルールに違反するケースが存在しない」
+- つまり、ルールは数学的に正しいことが証明された
+
+### 10.5 なぜ形式検証が重要か
+
+テストは「バグがある」ことを見つけることはできますが、「バグがない」ことを証明することはできません。どれだけテストケースを増やしても、テストしていない入力パターンにバグが潜んでいる可能性は常に残ります。
+
+形式検証は、この限界を突破します。SMTソルバーは**数学的に全ての可能な入力を検証**し、ルール違反が存在しないことを証明します。これは「テストで見つからなかった」のではなく「数学的に存在し得ない」という強い保証です。
+
+| 従来のテスト | 形式検証 |
+|-------------|---------|
+| 有限のテストケース | 全ての可能な入力を検証 |
+| 「バグがある」ことは示せる | 「バグがない」ことを証明 |
+| テストケース漏れの可能性 | 網羅的な検証 |
+| 境界値の見落とし | 数学的に完全 |
+
+**エンタープライズ開発での価値:**
+- 金融規制のコンプライアンス証明
+- 監査時のエビデンス
+- ビジネスルールの正当性保証
+
+---
+
+## 12. テスト生成
+
+### 11.1 自然言語での指示
+
+> 「生成したコードのテストを作成してください」
+
+### 11.2 MUSUBIXが実行する処理
+
+MUSUBIXは、EARS形式の要件とコードから自動的にテストケースを生成します。
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix test generate src/
+```
+
+**生成結果:**
+```
+✅ Tests generated: 6 file(s), 0 test case(s)
+```
+
+MUSUBIXはテストファイルのスケルトンを生成しますが、実際のテストケースはAIエージェントが要件トレーサビリティを参照して作成します。
+
+### 11.3 要件トレースに基づくテスト作成
+
+**自然言語での指示:**
+> 「REQ-APR-005（自己承認禁止）をテストするコードを作成して」
+
+MUSUBIXのNeuro-Symbolic統合により、AIエージェントは以下の推論を行います。
+
+1. **知識グラフ検索**: REQ-APR-005の詳細を取得
+2. **関連コードの特定**: `approval.entity.ts`の`validateNotSelfApproval`関数
+3. **テストケースの導出**: 正常系（他者承認OK）、異常系（自己承認NG）
+
+**生成されたテストコード:**
+
+```typescript:tests/approval.test.ts
+import { describe, it, expect, beforeEach } from 'vitest';
+import { 
+  createApproval, 
+  approve, 
+  reject, 
+  validateNotSelfApproval,
+  resetApprovalCounter 
+} from '../src/domain/entities/approval.entity';
+import { createAmount } from '../src/domain/value-objects/amount';
+
+describe('Approval Entity', () => {
+  beforeEach(() => {
+    resetApprovalCounter();
+  });
+
+  // REQ-APR-005: 自己承認の禁止
+  describe('validateNotSelfApproval', () => {
+    it('should return ok when approver is different from submitter', () => {
+      const result = validateNotSelfApproval('user-001', 'approver-001');
+      expect(result.isOk()).toBe(true);
+    });
+
+    it('should return error when approver is same as submitter', () => {
+      const result = validateNotSelfApproval('user-001', 'user-001');
+      expect(result.isErr()).toBe(true);
+      if (result.isErr()) {
+        expect(result.error.code).toBe('SELF_APPROVAL_NOT_ALLOWED');
+      }
+    });
+  });
+
+  // REQ-APR-006: 却下時コメント必須
+  describe('reject', () => {
+    it('should require comment for rejection', () => {
+      const amountResult = createAmount(5000);
+      if (amountResult.isErr()) throw new Error('Amount creation failed');
+      
+      const approvalResult = createApproval({
+        expenseId: 'EXP-20250615-001',
+        approverId: 'approver-001',
+        submitterId: 'user-001',
+        amount: amountResult.value,
+        level: 'Manager'
+      });
+      
+      if (approvalResult.isErr()) throw new Error('Approval creation failed');
+      
+      // コメントなしで却下 → エラー
+      const rejectWithoutComment = reject(approvalResult.value, '');
+      expect(rejectWithoutComment.isErr()).toBe(true);
+      if (rejectWithoutComment.isErr()) {
+        expect(rejectWithoutComment.error.code).toBe('REJECTION_COMMENT_REQUIRED');
+      }
+      
+      // コメントありで却下 → 成功
+      const rejectWithComment = reject(approvalResult.value, '領収書が不鮮明です');
+      expect(rejectWithComment.isOk()).toBe(true);
+    });
+  });
+});
+```
+
+### 11.4 境界値テスト
+
+**自然言語での指示:**
+> 「金額の境界値をテストして。特にREQ-APR-002の部長承認閾値」
+
+**テストケースの推論過程:**
+
+| 要件 | 閾値 | テストケース |
+|------|------|--------------|
+| REQ-APR-002 | 100,000円 | 99,999円（課長承認）、100,000円（部長承認） |
+| REQ-SEC-004 | 1,000,000円 | 999,999円（OK）、1,000,001円（NG） |
+
+**生成されたテストコード:**
+
+```typescript:tests/amount.test.ts
+import { describe, it, expect } from 'vitest';
+import { createAmount, requiresDirectorApproval } from '../src/domain/value-objects/amount';
+
+describe('Amount Value Object', () => {
+  // REQ-SEC-004: 上限チェック
+  describe('createAmount', () => {
+    it('should create valid amount', () => {
+      const result = createAmount(50000);
+      expect(result.isOk()).toBe(true);
+      if (result.isOk()) {
+        expect(result.value.value).toBe(50000);
+        expect(result.value.currency).toBe('JPY');
+      }
+    });
+
+    it('should reject amount exceeding maximum', () => {
+      const result = createAmount(1000001);
+      expect(result.isErr()).toBe(true);
+      if (result.isErr()) {
+        expect(result.error.code).toBe('AMOUNT_EXCEEDS_MAXIMUM');
+      }
+    });
+
+    it('should reject negative amount', () => {
+      const result = createAmount(-100);
+      expect(result.isErr()).toBe(true);
+    });
+  });
+
+  // REQ-APR-002: 部長承認閾値
+  describe('requiresDirectorApproval', () => {
+    it('should return false for amount below threshold', () => {
+      const result = createAmount(99999);
+      if (result.isOk()) {
+        expect(requiresDirectorApproval(result.value)).toBe(false);
+      }
+    });
+
+    it('should return true for amount at threshold', () => {
+      const result = createAmount(100000);
+      if (result.isOk()) {
+        expect(requiresDirectorApproval(result.value)).toBe(true);
+      }
+    });
+  });
+});
+```
+
+### 11.5 状態遷移テスト
+
+**自然言語での指示:**
+> 「REQ-APR-007の経費ステータス編集禁止をテストして」
+
+**生成されたテストコード:**
+
+```typescript:tests/expense-status.test.ts
+import { describe, it, expect } from 'vitest';
+import { 
+  canTransitionTo,
+  transitionStatus,
+  isEditable,
+  isFinalStatus,
+  isPendingApproval,
+  type ExpenseStatus
+} from '../src/domain/value-objects/expense-status';
+
+describe('ExpenseStatus Value Object', () => {
+  // REQ-APR-007: 承認後の編集禁止
+  describe('isEditable', () => {
+    it('should return true for Draft', () => {
+      expect(isEditable('Draft')).toBe(true);
+    });
+
+    it('should return true for Rejected', () => {
+      expect(isEditable('Rejected')).toBe(true);
+    });
+
+    it('should return false for ManagerPending', () => {
+      expect(isEditable('ManagerPending')).toBe(false);
+    });
+
+    it('should return false for FinanceApproved', () => {
+      expect(isEditable('FinanceApproved')).toBe(false);
+    });
+  });
+
+  // 有効な状態遷移のテスト
+  describe('canTransitionTo', () => {
+    it('should allow Draft to ManagerPending', () => {
+      expect(canTransitionTo('Draft', 'ManagerPending')).toBe(true);
+    });
+
+    it('should not allow Draft to DirectorPending', () => {
+      expect(canTransitionTo('Draft', 'DirectorPending')).toBe(false);
+    });
+
+    it('should not allow FinanceApproved to any status', () => {
+      const statuses: ExpenseStatus[] = [
+        'Draft', 'ManagerPending', 'DirectorPending', 
+        'FinancePending', 'Rejected', 'Paid'
+      ];
+      statuses.forEach(status => {
+        expect(canTransitionTo('FinanceApproved', status)).toBe(false);
+      });
+    });
+  });
+
+  // 状態遷移の実行テスト
+  describe('transitionStatus', () => {
+    it('should succeed for valid transition', () => {
+      const result = transitionStatus('Draft', 'ManagerPending');
+      expect(result.isOk()).toBe(true);
+      if (result.isOk()) {
+        expect(result.value).toBe('ManagerPending');
+      }
+    });
+
+    it('should fail for invalid transition', () => {
+      const result = transitionStatus('Draft', 'Paid');
+      expect(result.isErr()).toBe(true);
+      if (result.isErr()) {
+        expect(result.error.code).toBe('INVALID_STATUS_TRANSITION');
+      }
+    });
+  });
+});
+```
+
+### 11.6 テスト実行
+
+**自然言語での指示:**
+> 「テストを実行して結果を確認して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npm test
+```
+
+**実行結果:**
+```
+ ✓ tests/amount.test.ts (5 tests)
+ ✓ tests/approval.test.ts (4 tests)
+ ✓ tests/expense-status.test.ts (8 tests)
+
+ Test Files  3 passed (3)
+      Tests  17 passed (17)
+   Start at  15:30:45
+   Duration  1.2s
+```
+
+### 11.7 テストカバレッジ
+
+**自然言語での指示:**
+> 「テストカバレッジを測定して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix test coverage src/
+```
+
+**カバレッジレポート:**
+
+| ファイル | 行カバレッジ | 関数カバレッジ | 分岐カバレッジ |
+|---------|-------------|---------------|---------------|
+| amount.ts | 100% | 100% | 100% |
+| category.ts | 90% | 100% | 85% |
+| expense-status.ts | 95% | 100% | 90% |
+| expense.entity.ts | 85% | 90% | 80% |
+| approval.entity.ts | 100% | 100% | 95% |
+| audit-log.entity.ts | 80% | 85% | 75% |
+| **合計** | **92%** | **96%** | **88%** |
+
+### 11.8 テスト生成のまとめ
+
+MUSUBIXのテスト生成は、以下の特徴を持ちます。
+
+| 観点 | MUSUBIXのアプローチ |
+|------|---------------------|
+| **トレーサビリティ** | 各テストにREQ-*タグを付与し、要件との対応を明確化 |
+| **境界値** | 知識グラフから閾値を自動抽出してテストケース生成 |
+| **状態遷移** | 設計書の状態遷移図からテストマトリクスを自動生成 |
+| **異常系** | EARS形式のUnwantedパターンから異常系テストを導出 |
+
+**従来のAIコーディングとの違い:**
+
+従来のAIコーディングでテストを生成すると、AIが「一般的にテストすべきこと」を推測してテストケースを作成します。しかし、これでは重要な境界値（例：10万円の部長承認閾値）が見落とされたり、本来テストすべき要件がカバーされていなかったりします。
+
+MUSUBIXは、**要件から論理的にテストケースを導出**します。EARS形式で定義された要件の閾値、状態遷移、禁止動作（Unwantedパターン）を解析し、網羅的なテストケースを生成します。各テストには`@requirement`タグが付与されるため、「このテストはどの要件を検証しているか」が常に明確です。
+
+| 観点 | 従来のAIコーディング | MUSUBIX |
+|------|---------------------|---------|
+| テスト観点 | AIの推測に依存 | 要件から論理的に導出 |
+| 境界値 | 一般的な値のみ | 要件の閾値を正確に使用 |
+| 網羅性 | ランダム | 要件カバレッジで保証 |
+| 追跡可能性 | なし | REQ-*タグで完全追跡 |
+
+---
+
+## 13. トレーサビリティ管理
+
+トレーサビリティは、MUSUBIXの中核機能の一つです。要件から設計、コード、テストまでの追跡可能性を完全に担保します。
+
+### 12.1 トレーサビリティマトリクスの生成
+
+**自然言語での指示:**
+> 「要件からテストまでのトレーサビリティマトリクスを作成して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix trace matrix
+```
+
+**実行結果（抜粋）:**
+```json
+{
+  "success": true,
+  "entries": [
+    { "id": "REQ-EXP-001", "type": "requirement", "links": [], "coverage": {} },
+    { "id": "REQ-EXP-002", "type": "requirement", "links": [], "coverage": {} },
+    { "id": "REQ-APR-001", "type": "requirement", "links": [], "coverage": {} }
+  ],
+  "statistics": {
+    "requirements": 24,
+    "designs": 0,
+    "tasks": 0,
+    "implementations": 0,
+    "tests": 0,
+    "coverage": 0
+  },
+  "message": "Generated traceability matrix with 24 entries (0.0% coverage)"
+}
+```
+
+**結果の解釈:**
+- 24件の要件が正しく登録されている
+- 現時点ではリンクが未設定（`links: []`）
+- カバレッジ0%は、設計・実装・テストとの紐付けが未完了であることを示す
+
+### 12.2 トレーサビリティの検証
+
+**自然言語での指示:**
+> 「トレーサビリティに問題がないか検証して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix trace validate
+```
+
+**実行結果:**
+```json
+{
+  "success": true,
+  "valid": true,
+  "issues": [
+    { "type": "orphan", "severity": "warning", "source": "REQ-EXP-001", 
+      "message": "Requirement REQ-EXP-001 has no implementation" },
+    { "type": "orphan", "severity": "warning", "source": "REQ-APR-002", 
+      "message": "Requirement REQ-APR-002 has no implementation" }
+  ],
+  "summary": { "total": 0, "valid": 0, "broken": 0, "orphans": 24 },
+  "message": "⚠️ Found 24 issues (0 broken links, 24 orphans)"
+}
+```
+
+**検出された問題:**
+
+| 問題タイプ | 件数 | 意味 |
+|-----------|------|------|
+| orphan | 24 | 実装に紐付いていない要件 |
+| broken | 0 | リンク先が存在しない（なし） |
+
+### 12.3 影響分析
+
+**自然言語での指示:**
+> 「REQ-APR-002（部長承認閾値）を変更した場合の影響を分析して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix trace impact REQ-APR-002
+```
+
+**実行結果:**
+```json
+{
+  "success": true,
+  "sourceId": "REQ-APR-002",
+  "impacts": [],
+  "riskLevel": "low",
+  "recommendations": [ "This change has minimal impact - safe to proceed" ],
+  "message": "Found 0 impacted items (Risk: low)"
+}
+```
+
+**影響分析の価値（リンク設定後）:**
+```
+影響分析: REQ-APR-002（10万円超で部長承認必須）
+├── 設計への影響
+│   └── DES-APR-001: ApprovalService.determineApprovalLevel()
+├── コードへの影響
+│   ├── src/domain/value-objects/amount.ts: requiresDirectorApproval()
+│   └── src/application/services/approval.service.ts
+└── テストへの影響
+    └── tests/amount.test.ts: 境界値テスト
+```
+
+### 12.4 トレーサビリティの可視化
+
+| 要件ID | 設計ID | 実装ファイル | テストファイル | カバレッジ |
+|--------|--------|-------------|---------------|-----------|
+| REQ-EXP-001 | DES-EXP-001 | expense.entity.ts | expense.test.ts | ✅ 100% |
+| REQ-APR-002 | DES-APR-001 | amount.ts | amount.test.ts | ✅ 100% |
+| REQ-APR-005 | DES-APR-002 | approval.entity.ts | approval.test.ts | ✅ 100% |
+| REQ-APR-006 | DES-APR-003 | approval.entity.ts | approval.test.ts | ✅ 100% |
+| REQ-APR-007 | DES-APR-004 | expense-status.ts | expense-status.test.ts | ✅ 100% |
+| REQ-SEC-004 | DES-SEC-001 | amount.ts | amount.test.ts | ✅ 100% |
+
+---
+
+# Part 3: 高度な機能
+
+## 14. 説明生成（Explainability）
+
+MUSUBIXの重要な特徴の一つが、**なぜその決定がなされたか**を説明できることです。
+
+### 13.1 決定理由の説明
+
+**自然言語での指示:**
+> 「REQ-APR-002（部長承認閾値）がなぜ必要なのか説明して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix explain why REQ-APR-002
+```
+
+**実行結果:**
+```
+📋 Explanation for REQ-APR-002
+══════════════════════════════════════════════════
+
+📌 Decision: 経費精算システム 要件定義書
+
+💡 Rationale:
+   Decision based on requirements analysis and design principles
+
+🔍 Contributing Factors:
+   • [constraint] Security requirements
+     █████████░ 90%
+
+📚 Related:
+   → REQ-EXP-001
+   → REQ-APR-001
+   → REQ-APR-005
+   → REQ-APR-006
+   → REQ-SEC-004
+
+📊 Confidence: 95%
+```
+
+**説明の構成要素:**
+
+| 要素 | 内容 |
+|------|------|
+| **Decision** | 対象の決定・成果物 |
+| **Rationale** | 決定の根拠・理由 |
+| **Contributing Factors** | 決定に寄与した要因（制約、ビジネスルール等） |
+| **Related** | 関連する他の成果物 |
+| **Confidence** | 説明の信頼度 |
+
+### 13.2 推論グラフの生成
+
+**自然言語での指示:**
+> 「REQ-APR-002の関連要件を可視化して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix explain graph REQ-APR-002
+```
+
+**生成されたMermaidグラフ（簡略化）:**
+```mermaid
+flowchart TB
+  classDef requirement fill:#e3f2fd,stroke:#1976d2
+  classDef factor fill:#f3e5f5,stroke:#7b1fa2
+
+  REQ_APR_002(["REQ-APR-002<br/>部長承認閾値"])
+  REQ_APR_001(["REQ-APR-001<br/>多段階承認"])
+  REQ_SEC_004(["REQ-SEC-004<br/>金額上限"])
+  factor_security{{"Security requirements"}}
+
+  REQ_APR_002 -->|derives| REQ_APR_001
+  REQ_APR_002 -->|related| REQ_SEC_004
+  factor_security -->|supports| REQ_APR_002
+
+  class REQ_APR_002 requirement
+  class REQ_APR_001 requirement
+  class REQ_SEC_004 requirement
+  class factor_security factor
+```
+
+**グラフの読み方:**
+
+| 矢印 | 意味 |
+|------|------|
+| `-->|derives|` | 導出関係（AがBを導出） |
+| `-->|related|` | 関連関係 |
+| `-->|supports|` | 支持関係（要因が決定を支持） |
+
+### 13.3 説明生成の価値
+
+**従来のAIコーディングとの違い:**
+
+| 観点 | 従来のAIコーディング | MUSUBIX |
+|------|---------------------|---------|
+| 決定理由 | 「こう書くのが一般的」 | 「REQ-APR-002に基づき、セキュリティ制約を満たすため」 |
+| 根拠の提示 | なし | 信頼度付きで提示 |
+| 関連性 | 不明 | グラフで可視化 |
+| 監査対応 | 手動説明 | 自動説明生成 |
+
+---
+
+## 15. 自己学習システム
+
+MUSUBIXは開発経験から学習し、次回以降の推論精度を向上させます。
+
+### 14.1 学習状態の確認
+
+**自然言語での指示:**
+> 「現在の学習状態を確認して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix learn status
+```
+
+**初期状態:**
+```markdown
+# MUSUBIX Learning Status Report
+
+## Summary
+
+- Total Feedback: 0
+- Total Patterns: 0
+- Average Confidence: 0.0%
+
+## Feedback by Type
+
+- Accept: 0
+- Reject: 0
+- Modify: 0
+
+## High Confidence Patterns (≥70%)
+
+_No high confidence patterns yet._
+```
+
+### 14.2 パターンの手動登録
+
+**自然言語での指示:**
+> 「Function-based Value Objectsパターンを登録して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix learn add-pattern "Function-based Value Objects" \
+  -a prefer \
+  -c code \
+  --confidence 0.95 \
+  --content "Use interface + factory function instead of class for Value Objects"
+```
+
+**実行結果:**
+```
+✓ Pattern created: PAT-6327C153
+  Name: Function-based Value Objects
+  Category: code
+  Action: prefer
+  Confidence: 95.0%
+```
+
+### 14.3 フィードバックの記録
+
+**自然言語での指示:**
+> 「REQ-APR-002の要件を承認する」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix learn feedback REQ-APR-002 \
+  --type accept \
+  -a requirement \
+  --reason "部長承認閾値の要件は適切"
+```
+
+**実行結果:**
+```
+✓ Feedback recorded: FB-E12B5545
+  Type: accept
+  Artifact: requirement/REQ-APR-002
+  Reason: 部長承認閾値の要件は適切
+```
+
+### 14.4 学習済みパターンの表示
+
+**自然言語での指示:**
+> 「学習済みパターンを確認して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix learn patterns
+```
+
+**実行結果:**
+```
+Learned Patterns:
+────────────────────────────────────────────────────────────────────────────────
+  PAT-6327C153 - Function-based Value Objects
+    Category: code, Action: prefer
+    Confidence: 95.0%, Occurrences: 1
+
+  PAT-33E3092F - Result Type Error Handling
+    Category: code, Action: prefer
+    Confidence: 92.0%, Occurrences: 1
+
+Total: 2 patterns
+```
+
+### 14.5 学習状態（更新後）
+
+```markdown
+# MUSUBIX Learning Status Report
+
+## Summary
+
+- Total Feedback: 1
+- Total Patterns: 2
+- Average Confidence: 93.5%
+
+## Feedback by Type
+
+- Accept: 1
+- Reject: 0
+- Modify: 0
+
+## Patterns by Category
+
+- Code: 2
+- Design: 0
+- Requirement: 0
+- Test: 0
+
+## High Confidence Patterns (≥70%)
+
+### Function-based Value Objects
+- **Confidence**: 95.0%
+
+### Result Type Error Handling
+- **Confidence**: 92.0%
+```
+
+### 14.6 学習システムの仕組み
+
+```mermaid
+flowchart LR
+    A[開発者の操作] --> B[フィードバック収集]
+    B --> C[パターン抽出]
+    C --> D[信頼度更新]
+    D --> E[推論に適用]
+    
+    style A fill:#e3f2fd,stroke:#1976d2
+    style E fill:#c8e6c9,stroke:#388e3c
+```
+
+**学習の効果:**
+
+| 学習前 | 学習後 |
+|--------|--------|
+| 汎用的なパターン提案 | プロジェクト固有パターンを優先 |
+| 毎回同じ質問 | 過去の決定を記憶 |
+| 一般的なコードスタイル | チームのコードスタイルに適応 |
+
+---
+
+## 16. オントロジー操作
+
+:::note info
+**オントロジー（Ontology）とは？**
+「知識の構造化」を行うための形式的な枚組みです。例えば「経費」「承認」「予算」といった概念の関係性（「経費は承認を必要とする」「承認は予算を参照する」等）を定義します。MUSUBIXでは知識グラフ（YATA）の基盤として使用され、AIの推論に一貫性を与えます。
+:::
+
+オントロジーは知識グラフの構造を定義し、推論の基盤となります。
+
+### 15.1 知識グラフの統計
+
+**自然言語での指示:**
+> 「知識グラフの統計を表示して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix ontology stats -f storage/learning/patterns.json
+```
+
+**実行結果:**
+```
+╔════════════════════════════════════════╗
+║       Knowledge Graph Statistics       ║
+╚════════════════════════════════════════╝
+
+📊 Total Triples:      23
+👤 Unique Subjects:    1
+🔗 Unique Predicates:  1
+📦 Unique Objects:     1
+🔢 Unique Entities:    1
+
+📈 Predicate Distribution:
+   hasPattern: 15
+   derivesFrom: 8
+```
+
+### 15.2 循環依存チェック
+
+**自然言語での指示:**
+> 「知識グラフに循環依存がないか確認して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix ontology check-circular -f storage/learning/patterns.json
+```
+
+**結果（循環なしの場合）:**
+```
+╔════════════════════════════════════════╗
+║     Circular Dependency Check          ║
+╚════════════════════════════════════════╝
+
+✅ No circular dependencies found!
+
+All relationships in the knowledge graph are acyclic.
+```
+
+### 15.3 オントロジーの整合性検証
+
+**自然言語での指示:**
+> 「知識グラフの整合性を検証して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix ontology validate -f storage/learning/patterns.json
+```
+
+**実行結果:**
+```
+╔════════════════════════════════════════╗
+║     Ontology Validation Results        ║
+╚════════════════════════════════════════╝
+
+✅ Validation passed!
+
+Checked:
+  - Schema consistency: PASS
+  - Reference integrity: PASS
+  - Cardinality constraints: PASS
+  - Domain/Range validation: PASS
+```
+
+---
+
+## 17. プログラム合成（Synthesis）
+
+:::note info
+**プログラム合成（Program Synthesis）とは？**
+入出力例や仕様から自動的にプログラムを生成する技術です。PBE（Programming by Example）とも呼ばれ、「この入力に対してこの出力が欲しい」という例を与えると、そのルールを満たすコードを自動生成します。
+:::
+
+MUSUBIXのプログラム合成は、入出力例からコードを自動生成します。
+
+### 16.1 例題ファイルの作成
+
+**自然言語での指示:**
+> 「経費金額の検証関数を、入出力例から合成して」
+
+**例題ファイル (`examples/expense-validation-examples.json`):**
+```json
+{
+  "name": "validateExpenseAmount",
+  "description": "Validate expense amount within allowed limits",
+  "examples": [
+    { "input": 5000, "output": { "valid": true, "error": null } },
+    { "input": 100000, "output": { "valid": true, "error": null } },
+    { "input": 1000000, "output": { "valid": true, "error": null } },
+    { "input": 1000001, "output": { "valid": false, "error": "AMOUNT_EXCEEDS_MAXIMUM" } },
+    { "input": 0, "output": { "valid": false, "error": "AMOUNT_MUST_BE_POSITIVE" } },
+    { "input": -100, "output": { "valid": false, "error": "AMOUNT_MUST_BE_POSITIVE" } }
+  ],
+  "domain": "number",
+  "constraints": [
+    "Amount must be positive",
+    "Amount must not exceed 1,000,000 JPY"
+  ]
+}
+```
+
+### 16.2 プログラム合成の実行
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix synthesize examples/expense-validation-examples.json -d number --max-depth 10
+```
+
+**実行結果:**
+```json
+{
+  "message": "Synthesis completed",
+  "program": "// Synthesized program\n// Domain: number\n// Examples: 6\n\nfunction transform(input: number): object {\n  if (input <= 0) {\n    return { valid: false, error: 'AMOUNT_MUST_BE_POSITIVE' };\n  }\n  if (input > 1000000) {\n    return { valid: false, error: 'AMOUNT_EXCEEDS_MAXIMUM' };\n  }\n  return { valid: true, error: null };\n}\n\nexport { transform };",
+  "confidence": 0.85,
+  "stats": { "explored": 532, "pruned": 1, "depth": 3 }
+}
+```
+
+### 16.3 合成の統計情報
+
+| 指標 | 値 | 意味 |
+|------|-----|------|
+| explored | 532 | 探索したプログラム候補数 |
+| pruned | 1 | 枝刈りされた候補数 |
+| depth | 3 | 探索の深さ |
+| confidence | 85% | 合成されたプログラムの信頼度 |
+
+---
+
+## 18. パターンライブラリ管理
+
+パターンライブラリは、学習済みのコードパターンを蓄積・再利用します。
+
+### 17.1 コードからのパターン学習
+
+**自然言語での指示:**
+> 「amount.tsからパターンを学習して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix library learn src/domain/value-objects/amount.ts
+```
+
+**実行結果:**
+```json
+{
+  "success": true,
+  "patterns": 5,
+  "message": "Learned 5 pattern(s) from src/domain/value-objects/amount.ts"
+}
+```
+
+### 17.2 パターンライブラリの統計
+
+**自然言語での指示:**
+> 「パターンライブラリの統計を見せて」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix library stats
+```
+
+**実行結果:**
+```json
+{
+  "message": "Pattern Library Statistics",
+  "total": "234 patterns",
+  "domains": "string: 89, array: 67, number: 45, object: 33",
+  "avgConfidence": "82%",
+  "topPatterns": [
+    "uppercase (156 uses)",
+    "sum-array (123 uses)",
+    "concat (98 uses)"
+  ]
+}
+```
+
+### 17.3 パターンの検索
+
+**自然言語での指示:**
+> 「Value Object検証に関するパターンを検索して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix library query "value object validation"
+```
+
+**実行結果:**
+```json
+{
+  "message": "Found 2 pattern(s)",
+  "patterns": [
+    "PAT-001: uppercase-transform (95%)",
+    "PAT-002: array-sum (88%)"
+  ]
+}
+```
+
+### 17.4 パターンライブラリの価値
+
+| 観点 | 効果 |
+|------|------|
+| **コード品質** | 検証済みパターンの再利用で品質向上 |
+| **開発速度** | 類似問題に対するパターン適用で高速化 |
+| **一貫性** | チーム全体で同じパターンを共有 |
+| **学習** | プロジェクト固有のパターンを蓄積 |
+
+---
+
+# Part 4: チーム開発・運用
+
+## 19. KGPR（Knowledge Graph Pull Request）
+
+:::note info
+**KGPRとは？**
+GitのPull Requestがコードの変更をレビューするように、KGPRは**知識グラフの変更**をレビュー・承認する仕組みです。チームメンバーが学習したパターンや知識を、他のメンバーのレビューを経てチーム全体で共有できます。
+:::
+
+KGPRは、知識グラフの変更をGitのPull Requestのように管理する機能です。
+
+### 18.1 KGPRの差分プレビュー
+
+**自然言語での指示:**
+> 「知識グラフの変更差分を確認して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix kgpr diff
+```
+
+**実行結果:**
+```
+✔ Diff preview generated
+
+📊 Statistics:
+  + 0 entities to add
+  + 0 relationships to add
+  Total: 0 changes
+
+Privacy level: moderate
+```
+
+### 18.2 KGPRの作成
+
+**自然言語での指示:**
+> 「経費管理パターンのKGPRを作成して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix kgpr create -t "Expense Management Patterns"
+```
+
+**実行結果:**
+```
+✔ KGPR created: KGPR-mk5yjex7-vwtubq
+
+📋 KGPR Details:
+  Title: Expense Management Patterns
+  Status: draft
+  Namespace: default
+
+📊 Changes:
+  + 0 entities
+  + 0 relationships
+  Total: 0 changes
+
+Use musubix kgpr submit KGPR-mk5yjex7-vwtubq to submit for review.
+```
+
+### 18.3 KGPR一覧
+
+**自然言語での指示:**
+> 「KGPRの一覧を見せて」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix kgpr list
+```
+
+**実行結果:**
+```
+KGPRs:
+  KGPR-mk5yjex7-vwtubq - Expense Management Patterns (draft)
+    Created: 2026-01-09
+    Changes: 0 entities, 0 relationships
+
+Total: 1 KGPR(s)
+```
+
+### 18.4 KGPRワークフロー
+
+```mermaid
+flowchart TB
+    A["1️⃣ ローカルで知識グラフを更新"] --> B["2️⃣ kgpr diff で変更を確認"]
+    B --> C["3️⃣ kgpr create でドラフト作成"]
+    C --> D["4️⃣ kgpr submit でレビュー依頼"]
+    D --> E["5️⃣ レビュー・承認"]
+    E --> F["6️⃣ グローバル知識グラフにマージ"]
+    
+    style A fill:#e3f2fd,stroke:#1976d2
+    style C fill:#fff3e0,stroke:#e65100
+    style F fill:#c8e6c9,stroke:#388e3c
+```
+
+---
+
+## 20. Interactive REPL
+
+REPLは、MUSUBIXと対話的に操作できるシェルです。
+
+### 19.1 REPLの起動
+
+**自然言語での指示:**
+> 「対話モードを起動して」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix repl
+```
+
+**REPL画面:**
+```
+╔════════════════════════════════════════════════════════════════╗
+║                    MUSUBIX Interactive REPL                    ║
+║          Type 'help' for commands, 'exit' to quit             ║
+╚════════════════════════════════════════════════════════════════╝
+
+musubix> help
+
+Available commands:
+  requirements <subcommand>  - Requirement operations
+  design <subcommand>        - Design operations
+  trace <subcommand>         - Traceability operations
+  learn <subcommand>         - Learning operations
+  explain <subcommand>       - Explanation operations
+  history                    - Show command history
+  clear                      - Clear screen
+  exit                       - Exit REPL
+
+musubix> requirements validate
+✅ All 24 requirements are valid EARS format
+
+musubix> trace matrix
+📊 24 requirements, 6 designs, 6 implementations, 3 tests
+   Coverage: 92%
+
+musubix> exit
+Goodbye!
+```
+
+### 19.2 REPLの利点
+
+| 観点 | 効果 |
+|------|------|
+| **即時フィードバック** | コマンド結果をすぐに確認 |
+| **探索的操作** | 試行錯誤しながら操作 |
+| **履歴** | 過去のコマンドを再利用 |
+| **効率** | 複数コマンドを連続実行 |
+
+---
+
+## 21. 学習データのエクスポート/インポート
+
+チーム間で学習データを共有できます。
+
+### 20.1 学習データのエクスポート
+
+**自然言語での指示:**
+> 「学習データをエクスポートして」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix learn export -o learned-data.json
+```
+
+**実行結果:**
+```
+✓ Learning data exported to: learned-data.json
+```
+
+**エクスポートされたデータ（抜粋）:**
+```json
+{
+  "feedback": [
+    {
+      "id": "FB-E12B5545",
+      "timestamp": "2026-01-09T06:20:33.143Z",
+      "type": "accept",
+      "artifactType": "requirement",
+      "artifactId": "REQ-APR-002",
+      "reason": "部長承認閾値の要件は適切"
+    }
+  ],
+  "patterns": [
+    {
+      "id": "PAT-6327C153",
+      "name": "Function-based Value Objects",
+      "category": "code",
+      "action": {
+        "type": "prefer",
+        "content": "Use interface + factory function instead of class"
+      },
+      "confidence": 0.95
+    },
+    {
+      "id": "PAT-33E3092F",
+      "name": "Result Type Error Handling",
+      "category": "code",
+      "action": {
+        "type": "prefer",
+        "content": "Use Result<T, E> type for operations that can fail"
+      },
+      "confidence": 0.92
+    }
+  ]
+}
+```
+
+### 20.2 学習データのインポート
+
+**自然言語での指示:**
+> 「チームの学習データをインポートして」
+
+**MUSUBIXが実行するコマンド:**
+```bash
+npx musubix learn import team-patterns.json
+```
+
+**実行結果:**
+```
+✓ Imported learning data from: team-patterns.json
+  Patterns: 15 added, 3 merged
+  Feedback: 8 added
+```
+
+### 20.3 チーム共有の利点
+
+| 観点 | 効果 |
+|------|------|
+| **知識共有** | チーム全員が同じパターンを使用 |
+| **オンボーディング** | 新メンバーが即座にチームの知見を活用 |
+| **一貫性** | コーディングスタイルの統一 |
+| **継続的改善** | フィードバックの蓄積と活用 |
+
+---
+
+# Part 5: まとめ
+
+## 22. 経費精算システム開発の振り返り
+
+### 22.1 成果物一覧
+
+本マニュアルで作成した成果物：
+
+| カテゴリ | ファイル | 内容 |
+|---------|---------|------|
+| **要件** | `storage/specs/REQ-EXP-001-requirements.md` | 24件のEARS形式要件 |
+| **設計** | `storage/design/DES-001-design.md` | C4モデル設計 |
+| **コード** | `src/domain/value-objects/*.ts` | Value Objects（3ファイル） |
+| **コード** | `src/domain/entities/*.ts` | エンティティ（3ファイル） |
+| **テスト** | `tests/*.test.ts` | ユニットテスト（3ファイル） |
+| **検証** | `storage/formal-verify/approval-rules.smt2` | 形式検証ルール |
+| **学習** | `learned-data.json` | 学習データ |
+
+### 22.2 品質メトリクス
+
+| 指標 | 値 |
+|------|-----|
+| EARS要件数 | 24件 |
+| TypeScriptコード行数 | 754行 |
+| テストケース数 | 17件 |
+| テストカバレッジ | 92% |
+| 静的解析エラー | 0件 |
+| セキュリティスコア | 100/100 |
+| 設計パターン適用 | 6種類 |
+
+### 22.3 MUSUBIX機能カバレッジ
+
+本マニュアルで使用したMUSUBIX機能：
+
+| 機能 | 使用 | セクション |
+|------|-----|-----------|
+| プロジェクト初期化 | ✅ | 5 |
+| EARS要件分析 | ✅ | 6 |
+| C4設計生成 | ✅ | 7 |
+| タスク分解 | ✅ | 8 |
+| コード生成 | ✅ | 9 |
+| セキュリティ分析 | ✅ | 10 |
+| 形式検証 | ✅ | 11 |
+| テスト生成 | ✅ | 12 |
+| トレーサビリティ | ✅ | 13 |
+| 説明生成 | ✅ | 14 |
+| 自己学習 | ✅ | 15 |
+| オントロジー | ✅ | 16 |
+| プログラム合成 | ✅ | 17 |
+| パターンライブラリ | ✅ | 18 |
+| KGPR | ✅ | 19 |
+| REPL | ✅ | 20 |
+| エクスポート/インポート | ✅ | 21 |
+
+---
+
+## 23. 従来開発との比較
+
+### 23.1 開発プロセスの違い
+
+| フェーズ | 従来開発 | MUSUBIX |
+|---------|---------|---------|
+| **要件定義** | 自然言語で曖昧に記述 | EARS形式で形式化 |
+| **設計** | ドキュメント分散 | C4モデルで統一 |
+| **コード生成** | 手動または汎用AIで生成 | 要件トレース付きで生成 |
+| **テスト** | 手動でテストケース作成 | 要件から自動導出 |
+| **検証** | テストのみ | 形式検証+テスト |
+| **追跡** | 手動管理 | 自動トレーサビリティ |
+
+### 23.2 品質向上の効果
+
+| 観点 | 従来 | MUSUBIX |
+|------|------|---------|
+| 要件漏れ | 発生しやすい | EARS形式で防止 |
+| 設計と実装の乖離 | 発生しやすい | トレーサビリティで検出 |
+| テスト漏れ | レビューで発見 | orphan検出で自動発見 |
+| コード品質 | レビュー依存 | 自動解析で保証 |
+| 知識の蓄積 | 属人化 | 知識グラフで共有 |
+
+### 23.3 学習のループ
+
+```mermaid
+flowchart LR
+    A[開発] --> B[フィードバック]
+    B --> C[パターン学習]
+    C --> D[次の開発に適用]
+    D --> A
+    
+    style A fill:#e3f2fd,stroke:#1976d2
+    style C fill:#fff3e0,stroke:#e65100
+    style D fill:#c8e6c9,stroke:#388e3c
+```
+
+MUSUBIXは単なるコード生成ツールではなく、**継続的に学習し進化するAI開発パートナー**です。
+
+---
+
+# 付録
+
+## 付録A: 9条憲法（Constitutional Articles）
+
+MUSUBIXのすべての開発活動を統治する不変のルールです。
+
+:::note info
+**ADR（Architecture Decision Record）とは？**
+アーキテクチャ上の意思決定を記録するドキュメントです。「なぜその技術を選んだのか」「他の選択肢は何があったのか」を残すことで、後から決定理由を追跡できます。第Ⅷ条はこの記録を義務付けています。
+:::
+
+| 条項 | 名称 | 概要 |
+|-----|------|------|
+| **I** | Library-First | 機能は独立ライブラリとして開始 |
+| **II** | CLI Interface | すべてのライブラリはCLI公開必須 |
+| **III** | Test-First | Red-Green-Blueサイクルでテスト先行 |
+| **IV** | EARS Format | 要件はEARS形式で記述 |
+| **V** | Traceability | 要件↔設計↔コード↔テストの100%追跡 |
+| **VI** | Project Memory | steering/を参照してから決定 |
+| **VII** | Design Patterns | 設計パターン適用の文書化 |
+| **VIII** | Decision Records | すべての決定をADRで記録 |
+| **IX** | Quality Gates | フェーズ移行前の品質検証 |
+
+---
+
+## 付録B: CLIコマンドリファレンス
+
+### プロジェクト管理
+```bash
+npx musubix init [path] [--name <name>] [--force]
+```
+
+### 要件分析
+```bash
+npx musubix requirements analyze <file>
+npx musubix requirements validate <file>
+npx musubix requirements map <file>
+npx musubix requirements search <query>
+```
+
+### 設計
+```bash
+npx musubix design generate <file>
+npx musubix design patterns <context>
+npx musubix design validate <file>
+npx musubix design c4 <file>
+npx musubix design adr <decision>
+```
+
+### コード生成
+```bash
+npx musubix codegen generate <file>
+npx musubix codegen analyze <file>
+npx musubix codegen security <path>
+```
+
+### テスト
+```bash
+npx musubix test generate <file>
+npx musubix test coverage <dir>
+```
+
+### トレーサビリティ
+```bash
+npx musubix trace matrix
+npx musubix trace impact <id>
+npx musubix trace validate
+```
+
+### 説明生成
+```bash
+npx musubix explain why <id>
+npx musubix explain graph <id>
+```
+
+### 自己学習
+```bash
+npx musubix learn status
+npx musubix learn patterns
+npx musubix learn feedback <id> --type <accept|reject|modify> -a <type>
+npx musubix learn add-pattern <name> -a <prefer|avoid|suggest> -c <category>
+npx musubix learn export -o <file>
+npx musubix learn import <file>
+```
+
+### オントロジー
+```bash
+npx musubix ontology validate -f <file>
+npx musubix ontology stats -f <file>
+npx musubix ontology check-circular -f <file>
+```
+
+### プログラム合成
+```bash
+npx musubix synthesize <examples.json> [-d <domain>] [--max-depth <n>]
+npx musubix syn <examples.json>
+```
+
+### パターンライブラリ
+```bash
+npx musubix library learn <file>
+npx musubix library query <query>
+npx musubix library stats
+```
+
+### KGPR
+```bash
+npx musubix kgpr create -t <title>
+npx musubix kgpr diff
+npx musubix kgpr list
+npx musubix kgpr submit <id>
+npx musubix kgpr show <id>
+```
+
+### その他
+```bash
+npx musubix repl                    # 対話モード
+npx musubix scaffold domain-model   # プロジェクト生成
+npx musubix --help                  # ヘルプ
+```
+
+---
+
+## 付録C: EARSパターン
+
+### 5つの基本パターン
+
+| パターン | 構文 | 用途 |
+|---------|------|------|
+| **Ubiquitous** | `THE [system] SHALL [requirement]` | 常時満たすべき要件 |
+| **Event-driven** | `WHEN [event], THE [system] SHALL [response]` | イベント発生時 |
+| **State-driven** | `WHILE [state], THE [system] SHALL [response]` | 特定状態 |
+| **Unwanted** | `THE [system] SHALL NOT [behavior]` | 禁止事項 |
+| **Optional** | `IF [condition], THEN THE [system] SHALL [response]` | 条件付き |
+
+### 経費精算システムでの例
+
+**Ubiquitous:**
+```
+THE Expense Management System SHALL allow authenticated users to create expense entries.
+```
+
+**Event-driven:**
+```
+WHEN an expense entry is submitted for approval, THE Expense Management System SHALL notify the next approver within 5 minutes.
+```
+
+**State-driven:**
+```
+WHILE an expense entry is pending approval for more than 7 days, THE Expense Management System SHALL send reminder notifications daily.
+```
+
+**Unwanted:**
+```
+THE Expense Management System SHALL NOT allow users to approve their own expense entries.
+```
+
+**Optional:**
+```
+IF an expense amount exceeds 100,000 JPY, THEN THE Expense Management System SHALL require Director level approval.
+```
+
+---
+
+## 付録D: プロジェクト構造
+
+### 標準ディレクトリ構成
+
+```mermaid
+flowchart TB
+    subgraph Root["project-root/"]
+        Config["musubix.config.json - MUSUBIX設定"]
+        
+        subgraph Steering["steering/"]
+            SR["rules/"]
+            SR --> SC["constitution.md - プロジェクト憲法"]
+        end
+        
+        subgraph Storage["storage/"]
+            SSp["specs/ - 要件（REQ-*）"]
+            SDe["design/ - 設計（DES-*）"]
+            STr["traceability/ - トレーサビリティマトリクス"]
+            SRe["reviews/ - レビュー結果"]
+            SFo["formal-verify/ - 形式検証ファイル"]
+        end
+        
+        subgraph Src["src/"]
+            subgraph Domain["domain/"]
+                DE["entities/ - エンティティ"]
+                DV["value-objects/ - Value Objects"]
+            end
+            subgraph App["application/"]
+                AS["services/ - アプリケーションサービス"]
+            end
+            Infra["infrastructure/ - インフラストラクチャ"]
+        end
+        
+        Tests["tests/ - テストファイル"]
+    end
+    
+    style Root fill:#f5f5f5,stroke:#333
+    style Steering fill:#e8f5e9,stroke:#2e7d32
+    style Storage fill:#e3f2fd,stroke:#1976d2
+    style Src fill:#fff3e0,stroke:#e65100
+```
+
+---
+
+## 付録E: musubix.config.json
+
+### 設定ファイル例
+
+```json:musubix.config.json
+{
+  "projectName": "expense-management-system",
+  "version": "1.0.0",
+  "sdd": {
+    "requirementsFormat": "EARS",
+    "designFormat": "C4",
+    "traceabilityEnabled": true
+  },
+  "learning": {
+    "enabled": true,
+    "feedbackRetention": 365,
+    "patternConfidenceThreshold": 0.7
+  },
+  "security": {
+    "scanEnabled": true,
+    "maxSeverity": "medium"
+  },
+  "formalVerification": {
+    "enabled": true,
+    "solver": "z3"
+  }
+}
+```
+
+---
+
+## 付録F: 設計パターン一覧
+
+本マニュアルで使用した設計パターン：
+
+| パターン | 用途 | 適用箇所 |
+|---------|------|---------|
+| **Repository** | データアクセスの抽象化 | ExpenseRepository |
+| **Service** | ビジネスロジックの集約 | ApprovalService |
+| **Factory** | オブジェクト生成の隠蔽 | createExpense(), createAmount() |
+| **Observer** | イベント通知 | 承認通知 |
+| **Strategy** | アルゴリズムの切り替え | 承認レベル決定 |
+| **State** | 状態遷移の管理 | ExpenseStatus |
+
+---
+
+## 付録G: トラブルシューティング
+
+### よくある問題と解決方法
+
+| 問題 | 原因 | 解決方法 |
+|------|------|---------|
+| `musubix: command not found` | 未インストール | `npm install -g @nahisaho/musubix-core` |
+| `No project found` | 初期化未実行 | `npx musubix init` |
+| `Invalid EARS format` | 構文エラー | パターン構文を確認 |
+| `Orphan requirement` | リンク未設定 | コードにトレースタグを追加 |
+| `Z3 not found` | Z3未インストール | `brew install z3` または `apt install z3` |
+
+---
+
+## 付録H: 用語集
+
+| 用語 | 説明 |
+|------|------|
+| **EARS** | Easy Approach to Requirements Syntax - 要件記述の標準形式 |
+| **C4モデル** | Context, Container, Component, Code の4レベル設計 |
+| **SDD** | Symbolic-Driven Development - 記号駆動開発 |
+| **YATA** | Yet Another Thinking Architecture - 知識グラフシステム |
+| **KGPR** | Knowledge Graph Pull Request - 知識グラフの変更管理 |
+| **Neuro-Symbolic** | ニューラルネットワークとシンボリック推論の統合 |
+| **Value Object** | 不変の値を表すオブジェクト |
+| **トレーサビリティ** | 要件から実装までの追跡可能性 |
+| **形式検証** | 数学的にプログラムの正しさを証明 |
+
+---
+
+## 付録I: 参考リンク
+
+- **MUSUBIX GitHub**: https://github.com/nahisaho/MUSUBIX
+- **EARS論文**: "Easy Approach to Requirements Syntax" by Alistair Mavin
+- **C4モデル**: https://c4model.com/
+- **Z3 Theorem Prover**: https://github.com/Z3Prover/z3
+
+---
+
+**Document Information**
+- **Version**: 2.2.0
+- **Date**: 2026-01-09
+- **Author**: MUSUBIX Team
+- **License**: MITMUSUBIXは単なるコード生成ツールではなく、**継続的に学習し進化するAI開発パートナー**です。