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

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

フルAI開発バトル参加レポート

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

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

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

自己紹介

クラウド開発事業部所属のmatsuraです。
普段は 受託開発案件のPJリーダーやSylphinaのテックリードを担当しています。エンジニア歴は 4年で、主に AWS/Amazon Connect/Reactを使った開発をしています。

普段使ってるAIツール

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

  • Cursor
  • Chat GPT Pro

Chat GPT Proはかなり調査系タスクで役に立ちます。

参照したURLを必ず表示してくれるのでハルシネーションリスクも初期のAIよりも減り責任あるAIとしての姿を感じます。

Cursorに関してはKiroよりも先発の古いAIエディタではあるのですが、使い勝手がよく重宝してました。

Claude Codeに乗り換えようとしていたんですがあまりコードを書く機会が減ってしまったためそのまま今まで来ました・・・・・・AIはまだまだ黎明期なのかどんどん新しいのが出てきますね

企画概要とゴール

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

作業プロセス

要件の理解と整理

まずは要件を整理します。
方向性としてはシンプルなToDoアプリを作れば良いということがわかったので、ミニマムに作ろうと思いました。

運営への質問事項

Vive コーディングの経験もあったので私の今のAI駆動開発の実力を試すいい機会だと思い運営へは質問しませんでした。

Specs定義

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

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

私はまず、上記のお題と必須要件をプロンプトに記載した後最後に

「曖昧な要件だと思うので私に判断を仰ぎたい部分は必ず私に質問してください」

という一文を付け加えました。

これまでのViveコーディングの経験上曖昧な要件でもコーディングしてくれることはわかっていたのですが、判断できない部分も何となくこうだろうで突き進んでしまうため手戻りが生じる場合もありました。

なのでこのようなAIが判断できないことを私に質問させることでより私の頭の中の通り実装してくれるのでこの質問させるという手法は Vive コーディングをする上で必須テクニックだと思ってます。

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
ある日、現場リーダー佐藤さんからSlackでふわっとした依頼がきました。
 
「
お疲れ〜!
多機能な管理ツールに疲れた社員のために、
今日やるべきことだけを管理できる軽量なツールが欲しいんだよね。
一応要件も書いたから、それに沿っていい感じに作ってほしい!
完成したらAWS(自分のSandbox環境)にデプロイしておいて〜!
」
 
**機能要件:**
 
- タスクの追加(画面上部のフォームからテキスト入力)、編集、削除、一覧表示(タイトル、担当者、期限を表示)
- ログイン機能は不要
- 操作性
- 画面は1ページで完結。サクサク軽く動いて、直感的に操作できること
- 編集・削除は各行のボタンで可能
- データ保持
- ブラウザを閉じてもデータが消えないこと
- 品質保証
- Playwright MCPを活用し、E2Eテストが通っていること
 
この要件を満たすシステムを開発したいと思います。
 
曖昧な要件だと思うので私に判断を仰ぎたい部分は必ず私に質問してください
 
あなたから私への質問は必ず日本語でお願いします
 

その後Kiroはいくつかの技術選択、アプリのUI/UXに関していくつかの質問をした後以下の出力を返しました

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
139
140
141
142
143
# 要件定義書
 
## はじめに
 
本システムは、多機能な管理ツールに疲れた社員のために、今日やるべきことだけを管理できる軽量なタスク管理ツールです。シンプルで直感的な操作性を重視し、1ページで完結する使いやすいインターフェースを提供します。
 
## 用語集
 
- **システム**: 軽量タスク管理ツール
- **タスク**: ユーザーが管理する作業項目（タイトル、担当者、期限、優先度、ステータス、説明文を含む）
- **LocalStorage**: ブラウザのローカルストレージ機能
- **モーダル**: タスク編集用のポップアップウィンドウ
- **日付ピッカー**: 日付選択用のUIコンポーネント
- **ソート**: データの並び替え機能
 
## 要件
 
### 要件1: タスクの追加
 
**ユーザーストーリー:** ユーザーとして、新しいタスクを追加したいので、画面上部のフォームから必要な情報を入力できるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがタスクフォームにタイトルを入力し追加ボタンをクリックする THEN システムは新しいタスクを作成しタスク一覧に表示する
2. WHEN ユーザーが空のタイトルでタスクを追加しようとする THEN システムは追加を拒否しエラーメッセージを表示する
3. WHEN タスクが追加される THEN システムはフォームの入力欄をクリアし次の入力に備える
4. WHEN タスクが追加される THEN システムは即座にLocalStorageにデータを保存する
5. WHEN ユーザーがタスクフォームで期限を入力する THEN システムは日付ピッカーを表示し日付選択を可能にする
 
### 要件2: タスクの表示
 
**ユーザーストーリー:** ユーザーとして、登録したタスクの一覧を確認したいので、タイトル、担当者、期限、優先度、ステータスが表示されるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがシステムにアクセスする THEN システムはLocalStorageから全てのタスクを読み込み一覧表示する
2. WHEN タスクが表示される THEN システムは各タスクのタイトル、担当者、期限、優先度、ステータスを表示する
3. WHEN LocalStorageにデータが存在しない THEN システムは空の状態を適切に表示する
4. WHEN ブラウザを閉じて再度開く THEN システムは以前保存したタスクデータを保持し表示する
 
### 要件3: タスクの編集
 
**ユーザーストーリー:** ユーザーとして、既存のタスク情報を修正したいので、各タスク行の編集ボタンからモーダルで編集できるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがタスク行の編集ボタンをクリックする THEN システムは編集モーダルを表示し現在のタスク情報を入力欄に表示する
2. WHEN ユーザーがモーダルでタスク情報を変更し保存ボタンをクリックする THEN システムはタスクを更新しモーダルを閉じる
3. WHEN タスクが更新される THEN システムは即座にLocalStorageに変更を保存する
4. WHEN ユーザーがモーダルでキャンセルボタンをクリックする THEN システムは変更を破棄しモーダルを閉じる
5. WHEN ユーザーがモーダルでタイトルを空にして保存しようとする THEN システムは保存を拒否しエラーメッセージを表示する
 
### 要件4: タスクの削除
 
**ユーザーストーリー:** ユーザーとして、不要になったタスクを削除したいので、各タスク行の削除ボタンから削除できるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがタスク行の削除ボタンをクリックする THEN システムは確認ダイアログを表示する
2. WHEN ユーザーが削除を確認する THEN システムはタスクを一覧から削除しLocalStorageから削除する
3. WHEN ユーザーが削除をキャンセルする THEN システムはタスクを保持し何も変更しない
4. WHEN タスクが削除される THEN システムは即座に画面を更新し削除されたタスクを非表示にする
 
### 要件5: タスクの完了管理
 
**ユーザーストーリー:** ユーザーとして、完了したタスクをマークしたいので、チェックボックスで完了状態を切り替えられるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがタスクの完了チェックボックスをクリックする THEN システムはタスクのステータスを完了に変更する
2. WHEN タスクが完了状態になる THEN システムは視覚的に完了を示す表示を行う
3. WHEN ユーザーが完了済みタスクのチェックボックスを再度クリックする THEN システムはタスクを未完了状態に戻す
4. WHEN タスクの完了状態が変更される THEN システムは即座にLocalStorageに変更を保存する
 
### 要件6: タスクのソート機能
 
**ユーザーストーリー:** ユーザーとして、タスクを見やすく整理したいので、各項目でソートできるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがタイトル列のヘッダーをクリックする THEN システムはタスクをタイトルの昇順または降順でソートする
2. WHEN ユーザーが担当者列のヘッダーをクリックする THEN システムはタスクを担当者名の昇順または降順でソートする
3. WHEN ユーザーが期限列のヘッダーをクリックする THEN システムはタスクを期限の昇順または降順でソートする
4. WHEN ユーザーが優先度列のヘッダーをクリックする THEN システムはタスクを優先度の昇順または降順でソートする
5. WHEN ユーザーがステータス列のヘッダーをクリックする THEN システムはタスクをステータスの昇順または降順でソートする
6. WHEN ユーザーが同じ列のヘッダーを再度クリックする THEN システムはソート順を反転する
 
### 要件7: シングルページアプリケーション
 
**ユーザーストーリー:** ユーザーとして、快適に操作したいので、画面遷移なく1ページで全ての操作を完結できるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがシステムにアクセスする THEN システムは単一のページで全ての機能を提供する
2. WHEN ユーザーが任意の操作を行う THEN システムはページリロードなしで即座に反応する
3. WHEN ユーザーがタスクを追加、編集、削除する THEN システムはページ遷移なしで操作を完了する
 
### 要件8: レスポンシブデザイン
 
**ユーザーストーリー:** ユーザーとして、様々なデバイスで使用したいので、画面サイズに応じて適切に表示されるようにしてほしい
 
#### 受入基準
 
1. WHEN ユーザーがモバイルデバイスでアクセスする THEN システムはモバイル画面に最適化されたレイアウトを表示する
2. WHEN ユーザーがタブレットでアクセスする THEN システムはタブレット画面に最適化されたレイアウトを表示する
3. WHEN ユーザーがデスクトップでアクセスする THEN システムはデスクトップ画面に最適化されたレイアウトを表示する
4. WHEN 画面サイズが変更される THEN システムは自動的にレイアウトを調整する
 
### 要件9: データの永続化
 
**ユーザーストーリー:** ユーザーとして、データを失いたくないので、ブラウザを閉じてもタスクデータが保持されるようにしてほしい
 
#### 受入基準
 
1. WHEN タスクが追加、編集、削除される THEN システムは即座にLocalStorageにデータを保存する
2. WHEN ユーザーがブラウザを閉じて再度開く THEN システムは以前のタスクデータを復元し表示する
3. WHEN LocalStorageへの保存が失敗する THEN システムはエラーメッセージを表示しユーザーに通知する
4. WHEN システムがLocalStorageからデータを読み込む THEN システムはデータの整合性を検証する
 
### 要件10: E2Eテストによる品質保証
 
**ユーザーストーリー:** 開発者として、システムの品質を保証したいので、Playwright MCPを活用したE2Eテストが実装され全て通過するようにしてほしい
 
#### 受入基準
 
1. WHEN E2Eテストが実行される THEN システムはタスクの追加機能が正しく動作することを検証する
2. WHEN E2Eテストが実行される THEN システムはタスクの編集機能が正しく動作することを検証する
3. WHEN E2Eテストが実行される THEN システムはタスクの削除機能が正しく動作することを検証する
4. WHEN E2Eテストが実行される THEN システムはタスクの完了チェック機能が正しく動作することを検証する
5. WHEN E2Eテストが実行される THEN システムはソート機能が正しく動作することを検証する
6. WHEN E2Eテストが実行される THEN システムはデータの永続化が正しく動作することを検証する
7. WHEN 全てのE2Eテストが実行される THEN システムは全てのテストが成功することを保証する
 
### 要件11: AWSへのデプロイ
 
**ユーザーストーリー:** 開発者として、システムを本番環境で動作させたいので、AWS Amplify Gen2を使用してデプロイできるようにしてほしい
 
#### 受入基準
 
1. WHEN システムがビルドされる THEN システムはAmplify Gen2の設定に従って正しくビルドされる
2. WHEN システムがデプロイされる THEN システムはAWS Amplifyを通じて公開される
3. WHEN デプロイが完了する THEN システムは公開URLからアクセス可能になる
4. WHEN デプロイされたシステムにアクセスする THEN システムは全ての機能が正常に動作する

 

  • 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
# 設計書
 
## 概要
 
軽量タスク管理ツールは、React + TypeScript + TailwindCSSで構築されるシングルページアプリケーションです。LocalStorageを使用してデータを永続化し、AWS Amplify Gen2を通じてデプロイされます。シンプルで直感的なUIを提供し、タスクの追加、編集、削除、完了管理、ソート機能を備えています。
 
## アーキテクチャ
 
### 技術スタック
 
- **フロントエンド**: React 18+ with TypeScript
- **スタイリング**: TailwindCSS
- **状態管理**: React Hooks (useState, useEffect, useReducer)
- **データ永続化**: Browser LocalStorage API
- **ビルドツール**: Vite
- **テスト**: Playwright (E2Eテスト)
- **デプロイ**: AWS Amplify Gen2
- **日付処理**: date-fns (軽量な日付ライブラリ)
 
### アプリケーション構造
 
```
src/
├── components/
│   ├── TaskForm.tsx          # タスク追加フォーム
│   ├── TaskList.tsx          # タスク一覧表示
│   ├── TaskItem.tsx          # 個別タスク行
│   ├── EditModal.tsx         # タスク編集モーダル
│   ├── DeleteConfirm.tsx     # 削除確認ダイアログ
│   └── SortableHeader.tsx    # ソート可能なテーブルヘッダー
├── hooks/
│   ├── useLocalStorage.ts    # LocalStorage操作フック
│   └── useTasks.ts           # タスク管理ロジック
├── types/
│   └── task.ts               # タスク型定義
├── utils/
│   ├── storage.ts            # LocalStorage ユーティリティ
│   └── validation.ts         # バリデーション関数
├── App.tsx                   # メインアプリケーション
└── main.tsx                  # エントリーポイント
```
 
## コンポーネントとインターフェース
 
### データモデル
 
#### Task型
 
```typescript
interface Task {
  id: string; // UUID
  title: string; // タスクタイトル（必須）
  assignee: string; // 担当者名
  dueDate: string | null; // 期限（ISO 8601形式）
  priority: "low" | "medium" | "high"; // 優先度
  status: "todo" | "in-progress" | "completed"; // ステータス
  description: string; // 説明文
  completed: boolean; // 完了フラグ
  createdAt: string; // 作成日時（ISO 8601形式）
  updatedAt: string; // 更新日時（ISO 8601形式）
}
```
 
#### SortConfig型
 
```typescript
interface SortConfig {
  key: keyof Task | null;
  direction: "asc" | "desc";
}
```
 
### コンポーネント設計
 
#### App.tsx
 
- 最上位コンポーネント
- タスク状態の管理
- TaskFormとTaskListを配置
 
#### TaskForm.tsx
 
- 新規タスク追加フォーム
- Props: `onAddTask: (task: Omit) => void`
- バリデーション機能
- 日付ピッカー統合
 
#### TaskList.tsx
 
- タスク一覧表示
- Props: `tasks: Task[], onEdit, onDelete, onToggleComplete, sortConfig, onSort`
- ソート可能なヘッダー
- 空状態の表示
 
#### TaskItem.tsx
 
- 個別タスク行
- Props: `task: Task, onEdit, onDelete, onToggleComplete`
- 完了チェックボックス
- 編集・削除ボタン
 
#### EditModal.tsx
 
- タスク編集モーダル
- Props: `task: Task, isOpen: boolean, onClose, onSave`
- フォームバリデーション
- キャンセル機能
 
#### DeleteConfirm.tsx
 
- 削除確認ダイアログ
- Props: `isOpen: boolean, onConfirm, onCancel, taskTitle: string`
 
#### SortableHeader.tsx
 
- ソート可能なテーブルヘッダー
- Props: `label: string, sortKey: keyof Task, currentSort: SortConfig, onSort`
- ソート方向インジケーター
 
### カスタムフック
 
#### useLocalStorage
 
```typescript
function useLocalStorage(
  key: string,
  initialValue: T
): [T, (value: T) => void];
```
 
- LocalStorageとの同期
- JSON シリアライズ/デシリアライズ
- エラーハンドリング
 
#### useTasks
 
```typescript
function useTasks(): {
  tasks: Task[];
  addTask: (task: Omit) => void;
  updateTask: (id: string, updates: Partial) => void;
  deleteTask: (id: string) => void;
  toggleComplete: (id: string) => void;
  sortConfig: SortConfig;
  sortTasks: (key: keyof Task) => void;
};
```
 
- タスクのCRUD操作
- ソート機能
- LocalStorageへの自動保存
 
## データモデル
 
### LocalStorage構造
 
```json
{
  "lightweight-task-manager-tasks": [
    {
      "id": "uuid-v4",
      "title": "タスクタイトル",
      "assignee": "山田太郎",
      "dueDate": "2025-12-31T00:00:00.000Z",
      "priority": "high",
      "status": "in-progress",
      "description": "タスクの詳細説明",
      "completed": false,
      "createdAt": "2025-11-27T10:00:00.000Z",
      "updatedAt": "2025-11-27T10:00:00.000Z"
    }
  ]
}
```
 
### データフロー
 
1. **初期ロード**: LocalStorageからタスクデータを読み込み
2. **追加**: 新規タスク作成 → 状態更新 → LocalStorage保存
3. **編集**: タスク更新 → 状態更新 → LocalStorage保存
4. **削除**: タスク削除 → 状態更新 → LocalStorage保存
5. **完了切替**: completed フラグ更新 → 状態更新 → LocalStorage保存
6. **ソート**: ソート設定変更 → 表示順序更新（LocalStorage保存不要）
 
## 正確性プロパティ
 
_プロパティとは、システムの全ての有効な実行において真であるべき特性や振る舞いのことです。本質的には、システムが何をすべきかについての形式的な記述です。プロパティは、人間が読める仕様と機械で検証可能な正確性の保証との橋渡しをします。_
 
### プロパティリフレクション
 
事前分析を確認した結果、以下の冗長性を特定しました：
 
- **要件9.1**（即座にLocalStorageに保存）は要件1.4、3.3、4.2で個別にカバーされているため冗長
- **要件9.2**（ブラウザ再起動後のデータ復元）は要件2.4でカバーされているため冗長
 
これらの冗長なプロパティは除外し、各プロパティが独自の検証価値を提供するようにします。
 
### 正確性プロパティ一覧
 
#### プロパティ1: タスク追加でリストが成長する
 
*任意の*タスクリストと有効な（空でない）タスクデータに対して、タスクを追加するとタスクリストの長さが1増加する
**検証: 要件 1.1**
 
#### プロパティ2: 無効なタイトルは拒否される
 
*任意の*空文字列または空白文字のみの文字列に対して、それをタイトルとしてタスクを追加しようとすると拒否され、タスクリストは変更されない
**検証: 要件 1.2**
 
#### プロパティ3: 追加後にフォームがクリアされる
 
*任意の*フォーム状態に対して、有効なタスクを追加すると、フォームの全ての入力欄が空になる
**検証: 要件 1.3**
 
#### プロパティ4: タスク追加のラウンドトリップ
 
*任意の*タスクに対して、それを追加してLocalStorageから読み込むと、同じタスクデータが取得できる
**検証: 要件 1.4**
 
#### プロパティ5: LocalStorageからのデータ読み込み
 
*任意の*タスクセットに対して、それをLocalStorageに保存してシステムを再起動すると、同じタスクセットが表示される
**検証: 要件 2.1, 2.4**
 
#### プロパティ6: タスク表示に必須フィールドが含まれる
 
*任意の*タスクに対して、それを表示すると、タイトル、担当者、期限、優先度、ステータスの全てが表示される
**検証: 要件 2.2**
 
#### プロパティ7: 編集モーダルに現在のデータが表示される
 
*任意の*タスクに対して、編集ボタンをクリックすると、モーダルに現在のタスクデータが全て表示される
**検証: 要件 3.1**
 
#### プロパティ8: タスク更新が反映される
 
*任意の*タスクと任意の有効な変更内容に対して、タスクを更新すると、変更内容がタスクリストに反映される
**検証: 要件 3.2**
 
#### プロパティ9: タスク更新のラウンドトリップ
 
*任意の*タスクと任意の有効な変更内容に対して、タスクを更新してLocalStorageから読み込むと、変更後のデータが取得できる
**検証: 要件 3.3**
 
#### プロパティ10: 編集キャンセルで変更が破棄される
 
*任意の*タスクと任意の変更内容に対して、編集をキャンセルすると、元のタスクデータが保持される
**検証: 要件 3.4**
 
#### プロパティ11: 編集時の無効なタイトルは拒否される
 
*任意の*タスクに対して、タイトルを空文字列または空白文字のみに変更して保存しようとすると拒否され、元のデータが保持される
**検証: 要件 3.5**
 
#### プロパティ12: 削除確認ダイアログが表示される
 
*任意の*タスクに対して、削除ボタンをクリックすると、確認ダイアログが表示される
**検証: 要件 4.1**
 
#### プロパティ13: 削除でタスクが消える
 
*任意の*タスクリストとその中の任意のタスクに対して、そのタスクを削除すると、タスクリストから消え、LocalStorageからも削除される
**検証: 要件 4.2**
 
#### プロパティ14: 削除キャンセルでデータが保持される
 
*任意の*タスクに対して、削除をキャンセルすると、タスクがタスクリストに保持される
**検証: 要件 4.3**
 
#### プロパティ15: 完了チェックでステータスが変更される
 
*任意の*未完了タスクに対して、完了チェックボックスをクリックすると、completedフラグがtrueになる
**検証: 要件 5.1**
 
#### プロパティ16: 完了タスクに視覚的変化がある
 
*任意の*タスクに対して、完了状態にすると、視覚的に完了を示す表示（例：打ち消し線、色の変化）が適用される
**検証: 要件 5.2**
 
#### プロパティ17: 完了切替のラウンドトリップ
 
*任意の*タスクに対して、完了状態にしてから再度チェックを外すと、元の未完了状態に戻る
**検証: 要件 5.3**
 
#### プロパティ18: 完了状態変更のラウンドトリップ
 
*任意の*タスクに対して、完了状態を変更してLocalStorageから読み込むと、変更後の完了状態が取得できる
**検証: 要件 5.4**
 
#### プロパティ19: タイトルでソートされる
 
*任意の*タスクセットに対して、タイトル列でソートすると、タスクがタイトルの辞書順（昇順または降順）に並ぶ
**検証: 要件 6.1**
 
#### プロパティ20: 担当者でソートされる
 
*任意の*タスクセットに対して、担当者列でソートすると、タスクが担当者名の辞書順（昇順または降順）に並ぶ
**検証: 要件 6.2**
 
#### プロパティ21: 期限でソートされる
 
*任意の*タスクセットに対して、期限列でソートすると、タスクが期限の時系列順（昇順または降順）に並ぶ
**検証: 要件 6.3**
 
#### プロパティ22: 優先度でソートされる
 
*任意の*タスクセットに対して、優先度列でソートすると、タスクが優先度順（low < medium < high）に並ぶ
**検証: 要件 6.4**
 
#### プロパティ23: ステータスでソートされる
 
*任意の*タスクセットに対して、ステータス列でソートすると、タスクがステータス順に並ぶ
**検証: 要件 6.5**
 
#### プロパティ24: ソート方向の反転
 
*任意の*タスクセットと任意のソート列に対して、同じ列を2回続けてソートすると、ソート順が反転する
**検証: 要件 6.6**
 
## エラーハンドリング
 
### バリデーションエラー
 
- **空のタイトル**: タスク追加・編集時にタイトルが空の場合、エラーメッセージを表示し操作を拒否
- **無効な日付**: 期限に無効な日付が入力された場合、エラーメッセージを表示
- **必須フィールド**: タイトル以外のフィールドは任意だが、優先度とステータスはデフォルト値を設定
 
### LocalStorageエラー
 
- **容量超過**: LocalStorageの容量制限に達した場合、エラーメッセージを表示
- **アクセス不可**: LocalStorageが利用できない環境（プライベートモード等）の場合、警告を表示
- **データ破損**: LocalStorageから読み込んだデータが不正な場合、デフォルト値で初期化
 
### ネットワークエラー
 
- 本システムはオフラインで動作するため、ネットワークエラーは発生しない
 
## テスト戦略
 
### E2Eテスト（Playwright）
 
Playwright MCPを使用して、以下のシナリオをテストします：
 
#### 基本操作テスト
 
1. **タスク追加フロー**
 
   - フォームに入力してタスクを追加
   - 追加されたタスクが一覧に表示されることを確認
   - LocalStorageに保存されることを確認
 
2. **タスク編集フロー**
 
   - タスクの編集ボタンをクリック
   - モーダルでデータを変更
   - 変更が反映されることを確認
 
3. **タスク削除フロー**
 
   - タスクの削除ボタンをクリック
   - 確認ダイアログで確認
   - タスクが削除されることを確認
 
4. **完了チェックフロー**
 
   - 完了チェックボックスをクリック
   - 視覚的な変化を確認
   - LocalStorageに保存されることを確認
 
5. **ソート機能テスト**
   - 各列のヘッダーをクリック
   - ソート順が正しいことを確認
   - ソート方向の反転を確認
 
#### データ永続化テスト
 
6. **ページリロードテスト**
 
   - タスクを追加
   - ページをリロード
   - タスクが保持されていることを確認
 
7. **複数タスクの操作テスト**
   - 複数のタスクを追加
   - 編集、削除、完了チェックを組み合わせて実行
   - 全ての操作が正しく動作することを確認
 
#### エッジケーステスト
 
8. **空状態テスト**
 
   - タスクが0件の状態を確認
   - 適切なメッセージが表示されることを確認
 
9. **バリデーションテスト**
 
   - 空のタイトルで追加を試みる
   - エラーメッセージが表示されることを確認
 
10. **レスポンシブテスト**
    - モバイル、タブレット、デスクトップの各画面サイズで動作確認
 
### テスト実装方針
 
- **Playwright MCP**: E2Eテストの実装と実行に使用
- **テストデータ**: 各テストケースで独立したテストデータを使用
- **クリーンアップ**: 各テスト後にLocalStorageをクリア
- **アサーション**: 画面表示とLocalStorageの両方を検証
- **待機処理**: 非同期操作の完了を適切に待機
 
### テストカバレッジ目標
 
- 全ての正確性プロパティをE2Eテストでカバー
- 全てのユーザー操作フローをテスト
- エッジケースとエラーハンドリングをテスト
 
## UI/UXデザイン
 
### レイアウト
 
```
┌─────────────────────────────────────────────────────────┐
│  軽量タスク管理ツール                                      │
├─────────────────────────────────────────────────────────┤
│  [タスク追加フォーム]                                      │
│  タイトル: [_____________]  担当者: [_______]             │
│  期限: [? ____]  優先度: [▼]  ステータス: [▼]          │
│  説明: [_____________________________________]            │
│  [追加]                                                   │
├─────────────────────────────────────────────────────────┤
│  [タスク一覧テーブル]                                      │
│  ┌──┬────────┬────┬────┬────┬────┬──────┐              │
│  │✓│タイトル↕│担当者│期限│優先度│ステータス│操作│              │
│  ├──┼────────┼────┼────┼────┼────┼──────┤              │
│  │□│タスク1  │山田 │12/31│高  │進行中│[編集][削除]│              │
│  │☑│タスク2  │佐藤 │12/25│中  │完了  │[編集][削除]│              │
│  └──┴────────┴────┴────┴────┴────┴──────┘              │
└─────────────────────────────────────────────────────────┘
```
 
### カラースキーム（TailwindCSS）
 
- **プライマリ**: blue-600（ボタン、リンク）
- **セカンダリ**: gray-600（テキスト）
- **成功**: green-500（完了タスク）
- **警告**: yellow-500（期限間近）
- **危険**: red-500（削除ボタン）
- **背景**: gray-50（ページ背景）
- **カード**: white（フォーム、テーブル）
 
### インタラクション
 
- **ホバー効果**: ボタンとテーブル行にホバー時の色変化
- **フォーカス**: 入力欄にフォーカスリング
- **トランジション**: モーダルの開閉、ソートのアニメーション
- **フィードバック**: 操作成功時のトースト通知（オプション）
 
### アクセシビリティ
 
- **キーボード操作**: Tab、Enter、Escapeキーでの操作をサポート
- **ARIAラベル**: スクリーンリーダー対応
- **コントラスト**: WCAG AA基準を満たす色のコントラスト
- **フォーカス管理**: モーダル開閉時の適切なフォーカス移動
 
## AWS Amplify Gen2デプロイ設定
 
### プロジェクト構成
 
```
amplify/
├── backend.ts              # Amplify Gen2バックエンド設定
└── package.json            # Amplifyの依存関係
 
amplify_outputs.json        # Amplify設定出力（自動生成）
```
 
### backend.ts設定
 
```typescript
import { defineBackend } from "@aws-amplify/backend";
 
const backend = defineBackend({
  // 本システムはフロントエンドのみのため、
  // バックエンドリソースは定義しない
});
```
 
### ビルド設定
 
- **ビルドコマンド**: `npm run build`
- **出力ディレクトリ**: `dist`
- **Node.jsバージョン**: 18.x以上
 
### デプロイフロー
 
1. ローカルで開発・テスト
2. `amplify sandbox` でサンドボックス環境にデプロイ
3. E2Eテストを実行して動作確認
4. 問題なければ本番環境にデプロイ
 
### 環境変数
 
本システムはLocalStorageのみを使用するため、環境変数は不要です。
 
## パフォーマンス考慮事項
 
### 最適化戦略
 
- **React.memo**: 不要な再レンダリングを防ぐ
- **useMemo/useCallback**: 計算コストの高い処理をメモ化
- **仮想スクロール**: タスク数が多い場合の表示最適化（オプション）
- **デバウンス**: ソート操作の連続実行を制限
 
### LocalStorage制限
 
- **容量**: 約5-10MB（ブラウザによる）
- **対策**: タスク数が多い場合の警告表示
- **代替案**: 将来的にはバックエンドDBへの移行を検討
 
## セキュリティ考慮事項
 
### XSS対策
 
- Reactのデフォルトのエスケープ機能を使用
- dangerouslySetInnerHTMLは使用しない
- ユーザー入力を適切にサニタイズ
 
### データ保護
 
- LocalStorageは平文で保存されるため、機密情報は保存しない
- 将来的には暗号化を検討
 
## 将来の拡張性
 
### フェーズ2の機能候補
 
- タスクのフィルタリング機能
- タスクの検索機能
- タスクのカテゴリ/タグ機能
- タスクの添付ファイル機能
- 複数ユーザーでの共有機能（バックエンドDB必要）
- タスクの履歴管理
- リマインダー通知機能
 
### 技術的な拡張
 
- バックエンドAPI（AWS AppSync + DynamoDB）の追加
- 認証機能（Amazon Cognito）の追加
- リアルタイム同期機能
- オフライン対応の強化（Service Worker）

 

  • 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
# 実装タスクリスト
 
- [x] 1. プロジェクトのセットアップとAmplify Gen2の初期化
 
  - Vite + React + TypeScript プロジェクトを作成
  - TailwindCSSをインストールして設定
  - AWS Amplify Gen2をインストールして初期化
  - 基本的なプロジェクト構造を作成（components, hooks, types, utils ディレクトリ）
  - _要件: 11.1_
 
- [ ] 2. 型定義とユーティリティ関数の実装
 
  - [x] 2.1 Task型とSortConfig型を定義
    - types/task.ts にTask型とSortConfig型を定義
    - _要件: 1.1, 2.2_
  - [x] 2.2 バリデーション関数を実装
    - utils/validation.ts にタイトルバリデーション関数を実装
    - 空文字列と空白文字のみの文字列を検証
    - _要件: 1.2, 3.5_
  - [x] 2.3 LocalStorageユーティリティを実装
    - utils/storage.ts にLocalStorage操作関数を実装
    - データの保存、読み込み、削除機能
    - エラーハンドリング（容量超過、アクセス不可、データ破損）
    - _要件: 1.4, 2.1, 9.3, 9.4_
 
- [ ] 3. カスタムフックの実装
 
  - [x] 3.1 useLocalStorageフックを実装
    - hooks/useLocalStorage.ts を作成
    - LocalStorageとの同期機能
    - JSONシリアライズ/デシリアライズ
    - _要件: 1.4, 2.1, 2.4_
  - [x] 3.2 useTasksフックを実装
    - hooks/useTasks.ts を作成
    - タスクのCRUD操作（追加、更新、削除）
    - 完了切替機能
    - ソート機能
    - LocalStorageへの自動保存
    - _要件: 1.1, 3.2, 4.2, 5.1, 6.1-6.6_
 
- [ ] 4. UIコンポーネントの実装 - フォーム
 
  - [x] 4.1 TaskFormコンポーネントを実装
    - components/TaskForm.tsx を作成
    - タイトル、担当者、期限、優先度、ステータス、説明の入力欄
    - 日付ピッカーの統合
    - バリデーション機能
    - 追加ボタンとフォームクリア機能
    - _要件: 1.1, 1.2, 1.3, 1.5_
 
- [ ] 5. UIコンポーネントの実装 - テーブル
 
  - [x] 5.1 SortableHeaderコンポーネントを実装
    - components/SortableHeader.tsx を作成
    - ソート方向インジケーター
    - クリックでソート切替
    - _要件: 6.1-6.6_
  - [x] 5.2 TaskItemコンポーネントを実装
    - components/TaskItem.tsx を作成
    - タスク情報の表示（タイトル、担当者、期限、優先度、ステータス）
    - 完了チェックボックス
    - 編集・削除ボタン
    - 完了タスクの視覚的表示
    - _要件: 2.2, 5.1, 5.2_
  - [x] 5.3 TaskListコンポーネントを実装
    - components/TaskList.tsx を作成
    - ソート可能なテーブルヘッダー
    - TaskItemのリスト表示
    - 空状態の表示
    - _要件: 2.1, 2.3_
 
- [ ] 6. UIコンポーネントの実装 - モーダルとダイアログ
 
  - [x] 6.1 EditModalコンポーネントを実装
    - components/EditModal.tsx を作成
    - タスク編集フォーム
    - 現在のタスクデータの表示
    - 保存・キャンセルボタン
    - バリデーション機能
    - _要件: 3.1, 3.2, 3.4, 3.5_
  - [x] 6.2 DeleteConfirmコンポーネントを実装
    - components/DeleteConfirm.tsx を作成
    - 削除確認メッセージ
    - 確認・キャンセルボタン
    - _要件: 4.1, 4.3_
 
- [ ] 7. メインアプリケーションの実装
 
  - [x] 7.1 App.tsxを実装
    - useTasksフックを使用してタスク状態を管理
    - TaskFormとTaskListを配置
    - EditModalとDeleteConfirmの状態管理
    - レスポンシブレイアウト
    - _要件: 7.1, 7.3, 8.1-8.4_
 
- [ ] 8. スタイリングとレスポンシブデザイン
 
  - [x] 8.1 TailwindCSSでスタイリング
    - 全コンポーネントにTailwindCSSクラスを適用
    - カラースキームの実装（プライマリ、セカンダリ、成功、警告、危険）
    - ホバー効果とトランジション
    - _要件: 8.1-8.4_
  - [x] 8.2 アクセシビリティ対応
    - ARIAラベルの追加
    - キーボード操作のサポート
    - フォーカス管理
    - コントラスト比の確認
    - _要件: 7.2_
 
- [ ] 9. Amplify Gen2のデプロイ設定
 
  - [x] 9.1 Amplifyバックエンド設定
    - amplify/backend.ts を作成
    - 必要最小限の設定（フロントエンドのみ）
    - _要件: 11.1_
  - [x] 9.2 ビルド設定の確認
    - package.json のビルドスクリプトを確認
    - Amplifyのビルド設定を確認
    - _要件: 11.1_
 
- [ ] 10. E2Eテストの実装（Playwright MCP）
 
  - [x] 10.1 Playwrightのセットアップ
    - Playwrightをインストール
    - playwright.config.ts を設定
    - テストディレクトリを作成
    - _要件: 10.1-10.7_
  - [x] 10.2 基本操作のE2Eテスト
    - タスク追加フローのテスト
    - **プロパティ1: タスク追加でリストが成長する**
    - **検証: 要件 1.1**
    - タスク編集フローのテスト
    - **プロパティ8: タスク更新が反映される**
    - **検証: 要件 3.2**
    - タスク削除フローのテスト
    - **プロパティ13: 削除でタスクが消える**
    - **検証: 要件 4.2**
    - 完了チェックフローのテスト
    - **プロパティ15: 完了チェックでステータスが変更される**
    - **検証: 要件 5.1**
    - _要件: 10.1, 10.2, 10.3, 10.4_
  - [x] 10.3 ソート機能のE2Eテスト
    - 各列のソート機能をテスト
    - **プロパティ19-23: 各列でソートされる**
    - **検証: 要件 6.1-6.5**
    - ソート方向の反転をテスト
    - **プロパティ24: ソート方向の反転**
    - **検証: 要件 6.6**
    - _要件: 10.5_
  - [x] 10.4 データ永続化のE2Eテスト
    - ページリロード後のデータ保持をテスト
    - **プロパティ5: LocalStorageからのデータ読み込み**
    - **検証: 要件 2.1, 2.4**
    - LocalStorageへの保存をテスト
    - **プロパティ4: タスク追加のラウンドトリップ**
    - **検証: 要件 1.4**
    - _要件: 10.6_
  - [x] 10.5 バリデーションとエッジケースのE2Eテスト
    - 空のタイトルでの追加拒否をテスト
    - **プロパティ2: 無効なタイトルは拒否される**
    - **検証: 要件 1.2**
    - 空状態の表示をテスト
    - フォームクリアをテスト
    - **プロパティ3: 追加後にフォームがクリアされる**
    - **検証: 要件 1.3**
    - _要件: 10.7_
 
- [x] 11. チェックポイント - 全テストの実行と確認
 
  - 全てのE2Eテストが通過することを確認
  - 質問があればユーザーに確認
 
- [x] 12. ローカルでの動作確認とデバッグ
 
  - 開発サーバーで動作確認
  - ブラウザの開発者ツールでLocalStorageを確認
  - 各機能が正しく動作することを確認
  - _要件: 7.2_
 
- [x] 13. Amplify Sandboxへのデプロイ
 
  - `amplify sandbox` コマンドでサンドボックス環境にデプロイ
  - デプロイされたURLにアクセスして動作確認
  - _要件: 11.2, 11.3, 11.4_
 
- [x] 14. 最終チェックポイント - 本番デプロイ前の確認
  - 全ての機能が正常に動作することを確認
  - E2Eテストが全て通過することを確認
  - 質問があればユーザーに確認

出力の判定と修正

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

判定結果

問題なし

良かった点

  • 要件を整理した上で適切な技術選択の質問をしてくれた点
  • requirements.md、design.md、tasks.mdの3つのドキュメントが体系的に整理されていた点
  • 曖昧な部分について的確な質問を返してくれた点
  • スペック駆動開発のアプローチが期待通り実行された点

問題点

  • Amplifyでホスティングする予定だったが、gitのブランチ作成とAmplifyとの紐付けタスクが抜けていることを見逃していた点
  • そのため、デプロイ前にgitへのプッシュとAmplify環境作成を割り込みタスクとして実行する必要があった点
  • Amplifyのビルド時に複数回エラーが発生し、その都度ビルドエラーログをAIに渡して対応する必要があった点

Kiroとの対話

tailwind CSSを使ってみたのですが、最初tailwind CSSの適用がされておらず、白黒ののっぺりとした画面となってしまいました。
そのため、tailwind CSSが効いてないことをAIに伝えるとAIがそのまま試行錯誤し解決しました。
Vive コーディングではAIが自分でエラーを確認し試行錯誤してくれるので大変便利ですよね。

テスト実装

Playwright MCPを活用して、アプリケーションの品質を保証するための包括的なE2Eテストを実装しました。テストは機能ごとに4つのファイルに分類し、合計20以上のテストケースをカバーしています。

1. 基本操作テスト

CRUD操作の基本機能を検証するテストです。

  • タスク追加機能: 空の状態からタスクを追加し、リストに正しく表示されることを確認
  • タスク編集機能: 編集モーダルを開き、タイトル・担当者・優先度などを変更して保存、変更が反映されることを確認
  • タスク削除機能: 削除ボタンをクリックし、確認ダイアログを経てタスクがリストから消えることを確認
  • 完了チェック機能: チェックボックスをクリックしてタスクが完了状態になり、打ち消し線が適用されることを確認

2. データ永続化テスト

LocalStorageを使ったデータ保持機能を検証するテストです。

  • リロード後のデータ保持: タスクを追加後にページをリロードし、データが保持されていることを確認
  • LocalStorageへの保存: タスク追加時にLocalStorageに正しい形式でデータが保存されることを確認
  • 複合操作の整合性: 複数タスクの追加・編集・削除を行った後、リロードしてもデータの整合性が保たれることを確認
  • 完了状態の永続化: 完了チェックの状態がリロード後も保持されることを確認

3. ソート機能テスト

テーブルの各列でのソート機能を検証するテストです。

  • タイトルソート: タイトル列をクリックして昇順・降順にソートされることを確認
  • 担当者ソート: 担当者列をクリックして正しくソートされることを確認
  • 期限ソート: 期限列をクリックして日付順にソートされることを確認
  • 優先度ソート: 優先度列をクリックして低・中・高の順にソートされることを確認
  • ステータスソート: ステータス列でのソート機能を確認
  • ソート方向の反転: 同じ列を2回クリックすると昇順・降順が切り替わることを確認

4. バリデーション・エッジケーステスト

入力検証やエッジケースを検証するテストです。

  • 空タイトルの拒否: タイトルが空の状態で追加しようとするとエラーメッセージが表示されることを確認
  • 空白文字のみの拒否: 空白文字のみのタイトルも拒否されることを確認
  • 編集時のバリデーション: 編集時にタイトルを空にしようとするとエラーが表示されることを確認
  • フォームのクリア: タスク追加後にフォームが自動的にクリアされることを確認
  • 空状態の表示: タスクがない場合に適切なメッセージとアイコンが表示されることを確認
  • 削除のキャンセル: 削除確認ダイアログでキャンセルするとタスクが保持されることを確認
  • 編集のキャンセル: 編集モーダルでキャンセルすると変更が破棄されることを確認
  • Escapeキーでの操作: Escapeキーでモーダルやダイアログを閉じられることを確認

テスト実行結果

全てのテストが正常にパスし、アプリケーションの品質が保証されました。Playwright MCPのおかげで、実際のブラウザ操作を通じた現実的なテストを効率的に実装できました。

 

成果物

実際に作ったアプリのデモ動画はこちらです。

所要時間

2時間

主な機能

  • タスク管理機能: タイトル、担当者、期限を含むタスクの追加・編集・削除
  • 一覧表示機能: 登録されたタスクを見やすい形で一覧表示
  • フォーム入力機能: 画面上部のフォームからタスクを簡単に追加
  • 操作ボタン機能: 各タスク行に編集・削除ボタンを配置し直感的な操作を実現
  • データ永続化機能: ローカルストレージを活用してブラウザを閉じてもデータを保持
  • レスポンシブデザイン: モバイル・デスクトップ両対応の軽量なUI
  • E2Eテスト機能: Playwright MCPを使用したCRUD操作の自動テスト

工夫点など

  • ユーザビリティを重視したUI設計: TailwindCSSを活用して、直感的で使いやすいインターフェースを実現。タスクの追加フォームを画面上部に固定配置し、編集・削除ボタンを各行に配置することで操作対象を明確化
  • データ永続化の実装: ローカルストレージを活用してブラウザを閉じてもデータが保持される仕組みを実装。サーバーサイドの複雑な実装なしに実用的なデータ保持機能を実現
  • レスポンシブ対応: TailwindCSSのレスポンシブクラスを活用し、モバイルとデスクトップ両方で快適に使用可能。画面サイズに応じてレイアウトが最適化され、どのデバイスからでもサクサク操作可能
  • 包括的なE2Eテスト: Playwright MCPを使用してCRUD操作の全てをカバーするE2Eテストを実装。タスクの追加、編集、削除、一覧表示の各機能が正常に動作することを自動テストで保証
  • シンプルな技術スタック: React + TailwindCSS + ローカルストレージという最小限の技術スタックを選択。複雑な依存関係を避けることで軽量で高速なアプリケーションを実現し、メンテナンス性も向上

発見と学び

AIとの対話で得られた発見

今回のフルAI開発バトルを通じて、いくつかの重要な発見がありました。

1. 質問させることの重要性

「曖昧な要件だと思うので私に判断を仰ぎたい部分は必ず私に質問してください」という一文を加えることで、AIが勝手に判断して進むのではなく、適切なタイミングで確認を求めてくれるようになりました。これにより手戻りを大幅に削減できました。

2. スペック駆動開発の効果

要件定義→設計→タスク分解の順序で進めることで、開発全体の見通しが良くなり、AIも迷わずに実装を進められました。特にrequirements.md、design.md、tasks.mdの3つのドキュメントを最初に作成したことで、後の開発がスムーズに進みました。

3. エラー対応におけるAIの自己解決能力

TailwindCSSが適用されない問題やAmplifyのビルドエラーなど、技術的な問題が発生した際、AIが自分でエラーログを分析し、試行錯誤して解決してくれました。人間はエラーの発生を伝えるだけで、具体的な解決策を考える必要がありませんでした。

4. Playwright MCPの威力

E2Eテストの実装において、Playwright MCPを使うことで、実際のブラウザ操作を通じたテストが簡単に実装できました。AIがテストコードを書き、実際に動作確認まで行ってくれるため、品質保証の面でも安心できました。

実務で活用できるTips

プロンプト設計のコツ

  • 「質問してください」を明示的に指示する
  • 日本語での質問を求める（理解しやすさのため）
  • 要件の曖昧さを事前に伝える

開発フローの最適化

  • スペック駆動開発を徹底する
  • ドキュメント作成→実装の順序を守る
  • エラーログは必ずAIに共有する

技術選択の判断基準

  • AIが得意な技術スタックを選ぶ（React、TailwindCSS等）
  • デプロイまで含めた全体設計を最初に決める
  • テスト実装も開発計画に含める

感想

良かった点

今回のフルAI開発バトルに参加して、本当に多くの収穫がありました。

まず、AIとの協働開発スキルが大幅に向上したことが最大の成果です。これまでもCursorやChatGPT Proを使っていましたが、「AIに質問させる」「スペック駆動で進める」といった具体的な手法を身につけることで、AIをより効果的に活用できるようになりました。

また、短時間での開発力が証明できたことも大きな自信につながりました。2時間で要件定義からデプロイまで完了できたのは、AIとの協働があってこそです。これは実務でのプロトタイプ開発や概念実証において非常に有用なスキルだと感じています。

新しい技術への挑戦ができたことも良かった点です。Playwright MCPは今回初めて使いましたが、AIのサポートがあることで学習コストを大幅に削減しながら実用的なE2Eテストを実装できました。

そして何より、AIの可能性を肌で感じられたことが印象的でした。エラー対応での自己解決能力や、曖昧な要件に対する適切な質問など、AIが単なるコード生成ツールを超えて、開発パートナーとして機能することを実感できました。

苦労した点

一方で、いくつかの苦労した点や課題も見えてきました。

AIの判断に依存するリスクが最も大きな課題でした。AIが「これで良いだろう」と判断して進めた部分で、後から「実はこうしたかった」という齟齬が生じることがありました。特にUI/UXの細かい部分では、人間の感覚とAIの判断にギャップを感じる場面がありました。

デバッグ時の情報共有の難しさも課題でした。エラーログをAIに渡すのは簡単ですが、「なんとなく動作が重い」「UIの見た目が微妙」といった感覚的な問題を言語化してAIに伝えるのは思った以上に難しく、時間がかかりました。

最終的な品質の担保についても課題を感じました。AIが作成したコードやテストが本当に要件を満たしているか、セキュリティ面で問題がないかなど、最終的な品質判断は人間が行う必要があり、その責任の重さを改めて実感しました。

今後に活かせること

今回の経験を通じて、実務で活かせる具体的なポイントが明確になりました。

プロトタイプ開発の高速化では、新機能の検証や顧客への提案資料作成時に、今回の手法を活用することで開発時間を大幅に短縮できると考えています。特に「要件が曖昧な段階でもAIに質問させながら進める」アプローチは、顧客との要件すり合わせにも有効だと感じました。

チーム開発での活用においては、ジュニアエンジニアの教育やコードレビューの効率化に応用できそうです。AIとの対話ログを共有することで、思考プロセスや技術選択の理由を可視化でき、チーム全体のスキル向上につながると期待しています。

品質保証プロセスの改善では、Playwright MCPを使ったE2Eテストの自動生成を既存プロジェクトにも導入したいと考えています。テストケースの網羅性向上と、回帰テストの自動化により、リリース品質の向上が期待できます。

技術調査・学習の効率化も大きなメリットです。新しい技術やライブラリを導入する際、AIと対話しながら実際に動くサンプルを作成することで、ドキュメントを読むだけでは得られない実践的な知見を短時間で獲得できます。

最後に、顧客とのコミュニケーション改善にも活用できると感じています。要件の曖昧な部分をAIに質問させることで、顧客への確認事項を整理し、より具体的で建設的な議論ができるようになると期待しています。

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

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

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

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

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

採用情報
2025-12-03

関連投稿

ページトップへ