Kiro、便利ですねー！
AWS（というかAmazonなのかな？）が本気出してきたなーという感じで、「仕様書駆動開発」を謳っており、まずは設計文書を作成し、タスクを整理してから、実装を始める、といったより実際の開発工程に近いフローでLLMに開発させることができます。
何よりロゴが可愛すぎる。
さっそく利用者がたくさんおり、いろんな記事が出ていますが、最初にこんな記事を目にしました。
Claude Codeとの棲み分けなどについても記載されており、大変ありがたなーと思って読ませていただいたんですが、「デメリット」の項目に記載されていたところがやっぱり気になりました。
どうせ、いづれ利用可能になるわけですが、2025/07現在ではClaude Sonnet 3.7 or 4.0しか利用できず、Opus 4.0は利用できません。
なので、仕様書などを作成させても、結局はClaude Codeで実装させるーという方がちょこちょこいました。
が！！！！！
であれば最初からClaude Codeに作業させてもいいんじゃね？？？と思いました。
ちょっと前にこんな記事も書いており、そもそも元から設計やタスク分割をClaude Codeにやらせていたので、Kiroの作成する文章を真似たりして、カスタムコマンドやCLAUDE.mdなどに設定しておけば、他のツールを利用せずに開発を完結させれそうな気もします。
ということで、簡単なツールを作りながら設定ファイルなどを紹介します！
今回は実装はせず、あくまで事前設計の手順を紹介したいと思います！
（Claude Codeに実装力があるのはみなさんご存知だと思うので！）
設定ファイル
まずは、自作した（LLMに作らせた）ファイル群をざっと載せます！
英語の方が精度が良いとかよく聞くし実際そうだと思うので、設定ファイルは大体英語で書いていきます！
~/.claude/CLAUDE.md
# Guidelines
This document defines the project's rules, objectives, and progress management methods. Please proceed with the project according to the following content.
## Top-Level Rules
- To maximize efficiency, **if you need to execute multiple independent processes, invoke those tools concurrently, not sequentially**.
- **You must think exclusively in English**. However, you are required to **respond in Japanese**.
- To understand how to use a library, **always use the Contex7 MCP** to retrieve the latest information.
- For temporary notes for design, create a markdown in `.tmp` and save it.
- **After using Write or Edit tools, ALWAYS verify the actual file contents using the Read tool**, regardless of what the system-reminder says. The system-reminder may incorrectly show "(no content)" even when the file has been successfully written.
- Please respond critically and without pandering to my opinions, but please don't be forceful in your criticism.
## Programming Rules
- Avoid hard-coding values unless absolutely necessary.
- Do not use `any` or `unknown` types in TypeScript.
- You must not use a TypeScript `class` unless it is absolutely necessary (e.g., extending the `Error` class for custom error handling that requires `instanceof` checks).
## Development Style - Specification-Driven Development
### Overview
When receiving development tasks, please follow the 4-stage workflow below. This ensures requirement clarification, structured design, and efficient implementation.
### 4-Stage Workflow
#### Stage 1: Requirements
- Analyze user requests and convert them into clear functional requirements
- Document requirements in `.tmp/requirements.md`
- Use `/requirements` command for detailed template
#### Stage 2: Design
- Create technical design based on requirements
- Document design in `.tmp/design.md`
- Use `/design` command for detailed template
#### Stage 3: Task List
- Break down design into implementable units
- Document in `.tmp/tasks.md`
- Use `/tasks` command for detailed template
- Manage major tasks with TodoWrite tool
#### Stage 4: Implementation
- Implement according to task list
- For each task:
- Update task to in_progress using TodoWrite
- Execute implementation and testing
- Run lint and typecheck
- Update task to completed using TodoWrite
### Workflow Commands
- `/spec` - Start the complete specification-driven development workflow
- `/requirements` - Execute Stage 1: Requirements only
- `/design` - Execute Stage 2: Design only (requires requirements)
- `/tasks` - Execute Stage 3: Task breakdown only (requires design)
### Important Notes
- Each stage depends on the deliverables of the previous stage
- Please obtain user confirmation before proceeding to the next stage
- Always use this workflow for complex tasks or new feature development
- Simple fixes or clear bug fixes can be implemented directly
今回特に重要なのは## Development Style - Specification-Driven Development以降の項目です。
専用のカスタムコマンドを4つ作成し、ステップを追って実行していきます。
どれか一つの工程だけ実行しても良いですし、/specコマンドでまとめて実行しても良いです！
作成されたドキュメントは、基本的にはリポジトリルートの.tmpフォルダに格納していく想定です。
それぞれの工程はこのような指示を出していきます。
~/.claude/commands/requirements.md
---
allowed-tools: TodoWrite, TodoRead, Read, Write, MultiEdit, Bash(mkdir:*)
description: Create requirements specification for the given task (Stage 1 of Spec-Driven Development)
---
## Context
- Task description: $ARGUMENTS
## Your task
### 1. Create directory
- Create `.tmp` directory if it doesn't exist
### 2. Analyze the user's request
Carefully analyze the provided task description and extract:
- The core problem to be solved
- Implicit requirements not explicitly stated
- Potential edge cases and constraints
- Success criteria
### 3. Create Requirements Document
Create `.tmp/requirements.md` with the following sections:
```markdown
# 要件定義書 - [タスク名]
## 1. 目的
[このタスク/プロジェクトの目的を明確に記述]
## 2. 機能要件
### 2.1 必須機能
- [ ] [機能1の詳細説明]
- [ ] [機能2の詳細説明]
...
### 2.2 オプション機能
- [ ] [将来的に実装可能な機能]
...
## 3. 非機能要件
### 3.1 パフォーマンス
- [応答時間、処理速度などの要件]
### 3.2 セキュリティ
- [セキュリティに関する要件]
### 3.3 保守性
- [コードの保守性に関する要件]
### 3.4 互換性
- [既存システムとの互換性要件]
## 4. 制約事項
### 4.1 技術的制約
- [使用技術、ライブラリの制約]
### 4.2 ビジネス制約
- [納期、予算などの制約]
## 5. 成功基準
### 5.1 完了の定義
- [ ] [明確な完了条件1]
- [ ] [明確な完了条件2]
...
### 5.2 受け入れテスト
- [ユーザーが満足する条件]
## 6. 想定されるリスク
- [実装上のリスクと対策]
## 7. 今後の検討事項
- [設計フェーズで詳細化すべき事項]
```
### 4. Create TODO entry
Use TodoWrite to add "要件定義の完了とレビュー" as a task
### 5. Present to user
Show the created requirements document and ask for:
- Confirmation of understanding
- Any missing requirements
- Approval to proceed to design phase
## Important Notes
- Be thorough in identifying implicit requirements
- Consider both current needs and future extensibility
- Use clear, unambiguous language
- Include measurable success criteria
think hard
小さいツールを作るのであれば、保守性やセキュリティなどの非機能要件はむしろノイズになってしまうかもしれないので、生成されたrequirements.md確認し、不要であれば修正・削除してしまいましょう！
生成された文章を整理したら、次は設計を行います。
~/.claude/commands/design.md
---
allowed-tools: TodoWrite, TodoRead, Read, Write, MultiEdit
description: Create detailed design specification based on requirements (Stage 2 of Spec-Driven Development)
---
## Context
- Requirements document: @.tmp/requirements.md
## Your task
### 1. Verify prerequisites
- Check that `.tmp/requirements.md` exists
- If not, inform user to run `/requirements` first
### 2. Analyze requirements
Read and understand the requirements document thoroughly
### 3. Create Design Document
Create `.tmp/design.md` with the following sections:
````markdown
# 詳細設計書 - [タスク名]
## 1. アーキテクチャ概要
### 1.1 システム構成図
[ASCII図やMermaid図でシステム全体の構成を表現]
### 1.2 技術スタック
- 言語: [使用言語とバージョン]
- フレームワーク: [使用フレームワーク]
- ライブラリ: [主要ライブラリ一覧]
- ツール: [ビルドツール、テストツールなど]
## 2. コンポーネント設計
### 2.1 コンポーネント一覧
| コンポーネント名 | 責務 | 依存関係 |
| ---------------- | ------------ | ------------------------ |
| [Component A] | [責務の説明] | [依存するコンポーネント] |
### 2.2 各コンポーネントの詳細
#### [Component A]
- **目的**: [このコンポーネントの目的]
- **公開インターフェース**:
```typescript
interface ComponentA {
method1(param: Type): ReturnType;
}
```
````
- **内部実装方針**: [実装のアプローチ]
## 3. データフロー
### 3.1 データフロー図
[データの流れを示す図]
### 3.2 データ変換
- 入力データ形式: [形式の説明]
- 処理過程: [変換ロジック]
- 出力データ形式: [形式の説明]
## 4. APIインターフェース
### 4.1 内部API
[モジュール間のインターフェース定義]
### 4.2 外部API
[外部システムとの連携インターフェース]
## 5. エラーハンドリング
### 5.1 エラー分類
- [エラータイプ1]: [対処方法]
- [エラータイプ2]: [対処方法]
### 5.2 エラー通知
[エラーの通知方法とログ戦略]
## 6. セキュリティ設計
### 6.1 認証・認可
[必要に応じて記載]
### 6.2 データ保護
[機密データの扱い方]
## 7. テスト戦略
### 7.1 単体テスト
- カバレッジ目標: [%]
- テストフレームワーク: [使用ツール]
### 7.2 統合テスト
[統合テストのアプローチ]
## 8. パフォーマンス最適化
### 8.1 想定される負荷
[パフォーマンス要件]
### 8.2 最適化方針
[最適化のアプローチ]
## 9. デプロイメント
### 9.1 デプロイ構成
[本番環境へのデプロイ方法]
### 9.2 設定管理
[環境変数、設定ファイルの管理]
## 10. 実装上の注意事項
- [注意点1]
- [注意点2]
```
### 4. Update TODO
Use TodoWrite to add "詳細設計の完了とレビュー" as a task
### 5. Present to user
Show the created design document and ask for:
- Technical feedback
- Architecture approval
- Permission to proceed to task breakdown
## Important Notes
- Design should be implementable and testable
- Consider maintainability and extensibility
- Include concrete interface definitions where possible
- Address all requirements from the requirements document
```
think hard
要求事項文章と同様に、確認・修正しましょう。
最後に、タスク分割します。
~/.claude/commands/tasks.md
---
allowed-tools: TodoWrite, TodoRead, Read, Write, MultiEdit
description: Break down design into implementable tasks (Stage 3 of Spec-Driven Development)
---
## Context
- Requirements: @.tmp/requirements.md
- Design document: @.tmp/design.md
## Your task
### 1. Verify prerequisites
- Check that both `.tmp/requirements.md` and `.tmp/design.md` exist
- If not, inform user to complete previous stages first
### 2. Analyze design document
Read and understand the design thoroughly to identify all implementation tasks
### 3. Create Task List Document
Create `.tmp/tasks.md` with the following structure:
```markdown
# タスクリスト - [機能/改善名]
## 概要
- 総タスク数: [数]
- 推定作業時間: [時間/日数]
- 優先度: [高/中/低]
## タスク一覧
### Phase 1: 準備・調査
#### Task 1.1: [タスク名]
- [ ] [具体的な作業項目1]
- [ ] [具体的な作業項目2]
- [ ] [具体的な作業項目3]
- **完了条件**: [明確な完了条件]
- **依存**: [依存するタスク または なし]
- **推定時間**: [時間]
#### Task 1.2: [タスク名]
- [ ] [具体的な作業項目1]
- [ ] [具体的な作業項目2]
- **完了条件**: [明確な完了条件]
- **依存**: [依存するタスク]
- **推定時間**: [時間]
### Phase 2: 実装
#### Task 2.1: [機能名]の実装
- [ ] [実装項目1]
- [ ] [実装項目2]
- [ ] [実装項目3]
- **完了条件**: [明確な完了条件]
- **依存**: [依存するタスク]
- **推定時間**: [時間]
#### Task 2.2: [機能名]の実装
- [ ] [実装項目1]
- [ ] [実装項目2]
- **完了条件**: [明確な完了条件]
- **依存**: [依存するタスク]
- **推定時間**: [時間]
### Phase 3: 検証・テスト
#### Task 3.1: [検証項目]
- [ ] [テスト項目1]
- [ ] [テスト項目2]
- [ ] [テスト項目3]
- **完了条件**: [明確な完了条件]
- **依存**: [依存するタスク]
- **推定時間**: [時間]
### Phase 4: 仕上げ
#### Task 4.1: [仕上げ項目]
- [ ] [仕上げ作業1]
- [ ] [仕上げ作業2]
- **完了条件**: [明確な完了条件]
- **依存**: [依存するタスク]
- **推定時間**: [時間]
## 実装順序
1. Phase 1から順次実行
2. 並行実行可能なタスクは並行で実行
3. 依存関係を考慮した実装順序
## リスクと対策
- [特定されたリスク]: [対策方法]
## 注意事項
- 各タスクはコミット単位で完結させる
- タスク完了時は必要に応じて品質チェックを実行
- 不明点は実装前に確認する
```
### 4. Register tasks in TodoWrite
Extract main tasks (Phase level or important tasks) and register them using TodoWrite tool with appropriate priorities
### 5. Create implementation guide
Add a section at the end of tasks.md:
```markdown
## 実装開始ガイド
1. このタスクリストに従って順次実装を進めてください
2. 各タスクの開始時にTodoWriteでin_progressに更新
3. 完了時はcompletedに更新
4. 問題発生時は速やかに報告してください
```
### 6. Present to user
Show the task breakdown and:
- Explain the implementation order
- Highlight any critical paths
- Ask for approval to begin implementation
## Important Notes
- Tasks should be commit-sized (completable in 1-4 hours)
- Include clear completion criteria for each task
- Consider parallel execution opportunities
- Include testing tasks throughout, not just at the end
think hard
これらを全部まとめて行う場合、こんなコマンドも用意しておきます。
~/.claude/commands/spec.md
---
allowed-tools: TodoWrite, TodoRead, Read, Write, MultiEdit, Bash(mkdir:*)
description: Start Specification-Driven Development workflow for the given task
---
## Context
- Task requirements: $ARGUMENTS
## Your task
Execute the complete Specification-Driven Development workflow:
### 1. Setup
- Create `.tmp` directory if it doesn't exist
- Create a new feature branch based on the task
### 2. Stage 1: Requirements
Execute `/requirements` command to create detailed requirements specification.
**Present requirements to user for approval before proceeding**
### 3. Stage 2: Design
Execute `/design` command to create technical design based on requirements.
**Present design to user for approval before proceeding**
### 4. Stage 3: Task List
Execute `/tasks` command to break down design into implementable tasks.
**Present task list to user for approval before proceeding**
### 5. Report completion
Summarize what was created and inform user that they can now proceed with implementation using the generated specification documents.
## Important Notes
- Each stage output should be detailed and actionable
- Wait for user confirmation between stages
- Focus on clarity and completeness in documentation
- Consider edge cases and error scenarios in each stage
think hard
ツール作成の仕様書を作ってみる
結構実務寄りのコマンド構成になっているため、小さいツールを作ってもあまり効力を発揮しない（というか無駄そう）ですが、実際に使ってみましょう！
mkdir super-todo
cd super-todo
claude
例えばこんな感じ…
> /requirements ブラウザで動作する超かっこいいtodoアプリを作って。
めちゃめちゃ考えていますねー。
こんな雑な指示は人間には出せない…
✻ Thinking…
ユーザーは「ブラウザで動作する超かっこいいtodoアプリを作って」というタスクを与えてくれました。そして、/requirements
コマンドを実行して要件定義書を作成するよう求められています。
まず、以下の手順を実行する必要があります：
1. .tmp ディレクトリを作成（存在しない場合）
2. ユーザーのリクエストを分析
3. 要件定義書を作成（.tmp/requirements.md）
4. TodoWrite を使用してタスクを追加
5. ユーザーに提示して確認を求める
現在のワーキングディレクトリを確認し、.tmp ディレクトリが存在するかチェックしてから、要件定義書を作成します。
ユーザーの要求を分析すると：
- ブラウザで動作するTodoアプリ
- 「超かっこいい」というのはUI/UXに重点を置いたデザイン要求
- 基本的なTodo機能（追加、編集、削除、完了管理）
- モダンな技術スタックの使用が想定される
要件定義書を作成しましょう。
このようなファイルが出力されました！
すごい真面目！
.tmp/requirements.md
# 要件定義書 - ブラウザ対応超かっこいいTodoアプリ
## 1. 目的
ブラウザで動作する視覚的に魅力的で機能的なTodoアプリケーションを開発し、ユーザーがタスク管理を効率的かつ楽しく行えるようにする。
## 2. 機能要件
### 2.1 必須機能
- [ ] **タスク追加機能**: 新しいタスクをテキスト入力で追加できる
- [ ] **タスク表示機能**: 追加されたタスクを一覧表示できる
- [ ] **タスク完了機能**: タスクの完了状態をトグルで切り替えできる
- [ ] **タスク編集機能**: 既存のタスクをインライン編集できる
- [ ] **タスク削除機能**: 不要なタスクを削除できる
- [ ] **タスクフィルタリング**: 全て/未完了/完了済みでフィルタリングできる
- [ ] **データ永続化**: ブラウザのローカルストレージに保存される
- [ ] **レスポンシブデザイン**: スマートフォン、タブレット、デスクトップに対応
- [ ] **アニメーション効果**: タスクの追加、削除、完了時のスムーズなアニメーション
### 2.2 オプション機能
- [ ] **優先度設定**: タスクに優先度（高・中・低）を設定できる
- [ ] **期限設定**: タスクに期限を設定できる
- [ ] **カテゴリー分類**: タスクをカテゴリー別に分類できる
- [ ] **検索機能**: タスクをキーワード検索できる
- [ ] **一括操作**: 複数タスクの一括完了/削除
- [ ] **統計表示**: 完了率やタスク数の統計表示
- [ ] **テーマ切り替え**: ダークモード/ライトモード切り替え
- [ ] **タスク並び替え**: ドラッグ&ドロップでタスクの順序変更
## 3. 非機能要件
### 3.1 パフォーマンス
- 初回ロード時間: 2秒以内
- タスク操作の応答時間: 100ms以内
- 1000件のタスクまでスムーズに動作
### 3.2 セキュリティ
- XSS攻撃対策: ユーザー入力の適切なサニタイズ
- CSP（Content Security Policy）の実装
- 機密データの暗号化は不要（ローカル保存のため）
### 3.3 保守性
- モジュール化されたコード構造
- TypeScript使用による型安全性
- 包括的なテストカバレッジ（80%以上）
- リンターとフォーマッターの導入
### 3.4 互換性
- モダンブラウザ対応: Chrome 90+、Firefox 90+、Safari 14+、Edge 90+
- ES2020+の機能使用可能
- Progressive Web App（PWA）対応
## 4. 制約事項
### 4.1 技術的制約
- フロントエンドのみ（サーバーサイドは不要）
- 外部APIへの依存は最小限に抑制
- バンドルサイズ: 500KB以内
- アクセシビリティ: WCAG 2.1 AAレベル準拠
### 4.2 ビジネス制約
- オープンソース開発
- 無料で利用可能
- 商用利用可能なライセンス
## 5. 成功基準
### 5.1 完了の定義
- [ ] すべての必須機能が実装され、動作確認済み
- [ ] レスポンシブデザインが実装され、主要デバイスで動作確認済み
- [ ] パフォーマンス要件を満たしている
- [ ] ユーザビリティテストで高い評価を得ている
- [ ] コードレビューを通過している
- [ ] 本番環境へのデプロイが完了している
### 5.2 受け入れテスト
- 初心者でも直感的に使用できる
- 視覚的に魅力的で「超かっこいい」と評価される
- 日常的なタスク管理に実用的である
- 異なるデバイス間で一貫した体験を提供
## 6. 想定されるリスク
- **技術的リスク**:
- ブラウザ間の互換性問題
- パフォーマンスの劣化
- 対策: 主要ブラウザでの継続的なテスト、パフォーマンス監視
- **UX/UIリスク**:
- ユーザーの期待に応えられない可能性
- 対策: プロトタイピングとユーザーフィードバックの収集
- **データ喪失リスク**:
- ローカルストレージの制限や削除
- 対策: データのエクスポート/インポート機能の実装
## 7. 今後の検討事項
- 使用する技術スタック（React、Vue、Vanilla JS等）の選定
- デザインシステムとカラーパレットの決定
- アニメーションライブラリの選定
- PWA機能の詳細仕様
- 国際化（i18n）対応の必要性
- データ同期機能の将来的な実装可能性
さらに、Claude Code上ではこのように聞き返してくれます。
⏺ 要件定義書を作成しました
「ブラウザで動作する超かっこいいTodoアプリ」の要件定義書を .tmp/requirements.md に作成しました。
主な要件のポイント：
必須機能（9項目）
- 基本的なTodo操作（追加、表示、完了、編集、削除）
- フィルタリング、データ永続化、レスポンシブデザイン
- スムーズなアニメーション効果
オプション機能（8項目）
- 優先度設定、期限設定、カテゴリー分類
- 検索、一括操作、統計表示、テーマ切り替え、並び替え
非機能要件
- パフォーマンス：初回ロード2秒以内、操作応答100ms以内
- TypeScript使用、テストカバレッジ80%以上
- モダンブラウザ対応、PWA対応
確認事項：
1. 技術スタック：React、Vue、Vanilla JSのいずれを希望しますか？
2. 優先度：オプション機能で特に重要視するものはありますか？
3. デザイン：「超かっこいい」のイメージ（モダン、ミニマル、カラフル等）はありますか？
4. 追加・修正：要件に過不足はありませんか？
この要件定義で問題なければ、次の設計フェーズに進みます。いかがでしょうか？
今回はこれで問題ないので、このまま進んでもらいます。
> 設計フェーズに進んで。
CLAUDE.mdに作業の手順を記載しているので、このままスムーズに設計も行ってくれます。
.tmp/design.md
# 技術設計書 - ブラウザ対応超かっこいいTodoアプリ
## 1. 技術スタック
### 1.1 コア技術
- **フレームワーク**: React 18+ (Hooks、Suspense対応)
- **言語**: TypeScript 5.0+
- **ビルドツール**: Vite 4.0+
- **パッケージマネージャー**: npm
### 1.2 UI/UX
- **スタイリング**: Tailwind CSS 3.0+
- **アニメーション**: Framer Motion 10.0+
- **アイコン**: Lucide React
- **フォント**: Inter (Google Fonts)
### 1.3 状態管理・データ
- **状態管理**: Zustand
- **データ永続化**: localStorage API
- **バリデーション**: Zod
### 1.4 開発・テスト
- **テスト**: Vitest + React Testing Library
- **リンター**: ESLint + Prettier
- **型チェック**: TypeScript
## 2. アーキテクチャ設計
### 2.1 プロジェクト構成
```
src/
├── components/ # UIコンポーネント
│ ├── ui/ # 基本UIコンポーネント
│ ├── todo/ # Todo関連コンポーネント
│ └── layout/ # レイアウトコンポーネント
├── hooks/ # カスタムフック
├── stores/ # Zustand ストア
├── types/ # TypeScript型定義
├── utils/ # ユーティリティ関数
├── styles/ # グローバルスタイル
└── constants/ # 定数定義
```
### 2.2 コンポーネント設計
#### 2.2.1 コンポーネント階層
```
App
├── Header
│ ├── Logo
│ └── ThemeToggle
├── TodoContainer
│ ├── TodoInput
│ ├── TodoFilters
│ ├── TodoList
│ │ └── TodoItem
│ │ ├── TodoCheckbox
│ │ ├── TodoText
│ │ ├── TodoEditForm
│ │ └── TodoActions
│ └── TodoStats
└── Footer
```
#### 2.2.2 主要コンポーネント仕様
**TodoItem**
- Props: `todo`, `onToggle`, `onEdit`, `onDelete`
- State: `isEditing`, `editText`
- 機能: 完了状態切り替え、インライン編集、削除
**TodoInput**
- Props: `onAdd`
- State: `inputText`, `isSubmitting`
- 機能: 新規タスク追加、バリデーション
**TodoFilters**
- Props: `currentFilter`, `onFilterChange`
- 機能: フィルタ状態管理（all/active/completed）
### 2.3 状態管理設計
#### 2.3.1 Todo Store (Zustand)
```typescript
interface TodoState {
todos: Todo[]
filter: FilterType
theme: ThemeType
// Actions
addTodo: (text: string) => void
toggleTodo: (id: string) => void
editTodo: (id: string, text: string) => void
deleteTodo: (id: string) => void
setFilter: (filter: FilterType) => void
toggleTheme: () => void
clearCompleted: () => void
}
```
#### 2.3.2 データ型定義
```typescript
interface Todo {
id: string
text: string
completed: boolean
createdAt: Date
updatedAt: Date
}
type FilterType = 'all' | 'active' | 'completed'
type ThemeType = 'light' | 'dark'
```
## 3. UI/UX設計
### 3.1 デザインシステム
#### 3.1.1 カラーパレット
```css
:root {
/* Light Theme */
--bg-primary: #ffffff
--bg-secondary: #f8fafc
--text-primary: #1e293b
--text-secondary: #64748b
--accent: #3b82f6
--accent-hover: #2563eb
--success: #10b981
--danger: #ef4444
/* Dark Theme */
--bg-primary-dark: #0f172a
--bg-secondary-dark: #1e293b
--text-primary-dark: #f1f5f9
--text-secondary-dark: #94a3b8
}
```
#### 3.1.2 タイポグラフィ
- **見出し**: font-size: 2rem, font-weight: 700
- **本文**: font-size: 1rem, font-weight: 400
- **小文字**: font-size: 0.875rem, font-weight: 400
#### 3.1.3 スペーシング
- **基本単位**: 0.25rem (4px)
- **コンポーネント間**: 1rem (16px)
- **セクション間**: 2rem (32px)
### 3.2 アニメーション設計
#### 3.2.1 アニメーション仕様
- **追加アニメーション**: fadeIn + slideDown (300ms)
- **削除アニメーション**: fadeOut + slideUp (200ms)
- **完了アニメーション**: scaleIn + colorChange (150ms)
- **ホバー効果**: scale(1.02) + shadow (100ms)
#### 3.2.2 Framer Motion バリアント
```typescript
const todoVariants = {
hidden: { opacity: 0, y: -20 },
visible: { opacity: 1, y: 0 },
exit: { opacity: 0, x: -100 }
}
```
### 3.3 レスポンシブデザイン
#### 3.3.1 ブレークポイント
- **Mobile**: < 768px
- **Tablet**: 768px - 1024px
- **Desktop**: > 1024px
#### 3.3.2 レイアウト調整
- **Mobile**: 単一カラム、フルスクリーン
- **Tablet**: 中央寄せ、max-width: 640px
- **Desktop**: 中央寄せ、max-width: 768px
## 4. データ永続化設計
### 4.1 localStorage スキーマ
```typescript
interface StorageSchema {
todos: Todo[]
settings: {
theme: ThemeType
filter: FilterType
}
version: string
}
```
### 4.2 データマイグレーション
- バージョン管理による段階的アップデート
- 後方互換性の保持
- データ破損時の復旧機能
## 5. パフォーマンス最適化
### 5.1 React最適化
- `React.memo` によるコンポーネントメモ化
- `useMemo` / `useCallback` による計算結果キャッシュ
- `React.lazy` による動的インポート
### 5.2 バンドル最適化
- Tree Shaking の活用
- Code Splitting の実装
- 不要な依存関係の削除
### 5.3 アニメーション最適化
- GPU加速の活用 (transform, opacity)
- `will-change` プロパティの適切な使用
- 60fps維持のための最適化
## 6. アクセシビリティ設計
### 6.1 ARIA属性
- `role` 属性の適切な設定
- `aria-label` によるスクリーンリーダー対応
- `aria-live` による動的更新通知
### 6.2 キーボード操作
- Tab順序の管理
- Enter/Escapeキーによる操作
- フォーカス管理
### 6.3 視覚的配慮
- 十分なカラーコントラスト比 (4.5:1以上)
- フォーカスインジケーター
- 動きの軽減オプション
## 7. エラーハンドリング
### 7.1 エラー境界
- React Error Boundary による予期せぬエラーのキャッチ
- フォールバックUIの表示
- エラーログの記録
### 7.2 バリデーション
- 入力値の検証 (Zod)
- エラーメッセージの表示
- 不正な操作の防止
## 8. テスト戦略
### 8.1 単体テスト
- コンポーネントの動作テスト
- カスタムフックのテスト
- ユーティリティ関数のテスト
### 8.2 統合テスト
- ユーザーフローのテスト
- データストアの連携テスト
- localStorage操作のテスト
### 8.3 E2Eテスト
- 主要機能のエンドツーエンドテスト
- 複数ブラウザでの動作確認
- パフォーマンステスト
## 9. セキュリティ考慮事項
### 9.1 XSS対策
- React のデフォルトエスケープ機能活用
- `dangerouslySetInnerHTML` の使用回避
- 入力値のサニタイゼーション
### 9.2 CSP設定
- Content Security Policy の実装
- インラインスクリプトの制限
- 外部リソースの制限
## 10. 将来の拡張性
### 10.1 機能拡張
- プラグインシステムの検討
- API連携の準備
- 多言語対応の基盤
### 10.2 技術的拡張
- PWA機能の段階的実装
- オフライン対応
- 同期機能の準備
## 11. 開発工程
### 11.1 Phase 1: 基盤構築
- プロジェクトセットアップ
- 基本コンポーネント実装
- 状態管理実装
### 11.2 Phase 2: 機能実装
- CRUD操作の実装
- フィルタリング機能
- データ永続化
### 11.3 Phase 3: UI/UX強化
- アニメーション実装
- レスポンシブ対応
- テーマ切り替え
### 11.4 Phase 4: 最適化・テスト
- パフォーマンス最適化
- テスト実装
- アクセシビリティ対応
一気に超具体化しましたね！！
Reactを初めて触ります！って時の学習にも使えそうです！
設計が問題ないか聞かれると思うので、次のフェーズに進めます。
> 次のフェーズに進んでください。
.tmp/tasks.md
# タスクリスト - ブラウザ対応超かっこいいTodoアプリ
## Phase 1: 基盤構築
### 1.1 プロジェクトセットアップ
- [ ] **T001**: Vite + React + TypeScript プロジェクト初期化
- [ ] **T002**: 依存関係のインストール（Tailwind CSS、Framer Motion、Zustand、Zod、Lucide React）
- [ ] **T003**: ESLint + Prettier 設定
- [ ] **T004**: Vitest + React Testing Library 設定
- [ ] **T005**: tsconfig.json 設定（厳密な型チェック）
- [ ] **T006**: ディレクトリ構成の作成（src/components、hooks、stores等）
### 1.2 基本設定・定数定義
- [ ] **T007**: TypeScript型定義の作成（types/index.ts）
- [ ] **T008**: 定数定義の作成（constants/index.ts）
- [ ] **T009**: グローバルスタイルの設定（Tailwind CSS設定）
- [ ] **T010**: カスタムCSS変数の定義（カラーパレット）
### 1.3 基本UIコンポーネント
- [ ] **T011**: Button コンポーネント作成
- [ ] **T012**: Input コンポーネント作成
- [ ] **T013**: Checkbox コンポーネント作成
- [ ] **T014**: Modal コンポーネント作成
- [ ] **T015**:基本UIコンポーネントのStorybook設定（オプション）
## Phase 2: 状態管理とデータ層
### 2.1 Zustand ストア実装
- [ ] **T016**: Todo ストアの基本実装
- [ ] **T017**: addTodo アクション実装
- [ ] **T018**: toggleTodo アクション実装
- [ ] **T019**: editTodo アクション実装
- [ ] **T020**: deleteTodo アクション実装
- [ ] **T021**: setFilter アクション実装
- [ ] **T022**: clearCompleted アクション実装
### 2.2 データ永続化
- [ ] **T023**: localStorage ユーティリティ関数作成
- [ ] **T024**: ストアのlocalStorage連携実装
- [ ] **T025**: データマイグレーション機能実装
- [ ] **T026**: エラーハンドリング（データ破損時の復旧）
### 2.3 カスタムフック
- [ ] **T027**: useTodos フック作成
- [ ] **T028**: useLocalStorage フック作成
- [ ] **T029**: useDebounce フック作成（検索用）
- [ ] **T030**: useKeyboard フック作成（キーボード操作用）
## Phase 3: コアコンポーネント実装
### 3.1 レイアウトコンポーネント
- [ ] **T031**: App コンポーネント作成
- [ ] **T032**: Header コンポーネント作成
- [ ] **T033**: Footer コンポーネント作成
- [ ] **T034**: TodoContainer コンポーネント作成
### 3.2 Todo関連コンポーネント
- [ ] **T035**: TodoInput コンポーネント作成
- [ ] **T036**: TodoList コンポーネント作成
- [ ] **T037**: TodoItem コンポーネント作成
- [ ] **T038**: TodoCheckbox コンポーネント作成
- [ ] **T039**: TodoText コンポーネント作成
- [ ] **T040**: TodoEditForm コンポーネント作成
- [ ] **T041**: TodoActions コンポーネント作成
- [ ] **T042**: TodoFilters コンポーネント作成
- [ ] **T043**: TodoStats コンポーネント作成
### 3.3 機能コンポーネント
- [ ] **T044**: ThemeToggle コンポーネント作成
- [ ] **T045**: Logo コンポーネント作成
- [ ] **T046**: ErrorBoundary コンポーネント作成
## Phase 4: 機能実装
### 4.1 CRUD操作
- [ ] **T047**: タスク追加機能の実装
- [ ] **T048**: タスク表示機能の実装
- [ ] **T049**: タスク完了切り替え機能の実装
- [ ] **T050**: タスクインライン編集機能の実装
- [ ] **T051**: タスク削除機能の実装
### 4.2 フィルタリング・検索
- [ ] **T052**: フィルタリング機能の実装（all/active/completed）
- [ ] **T053**: 検索機能の実装
- [ ] **T054**: 統計表示機能の実装
### 4.3 バリデーション
- [ ] **T055**: Zod スキーマ定義
- [ ] **T056**: 入力値バリデーション実装
- [ ] **T057**: エラーメッセージ表示機能
## Phase 5: UI/UX強化
### 5.1 テーマ機能
- [ ] **T058**: ダークモード/ライトモード切り替え実装
- [ ] **T059**: テーマ状態の永続化
- [ ] **T060**: システムテーマの自動検出
### 5.2 アニメーション実装
- [ ] **T061**: Framer Motion バリアント定義
- [ ] **T062**: タスク追加アニメーション実装
- [ ] **T063**: タスク削除アニメーション実装
- [ ] **T064**: タスク完了アニメーション実装
- [ ] **T065**: ホバーエフェクト実装
- [ ] **T066**: ページトランジション実装
### 5.3 レスポンシブデザイン
- [ ] **T067**: モバイルレイアウト実装
- [ ] **T068**: タブレットレイアウト実装
- [ ] **T069**: デスクトップレイアウト実装
- [ ] **T070**: タッチ操作対応
## Phase 6: パフォーマンス最適化
### 6.1 React最適化
- [ ] **T071**: React.memo 適用
- [ ] **T072**: useMemo/useCallback 適用
- [ ] **T073**: コンポーネントの遅延読み込み実装
- [ ] **T074**: 仮想スクロール実装（大量データ対応）
### 6.2 バンドル最適化
- [ ] **T075**: webpack/Vite設定最適化
- [ ] **T076**: Tree shaking 確認
- [ ] **T077**: Code splitting 実装
- [ ] **T078**: 不要な依存関係の削除
### 6.3 アニメーション最適化
- [ ] **T079**: GPU加速の適用
- [ ] **T080**: will-change プロパティ最適化
- [ ] **T081**: 60fps維持の確認
## Phase 7: アクセシビリティ対応
### 7.1 ARIA属性
- [ ] **T082**: role属性の設定
- [ ] **T083**: aria-label 属性の設定
- [ ] **T084**: aria-live 属性の設定
- [ ] **T085**: スクリーンリーダーテスト
### 7.2 キーボード操作
- [ ] **T086**: Tab順序の最適化
- [ ] **T087**: Enter/Escapeキー操作実装
- [ ] **T088**: フォーカス管理実装
- [ ] **T089**: キーボードナビゲーション実装
### 7.3 視覚的配慮
- [ ] **T090**: カラーコントラスト比の確認
- [ ] **T091**: フォーカスインジケーター実装
- [ ] **T092**: 動きの軽減オプション実装
## Phase 8: テスト実装
### 8.1 単体テスト
- [ ] **T093**: 基本UIコンポーネントのテスト
- [ ] **T094**: Todoコンポーネントのテスト
- [ ] **T095**: カスタムフックのテスト
- [ ] **T096**: ユーティリティ関数のテスト
- [ ] **T097**: Zustandストアのテスト
### 8.2 統合テスト
- [ ] **T098**: ユーザーフローのテスト
- [ ] **T099**: データ永続化のテスト
- [ ] **T100**: テーマ切り替えのテスト
### 8.3 E2Eテスト
- [ ] **T101**: Playwright設定
- [ ] **T102**: 主要機能のE2Eテスト
- [ ] **T103**: 複数ブラウザテスト
- [ ] **T104**: パフォーマンステスト
## Phase 9: セキュリティ・品質保証
### 9.1 セキュリティ対策
- [ ] **T105**: XSS対策の実装
- [ ] **T106**: CSP設定
- [ ] **T107**: 入力値サニタイゼーション
- [ ] **T108**: セキュリティ監査
### 9.2 コード品質
- [ ] **T109**: TypeScript strict モード確認
- [ ] **T110**: ESLint/Prettierルール最適化
- [ ] **T111**: コードレビュー実施
- [ ] **T112**: リファクタリング
## Phase 10: デプロイ・最終調整
### 10.1 ビルド・デプロイ
- [ ] **T113**: 本番ビルド設定
- [ ] **T114**: 静的ファイル最適化
- [ ] **T115**: デプロイ設定（Vercel/Netlify）
- [ ] **T116**: 環境設定の確認
### 10.2 最終テスト
- [ ] **T117**: 全機能の動作確認
- [ ] **T118**: パフォーマンス計測
- [ ] **T119**: アクセシビリティ監査
- [ ] **T120**: 複数デバイスでの動作確認
### 10.3 ドキュメント
- [ ] **T121**: README.md作成
- [ ] **T122**: 使用方法のドキュメント作成
- [ ] **T123**: 開発者向けドキュメント作成
- [ ] **T124**: ライセンス設定
## 実装優先度
### 最優先（MVP）
- T001-T006: プロジェクトセットアップ
- T007-T010: 基本設定
- T016-T022: 状態管理
- T031-T043: コアコンポーネント
- T047-T051: CRUD操作
- T052: フィルタリング
### 高優先
- T011-T015: 基本UIコンポーネント
- T023-T026: データ永続化
- T058-T060: テーマ機能
- T061-T066: アニメーション
- T067-T070: レスポンシブデザイン
### 中優先
- T071-T081: パフォーマンス最適化
- T082-T092: アクセシビリティ
- T093-T100: テスト実装
### 低優先
- T101-T104: E2Eテスト
- T105-T124: セキュリティ・品質保証・デプロイ
## 見積もり
- **Phase 1-2**: 2-3日
- **Phase 3-4**: 3-4日
- **Phase 5**: 2-3日
- **Phase 6-7**: 2-3日
- **Phase 8-10**: 2-3日
**総予想期間**: 11-16日（1日8時間作業想定）
なんと、このtodoアプリの実装にはタスクを124個処理する必要があり、11~16日かかるそうです！！！
（作業工数見積もりとかしてくれますが、実装するのはあなたなんですよね…と思いつつ…）
とまぁこんな感じで細かめに作業分割をしてくれます。
ちなみにClaude Code上ではmdで出力しつつ、Todosにも格納して作業開始の準備をしてくれます。
⏺ Update Todos
⎿ ☒ タスクリスト作成フェーズの実行
☐ 実装フェーズの開始準備
☐ Vite + React + TypeScript プロジェクト初期化
☐ 依存関係のインストール（Tailwind CSS、Framer Motion、Zustand、Zod、Lucide React）
☐ ESLint + Prettier 設定
☐ Vitest + React Testing Library 設定
☐ tsconfig.json 設定（厳密な型チェック）
☐ ディレクトリ構成の作成（src/components、hooks、stores等）
☐ TypeScript型定義の作成（types/index.ts）
☐ 定数定義の作成（constants/index.ts）
☐ グローバルスタイルの設定（Tailwind CSS設定）
☐ カスタムCSS変数の定義（カラーパレット）
⏺ 最優先タスクをTodoリストに追加しました。Phase 1の基盤構築タスク（T001-T010）が準備完了です。
T001のプロジェクト初期化から開始しますか？
終わりに
とまぁこんな感じで壮大なプロジェクトになってしまったわけですが、今回は実装せず、Kiro風の仕様書駆動開発を再現するまでで留めておきます…
実際に作業するとなったら、この中からさらにissue・ブランチを切って、同様の手順で仕様書を作って作業する流れになると思います。
適切な粒度でタスクが分割できればあとはClaude CodeがOpusでサクッと実装してくれる…はず！！！
このままだと粒度が大きく、コンテキストが大きくなり破綻すると思うので、結構細かめに設定してあげましょう！
ということで、KiroにOpus4が乗るまでの運命かもしれませんが、ツールの切り替えが面倒な方はこんな感じで作業させてあげてはどうでしょうか！