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

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

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

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

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

 

自己紹介

クラウド開発事業部所属のtokitoです。
普段はプロジェクト推進、システム開発・運用保守を担当しています。エンジニア歴は8年で、主にLaravelや.NETを使った開発をしています。

趣味はサッカー観戦です。妻のご家族からの誘いを受けてサッカー観戦をするようになってから、徐々にハマっていき今年度は推しクラブのアウェイ遠征を全制覇しました。

 

普段使ってるAIツール

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

  • Gemini: Webで調べても直ぐに解決策がない場合やコーディングの参考として利用

 

企画概要とゴール

今回、「フル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への事前学習を行うことを指示されていたこと、また不明点も含めてKiroと対話しながら進めようと思ったためです。

 

Specs定義

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

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

Kiroに指示を出すうえで日本語での複雑な文章は齟齬が生まれるリスクが考えられたので簡潔な文字列で伝えること、指示の順序を整理すること、コーディングの形式に寄せるために段落（インデント）をいれて箇条書きにすることを意識しました。

Kiroへの指示

最初の指示

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

追加要件指示

1
2
追加要件
・誤ってタスクを完了した場合、元に戻せるようにして欲しい。

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
# 要件定義書
 
## はじめに
 
本システムは、多機能な管理ツールに疲れた社員のための軽量なタスク管理ツールです。今日やるべきタスクをシンプルに管理でき、1ページで完結する直感的な操作性を提供します。データは永続化され、ブラウザを閉じても保持されます。
 
## 用語集
 
- **システム**: 軽量タスク管理ツール
- **タスク**: ユーザーが管理する作業項目（タイトル、担当者、期限を含む）
- **タスクリスト**: システムに登録されているすべてのタスクの一覧
- **フォーム**: タスクを追加・編集するための入力インターフェース
- **永続化ストレージ**: ブラウザのローカルストレージまたはバックエンドデータベース
 
## 要件
 
### 要件 1
 
**ユーザーストーリー:** ユーザーとして、新しいタスクを追加したい。そうすることで、今日やるべき作業を記録できる。
 
#### 受入基準
 
1. WHEN ユーザーが画面上部のフォームにタスクのタイトル、担当者、期限を入力し送信ボタンをクリックする THEN システムは新しいタスクを作成しタスクリストに追加する
2. WHEN ユーザーがタスクを追加する THEN システムはフォームの入力フィールドをクリアし次の入力に備える
3. WHEN ユーザーが空のタイトルでタスクを追加しようとする THEN システムは追加を拒否し現在の状態を維持する
4. WHEN タスクが追加される THEN システムは即座にタスクを永続化ストレージに保存する
5. WHEN タスクが追加される THEN システムはタスクリストに新しいタスクを表示する
 
### 要件 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. WHEN ユーザーがシステムにアクセスする THEN システムはすべてのタスクをタスクリストに表示する
2. WHEN タスクが表示される THEN システムは各タスクのタイトル、担当者、期限を表示する
3. WHEN タスクが表示される THEN システムは各タスクの行に編集ボタンと削除ボタンを表示する
 
### 要件 5
 
**ユーザーストーリー:** ユーザーとして、ブラウザを閉じてもデータが保持されることを期待する。そうすることで、作業を中断しても情報が失われない。
 
#### 受入基準
 
1. WHEN ユーザーがブラウザを閉じる THEN システムはすべてのタスクデータを永続化ストレージに保持する
2. WHEN ユーザーが再度システムにアクセスする THEN システムは永続化ストレージから保存されたタスクを読み込み表示する
3. WHEN データが永続化される THEN システムはデータの整合性を保証する
 
### 要件 6
 
**ユーザーストーリー:** ユーザーとして、1ページで完結する直感的な操作を期待する。そうすることで、ストレスなくタスクを管理できる。
 
#### 受入基準
 
1. システムはすべての機能を単一のページで提供する
2. WHEN ユーザーが操作を実行する THEN システムは即座に応答しページ遷移を発生させない
3. WHEN ユーザーがインターフェースを操作する THEN システムは直感的で分かりやすいUIを提供する
4. システムは軽量で高速に動作する
 
### 要件 7
 
**ユーザーストーリー:** ユーザーとして、タスクを完了済みとしてマークしたい。そうすることで、進捗状況を把握できる。
 
#### 受入基準
 
1. WHEN ユーザーがタスクの完了ボタンをクリックする THEN システムはそのタスクを完了済みとしてマークする
2. WHEN タスクが完了済みとしてマークされる THEN システムは視覚的にタスクの状態を区別して表示する
3. WHEN ユーザーが完了済みタスクの完了ボタンを再度クリックする THEN システムはそのタスクを未完了状態に戻す
4. WHEN タスクの完了状態が変更される THEN システムは即座に永続化ストレージに保存する
 
### 要件 8
 
**ユーザーストーリー:** ユーザーとして、誤った操作を元に戻したい。そうすることで、ミスを簡単に修正できる。
 
#### 受入基準
 
1. WHEN ユーザーがタスクを削除する THEN システムは削除操作を履歴に記録する
2. WHEN ユーザーがタスクを完了済みにする THEN システムは完了操作を履歴に記録する
3. WHEN ユーザーが元に戻すボタンをクリックする THEN システムは最後の操作を取り消し以前の状態に戻す
4. WHEN 元に戻す操作が実行される THEN システムは変更を永続化ストレージに保存する
5. WHEN 元に戻せる操作がない場合 THEN システムは元に戻すボタンを無効化する
 
### 要件 9
 
**ユーザーストーリー:** 開発者として、E2Eテストが通っていることを確認したい。そうすることで、システムの品質を保証できる。
 
#### 受入基準
 
1. WHEN E2Eテストが実行される THEN システムはPlaywright MCPを使用してテストを実行する
2. WHEN E2Eテストが実行される THEN システムはタスクの追加、編集、削除、一覧表示の機能をテストする
3. WHEN E2Eテストが実行される THEN システムはデータの永続化をテストする
4. システムはすべてのE2Eテストに合格する

 

  • 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
# 設計書
 
## 概要
 
軽量タスク管理ツールは、シンプルで直感的なシングルページアプリケーション（SPA）として実装されます。フロントエンドはReactを使用し、データの永続化にはブラウザのLocalStorageを使用します。AWS（Sandbox環境）へのデプロイには、S3 + CloudFrontの静的ホスティングを使用します。
 
## アーキテクチャ
 
### 技術スタック
 
- **フロントエンド**: React + TypeScript
- **ビルドツール**: Vite
- **スタイリング**: CSS Modules または Tailwind CSS
- **データ永続化**: Browser LocalStorage
- **テスティング**: Vitest（ユニットテスト）、Playwright（E2Eテスト）
- **プロパティベーステスト**: fast-check
- **デプロイ**: AWS S3 + CloudFront
 
### アーキテクチャパターン
 
シンプルなクライアントサイドアーキテクチャを採用：
 
```
┌─────────────────────────────────────┐
│         React Components            │
│  ┌──────────┐  ┌─────────────────┐ │
│  │ TaskForm │  │   TaskList      │ │
│  └──────────┘  └─────────────────┘ │
│         │              │            │
│         └──────┬───────┘            │
│                │                    │
│         ┌──────▼──────┐             │
│         │ Task Store  │             │
│         └──────┬──────┘             │
│                │                    │
│         ┌──────▼──────┐             │
│         │LocalStorage │             │
│         └─────────────┘             │
└─────────────────────────────────────┘
```
 
## コンポーネントとインターフェース
 
### データモデル
 
#### Task
 
```typescript
interface Task {
  id: string;          // 一意識別子（UUID）
  title: string;       // タスクのタイトル
  assignee: string;    // 担当者名
  dueDate: string;     // 期限（ISO 8601形式）
  completed: boolean;  // 完了状態
  createdAt: string;   // 作成日時（ISO 8601形式）
  updatedAt: string;   // 更新日時（ISO 8601形式）
}
```
 
#### UndoAction
 
```typescript
interface UndoAction {
  type: 'delete' | 'complete' | 'uncomplete';
  task: Task;
  timestamp: string;
}
```
 
### コンポーネント構成
 
#### App
 
ルートコンポーネント。全体のレイアウトとタスク状態を管理。
 
```typescript
interface AppProps {}
interface AppState {
  tasks: Task[];
  editingTaskId: string | null;
  undoStack: UndoAction[];
}
```
 
#### TaskForm
 
タスクの追加・編集フォーム。
 
```typescript
interface TaskFormProps {
  onSubmit: (task: Omit<Task, 'id' | 'createdAt' | 'updatedAt'>) => void;
  initialValues?: Task;
  onCancel?: () => void;
}
```
 
#### TaskList
 
タスクの一覧表示。
 
```typescript
interface TaskListProps {
  tasks: Task[];
  onEdit: (taskId: string) => void;
  onDelete: (taskId: string) => void;
}
```
 
#### TaskItem
 
個別のタスク行。
 
```typescript
interface TaskItemProps {
  task: Task;
  onEdit: () => void;
  onDelete: () => void;
  onToggleComplete: () => void;
  isEditing: boolean;
  onSave: (task: Task) => void;
  onCancel: () => void;
}
```
 
#### UndoButton
 
元に戻すボタンコンポーネント。
 
```typescript
interface UndoButtonProps {
  onUndo: () => void;
  disabled: boolean;
}
```
 
### ストレージインターフェース
 
#### TaskStorage
 
LocalStorageとのやり取りを抽象化。
 
```typescript
interface TaskStorage {
  getTasks(): Task[];
  saveTasks(tasks: Task[]): void;
  addTask(task: Task): void;
  updateTask(task: Task): void;
  deleteTask(taskId: string): void;
  getUndoStack(): UndoAction[];
  saveUndoStack(actions: UndoAction[]): void;
}
```
 
## データモデル
 
### Task
 
タスクは以下の属性を持ちます：
 
- **id**: UUID v4形式の一意識別子
- **title**: 必須、1文字以上の文字列
- **assignee**: 必須、1文字以上の文字列
- **dueDate**: ISO 8601形式の日付文字列
- **completed**: 完了状態を示すブール値
- **createdAt**: タスク作成時のタイムスタンプ
- **updatedAt**: タスク更新時のタイムスタンプ
 
### UndoAction
 
元に戻す操作は以下の属性を持ちます：
 
- **type**: 操作の種類（'delete', 'complete', 'uncomplete'）
- **task**: 操作対象のタスク
- **timestamp**: 操作実行時のタイムスタンプ
 
### LocalStorageスキーマ
 
```json
{
  "tasks": [
    {
      "id": "uuid",
      "title": "string",
      "assignee": "string",
      "dueDate": "ISO 8601 string",
      "completed": boolean,
      "createdAt": "ISO 8601 string",
      "updatedAt": "ISO 8601 string"
    }
  ],
  "undoStack": [
    {
      "type": "delete | complete | uncomplete",
      "task": { /* Task object */ },
      "timestamp": "ISO 8601 string"
    }
  ]
}
```
 
 
## 正確性プロパティ
 
*プロパティとは、システムのすべての有効な実行において真であるべき特性または動作です。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性保証との橋渡しとなります。*
 
### プロパティ1: タスク追加によるリスト拡張
 
*任意の*タスクリストと有効な（空でない）タスクデータに対して、タスクを追加するとタスクリストの長さが1増加し、追加したタスクがリストに含まれる
**検証対象: 要件 1.1, 1.5**
 
### プロパティ2: フォームクリア
 
*任意の*UI状態において、タスクを送信した後、入力フォームのすべてのフィールドが空になる
**検証対象: 要件 1.2**
 
### プロパティ3: 無効なタイトルの拒否
 
*任意の*空白文字のみで構成される文字列に対して、それをタイトルとしてタスクを追加しようとすると拒否され、タスクリストは変更されない
**検証対象: 要件 1.3**
 
### プロパティ4: 永続化ラウンドトリップ
 
*任意の*タスクリストに対して、LocalStorageに保存してから読み込むと、元のタスクリストと同等のデータが得られる
**検証対象: 要件 1.4, 5.1, 5.2, 5.3**
 
### プロパティ5: 編集モード遷移
 
*任意の*タスクに対して、編集ボタンをクリックすると、そのタスクが編集可能な状態になる
**検証対象: 要件 2.1**
 
### プロパティ6: 編集の永続化
 
*任意の*タスクと変更内容に対して、タスクを編集して保存すると、LocalStorageに更新された内容が保存される
**検証対象: 要件 2.2**
 
### プロパティ7: 編集の即時反映
 
*任意の*タスクに対して、編集して保存すると、タスクリストに更新された情報が即座に表示される
**検証対象: 要件 2.3**
 
### プロパティ8: 編集キャンセルによる復元
 
*任意の*タスクに対して、編集を開始してからキャンセルすると、タスクは元の状態に戻る
**検証対象: 要件 2.4**
 
### プロパティ9: 削除によるリスト縮小
 
*任意の*タスクリストとその中のタスクに対して、タスクを削除するとタスクリストの長さが1減少し、削除したタスクはリストに含まれなくなり、LocalStorageからも削除される
**検証対象: 要件 3.1, 3.2, 3.3**
 
### プロパティ10: タスク表示の完全性
 
*任意の*タスクに対して、レンダリングされた表示にはタイトル、担当者、期限が含まれる
**検証対象: 要件 4.2**
 
### プロパティ11: 操作ボタンの存在
 
*任意の*タスクに対して、レンダリングされた行には編集ボタンと削除ボタンが含まれる
**検証対象: 要件 4.3**
 
### プロパティ12: 完了状態のトグル
 
*任意の*タスクに対して、完了ボタンをクリックするとタスクの完了状態が反転する（未完了→完了、完了→未完了）
**検証対象: 要件 7.1, 7.3**
 
### プロパティ13: 完了状態の視覚的区別
 
*任意の*完了済みタスクに対して、レンダリングされた表示には完了状態を示す視覚的な区別（CSSクラスやスタイル）が含まれる
**検証対象: 要件 7.2**
 
### プロパティ14: 操作履歴の記録
 
*任意の*タスクに対して、削除操作または完了状態の変更を実行すると、undoStackに操作が記録される
**検証対象: 要件 8.1, 8.2**
 
### プロパティ15: 元に戻す操作のラウンドトリップ
 
*任意の*タスクリストと操作（削除または完了）に対して、操作を実行してから元に戻すと、元のタスクリストの状態に戻る
**検証対象: 要件 8.3, 8.4**
 
## エラーハンドリング
 
### 入力検証エラー
 
- 空のタイトル: ユーザーにエラーメッセージを表示し、タスクの追加を防ぐ
- 無効な日付形式: 日付入力フィールドのHTML5バリデーションを使用
 
### ストレージエラー
 
- LocalStorage容量超過: ユーザーにエラーメッセージを表示し、古いタスクの削除を促す
- LocalStorage読み込みエラー: 空のタスクリストで初期化し、エラーをコンソールに記録
- UndoStack容量制限: 最大10件の操作履歴を保持し、古い履歴から削除
 
### 一般的なエラー
 
- すべてのエラーは適切にキャッチされ、ユーザーフレンドリーなメッセージとして表示される
- エラーが発生してもアプリケーションがクラッシュしないようにする
 
## テスト戦略
 
### ユニットテスト
 
Vitestを使用して以下のユニットテストを実装：
 
- **TaskStorageモジュール**: LocalStorageの読み書き操作
- **バリデーション関数**: タスクデータの検証ロジック
- **ユーティリティ関数**: 日付フォーマット、UUID生成など
 
### プロパティベーステスト
 
fast-checkライブラリを使用してプロパティベーステストを実装：
 
- 各プロパティベーステストは最低100回の反復を実行する
- 各テストは設計書の正確性プロパティを明示的に参照する
- タグ形式: `**Feature: lightweight-task-manager, Property {番号}: {プロパティテキスト}**`
- 各正確性プロパティは単一のプロパティベーステストで実装される
 
**テスト対象プロパティ:**
- プロパティ1-15（上記の正確性プロパティセクションを参照）
 
### E2Eテスト
 
Playwright MCPを使用してE2Eテストを実装：
 
- タスクの追加フロー
- タスクの編集フロー
- タスクの削除フロー
- タスクの完了/未完了の切り替えフロー
- 元に戻す操作のフロー
- データの永続化（ページリロード後の確認）
- すべての操作が単一ページ内で完結することの確認
 
### テストカバレッジ目標
 
- ユニットテスト: 80%以上のコードカバレッジ
- プロパティベーステスト: すべての正確性プロパティをカバー
- E2Eテスト: すべての主要なユーザーフローをカバー
 
## デプロイメント
 
### AWS構成
 
- **S3バケット**: 静的ファイルのホスティング
- **CloudFront**: CDN配信とHTTPS対応
- **ビルド**: `npm run build`でViteが最適化されたプロダクションビルドを生成
 
### デプロイ手順
 
1. `npm run build`でプロダクションビルドを作成
2. `dist/`ディレクトリの内容をS3バケットにアップロード
3. CloudFrontのキャッシュを無効化
4. デプロイされたURLで動作確認
 
### 環境変数
 
このアプリケーションはバックエンドを持たないため、環境変数は不要です。

 

  • 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
# 実装計画
 
- [x] 1. プロジェクト構造とコア型定義のセットアップ
 
  - Vite + React + TypeScriptプロジェクトを初期化
  - TaskインターフェースとUndoActionインターフェースを含む型定義を作成
  - 基本的なプロジェクト構造（components、utils、typesディレクトリ）を構築
  - _要件: 1.1, 2.1, 3.1, 4.1, 7.1, 8.1_
 
- [x] 2. LocalStorageストレージ層の実装
 
  - TaskStorageインターフェースを定義
  - LocalStorageの読み書き操作を実装（getTasks、saveTasks、addTask、updateTask、deleteTask、getUndoStack、saveUndoStack）
  - データのシリアライゼーション/デシリアライゼーションロジックを実装
  - UndoStack容量制限（最大10件）を実装
  - _要件: 1.4, 2.2, 3.2, 5.1, 5.2, 5.3, 7.4, 8.4_
 
- [ ]* 2.1 TaskStorageのユニットテストを作成
  - LocalStorage操作のモックを使用したテスト
  - CRUD操作の正確性を検証
  - UndoStack操作の正確性を検証
  - _要件: 1.4, 2.2, 3.2, 5.1, 5.2, 5.3, 7.4, 8.4_
 
- [ ]* 2.2 プロパティテスト: 永続化ラウンドトリップ
  - **Property 4: 永続化ラウンドトリップ**
  - **検証対象: 要件 1.4, 5.1, 5.2, 5.3**
 
- [x] 3. バリデーションとユーティリティ関数の実装
 
 
  - タスクタイトルのバリデーション関数を実装（空白チェック）
  - UUID生成関数を実装
  - 日付フォーマット関数を実装
  - _要件: 1.3_
 
- [ ]* 3.1 バリデーション関数のユニットテストを作成
  - 有効/無効な入力のテストケース
  - エッジケース（空文字列、空白のみ、null、undefined）
  - _要件: 1.3_
 
- [ ]* 3.2 プロパティテスト: 無効なタイトルの拒否
  - **Property 3: 無効なタイトルの拒否**
  - **検証対象: 要件 1.3**
 
- [x] 4. TaskFormコンポーネントの実装
 
 
  - フォームUIを作成（タイトル、担当者、期限の入力フィールド）
  - フォーム送信ハンドラーを実装
  - フォームバリデーションを統合
  - 送信後のフォームクリア機能を実装
  - _要件: 1.1, 1.2, 1.3_
 
- [ ]* 4.1 プロパティテスト: フォームクリア
  - **Property 2: フォームクリア**
  - **検証対象: 要件 1.2**
 
- [x] 5. TaskItemコンポーネントの実装
 
 
  - タスク表示UIを作成（タイトル、担当者、期限を表示）
  - 完了ボタン、編集ボタン、削除ボタンを追加
  - 完了状態の視覚的区別（CSSクラス/スタイル）を実装
  - インライン編集モードを実装
  - 編集キャンセル機能を実装
  - _要件: 2.1, 2.4, 3.1, 4.2, 4.3, 7.1, 7.2_
 
- [ ]* 5.1 プロパティテスト: タスク表示の完全性
  - **Property 10: タスク表示の完全性**
  - **検証対象: 要件 4.2**
 
- [ ]* 5.2 プロパティテスト: 操作ボタンの存在
  - **Property 11: 操作ボタンの存在**
  - **検証対象: 要件 4.3**
 
- [ ]* 5.3 プロパティテスト: 編集キャンセルによる復元
  - **Property 8: 編集キャンセルによる復元**
  - **検証対象: 要件 2.4**
 
- [ ]* 5.4 プロパティテスト: 完了状態のトグル
  - **Property 12: 完了状態のトグル**
  - **検証対象: 要件 7.1, 7.3**
 
- [ ]* 5.5 プロパティテスト: 完了状態の視覚的区別
  - **Property 13: 完了状態の視覚的区別**
  - **検証対象: 要件 7.2**
 
- [x] 6. TaskListコンポーネントの実装
 
 
  - タスクリストUIを作成
  - タスクの一覧表示を実装
  - 編集/削除イベントハンドラーを統合
  - _要件: 4.1, 4.2, 4.3_
 
- [x] 7. UndoButtonコンポーネントの実装
 
 
  - 元に戻すボタンUIを作成
  - undoStackが空の場合はボタンを無効化
  - 元に戻す操作のハンドラーを実装
  - _要件: 8.3, 8.5_
 
- [x] 8. Appコンポーネントの実装と状態管理
 
 
  - タスク状態管理を実装（useState）
  - UndoStack状態管理を実装（useState）
  - TaskStorageとの統合
  - タスクの追加/編集/削除/完了切り替えロジックを実装
  - 元に戻すロジックを実装
  - 初期データ読み込みを実装（useEffect）
  - _要件: 1.1, 1.4, 1.5, 2.2, 2.3, 3.2, 3.3, 5.2, 7.1, 7.3, 7.4, 8.1, 8.2, 8.3, 8.4_
 
- [ ]* 8.1 プロパティテスト: タスク追加によるリスト拡張
  - **Property 1: タスク追加によるリスト拡張**
  - **検証対象: 要件 1.1, 1.5**
 
- [ ]* 8.2 プロパティテスト: 編集モード遷移
  - **Property 5: 編集モード遷移**
  - **検証対象: 要件 2.1**
 
- [ ]* 8.3 プロパティテスト: 編集の永続化
  - **Property 6: 編集の永続化**
  - **検証対象: 要件 2.2**
 
- [ ]* 8.4 プロパティテスト: 編集の即時反映
  - **Property 7: 編集の即時反映**
  - **検証対象: 要件 2.3**
 
- [ ]* 8.5 プロパティテスト: 削除によるリスト縮小
  - **Property 9: 削除によるリスト縮小**
  - **検証対象: 要件 3.1, 3.2, 3.3**
 
- [ ]* 8.6 プロパティテスト: 操作履歴の記録
  - **Property 14: 操作履歴の記録**
  - **検証対象: 要件 8.1, 8.2**
 
- [ ]* 8.7 プロパティテスト: 元に戻す操作のラウンドトリップ
  - **Property 15: 元に戻す操作のラウンドトリップ**
  - **検証対象: 要件 8.3, 8.4**
 
- [x] 9. スタイリングとUI/UXの改善
 
 
  - CSS ModulesまたはTailwind CSSでスタイリングを実装
  - レスポンシブデザインを適用
  - 直感的で分かりやすいUIを実現
  - _要件: 6.1, 6.3_
 
- [x] 10. チェックポイント - すべてのテストが通ることを確認
 
 
 
  - すべてのテストが通ることを確認し、問題があればユーザーに質問する
 
- [x] 11. E2Eテストの実装（Playwright MCP）
 
 
  - Playwright設定ファイルを作成
  - タスク追加フローのE2Eテストを実装
  - タスク編集フローのE2Eテストを実装
  - タスク削除フローのE2Eテストを実装
  - タスク完了/未完了切り替えフローのE2Eテストを実装
  - 元に戻す操作フローのE2Eテストを実装
  - データ永続化のE2Eテスト（ページリロード）を実装
  - _要件: 9.1, 9.2, 9.3, 9.4_
 
- [x] 12. AWSデプロイ設定
 
 
  - ビルドスクリプトを設定
  - S3バケット設定用のドキュメントを作成
  - CloudFront設定用のドキュメントを作成
  - デプロイ手順書を作成
  - _要件: すべて（デプロイメント）_
 
- [x] 13. 最終チェックポイント - すべてのテストが通ることを確認
 
 
 
  - すべてのテストが通ることを確認し、問題があればユーザーに質問する

出力の判定と修正

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

判定結果

修正必要

 

良かった点

  • 指示で記載した点については画面のレイアウトや基本的な機能など踏襲されていた。
  • バリデーションチェックについて、必須チェックや追加で実装が必要なチェックなど表記されていて利用者が指定していな部分のAIからの提案が見られた。

問題点

  • タイトルやサブタイトルについて、明記していなかったのでAIで補完した名称となっていた。
  • デプロイ時のコマンドについて、bash向けになっていた。

Kiroとの対話

  • タイトル修正
    タイトル名やサブタイトルの修正のため以下のプロンプトを実行。サイトのタイトル名を含めて想定通りの修正を行ってくれた。

1
2
3
タイトルを「軽量タスク管理」ではなく「タスク管理」に変更。
 
サブタイトル「今日やるべきタスクをシンプルに管理」を「残タスクをシンプルに管理」に変更してください。

 

  • デプロイ時のコマンド修正
    Kiroに以下のプロンプト実行

1
2
3
コマンド「
npm run deploy your-bucket-name your-distribution-id
」の実行

Kiroによるデプロイ実行時に自動でshellscript向けのコマンドへ修正を行ってくれた。

 

テスト実装

E2Eテストの実装（Playwright MCP）にて作成されたテストは以下の通り。
データ保持の際に不具合が見つかったがKiro側で修正を行い再テストを実行した。最終的にはすべてのテストが成功し完了した。
テスト1: タスク追加フロー
テスト2: タスク完了/未完了切り替えフロー
テスト3: 元に戻す操作フロー
テスト4: タスク編集フロー
テスト5: タスク削除フロー
テスト6: 削除後の元に戻す操作
テスト7: データ永続化（ページリロード）

 

成果物

[スクリーンショット]


所要時間

120分

主な機能

  • タスクの一覧表示
  • タスクの追加
  • タスクの編集
  • タスクの削除
  • タスクの完了/未完了切り替え
  • 誤って削除したタスクを元に戻す
  • タスクのデータを保持

工夫点など

  • Kiroに簡潔な文章、形式で指示を与えるように指示の仕方を整理
  • プロンプトの入力のみでどこまでの作業をやってくれるのかタスクの実行やデプロイに至るまで全工程をKiroに実行させて基本的にYesかNoだけを選択するだけにプロンプトを組んだ。

 

発見と学び

タスクの進捗を確認するプロンプトを打った時に伝え方が悪かったのかタスクの一覧が答えとして返ってくることがあった。
どんな指示を与えるのか、どんな言葉を利用するのか考える必要があると思いました。

 

感想

良かった点

利用するAIによって変わってくる部分もあると思うが、全くコーディングをせずに実装からデプロイに至るまで実行できたので、手間暇なく一つのシステムを組めたので、現時点でここまで楽になったことを知ることが出来てよかったです。

他にも追加要件が与えられた際に自動で要件や設計部分に反映されるので、資料の反映に対する漏れは無くせると思いました。

苦労した点

Kiro自体を初めて使ったのでタスクの実行をどうするのか、どうしたら完了となるのか不明だったが、タスクの実行も含めてKiroにプロンプトを与えて実行してもらうことで楽に開発を行えた。

不明瞭な点が多いと補完できる範囲を超えてしまうことがあるので、初めの要件を如何に明確にできるかが重要だと思いました。

今後に活かせること

実務においてはプロトタイプの開発において、効果を発揮しやすいと思います。テストの実行も自動で行ってくれるため、少し修正して繰り返しテストを行う場面が多いときなどテスト実行のコストを大きく削減することが可能です。

 

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

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

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

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

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

採用情報
2025-12-05

関連投稿

ページトップへ