Kiroとおしゃべりしてみた-1.とりあえず作ってみた-

Posted at 2025-12-10

はじめに

AI開発アシスタント「Kiro」の機能を試すため、タスク管理CLIアプリケーションを開発しました。

この記事では、要件定義から実装・テストまでの全工程をKiroと対話しながら進めた体験記録をお届けします。特に以下の点に焦点を当てています：

🤖 Kiroとの対話プロセス: 実際のやり取りと学んだこと
📋 仕様駆動開発: EARS形式の要件定義からプロパティベーステストまで
🐛 エラー解決体験: 発生した問題とKiroによる解決過程
💡 実用性の評価: 実際の開発での使いどころと課題

結論を先に言うと: Kiroは非常に優秀な開発パートナーですが、生成コードの理解と品質担保には人間のスキルが重要です。

🎯 プロジェクト概要

プロジェクト名: kirotask
目的: Kiroの主要機能（仕様駆動開発、プロパティベーステスト、コード生成）を体験する
成果物: コマンドラインで動作するタスク管理ツール
Kiro: Freeプランで利用

主な機能

✅ タスクの追加・削除・更新
✅ 完了状態の切り替え
✅ フィルタリング（全て/完了/未完了）
✅ JSONファイルへの永続化

筆者のスキル

Kiro初体験
コマンドラインで動作するツール作成初体験
Amazon Q Developerでの開発経験あり

📋 フェーズ1: 要件定義

プロジェクト決定の経緯

まず、何を作るかをKiroに相談しました。

私

Kiroの様々な機能を試したいです。それにふさわしいサンプルコードを作成したい。

Kiro

なるほど！Kiroの機能を試すためのサンプルプロジェクトを作りたいんですね。

Kiroの主要機能を活用できるサンプルとして、タスク管理CLIを作成するのはいかがでしょうか？

このプロジェクトで以下のKiro機能を試せます：

- 仕様駆動開発: 要件→設計→タスクリストの作成
- プロパティベーステスト: データの整合性を検証
- コード生成: 複数ファイルの自動生成
- テスト自動化: ユニットテストとプロパティテストの両方
- リファクタリング: コードの改善提案

機能例：
- タスクの追加・削除・更新
- タスクの完了/未完了の切り替え
- タスクのフィルタリング（完了済み、未完了など）
- JSONファイルへの永続化

この内容で進めてよろしいですか？それとも、別のアイデアがあれば教えてください！

私の判断: お任せして進めてみることにしました。

要件定義書の作成

まずは要件定義書を作成してくれます。
簡単なサマリと修正すべきことがないか確認するよう促してくれました。

Kiro

要件定義書を作成しました。この文書には以下が含まれています：

・7つの主要要件：タスクの追加、削除、完了状態の切り替え、更新、表示、永続化、CLIインターフェース
・EARS形式の受け入れ基準：各要件に対して明確で検証可能な基準
・用語集：システムで使用する技術用語の定義
この要件で問題ありませんか？修正が必要な箇所があれば教えてください。よろしければ、次の設計フェーズに進みます。

requirements.md

# 要件定義書

## はじめに

本システムは、コマンドラインインターフェース（CLI）を通じてタスクを管理するアプリケーションです。ユーザーはタスクの追加、削除、更新、完了状態の切り替え、フィルタリング、および一覧表示を行うことができます。すべてのタスクデータはJSONファイルに永続化され、アプリケーションの再起動後もデータが保持されます。

## 用語集

- **TaskManagerCLI**: タスク管理を行うコマンドラインアプリケーションシステム
- **Task**: ユーザーが管理する作業項目。ID、説明、完了状態を持つ
- **TaskRepository**: タスクデータの永続化を担当するコンポーネント
- **JSONストレージ**: タスクデータを保存するJSONファイル形式のストレージ

## 要件

### 要件1

**ユーザーストーリー:** ユーザーとして、新しいタスクをリストに追加したい。そうすることで、やるべきことを記録できる。

#### 受け入れ基準

1. WHEN ユーザーが有効なタスク説明を提供する THEN TaskManagerCLI SHALL 新しいタスクを作成し、一意のIDを割り当てる
2. WHEN ユーザーが空のタスク説明を提供する THEN TaskManagerCLI SHALL タスクの追加を拒否し、エラーメッセージを表示する
3. WHEN 新しいタスクが追加される THEN TaskManagerCLI SHALL タスクの完了状態を未完了として初期化する
4. WHEN タスクが追加される THEN TaskManagerCLI SHALL タスクをJSONストレージに即座に永続化する

・・・中略・・・

### 要件3

**ユーザーストーリー:** ユーザーとして、タスクの完了状態を切り替えたい。そうすることで、作業の進捗を追跡できる。

#### 受け入れ基準

1. WHEN ユーザーが未完了タスクのIDを指定する THEN TaskManagerCLI SHALL そのタスクを完了状態に変更する
2. WHEN ユーザーが完了済みタスクのIDを指定する THEN TaskManagerCLI SHALL そのタスクを未完了状態に変更する
3. WHEN タスクの完了状態が変更される THEN TaskManagerCLI SHALL 変更をJSONストレージに即座に反映する
4. WHEN ユーザーが存在しないタスクIDを指定する THEN TaskManagerCLI SHALL エラーメッセージを表示し、リストを変更しない

・・・中略・・・

### 要件6

**ユーザーストーリー:** ユーザーとして、タスクデータがファイルに保存されることを期待する。そうすることで、アプリケーションを再起動してもデータが失われない。

#### 受け入れ基準

1. WHEN TaskManagerCLI が起動する THEN TaskRepository SHALL JSONストレージからタスクデータを読み込む
2. WHEN JSONストレージが存在しない THEN TaskRepository SHALL 空のタスクリストで初期化する
3. WHEN タスクデータが変更される THEN TaskRepository SHALL すべてのタスクをJSONストレージにシリアライズする
4. WHEN JSONストレージからデータを読み込む THEN TaskRepository SHALL JSONをデシリアライズしてタスクオブジェクトに変換する
5. WHEN JSONストレージが破損している THEN TaskRepository SHALL エラーメッセージを表示し、空のリストで初期化する

### 要件7

**ユーザーストーリー:** ユーザーとして、明確なコマンドラインインターフェースを使用したい。そうすることで、直感的にアプリケーションを操作できる。

#### 受け入れ基準

1. WHEN ユーザーがヘルプコマンドを実行する THEN TaskManagerCLI SHALL 利用可能なすべてのコマンドと使用方法を表示する
2. WHEN ユーザーが無効なコマンドを入力する THEN TaskManagerCLI SHALL エラーメッセージとヘルプ情報を表示する
3. WHEN コマンドが成功する THEN TaskManagerCLI SHALL 成功メッセージを表示する
4. WHEN コマンドが失敗する THEN TaskManagerCLI SHALL 明確なエラーメッセージを表示する

Kiroと対話したこと

Q1: 「SHALL」って何？

最初に戸惑ったのが、要件定義に出てくる「SHALL」という表現でした。

私

WHEN ユーザーが有効なタスク説明を提供する 
THEN TaskManagerCLI SHALL 新しいタスクを作成し、一意のIDを割り当てる

これはどういう意味ですか

Kiro(要約)

「SHALL = 『〜しなければならない』という必須要件を示す、要件定義の国際標準（EARS形式）で使われる表現です」

なるほど、技術文書特有の書き方なんですね。日本語で「〜する」と読み替えればOK。
条件文で主語を明確にする書き方のようです。

Q2: タスクの修正はできる？

要件を読んでいて気になったので質問してみました。

私

タスクの内容を修正することはできますか

Kiro

「はい、要件4にタスク説明の更新機能が含まれています」

ちゃんと考慮されていました！
ステータスの更新と内容の更新を混同してしまったのですが、Kiroはちゃんと判別できていました。
レビュー時には見て確認はもちろん、チャットで聞きながら確認するといいかもしれません。

要件定義の成果物

最終的に7つの主要要件が定義されました：

#	要件	受け入れ基準数
1	タスク追加	4項目
2	タスク削除	3項目
3	完了状態切り替え	4項目
4	タスク更新	4項目
5	タスク表示・フィルタリング	4項目
6	JSON永続化	5項目
7	CLIインターフェース	4項目

各要件には、EARS形式で書かれた明確な受け入れ基準が設定されています。

Kiro

要件定義書の内容について、他に確認したいことはありますか？問題なければ、次の設計フェーズに進みましょう！

私

次に進んでください

🏗️ フェーズ2: 設計

design.mdが作成されました。
再びレビューを実施します。

コマンド名の決定

設計フェーズで最初に議論になったのが、コマンド名でした。

私

 taskというコマンド名は他のツールと重複しませんか？

Kiro

- `todo` - シンプルで直感的
- `taskmgr` - Task Managerの略
- `mytask` - 個人用であることを明示
- `tdl` - To-Do Listの略

私

Kiroで作ったことがわかる名前にしたいです

Kiro

`kirotask`はいかがでしょうか？
Kiroの名前が入っているので、このツールがKiroで作成されたことが明確になります。
この名前で設計書を更新してよろしいですか？

最終決定: kirotask 🎉

使用例：

kirotask add "買い物に行く"
kirotask list
kirotask complete 1
kirotask delete 1

こうして会話しながらレビューすることで、関連個所の修正が行われました。

アーキテクチャ設計

3層構造のクリーンアーキテクチャを採用しました。

┌─────────────────────────────┐
│   CLI Layer (Commander.js)  │  ← ユーザーインターフェース
└─────────────────────────────┘
              ↓
┌─────────────────────────────┐
│   Service Layer             │  ← ビジネスロジック
│   (TaskService)             │
└─────────────────────────────┘
              ↓
┌─────────────────────────────┐
│   Repository Layer          │  ← データアクセス
│   (TaskRepository)          │
└─────────────────────────────┘
              ↓
┌─────────────────────────────┐
│   Storage (tasks.json)      │  ← 永続化
└─────────────────────────────┘

技術スタック

カテゴリ	技術
言語	TypeScript 5.x
ランタイム	Node.js 18.x以上
CLIフレームワーク	Commander.js
テスト	Vitest + fast-check
ビルド	tsx

データモデル

interface Task {
  id: number;              // 一意の識別子
  description: string;     // タスクの説明
  completed: boolean;      // 完了状態
  createdAt: Date;        // 作成日時
  updatedAt: Date;        // 更新日時
}

JSONストレージ形式：

{
  "tasks": [
    {
      "id": 1,
      "description": "買い物に行く",
      "completed": false,
      "createdAt": "2024-01-01T10:00:00.000Z",
      "updatedAt": "2024-01-01T10:00:00.000Z"
    }
  ],
  "nextId": 2
}

🧪 正確性プロパティ（Property-Based Testing）

設計書では16個の正確性プロパティを定義しました。これがKiroの特徴的な機能です。

プロパティとは？

プロパティとは、システムのすべての有効な実行において真であるべき特性や動作のことです。

具体例で理解する:

従来のテスト: 「タスクID=1を削除すると、リストから消える」
プロパティテスト: 「任意のタスクIDを削除すると、リストから消える」

つまり、特定のケースではなくすべてのケースで成り立つ性質をテストします。

メリット:

人間が思いつかないエッジケースも自動発見
ランダムなデータで100回テストするため、網羅性が高い
要件定義の受け入れ基準を直接検証できる

代表的なプロパティ

プロパティ1: タスク追加でリストが成長する

任意の有効なタスク説明に対して、
それをタスクリストに追加すると、
リストの長さが1増加し、新しいタスクに一意のIDが割り当てられる

検証: 要件 1.1

プロパティ6: トグル操作の往復

任意のタスクに対して、
完了状態をトグルしてから再度トグルすると、
元の完了状態に戻る

検証: 要件 3.1, 3.2

プロパティ13: シリアライゼーション往復

任意の有効なタスクリストに対して、
JSONにシリアライズしてからデシリアライズすると、
元のタスクリストと等価なリストが得られる

検証: 要件 6.3, 6.4

テスト戦略

ユニットテスト (Vitest)

各コンポーネントの具体的な動作を検証
エッジケースのテスト

プロパティベーステスト (fast-check)

正確性プロパティの検証
各テストは最低100回反復実行
ランダムなデータで網羅的にテスト

// Feature: task-manager-cli, Property 1: タスク追加でリストが成長する
test('adding a task increases list length', () => {
  fc.assert(
    fc.property(fc.string({ minLength: 1 }), (description) => {
      // プロパティ検証ロジック
    }),
    { numRuns: 100 }
  );
});

📊 ここまでの成果物まとめ

作成したドキュメント

ドキュメント	パス	内容
要件定義書	`.kiro/specs/task-manager-cli/requirements.md`	7要件、28受け入れ基準
設計書	`.kiro/specs/task-manager-cli/design.md`	アーキテクチャ、16プロパティ、テスト戦略

設計のポイント

✅ レイヤードアーキテクチャ: 関心の分離で保守性向上
✅ プロパティベーステスト: 網羅的な品質保証
✅ EARS形式の要件: 曖昧さのない明確な仕様
✅ 型安全性: TypeScriptで実装時のバグを削減

📝 フェーズ3: 実装計画（タスクリスト）

設計が完了したので、次は実装計画を作成しました。

タスクリストの構成

主要タスク（8つ）:

プロジェクト構造とコア設定のセットアップ
TaskRepositoryの実装
TaskServiceの実装
チェックポイント
CLIインターフェースの実装
エントリーポイントとビルド設定
最終チェックポイント
READMEとドキュメントの作成

サブタスク: 合計40以上の詳細タスク

オプションタスクの戦略

Kiroは、テスト関連のタスクをオプション（*マーク）として提案してくれました。

- [ ] 3.1 addTaskメソッドの実装
- [ ]* 3.2 プロパティテスト: タスク追加でリストが成長する

私

コア機能を作成した後にその他タスクを実施します。

これにより、まずコア機能の実装に集中し、後からテストを追加できる柔軟な開発が可能になります。

💻 フェーズ4: 実装（コア機能）

いよいよコードを書いていきます！Kiroに「順に実行して」と指示すると、タスクを1つずつ自動的に実装してくれました。
コマンド実行時には一時停止し、ユーザの許可を待つのでRunボタンを押して実行させます。

npm install
# 87パッケージをインストール完了

各タスクを順次実行し機能を実装していきます。
次々ファイルが作成されていくのを眺めているだけでも楽しいですね。

✅ 動作確認

ビルドして実際に動かしてみました！
ここもRunボタンでコマンド実行を許可しテストコードを実行します。

ビルド

npm run build
# ビルド成功！

実行例

# ヘルプ表示
$ node dist/index.js
Usage: kirotask [options] [command]

Commands:
  add <description>          新しいタスクを追加
  list [filter]              タスクを表示 (all/completed/pending)
  complete <id>              タスクの完了状態を切り替え
  update <id> <description>  タスクの説明を更新
  delete <id>                タスクを削除

# タスクを追加
$ node dist/index.js add "買い物に行く"
✓ タスクを追加しました (ID: 1)

$ node dist/index.js add "レポートを書く"
✓ タスクを追加しました (ID: 2)

# タスク一覧を表示
$ node dist/index.js list

タスク一覧:
────────────────────────────────────────────────────────────
[ ] 1. 買い物に行く
[ ] 2. レポートを書く
────────────────────────────────────────────────────────────
合計: 2件

# タスクを完了にする
$ node dist/index.js complete 1
✓ タスク 1 を完了に変更しました

# 再度一覧表示
$ node dist/index.js list

タスク一覧:
────────────────────────────────────────────────────────────
[✓] 1. 買い物に行く
[ ] 2. レポートを書く
────────────────────────────────────────────────────────────
合計: 2件

すべての機能が正常に動作しました！ 🎉

📊 実装完了サマリー

完了したタスク

タスク	状態	説明
1. プロジェクト構造	✅	TypeScript環境、依存関係
1.1 データモデル	✅	Task型、バリデーション
2. TaskRepository	✅	JSON永続化、CRUD操作
3. TaskService	✅	ビジネスロジック全実装
5. CLIインターフェース	✅	全コマンド実装
6. エントリーポイント	✅	CLI起動設定
8. README	✅	ドキュメント作成

作成されたファイル

kirotask/
├── src/
│   ├── models/Task.ts              # データモデル
│   ├── repositories/
│   │   └── TaskRepository.ts       # データアクセス層
│   ├── services/
│   │   └── TaskService.ts          # ビジネスロジック層
│   ├── cli/
│   │   └── commands.ts             # CLIコマンド
│   ├── utils/
│   │   └── validation.ts           # バリデーション
│   └── index.ts                    # エントリーポイント
├── dist/                           # ビルド出力
├── data/tasks.json                 # タスクデータ
├── package.json
├── tsconfig.json
├── vitest.config.ts
└── README.md

堂々とできたといっていますが、コマンド名違いますね？

Terminal

kirotask list
kirotask : 用語 'kirotask' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。

私

アプリをkirotaskで実行できるようにしたい

Kiro

承知しました！kirotaskコマンドで実行できるようにします。npm linkを使ってグローバルにインストールします。
npm link

完了しました！これでkirotaskコマンドが使えるようになりました。
試してみましょう：
kirotask --version
PS C:\workspaces\kiro-intro> kirotask --version
1.0.0

kirotask list
PS C:\workspaces\kiro-intro> kirotask list

タスク一覧:
────────────────────────────────────────────────────────────
[✓] 1. 買い物に行く
[ ] 2. レポートを書く
────────────────────────────────────────────────────────────
合計: 2件

完璧です！🎉
kirotaskコマンドが使えるようになりました！

大量のチャットログが流れるので見直すのは大変ですが、何をどこまでやってくれたのかしっかり確認しましょう。

💻 フェーズ5: 実装（オプションタスク）

コア機能が完成したので、次はオプションタスクのテスト実装に取り組みました。

プロパティベーステストの実装

Kiroに「オプションタスクを実行してください」と依頼すると、fast-checkを使ったプロパティベーステストを実装してくれました。

実装されたテスト例

プロパティ1: タスク追加でリストが成長する

// Feature: task-manager-cli, Property 1: タスク追加でリストが成長する
test('adding a task increases list length', () => {
  fc.assert(
    fc.property(fc.string({ minLength: 1 }), (description) => {
      const initialCount = taskService.listTasks().length;
      const task = taskService.addTask(description);
      const finalCount = taskService.listTasks().length;
      
      expect(finalCount).toBe(initialCount + 1);
      expect(task.id).toBeGreaterThan(0);
    }),
    { numRuns: 100 }
  );
});

プロパティ6: トグル操作の往復

// Feature: task-manager-cli, Property 6: トグル操作の往復
test('toggle operation round trip', () => {
  fc.assert(
    fc.property(fc.string({ minLength: 1 }), (description) => {
      const task = taskService.addTask(description);
      const originalState = task.completed;
      
      taskService.toggleTask(task.id);
      taskService.toggleTask(task.id);
      
      const finalTask = taskService.listTasks().find(t => t.id === task.id);
      expect(finalTask?.completed).toBe(originalState);
    }),
    { numRuns: 100 }
  );
});

テスト実行結果

npm test

> kirotask@1.0.0 test
> vitest run

✓ src/services/TaskService.test.ts (16)
✓ src/repositories/TaskRepository.test.ts (8) 
✓ src/utils/validation.test.ts (4)
✓ src/__tests__/properties/task-operations.property.test.ts (16)

Test Files  4 passed (4)
Tests       44 passed (44)

全44テストが成功！ 🎉

プロパティベーステストの威力

各プロパティテストは100回の反復実行で、合計1,600回のランダムテストが実行された（らしい）。これにより：

エッジケースの自動発見
データの整合性の徹底検証
予期しないバグの早期発見

通常のユニットテストでは見つけにくい問題も、ランダムなデータで網羅的にテストすることで発見できます。

🚨 実装中のエラーと解決過程

順調に見えた実装でしたが、実際にはいくつかのエラーが発生しました。

重要な注意点:

コマンド実行を「Accept」で自動許可していたため、実質的にKiroが自動解決
大量のログが流れるため、リアルタイムでの理解は困難
以下の内容は事後のKiro申告に基づく記録

学んだこと: エラー解決プロセスも含めて「開発体験」として捉える必要があります。

エラー1: TypeScriptコンパイルエラー

最初のビルド時にエラーが発生：

npm run build

src/repositories/TaskRepository.ts:45:5 - error TS2322: 
Type 'string' is not assignable to type 'Date'.

原因: JSONから読み込んだ日付文字列をDate型に変換していない

私

ビルドエラーが出ています

Kiro

TypeScriptのエラーですね。JSONから読み込んだ日付文字列をDate型に変換する必要があります。修正します。

修正内容:

// 修正前
createdAt: taskData.createdAt,
updatedAt: taskData.updatedAt

// 修正後  
createdAt: new Date(taskData.createdAt),
updatedAt: new Date(taskData.updatedAt)

エラー2: テスト実行時のファイルパスエラー

テスト実行時に別のエラーが発生：

npm test

Error: ENOENT: no such file or directory, open './data/tasks.json'

原因: テスト実行時にデータディレクトリが存在しない

私

テストでファイルが見つからないエラーが出ています

Kiro

テスト環境でdataディレクトリが存在しないためですね。ディレクトリを自動作成するように修正します。

修正内容:

// TaskRepository.tsに追加
private ensureDataDirectory(): void {
  const dataDir = path.dirname(this.filePath);
  if (!fs.existsSync(dataDir)) {
    fs.mkdirSync(dataDir, { recursive: true });
  }
}

エラー3: CLIコマンドの引数解析エラー

Commander.jsの設定でエラーが発生：

kirotask add
error: missing required argument 'description'

原因: 引数の必須チェックが正しく動作していない

私

引数が必須になっていないようです

Kiro

Commander.jsの引数チェックを強化します。空文字列のバリデーションも追加しましょう。

修正内容:

// 修正前
.argument('<description>', 'タスクの説明')

// 修正後
.argument('<description>', 'タスクの説明')
.action((description: string) => {
  if (!description || description.trim() === '') {
    console.error('❌ タスクの説明は空にできません');
    process.exit(1);
  }
  // 処理続行
})

エラー4: グローバルコマンドが認識されない

（↑これはフェーズ4: 実装（コア機能）時に修正している。ハルシネーションでは）

実装完了後、コマンドを実行しようとしてエラー：

kirotask list
kirotask : 用語 'kirotask' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。

原因: package.jsonのbinフィールドが設定されていない

私

アプリをkirotaskで実行できるようにしたい

Kiro

承知しました！kirotaskコマンドで実行できるようにします。

まず、package.jsonにbinフィールドを追加します：

修正内容:

package.jsonにbinフィールド追加
npm linkでグローバルインストール
shebang行の追加

// package.json
{
  "bin": {
    "kirotask": "./dist/index.js"
  }
}

// dist/index.js の先頭に追加
#!/usr/bin/env node

npm run build
npm link

エラー5: プロパティテストの依存関係エラー

テスト実装時にfast-checkのインポートエラーが発生：

npm test

Error: Cannot find module 'fast-check'

原因: fast-checkがdevDependenciesに追加されていない

私

fast-checkが見つからないエラーが出ています

Kiro

fast-checkをインストールする必要がありますね。
npm install --save-dev fast-check @types/node

エラー6: プロパティテストの論理エラー

初回のプロパティテスト実行で失敗：

Property failed after 23 runs
Counterexample: ["   "]

原因: 空白文字のみの文字列を有効な入力として扱っていた

私

プロパティテストで空白文字列のテストが失敗しています

Kiro

プロパティテストが正しく動作していますね！空白文字のみの文字列は無効な入力として扱うべきです。ジェネレータを修正します。

修正内容:

// 修正前
fc.string({ minLength: 1 })

// 修正後  
fc.string({ minLength: 1 }).filter(s => s.trim().length > 0)

これは実はバグ発見！ プロパティベーステストの威力を実感した瞬間でした。

エラー解決から学んだこと

1. Kiroの問題解決能力

エラーメッセージから根本原因を正確に特定
複数の関連箇所を同時に修正提案
設定ファイルやビルド環境も含めた包括的な解決
プロパティテストによるバグの早期発見

2. 開発プロセスの現実

一発で完璧なコードは生成されない
エラーが発生しても対話で確実に解決
試行錯誤も含めて「開発体験」

3. 学習効果

エラーの原因と解決方法を理解できる
TypeScript、Node.js、CLIツールの知識が身につく
問題解決のアプローチを学べる
ただし、大量に流れる実行ログから判断するのは困難。ログを何らかの形で記録・分析する必要がある
本当にこのエラーが発生していたのか、この方法で修正したのか根拠がない

🎯 学んだこと・感想

Kiroの優れた点

1. 仕様駆動開発の自動化

要件→設計→実装の流れを体系的にガイド
EARS形式の要件定義で曖昧さを排除
プロパティベーステストで品質保証

2. 対話的な開発体験

各フェーズでレビューを促してくれる
疑問点をチャットで即座に解決
修正提案も的確

3. コード生成の精度

TypeScriptの型安全性を活かした実装
クリーンアーキテクチャの適切な実装
テストコードまで自動生成

4. エラー解決能力

エラーメッセージから根本原因を正確に特定
複数の関連箇所を同時に修正提案
設定ファイルやビルド環境も含めた包括的な解決
プロパティテストによるバグの早期発見

改善点・課題

1. 生成コードの理解負荷

問題: 大量のコードが一気に生成される
影響: 内容を理解するのに時間がかかる
対策案: 段階的な生成や、コード解説機能があると良い

2. 品質担保の責任所在

問題: Kiroが修正したコードが正しいか判断が困難
影響: 「よくわからんが動いている」状態になりがち
対策案:

修正内容の説明を求める
重要な部分は人間がレビューする
テストカバレッジで品質を担保する

3. 学習効果の限界

問題: エラー解決をKiroに任せると学習機会を逃す
影響: 同じエラーが再発した時に対応できない
対策案:

エラーの原因と解決方法を必ず確認する
重要なエラーは手動で解決してみる
解決プロセスをドキュメント化する

📈 今後の展望

試してみたい機能

リファクタリング支援
- 既存コードの改善提案
- パフォーマンス最適化
複雑なドメインロジック
- より複雑なビジネスルールの実装
- 複数エンティティ間の関係性
統合テスト
- エンドツーエンドテストの自動生成
- CI/CDパイプラインとの連携

実用化への課題

チーム開発での活用方法
- 複数人での仕様レビュー
- コード品質の統一
- 品質担保
既存プロジェクトへの適用
- レガシーコードのリファクタリング
- 段階的な品質向上

🎉 まとめ

Kiroの革新性

Kiroを使った仕様駆動開発を体験して、「AIが単なるコード生成ツールを超えて、開発プロセス全体をサポートする時代」の到来を実感しました。

達成できたこと vs 課題

✅ 達成できたこと:

完全に動作するCLIアプリケーションの完成
体系的な開発プロセスの実践
44個のテストによる品質保証

⚠️ 残った課題:

生成コードの完全な理解には時間が必要
エラー解決プロセスの「ブラックボックス化」
「よくわからんが動いている」状態からの脱却

今後の取り組み方針

この体験を通じて、人間とAIの適切な役割分担が重要だと理解しました：

人間の役割:

要件の明確化と優先順位付け
生成コードの理解と品質判断
重要な設計判断
エラー原因の理解と学習

Kiroの役割:

体系的な開発プロセスのガイド
高品質なコード生成
エラーの迅速な修正
テスト戦略の提案

次のステップ: 品質を担保する具体的な方法論の確立が急務です。

主な成果

✅ 完全に動作するCLIアプリケーションの完成
✅ 44個のテストによる品質保証
✅ 体系的な開発プロセスの習得
✅ プロパティベーステストの実践的理解
✅ エラー解決プロセスの体験

最終的な感想

Kiroは開発の相棒として非常に優秀です。特に：

初期設計の品質向上に大きく貢献
テスト駆動開発を自然に実践できる
保守性の高いコードを生成してくれる
エラーが発生しても対話で確実に解決できる

一方で、生成されたコードを理解し、カスタマイズしていくエンジニアのスキルも重要だと感じました。また、エラーが発生することは避けられないため、問題解決への取り組み方も学習の一部として捉える必要があります。さらに人間が品質を担保できる根拠を占める方法を備える必要があります。

AIツールは進化し続けていますが、「何を作りたいか」「なぜ作るのか」を明確にする人間の役割は変わりません。Kiroはその思考を整理し、実現するための強力なパートナーになってくれそうです。

開発期間: 約4時間（エラー解決含む）
生成コード行数: 約800行
テスト数: 44個（1,600回の反復テスト含む）
発生したエラー: 6件（すべて解決）

この記事が、Kiroや仕様駆動開発に興味を持つ方の参考になれば幸いです。Kiroとの対話を楽しんでください！

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up