【Kiro・Playwright】社内でフルAI開発バトル！！「1行も書かずに」Todoアプリを完成させた話〜櫻井の場合〜

カテゴリ一 AWS サーバーレス ブログ 開発 構築 AI クラウド
2025-12-15

こんにちは。エンジニアの櫻井です。

このブログはギークフィードアドベントカレンダー2025の15日目の記事です。

他の記事もぜひチェックしてみてください！

 

自己紹介

クラウド開発事業部所属の櫻井です。
普段は主にバックエンドの開発を担当しています。エンジニア歴は4年で、主にAWSを使った開発をしています。

 

普段使ってるAIツール

日常的に以下のAIツールを活用しています。

  • Claude Code : 毎日コーディングで利用していますが、他のコーディングツールより指示の理解や出力がいいように感じます。

 

企画概要とゴール

今回、「フルAI開発バトル」という企画に参加しました。

ルールはシンプルかつ過酷です。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 禁止事項：エディタで直接コードを書く・修正すること
- 許されるのは「AIへの指示」のみ。人間の役割は「Architect/Reviewer」、つまりAIをマネジメントして成果物を判断することです。
 
 
# お題
社員の生産性を上げる日々の業務管理ツールを作ってください。
 
## 必須要件：
- KiroとPlaywright MCPを使うこと
- スペック駆動開発を行うこと（vibe codingはNG）
- Todoを追加・編集・削除できること
- 追加は画面上部のフォームから可能
- 編集・削除は各行の操作ボタンで行う
- 一覧でTodoを確認できること
- 一覧にはタイトル、担当者、期限を表示
- サクサク軽く操作できること
- 画面は1ページで完結
- PlaywrightでCRUD周りのテストをすること

 

詳しいルールや目的はアドベントカレンダー1日目の記事で紹介しております。

 

作業プロセス

要件の理解と整理

まず、渡された要件(*1)を読み込み、AIと壁打ちを行いながら疑問点を洗い出しました。 疑問点は発生した時点で仮説を立て、運営に対して質問を行い曖昧な部分を取り除くようにしました。
(*1)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
お疲れ〜!
多機能な管理ツールに疲れた社員のために、
今日やるべきことだけを管理できる軽量なツールが欲しいんだよね。
一応要件も書いたから、それに沿っていい感じに作ってほしい!
完成したらAWS(自分のSandbox環境)にデプロイしておいて〜!
 
・機能要件
  ・タスクの追加(画面上部のフォームからテキスト入力)、編集、削除、一覧表示(タイトル、担当者、期限を表示)
  ・ログイン機能は不要
・操作性
  ・画面は1ページで完結。サクサク軽く動いて、直感的に操作できること
  ・編集・削除は各行のボタンで可能
・データ保持
  ・ブラウザを閉じてもデータが消えないこと
・品質保証
  ・Playwright MCPを活用し、E2Eテストが通っていること

運営への質問事項

おそらくToDoリスト的なものを作ればいいということはわかりましたが、要件の中で書かれていないかつ重要そうな部分は運営に確認を行いました。

1
2
3
4
5
6
7
Q1:今日やるべきことの定義を教えて下さい。
期限が今日のものですか？期限がまだ来ていないものすべてですか？
今日のタスクというフラグがあるものですか？
その他ですか？その他の場合は定義をもう少し詳しく教えてください。
 
A1:期限が今日のものと、期限がまだ来ていないものすべてのどちらもかなー
絶対終わらせないといけないタスクと、できたら今日中にやりたいタスクとで優先度がわかればいい。

Q1の回答から、デフォルトでは今日やるべきタスクと期限が今日のタスクを表示して、「すべて表示」のようなボタンをクリックしたときだけ今日やるべきタスク以外のタスクもすべて表示するようにしようと考えました。

 

1
2
3
4
Q2:ユーザーは1人用ですか？
もしくは複数人が使うことを想定していますか？
 
A2:複数の社員で使うことを想定してるよ！

 

1
2
3
Q3:ログイン機能は不要ということですがユーザはそれぞれユーザ名入力ボックスに入力してもらうことで、ユーザを判断するということでいいですか？
 
A3:うん！イイネ

Q2 , Q3 から、

  • 複数人で使うアプリで、ユーザーの判別に複雑なロジックは不要で、ユーザーが入力した名前を信用するということ。
  • 複数人で使うということから、別のユーザーにタスクを作成するユーザーも居る可能性があるということを考え、どのユーザーがどのユーザーのために作成したタスクなのかが分かる必要があるということ
  • 他のユーザーのタスクを確認したい可能性を考え、デフォルトでは自分のタスクのみを表示するが、他のユーザーのタスクも表示できるようにすること
    が必要だと考えました。

Specs定義

要件を整理した上で、スペック駆動開発の第一歩として、Kiroに要件定義を依頼しました。

指示に至るまでの思考プロセス

Kiroに要件を伝える際に、曖昧な部分を勝手に判断せずに質問するように指示を行うようにする。 まずは、要件や、壁打ち、運営への質問から、わかったことを議事録に残してもらうように指示を行う

Kiroへの指示

いきなりspecsを作成するのではなく、まず壁打ちを行い、曖昧な部分を洗い出すアプローチを取りました。この際、以下の点を意識してKiroに指示を出しました。

曖昧な部分を勝手に判断させない：AIは行間を読んで勝手に実装を進めがちなので、不明点は必ず質問させる
議事録として記録を残す：壁打ちの内容をドキュメント化し、後から見返せるようにする
段階的に進める：壁打ち → 質問の洗い出し → 運営への確認 → specs作成という流れを明確にする

 

1
2
3
4
作りたいサービスがありますが、サービスについてまず壁打ちをしたいです。
壁打ちしたことは、まずはドキュメントに起こしながら聞いてほしいです。質問があればどんどんしてください。
 
私が曖昧な指示を出していた場合は、必ず質問するようにしてください。勝手に行間を読まないようにしてください。

その後、運営からの要件を提示すると、Kiroは brainstorming.md を作成し、14個の質問をリストアップしてきました。それに対して順次回答をおこない、更に質問が出てきた場合は回答する。のような形で要件を詰めていきました。

最終的に出来上がったbrainstorming.mdは以下です

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
# 壁打ちメモ - タスク管理ツール
 
## わかったこと
 
### 機能要件
 
- タスクの追加（画面上部のフォームからテキスト入力）
- タスクの編集
- タスクの削除
- タスクの一覧表示
  - タイトルを表示
  - 担当者を表示
  - 期限を表示
- ログイン機能は不要
 
### 操作性
 
- 画面は 1 ページで完結
- サクサク軽く動く
- 直感的に操作できる
- 編集・削除は各行のボタンで可能
 
### データ保持
 
- ブラウザを閉じてもデータが消えない
 
### 品質保証
 
- Playwright MCP を活用
- E2E テストが通っていること
 
### デプロイ
 
- AWS（Sandbox 環境）にデプロイ
 
## 回答済み
 
### データ保存・技術スタック
 
- **データベース**: DynamoDB を使用
- **ユーザー管理**: 複数の社員で使うことを想定（ログイン不要だが、ユーザー判別機能は必要）
- **タスク完了状態**: 管理する（一般的なタスク管理ツールをイメージ）
- **フロントエンド**: Vite + React
- **デプロイ**: S3 + CloudFront
- **バックエンド**: Lambda + API Gateway + DynamoDB
- **IaC**: CDK を使用
 
### タスクの入力項目
 
- **追加フォームで入力する項目**:
  - タイトル（必須）
  - 担当者（必須）
  - 期限（必須）
  - 説明文（任意）
  - 優先度（任意）: 「必須」または「できれば今日中」
- **編集で変更できる項目**: すべて（タイトル、担当者、期限、説明文、優先度）
- **編集方法**: モーダルで編集
 
### タスクの完了状態管理
 
- **完了/未完了の切り替え**: チェックボックス
- **完了タスクの表示**: パターン B（完了タスクは非表示にし、「完了済みを表示」ボタンで切り替え）
- **完了日時の記録**: 行う
 
### タスクの表示
 
- **一覧に表示する項目**: チェックボックス、タイトル、担当者、期限、優先度
- **説明文の表示**: タイトルをクリックするとモーダルで詳細（説明文含む）を表示
- **並び順**: ユーザーが選べるようにする（追加順 / 期限順）
- **デフォルト表示**: 期限が今日以前で未完了のタスクを表示
- **期限切れの表示**: 期限が今日以前の未完了タスクは赤色で表示
 
### データベース設計
 
- **DynamoDB テーブル設計**: 複数ユーザー対応を見越した設計にする
 
### 削除機能
 
- **削除確認**: 削除時は確認ダイアログを表示
- **削除対象**: 未完了タスク、完了済みタスクどちらも削除可能
 
### エラーハンドリング
 
- **API 呼び出し失敗時**: リトライを行い、それでも失敗したらエラーメッセージを表示してエラー終了
 
### プロジェクト構成
 
- **CDK プロジェクト**: 同一リポジトリに含める
 
### 将来的な拡張（時間があれば）
 
- タスクの検索やフィルタリング機能（日付以外）
 
 
4. **Cookie/Session ID**
   - サーバー側でセッション ID を発行し、Cookie に保存
   - メリット: ある程度の永続性
   - デメリット: Cookie を削除すると消える
 
### 参考情報：一般的なタスク管理ツールの完了状態管理
 
典型的な実装イメージ:
 
1. **チェックボックスで完了/未完了を切り替え**
 
   - タスク一覧の各行にチェックボックス
   - チェックを入れると完了状態になる
   - 完了したタスクは打ち消し線（~~タスク名~~）やグレーアウト表示
 
2. **完了タスクの表示オプション**
 
   - パターン A: 完了タスクも一覧に表示し続ける（Todoist、Microsoft To Do など）
   - パターン B: 完了タスクは非表示にし、「完了済みを表示」ボタンで切り替え
   - パターン C: 完了タスクは自動的に削除される
 
3. **完了日時の記録**
   - いつ完了したかを記録する場合もある
 
### 参考情報：軽量アプリを作る別の技術案
 
1. **Next.js + S3 + CloudFront（提案済み）**
 
   - メリット: SSG/SSR で高速、SEO 対応可能、開発体験が良い
   - デメリット: 小規模アプリには少しオーバースペック
 
2. **Vite + React + S3 + CloudFront**
 
   - メリット: ビルドが超高速、軽量、シンプル
   - デメリット: SSR が不要ならこちらの方が軽い
 
3. **Vanilla JS（フレームワークなし）+ S3 + CloudFront**
 
   - メリット: 最も軽量、依存関係なし
   - デメリット: 開発効率が下がる、状態管理が煩雑
 
4. **AWS Amplify**
 
   - メリット: フロントエンド + バックエンド + デプロイが統合、DynamoDB との連携が簡単
   - デメリット: Amplify の学習コストがある
 
5. **Astro + S3 + CloudFront**
   - メリット: 超軽量、部分的に React などを使える
   - デメリット: 動的な操作が多い場合は不向き
 
**推奨**: 今回のケースでは **Vite + React** が最も軽量でシンプルだと思います。
 
### ユーザー判別機能
 
- **方法**: ユーザー名入力ボックスに入力してもらうことで、ユーザーを判断する
- **実装**: 毎回アクセス時にユーザー名を入力してもらう
 
### 期限について
 
- **期限の形式**: 日時（日付 + 時刻）
- **期限切れの視覚的区別**: 期限が今日以前の未完了タスクは赤色で表示
 
### フィルタリングについて
 
- **デフォルト表示**: 期限が今日以前で未完了のタスクを表示
- **全タスク表示への切り替え**: 「全タスクを表示」ボタンで切り替えられるようにする
 
## 壁打ち完了
 
すべての要件が明確になりました。次のステップは spec（要件定義書）の作成です。

 

最後に、

brainstorming.mdからspecsを作成してください。

と依頼しました。

Kiroの出力

  • requirements.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
# 要件定義書
 
## はじめに
 
本システムは、多機能な管理ツールに疲れた社員のために、今日やるべきことだけを管理できる軽量なタスク管理ツールである。1 ページで完結するシンプルな UI で、タスクの追加・編集・削除・一覧表示を行い、ブラウザを閉じてもデータが永続化される。複数の社員が使用することを想定し、ユーザー名による簡易的なユーザー判別機能を持つ。
 
## 用語集
 
- **タスク管理システム**: 本タスク管理システム全体を指す
- **ユーザー**: システムを利用する社員
- **タスク**: ユーザーが管理する作業項目。タイトル、担当者、期限、説明文、優先度、完了状態を持つ
- **タスク一覧**: タスクの一覧表示画面
- **追加フォーム**: タスクを追加するための入力フォーム
- **編集モーダル**: タスクを編集するためのモーダルダイアログ
- **詳細モーダル**: タスクの詳細（説明文含む）を表示するモーダルダイアログ
- **完了状態**: タスクの完了/未完了の状態
- **優先度**: タスクの優先度（「必須」または「できれば今日中」）
- **期限**: タスクの期限（日付と時刻を含む）
- **期限切れタスク**: 期限が今日以前で未完了のタスク
- **DynamoDB テーブル**: タスクデータを永続化する AWS DynamoDB のテーブル
- **API ゲートウェイ**: バックエンド API のエンドポイントを提供する AWS サービス
- **Lambda 関数**: バックエンドのビジネスロジックを実行する AWS サービス
 
## 要件
 
### 要件 1
 
**ユーザーストーリー:** ユーザーとして、必要な情報を含む新しいタスクを追加したい。そうすることで、やるべきことを記録できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーが有効なタスク情報を含む追加フォームを送信する THEN タスク管理システム SHALL 提供されたタイトル、担当者、期限、任意の説明文、任意の優先度を持つ新しいタスクを作成する
2. WHEN ユーザーがタイトルなしで追加フォームを送信しようとする THEN タスク管理システム SHALL タスク作成を防止し、バリデーションエラーメッセージを表示する
3. WHEN ユーザーが担当者なしで追加フォームを送信しようとする THEN タスク管理システム SHALL タスク作成を防止し、バリデーションエラーメッセージを表示する
4. WHEN ユーザーが期限なしで追加フォームを送信しようとする THEN タスク管理システム SHALL タスク作成を防止し、バリデーションエラーメッセージを表示する
5. WHEN ユーザーがタスクの作成に成功する THEN タスク管理システム SHALL タスクを DynamoDB テーブルに即座に永続化する
 
### 要件 2
 
**ユーザーストーリー:** ユーザーとして、タスクを一覧で表示したい。そうすることで、やるべきことを確認できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーがタスク一覧にアクセスする THEN タスク管理システム SHALL デフォルトで期限切れタスク、優先度が「必須」のタスク、優先度が「できれば今日中」のタスク、期限が今日のタスクを表示する
2. WHEN タスク一覧にタスクを表示する THEN タスク管理システム SHALL 完了チェックボックス、タイトル、担当者、期限、優先度を表示する
3. WHEN タスクが期限切れタスクである THEN タスク管理システム SHALL タスクを赤色のテキストで表示する
4. WHEN ユーザーがタスクのタイトルをクリックする THEN タスク管理システム SHALL 説明文を含むすべてのタスク情報を表示する詳細モーダルを開く
5. WHEN ユーザーがソートオプションを選択する THEN タスク管理システム SHALL 選択された基準（作成順または期限順）に従ってタスク一覧を並び替える
 
### 要件 3
 
**ユーザーストーリー:** ユーザーとして、既存のタスクを編集したい。そうすることで、状況が変わったときにタスク情報を更新できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーがタスクの編集ボタンをクリックする THEN タスク管理システム SHALL 現在のすべてのタスク情報が事前入力された編集モーダルを開く
2. WHEN ユーザーが有効な変更を含む編集モーダルを送信する THEN タスク管理システム SHALL DynamoDB テーブル内のタスクを新しい情報で更新する
3. WHEN ユーザーがタイトルなしで編集モーダルを保存しようとする THEN タスク管理システム SHALL 更新を防止し、バリデーションエラーメッセージを表示する
4. WHEN ユーザーが担当者なしで編集モーダルを保存しようとする THEN タスク管理システム SHALL 更新を防止し、バリデーションエラーメッセージを表示する
5. WHEN ユーザーが期限なしで編集モーダルを保存しようとする THEN タスク管理システム SHALL 更新を防止し、バリデーションエラーメッセージを表示する
 
### 要件 4
 
**ユーザーストーリー:** ユーザーとして、不要になったタスクを削除したい。そうすることで、タスク一覧を整理できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーがタスクの削除ボタンをクリックする THEN タスク管理システム SHALL 削除前に確認ダイアログを表示する
2. WHEN ユーザーが確認ダイアログで削除を確定する THEN タスク管理システム SHALL DynamoDB テーブルからタスクを削除する
3. WHEN ユーザーが確認ダイアログで削除をキャンセルする THEN タスク管理システム SHALL ダイアログを閉じ、タスクを変更せずに維持する
4. WHEN タスクが削除される THEN タスク管理システム SHALL タスク一覧の表示から即座にタスクを削除する
 
### 要件 5
 
**ユーザーストーリー:** ユーザーとして、タスクを完了としてマークしたい。そうすることで、進捗を追跡できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーがタスクの完了チェックボックスをチェックする THEN タスク管理システム SHALL 完了状態を完了に更新し、完了タイムスタンプを記録する
2. WHEN ユーザーがタスクの完了チェックボックスのチェックを外す THEN タスク管理システム SHALL 完了状態を未完了に更新し、完了タイムスタンプをクリアする
3. WHEN タスクが完了としてマークされる THEN タスク管理システム SHALL デフォルトのタスク一覧ビューからタスクを非表示にする
4. WHEN ユーザーが「完了済みを表示」トグルボタンをクリックする THEN タスク管理システム SHALL タスク一覧に完了済みタスクを表示する
5. WHEN ユーザーが「完了済みを表示」トグルボタンを再度クリックする THEN タスク管理システム SHALL タスク一覧から完了済みタスクを非表示にする
6. WHEN ユーザーが完了済みタスクの「未完了に戻す」ボタンをクリックする THEN タスク管理システム SHALL タスクの完了状態を未完了に更新し、完了タイムスタンプをクリアする
 
### 要件 6
 
**ユーザーストーリー:** ユーザーとして、タスクをフィルタリングしたい。そうすることで、必要なタスクに集中できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーがフィルターを適用せずにタスク一覧にアクセスする THEN タスク管理システム SHALL デフォルトで期限切れタスク、優先度が「必須」のタスク、優先度が「できれば今日中」のタスク、期限が今日のタスクを表示する
2. WHEN ユーザーが「すべてのタスクを表示」ボタンをクリックする THEN タスク管理システム SHALL 期限に関係なくすべての未完了タスクを表示する
3. WHEN ユーザーが「すべてのタスクを表示」ボタンを再度クリックする THEN タスク管理システム SHALL デフォルトのフィルター表示に戻る
4. WHEN ユーザーが担当者名でフィルタリングする THEN タスク管理システム SHALL 指定された担当者名に一致するタスクのみを表示する
5. WHEN ユーザーが担当者フィルターをクリアする THEN タスク管理システム SHALL すべてのタスクを表示する
 
### 要件 7
 
**ユーザーストーリー:** ユーザーとして、システムを使用する際に自分を識別したい。そうすることで、自分のタスクのみを表示できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーがタスク管理システムにアクセスする THEN タスク管理システム SHALL ユーザー名入力フィールドを表示する
2. WHEN ユーザーがユーザー名を入力して送信する THEN タスク管理システム SHALL そのユーザー名に関連付けられたタスクのみを取得して表示する
3. WHEN ユーザーがユーザー名を入力していない THEN タスク管理システム SHALL タスク管理機能へのアクセスを防止する
 
### 要件 8
 
**ユーザーストーリー:** ユーザーとして、システムがエラーを適切に処理してほしい。そうすることで、何が問題だったかを理解し、作業を続けられる。
 
#### 受け入れ基準
 
1. WHEN API ゲートウェイのリクエストが失敗する THEN タスク管理システム SHALL 自動的にリクエストを再試行する
2. WHEN API ゲートウェイのリクエストが再試行後も失敗する THEN タスク管理システム SHALL ユーザーにエラーメッセージを表示する
3. WHEN Lambda 関数がエラーに遭遇する THEN タスク管理システム SHALL クライアントに適切なエラーレスポンスを返す
4. WHEN DynamoDB テーブルが利用できない THEN タスク管理システム SHALL サービスが一時的に利用できないことを示すエラーメッセージを表示する
 
### 要件 9
 
**ユーザーストーリー:** ユーザーとして、アプリケーションが高速で応答性が高いことを望む。そうすることで、効率的にタスクを管理できる。
 
#### 受け入れ基準
 
1. WHEN ユーザーが任意のタスク操作を実行する THEN タスク管理システム SHALL 通常のネットワーク条件下で 2 秒以内に操作を完了し UI を更新する
2. WHEN タスク管理システムがタスク一覧を読み込む THEN タスク管理システム SHALL 1 秒以内に初期ビューをレンダリングする
3. WHEN ユーザーが UI 要素と対話する THEN タスク管理システム SHALL 即座に視覚的フィードバックを提供する
 
### 要件 10
 
**ユーザーストーリー:** システム管理者として、アプリケーションを AWS にデプロイしたい。そうすることで、すべての社員がアクセスできるようになる。
 
#### 受け入れ基準
 
1. WHEN アプリケーションがデプロイされる THEN タスク管理システム SHALL CloudFront を通じて S3 からフロントエンドを提供する
2. WHEN アプリケーションがデプロイされる THEN タスク管理システム SHALL Lambda 関数に接続された API ゲートウェイを通じてバックエンド API を公開する
3. WHEN アプリケーションがデプロイされる THEN タスク管理システム SHALL すべてのタスクデータを DynamoDB テーブルに保存する
4. WHEN インフラストラクチャの変更が必要になる THEN タスク管理システム SHALL Infrastructure as Code 管理のために AWS CDK を使用する

 

  • design.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
# 設計書
 
## 概要
 
本システムは、軽量なタスク管理ツールとして、Vite + React によるフロントエンドと、AWS Lambda + API Gateway + DynamoDB によるサーバーレスバックエンドで構成される。**完全に 1 画面で完結するシングルページアプリケーション（SPA）**として実装し、ヘッダー部分にユーザー名入力欄を常時表示することで、画面遷移なしにユーザー判別とタスク管理を行う。AWS CDK を使用してインフラストラクチャをコード管理し、S3 + CloudFront でフロントエンドを配信する。
 
## アーキテクチャ
 
### システム構成図
 
```
┌─────────────┐
│   ユーザー   │
└──────┬──────┘
       │
       ▼
┌─────────────────────────────────┐
│      CloudFront (CDN)           │
└──────┬──────────────────────────┘
       │
       ▼
┌─────────────────────────────────┐
│      S3 (静的ホスティング)       │
│   Vite + React フロントエンド    │
└──────┬──────────────────────────┘
       │
       │ HTTPS
       ▼
┌─────────────────────────────────┐
│      API Gateway (REST API)     │
└──────┬──────────────────────────┘
       │
       ▼
┌─────────────────────────────────┐
│      Lambda 関数群              │
│  - getTasks                     │
│  - createTask                   │
│  - updateTask                   │
│  - deleteTask                   │
└──────┬──────────────────────────┘
       │
       ▼
┌─────────────────────────────────┐
│      DynamoDB テーブル          │
│      (Tasks)                    │
└─────────────────────────────────┘
```
 
### 技術スタック
 
**フロントエンド:**
 
- Vite 5.x
- React 18.x
- TypeScript 5.x
- CSS Modules または Tailwind CSS
 
**バックエンド:**
 
- AWS Lambda (Node.js 20.x)
- AWS API Gateway (REST API)
- AWS DynamoDB
 
**インフラストラクチャ:**
 
- AWS CDK (TypeScript)
- AWS S3
- AWS CloudFront
 
**開発ツール:**
 
- Playwright (E2E テスト)
- Vitest (ユニットテスト)
 
## コンポーネントとインターフェース
 
### フロントエンドコンポーネント
 
#### 1. App コンポーネント
 
- ルートコンポーネント
- **1 画面で完結する設計**
- ヘッダー部分にユーザー名入力フィールドを常時表示
- ユーザー名が入力されている場合のみ TaskList を表示
- ユーザー名が未入力の場合は案内メッセージを表示
- グローバルな状態管理
 
#### 2. TaskList コンポーネント
 
- タスク一覧の表示
- フィルタリング機能（デフォルト表示、全タスク表示、担当者フィルター）
- ソート機能（作成順、期限順）
- 完了済みタスクの表示/非表示切り替え
 
#### 3. TaskItem コンポーネント
 
- 個別タスクの表示
- 完了チェックボックス
- タイトル、担当者、期限、優先度の表示
- 編集ボタン、削除ボタン
- 期限切れタスクの赤色表示
 
#### 4. AddTaskForm コンポーネント
 
- タスク追加フォーム
- タイトル、担当者、期限（日時）、説明文、優先度の入力フィールド
- バリデーション機能
- 送信ボタン
 
#### 5. EditTaskModal コンポーネント
 
- タスク編集用モーダル
- すべてのタスク情報の編集
- バリデーション機能
- 保存ボタン、キャンセルボタン
 
#### 6. TaskDetailModal コンポーネント
 
- タスク詳細表示用モーダル
- すべてのタスク情報（説明文含む）の表示
- 閉じるボタン
 
#### 7. DeleteConfirmDialog コンポーネント
 
- 削除確認ダイアログ
- 確認ボタン、キャンセルボタン
 
### バックエンド API エンドポイント
 
#### GET /tasks
 
- クエリパラメータ: `username` (必須)
- レスポンス: タスク一覧（JSON 配列）
- 説明: 指定されたユーザー名に関連付けられたすべてのタスクを取得
 
#### POST /tasks
 
- リクエストボディ: タスク情報（JSON）
  ```json
  {
    "username": "string",
    "title": "string",
    "assignee": "string",
    "deadline": "ISO 8601 datetime string",
    "description": "string (optional)",
    "priority": "必須 | できれば今日中 (optional)"
  }
  ```
- レスポンス: 作成されたタスク（JSON）
- 説明: 新しいタスクを作成
 
#### PUT /tasks/{taskId}
 
- パスパラメータ: `taskId`
- リクエストボディ: 更新するタスク情報（JSON）
- レスポンス: 更新されたタスク（JSON）
- 説明: 既存のタスクを更新
 
#### DELETE /tasks/{taskId}
 
- パスパラメータ: `taskId`
- レスポンス: 成功メッセージ（JSON）
- 説明: タスクを削除
 
## データモデル
 
### Task エンティティ
 
```typescript
interface Task {
  taskId: string; // UUID、プライマリキー
  username: string; // ユーザー名、GSI のパーティションキー
  title: string; // タスクのタイトル（必須）
  assignee: string; // 担当者名（必須）
  deadline: string; // 期限（ISO 8601 形式の日時文字列、必須）
  description?: string; // 説明文（任意）
  priority?: "required" | "nice-to-have"; // 優先度（任意）
  completed: boolean; // 完了状態（デフォルト: false）
  completedAt?: string; // 完了日時（ISO 8601 形式、完了時のみ）
  createdAt: string; // 作成日時（ISO 8601 形式）
  updatedAt: string; // 更新日時（ISO 8601 形式）
}
```
 
### DynamoDB テーブル設計
 
**テーブル名:** `Tasks`
 
**プライマリキー:**
 
- パーティションキー: `taskId` (String)
 
**グローバルセカンダリインデックス (GSI):**
 
- インデックス名: `UsernameIndex`
- パーティションキー: `username` (String)
- ソートキー: `createdAt` (String)
 
**属性:**
 
- `taskId`: String (UUID)
- `username`: String
- `title`: String
- `assignee`: String
- `deadline`: String (ISO 8601)
- `description`: String (任意)
- `priority`: String (任意、'required' または 'nice-to-have')
- `completed`: Boolean
- `completedAt`: String (任意、ISO 8601)
- `createdAt`: String (ISO 8601)
- `updatedAt`: String (ISO 8601)
 
## 正確性プロパティ
 
_プロパティとは、システムのすべての有効な実行において真であるべき特性または動作です。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証との橋渡しとなります。_
 
### プロパティ 1: タスク作成の完全性
 
*任意の*有効なタスク情報（タイトル、担当者、期限を含む）に対して、タスクを作成すると、提供されたすべての情報を持つ新しいタスクが DynamoDB に永続化され、取得可能になる
 
**検証: 要件 1.1, 1.5**
 
### プロパティ 2: 必須フィールドのバリデーション
 
*任意の*タスク情報に対して、タイトル、担当者、期限のいずれかが空の場合、タスクの作成または更新は拒否され、適切なバリデーションエラーメッセージが表示される
 
**検証: 要件 1.2, 1.3, 1.4, 3.3, 3.4, 3.5**
 
### プロパティ 3: デフォルトフィルターの正確性
 
*任意の*タスクセットに対して、デフォルトフィルターを適用すると、表示されるタスクはすべて以下のいずれかの条件を満たす: (1) 期限切れ（期限が今日以前で未完了）、(2) 優先度が「必須」、(3) 優先度が「できれば今日中」、(4) 期限が今日
 
**検証: 要件 2.1, 6.1**
 
### プロパティ 4: タスク表示の完全性
 
*任意の*タスクに対して、タスク一覧に表示される際、完了チェックボックス、タイトル、担当者、期限、優先度のすべてが含まれる
 
**検証: 要件 2.2**
 
### プロパティ 5: 期限切れタスクの視覚的区別
 
*任意の*期限切れタスク（期限が今日以前で未完了）に対して、タスク一覧での表示は赤色のテキストスタイルを含む
 
**検証: 要件 2.3**
 
### プロパティ 6: タスク詳細モーダルの完全性
 
*任意の*タスクに対して、タイトルをクリックすると、説明文を含むすべてのタスク情報を表示する詳細モーダルが開く
 
**検証: 要件 2.4**
 
### プロパティ 7: ソート機能の正確性
 
*任意の*タスクセットに対して、作成順でソートすると結果は作成日時の昇順になり、期限順でソートすると結果は期限の昇順になる
 
**検証: 要件 2.5**
 
### プロパティ 8: 編集モーダルの事前入力
 
*任意の*タスクに対して、編集ボタンをクリックすると、現在のすべてのタスク情報が事前入力された編集モーダルが開く
 
**検証: 要件 3.1**
 
### プロパティ 9: タスク更新の正確性
 
*任意の*既存のタスクと有効な変更に対して、編集モーダルを送信すると、DynamoDB のタスクが新しい情報で更新され、取得時に新しい情報が反映される
 
**検証: 要件 3.2**
 
### プロパティ 10: 削除確認ダイアログの表示
 
*任意の*タスクに対して、削除ボタンをクリックすると、削除を実行する前に確認ダイアログが表示される
 
**検証: 要件 4.1**
 
### プロパティ 11: タスク削除の完全性
 
*任意の*タスクに対して、削除を確定すると、タスクは DynamoDB から削除され、タスク一覧から即座に消える
 
**検証: 要件 4.2, 4.4**
 
### プロパティ 12: 削除キャンセルの不変性
 
*任意の*タスクに対して、削除ダイアログでキャンセルを選択すると、タスクは変更されず、元の状態を維持する
 
**検証: 要件 4.3**
 
### プロパティ 13: タスク完了の状態更新
 
*任意の*未完了タスクに対して、完了チェックボックスをチェックすると、完了状態が完了に更新され、完了タイムスタンプが記録される
 
**検証: 要件 5.1**
 
### プロパティ 14: 完了状態のラウンドトリップ
 
*任意の*タスクに対して、完了チェックボックスをチェックしてからチェックを外すと、完了状態が未完了に戻り、完了タイムスタンプがクリアされる
 
**検証: 要件 5.2, 5.6**
 
### プロパティ 15: 完了タスクのデフォルト非表示
 
*任意の*タスクに対して、完了としてマークすると、デフォルトのタスク一覧ビューから非表示になる
 
**検証: 要件 5.3**
 
### プロパティ 16: 完了タスク表示トグルの動作
 
*任意の*完了済みタスクセットに対して、「完了済みを表示」トグルボタンをクリックすると完了済みタスクが表示され、再度クリックすると非表示になる
 
**検証: 要件 5.4, 5.5**
 
### プロパティ 17: 全タスク表示トグルの動作
 
*任意の*タスクセットに対して、「すべてのタスクを表示」ボタンをクリックするとすべての未完了タスクが表示され、再度クリックするとデフォルトフィルター表示に戻る
 
**検証: 要件 6.2, 6.3**
 
### プロパティ 18: 担当者フィルターの正確性
 
*任意の*タスクセットと担当者名に対して、担当者名でフィルタリングすると、表示されるタスクはすべて指定された担当者名と一致する
 
**検証: 要件 6.4**
 
### プロパティ 19: 担当者フィルタークリアの動作
 
*任意の*タスクセットに対して、担当者フィルターを適用してからクリアすると、すべてのタスクが表示される
 
**検証: 要件 6.5**
 
### プロパティ 20: ユーザー名によるタスクフィルタリング
 
*任意の*ユーザー名とタスクセットに対して、ユーザー名を入力して送信すると、そのユーザー名に関連付けられたタスクのみが取得され表示される
 
**検証: 要件 7.2**
 
### プロパティ 21: API 失敗時の再試行
 
*任意の*API リクエストに対して、最初の試行が失敗した場合、システムは自動的にリクエストを再試行する
 
**検証: 要件 8.1**
 
### プロパティ 22: 再試行失敗時のエラー表示
 
*任意の*API リクエストに対して、再試行後も失敗した場合、ユーザーに適切なエラーメッセージが表示される
 
**検証: 要件 8.2, 8.4**
 
### プロパティ 23: Lambda 関数のエラーレスポンス
 
*任意の*エラー条件に対して、Lambda 関数はクライアントに適切な HTTP ステータスコードとエラーメッセージを含むエラーレスポンスを返す
 
**検証: 要件 8.3**
 
## エラーハンドリング
 
### フロントエンドエラーハンドリング
 
1. **バリデーションエラー**
 
   - 必須フィールドが空の場合、フォーム送信を防止
   - フィールドごとに具体的なエラーメッセージを表示
   - エラー状態のフィールドを視覚的に強調表示
 
2. **API エラー**
 
   - 最大 3 回まで自動リトライ（指数バックオフ）
   - リトライ失敗後、ユーザーフレンドリーなエラーメッセージを表示
   - ネットワークエラー、サーバーエラー、タイムアウトを区別
 
3. **UI エラー**
   - エラートースト通知を使用
   - エラーメッセージは 5 秒後に自動的に消える
   - ユーザーが手動で閉じることも可能
 
### バックエンドエラーハンドリング
 
1. **Lambda 関数エラー**
 
   - すべてのエラーをキャッチし、適切な HTTP ステータスコードを返す
   - 400: バリデーションエラー
   - 404: リソースが見つからない
   - 500: サーバー内部エラー
   - エラーレスポンスには`error`フィールドを含む
 
2. **DynamoDB エラー**
 
   - 条件付き書き込みの失敗を適切に処理
   - スロットリングエラーの場合は自動リトライ
   - 接続エラーの場合は 503 ステータスを返す
 
3. **ロギング**
   - すべてのエラーを CloudWatch Logs に記録
   - エラーメッセージ、スタックトレース、リクエストコンテキストを含む
 
## テスト戦略
 
### ユニットテスト
 
**フロントエンド:**
 
- Vitest を使用
- 各コンポーネントの個別機能をテスト
- モックを使用して API コールを分離
- カバレッジ目標: 80%以上
 
**テスト対象:**
 
- コンポーネントのレンダリング
- ユーザーインタラクション（クリック、入力）
- 状態管理
- バリデーションロジック
- エラーハンドリング
 
**バックエンド:**
 
- Jest を使用
- Lambda 関数のビジネスロジックをテスト
- DynamoDB クライアントをモック
- カバレッジ目標: 80%以上
 
**テスト対象:**
 
- CRUD 操作
- バリデーション
- エラーハンドリング
- データ変換
 
### プロパティベーステスト
 
**フレームワーク:** fast-check (JavaScript/TypeScript 用のプロパティベーステストライブラリ)
 
**設定:**
 
- 各プロパティテストは最低 100 回の反復を実行
- ランダムシードを記録して再現可能性を確保
 
**テストタグ:**
 
- 各プロパティベーステストには、設計書の対応するプロパティを参照するコメントを含める
- フォーマット: `// Feature: daily-task-manager, Property X: [プロパティの説明]`
 
**テスト対象:**
 
- 上記の正確性プロパティ 1〜23
- ランダムなタスクデータを生成してプロパティを検証
- エッジケース（空文字列、境界値）を含むジェネレーターを使用
 
**ジェネレーター戦略:**
 
- `taskGenerator`: 有効なタスクオブジェクトを生成
- `invalidTaskGenerator`: 無効なタスクオブジェクトを生成（必須フィールドが欠けている）
- `taskArrayGenerator`: タスクの配列を生成
- `usernameGenerator`: ユーザー名を生成
- `dateGenerator`: 過去、現在、未来の日時を生成
 
### E2E テスト
 
**フレームワーク:** Playwright
 
**テスト対象:**
 
- ユーザーフロー全体（ログイン → タスク追加 → 編集 → 削除）
- フィルタリングとソート機能
- モーダルの開閉
- エラーシナリオ
 
**実行環境:**
 
- ローカル開発環境
- CI/CD パイプライン
 
### インテグレーションテスト
 
**テスト対象:**
 
- フロントエンドとバックエンドの統合
- API Gateway + Lambda + DynamoDB の統合
- 実際の AWS サービスを使用（テスト環境）
 
**ツール:**
 
- AWS SAM Local または LocalStack（ローカルテスト用）
- 専用のテスト AWS 環境
 
## デプロイメント
 
### インフラストラクチャ
 
**AWS CDK スタック構成:**
 
1. **FrontendStack**
 
   - S3 バケット（静的ホスティング）
   - CloudFront ディストリビューション
   - バケットポリシー
 
2. **BackendStack**
 
   - DynamoDB テーブル（Tasks）
   - Lambda 関数（getTasks, createTask, updateTask, deleteTask）
   - API Gateway（REST API）
   - IAM ロール・ポリシー
 
3. **MonitoringStack**（オプション）
   - CloudWatch Alarms
   - CloudWatch Dashboards
 
### CI/CD パイプライン
 
**ステージ:**
 
1. **ビルド**
 
   - フロントエンド: `npm run build`
   - バックエンド: Lambda 関数のパッケージング
   - CDK: `cdk synth`
 
2. **テスト**
 
   - ユニットテスト実行
   - プロパティベーステスト実行
   - E2E テスト実行
 
3. **デプロイ**
   - CDK: `cdk deploy --all`
   - フロントエンドアセットを S3 にアップロード
   - CloudFront キャッシュの無効化
 
### 環境
 
- **開発環境**: ローカル開発用
- **テスト環境**: CI/CD テスト用
- **本番環境**: Sandbox AWS 環境
 
### デプロイ手順
 
```bash
# 1. 依存関係のインストール
npm install
 
# 2. フロントエンドのビルド
cd frontend
npm run build
 
# 3. CDKのデプロイ
cd ../cdk
npm run build
cdk deploy --all
 
# 4. 出力されたCloudFront URLにアクセス
```
 
## セキュリティ考慮事項
 
1. **認証・認可**
 
   - 現在はユーザー名のみで識別（簡易実装）
   - 将来的には Cognito 等の認証サービスの導入を検討
 
2. **データ保護**
 
   - HTTPS 通信の強制（CloudFront）
   - DynamoDB の暗号化（保存時）
 
3. **入力バリデーション**
 
   - フロントエンドとバックエンドの両方でバリデーション
   - SQL インジェクション対策（DynamoDB は NoSQL のため影響は限定的）
   - XSS 対策（React のデフォルトエスケープ機能を活用）
 
4. **API セキュリティ**
 
   - CORS 設定の適切な構成
   - レート制限の実装（API Gateway）
 
5. **IAM 権限**
   - 最小権限の原則に従う
   - Lambda 関数には必要最小限の DynamoDB アクセス権限のみを付与

 

  • tasks.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
# 実装計画
 
- [x] 1. プロジェクト構造と CDK セットアップ
 
  - モノレポ構造を作成（frontend、backend、cdk）
  - 各ディレクトリに必要な package.json を配置
  - TypeScript 設定ファイルを作成
  - _要件: 10.4_
 
- [x] 1.1 CDK プロジェクトの初期化
 
  - CDK プロジェクトを初期化
  - DynamoDB テーブルスタックを定義
  - Lambda 関数スタックを定義
  - API Gateway スタックを定義
  - S3 + CloudFront スタックを定義
  - _要件: 10.1, 10.2, 10.3, 10.4_
 
- [x] 2. DynamoDB テーブルとデータモデルの実装
 
  - DynamoDB テーブル定義を CDK で作成
  - プライマリキー: taskId
  - GSI: UsernameIndex (username, createdAt)
  - _要件: 1.5, 10.3_
 
- [x] 2.1 TypeScript データモデルの定義
 
  - Task インターフェースを定義
  - バリデーション関数を実装
  - _要件: 1.1, 1.2, 1.3, 1.4_
 
- [x] 2.2 プロパティテスト: タスク作成の完全性
 
  - **Property 1: タスク作成の完全性**
  - **検証: 要件 1.1, 1.5**
 
- [x] 2.3 プロパティテスト: 必須フィールドのバリデーション
 
  - **Property 2: 必須フィールドのバリデーション**
  - **検証: 要件 1.2, 1.3, 1.4, 3.3, 3.4, 3.5**
 
- [x] 3. Lambda 関数の実装
 
  - 共通のユーティリティ関数を作成（エラーハンドリング、レスポンス生成）
  - DynamoDB クライアントの初期化
  - _要件: 8.3_
 
- [x] 3.1 getTasks Lambda 関数の実装
 
  - ユーザー名でタスクを取得する関数を実装
  - UsernameIndex を使用したクエリ
  - エラーハンドリングを実装
  - _要件: 7.2_
 
- [x] 3.2 プロパティテスト: ユーザー名によるタスクフィルタリング
 
  - **Property 20: ユーザー名によるタスクフィルタリング**
  - **検証: 要件 7.2**
 
- [x] 3.3 createTask Lambda 関数の実装
 
  - タスク作成ロジックを実装
  - UUID 生成、タイムスタンプ設定
  - バリデーションを実装
  - DynamoDB への書き込み
  - _要件: 1.1, 1.2, 1.3, 1.4, 1.5_
 
- [x] 3.4 updateTask Lambda 関数の実装
 
  - タスク更新ロジックを実装
  - バリデーションを実装
  - DynamoDB の更新
  - _要件: 3.2, 3.3, 3.4, 3.5_
 
- [x] 3.5 プロパティテスト: タスク更新の正確性
 
  - **Property 9: タスク更新の正確性**
  - **検証: 要件 3.2**
 
- [x] 3.6 deleteTask Lambda 関数の実装
 
  - タスク削除ロジックを実装
  - DynamoDB からの削除
  - _要件: 4.2_
 
- [x] 3.7 プロパティテスト: Lambda 関数のエラーレスポンス
 
  - **Property 23: Lambda 関数のエラーレスポンス**
  - **検証: 要件 8.3**
 
- [x] 3.8 ユニットテスト: Lambda 関数
 
  - getTasks のユニットテスト
  - createTask のユニットテスト
  - updateTask のユニットテスト
  - deleteTask のユニットテスト
  - _要件: 1.1, 3.2, 4.2, 7.2_
 
- [x] 4. API Gateway の設定
 
  - REST API を定義
  - エンドポイントを作成（GET /tasks, POST /tasks, PUT /tasks/{taskId}, DELETE /tasks/{taskId}）
  - Lambda 統合を設定
  - CORS を設定
  - _要件: 10.2_
 
- [x] 5. フロントエンドプロジェクトのセットアップ
 
  - Vite + React + TypeScript プロジェクトを作成
  - 必要な依存関係をインストール（React Router、状態管理ライブラリなど）
  - ディレクトリ構造を作成（components、hooks、services、types）
  - _要件: 10.1_
 
- [x] 5.1 API クライアントの実装
 
  - API 呼び出し用のサービスクラスを作成
  - リトライロジックを実装（最大 3 回、指数バックオフ）
  - エラーハンドリングを実装
  - _要件: 8.1, 8.2_
 
- [x] 5.2 プロパティテスト: API 失敗時の再試行
 
  - **Property 21: API 失敗時の再試行**
  - **検証: 要件 8.1**
 
- [x] 5.3 プロパティテスト: 再試行失敗時のエラー表示
 
  - **Property 22: 再試行失敗時のエラー表示**
  - **検証: 要件 8.2, 8.4**
 
- [x] 6. ユーザー識別機能の実装
 
  - UserIdentificationForm コンポーネントを作成
  - ユーザー名入力フィールドとバリデーション
  - ユーザー名の状態管理
  - _要件: 7.1, 7.2, 7.3_
 
- [x] 6.1 ユニットテスト: UserIdentificationForm コンポーネント
 
  - レンダリングテスト
  - ユーザー名入力のテスト
  - バリデーションのテスト
  - _要件: 7.1, 7.3_
 
- [x] 7. タスク一覧表示機能の実装
 
  - TaskList コンポーネントを作成
  - タスクの取得と表示
  - ローディング状態の管理
  - _要件: 2.1, 2.2_
 
- [x] 7.1 TaskItem コンポーネントの実装
 
  - 個別タスクの表示
  - 完了チェックボックス
  - タイトル、担当者、期限、優先度の表示
  - 編集ボタン、削除ボタン
  - _要件: 2.2_
 
- [x] 7.2 プロパティテスト: タスク表示の完全性
 
  - **Property 4: タスク表示の完全性**
  - **検証: 要件 2.2**
 
- [x] 7.3 期限切れタスクの赤色表示
 
  - 期限切れ判定ロジックを実装
  - 条件付きスタイリングを適用
  - _要件: 2.3_
 
- [x] 7.4 プロパティテスト: 期限切れタスクの視覚的区別
 
  - **Property 5: 期限切れタスクの視覚的区別**
  - **検証: 要件 2.3**
 
- [x] 8. フィルタリング機能の実装
 
  - デフォルトフィルターロジックを実装（期限切れ、優先度「必須」、優先度「できれば今日中」、期限が今日）
  - 「すべてのタスクを表示」トグルボタンを実装
  - 担当者フィルター機能を実装
  - _要件: 2.1, 6.1, 6.2, 6.3, 6.4, 6.5_
 
- [x] 8.1 プロパティテスト: デフォルトフィルターの正確性
 
  - **Property 3: デフォルトフィルターの正確性**
  - **検証: 要件 2.1, 6.1**
 
- [x] 8.2 プロパティテスト: 全タスク表示トグルの動作
 
  - **Property 17: 全タスク表示トグルの動作**
  - **検証: 要件 6.2, 6.3**
 
- [x] 8.3 プロパティテスト: 担当者フィルターの正確性
 
  - **Property 18: 担当者フィルターの正確性**
  - **検証: 要件 6.4**
 
- [x] 8.4 プロパティテスト: 担当者フィルタークリアの動作
 
  - **Property 19: 担当者フィルタークリアの動作**
  - **検証: 要件 6.5**
 
- [x] 9. ソート機能の実装
 
  - ソートオプション選択 UI を実装
  - 作成順ソートロジックを実装
  - 期限順ソートロジックを実装
  - _要件: 2.5_
 
- [x] 9.1 プロパティテスト: ソート機能の正確性
 
  - **Property 7: ソート機能の正確性**
  - **検証: 要件 2.5**
 
- [x] 10. タスク追加機能の実装
 
  - AddTaskForm コンポーネントを作成
  - 入力フィールド（タイトル、担当者、期限、説明文、優先度）
  - バリデーションロジックを実装
  - API 呼び出しとエラーハンドリング
  - _要件: 1.1, 1.2, 1.3, 1.4_
 
- [x] 10.1 ユニットテスト: AddTaskForm コンポーネント
 
  - レンダリングテスト
  - 入力フィールドのテスト
  - バリデーションのテスト
  - 送信処理のテスト
  - _要件: 1.1, 1.2, 1.3, 1.4_
 
- [x] 11. タスク編集機能の実装
 
  - EditTaskModal コンポーネントを作成
  - モーダルの開閉ロジック
  - 既存タスク情報の事前入力
  - バリデーションロジックを実装
  - API 呼び出しとエラーハンドリング
  - _要件: 3.1, 3.2, 3.3, 3.4, 3.5_
 
- [x] 11.1 プロパティテスト: 編集モーダルの事前入力
 
  - **Property 8: 編集モーダルの事前入力**
  - **検証: 要件 3.1**
 
- [x] 11.2 ユニットテスト: EditTaskModal コンポーネント
 
  - レンダリングテスト
  - 事前入力のテスト
  - バリデーションのテスト
  - 更新処理のテスト
  - _要件: 3.1, 3.2, 3.3, 3.4, 3.5_
 
- [x] 12. タスク詳細表示機能の実装
 
  - TaskDetailModal コンポーネントを作成
  - モーダルの開閉ロジック
  - すべてのタスク情報（説明文含む）の表示
  - _要件: 2.4_
 
- [x] 12.1 プロパティテスト: タスク詳細モーダルの完全性
 
  - **Property 6: タスク詳細モーダルの完全性**
  - **検証: 要件 2.4**
 
- [x] 13. タスク削除機能の実装
 
  - DeleteConfirmDialog コンポーネントを作成
  - 削除確認ダイアログの表示
  - 削除確定時の API 呼び出し
  - キャンセル時の処理
  - _要件: 4.1, 4.2, 4.3_
 
- [x] 13.1 プロパティテスト: 削除確認ダイアログの表示
 
  - **Property 10: 削除確認ダイアログの表示**
  - **検証: 要件 4.1**
 
- [x] 13.2 プロパティテスト: タスク削除の完全性
 
  - **Property 11: タスク削除の完全性**
  - **検証: 要件 4.2, 4.4**
 
- [x] 13.3 プロパティテスト: 削除キャンセルの不変性
 
  - **Property 12: 削除キャンセルの不変性**
  - **検証: 要件 4.3**
 
- [x] 14. タスク完了機能の実装
 
  - 完了チェックボックスのイベントハンドラー
  - 完了状態の更新 API 呼び出し
  - 完了タイムスタンプの記録
  - _要件: 5.1, 5.2_
 
- [x] 14.1 プロパティテスト: タスク完了の状態更新
 
  - **Property 13: タスク完了の状態更新**
  - **検証: 要件 5.1**
 
- [x] 14.2 プロパティテスト: 完了状態のラウンドトリップ
 
  - **Property 14: 完了状態のラウンドトリップ**
  - **検証: 要件 5.2, 5.6**
 
- [x] 15. 完了タスクの表示/非表示機能の実装
 
  - 完了タスクのフィルタリングロジック
  - 「完了済みを表示」トグルボタンの実装
  - デフォルトで完了タスクを非表示
  - _要件: 5.3, 5.4, 5.5_
 
- [x] 15.1 プロパティテスト: 完了タスクのデフォルト非表示
 
  - **Property 15: 完了タスクのデフォルト非表示**
  - **検証: 要件 5.3**
 
- [x] 15.2 プロパティテスト: 完了タスク表示トグルの動作
 
  - **Property 16: 完了タスク表示トグルの動作**
  - **検証: 要件 5.4, 5.5**
 
- [x] 16. エラーハンドリングとユーザーフィードバックの実装
 
  - エラートースト通知コンポーネントを作成
  - グローバルエラーハンドラーを実装
  - ローディングインジケーターを実装
  - _要件: 8.2, 9.3_
 
- [x] 16.1 ユニットテスト: エラーハンドリング
 
  - エラートースト表示のテスト
  - エラーメッセージのテスト
  - _要件: 8.2_
 
- [x] 17. スタイリングとレスポンシブデザイン
 
  - CSS Modules または Tailwind CSS を設定
  - 各コンポーネントのスタイリング
  - レスポンシブデザインの実装
  - 期限切れタスクの赤色スタイル
  - _要件: 2.3_
 
- [x] 18. チェックポイント - すべてのテストが通ることを確認
 
  - すべてのテストが通ることを確認し、質問があればユーザーに尋ねる
 
- [x] 19. E2E テストの実装
 
  - Playwright のセットアップ
  - ユーザー識別フローのテスト
  - タスク追加フローのテスト
  - タスク編集フローのテスト
  - タスク削除フローのテスト
  - フィルタリングとソートのテスト
  - _要件: すべて_
 
- [x] 19.1 E2E テスト: 完全なユーザーフロー
 
  - ユーザー名入力 → タスク追加 → 編集 → 完了 → 削除の一連のフロー
  - フィルタリングとソート機能
  - エラーシナリオ
 
- [x] 20. デプロイメントの準備
 
  - 環境変数の設定
  - ビルドスクリプトの作成
  - デプロイスクリプトの作成
  - _要件: 10.1, 10.2, 10.3, 10.4_
 
- [x] 21. AWS へのデプロイ
 
  - CDK を使用してインフラストラクチャをデプロイ
  - フロントエンドを S3 にアップロード
  - CloudFront キャッシュを無効化
  - デプロイ後の動作確認
  - _要件: 10.1, 10.2, 10.3, 10.4_
 
- [x] 22. 最終チェックポイント - すべてのテストが通ることを確認
  - すべてのテストが通ることを確認し、質問があればユーザーに尋ねる

出力の判定と修正

Kiroの出力を確認し、期待通りか、修正が必要かを判断しました。

判定結果

修正が必要

 

良かった点

最初に壁打ちをすることで、修正事項がすくなかったこと

問題点

・どのようなUIライブラリを使うかを指示していなかった
途中で気づきMUIを使うように指示しました。

Kiroとの対話

MUIを使用するように修正してください。

 

テスト実装

1. ユーザージャーニーテスト

・ユーザー識別
・タスク作成
・タスク詳細表示
・タスク編集
・タスク完了/未完了の切り替え
・タスク削除

2. バリデーションエラーテスト

・必須項目（タイトル、担当者、期限）が空の場合のエラー表示
・ユーザー名なしでのアクセス制限

3. フィルタリング機能テスト

・複数の担当者でタスクを作成
・特定の担当者でフィルタリング
・フィルタのクリア機能

4. ソート機能テスト

・作成日順
・期限順での並び替え

5. 表示切り替えテスト

・デフォルトフィルター（期限切れ、必須、できれば今日中、今日が期限）
・すべてのタスク表示
・完了済みタスクの表示/非表示

6. 削除確認ダイアログテスト

・削除確認ダイアログの表示
・削除のキャンセル機能
・削除の実行

成果物

自分のタスクを作成

 

 

別のユーザにタスクを作成

 

 

タスクの編集

 

 

タスクの完了

 

 

タスクの削除

 

 

タスクのフィルタリング

 

 

所要時間

3時間半

主な機能

  • タスクの作成/編集/削除
  • タスクの完了/完了取り消し
  • ユーザー入力
  • 担当者選択
  • タスクの表示
  • タスクの並び替え

工夫点など

  • specs作成前にもととなるドキュメントを作成するようにしました。事前にKiroと内容を細かく定義しておくことで手戻りを少なくできました。

 

発見と学び

brainstorming.mdという議事録をAIに作成してもらった、後から「なぜこの設計にしたのか」を振り返ることができました。また、運営への質問内容と回答も記録しておくことで、要件の変更履歴が明確になりました。

AIとの開発では、会話のログが流れていってしまうため、重要な決定事項はドキュメントとして残すことが特に重要だと感じました。

 

感想

良かった点

社内メンバーも同じ課題を行いブログを公開するので、自分がやったことのない使い方などを取り入れる機会ができそうです。

それにより、更にAIとうまく付き合っていく方法を勉強できることが良かったと思います。

苦労した点

最初の要件洗い出しのときに、見落としがないか、AIが勘違いをしている箇所がないかを確認しながら行うので少し時間がかかってしまいました。

今後に活かせること

実務でAIを使った開発をする際にも、まずは自分とAIの認識のズレがないかを確認したうえで仕様書を作成するようにすることで、AIの勝手な判断による実装をなるべく減らし、想定外のものができてしまう問題を少なくできると思いました。

 

この記事が、少しでもみなさんのにお役に立てば幸いです。

ここまでお読みいただき、ありがとうございました！

この記事が気に入ったら
いいね ! しよう

シェアする
ツイートする
Twitter で
The following two tabs change content below.
櫻井
2022年3月にギークフィードに入社。 エンジニア完全未経験からSAP・SAAを三週間で取得することが出来ました。そのためAWSに関することを中心に記事を作成する予定です。 自分が初心者だからこそわかる、エンジニア未経験の方や、エンジニアを始めたばかりの方の躓きポイントをうまく説明できるように頑張ります。

【採用情報】一緒に働く仲間を募集しています

採用情報
2025-12-15

関連投稿

ページトップへ