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

カテゴリ一 AWS ブログ 開発 AI クラウド デザイン
2025-12-16

こんにちは。エンジニアのサミーラです。

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

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

自己紹介

クラウド開発事業部所属のサミーラです。
普段は製品サービスYouWireを担当しています。エンジニア歴は7年で、主にPHP, CSS, Javascript, MySQL, Apacheを使った開発をしています。

普段使ってるAIツール

日常的に以下のAIツールを活用しています。
・Claude Code: 毎日・開発、障害調査、設計、運用、テスト

企画概要とゴール

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

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

# 禁止事項：エディタで直接コードを書く・修正すること
– 許されるのは「AIへの指示」のみ。人間の役割は「Architect/Reviewer」、つまりAIをマネジメントして成果物を判断することです。

# お題
社員の生産性を上げる日々の業務管理ツールを作ってください。

## 必須要件：
– KiroとPlaywright MCPを使うこと
– スペック駆動開発を行うこと（vibe codingはNG）
– Todoを追加・編集・削除できること
– 追加は画面上部のフォームから可能
– 編集・削除は各行の操作ボタンで行う
– 一覧でTodoを確認できること
– 一覧にはタイトル、担当者、期限を表示
– サクサク軽く操作できること
– 画面は1ページで完結
– PlaywrightでCRUD周りのテストをすること

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

作業プロセス

要件の理解と整理

まず、お客様からのご要望を拝見しました。

そして、お客様の要件を満たす方法、さらにはユーザーエクスペリエンス（UX）の観点からその要件の品質をいかに向上させるかについて深く考えました。

その上で、私はインターネットでシンプル（簡易的）なタスク管理ツールを探しました。

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

運営への質問事項

今回のご依頼はシンプルなタスク管理アプリケーションの作成であったため、私は受け取った要件で十分だと考えました。また、お客様ご自身も必要なツールについて明確な理解をお持ちではないだろうと推測しました。

そのため、私はインターネットでタスク管理ツールについて調査し、一般的で使いやすいアプリケーションをお客様に提供することを計画しました。このような理由から、私は担当部署（あるいは管理者）に質問をすることはありませんでした。

Specs定義

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

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

私自身、これまでKiro を使って開発を進めた経験がなかったため、どのように指示を与えればよいのか最初は分かりませんでした。

そこでまず、「どのようなアプリケーションを作りたいのか」を簡単に説明し、Kiro が理解できる形式のドキュメントを作成してほしいと依頼しました。

そのドキュメント形式に沿って必要な要件を埋めていくことで、Kiro に正確に意図を伝えられるようにしました。

Kiroへの指示

I need to create a single-page application for a simple task management tool. First, I need to design the application. What details do you need in order to design a production-level application? Could you give me a template for a design document that you can easily understand, so that I can fill it in?

出力の判定と修正

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

判定結果

デザインをレビューしたところ、いくつか細かい修正が必要な点が見つかったため、修正してほしいポイントを Kiro に伝えました。その後、指示内容に基づいて、Kiro は期待どおりにデザインを更新してくれました。

良かった点

要件定義書や設計書を作成するために、こちらから細かい指示を与える必要はありませんでしたが、Kiro 自身が要件分析からプロジェクトを開始する点は、AI ベースのコード編集ツールとして非常に良い取り組みだと感じました。

また、タスクリストが作成され、各タスクを内容を確認しながら個別に実行できるため、アプリケーションがどのように構築されていくのかを深く理解することができました。

予想どおり、Kiro は要件に基づいた設計を提示してくれただけでなく、要件自体についても整理した内容を提供してくれました。

問題点

Kiro は非常に網羅的な設計ドキュメントを作成してくれるため、内容を読み込み、理解するまでにかなりの時間がかかります。

また、テスト設計に関しては、すべてのテストシナリオが網羅されているかどうかを判断するのが難しいと感じました。

Kiroとの対話

私が考えていた内容と、Kiro が生成した設計との間にいくつかのズレがあったため、指定したポイントに基づいて修正を行うよう 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
I need to add following requirements as well.
Glossary
・Task: should have the task title, start date, end date, update at as well.
・Subtask: a task with a parent task.
 
Requirement 1: Task Creation
・There should be a form with a single text field and a button to create a main task.
・Task should be able to have subtasks and subtasks can have subtasks. The tasks should be able to divide into two sub layers.
・When user click on a task a dropdown should be displayed with the subtasks and create new subtask option
・Tasks should be stored in the server side.
 
Requirement 2: Task Display
・Task Management System should retrieve all tasks from server
・Task Management System should show each task's title, status, end date only.
・Tasks which has passed the end date but still not completed should be displayed in red, while not started is blue and going on is green
・Tasks should display in reverse chronological order by end date.
・Tasks should display in a list that each task has a drop down which displays the sub tasks of that particular task
 
Requirement 3: Task Status Management
・should be able to mark task as not started, going on, completed.
・task should be able to change to any status at any time. There is NO functionality like when task is completed it can not be mark back as going on.
・Task details like status should be stored in the server side.
 
Requirement 6: Data Persistence
・Task Management System SHALL synchronize the current state to Server side storage

開発およびテストは Docker コンテナを使用して自分の PC 上で行う必要があったため、開発・テスト用の Docker 開発コンテナ環境を構築するよう Kiro に依頼しました。

1
2
I need to do this implementation in dev container.
I need to setup project inside the container. Create the project inside the container.

タスクを実行した際、Kiro は Docker ホスト（自分の PC）上で再度プロジェクトのセットアップを行い、「npm install」などのプロジェクト関連コマンドをホストマシン上で実行し始めました。本来は Docker コンテナ内でコマンドを実行してほしかったため、その点を Kiro に依頼しました。

1
Execute all the tasks and continue update. Run any command required inside the docker container. Only ask me the commands on host machine.

Kiro がアプリを実装した後に内容を確認したところ、いくつか修正が必要な点が見つかりました。そのため、それらの修正を行うよう Kiro に依頼しました。

1
2
3
4
5
6
7
8
9
I need to update the screen design with following details.
・Primary color should be ambiance purple. And use different variations of ambiance purple.
・Title of the app should be "My tasks"
・Sub tasks should be able to display as an accordions below the main task
・There should be an arrow like symbol to mention there are sub tasks.
 
All the changes that I do on the screen, like changing task status, deleting a task is happened in the background but is it not reflected on the screen without reloading the browser. I need to immediately reflect any operation that I do on the screen like when I delete a task or sub task, it should be disappear from the screen, when I select a status the selected status should be displayed on the screen.
 
I should be able to add and change a due date to each task and sub task. And the due date should be displayed on the task.

Kiro は自らテストケースを作成し、テストの実装まで行ってくれました。しかし、Playwright を使用したテストケースは作成されていなかったため、Playwright を使ってテストケースの作成および実装を行うよう、改めて Kiro に依頼しました。

1
Design the complete set of test cases to test this application. Create the test design document fist. Design the test to use "playwrite".

テスト実装

本タスク管理アプリでは、Playwright を用いた包括的な E2E（エンドツーエンド）テストスイートを構築しました。

全体で 34 のテストケースを実装し、4 つの主要なテストカテゴリに分けて機能・デザイン・レスポンシブ対応を網羅的に検証しています。

テストは Chrome / Firefox / Safari / Edge / モバイル Chrome / モバイル Safari の 6 種類のブラウザ・デバイスで実行され、モバイル・タブレット・デスクトップの各画面サイズに対応した動作確認を行っています。

テスト内容の主なカバー範囲

  • タスク作成・編集・削除などの基本機能
  • ステータス変更やリアルタイム UI 更新
  • サブタスクの階層構造とアニメーション挙動
  • レスポンシブデザインと操作性
  • 入力バリデーションやエラーハンドリング
  • デザイン（カラー、レイアウト、アニメーション）の一貫性

テスト設計の特徴

  • Page Object Model を採用し、保守性の高いテスト構成
  • TypeScript による型安全なテスト実装
  • 並列実行と 自動リトライ による安定したテスト運用
  • テスト失敗時の スクリーンショット・動画記録・HTML レポートの自動生成

品質保証の効果

このテストスイートにより、

  • ユーザー操作の主要なフローがすべて自動検証され
  • ブラウザやデバイスが変わっても一貫した体験を提供でき
  • UI・機能・レスポンシブ対応の品質を継続的に担保できる

という 高い信頼性と再現性のある品質保証環境を実現しています。

成果物

メイン画面

メイン画面（サブタスク含め）

サブタスクを追加

所要時間

6時間

主な機能

  • タスク作成・編集・削除
  • タスクで、タスクのステータス、完了日設定可能。
  • サブタスク作成・編集・削除
  • サブタスクで、タスクのステータス、完了日設定可能。

工夫点など

  • 使いやすさを高める高度なタスク管理機能
    • ドラッグ＆ドロップによる並び替え、タスクテンプレート、通知機能、共同編集、時間計測などにより、生産性と柔軟性を大幅に向上させます。
  • リアルタイムかつオフライン対応のアーキテクチャ
    • WebSocket を用いたリアルタイム共同編集と、オフラインファースト設計により、ネットワーク状況に依存しない快適な利用体験を実現します。
  • 大量データに対応する検索・一括操作機能
    • 高度な全文検索やフィルタリング、一括更新・削除などの機能により、多数のタスクも効率的に管理できます。
  • ネイティブアプリのように使える PWA 化
    • PWA 対応により、インストール可能なアプリとして利用でき、プッシュ通知やバックグラウンド同期などの機能を提供します。
  • スケーラブルで高速なパフォーマンス設計
    • 仮想スクロール、楽観的 UI 更新、キャッシュ戦略、遅延読み込み、DB 最適化により、大規模データでも快適な動作を維持します。

感想

良かった点

これまで、AI を使ってアプリケーションを一から実装した経験はありませんでしたが、このプロジェクトを通じて、AI を活用してアプリをゼロから構築する実践的な経験を得ることができました。

苦労した点

指示を出しても、Kiro が問題を修正してくれないことが時々ありました。そのため、どのように指示を出せば Kiro に正しく作業してもらえるのかを工夫する必要がありました。

今後に活かせること

現在の AI 時代において、ソフトウェア開発にAIを活用することはもはや当たり前になっています。今回のプロジェクトを通じて、新規プロジェクトだけでなく既存プロジェクトに対しても、AI を問題なく活用できることを実感しました（特に既存プロジェクトでの活用には良い経験があります）。

一方で、開発に時間を要するフェーズは大きく変化してきています。
AI 開発では、実装そのものよりも、設計ドキュメントをレビューし、適切なプロンプトで修正指示を出すことに、より多くの時間を使う必要があると感じました。

この記事が、少しでもみなさんのにお役に立てば幸いです。
ここまでお読みいただき、ありがとうございました！

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

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

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

採用情報
2025-12-16

関連投稿

ページトップへ