AIプログラミング学習 Kiroを覚えて爆速プログラミング #01 プロンプトサンプル

なんだかんだ言っても、Kiroを実際に使ってみてナンボです。 ちなみに、気付いた人もいるかもしれませんが、AIプログラミングの世界は、初めの一歩が「HelloWorld」ではありません。 人間のやる一歩目と、AIの一歩目は、すでにここから違うということを意識しないといけませんね。 今回は、「基本の最小構成プロンプト例」を作って実際に動かしてみたいと思います。

仕様を作らせるタイプ

以下のような感じで、プロンプトを書いていきます。

「○○を作りたい。まず要件を整理して」 「まだコードは書かず、要件と設計だけ作って」 「既存コードを読んでから提案して」

PHPで簡単なアンケート集計APIを作りたい。 まずはコードを書かずに、以下を作ってください。 1. 要件定義 2. 想定ユーザー 3. API設計 4. 実装タスクの分解 既存システムはMySQL + PHP8です。 Kiroはこういうプロンプトから、 要件 → 設計 → タスク を自動生成する設計になっています。

段階分割プロンプト

1. 要件だけ作らせる

ユーザーがCSVをアップロードすると、 集計結果をJSONで返すAPIを作りたい。 まず要件だけ作ってください。 コードはまだ不要です。

2. 設計を作らせる

上記要件をもとに、 アーキテクチャ設計とディレクトリ構成を提案してください。

3. タスク分解

実装タスクを、順番付きのチェックリストにしてください。

4. 実装

タスク1を実装してください。 既存コードと整合性を保ってください。 この「段階的なプロンプト」が、「スペック駆動開発」の基本パターンです。

もう少し実践的なプロンプト例

既存プロジェクトに機能追加する例

このリポジトリにログイン機能を追加したい。 制約: - PHP8.4 - セッション認証 - CSRF対策必須 まず以下を作ってください。 1. 要件 2. DB設計 3. 変更が必要なファイル一覧 4. 実装タスク コードはまだ書かないでください。

このサンプルのポイント

- 制約を書く - まだ実装しないと明示 - 変更範囲を出させる

Kiroっぽい指示プロンプト

Kiro系のワークフローでは、こういうルールを最初に与えることがよくあります。 以下のルールで作業してください。 - まず計画を作る - 承認されるまで実装しない - タスクを1つずつ実行する - 不明点は質問する 実際、コミュニティなどでも、 「ステップを順番に進める」「勝手に実装しない」 といった制約を与えるプロンプトが共有されています。

slashコマンド型の例（Kiro系ワークフロー）

ツールやテンプレートでは、以下の様な流れもあります。 /spec-init ユーザー認証機能 /spec-requirements auth /spec-design auth /spec-tasks auth /spec-impl auth 1.1 こうしたコマンド形式は 仕様 → 設計 → タスク → 実装を順番に進めるワークフローの例 として紹介されています。

おすすめのテンプレ

最後に、コピペして使えるテンプレを用意しました。 ○○を作りたい。 制約: - 言語: - フレームワーク: - DB: 次の順で進めてください。 1. 要件定義 2. 設計 3. 実装タスク分解 まだコードは書かないでください。

Kiroを操作してみる

Kiroがインストールされている状態で、起動した状態からスタートします。

プロジェクトを開く

Githubのリポジトリ または、空フォルダを開く。 Macの場合は、クィックアクションに追加しておくと便利。 ちなみに、クィックアクションの登録は、下記を参照してください。 [VScode] 右クリックのフォルダで開く「クィックアクション」に登録して作業効率化する方法 立ち上がった画面。

最初のSpecsを登録

チャットパネルに「簡単なTODO APIを作りたい。まず要件と設計を作って」と入力 Sessionにチャットでの返答が表示されます。 "requirements.md" というファイルがが出力されました。 内容はこちら。 requirements.md # Requirements Document ## Introduction このドキュメントは、シンプルなTODO管理APIの要件を定義します。ユーザーはこのAPIを通じて、タスクの作成、取得、更新、削除を行うことができます。 ## Glossary - **TODO_API**: タスク管理機能を提供するRESTful APIシステム - **Task**: ユーザーが管理する個別のタスク項目（タイトル、説明、完了状態を含む） - **Client**: APIを利用するアプリケーションまたはユーザー ## Requirements ### Requirement 1: タスクの作成 **User Story:** As a user, I want to create new tasks, so that I can track things I need to do. #### Acceptance Criteria 1. WHEN a Client submits a valid task with title, THE TODO_API SHALL create a new Task and return it with a unique ID 2. WHEN a Client submits a task without a title, THE TODO_API SHALL reject the request and return an error 3. WHEN a Task is created, THE TODO_API SHALL assign a creation timestamp 4. WHEN a Task is created, THE TODO_API SHALL set its completion status to false by default ### Requirement 2: タスクの取得 **User Story:** As a user, I want to retrieve my tasks, so that I can see what I need to do. #### Acceptance Criteria 1. WHEN a Client requests all tasks, THE TODO_API SHALL return a list of all Tasks 2. WHEN a Client requests a specific task by ID, THE TODO_API SHALL return that Task if it exists 3. IF a Client requests a task with a non-existent ID, THEN THE TODO_API SHALL return a not found error 4. WHEN returning tasks, THE TODO_API SHALL include all task properties (ID, title, description, completion status, timestamps) ### Requirement 3: タスクの更新 **User Story:** As a user, I want to update my tasks, so that I can modify details or mark them as complete. #### Acceptance Criteria 1. WHEN a Client updates a task's title or description, THE TODO_API SHALL save the changes and return the updated Task 2. WHEN a Client marks a task as complete, THE TODO_API SHALL update the completion status and record a completion timestamp 3. IF a Client attempts to update a non-existent task, THEN THE TODO_API SHALL return a not found error 4. WHEN a Task is updated, THE TODO_API SHALL update the last modified timestamp ### Requirement 4: タスクの削除 **User Story:** As a user, I want to delete tasks, so that I can remove tasks I no longer need. #### Acceptance Criteria 1. WHEN a Client deletes a task by ID, THE TODO_API SHALL remove the Task from the system 2. IF a Client attempts to delete a non-existent task, THEN THE TODO_API SHALL return a not found error 3. WHEN a Task is deleted, THE TODO_API SHALL return a success confirmation ### Requirement 5: データの永続化 **User Story:** As a user, I want my tasks to be saved, so that they persist across API restarts. #### Acceptance Criteria 1. WHEN a Task is created, updated, or deleted, THE TODO_API SHALL persist the changes to storage 2. WHEN the API restarts, THE TODO_API SHALL load all previously saved Tasks 3. THE TODO_API SHALL maintain data integrity during concurrent operations ### Requirement 6: エラーハンドリング **User Story:** As a developer, I want clear error messages, so that I can understand what went wrong. #### Acceptance Criteria 1. WHEN an error occurs, THE TODO_API SHALL return an appropriate HTTP status code 2. WHEN an error occurs, THE TODO_API SHALL return a descriptive error message 3. IF invalid data is submitted, THEN THE TODO_API SHALL return a validation error with details 4. IF an internal error occurs, THEN THE TODO_API SHALL return a server error without exposing internal details ### Requirement 7: APIレスポンス形式 **User Story:** As a developer, I want consistent API responses, so that I can easily integrate with the API. #### Acceptance Criteria 1. THE TODO_API SHALL return all responses in JSON format 2. THE TODO_API SHALL use standard HTTP methods (GET, POST, PUT, DELETE) 3. THE TODO_API SHALL follow RESTful conventions for endpoint design 4. WHEN returning success responses, THE TODO_API SHALL include appropriate status codes (200, 201, 204) おい！、英語で出てきたので、日本語で作り直してもらいました。 （早く、英語が読める人間になりたい・・・） 日本語修正版 # 要件定義書 ## はじめに このドキュメントは、シンプルなTODO管理APIの要件を定義します。ユーザーはこのAPIを通じて、タスクの作成、取得、更新、削除を行うことができます。 ## 用語集 - **TODO_API**: タスク管理機能を提供するRESTful APIシステム - **タスク**: ユーザーが管理する個別のタスク項目（タイトル、説明、完了状態を含む） - **クライアント**: APIを利用するアプリケーションまたはユーザー ## 要件 ### 要件1: タスクの作成 **ユーザーストーリー:** ユーザーとして、新しいタスクを作成したい。なぜなら、やるべきことを記録できるから。 #### 受入基準 1. WHEN クライアントがタイトル付きの有効なタスクを送信する THEN TODO_APIはタスクを作成し、一意のIDを付けて返す 2. WHEN クライアントがタイトルなしのタスクを送信する THEN TODO_APIはリクエストを拒否し、エラーを返す 3. WHEN タスクが作成される THEN TODO_APIは作成タイムスタンプを割り当てる 4. WHEN タスクが作成される THEN TODO_APIはデフォルトで完了状態をfalseに設定する ### 要件2: タスクの取得 **ユーザーストーリー:** ユーザーとして、自分のタスクを取得したい。なぜなら、やるべきことを確認できるから。 #### 受入基準 1. WHEN クライアントが全タスクをリクエストする THEN TODO_APIは全タスクのリストを返す 2. WHEN クライアントがIDで特定のタスクをリクエストする THEN TODO_APIはそのタスクが存在すれば返す 3. IF クライアントが存在しないIDのタスクをリクエストする THEN TODO_APIは未検出エラーを返す 4. WHEN タスクを返す THEN TODO_APIは全てのタスクプロパティ（ID、タイトル、説明、完了状態、タイムスタンプ）を含める ### 要件3: タスクの更新 **ユーザーストーリー:** ユーザーとして、タスクを更新したい。なぜなら、詳細を変更したり完了マークを付けたりできるから。 #### 受入基準 1. WHEN クライアントがタスクのタイトルまたは説明を更新する THEN TODO_APIは変更を保存し、更新されたタスクを返す 2. WHEN クライアントがタスクを完了としてマークする THEN TODO_APIは完了状態を更新し、完了タイムスタンプを記録する 3. IF クライアントが存在しないタスクを更新しようとする THEN TODO_APIは未検出エラーを返す 4. WHEN タスクが更新される THEN TODO_APIは最終更新タイムスタンプを更新する ### 要件4: タスクの削除 **ユーザーストーリー:** ユーザーとして、タスクを削除したい。なぜなら、不要になったタスクを削除できるから。 #### 受入基準 1. WHEN クライアントがIDでタスクを削除する THEN TODO_APIはシステムからタスクを削除する 2. IF クライアントが存在しないタスクを削除しようとする THEN TODO_APIは未検出エラーを返す 3. WHEN タスクが削除される THEN TODO_APIは成功確認を返す ### 要件5: データの永続化 **ユーザーストーリー:** ユーザーとして、タスクが保存されてほしい。なぜなら、API再起動後も残るから。 #### 受入基準 1. WHEN タスクが作成、更新、または削除される THEN TODO_APIは変更をストレージに永続化する 2. WHEN APIが再起動する THEN TODO_APIは以前に保存された全タスクを読み込む 3. THE TODO_APIは並行操作中もデータ整合性を維持する ### 要件6: エラーハンドリング **ユーザーストーリー:** 開発者として、明確なエラーメッセージがほしい。なぜなら、何が問題だったか理解できるから。 #### 受入基準 1. WHEN エラーが発生する THEN TODO_APIは適切なHTTPステータスコードを返す 2. WHEN エラーが発生する THEN TODO_APIは説明的なエラーメッセージを返す 3. IF 無効なデータが送信される THEN TODO_APIは詳細を含むバリデーションエラーを返す 4. IF 内部エラーが発生する THEN TODO_APIは内部詳細を公開せずにサーバーエラーを返す ### 要件7: APIレスポンス形式 **ユーザーストーリー:** 開発者として、一貫したAPIレスポンスがほしい。なぜなら、APIと簡単に統合できるから。 #### 受入基準 1. THE TODO_APIは全てのレスポンスをJSON形式で返す 2. THE TODO_APIは標準HTTPメソッド（GET、POST、PUT、DELETE）を使用する 3. THE TODO_APIはエンドポイント設計でRESTful規約に従う 4. WHEN 成功レスポンスを返す THEN TODO_APIは適切なステータスコード（200、201、204）を含める 日本語が少しおかしいのではなく、プログラミングチックな記述になっているのを、エンジニアであれば気がつきますね。 次に設計ドキュメントを作ってもらいます。 「設計ドキュメントを作成して」 design.md # 設計ドキュメント: TODO API ## 概要 TODO APIは、RESTful原則に基づいたシンプルなタスク管理APIです。クライアントはHTTPリクエストを通じてタスクの作成、取得、更新、削除（CRUD操作）を行うことができます。データはJSON形式でストレージに永続化され、API再起動後も保持されます。 ## アーキテクチャ システムは以下の3層アーキテクチャで構成されます： ``` ┌─────────────────┐ │ HTTPハンドラ層 │ ← リクエスト/レスポンス処理、バリデーション └────────┬────────┘ │ ┌────────▼────────┐ │ ビジネスロジック層│ ← タスク操作、ビジネスルール └────────┬────────┘ │ ┌────────▼────────┐ │ データ永続化層 │ ← JSONファイルへの読み書き └─────────────────┘ ``` ### 層の責務 1. **HTTPハンドラ層** - HTTPリクエストの受信とルーティング - リクエストボディのバリデーション - HTTPレスポンスの生成 - エラーハンドリングとステータスコード設定 2. **ビジネスロジック層** - タスクのCRUD操作 - ID生成とタイムスタンプ管理 - ビジネスルールの適用 3. **データ永続化層** - タスクデータのJSONファイルへの保存 - JSONファイルからのタスクデータ読み込み - データ整合性の保証 ## コンポーネントとインターフェース ### 1. タスクモデル ```typescript interface Task { id: string; // UUID形式の一意識別子 title: string; // タスクのタイトル（必須） description?: string; // タスクの説明（オプション） completed: boolean; // 完了状態 createdAt: string; // 作成日時（ISO 8601形式） updatedAt: string; // 最終更新日時（ISO 8601形式） completedAt?: string; // 完了日時（ISO 8601形式、完了時のみ） } ``` ### 2. APIエンドポイント #### タスク作成 - **エンドポイント**: `POST /tasks` - **リクエストボディ**: ```json { "title": "string (required)", "description": "string (optional)" } ``` - **成功レスポンス**: `201 Created` ```json { "id": "uuid", "title": "string", "description": "string", "completed": false, "createdAt": "ISO 8601 timestamp", "updatedAt": "ISO 8601 timestamp" } ``` - **エラーレスポンス**: `400 Bad Request` (タイトルが空の場合) #### 全タスク取得 - **エンドポイント**: `GET /tasks` - **成功レスポンス**: `200 OK` ```json [ { /* Task object */ }, { /* Task object */ } ] ``` #### 特定タスク取得 - **エンドポイント**: `GET /tasks/:id` - **成功レスポンス**: `200 OK` (Task object) - **エラーレスポンス**: `404 Not Found` #### タスク更新 - **エンドポイント**: `PUT /tasks/:id` - **リクエストボディ**: ```json { "title": "string (optional)", "description": "string (optional)", "completed": "boolean (optional)" } ``` - **成功レスポンス**: `200 OK` (更新されたTask object) - **エラーレスポンス**: `404 Not Found` #### タスク削除 - **エンドポイント**: `DELETE /tasks/:id` - **成功レスポンス**: `204 No Content` - **エラーレスポンス**: `404 Not Found` ### 3. ストレージインターフェース ```typescript interface TaskStorage { // 全タスクを取得 getAllTasks(): Promise<Task[]>; // IDでタスクを取得 getTaskById(id: string): Promise<Task | null>; // タスクを作成 createTask(task: Task): Promise<Task>; // タスクを更新 updateTask(id: string, updates: Partial<Task>): Promise<Task | null>; // タスクを削除 deleteTask(id: string): Promise<boolean>; } ``` ### 4. バリデーション ```typescript interface TaskValidator { // タスク作成リクエストのバリデーション validateCreateRequest(data: any): ValidationResult; // タスク更新リクエストのバリデーション validateUpdateRequest(data: any): ValidationResult; } interface ValidationResult { valid: boolean; errors?: string[]; } ``` ## データモデル ### タスクデータ構造 タスクは以下のプロパティを持ちます： - **id**: UUID v4形式の一意識別子（システム生成） - **title**: 1文字以上の文字列（必須） - **description**: 任意の文字列（オプション） - **completed**: ブール値（デフォルト: false） - **createdAt**: ISO 8601形式のタイムスタンプ（システム生成） - **updatedAt**: ISO 8601形式のタイムスタンプ（更新時に自動更新） - **completedAt**: ISO 8601形式のタイムスタンプ（完了時のみ設定） ### ストレージ形式 タスクはJSONファイル（`tasks.json`）に配列形式で保存されます： ```json [ { "id": "550e8400-e29b-41d4-a716-446655440000", "title": "買い物に行く", "description": "牛乳とパンを買う", "completed": false, "createdAt": "2024-01-15T10:30:00.000Z", "updatedAt": "2024-01-15T10:30:00.000Z" } ] ``` ## 正確性プロパティ プロパティとは、システムの全ての有効な実行において真であるべき特性や振る舞いのことです。プロパティは、人間が読める仕様と機械で検証可能な正確性保証の橋渡しをします。 ### プロパティ1: タスク作成時のID割り当て *任意の*有効なタイトルを持つタスクに対して、タスクを作成すると、返されるタスクには一意のID（UUID形式）が含まれている必要があります。 **検証: 要件 1.1** ### プロパティ2: 無効なタイトルの拒否 *任意の*空文字列または空白のみの文字列をタイトルとして送信した場合、APIはリクエストを拒否し、400エラーを返す必要があります。 **検証: 要件 1.2** ### プロパティ3: タスク作成時の初期状態 *任意の*タスクを作成した場合、返されるタスクは以下の初期状態を持つ必要があります： - `completed`がfalse - `createdAt`が有効なISO 8601タイムスタンプ - `updatedAt`が`createdAt`と同じ値 **検証: 要件 1.3, 1.4** ### プロパティ4: 全タスク取得の完全性 *任意の*タスクセットに対して、N個のタスクを作成した後に全タスクを取得すると、正確にN個のタスクが返される必要があります。 **検証: 要件 2.1** ### プロパティ5: タスク作成と取得のラウンドトリップ *任意の*タスクに対して、タスクを作成してそのIDで取得すると、作成時と同じタスクデータが返される必要があります。 **検証: 要件 2.2** ### プロパティ6: 存在しないタスク取得時のエラー *任意の*存在しないIDに対して、そのIDでタスクを取得しようとすると、404エラーが返される必要があります。 **検証: 要件 2.3** ### プロパティ7: タスクレスポンスの完全性 *任意の*タスク取得レスポンスに対して、返されるタスクには全ての必須フィールド（id、title、completed、createdAt、updatedAt）が含まれている必要があります。 **検証: 要件 2.4** ### プロパティ8: タスク更新の反映 *任意の*タスクと更新データに対して、タスクを更新すると、返されるタスクには更新された値が反映されている必要があります。 **検証: 要件 3.1** ### プロパティ9: タスク完了時のタイムスタンプ設定 *任意の*タスクに対して、completedをtrueに更新すると、返されるタスクには`completedAt`フィールドが設定され、`updatedAt`が更新されている必要があります。 **検証: 要件 3.2, 3.4** ### プロパティ10: 存在しないタスク更新時のエラー *任意の*存在しないIDに対して、そのIDでタスクを更新しようとすると、404エラーが返される必要があります。 **検証: 要件 3.3** ### プロパティ11: タスク削除の成功 *任意の*タスクに対して、タスクを削除すると、204ステータスが返され、その後そのIDでタスクを取得しようとすると404エラーが返される必要があります。 **検証: 要件 4.1, 4.3** ### プロパティ12: 存在しないタスク削除時のエラー *任意の*存在しないIDに対して、そのIDでタスクを削除しようとすると、404エラーが返される必要があります。 **検証: 要件 4.2** ### プロパティ13: データ永続化のラウンドトリップ *任意の*タスクに対して、タスクを作成してストレージから直接読み込むと、同じタスクデータが存在する必要があります。 **検証: 要件 5.1** ### プロパティ14: API再起動後のデータ保持 *任意の*タスクセットに対して、タスクを作成してAPIを再起動した後に全タスクを取得すると、作成したタスクが全て存在する必要があります。 **検証: 要件 5.2** ### プロパティ15: エラー時の適切なステータスコード *任意の*エラー条件に対して、APIは適切なHTTPステータスコード（400、404、500など）を返す必要があります。 **検証: 要件 6.1** ### プロパティ16: エラー時のメッセージ存在 *任意の*エラー条件に対して、APIは空でないエラーメッセージを含むレスポンスを返す必要があります。 **検証: 要件 6.2** ### プロパティ17: バリデーションエラーの詳細 *任意の*無効なリクエストデータに対して、APIはバリデーションエラーの詳細を含む400エラーを返す必要があります。 **検証: 要件 6.3** ### プロパティ18: 内部エラー時の情報隠蔽 *任意の*内部エラーに対して、APIは500エラーを返し、レスポンスにはスタックトレースやデータベース詳細などの内部情報が含まれていない必要があります。 **検証: 要件 6.4** ### プロパティ19: JSON形式のレスポンス *任意の*APIリクエストに対して、レスポンスのContent-Typeは`application/json`である必要があります。 **検証: 要件 7.1** ### プロパティ20: 成功時の適切なステータスコード *任意の*成功した操作に対して、APIは適切なステータスコード（GET: 200、POST: 201、DELETE: 204）を返す必要があります。 **検証: 要件 7.4** ## エラーハンドリング ### エラーレスポンス形式 全てのエラーレスポンスは以下の形式に従います： ```json { "error": { "code": "ERROR_CODE", "message": "人間が読めるエラーメッセージ", "details": {} // オプション：追加の詳細情報 } } ``` ### エラーコード一覧 | HTTPステータス | エラーコード | 説明 | |--------------|------------|------| | 400 | VALIDATION_ERROR | リクエストデータのバリデーション失敗 | | 400 | INVALID_REQUEST | 不正なリクエスト形式 | | 404 | TASK_NOT_FOUND | 指定されたIDのタスクが存在しない | | 500 | INTERNAL_ERROR | サーバー内部エラー | ### エラー処理戦略 1. **バリデーションエラー** - リクエストデータを受信時に即座にバリデーション - 全てのバリデーションエラーを収集して一度に返す - 具体的なフィールド名とエラー理由を含める 2. **リソース未検出エラー** - 存在しないIDへのアクセス時に404を返す - エラーメッセージに要求されたIDを含める 3. **内部エラー** - 予期しないエラーをキャッチ - エラーをログに記録（詳細情報含む） - クライアントには一般的なエラーメッセージのみ返す ## テスト戦略 ### デュアルテストアプローチ このAPIの正確性を保証するため、ユニットテストとプロパティベーステストの両方を使用します： - **ユニットテスト**: 特定の例、エッジケース、エラー条件を検証 - **プロパティベーステスト**: 全ての入力に対する普遍的なプロパティを検証 両方のアプローチは補完的であり、包括的なカバレッジに必要です。 ### ユニットテストの焦点 ユニットテストは以下に焦点を当てます： - 特定の例（例：特定のタイトルでタスクを作成） - コンポーネント間の統合ポイント - エッジケースとエラー条件 - 境界値（例：空文字列、非常に長い文字列） プロパティベーステストが多くの入力をカバーするため、過度にユニットテストを書くことは避けます。 ### プロパティベーステストの設定 - **テストライブラリ**: 実装言語に応じて選択 - TypeScript/JavaScript: fast-check - Python: Hypothesis - Java: jqwik - Go: gopter - **イテレーション数**: 各プロパティテストは最小100回実行（ランダム化のため） - **タグ形式**: 各テストには設計ドキュメントのプロパティを参照するコメントを付ける ``` // Feature: todo-api, Property 1: タスク作成時のID割り当て ``` - **実装ルール**: - 各正確性プロパティは単一のプロパティベーステストで実装 - テストは設計ドキュメントのプロパティ番号を明示的に参照 ### テストカバレッジ目標 - **HTTPハンドラ層**: 全エンドポイント、全HTTPメソッド - **ビジネスロジック層**: 全CRUD操作、全バリデーションルール - **データ永続化層**: 読み書き操作、エラーハンドリング - **エンドツーエンド**: 主要なユーザーフロー（作成→取得→更新→削除） ### テスト実行戦略 1. **開発時**: 各コンポーネント実装後に対応するテストを実行 2. **コミット前**: 全ユニットテストとプロパティベーステストを実行 3. **CI/CD**: 全テストスイートを自動実行 4. **プロパティテスト**: 定期的にイテレーション数を増やして実行（例：1000回） そして次は、実装タスクを作ってもらいます。 「実装タスクを作って。」 tasks.md # 実装計画: TODO API ## 概要 この実装計画は、RESTful TODO APIを段階的に構築するためのタスクリストです。各タスクは前のタスクの上に構築され、最終的に完全に機能するAPIが完成します。 ## タスク - [ ] 1. プロジェクト構造とコアインターフェースのセットアップ - TypeScriptプロジェクトの初期化（package.json、tsconfig.json） - 必要な依存関係のインストール（Express、UUID、日付処理ライブラリ） - ディレクトリ構造の作成（src/models、src/handlers、src/storage、src/validators） - Taskインターフェースの定義（src/models/task.ts） - テストフレームワークのセットアップ（Jest、fast-check） - _要件: 1.1, 2.1, 7.1_ - [ ] 2. データモデルとバリデーションの実装 - [ ] 2.1 コアデータモデルインターフェースと型の作成 - TaskStorageインターフェースの定義 - TaskValidatorインターフェースの定義 - ValidationResult型の定義 - _要件: 1.1, 1.2, 2.4_ - [ ]* 2.2 データモデルのプロパティテスト - **プロパティ7: タスクレスポンスの完全性** - **検証: 要件 2.4** - [ ] 2.3 バリデーション機能の実装 - タスク作成リクエストのバリデーション関数 - タスク更新リクエストのバリデーション関数 - タイトルの空チェック（空文字列、空白のみを拒否） - _要件: 1.2, 6.3_ - [ ]* 2.4 バリデーションのプロパティテスト - **プロパティ2: 無効なタイトルの拒否** - **検証: 要件 1.2** - [ ]* 2.5 バリデーションのプロパティテスト - **プロパティ17: バリデーションエラーの詳細** - **検証: 要件 6.3** - [ ] 3. データ永続化層の実装 - [ ] 3.1 JSONファイルストレージの実装 - TaskStorageインターフェースの実装クラス作成 - JSONファイルへの読み書き機能 - タスクの作成、取得、更新、削除メソッド - エラーハンドリング（ファイル読み書きエラー） - _要件: 5.1, 5.2_ - [ ]* 3.2 ストレージのプロパティテスト - **プロパティ13: データ永続化のラウンドトリップ** - **検証: 要件 5.1** - [ ]* 3.3 ストレージのプロパティテスト - **プロパティ5: タスク作成と取得のラウンドトリップ** - **検証: 要件 2.2** - [ ] 4. チェックポイント - 基本機能のテスト - 全てのテストが通ることを確認し、質問があればユーザーに尋ねる。 - [ ] 5. ビジネスロジック層の実装 - [ ] 5.1 タスク作成ロジックの実装 - UUID生成機能 - タイムスタンプ生成（ISO 8601形式） - デフォルト値の設定（completed: false） - _要件: 1.1, 1.3, 1.4_ - [ ]* 5.2 タスク作成のプロパティテスト - **プロパティ1: タスク作成時のID割り当て** - **検証: 要件 1.1** - [ ]* 5.3 タスク作成のプロパティテスト - **プロパティ3: タスク作成時の初期状態** - **検証: 要件 1.3, 1.4** - [ ] 5.4 タスク取得ロジックの実装 - 全タスク取得機能 - ID指定タスク取得機能 - 存在しないタスクのエラーハンドリング - _要件: 2.1, 2.2, 2.3_ - [ ]* 5.5 タスク取得のプロパティテスト - **プロパティ4: 全タスク取得の完全性** - **検証: 要件 2.1** - [ ]* 5.6 タスク取得のプロパティテスト - **プロパティ6: 存在しないタスク取得時のエラー** - **検証: 要件 2.3** - [ ] 5.7 タスク更新ロジックの実装 - タスクフィールド更新機能 - 完了状態更新時のcompletedAt設定 - updatedAtタイムスタンプの自動更新 - 存在しないタスクのエラーハンドリング - _要件: 3.1, 3.2, 3.3, 3.4_ - [ ]* 5.8 タスク更新のプロパティテスト - **プロパティ8: タスク更新の反映** - **検証: 要件 3.1** - [ ]* 5.9 タスク更新のプロパティテスト - **プロパティ9: タスク完了時のタイムスタンプ設定** - **検証: 要件 3.2, 3.4** - [ ]* 5.10 タスク更新のプロパティテスト - **プロパティ10: 存在しないタスク更新時のエラー** - **検証: 要件 3.3** - [ ] 5.11 タスク削除ロジックの実装 - タスク削除機能 - 存在しないタスクのエラーハンドリング - _要件: 4.1, 4.2, 4.3_ - [ ]* 5.12 タスク削除のプロパティテスト - **プロパティ11: タスク削除の成功** - **検証: 要件 4.1, 4.3** - [ ]* 5.13 タスク削除のプロパティテスト - **プロパティ12: 存在しないタスク削除時のエラー** - **検証: 要件 4.2** - [ ] 6. チェックポイント - ビジネスロジックのテスト - 全てのテストが通ることを確認し、質問があればユーザーに尋ねる。 - [ ] 7. HTTPハンドラ層の実装 - [ ] 7.1 Expressアプリケーションのセットアップ - Expressアプリの初期化 - JSONボディパーサーの設定 - エラーハンドリングミドルウェアの作成 - _要件: 7.1, 7.2_ - [ ] 7.2 タスク作成エンドポイントの実装（POST /tasks） - リクエストボディのバリデーション - ビジネスロジック層の呼び出し - 201ステータスとタスクデータのレスポンス - エラーハンドリング（400エラー） - _要件: 1.1, 1.2, 7.4_ - [ ]* 7.3 タスク作成エンドポイントのユニットテスト - 有効なタスク作成のテスト - 無効なタイトルでのエラーテスト - _要件: 1.1, 1.2_ - [ ] 7.4 全タスク取得エンドポイントの実装（GET /tasks） - ビジネスロジック層の呼び出し - 200ステータスとタスクリストのレスポンス - _要件: 2.1, 7.4_ - [ ] 7.5 特定タスク取得エンドポイントの実装（GET /tasks/:id） - パスパラメータからIDを取得 - ビジネスロジック層の呼び出し - 200ステータスとタスクデータのレスポンス - エラーハンドリング（404エラー） - _要件: 2.2, 2.3, 7.4_ - [ ]* 7.6 タスク取得エンドポイントのユニットテスト - 全タスク取得のテスト - 特定タスク取得のテスト - 存在しないIDでの404エラーテスト - _要件: 2.1, 2.2, 2.3_ - [ ] 7.7 タスク更新エンドポイントの実装（PUT /tasks/:id） - パスパラメータからIDを取得 - リクエストボディのバリデーション - ビジネスロジック層の呼び出し - 200ステータスと更新されたタスクのレスポンス - エラーハンドリング（404エラー） - _要件: 3.1, 3.2, 3.3, 7.4_ - [ ]* 7.8 タスク更新エンドポイントのユニットテスト - タスク更新のテスト - 完了状態更新のテスト - 存在しないIDでの404エラーテスト - _要件: 3.1, 3.2, 3.3_ - [ ] 7.9 タスク削除エンドポイントの実装（DELETE /tasks/:id） - パスパラメータからIDを取得 - ビジネスロジック層の呼び出し - 204ステータスのレスポンス - エラーハンドリング（404エラー） - _要件: 4.1, 4.2, 4.3, 7.4_ - [ ]* 7.10 タスク削除エンドポイントのユニットテスト - タスク削除のテスト - 存在しないIDでの404エラーテスト - _要件: 4.1, 4.2_ - [ ] 8. エラーハンドリングの実装 - [ ] 8.1 統一エラーレスポンス形式の実装 - エラーレスポンスビルダー関数 - エラーコードの定義 - エラーメッセージの標準化 - _要件: 6.1, 6.2_ - [ ]* 8.2 エラーハンドリングのプロパティテスト - **プロパティ15: エラー時の適切なステータスコード** - **検証: 要件 6.1** - [ ]* 8.3 エラーハンドリングのプロパティテスト - **プロパティ16: エラー時のメッセージ存在** - **検証: 要件 6.2** - [ ] 8.4 内部エラーハンドリングの実装 - グローバルエラーハンドラーミドルウェア - エラーログ機能 - 内部詳細の隠蔽 - _要件: 6.4_ - [ ]* 8.5 内部エラーのプロパティテスト - **プロパティ18: 内部エラー時の情報隠蔽** - **検証: 要件 6.4** - [ ] 9. レスポンス形式の統一 - [ ] 9.1 JSON形式レスポンスの確保 - Content-Typeヘッダーの設定 - 全エンドポイントでのJSON形式確認 - _要件: 7.1_ - [ ]* 9.2 レスポンス形式のプロパティテスト - **プロパティ19: JSON形式のレスポンス** - **検証: 要件 7.1** - [ ]* 9.3 ステータスコードのプロパティテスト - **プロパティ20: 成功時の適切なステータスコード** - **検証: 要件 7.4** - [ ] 10. 統合とエントリーポイント - [ ] 10.1 全コンポーネントの統合 - メインアプリケーションファイルの作成（src/index.ts） - 全層の接続（ハンドラ→ロジック→ストレージ） - サーバー起動コードの実装 - 環境変数の設定（ポート、ストレージパス） - _要件: 全要件_ - [ ]* 10.2 統合テスト - エンドツーエンドフローのテスト（作成→取得→更新→削除） - API再起動後のデータ保持テスト - _要件: 5.2_ - [ ]* 10.3 API再起動のプロパティテスト - **プロパティ14: API再起動後のデータ保持** - **検証: 要件 5.2** - [ ] 11. 最終チェックポイント - 全テストの実行 - 全てのテストが通ることを確認し、質問があればユーザーに尋ねる。 ## 注意事項 - `*`マークが付いたタスクはオプションで、より速いMVP開発のためにスキップ可能です - 各タスクは特定の要件を参照しており、トレーサビリティを確保しています - チェックポイントは段階的な検証を保証します - プロパティテストは普遍的な正確性プロパティを検証します - ユニットテストは特定の例とエッジケースを検証します もう少し具体的な内容で修正してみます。 「このシステムを、以下の条件で修正して - PHP8.4 - MySQL - フレームワークなし - Dockerで起動できる様にする。（開発環境）」 ※長くなるので、修正後のドキュメントは掲載しません。

タスク単位で実装させる

一度で全部をやらせないのがコツです。

- 「タスク1を実装して」 - 生成されたコードを確認 - 問題なければ次へ

これを繰り返します。 実際のコードを書き進めていくと、時折「Run」ボタンのクリックを求められます。 AIが、テスト実行するためのDockerの実行の様ですが、その時に、Errorが発生することもあり、それを修正していくのが、チャット画面で確認できます。 イメージとして、高速に、コーディングしているのが見れて、これはこれで面白いですね。 どうやら、テスト駆動開発を進めているようですね。 なので、開発が終わると、テストコードも出来上がっているような感じなんでしょうね。 画面右側のチャットで進捗確認ができて、 tasks.mdのファイルも、実装ずみのチェックもちゃんと書き換えられていきます。（リアルタイムに） まるで有能な部下が作業するのを見守っているような感覚にすらなります。

実行完了

Macbook M2で2時間ぐらい掛かりましたが（途中、RUNボタン待ち時間が長い時もあったので・・・）無事に終了しました。 ブラウザアクセスすると、こんな画面が表示されました。 http://localhost:8080/tasks

[{"id":"c0362a06-7b5f-4e1b-85d2-5f5c078d6a1f","title":"Review pull requests","description":"Check PRs #123 and #456","completed":false,"createdAt":"2026-02-07T07:52:58Z","updatedAt":"2026-02-07T07:52:58Z","completedAt":null},{"id":"2f016578-56de-439a-88c3-3ea9a67daa29","title":"Write documentation","description":null,"completed":false,"createdAt":"2026-02-07T07:52:52Z","updatedAt":"2026-02-07T07:52:52Z","completedAt":null},{"id":"adf29ac5-087a-4784-962e-d34c88e76666","title":"Buy groceries","description":"Milk, eggs, bread","completed":false,"createdAt":"2026-02-07T07:52:45Z","updatedAt":"2026-02-07T07:52:45Z","completedAt":null}]

今回は、HTMLフロントエンドの指示がなかったので、ビジュアルがないのですが、バックエンド処理が完了しているのがわかりました。

あとがき

プログラミングのAI生成を体験してみましたが、なんかあっけないというか、ほぼ何もせずに自動でできてしまうので、こうした環境構築をするだけでここまでできるということにまずは感動できると思います。 でも、仕様書やらタスクの内容確認が、技術事態を知らないと何も判断できないと思うので、改めて自身の技術レベルに応じたクオリティが出来上がるイメージを持ちました。 あとは、Specsの指示とタスクの確認スキルを上げれば、ある程度のソフトウェアは簡単に作り上げることができそうですね。 うちの会社に、エンジニアの従業員が増えた感覚が持てたので、それなりの課金でもすることにしましょうか。