Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 09:06:31 +08:00
commit 17077288f6
10 changed files with 2354 additions and 0 deletions

View File

@@ -0,0 +1,146 @@
# 設計
## アーキテクチャ概要
*システムアーキテクチャの高レベルな概要を提供してください。*
```mermaid
graph TD
A[コンポーネントA] --> B[コンポーネントB]
B --> C[コンポーネントC]
A --> D[コンポーネントD]
```
## コンポーネント
### コンポーネント1: [名前]
**目的**: *このコンポーネントの役割*
**責務**:
- 責務1
- 責務2
**インターフェース**:
- API/メソッド1
- API/メソッド2
### コンポーネント2: [名前]
**目的**: *このコンポーネントの役割*
**責務**:
- 責務1
- 責務2
## データフロー
### シーケンス: [プロセス名]
```mermaid
sequenceDiagram
participant ユーザー
participant システム
participant データベース
ユーザー->>システム: リクエスト
システム->>データベース: クエリ
データベース-->>システム: レスポンス
システム-->>ユーザー: 結果
```
## API設計
### エンドポイント: [/api/resource]
**メソッド**: GET/POST/PUT/DELETE
**目的**: *このエンドポイントの機能*
**リクエスト**:
```json
{
"field1": "value1",
"field2": "value2"
}
```
**レスポンス**:
```json
{
"status": "success",
"data": {}
}
```
## データベーススキーマ
### テーブル: [table_name]
| カラム | 型 | 制約 | 説明 |
|--------|------|-------------|-------------|
| id | UUID | PRIMARY KEY | 一意識別子 |
| created_at | TIMESTAMP | NOT NULL | 作成日時 |
| updated_at | TIMESTAMP | NOT NULL | 更新日時 |
## 技術的決定事項
### 決定1: [技術/アプローチの選択]
**検討した選択肢**:
1. 選択肢A - メリット/デメリット
2. 選択肢B - メリット/デメリット
**決定**: 選択肢A
**根拠**: *この選択肢を選んだ理由*
## セキュリティ考慮事項
*セキュリティ対策と考慮事項を記述してください。*
## パフォーマンス考慮事項
*パフォーマンス最適化と考慮事項を記述してください。*
## エラー処理
*エラー処理戦略と復旧メカニズムを記述してください。*
---
## 設計書作成のガイド
### アーキテクチャ図の種類
- **コンポーネント図**: システムの主要な部品と関係性
- **シーケンス図**: 処理の流れと相互作用
- **データフロー図**: データの移動と変換
- **配置図**: 物理的な構成とネットワーク
### Mermaid図の基本構文
#### グラフ(フローチャート)
```mermaid
graph TD
A[開始] --> B{判定}
B -->|Yes| C[処理1]
B -->|No| D[処理2]
C --> E[終了]
D --> E
```
#### シーケンス図
```mermaid
sequenceDiagram
participant A as クライアント
participant B as サーバー
participant C as DB
A->>B: リクエスト送信
B->>C: データ取得
C-->>B: データ返却
B-->>A: レスポンス返却
```
### コンポーネント設計のポイント
1. **単一責任の原則**: 各コンポーネントは1つの明確な目的を持つ
2. **疎結合**: コンポーネント間の依存関係を最小限に
3. **高凝集**: 関連する機能を同じコンポーネントに
4. **インターフェース定義**: 明確な入出力を定義
### API設計のベストプラクティス
- RESTful原則に従う
- 適切なHTTPステータスコードを使用
- バージョニング戦略を定義
- エラーレスポンスの一貫性
- ペイロードの検証とサニタイゼーション
### データベース設計の考慮点
- 正規化と非正規化のバランス
- インデックス戦略
- トランザクション境界
- バックアップとリカバリ計画

View File

@@ -0,0 +1,67 @@
# 要件定義
## 概要
*この機能/システムの高レベルな目的と目標を記述してください。*
## ユーザーストーリー
### ストーリー1: [ユーザーストーリーのタイトル]
**私は** [ユーザーの種類]として
**〜したい** [目標/要望]
**なぜなら** [利益/価値]
#### 受入基準EARS記法
- **REQ-001**: [条件/トリガー]の時、システムは[期待される振る舞い]しなければならない
- **REQ-002**: もし[前提条件]ならば、システムは[期待される振る舞い]しなければならない
- **REQ-003**: [継続条件]の間、システムは[期待される振る舞い]しなければならない
- **REQ-004**: [場所/コンテキスト]において、システムは[期待される振る舞い]しなければならない
### ストーリー2: [ユーザーストーリーのタイトル]
**私は** [ユーザーの種類]として
**〜したい** [目標/要望]
**なぜなら** [利益/価値]
#### 受入基準EARS記法
- **REQ-005**: [条件/トリガー]の時、システムは[期待される振る舞い]しなければならない
## 非機能要件
### 性能要件
- **NFR-001**: システムは[性能要件]を満たさなければならない
### セキュリティ要件
- **NFR-002**: システムは[セキュリティ要件]を満たさなければならない
### ユーザビリティ要件
- **NFR-003**: システムは[ユーザビリティ要件]を満たさなければならない
## 依存関係
*外部依存関係や前提条件をリストアップしてください。*
## スコープ外
*この仕様に含まれないものを明示的にリストアップしてください。*
---
## EARS記法の書き方ガイド
### 基本パターン
- **基本形**: システムは[振る舞い]しなければならない
- **イベント駆動**: [イベント]の時、システムは[振る舞い]しなければならない
- **条件付き**: もし[条件]ならば、システムは[振る舞い]しなければならない
- **継続的**: [状態]の間、システムは[振る舞い]しなければならない
- **場所/コンテキスト**: [場所]において、システムは[振る舞い]しなければならない
### 良い要件の例
- REQ-001: ユーザーがログインボタンをクリックした時、システムは2秒以内に認証処理を完了しなければならない
- REQ-002: もしパスワードが間違っている場合、システムはエラーメッセージを表示しなければならない
- REQ-003: ファイルアップロード中、システムは進捗状況を表示しなければならない
- REQ-004: モバイル環境において、システムはレスポンシブデザインで表示しなければならない
- NFR-001: システムは同時に1000人のユーザーアクセスを処理できなければならない
### 避けるべき表現
- 「〜すべきである」「〜することが望ましい」→ 「〜しなければならない」を使用
- 曖昧な表現(「速く」「使いやすく」)→ 具体的な数値や基準を使用
- 複合要件(複数の「しなければならない」)→ 個別の要件に分割

View File

@@ -0,0 +1,185 @@
# タスク
> このドキュメントはAIエージェントClaude Code等が実装を行うことを前提としています。
> タスクは具体的なファイルパス、技術仕様、検証可能な受入基準を含めて記載してください。
## 実装計画
### フェーズ1: 基盤構築
*推定期間: X分AIエージェント作業時間*
#### タスク1.1: [タスクタイトル]
**説明**:
*AIエージェントが実装すべき内容を具体的に記載*
- 対象ファイルパス
- 実装する機能の詳細
- 使用する技術・ライブラリ
**技術的文脈**:
*AIエージェントの判断に必要な情報*
- 技術スタック
- 参照すべき既存コード
- コーディング規約
**受入基準**:
- [ ] *検証可能な基準(ファイル存在、機能動作、テスト通過など)*
- [ ] *検証可能な基準*
**依存関係**: なし
**推定工数**: X分AIエージェント作業時間
**ステータス**: `TODO`
#### タスク1.2: [タスクタイトル]
**説明**:
*AIエージェントが実装すべき内容を具体的に記載*
- 対象ファイルパス
- 実装する機能の詳細
- 使用する技術・ライブラリ
**技術的文脈**:
*AIエージェントの判断に必要な情報*
**受入基準**:
- [ ] *検証可能な基準*
- [ ] *検証可能な基準*
**依存関係**: タスク1.1
**推定工数**: X分AIエージェント作業時間
**ステータス**: `TODO`
### フェーズ2: コア機能
*推定期間: X分AIエージェント作業時間*
#### タスク2.1: [タスクタイトル]
**説明**:
*AIエージェントが実装すべき内容を具体的に記載*
**技術的文脈**:
*AIエージェントの判断に必要な情報*
**受入基準**:
- [ ] *検証可能な基準*
- [ ] *検証可能な基準*
**依存関係**: フェーズ1
**推定工数**: X分AIエージェント作業時間
**ステータス**: `TODO`
#### タスク2.2: [タスクタイトル]
**説明**:
*AIエージェントが実装すべき内容を具体的に記載*
**技術的文脈**:
*AIエージェントの判断に必要な情報*
**受入基準**:
- [ ] *検証可能な基準*
- [ ] *検証可能な基準*
**依存関係**: タスク2.1
**推定工数**: X分AIエージェント作業時間
**ステータス**: `TODO`
### フェーズ3: 統合とテスト
*推定期間: X分AIエージェント作業時間*
#### タスク3.1: [タスクタイトル]
**説明**:
*AIエージェントが実装すべき内容を具体的に記載*
**技術的文脈**:
*AIエージェントの判断に必要な情報*
**受入基準**:
- [ ] *検証可能な基準*
- [ ] *検証可能な基準*
**依存関係**: フェーズ2
**推定工数**: X分AIエージェント作業時間
**ステータス**: `TODO`
## タスクステータスの凡例
- `TODO` - 未着手
- `IN_PROGRESS` - 作業中
- `BLOCKED` - 依存関係や問題によりブロック中
- `REVIEW` - レビュー待ち
- `DONE` - 完了
## リスクと軽減策
### リスク1: [リスクの説明]
**影響度**: 高/中/低
**発生確率**: 高/中/低
**軽減策**: *このリスクへの対処方法*
### リスク2: [リスクの説明]
**影響度**: 高/中/低
**発生確率**: 高/中/低
**軽減策**: *このリスクへの対処方法*
## 備考
*実装に関する追加の注意事項や考慮事項*
---
## タスク管理のガイド
### AIエージェント向けタスクの粒度
適切なタスクサイズの目安AIエージェント作業時間
- **シンプルな実装**: 10-20分単一ファイル、基本的な関数、設定ファイル
- **標準的な実装**: 20-40分複数ファイル、APIエンドポイント、データモデル、基本テスト
- **複雑な実装**: 40-90分複数コンポーネント統合、複雑なロジック、包括的テスト
- **非常に複雑**: 90分以上 → さらに分解を検討
### AIエージェント向け良いタスク定義の特徴
1. **具体的**: ファイルパス、関数名、クラス名を明記
2. **測定可能**: 検証可能な受入基準(テスト通過、ファイル存在など)
3. **達成可能**: AIエージェントが実行可能な粒度
4. **文脈提供**: 技術スタック、参照コード、コーディング規約を明記
5. **期限付き**: AIエージェント作業時間の見積もりを明記
### AIエージェント向け受入基準の書き方
- チェックボックス形式で記載
- AIエージェントが検証可能な基準ファイル存在、テスト通過、エラーゼロなど
- 具体的なファイルパスやコマンドを含める
- 技術的に測定可能な条件を明記
### 依存関係の管理
- **前提タスク**: このタスクの開始前に完了が必要
- **並行可能**: 同時に進められるタスク
- **後続タスク**: このタスクの完了後に開始可能
### ステータス遷移のルール
```
TODO → IN_PROGRESS → REVIEW → DONE
BLOCKED
IN_PROGRESS
```
### フェーズ分けの考え方
1. **基盤構築**: 環境設定、基本構造
2. **コア機能**: 主要な機能の実装
3. **拡張機能**: 追加機能、改善
4. **統合・テスト**: 結合、品質保証
5. **リリース準備**: デプロイ、文書化
### リスク評価のマトリクス
| | 低影響 | 中影響 | 高影響 |
|---|--------|--------|--------|
| **高確率** | 注意 | 対策必要 | 最優先対応 |
| **中確率** | 監視 | 注意 | 対策必要 |
| **低確率** | 受容 | 監視 | 注意 |
### AIエージェント作業時間の見積もり
- 基本的な実装: 楽観的見積もり × 1.2-1.5
- 不確実性が高い場合: × 1.5-2.0
- 新しいライブラリや複雑な統合: × 2.0-2.5
- AIエージェントの能力範囲内のタスクに限定すること
### 進捗管理のヒント
- 毎日ステータスを更新
- ブロッカーは即座に報告
- 見積もりと実績の差を記録
- 振り返りで改善点を特定