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

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

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

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

自己紹介

クラウド開発事業部所属のyamadaです。 普段はサーバレスバックエンド開発を担当しています。エンジニア歴は2年で、主にNode.jsやAWSを使った開発をしています。

最近は1歳の子供と過ごす時間にハマっています。毎日できることが増えていく様子を見ていると、“学習曲線の暴力”ってこういうことか…と実感します。
技術も育児も、小さな成功を積み重ねるのが一番楽しいですね。

普段使ってるAIツール

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

  • ChatGPT: 設計書などのドキュメント作成
    • お気に入りポイント

      • 意図の読み取りが正確で、話の軸がぶれにくい点
        前後の文脈や目的を踏まえて回答してくれるため、こちらの意図から外れた内容になりにくく、作業の手戻りが減ります。

      • 必要な背景や前提を自然に補って文章を整えてくれる点
        こちらが省略した部分を違和感なく補足してくれるため、資料化しやすい形で文章をまとめられます。

      • 最終的な“読み物としての品質”に仕上げる速度が速い点
        叩き台の作成から仕上げまで一気に進められるため、短時間でも外部に出せる水準の文章に整えられます。

企画概要とゴール

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

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

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

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

作業プロセス

要件の理解と整理

まず最初にやったのは、渡された要件を丁寧に読み込むことです。

実務でもそうですが、要件定義書には「書かれていること」と「書かれていないこと」があります。今回の企画では、意図的に曖昧な部分が残されていると気がつき、自分で判断する必要があると思いました。

提示された要件には「軽量」「サクサク」「直感的」といった感覚的な表現が多く含まれていました。
ただ、こういった言葉は方向性としては大事でも、そのままでは実装時の判断基準にならず、曖昧さが残ってしまいます。
そのため、まずはこれらの表現が実際には“何を満たす状態”を指しているのかを整理し、判断できる形にまとめるところから始めました。

最初に決めたのは、このシステム全体が最終的に目指す姿（上位の目的）です。

「社員が今日やるべきタスクを、ロール問わず誰でも使えるインターフェースで、パフォーマンス劣化なく管理できるシステムを提供する」

この大枠を決めたうえで、ここから実際に満たすべきポイントを3つに分けました。

1. 誰でも迷わず使えること

2. タスク数によらないパフォーマンス保証

3. 必要なCRUD処理をすべて行えること

この3つを土台として「何を作るべきか」をはっきりさせ、そのうえで要件定義の作業に進む形をとりました。

運営への質問事項　

特に質問は行いませんでした。特に疑問がなく要件定義を整理できたからです。

Specs定義

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

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

ここまでで、「このシステムが最終的にどういう状態になっていればOKか」と、そこに至るための3つのポイントまでは自分の中で整理できました。
一方で、この時点ではまだそれが「頭の中の整理」でしかなく、そのままでは要件定義書としては使えません。そこで、ここから先は Kiro に手を動かしてもらい、「人がそのまま実装・テストに使える形」にまで落としてもらうことにしました。

ただ、「要件定義書を作ってください」とだけ投げると、粒度や範囲の解釈が Kiro 側に寄ってしまい、せっかく決めた3つのポイントとズレるリスクがあります。そこで、Kiro にお願いする前に、次のような役割分担をはっきりさせておきました。

  • 自分がやること

    • どこまでをこのアプリの守備範囲とするか

    • 何を優先するか（使いやすさ／パフォーマンス／タスク管理の完結性）

    • 「サクサク」などの感覚的な表現を、ある程度判断できるレベルまで整理しておくこと

  • Kiro にやってほしいこと

    • それらを前提にしたうえで、ユーザーストーリーと受け入れ基準まで具体的に書き起こすこと

    • 抜けがちな部分（テスト観点、デプロイ方法、データ構造など）も含めて、仕様として一通りそろえ切ること

    • あとから自分や他の開発者が読んでも迷わないように、「何をもって完了とするか」が分かるレベルまで文章を整えること

もう一つ意識したのは、「一発で正解を書いてもらう」というより、
① まず Kiro にドラフトを書いてもらう → ② そのドラフトを Kiro 自身にチェックさせる → ③ 最後に自分が見る、という三段階構成にしておくことです。
これを最初に決めておくことで、「どこまでがAIに任せられて、どこから先は自分が見るべきか」という線引きができ、結果的に負担を減らしつつ、必要な精度も確保できるだろうと考えました。

Kiroへの指示

要件定義書、設計書、タスクで次のようなプロンプトを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
このアプリの前提を先に共有します。
 
- 上位の目的：
　「社員が今日やるべきタスクを、ロール問わず誰でも使えるインターフェースで、パフォーマンス劣化なく管理できるようにすること」
- 重要な観点：
1. 誰でも迷わず使えること
2. タスク数によらず動作が重くならないこと
3. 必要な CRUD 操作が一通りそろっていること
 
ここまでで、「このシステムがどういう状態ならOKか」と、そのために押さえておきたい観点は整理できたので、あとは仕様として読める形にしてほしいです。
 
前提となる条件はおおざっぱにいうと以下です：
 
- Todo を追加・編集・削除できること
- 追加は画面上部のフォームから行う
- 編集／削除は各行のボタンから行う
- 一覧で Todo を確認できること（タイトル／担当者／期限を表示）
- 画面は 1 ページで完結し、「サクサク軽く」動くこと
- ブラウザを閉じてもデータが消えないこと（localStorage 前提でよい）
- Playwright MCP を使って CRUD 周りの E2E テストを回すこと
 
この前提に沿って、まずは要件定義書（requirements.md）のドラフトを書いてください。
 
粒度としては、
- ユーザーが何をしたいのか（ユーザーストーリー）
- それができたと言える条件（受け入れ基準）
 
が分かるレベルまで落としてもらえれば十分です。
 
「サクサク」「直感的」みたいな表現は、そのまま書かず、
分かる範囲で判断しやすい書き方に寄せてもらえると助かります。
 
一度ドラフトを書いたあと、自分で見直して、
・テスト観点（E2Eでどこまで見るか）
・データ構造（Task と localStorage 周り）
・やらないことの境界
あたりに明らかな抜けや矛盾がないかだけ簡単にチェックしてから出してもらえると嬉しいです。

 

  • design.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
次に、いま作ってもらった requirements.md を前提に、設計書（design.md）のドラフトを書いてください。
 
想定しているのは、単一 HTML＋JS で動くシンプルな構成です。
ざっくりでいいので、
 
- 画面（フォーム＋一覧）が何を担当するか
- その裏で動くロジックが何をしているか（Todo の管理、Undo など）
- データ保存（localStorage）をどう扱うか
- Todo のデータ構造（タイトル／担当者／期限 など）
 
といったあたりが分かるように整理してもらえると助かります。
 
クラスや関数を使う前提であれば、
UI／ロジック／ストレージ／データモデル、くらいに分けて
「それぞれがどんな責務を持つか」が読み取れるレベルまで書いてください。
 
最終的なコードと 1 行 1 行合わせる必要はないので、
実装のベースになる程度の粗さで大丈夫です。

 

  • tasks.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
design.md をベースに、実装タスクを tasks.md として一覧化してください。
 
タスクの粒度は、
 
- ○○クラス／モジュールを作る
- ○○画面（フォーム／一覧）を実装する
- Undo 機能を実装する
- localStorage との読み書きを実装する
- Playwright で CRUD の E2E テストを書く
- Amplify（静的ホスティング）にデプロイできる状態にする
 
といった単位で構いません。
 
それぞれのタスクについて、
「何をやるタスクか」が一行で分かる説明を付けてもらえると助かります。
可能であれば、どの要件（requirements.md のどの項目）に対応しているかも軽く触れてください。
 
実装しやすい順番で並べてもらえればOKです。

Kiroの出力

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
# 要件定義書
 
## はじめに
 
本システムは、軽量で直感的に使えるタスク管理ツールを提供します。
ユーザーはタスクの追加・表示・編集・削除ができ、シンプルで分かりやすい操作性を重視します。
 
## 用語集
 
- **System（システム）**: 本タスク管理ツール全体
- **Task（タスク）**: タイトル、担当者、期限を持つ作業項目
- **User（ユーザー）**: 本システムの利用者
- **Task List（タスクリスト）**: 登録されたタスクを一覧表示する領域
 
## 要件
 
### 機能要件
 
#### 要件 1: タスク追加
 
**ユーザーストーリー**
ユーザーとして、新しいタスクを追加したい。やるべきことを整理できるから。
 
**受け入れ基準**
 
1. ユーザーがタイトル・担当者・期限を入力して「追加」ボタンをクリックすると、タスクがリストに追加される
2. タスク追加後、入力欄がクリアされる
3. タイトル・担当者・期限が未入力の場合はタスクを追加しない
4. 追加されたタスクは一覧の先頭に表示される
 
---
 
#### 要件 2: タスク一覧表示
 
**ユーザーストーリー**
登録済みのタスクを一覧で確認したい。
 
**受け入れ基準**
 
1. ページ読み込み時に、保存されているタスクを読み込み一覧表示する
2. タスクのタイトル・担当者・期限を表示する
3. 新しいタスクが上に表示されるように並び替える
4. タスク行には編集・削除ボタンを表示する
5. 一覧は視認性が高く読みやすい状態で表示される
 
---
 
#### 要件 3: タスク編集
 
**ユーザーストーリー**
登録したタスクを後から変更したい。
 
**受け入れ基準**
 
1. 編集ボタンを押すとタスク行が編集モードになる
2. 編集モードでは保存・キャンセルボタンが表示される
3. 保存するとタスク内容が更新される
4. キャンセルすると編集前の内容に戻る
 
---
 
#### 要件 4: タスク削除
 
**ユーザーストーリー**
不要なタスクを削除したい。
 
**受け入れ基準**
 
1. 削除ボタンをクリックするとタスクが一覧から削除される
2. 削除後、データ保存領域からもタスクが削除されていることが望ましい
 
---
 
#### 要件 5: データ保持
 
**ユーザーストーリー**
ブラウザを閉じてもタスクが残っていてほしい。
 
**受け入れ基準**
 
1. ブラウザを再度開いたときに、前回のタスクが復元される

 

  • 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
# 設計書
 
## 概要
 
本システムは、ブラウザローカルで動作するシンプルなタスク管理アプリケーションです。
ユーザーはタスクの追加、一覧表示、編集、削除といった基本操作を行うことができ、データはブラウザの localStorage に保存されます。
単一の HTML ファイルと Vanilla JavaScript を使った、軽量で扱いやすい構成とします。
 
**設計の方向性：**
 
- 単純な構成で読みやすく、変更しやすいこと
- 画面は 1 ページで完結すること
- Todo の追加・編集・削除・一覧という基本機能にフォーカスすること
 
**技術スタック：**
 
- 言語: Vanilla JavaScript（ES6 クラスベース）
- マークアップ: HTML（単一ファイル）
- スタイル: Tailwind CSS（CDN 利用を想定）
- データ永続化: localStorage API
- 対象ブラウザ: モダンブラウザ（Chrome / Firefox / Safari / Edge）
 
**デプロイ方法（前提）：**
 
- 静的ホスティングサービス（例: Amplify Hosting）で index.html を配置する想定
※詳細手順は本設計書の対象外
 
---
 
## アーキテクチャ概要
 
本システムは、大きく次の 4 つのレイヤーで構成します。
 
1. プレゼンテーション層（UI）
2. ビジネスロジック層（タスク管理）
3. データ永続化層（localStorage）
4. データモデル層（Task オブジェクト）
 
レイヤー間の依存関係は下記のイメージです。
 
- UI（TaskUI）がビジネスロジック（TaskManager）を呼び出す
- TaskManager がデータ永続化（TaskStorage）を通じて localStorage を更新する
- Task はタスク 1 件分のデータ構造を表現する
 
---
 
## レイヤー構成
 
### プレゼンテーション層（TaskUI）
 
**役割**
 
- フォーム入力（タイトル／担当者／期限）の受付
- タスク一覧（テーブル）の描画
- 編集モード／通常モードの切り替え
- ボタン押下など UI イベントのハンドリング
 
**責務**
 
- ユーザー操作を TaskManager に橋渡しする
- TaskManager から取得したタスク一覧を DOM に反映する
 
---
 
### ビジネスロジック層（TaskManager）
 
**役割**
 
- タスクの追加／編集／削除の中核ロジック
- タスク一覧の並び順（新しい順）の制御
- 保存タイミングの制御
 
**責務**
 
- Task の生成・更新・削除
- TaskStorage とのやりとり（保存／読み込み）
- UI から呼び出されるインターフェースの提供
 
---
 
### データ永続化層（TaskStorage）
 
**役割**
 
- localStorage とのデータ読み書き
 
**責務**
 
- タスク一覧の保存（配列 → JSON）
- タスク一覧の取得（JSON → 配列）
- localStorage が使えない場合の簡易フォールバック（空配列返却など）
 
---
 
### データモデル層（Task）
 
**役割**
 
- タスク 1 件分のデータ構造を定義
 
**主なフィールド**
 
- id: 一意な識別子
- title: タスク名
- assignee: 担当者
- dueDate: 期限
- createdAt: 作成日時（ソート用）
 
---
 
## コンポーネント設計
 
### Task クラス（データモデル）
 
class Task {
constructor(title, assignee, dueDate) {
this.id = crypto.randomUUID();
this.title = title;
this.assignee = assignee;
this.dueDate = dueDate;
this.createdAt = Date.now();
}
}
 
---
 
### TaskStorage クラス（データ永続化）
 
class TaskStorage {
constructor() {
this.storageKey = "tasks";
}
 
loadTasks() {
try {
const raw = localStorage.getItem(this.storageKey);
return raw ? JSON.parse(raw) : [];
} catch (e) {
console.error("タスクの読み込みに失敗しました", e);
return [];
}
}
 
saveTasks(tasks) {
try {
const raw = JSON.stringify(tasks);
localStorage.setItem(this.storageKey, raw);
} catch (e) {
console.error("タスクの保存に失敗しました", e);
}
}
}
 
---
 
### TaskManager クラス（ビジネスロジック層）
 
class TaskManager {
constructor(storage) {
this.storage = storage;
this.tasks = [];
}
 
initialize() {
this.tasks = this.storage.loadTasks();
this.sortTasks();
}
 
addTask(title, assignee, dueDate) {
if (!title || !assignee || !dueDate) {
return { success: false };
}
 
const task = new Task(title, assignee, dueDate);
this.tasks.unshift(task);
this.storage.saveTasks(this.tasks);
return { success: true, task };
}
 
updateTask(id, title, assignee, dueDate) {
const task = this.tasks.find(t => t.id === id);
if (!task) {
return { success: false };
}
 
if (!title || !assignee || !dueDate) {
return { success: false };
}
 
task.title = title;
task.assignee = assignee;
task.dueDate = dueDate;
this.storage.saveTasks(this.tasks);
return { success: true, task };
}
 
deleteTask(id) {
const before = this.tasks.length;
this.tasks = this.tasks.filter(t => t.id !== id);
if (this.tasks.length !== before) {
this.storage.saveTasks(this.tasks);
return { success: true };
}
return { success: false };
}
 
sortTasks() {
this.tasks.sort((a, b) => b.createdAt - a.createdAt);
}
 
getAllTasks() {
return this.tasks;
}
}
 
---
 
### TaskUI クラス（プレゼンテーション層）
 
class TaskUI {
constructor(manager) {
this.manager = manager;
this.editingTaskId = null;
}
 
initialize() {
this.setupEventListeners();
this.renderTaskList();
}
 
setupEventListeners() {
const addButton = document.getElementById("add-task-btn");
addButton.addEventListener("click", () => this.handleAddTask());
}
 
handleAddTask() {
const title = document.getElementById("title-input").value;
const assignee = document.getElementById("assignee-input").value;
const dueDate = document.getElementById("duedate-input").value;
 
const result = this.manager.addTask(title, assignee, dueDate);
if (result.success) {
this.clearInputs();
this.renderTaskList();
} else {
alert("タスクを追加できませんでした。入力内容を確認してください。");
}
}
 
handleEditTask(id) {
this.editingTaskId = id;
this.renderTaskList();
}
 
handleUpdateTask(id) {
const title = document.getElementById(`edit-title-${id}`).value;
const assignee = document.getElementById(`edit-assignee-${id}`).value;
const dueDate = document.getElementById(`edit-duedate-${id}`).value;
 
const result = this.manager.updateTask(id, title, assignee, dueDate);
if (result.success) {
this.editingTaskId = null;
this.renderTaskList();
} else {
alert("タスクを更新できませんでした。入力内容を確認してください。");
}
}
 
handleDeleteTask(id) {
const result = this.manager.deleteTask(id);
if (result.success) {
this.renderTaskList();
}
}
 
handleCancelEdit() {
this.editingTaskId = null;
this.renderTaskList();
}
 
clearInputs() {
document.getElementById("title-input").value = "";
document.getElementById("assignee-input").value = "";
document.getElementById("duedate-input").value = "";
}
 
renderTaskList() {
const tasks = this.manager.getAllTasks();
const tbody = document.getElementById("task-list");
 
if (!tasks || tasks.length === 0) {
tbody.innerHTML = `
<tr>
<td colspan="4">タスクがありません</td>
</tr>
`;
return;
}
 
tbody.innerHTML = tasks.map(task => {
if (this.editingTaskId === task.id) {
return `
<tr>
<td><input id="edit-title-${task.id}" value="${task.title}"></td>
<td><input id="edit-assignee-${task.id}" value="${task.assignee}"></td>
<td><input id="edit-duedate-${task.id}" value="${task.dueDate}"></td>
<td>
<button onclick="app.ui.handleUpdateTask('${task.id}')">保存</button>
<button onclick="app.ui.handleCancelEdit()">キャンセル</button>
</td>
</tr>
`;
} else {
return `
<tr>
<td>${task.title}</td>
<td>${task.assignee}</td>
<td>${task.dueDate}</td>
<td>
<button onclick="app.ui.handleEditTask('${task.id}')">編集</button>
<button onclick="app.ui.handleDeleteTask('${task.id}')">削除</button>
</td>
</tr>
`;
}
}).join("");
}
}
 
---
 
## データモデル
 
### Task オブジェクト
 
{
id: string, // 一意なID
title: string, // タスク名
assignee: string, // 担当者
dueDate: string, // 期限（日付文字列）
createdAt: number // 作成日時（ミリ秒）
}
 
---
 
## localStorage スキーマ
 
- キー: `"tasks"`
- 値: Task オブジェクトの配列を JSON 文字列化したもの
 
[
{
"id": "xxx-yyy-zzz",
"title": "サンプルタスク",
"assignee": "山田",
"dueDate": "2025-11-28",
"createdAt": 1732723200000
}
]

 

  • 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
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
580
581
582
583
584
585
586
587
588
589
# 実装タスクリスト
 
## 概要
 
本タスクリストは、要件定義書（requirements.md）と設計書（design.md）に基づき、実装可能な粒度まで分解したタスクです。各タスクは段階的に実装し、前のタスクの成果物を次のタスクで活用します。
 
**実装方針：**
 
- 単一 HTML ファイル（index.html）にすべてを実装
 
- クラスベースの Vanilla JavaScript
 
- Tailwind CSS（CDN）
 
- 2 時間以内での完成を目指す
 
**タスク表記：**
 
- `[ ]`: 未着手
 
- `[x]`: 完了
 
- `*`: オプション（テスト関連タスク）
 
---
 
## タスク一覧
 
- [ ] 1. プロジェクト基盤の構築
 
  - HTML ファイルの基本構造を作成
 
  - Tailwind CSS CDN の読み込み
 
  - 基本的な DOM 要素の配置
 
  - _要件: 8.1, 10.2_
 
- [ ] 1.1 HTML ファイルの基本構造を作成
 
  - DOCTYPE、html、head、body タグの配置
 
  - meta charset、viewport 設定
 
  - title 要素の設定
 
  - _要件: 8.1_
 
- [ ] 1.2 Tailwind CSS CDN を読み込む
 
  - script タグで Tailwind CSS CDN を読み込み
 
  - 基本的なスタイリングが適用されることを確認
 
  - _要件: 6.1-6.6_
 
- [ ] 1.3 DOM 要素の基本構造を配置
 
  - タスク追加フォーム（タイトル、担当者、期限の入力フィールド）
 
  - タスク一覧テーブル（thead、tbody）
 
  - エラーメッセージ表示領域
 
  - Undo 通知バー
 
  - 日本語ラベルの配置
 
  - _要件: 1.1, 2.2, 6.1-6.6, 6.9-6.10_
 
- [ ] 2. データモデル層の実装
 
  - Task クラスの実装
 
  - バリデーションロジックの実装
 
  - _要件: 1.2-1.4_
 
- [ ] 2.1 Task クラスを実装
 
  - constructor（id、title、assignee、dueDate、createdAt）
 
  - crypto.randomUUID()で ID 生成
 
  - Date.now()で createdAt 生成
 
  - _要件: 1.1_
 
- [ ] 2.2 Task.validate()メソッドを実装
 
  - タイトルの空チェック
 
  - 担当者の空チェック
 
  - 期限の空チェック
 
  - YYYY-MM-DD 形式チェック
 
  - 有効な日付かチェック
 
  - エラーメッセージ配列を返す
 
  - _要件: 1.2-1.4_
 
- [ ] 3. データ永続化層の実装
 
  - TaskStorage クラスの実装
 
  - localStorage 操作の実装
 
  - _要件: 1.6, 2.1, 5.1-5.4_
 
- [ ] 3.1 TaskStorage クラスを実装
 
  - constructor（storageKey = "tasks"）
 
  - loadTasks()メソッド（localStorage から読み込み、JSON.parse）
 
  - saveTasks()メソッド（JSON.stringify、localStorage に保存）
 
  - isAvailable()メソッド（localStorage 利用可能性チェック）
 
  - エラーハンドリング（try-catch）
 
  - _要件: 1.6, 2.1, 5.1-5.3_
 
- [ ] 4. ビジネスロジック層の実装
 
  - TaskManager クラスの実装
 
  - CRUD 操作の実装
 
  - Undo 機能の実装
 
  - _要件: 1.1-1.6, 2.1-2.5, 3.1-3.5, 4.1-4.3, 4.5.1-4.5.6_
 
- [ ] 4.1 TaskManager クラスの基本構造を実装
 
  - constructor（storage）
 
  - tasks 配列の初期化
 
  - deletedTask、undoTimer の初期化
 
  - _要件: 1.1, 4.5.1_
 
- [ ] 4.2 initialize()メソッドを実装
 
  - storage.loadTasks()でタスク読み込み
 
  - sortTasks()でソート
 
  - _要件: 2.1, 2.3_
 
- [ ] 4.3 addTask()メソッドを実装
 
  - Task.validate()でバリデーション
 
  - エラーがあれば{success: false, errors}を返す
 
  - 新しい Task インスタンスを生成
 
  - tasks 配列の先頭に追加（unshift）
 
  - storage.saveTasks()で保存
 
  - {success: true, task}を返す
 
  - _要件: 1.1-1.6_
 
- [ ] 4.4 updateTask()メソッドを実装
 
  - Task.validate()でバリデーション
 
  - エラーがあれば{success: false, errors}を返す
 
  - ID でタスクを検索
 
  - タスクのプロパティを更新
 
  - storage.saveTasks()で保存
 
  - {success: true, task}を返す
 
  - _要件: 3.1-3.5_
 
- [ ] 4.5 deleteTask()メソッドを実装
 
  - ID でタスクのインデックスを検索
 
  - deletedTask に{task, index}を保存（Undo 用）
 
  - tasks 配列から splice で削除
 
  - storage.saveTasks()で保存
 
  - {success: true}を返す
 
  - _要件: 4.1-4.3, 4.5.1_
 
- [ ] 4.6 undoDelete()メソッドを実装
 
  - deletedTask が存在しない場合は{success: false}を返す
 
  - tasks 配列の元の位置に splice で挿入
 
  - storage.saveTasks()で保存
 
  - clearUndoBuffer()を呼び出し
 
  - {success: true, task}を返す
 
  - _要件: 4.5.2-4.5.3_
 
- [ ] 4.7 clearUndoBuffer()メソッドを実装
 
  - deletedTask を null に設定
 
  - undoTimer が存在すれば clearTimeout
 
  - undoTimer を null に設定
 
  - _要件: 4.5.4-4.5.5_
 
- [ ] 4.8 sortTasks()メソッドを実装
 
  - tasks 配列を createdAt の降順でソート
 
  - _要件: 2.3_
 
- [ ] 4.9 getAllTasks()と getTaskById()を実装
 
  - getAllTasks(): tasks 配列を返す
 
  - getTaskById(id): ID でタスクを検索して返す
 
  - _要件: 2.1_
 
- [ ] 5. プレゼンテーション層の実装（基本機能）
 
  - TaskUI クラスの実装
 
  - タスク追加機能の実装
 
  - タスク一覧表示機能の実装
 
  - _要件: 1.1-1.6, 2.1-2.5_
 
- [ ] 5.1 TaskUI クラスの基本構造を実装
 
  - constructor（taskManager）
 
  - editingTaskId の初期化
 
  - _要件: 3.1_
 
- [ ] 5.2 initialize()メソッドを実装
 
  - setupEventListeners()を呼び出し
 
  - renderTaskList()を呼び出し
 
  - checkLocalStorageAvailability()を呼び出し
 
  - _要件: 1.1, 2.1_
 
- [ ] 5.3 setupEventListeners()メソッドを実装
 
  - 追加ボタンの click イベント
 
  - 入力フィールドの Enter キーイベント
 
  - _要件: 1.1_
 
- [ ] 5.4 handleAddTask()メソッドを実装
 
  - 入力フィールドから値を取得
 
  - taskManager.addTask()を呼び出し
 
  - 成功時: clearInputs()、renderTaskList()、hideError()
 
  - 失敗時: showError()でエラーメッセージ表示
 
  - _要件: 1.1-1.6_
 
- [ ] 5.5 renderTaskList()メソッドを実装
 
  - taskManager.getAllTasks()でタスク取得
 
  - タスクが 0 件の場合は「タスクがありません」を表示
 
  - 各タスクを renderViewRow()または renderEditRow()でレンダリング
 
  - tbody の innerHTML に一括設定
 
  - _要件: 2.1-2.5_
 
- [ ] 5.6 renderViewRow()メソッドを実装
 
  - タスクのタイトル、担当者、期限を表示
 
  - 編集ボタン、削除ボタンを配置
 
  - escapeHtml()で XSS 対策
 
  - Tailwind CSS でスタイリング
 
  - _要件: 2.2, 6.2-6.3_
 
- [ ] 5.7 clearInputs()メソッドを実装
 
  - すべての入力フィールドをクリア
 
  - タイトル入力フィールドにフォーカス
 
  - _要件: 1.5_
 
- [ ] 5.8 showError()と hideError()を実装
 
  - showError(message): エラーメッセージを表示
 
  - hideError(): エラーメッセージを非表示
 
  - _要件: 1.2-1.4, 6.7_
 
- [ ] 5.9 escapeHtml()メソッドを実装
 
  - div エレメントを作成
 
  - textContent に文字列を設定
 
  - innerHTML を返す（XSS 対策）
 
  - _要件: セキュリティ対策_
 
- [ ] 5.10 checkLocalStorageAvailability()を実装
 
  - taskManager.storage.isAvailable()をチェック
 
  - 利用不可の場合は showError()でエラー表示
 
  - _要件: 5.2_
 
- [ ] 6. プレゼンテーション層の実装（編集・削除機能）
 
  - タスク編集機能の実装
 
  - タスク削除機能の実装
 
  - Undo 機能の実装
 
  - _要件: 3.1-3.5, 4.1-4.3, 4.5.1-4.5.6_
 
- [ ] 6.1 handleEditTask()メソッドを実装
 
  - editingTaskId に対象タスクの ID を設定
 
  - renderTaskList()を呼び出し
 
  - _要件: 3.1_
 
- [ ] 6.2 renderEditRow()メソッドを実装
 
  - タスクの各フィールドを入力フィールドとして表示
 
  - 保存ボタン、キャンセルボタンを配置
 
  - escapeHtml()で XSS 対策
 
  - Tailwind CSS でスタイリング（背景色を変更）
 
  - _要件: 3.1, 6.4-6.5_
 
- [ ] 6.3 handleUpdateTask()メソッドを実装
 
  - 編集フィールドから値を取得
 
  - taskManager.updateTask()を呼び出し
 
  - 成功時: editingTaskId を null、renderTaskList()、hideError()
 
  - 失敗時: showError()でエラーメッセージ表示
 
  - _要件: 3.2-3.3, 3.5_
 
- [ ] 6.4 handleCancelEdit()メソッドを実装
 
  - editingTaskId を null に設定
 
  - renderTaskList()を呼び出し
 
  - _要件: 3.4_
 
- [ ] 6.5 handleDeleteTask()メソッドを実装
 
  - taskManager.deleteTask()を呼び出し
 
  - 成功時: renderTaskList()、showUndoNotification()
 
  - 10 秒後に clearUndoBuffer()と hideUndoNotification()を実行するタイマーを設定
 
  - _要件: 4.1-4.3, 4.5.1, 4.5.4_
 
- [ ] 6.6 handleUndo()メソッドを実装
 
  - taskManager.undoDelete()を呼び出し
 
  - 成功時: renderTaskList()、hideUndoNotification()
 
  - _要件: 4.5.2-4.5.3_
 
- [ ] 6.7 handleCloseUndo()メソッドを実装
 
  - taskManager.clearUndoBuffer()を呼び出し
 
  - hideUndoNotification()を呼び出し
 
  - _要件: 4.5.6_
 
- [ ] 6.8 showUndoNotification()と hideUndoNotification()を実装
 
  - showUndoNotification(): Undo 通知バーを表示
 
  - hideUndoNotification(): Undo 通知バーを非表示
 
  - _要件: 4.5.1, 4.5.4, 6.9-6.10_
 
- [ ] 7. アプリケーションエントリーポイントの実装
 
  - DOMContentLoaded イベントでの初期化
 
  - グローバル変数 app の設定
 
  - _要件: 全体_
 
- [ ] 7.1 DOMContentLoaded イベントリスナーを実装
 
  - TaskStorage インスタンス生成
 
  - TaskManager インスタンス生成（TaskStorage を注入）
 
  - TaskUI インスタンス生成（TaskManager を注入）
 
  - taskManager.initialize()を実行
 
  - taskUI.initialize()を実行
 
  - グローバル変数 app に taskUI を格納
 
  - _要件: 全体_
 
- [ ] 8. チェックポイント - 基本機能の動作確認
 
  - すべての基本機能が動作することを確認
 
  - エラーがあれば修正
 
  - _要件: 全体_
 
- [ ]\* 9. E2E テストの実装（Playwright MCP）
 
  - Playwright MCP を使用した E2E テストの実装
 
  - _要件: 9.1-9.8_
 
- [ ]\* 9.1 タスク追加フローのテストを実装
 
  - 入力 → 追加クリック → 表示確認
 
  - _要件: 9.1_
 
- [ ]\* 9.2 タスク編集フローのテストを実装
 
  - 編集クリック → 変更 → 保存 → 表示確認
 
  - _要件: 9.2_
 
- [ ]\* 9.3 タスク削除フローのテストを実装
 
  - 削除クリック → 削除確認
 
  - _要件: 9.3_
 
- [ ]\* 9.4 データ永続性のテストを実装
 
  - タスク追加 → ページリロード → タスク存在確認
 
  - _要件: 9.4_
 
- [ ]\* 9.5 入力検証のテストを実装
 
  - 空フィールド → エラーメッセージ確認
 
  - _要件: 9.5_
 
- [ ]\* 9.6 元に戻す機能フローのテストを実装
 
  - 削除クリック → 「元に戻す」クリック → タスク復元確認
 
  - _要件: 9.6_
 
- [ ]\* 9.7 元に戻すタイムアウトのテストを実装
 
  - 削除 → 10 秒待機 → 通知消失確認
 
  - _要件: 9.7_
 
- [ ] 10. 最終チェックポイント - すべてのテストが通過することを確認
 
  - すべてのテストが通過することを確認
 
  - エラーがあれば修正
 
  - _要件: 9.8_
 
- [ ] 11. デプロイ準備
 
  - index.html ファイルの最終確認
 
  - Amplify へのデプロイ手順の確認
 
  - _要件: 10.1-10.4_
 
- [ ] 11.1 index.html ファイルの最終確認
 
  - すべてのコードが単一ファイルに含まれていることを確認
 
  - Tailwind CSS CDN が正しく読み込まれていることを確認
 
  - ファイルサイズが 15-20KB 程度であることを確認
 
  - _要件: 10.2_
 
- [ ] 11.2 Amplify デプロイ手順の文書化
 
  - Git リポジトリ連携手順
 
  - Amplify アプリ作成手順
 
  - ビルド設定手順
 
  - 手動デプロイ手順（Git なし）
 
  - 公開 URL 確認手順
 
  - _要件: 10.1, 10.3-10.4_
 
---
 
## 実装順序の方針
 
1. **Phase 1（60 分）**: タスク 1〜5（基本 CRUD 機能）
 
   - プロジェクト基盤構築
 
   - データモデル層
 
   - データ永続化層
 
   - ビジネスロジック層
 
   - プレゼンテーション層（基本機能）
 
2. **Phase 2（30 分）**: タスク 6〜7（編集・削除・Undo 機能）
 
   - プレゼンテーション層（編集・削除機能）
 
   - アプリケーションエントリーポイント
 
   - 基本機能の動作確認
 
3. **Phase 3（30 分）**: タスク 9〜11（テスト・デプロイ）
 
   - E2E テスト実装（オプション）
 
   - 最終チェックポイント
 
   - デプロイ準備
 
## 注意事項
 
- オプションタスク（`*`マーク）は時間に余裕がある場合のみ実施
 
- 各チェックポイントで必ず動作確認を行う
 
- エラーが発生した場合は、該当タスクに戻って修正
 
- 2 時間を超えそうな場合は、オプションタスクをスキップ

出力の判定と修正

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

判定結果

requirements.md

判定結果
  • 修正必要
良かった点
  • タスクの追加・一覧表示・編集・削除・データ保持といった、基本となる機能要件は一通り押さえられていた
  • それぞれの機能について「ユーザーストーリー＋受け入れ基準」という形で書かれており、意図は概ね読み取れた
  • 「ブラウザを閉じてもタスクが残っていてほしい」といった、ユーザー視点の要望もきちんと拾えていた
問題点
  • テスト要件（Playwright MCP でどこまで確認するか）やデプロイ要件が定義されておらず、実装後の品質保証やリリースの前提が分からなかった
  • 「視認性が高く読みやすい」「軽量で直感的に使える」といった表現がそのまま残っており、どうなっていれば達成と言えるのかが判断しづらかった
  • Task や保存データの構造（id / title / assignee / dueDate / createdAt など）が明示されておらず、データ設計が仕様として見えない状態だった
  • 「やらないこと」（ログイン機能、サーバーサイド連携など）のスコープが書かれておらず、読み手によって解釈が広がる余地があった
  • バリデーションの細かい条件（どこまでを不正入力とみなすか）や、ユーザーに見せるエラーメッセージが定義されていなかった

 

design.md

判定結果
  • 修正必要
良かった点

  • プレゼンテーション層 / ビジネスロジック層 / データ永続化層 / データモデル層というレイヤー分割自体は初版の時点で明確に分かれていた

  • TaskUI / TaskManager / TaskStorage / Task というクラス分割の方向性は、責務の分離という観点で大きく外れてはいなかった

  • Task の中核フィールド（id / title / assignee / dueDate / createdAt）が初版から揃っており、「タスク 1 件」の単位はブレていなかった

  • タスクの追加・編集・削除・一覧のフロー（UI → TaskManager → TaskStorage → UI 再描画）は、初版のコードでも一通り成立していた

  • 単一 HTML + localStorage + Tailwind（CDN）という「ブラウザローカル完結・軽量シングルページ」の方針は初版から一貫していた

問題点

  • HTML の具体的構造（フォーム・エラー表示・Undo バー・テーブルなど）が書かれておらず、画面要素の ID やレイアウト前提が設計書から読み取れなかった

  • クラス依存関係図や初期化シーケンスがなく、TaskStorage → TaskManager → TaskUI の初期化順・依存関係が仕様として明示されていなかった

  • バリデーション仕様が不十分で、「空欄チェック」以外の要件（YYYY-MM-DD 形式、有効日付、エラーメッセージ）が定義されていなかった

  • XSS 対策・サニタイズ方針が書かれておらず、ユーザー入力の安全な扱いが仕様として欠落していた

  • 元に戻す機能に関する仕様がなく、「データ損失ゼロ」という設計原則との整合が取れていなかった

 

tasks.md

判定結果
  • 修正不要
理由
  • 要件・設計の内容がタスクにきれいにトレースされており、機能的な抜けやダブりが見当たらなかった
  • 実装の依存関係と順序（HTML → モデル → ストレージ → ロジック → UI → エントリーポイント）が自然で、2時間スコープとも矛盾していなかった
  • 各タスクの粒度がほぼ一貫していて「1タスク＝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
次の requirements.md（または design.md）のドラフトをレビューして、問題点を洗い出したうえで修正版を出してください。
 
まずは、以下のロールになりきって、それぞれの立場から「どこが足りていないか／曖昧か」をざっくり列挙してください。
 
- ビジネスアナリスト:
ビジネスゴール・ユーザーストーリー・受け入れ基準の整合を見る
 
- システムアーキテクト:
全体構成・データ構造・永続化の定義が十分かを見る
 
- QAエンジニア:
テスト観点から検証しにくい曖昧さや漏れを確認する
 
- UXデザイナー:
UI/UXの表示要素・ラベル・メッセージの不足を確認する
 
- 開発者:
実装時に迷う部分（フォーマット、バリデーション、保存タイミングなど）を確認する
 
手順:
1. 上記 5 ロールが気づく問題点を箇条書きで列挙
2. その指摘を踏まえてドキュメントの修正版を全文出力する（Markdown）
 
出力は「ロールごとの指摘リスト」と「修正版ドキュメント」の 2 点のみ。

このプロンプトにした理由は次のとおりです。

  • 一つの視点に依存しないため
    要件・設計のレビューは立場によって気づく点が異なるため、複数ロール（BA / アーキテクト / QA / UX / 開発者）を並べて俯瞰させることで、仕様の抜けを網羅的に拾えるようにした。

  • Kiro のレビュー粒度のブレを防ぐため
    「レビューしてください」だけでは深すぎたり浅すぎたり観点が偏りやすいので、ロールをざっくり指定することで、広さと適度な粒度を両立させた。

  • 自分側の確認コストを最小化するため
    短時間でレビューするために「指摘リスト」と「修正版」の2つを見るだけでよい構造として、レビュー負荷を最小にした。

テスト実装

今回の企画では「AI が生成した要件定義・設計に従って本当に動くか」を検証するため、Playwright MCP を使って CRUD + Undo 機能周りの E2E テストを実行しました。実際に行ったテストは次のとおりです。

  • タスク追加のテスト
    タイトル・担当者・期限を入力して追加ボタンを押すと、一覧の先頭にタスクが表示されることを確認。

  • タスク編集のテスト
    編集ボタンを押して内容を書き換え、保存すると、変更後の内容が一覧に正しく反映されることを確認。

  • タスク削除のテスト
    削除ボタンを押したとき、タスクが即座に一覧から消えることを確認。

  • データ永続性のテスト
    タスクを追加 → ページをリロードしても、localStorage から元のタスクが復元されることを確認。

  • 入力検証のテスト
    タイトル・担当者・期限のいずれかが空の状態で追加を試みると、エラーメッセージが表示されることを確認。

  • 元に戻す（Undo）機能のテスト
    タスク削除後に「元に戻す」を押すと、タスクが削除前の位置に戻ることを確認。

  • 元に戻すタイムアウトのテスト
    タスク削除後、10 秒間何も操作しない場合、自動的に Undo 通知が消えることを確認。

成果物

できあがった成果物がこちらです！

タスク入力

入力されたタスクの追加

タスク編集画面

タスク追加画面

タスク削除画面

バリデーション画面

所要時間

２時間５０分

主な機能

盛り込んだ機能はこちらです。

今回のミニアプリは「シンプルだけど毎日の業務でちゃんと使える」ことを意識して実装しました。実際に備えている主な機能は次のとおりです。

1. タスク追加

  • タイトル・担当者・期限を入力して新しいタスクを追加

  • 入力後は自動でフィールドをクリア

  • 未入力の場合はエラーメッセージを表示して追加をブロック

  • 追加されたタスクは常に一覧の先頭に表示

2. タスク一覧

  • すべてのタスクをテーブル形式で表示

  • タイトル／担当者／期限をそれぞれの列で確認可能

  • 作成日時に応じて自動で「新しい順」に並び替え

  • タスクが1件もない場合は「タスクがありません」と表示

3. タスク編集

  • 編集ボタンでその場で編集できるインライン編集方式

  • 保存で内容を更新、キャンセルで編集前の状態に戻せる

  • 編集時にもバリデーションを実行して不正入力を防止

4. タスク削除

  • 削除ボタンで即時削除（確認ダイアログは無し）

  • 後述の Undo 機能と組み合わせてシンプルな操作感を実現

5. 削除の取り消し（Undo）

  • タスク削除後に「元に戻す」通知を表示

  • 10 秒以内なら元の位置に完全復元可能

  • 「×」ボタンで通知を手動で閉じることもできる

  • 10 秒経過すると Undo は自動的に無効

  • 最新の削除 1 件のみ復元できる仕様

6. データ永続化

  • localStorage に自動保存

  • ブラウザを閉じてもタスクが残る

  • 再読み込み時には JSON から復元して一覧を再構築

7. UI/UX

  • 日本語ラベル（追加・編集・削除・保存・キャンセル・元に戻す）を完備

  • 項目名も「タイトル」「担当者」「期限」で統一

  • エラーは画面上部にわかりやすく表示

  • Tailwind CSS を使って軽量なデザインと十分な視認性を両立

8. 単一ページ構成

  • すべての機能を 1 つの HTML だけで完結

  • ページ遷移・リロードなしでスムーズに操作可能

  • JavaScript で UI を動的更新して「サクサク感」を実現

工夫点など

今回のアプリは、操作した瞬間に画面がスッと切り替わる“サクサク感”を強く意識しています。

これをこのように実現しました！

  • 同期的なデータ操作
    　非同期処理による待ち時間をなくし、データの読み書きをその場で完了させることで、操作と結果のズレを感じさせません。

  • メモリファーストの更新戦略
    　画面に表示するデータはまずメモリ上で更新し、永続化は後回しにすることで、ユーザーが結果を即座に確認できる状態を確保しています。

  • 即時の画面反映
    　データが変わったら迷わず画面にも直ちに反映させ、押した瞬間に変化が見える UI 体験を実現しています。

また、誤操作を防ぎながらテンポを落とさない UI 設計を心がけました。
誤ってタスクを削除してしまうと影響が大きいですが、いちいち「削除しますか？」の確認ログがでるとユーザー体験が悪化してしまいます。そこで今回は、

  • 削除はワンクリックで即時反映

  • 必要なら 10 秒以内に戻せる削除通知

という構成にしました。

発見と学び

今回の企画を通して、「AI にどう指示するか」が、想像以上に結果に影響することを実感しました。
ざっくり要望を投げるよりも、

  • 何を作りたいのか

  • どこまでを AI に任せたいのか

  • どの粒度のアウトプットがほしいのか

を先に言葉にしてから投げるだけで、要件定義書や設計書の質がかなり変わりました。

感想

良かった点

  • 要件定義書・設計書・実装タスクという一連の流れを、短時間でもきちんと踏めて有意義な時間でした。

  • 「AI に書かせて、自分がレビューする」という役割分担のイメージがかなりクリアになりました。

  • Playwright で E2E テストを書くところまでを一気通貫で試せました。

苦労した点

  • 最初のプロンプトがふわっとしていると、要件定義や設計がそれなりに曖昧なまま出てきてしまい、何度か書き直しが必要になりました。

  • 「軽い」「サクサク」といった言葉を、どこまで数値や条件に落とし込むかの線引きに悩みました。

  • どこまで仕様を詰めて、どこからは割り切るかの判断が地味に難しかったです。

今後に活かせること

  • 実務でも、要件や設計のドラフトを AI に書かせるときは、「ロール（誰目線か）」と「ゴール（どこまで書いてほしいか）」を最初に明示するといいかなと思いました。
  • 小さな機能追加でも、「やること」「やらないこと」「どうなっていれば完了か」を短く書き出してから AI に渡す習慣をつけるようにしようと思いました。

 

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

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

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

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

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

採用情報
2025-12-08

関連投稿

ページトップへ