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

カテゴリ一 AWS ブログ 開発 構築 AI クラウド ウェブ/ECトレンド
2025-12-02

こんにちは。エンジニアの落合です。

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

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

 

自己紹介

クラウド開発事業部所属の落合です。
最近はコールセンターのシステムのクラウド移植を担当しています。エンジニア歴としては3年目で、主にJavaScriptやPHP（Laravel）を使った開発をしています。

最近はSwitch2をようやく手に入れたので「Pokémon LEGENDS Z-A」や「牧場物語 let’s 風のグランドバザール」を楽しんでいます。
リアル脱出ゲームにもちょくちょく参加したりしています。

 

普段使ってるAIツール

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

  • Gemini: 文章の添削、ちょっとしたコードの解説、案出しなど
    画像生成機能も優れているので生成AIの中で一番よく使います。
  • Copilot: コード補完機能や実装内容の紐解きなど
  • Kiro: 要件定義・設計書の段階から開発をする際に利用。
    クレジットが少なめなので基本的にコードについて疑問点がある場合はCopilotに頼りがち。

 

企画概要とゴール

今回、「フル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日目の記事で紹介しております。

 

作業プロセス

要件の理解と整理

まず最初にしたことは、手元のメモに画面の想像図を書いたことです。
想像図を書くことで、現在提示されている要件のみでどの程度まで実装できそうか、他にヒアリングしておいたほうが良い要件はないかが出しやすかったです。

以前業務である機能の実装をした時に、最初に全体像を把握しておらず、後から大きな修正をする必要が出てきてしまったことがあり、今回はその経験を活かした形になりました。

また、Kiroにも実装に必要な要件を出してもらいました。

 

1
2
3
4
5
<strong>Kiroへの質問</strong>：
 
タスク管理Webページの作成にあたって、必要な情報をあなたに提示したいです。
 
必要な質問を整理して提示してください。

運営への質問事項

運営（佐藤さん）には3回質問しました。

1
2
3
4
5
6
7
8
9
10
11
12
13
1回目
 
・タスクの表示は何順ですか？
　→タスクに集中したいから優先度見れたらいいなー。
 
・表示順は変えられるようにしますか？
　→優先度順が見れたら嬉しいな！
 
・タスクの検索（絞り込み）機能は必要ですか？
　→あれは嬉しいけど、難しい操作は避けたいから、シンプルでいいよ。
 
・開発言語・フレームワークの指定はありますか？
　→特にないよ！

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2回目
 
・タスク件数が多くなると見づらくなるかと思いますが、ページングは必要ですか？
　→そうだね。
 
・必要な場合、デフォルト表示数は何件ですか？
・表示数は何件が必要ですか？（20, 50, 100など）
　→20件かな。
 
・「神ツール」で想像されているタスクの表示形式はリスト形式であっていますか？
　→うん。各行で編集削除がしたい。
 
・Todoリストにかかる1ヶ月の費用感はどれくらいを想定されていますか？
　→1ヶ月もかけなくてよくて、1、2日で作れるシンプルものがいいなーすぐ欲しい。
　　（おそらく期間と見間違えていそう、とにかくシンプルさを追求したいのだと解釈）

1
2
3
4
5
6
7
8
9
10
11
12
3回目
 
・「サクサク動く」の基準ってありますか？（◯秒以内に動作が進むこと、など）
　→特に基準はないよ！よくwebサイトとかでグルグル待たされたりするけど、そういう動きしなければいいな。
 
・UIに使用してほしい色系統はありますか？
　→色の指定は特にないけど、色使いがごちゃごちゃしたUIは避けたいな。
 
・時間内での実装は難しいかとは思いますが、念の為質問させてください。リマインド機能は必要でしょうか？
　もしくは期限超過時や期限が迫ってきた場合に色を付けたりして目立たせたりする必要はありますか？
　→そこまでは必要ないよー！
　 とにかく今日のタスクに集中できたらいいかな！

 

Specs定義

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

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

Kiroに出してもらった質問事項と、運営からの回答を組み合わせてKiroに要件を送りました。
何度もKiroとやりとりをすると、出力によってはどんどん要件から逸れてしまう恐れがあったので、できるだけ1度の入力で要件定義書を完成させてもらえるようにしました。

Kiroへの指示

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
1. 基本機能について
　　タスクに持たせたい情報は何ですか？：タスク情報
　　タスクの基本操作は何が必要ですか？：
　　　・画面1ページで完結すること
　　　・タスクの追加、編集、削除機能　
　　　・タスクの追加には画面上部のフォームからテキストで入力すること　
　　　・タスク一覧にはタイトル、担当者、期限を表示すること　
　　　・ログイン機能は不要
 
2. 絞り込み・検索機能について
　　どのような条件で絞り込みたいですか？：絞り込みは不要、優先度降順で表示して
　　　　　　　　　　　　　　　　　　　　　複数条件の組み合わせは不要
 
3. 表示・UI について
　　タスクの表示形式は？：リスト形式
　　並び替え機能は不要
　　色使いはシンプルに
　　20件ごとにページングが必要
 
4. データ保存について
　　データの保存先は？：どちらでも、可能な限りシンプルな構成にして　
　　　　　　　　　　　　ただし、ブラウザを閉じてもデータが残るようにして
　　複数デバイス間での同期は不要
 
5. 技術スタックについて
　　使用したい技術はありますか？：特になし
　　既存のプロジェクトに組み込みますか、それとも新規作成ですか？：新規作成
 
6. パフォーマンス要件
　　「サクサク動く」の具体的な基準は？：読み込みで待たされない程度（1～2秒？）
　  　　　　　　　　　　　　　　　　　　webサイトでぐるぐるしない程度
 
7. 通知・リマインダー：なし
 
8. アプリケーションが完成したらAWSのSandbox環境にデプロイすること

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
# 要件定義書
 
## はじめに
 
本文書は、シンプルで高速なタスク管理Webページの要件を定義する。単一ページで完結し、タスクの追加・編集・削除を効率的に行えることを目的とする。ユーザーは待ち時間なく快適にタスク管理を行える。
 
## 用語集
 
- **システム**: タスク管理Webページ
- **タスク**: ユーザーが管理する作業項目。タイトル、担当者、期限、優先度の情報を持つ
- **タスクリスト**: タスクの一覧表示領域
- **入力フォーム**: 画面上部に配置されたタスク追加用のフォーム
- **ローカルストレージ**: ブラウザに内蔵されたデータ保存機能
- **優先度**: タスクの重要度を示す数値（高い値ほど優先度が高い）
 
## 要件
 
### 要件 1
 
**ユーザーストーリー:** ユーザーとして、新しいタスクを追加したい。そうすることで、やるべきことを記録できる。
 
#### 受入基準
 
1. WHEN ユーザーが入力フォームにタスク情報を入力して送信ボタンを押す THEN システムは新しいタスクを作成してタスクリストに追加すること
2. WHEN タスクが追加される THEN システムは入力フォームをクリアすること
3. WHEN ユーザーがタイトルを空のまま送信しようとする THEN システムはタスクの追加を拒否して現在の状態を維持すること
4. WHEN タスクが追加される THEN システムはタスクをローカルストレージに即座に保存すること
5. THE システムは入力フォームを画面上部に配置すること
 
### 要件 2
 
**ユーザーストーリー:** ユーザーとして、既存のタスクを編集したい。そうすることで、情報を最新の状態に保てる。
 
#### 受入基準
 
1. WHEN ユーザーがタスクの編集ボタンをクリックする THEN システムは編集モードに切り替えて現在の情報を表示すること
2. WHEN ユーザーが編集内容を保存する THEN システムはタスク情報を更新してタスクリストに反映すること
3. WHEN タスクが編集される THEN システムは更新されたタスクをローカルストレージに即座に保存すること
4. WHEN ユーザーが編集をキャンセルする THEN システムは変更を破棄して元の表示に戻すこと
 
### 要件 3
 
**ユーザーストーリー:** ユーザーとして、不要なタスクを削除したい。そうすることで、タスクリストを整理できる。
 
#### 受入基準
 
1. WHEN ユーザーがタスクの削除ボタンをクリックする THEN システムはそのタスクをタスクリストから削除すること
2. WHEN タスクが削除される THEN システムはローカルストレージから該当タスクを即座に削除すること
3. WHEN タスクが削除される THEN システムは他のタスクの表示順序を維持すること
 
### 要件 4
 
**ユーザーストーリー:** ユーザーとして、タスクを優先度順に表示したい。そうすることで、重要なタスクを見逃さない。
 
#### 受入基準
 
1. THE システムはタスクリストを優先度の降順で表示すること
2. WHEN 新しいタスクが追加される THEN システムは優先度に基づいて適切な位置に挿入すること
3. WHEN タスクの優先度が変更される THEN システムはタスクリストを再ソートして表示すること
 
### 要件 4.5
 
**ユーザーストーリー:** ユーザーとして、大量のタスクを扱う際にページング機能を使いたい。そうすることで、画面が見やすく保たれる。
 
#### 受入基準
 
1. WHEN タスクが20件を超える THEN システムは20件ごとにページを分割して表示すること
2. THE システムはページネーション用のナビゲーションを表示すること
3. WHEN ユーザーがページを切り替える THEN システムは即座に（100ミリ秒以内に）該当ページのタスクを表示すること
4. WHEN 新しいタスクが追加される THEN システムは適切なページに配置して現在のページ表示を維持すること
5. THE システムは現在のページ番号と総ページ数を表示すること
 
### 要件 5
 
**ユーザーストーリー:** ユーザーとして、タスクの重要な情報を一目で確認したい。そうすることで、効率的にタスクを管理できる。
 
#### 受入基準
 
1. THE システムはタスクリストに各タスクのタイトル、担当者、期限を表示すること
2. THE システムはタスクをリスト形式で表示すること
3. THE システムはシンプルな色使いでUIを構成すること
4. THE システムは全ての機能を単一ページ内で提供すること
 
### 要件 6
 
**ユーザーストーリー:** ユーザーとして、ブラウザを閉じても自分のタスクが残っていてほしい。そうすることで、いつでも作業を再開できる。
 
#### 受入基準
 
1. WHEN ユーザーがブラウザを閉じて再度開く THEN システムは以前のタスクデータを復元して表示すること
2. THE システムはタスクデータをローカルストレージに永続化すること
3. WHEN ページが読み込まれる THEN システムはローカルストレージからタスクデータを取得すること
 
### 要件 7
 
**ユーザーストーリー:** ユーザーとして、待ち時間なく快適に操作したい。そうすることで、ストレスなくタスク管理ができる。
 
#### 受入基準
 
1. WHEN ページが読み込まれる THEN システムは2秒以内に初期表示を完了すること
2. WHEN ユーザーがタスクを追加、編集、削除する THEN システムは即座に（100ミリ秒以内に）UIを更新すること
3. THE システムは読み込み中のスピナーやローディング表示を不要とする応答速度を維持すること
4. THE システムはクライアントサイドでデータ処理を完結させること
 
### 要件 8
 
**ユーザーストーリー:** ユーザーとして、シンプルな構成のシステムを使いたい。そうすることで、安定して動作することを期待できる。
 
#### 受入基準
 
1. THE システムは外部サーバーとの通信を必要としないこと
2. THE システムは最小限の技術スタックで構成されること
3. THE システムはログイン機能を持たないこと
4. THE システムは単一のHTMLファイルとして配布可能であること
 
### 要件 9
 
**ユーザーストーリー:** ユーザーとして、誤った操作を元に戻したい。そうすることで、間違ってタスクを削除や編集してしまっても復元できる。
 
#### 受入基準
 
1. THE システムは操作履歴を保持すること
2. WHEN ユーザーがUndo操作を実行する THEN システムは直前の操作を取り消して前の状態に戻すこと
3. WHEN Undo可能な操作がない THEN システムはUndo操作を無効化すること
4. THE システムはタスクの追加、編集、削除の操作をUndo可能とすること
5. THE システムは最低10回分の操作履歴を保持すること
 
### 要件 10
 
**ユーザーストーリー:** 開発者として、完成したシステムをAWS環境にデプロイしたい。そうすることで、ユーザーがインターネット経由でアクセスできる。
 
#### 受入基準
 
1. THE システムはAWS Sandbox環境にデプロイ可能な構成であること
2. THE システムは静的ファイルとしてホスティング可能であること
3. WHEN デプロイが完了する THEN システムはHTTPS経由でアクセス可能であること
4. THE システムはAWS S3とCloudFrontを使用した静的ホスティングに適した構成であること

 

  • 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
# 設計書
 
## 概要
 
本システムは、シンプルで高速なタスク管理Webページである。単一のHTMLファイルで構成され、ブラウザのローカルストレージを使用してデータを永続化する。ユーザーはタスクの追加・編集・削除を1ページ内で完結でき、優先度順に整理されたタスクリストを20件ごとのページングで閲覧できる。
 
## アーキテクチャ
 
### 全体構成
 
システムは以下の3層で構成される：
 
1. **プレゼンテーション層**: HTML/CSS/JavaScriptによるUI
2. **ビジネスロジック層**: タスク管理、ソート、ページング処理
3. **データ層**: ローカルストレージへのアクセス
 
```mermaid
graph TB
UI[UI Layer&lt;br/&gt;HTML/CSS/JavaScript]
Logic[Business Logic Layer&lt;br/&gt;Task Management]
Storage[Data Layer&lt;br/&gt;LocalStorage]
 
UI --&gt; Logic
Logic --&gt; Storage
Storage --&gt; Logic
Logic --&gt; UI
```
 
### 技術スタック
 
- **フロントエンド**: Vanilla JavaScript（フレームワーク不使用）
- **スタイリング**: CSS（インラインまたは内部スタイル）
- **データ保存**: Web Storage API（localStorage）
- ローカルストレージとは、ブラウザに組み込まれたキー・バリュー型のストレージ機能
- データはブラウザのプロファイルディレクトリに保存される（例: Chrome の場合 `%LOCALAPPDATA%\Google\Chrome\User Data\Default\Local Storage`）
- ページを閉じてもデータは永続化され、同じオリジン（ドメイン）からアクセス可能
- **デプロイ**: AWS S3 + CloudFront
 
### 単一ファイル構成
 
全てのコード（HTML、CSS、JavaScript）を1つのHTMLファイルに統合する。これにより：
- デプロイが簡単
- 依存関係がない
- 高速な読み込み
 
## コンポーネントとインターフェース
 
### 1. TaskManager（タスク管理コンポーネント）
 
タスクのCRUD操作とビジネスロジックを担当する。
 
```javascript
class TaskManager {
constructor(storageKey)
addTask(task)
updateTask(taskId, updates)
deleteTask(taskId)
getTasks()
getTasksSortedByPriority()
}
```
 
### 2. StorageService（ストレージサービス）
 
ローカルストレージへのアクセスを抽象化する。
 
```javascript
class StorageService {
save(key, data)
load(key)
remove(key)
}
```
 
### 3. PaginationManager（ページング管理）
 
タスクリストのページング処理を担当する。
 
```javascript
class PaginationManager {
constructor(itemsPerPage)
paginate(items)
getCurrentPage()
getTotalPages()
goToPage(pageNumber)
nextPage()
previousPage()
}
```
 
### 4. UIController（UIコントローラー）
 
DOM操作とイベントハンドリングを担当する。
 
```javascript
class UIController {
renderTaskList(tasks)
renderPagination(currentPage, totalPages)
bindAddTask(handler)
bindEditTask(handler)
bindDeleteTask(handler)
bindPageChange(handler)
bindUndo(handler)
updateUndoButton(enabled)
clearForm()
showError(message)
}
```
 
### 5. CommandHistory（コマンド履歴管理）
 
Undo機能のためのコマンドパターンを実装する。
 
```javascript
class CommandHistory {
constructor(maxSize)
execute(command)
undo()
canUndo()
clear()
}
 
// コマンドインターフェース
interface Command {
execute()
undo()
}
```
 
## データモデル
 
### Task（タスク）
 
```javascript
{
id: string, // UUID
title: string, // タスクのタイトル（必須）
assignee: string, // 担当者名
dueDate: string, // 期限（ISO 8601形式）
priority: number, // 優先度（1-5、5が最高）
createdAt: string, // 作成日時（ISO 8601形式）
updatedAt: string // 更新日時（ISO 8601形式）
}
```
 
### バリデーションルール
 
- `title`: 空文字列不可、最大200文字
- `assignee`: 最大50文字
- `dueDate`: 有効な日付形式
- `priority`: 1〜5の整数
- `id`: UUID v4形式
 
 
## エラーハンドリング
 
### エラーの種類
 
1. **バリデーションエラー**: 入力データが不正な場合
2. **ストレージエラー**: ローカルストレージへのアクセスが失敗した場合
3. **データ破損エラー**: 保存されたデータが不正な形式の場合
 
### エラー処理戦略
 
- バリデーションエラー: ユーザーにフィードバックを表示し、操作を中断
- ストレージエラー: コンソールにログを出力し、メモリ上でのみ動作を継続
- データ破損エラー: 空のタスクリストで初期化し、ユーザーに通知
 
### エラーメッセージ
 
- 日本語で明確なメッセージを表示
- エラーは画面上部に赤色で表示
- 3秒後に自動的に消える
 
## テスト戦略
 
本システムでは、Playwrightを使用したE2Eテストとプロパティベーステストの両方を使用して品質を保証する。
 
### E2Eテスト（Playwright）
 
- ブラウザ上での実際のユーザー操作をシミュレート
- UI要素の存在と動作を検証
- 特定の例やエッジケースを検証
- 各コンポーネントの統合動作を確認
 
### プロパティベーステスト（Playwright + ランダムデータ生成）
 
プロパティベーステストは、すべての有効な入力に対して成立すべき普遍的な性質を検証する。Playwrightを使用してブラウザ上で実行する。
 
- 各プロパティテストは最低100回の反復実行を行う
- 各テストには設計書の正当性プロパティへの参照をコメントで明記する
- フォーマット: `// Feature: task-management-web, Property {番号}: {プロパティ文}`
- ランダムなタスクデータを生成してブラウザ上で操作を実行
 
### テストツール
 
- **E2Eテストフレームワーク**: Playwright（MCP Server経由）
- **実行環境**: ブラウザ（Chromium/Firefox/WebKit）
- **データ生成**: カスタムランダムデータジェネレーター
 
 
## 正当性プロパティ
 
*プロパティとは、システムの全ての有効な実行において真であるべき特性や振る舞いのことである。プロパティは、人間が読める仕様と機械で検証可能な正当性保証の橋渡しとなる。*
 
### プロパティ 1: タスク追加でリストが成長する
 
*任意の*タスクリストと有効なタスクデータに対して、タスクを追加すると、タスクリストの長さが1増加すること
 
**検証: 要件 1.1**
 
### プロパティ 2: 空のタイトルは拒否される
 
*任意の*空文字列または空白文字のみの文字列に対して、それをタイトルとするタスクの追加は拒否され、タスクリストは変更されないこと
 
**検証: 要件 1.3**
 
### プロパティ 3: ストレージラウンドトリップの一貫性
 
*任意の*タスクに対して、ローカルストレージに保存してから読み込むと、元のタスクと同等のデータが得られること
 
**検証: 要件 1.4, 2.3, 6.1**
 
### プロパティ 4: タスク更新の反映
 
*任意の*既存タスクと更新内容に対して、タスクを更新すると、タスクリスト内の該当タスクが新しい値を持つこと
 
**検証: 要件 2.2**
 
### プロパティ 5: 編集キャンセルで状態保持
 
*任意の*タスクに対して、編集を開始してキャンセルすると、タスクの内容が編集前と同じであること
 
**検証: 要件 2.4**
 
### プロパティ 6: タスク削除でリストから除外
 
*任意の*タスクリストと削除対象タスクに対して、タスクを削除すると、そのタスクはタスクリストに含まれなくなること
 
**検証: 要件 3.1**
 
### プロパティ 7: 削除後のストレージ一貫性
 
*任意の*タスクに対して、削除後にローカルストレージを確認すると、そのタスクは存在しないこと
 
**検証: 要件 3.2**
 
### プロパティ 8: 削除時の順序保持
 
*任意の*タスクリストから1つのタスクを削除した場合、残りのタスクの相対的な順序は変わらないこと
 
**検証: 要件 3.3**
 
### プロパティ 9: 優先度ソート不変性
 
*任意の*タスクリストに対して、表示されるタスクは常に優先度の降順でソートされていること。また、タスクの追加や優先度変更後も、この順序が維持されること
 
**検証: 要件 4.1, 4.2, 4.3**
 
### プロパティ 10: ページング境界の正確性
 
*任意の*21件以上のタスクリストに対して、各ページには最大20件のタスクが表示され、全てのタスクがいずれかのページに含まれること
 
**検証: 要件 4.5.1**
 
### プロパティ 11: ページング状態の維持
 
*任意の*ページ状態で新しいタスクを追加した場合、タスクは優先度に基づいて適切なページに配置され、現在表示中のページが不必要に変更されないこと
 
**検証: 要件 4.5.4**
 
### プロパティ 12: タスク表示の完全性
 
*任意の*タスクに対して、レンダリングされたHTML文字列には、タイトル、担当者、期限の情報が全て含まれること
 
**検証: 要件 5.1**
 
### プロパティ 13: フォームクリアの一貫性
 
*任意の*タスクを追加した後、入力フォームの全てのフィールドが空になること
 
**検証: 要件 1.2**
 
### プロパティ 14: 編集モードでの情報表示
 
*任意の*タスクに対して、編集モードに入ると、フォームには現在のタスク情報が正確に表示されること
 
**検証: 要件 2.1**
 
### プロパティ 15: Undo操作で状態復元
 
*任意の*操作（追加、編集、削除）に対して、その操作を実行した直後にUndoを実行すると、操作前の状態に戻ること
 
**検証: 要件 9.2**
 
### プロパティ 16: Undo履歴の上限
 
*任意の*11回以上の連続操作に対して、システムは最新の10回分の操作のみをUndo可能とすること
 
**検証: 要件 9.5**
 
### プロパティ 17: Undo不可時の無効化
 
*任意の*初期状態またはUndo履歴が空の状態で、Undoボタンが無効化されていること
 
**検証: 要件 9.3**

 

  • 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
# 実装計画
 
- [x] 1. プロジェクト構造とコアインターフェースのセットアップ
 
- 単一HTMLファイルの基本構造を作成
- データモデル（Task）の型定義を実装
- 基本的なCSSスタイルを追加（シンプルな色使い）
- _要件: 8.4, 5.3_
 
- [x] 2. ストレージサービスの実装
 
- [x] 2.1 StorageServiceクラスを実装
 
- localStorage APIを使用したsave/load/removeメソッドを実装
- JSON形式でのシリアライズ/デシリアライズを実装
- _要件: 6.2_
 
- [x] 2.2 プロパティテスト: ストレージラウンドトリップの一貫性
 
 
- **プロパティ 3: ストレージラウンドトリップの一貫性**
- **検証: 要件 1.4, 2.3, 6.1**
 
- [x] 3. タスク管理コアロジックの実装
 
- [x] 3.1 TaskManagerクラスを実装
 
- タスクの追加、更新、削除メソッドを実装
- UUID生成機能を実装
- タスクバリデーション機能を実装（タイトル必須、文字数制限）
- _要件: 1.1, 1.3, 2.2, 3.1_
 
- [x] 3.2 プロパティテスト: タスク追加でリストが成長する
 
- **プロパティ 1: タスク追加でリストが成長する**
- **検証: 要件 1.1**
 
- [x] 3.3 プロパティテスト: 空のタイトルは拒否される
 
- **プロパティ 2: 空のタイトルは拒否される**
- **検証: 要件 1.3**
 
- [x] 4. 優先度ソート機能の実装
 
- [x] 4.1 TaskManagerにソート機能を追加
 
- 優先度降順でタスクをソートするメソッドを実装
- タスク追加・更新時に自動ソートを適用
- _要件: 4.1, 4.2, 4.3_
 
- [x] 4.2 プロパティテスト: 優先度ソート不変性
- **プロパティ 9: 優先度ソート不変性**
- **検証: 要件 4.1, 4.2, 4.3**
 
- [x] 5. ページング機能の実装
 
- [x] 5.1 PaginationManagerクラスを実装
- 20件ごとのページ分割ロジックを実装
- ページ移動メソッド（next/previous/goToPage）を実装
- 現在ページと総ページ数の計算を実装
- _要件: 4.5.1, 4.5.4, 4.5.5_
 
- [x] 6. Undo機能の実装
 
- [x] 6.1 CommandHistoryクラスとCommandインターフェースを実装
- コマンドパターンを実装
- 最大10件の履歴管理を実装
- execute/undoメソッドを実装
- _要件: 9.1, 9.2, 9.5_
 
- [x] 6.2 各操作のCommandクラスを実装
- AddTaskCommand、UpdateTaskCommand、DeleteTaskCommandを実装
- 各コマンドのundo処理を実装
- _要件: 9.4_
 
- [x] 7. UIコントローラーの実装
 
- [x] 7.1 UIControllerクラスを実装
- DOM要素の取得と初期化
- タスクリストのレンダリング機能を実装
- ページネーションUIのレンダリングを実装
- _要件: 5.1, 5.2, 4.5.2, 4.5.5_
 
- [x] 7.2 入力フォームの実装
- 画面上部に入力フォームを配置
- タイトル、担当者、期限、優先度の入力フィールドを実装
- フォームクリア機能を実装
- _要件: 1.5, 1.2_
 
- [x] 8. イベントハンドリングの実装
 
- [x] 8.1 タスク追加イベントを実装
- フォーム送信時のイベントハンドラーを実装
- バリデーションエラー表示を実装
- _要件: 1.1, 1.3_
 
- [x] 8.2 タスク編集イベントを実装
- 編集ボタンクリック時のイベントハンドラーを実装
- 編集モードの切り替えを実装
- 編集キャンセル機能を実装
- _要件: 2.1, 2.2, 2.4_
 
- [x] 8.3 タスク削除イベントを実装
- 削除ボタンクリック時のイベントハンドラーを実装
- _要件: 3.1_
 
- [x] 8.4 ページング操作イベントを実装
- ページ切り替えボタンのイベントハンドラーを実装
- _要件: 4.5.3_
 
- [x] 8.5 Undoボタンのイベントを実装
- Undoボタンクリック時のイベントハンドラーを実装
- Undoボタンの有効/無効状態の更新を実装
- _要件: 9.2, 9.3_
 
- [x] 9. アプリケーション初期化とデータ復元
 
- [x] 9.1 アプリケーション起動処理を実装
- ページロード時にlocalStorageからデータを読み込み
- 初期表示を実行
- 全コンポーネントを統合
- _要件: 6.1, 6.3, 7.1_
 
- [x] 10. エラーハンドリングの実装
- エラーメッセージ表示機能を実装
- バリデーションエラーのユーザーフィードバックを実装
- ストレージエラーのフォールバック処理を実装
- _要件: 1.3_
 
- [x] 11. チェックポイント - 全テストの実行
 
- 全てのテストが通ることを確認
- 問題があればユーザーに報告
 
- [x] 12. パフォーマンス最適化
 
- 不要な再レンダリングを削減
- イベントリスナーの最適化
- _要件: 7.2, 7.3, 7.4_
 
- [x] 13. 最終チェックポイント
 
- 全ての要件が満たされていることを確認
- 全てのテストが通ることを確認
- 問題があればユーザーに報告
 
- [x] 14. AWSデプロイ準備
- デプロイ用のドキュメントを作成
- S3バケット設定の手順を記載
- CloudFront設定の手順を記載
- _要件: 10.1, 10.3, 10.4_

出力の判定と修正

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

判定結果

修正必要

 

良かった点

  • 1枚ページで完結することやリスト形式でタスクが一覧化されることなど、最初に提示した要件は守られていた
  • 最初に手元のメモに書いたページとほとんど同じUIだった

問題点

  • 優先度が5（最高）・4（高）・3（中）・2（低）・1（最低）の5段階になった
    →わかりにくいのでシンプルさを求めて高・中・低に変更
  • ページングが隣のページにしか行けないようになっていた
    →任意のページが見られるようにしたい

Kiroとの対話

  • 優先度は高・中・低にして→リスト一覧は高・中・低になったものの、登録欄が5段階のままだった→「優先度は高・中・低の3段階で統一して」→修正◎
  • ページングで任意のページに遷移できるようにしたい
    →想定通りに修正◎

 

テスト実装

  • プロパティ1: タスク追加でリストが成長する要件 1.1 を検証 100回の反復テスト
  • プロパティ2: 空のタイトルは拒否される要件 1.3 を検証 100回の反復テスト
  • プロパティ3: ストレージラウンドトリップの一貫性要件 1.4, 2.3, 6.1 を検証 100回の反復テスト
  • test-priority-sort.html – プロパティ9: 優先度ソート不変性要件 4.1, 4.2, 4.3 を検証 100回の反復テスト

 

成果物

  • タスクの追加、Undo操作

 

  • タスクの編集、削除、Undo操作

 

所要時間

2時間30分

主な機能

  • タスクの追加: タイトル、担当者、期限、優先度を入力して新規タスクを作成
  • タスクの編集: 既存タスクの情報を更新
  • タスクの削除: 不要なタスクを削除
  • 優先度順ソート: タスクを優先度の高い順に自動表示
  • ページング: 20件ごとにページを分割して表示
  • シンプルなUI: タイトル、担当者、期限を一覧で確認
  • ローカルストレージ保存: ブラウザを閉じてもデータが残る
  • 即座の保存: 追加・編集・削除時に自動保存
  • Undo機能: 直前の操作を取り消し（最大10回分）
  • 高速動作: 100ミリ秒以内のUI更新、2秒以内の初期表示
  • 単一ページ完結: ページ遷移なしで全機能を利用可能

工夫点など

  • 要件定義時点でできるだけ細かく要件を詰めたこと

 

発見と学び

  • 細かく要件を指示したところはうまくアプリに取り込めた反面、ざっくり指示した部分はAIに解釈の余地を与えてしまい、修正が必要になりました。
  • 最初に想像図を書くことで、AIへ指示する際に言語化がしやすくなりました。
  • 自分の中で勝手に解釈してしまった部分があること（社内で使うならレスポンシブ対応いらないかも、とか）に後から気がついたので、そういった部分も最初に全て出しきって整理したほうが良かったかもしれません。

 

感想

良かった点

  • 最初に想像していた通りのアプリが作れた
  • 先日の失敗で学んだことを今回の企画で活かすことができた

苦労した点

  • ざっくりとした指示をすると、想像していた動作と異なる動きになってしまうことがあったこと
  • 途中から修正をしようとすると、ドキュメントへの反映が漏れてしまうことがあり、修正指示をしても後でまた修正がデグレードしてしまうことがあった

今後に活かせること

実務でも、最初に要件を詰める際にAIに質問事項を作成してもらうことで要件定義がスムーズに行えそうだと感じました。

また、テスト項目の作成やテストの実施を自動でやってくれるのは非常に便利なので活用していきたいと思いました。

 

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

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

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

シェアする
ツイートする
Twitter で

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

採用情報
2025-12-02

関連投稿

ページトップへ