Claude Code Spec WorkflowとKiro、実際に試して比較してみた

はじめに

POSSEでエンジニアインターンをしている井上岳です。

最近、AIを使った開発ワークフローのツールがいくつか登場しています。今回取り上げたいのは、Claude Code Spec WorkflowとKiroです。

• Claude Code Spec Workflow
• Kiro

どちらもrequirements → design → tasksという流れで仕様を決めて実装するというアプローチを取っていますが、実際に使ってみるとかなり違いがあります。今回は同じお題で両方試してみたので、その違いを紹介したいと思います。

試したお題

今回は「ECサイトの注文から配送までのドメインモデリング」という課題に挑戦しました。関数型プログラミングのアプローチで、型安全な状態遷移を実現するという、そこそこ複雑な内容です。

投げたプロンプト：

ECサイトでの「注文から配送までの流れ」をドメインモデリングしてください。
顧客が商品を注文してから、在庫を確保し、出荷・配送を経て完了に至るまでの一連のプロセスを想定しています。
・不正な状態遷移が起きないようにしたい
・副作用（例：在庫確認や通知送信）はできるだけ分離したい
・将来的にキャンセル処理や再配送なども追加できるようにしたい
このドメインを、関数型的な考え方で安全に設計してください。
型、関数、状態遷移など、あなたが重要だと思う単位で自由に表現して構いません。

要点：

• 注文確定 → 在庫引当 → 出荷 → 配送完了という状態遷移
• 不正な状態遷移を型レベルで防ぐ
• 副作用（通知送信、在庫更新）をドメインロジックから分離
• 将来的なキャンセル・再配送機能への拡張性
  

Kiroで試してみました

Kiroは要件定義を書くところから始まります。プロンプトを投げると、まず requirements.md を作成してくれます。

要件定義では、User Storyの形式で各要件が整理されます。Acceptance Criteriaも明確に定義されていて、「何を満たせば完成なのか」がわかりやすいです。

# Requirements Document

## Introduction

ECサイトにおける注文から配送完了までの一連のプロセスを、関数型プログラミングの原則に基づいて安全にモデリングする機能です。この機能は、不正な状態遷移を防ぎ、副作用を適切に分離し、将来的な拡張（キャンセル処理、再配送など）に対応できる設計を提供します。

## Requirements

### Requirement 1

**User Story:** システム開発者として、注文の状態遷移を型安全に管理したいので、不正な状態変更を防ぐドメインモデルが必要です。

#### Acceptance Criteria

1. WHEN 注文が作成される THEN システム SHALL 初期状態（OrderPlaced）に設定する
2. WHEN 在庫確認が完了する THEN システム SHALL InventoryReserved状態に遷移する
3. WHEN 無効な状態遷移が試行される THEN システム SHALL エラーを返し状態変更を拒否する
4. WHEN 各状態遷移が実行される THEN システム SHALL 遷移の妥当性を事前に検証する

..... 続く

次に design.md が作られます。ここでは型定義、状態遷移関数、副作用システムなどの設計が詳細に記述されます。Mermaidによるアーキテクチャ図やTypeScriptのコード例も含まれていて、実装イメージがかなり具体的です。

# Design Document

## Overview

ECサイトの注文から配送までの流れを、関数型プログラミングの原則に基づいて安全にモデリングするドメイン設計です。この設計では、型安全な状態遷移、副作用の分離、イミュータブルなデータ構造を中心とした堅牢なシステムを構築します。

## Architecture

### Core Principles

1. **Type Safety**: 型システムを活用して不正な状態遷移をコンパイル時に防ぐ
2. **Immutability**: すべてのデータ構造をイミュータブルにし、状態変更は新しいインスタンス作成で行う
3. **Pure Functions**: 状態遷移ロジックを純粋関数として実装し、副作用を分離
4. **Effect Separation**: 副作用（IO、外部API呼び出し）を明示的に管理
5. **Composability**: 小さな関数を組み合わせて複雑な処理を構築

### Architecture Diagram

```mermaid
graph TB
    subgraph "Domain Layer"
        Order[Order Aggregate]
        States[Order States]
        Transitions[State Transitions]
        Events[Domain Events]
    end
    
    subgraph "Effect Layer"
        Effects[Side Effects]
        Inventory[Inventory Service]
        Notification[Notification Service]
        Shipping[Shipping Service]
    end
    
    subgraph "Application Layer"
        Commands[Command Handlers]
        Orchestrator[Effect Orchestrator]
    end
    
    Commands --> Order
    Order --> States
    States --> Transitions
    Transitions --> Events
    Events --> Effects
    Effects --> Inventory
    Effects --> Notification
    Effects --> Shipping
    Orchestrator --> Effects
```

## Components and Interfaces

### 1. Order State Types

```typescript
// 基本的な値オブジェクト
type OrderId = string & { readonly _brand: 'OrderId' }
type CustomerId = string & { readonly _brand: 'CustomerId' }
type ProductId = string & { readonly _brand: 'ProductId' }
type Timestamp = Date & { readonly _brand: 'Timestamp' }

// 注文アイテム
interface OrderItem {
  readonly productId: ProductId
  readonly quantity: number
  readonly unitPrice: number
}

// 配送情報
interface ShippingInfo {
  readonly address: string
  readonly method: 'standard' | 'express' | 'overnight'
  readonly trackingNumber?: string
}

// 状態固有のデータ
interface OrderPlacedData {
  readonly orderId: OrderId
  readonly customerId: CustomerId
  readonly items: readonly OrderItem[]
  readonly placedAt: Timestamp
}

interface InventoryReservedData extends OrderPlacedData {
  readonly reservedAt: Timestamp
  readonly reservationId: string
}

interface ShippedData extends InventoryReservedData {
  readonly shippingInfo: ShippingInfo
  readonly shippedAt: Timestamp
}

interface DeliveredData extends ShippedData {
  readonly deliveredAt: Timestamp
  readonly signature?: string
}

// 状態の型安全な表現
type OrderState = 
  | { readonly type: 'OrderPlaced'; readonly data: OrderPlacedData }
  | { readonly type: 'InventoryReserved'; readonly data: InventoryReservedData }
  | { readonly type: 'Shipped'; readonly data: ShippedData }
  | { readonly type: 'Delivered'; readonly data: DeliveredData }
```

..... 続く

そして implementation.md では、実装タスクが細かくブレークダウンされます。各タスクには要件番号が紐付けられているので、トレーサビリティも確保されています。

# Implementation Plan

- [x] 1. Set up project structure and core type definitions

  - Create TypeScript project with strict type checking enabled
  - Define branded types for OrderId, CustomerId, ProductId, and Timestamp
  - Implement basic value objects and interfaces for OrderItem and ShippingInfo
  - _Requirements: 5.1, 5.3, 6.1_

- [ ] 2. Implement core order state types and data structures

  - [ ] 2.1 Create order state data interfaces

    - Define OrderPlacedData, InventoryReservedData, ShippedData, and DeliveredData interfaces
    - Implement proper inheritance hierarchy with readonly properties
    - _Requirements: 3.1, 3.2, 3.3, 3.4, 3.5, 6.1_

  - [ ] 2.2 Implement OrderState union type
    - Create tagged union type for all order states
    - Ensure type safety with discriminated unions
    - _Requirements: 1.1, 1.2, 5.1, 5.2_

- [ ] 3. Create Result type and error handling utilities

  - [ ] 3.1 Implement generic Result type

    - Create Result<T, E> type with success and failure variants
    - Implement Result utility functions (map, flatMap, mapError)
    - _Requirements: 6.4, 1.3_

  - [ ] 3.2 Define TransitionResult type
    - Create specialized result type for state transitions
    - Include newState and effects in success case
    - _Requirements: 1.3, 1.4, 2.1_

..... 続く

実装に入ると、「Start task」ボタンで各タスクを実行できます。（画像のTask in progressの部分にStart taskボタンがあります）

タスクが完了すると自動でチェックが付く仕組みになっていて、進捗が可視化されます。

必ず反映されるのが便利ですね、、！！！

Claude Code Spec Workflowで試してみました

一方、Claude Code Spec Workflowは少し違うアプローチを取ります。

まず、コードベース分析から始まります。既存のプロジェクト構造や規約を理解してから仕様を書くという流れです。

その後、 requirements.md が作成されます。

# Requirements Document

## Introduction

ECサイトにおける「注文から配送までの流れ」のドメインモデル実装です。このシステムは、顧客の注文受付から在庫確保、出荷、配送、完了までの一連のプロセスを安全に管理します。

関数型プログラミングの原則に基づき、不正な状態遷移を防ぎ、副作用を分離し、将来的な拡張（キャンセル、再配送など)を容易にする設計を目指します。

**価値提供:**
- 状態遷移の安全性向上により、注文処理のバグを削減
- 副作用の分離により、テストの容易性とメンテナンス性を向上
- 型安全性により、開発者体験とコードの信頼性を向上

## Alignment with Product Vision

本機能は以下の観点で製品価値を提供します:
- **信頼性:** 型安全な状態管理により、注文処理の信頼性を確保
- **拡張性:** 関数型設計により、新機能（キャンセル、再配送）の追加を容易化
- **保守性:** 副作用の分離により、コードの理解とメンテナンスを容易化

## Requirements

### Requirement 1: 注文状態の型安全な管理

**User Story:** As a システム開発者, I want 注文の状態を型安全に管理する機能, so that 不正な状態遷移を防ぎ、バグを減少させることができる。

#### Acceptance Criteria

1. WHEN 注文が作成される THEN システム SHALL 注文を「注文作成済み」状態で初期化する
2. WHEN 「注文作成済み」状態の注文に対して在庫確保が実行される THEN システム SHALL 「在庫確保済み」状態へ遷移する
3. WHEN 不正な状態遷移が試行される（例: 「注文作成済み」から「配送中」への直接遷移） THEN システム SHALL 型エラーまたはコンパイルエラーを発生させる
4. WHEN 各状態遷移が実行される THEN システム SHALL 遷移の成功/失敗を明示的に返す（Result型またはEither型）

..... 続く

ここまではKiroと似ていますが、おもしろいのは次です。

要件定義書が完成すると、専用のバリデーションエージェントが動きます。要件の完全性や明確さをチェックして、改善点を指摘してくれます。

ユーザーストーリーのフォーマットに修正点があったみたいです。

バリデーション結果を元に要件を修正してから、design.mdの作成に進みます。設計書でも同様にバリデーションが行われます。

design.md

# Design Document

## Overview

ECサイトの注文フルフィルメントシステムを関数型プログラミングの原則に基づいて設計します。本設計は、型安全な状態管理、副作用の分離、拡張性を重視し、注文の作成から配送完了までのライフサイクルを安全に管理します。

**設計の中核原則:**
- **型駆動設計**: 不正な状態遷移をコンパイル時に検出
- **純粋関数**: 状態遷移ロジックを副作用から分離
- **代数的データ型**: Sum Type（直和型）による状態の明示的表現
- **Result/Either型**: 例外を使わないエラーハンドリング

## Steering Document Alignment

### Technical Standards
本設計は以下の技術標準に準拠します:
- **関数型プログラミング**: 純粋関数、不変性、型安全性
- **ドメイン駆動設計**: ユビキタス言語の使用、ドメインモデルの明確化
- **テスト駆動開発**: 純粋関数によるテスタビリティの向上

### Project Structure
プロジェクト構造は以下の方針に従います:
- **domain/**: ドメインモデルと状態遷移ロジック
- **effects/**: 副作用の定義と実行
- **types/**: 型定義とResult/Either型
- **tests/**: ユニットテストと統合テスト

## Code Reuse Analysis

新規プロジェクトのため、既存コードの再利用はありませんが、以下の汎用パターンを活用します:

### Existing Components to Leverage
- **関数型パターン**: Result型、Either型、Option型などの標準的な関数型パターン
- **状態機械パターン**: 型安全な状態遷移の実装パターン
- **Effect Systemパターン**: 副作用の記述と実行の分離パターン

### Integration Points
- **在庫管理システム**: 在庫確保・更新の副作用として統合
- **通知サービス**: メール/SMS送信の副作用として統合
- **配送業者API**: 配送追跡情報の更新副作用として統合

## Architecture

本システムは、以下の3層アーキテクチャで構成されます:

```mermaid
graph TB
    subgraph "Domain Layer (Pure)"
        OrderState[Order State Types]
        Transitions[State Transition Functions]
        OrderState --> Transitions
    end

    subgraph "Effect Layer (Impure)"
        EffectDef[Effect Definitions]
        EffectExec[Effect Executors]
        EffectDef --> EffectExec
    end

    subgraph "Integration Layer"
        Inventory[Inventory Service]
        Notification[Notification Service]
        Shipping[Shipping API]
    end

    Transitions --> EffectDef
    EffectExec --> Inventory
    EffectExec --> Notification
    EffectExec --> Shipping
```

### 状態遷移図

```mermaid
stateDiagram-v2
    [*] --> Created: createOrder
    Created --> InventoryReserved: reserveInventory
    InventoryReserved --> Shipped: ship
    Shipped --> InTransit: startDelivery
    InTransit --> Delivered: completeDelivery
    Delivered --> [*]

    note right of Created
        注文作成済み
        在庫未確保
    end note

    note right of InventoryReserved
        在庫確保済み
        出荷待ち
    end note

    note right of Shipped
        出荷済み
        配送開始待ち
    end note

    note right of InTransit
        配送中
    end note

    note right of Delivered
        配送完了
    end note
```

### 将来の拡張（キャンセル・再配送）

```mermaid
stateDiagram-v2
    [*] --> Created
    Created --> InventoryReserved: reserveInventory
    Created --> Cancelled: cancel
    InventoryReserved --> Shipped: ship
    InventoryReserved --> Cancelled: cancel
    Shipped --> InTransit: startDelivery
    InTransit --> Delivered: completeDelivery
    InTransit --> DeliveryFailed: markFailed
    DeliveryFailed --> InTransit: redeliver
    DeliveryFailed --> Cancelled: cancel
    Delivered --> [*]
    Cancelled --> [*]
```

## Components and Interfaces

### Component 1: Order State Types（注文状態型）

**目的:** 注文の各状態を型安全に表現し、不正な状態遷移をコンパイル時に防止

**型定義（TypeScript風の例）:**

```typescript
// 基本的な注文情報（すべての状態で共通）
type OrderId = string;
type CustomerId = string;
type OrderItem = {
  productId: string;
  quantity: number;
  price: number;
};

// 各状態を個別の型として定義（Phantom Type pattern）
type OrderCreated = {
  readonly _tag: "OrderCreated";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
};

type OrderInventoryReserved = {
  readonly _tag: "OrderInventoryReserved";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
};

type OrderShipped = {
  readonly _tag: "OrderShipped";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
  readonly shippedAt: Date;
  readonly trackingNumber: string;
};

type OrderInTransit = {
  readonly _tag: "OrderInTransit";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
  readonly shippedAt: Date;
  readonly trackingNumber: string;
  readonly inTransitAt: Date;
};

type OrderDelivered = {
  readonly _tag: "OrderDelivered";
  readonly orderId: OrderId;
  readonly customerId: CustomerId;
  readonly items: OrderItem[];
  readonly createdAt: Date;
  readonly reservedAt: Date;
  readonly shippedAt: Date;
  readonly trackingNumber: string;
  readonly inTransitAt: Date;
  readonly deliveredAt: Date;
};

// Sum Type（直和型）で全状態を表現
type Order =
  | OrderCreated
  | OrderInventoryReserved
  | OrderShipped
  | OrderInTransit
  | OrderDelivered;
```

..... 続く

タスクブレークダウンは task.md として作成されます。Kiroと比べると、各タスクの目的（Purpose）や活用する既存コンポーネント（Leverage）が明記されていて、より詳細です。

# Implementation Plan

## Task Overview

ECサイトの注文フルフィルメントシステムを、関数型プログラミングの原則に基づいて実装します。実装は以下の順序で進めます:

1. **基礎型の実装**: Result型、Effect型などの汎用的な型
2. **ドメインモデルの実装**: 注文状態型と状態遷移関数
3. **副作用システムの実装**: Effect実行器と統合層
4. **ドメインAPIの実装**: OrderAggregate
5. **テストの実装**: ユニットテスト、統合テスト、E2Eテスト

各タスクは1-3ファイルに限定し、15-30分で完了可能なアトミックな単位に分解しています。

## Steering Document Compliance

- **関数型プログラミング標準**: 純粋関数、不変性、型安全性を遵守
- **プロジェクト構造**: `src/domain/`, `src/effects/`, `src/types/`, `tests/` の構造に従う
- **TypeScript標準**: 厳格な型チェック、readonly修飾子の使用

## Atomic Task Requirements

各タスクは以下の基準を満たします:
- **ファイルスコープ**: 1-3ファイルのみに影響
- **時間制限**: 15-30分で完了可能
- **単一目的**: 1つのテスト可能な成果
- **明示的なファイル**: 作成/変更するファイルを明示
- **エージェントフレンドリー**: 明確な入出力とコンテキスト切り替えの最小化

## Tasks

### Phase 1: 基礎型の実装

- [x] 1. Create Result type in src/types/result.ts
  - File: src/types/result.ts
  - Define Result<T, E> type with Success and Failure variants
  - Implement utility functions: success(), failure(), map(), flatMap()
  - Add type guards: isSuccess(), isFailure()
  - Purpose: Provide foundation for error handling without exceptions
  - _Requirements: 7.2, 7.3_

- [ ] 2. Create Result type unit tests in tests/types/result.test.ts
  - File: tests/types/result.test.ts
  - Test success() and failure() constructors
  - Test map() transformation on Success and Failure
  - Test flatMap() chaining behavior
  - Test type guards work correctly
  - Success criteria: All tests pass, types compile without errors
  - Purpose: Ensure Result type behaves correctly for all operations
  - _Leverage: src/types/result.ts_
  - _Requirements: 7.2_

- [ ] 2.5. Create type guard utilities in src/types/guards.ts
  - File: src/types/guards.ts
  - Implement type guards for Order states: isOrderCreated(), isOrderInventoryReserved(), isOrderShipped(), etc.
  - Implement pattern matching utility: matchOrder() for safe state discrimination
  - Purpose: Enable type-safe pattern matching and state discrimination at compile time
  - _Leverage: src/types/result.ts, src/domain/order-states.ts_
  - _Requirements: 1.3, 7.3_

..... 続く

実装フェーズでは、カスタムコマンドを使ってタスクを実行していきます。こちらも完了したタスクにはチェックが付きます。

生成されたコードを見てみる

「ECサイトの注文から配送までのドメインモデリング」という課題に対して、両ツールが実際にどのようなコードを生成したのかを見てみましょう。

Kiroが生成したコード

Kiroはクラスベースのアプローチを採用しています。Orderクラスが状態を内部に持ち、状態遷移メソッドを提供する形です。

class Order {
  private constructor(private readonly state: OrderState) {}

  // 在庫確保への遷移
  reserveInventory(reservationId: string): TransitionResult<Order> {
    if (this.state.type !== 'OrderPlaced') {
      return {
        success: false,
        error: `Cannot reserve inventory from state: ${this.state.type}`
      }
    }

    const newData: InventoryReservedData = {
      ...this.state.data,
      reservedAt: new Date() as Timestamp,
      reservationId
    }

    const newState: OrderState = {
      type: 'InventoryReserved',
      data: newData
    }

    const effects: Effect[] = [
      {
        type: 'SendNotification',
        customerId: this.state.data.customerId,
        message: 'Your order inventory has been reserved'
      }
    ]

    return {
      success: true,
      newState: new Order(newState),
      effects
    }
  }
}

このアプローチの特徴は、状態と振る舞いがカプセル化されている点です。オブジェクト指向的な設計で、直感的に理解しやすいコードになっています。

Claude Code Spec Workflowが生成したコード

Claude Codeは純粋な関数型アプローチを採用しています。状態遷移を純粋関数として実装し、状態と関数を分離しています。

// 在庫確保への遷移（純粋関数）
function reserveInventory(
  order: OrderCreated,
  inventoryCheck: (items: OrderItem[]) => Result<boolean, InventoryError>
): Result<ReserveInventoryResult, OrderError> {
  // 1. 在庫チェック
  const checkResult = inventoryCheck(order.items);

  if (checkResult._tag === "Failure") {
    return failure(checkResult.error);
  }

  if (!checkResult.value) {
    return failure({
      _tag: "InsufficientInventory",
      productId: order.items[0].productId,
      requested: order.items[0].quantity,
      available: 0
    });
  }

  // 2. 新しい状態の生成
  const newState: OrderInventoryReserved = {
    _tag: "OrderInventoryReserved",
    ...order,
    reservedAt: new Date()
  };

  // 3. 副作用の記述（実行はしない）
  const effects: [ReserveInventoryEffect, SendNotificationEffect] = [
    createEffect("Reserve Inventory", async () => {
      return success({ reservationId: "...", items: order.items });
    }),
    createEffect("Send Reservation Notification", async () => {
      return success({ notificationId: "...", sentAt: new Date() });
    })
  ];

  return success({ newState, effects });
}

こちらは完全に関数型のアプローチです。状態遷移関数は純粋関数として実装され、副作用は値として返されるだけで実行されません。依存性注入によってテストもしやすくなっています。

どちらのコードが良いのか

両方とも型安全で拡張性のある設計ですが、今回の課題に対する適合性を見ると、興味深い違いがあります。

Claude Code Spec Workflowが生成したコードは、確かに教科書的な関数型プログラミングです。純粋関数として実装され、依存性注入によってテストもしやすい。関数型プログラミングの原則に忠実で、理論的には美しいコードです。

ただ、実際にチーム開発で使うことを考えると、いくつか気になる点があります。まず、完全に関数型のアプローチに慣れていない開発者にとっては学習コストが高いです。Result 型や Effect 型の扱い、依存性注入のパターンなど、関数型プログラミングの経験がないと戸惑う部分が多いと思います。

一方、Kiroのコードは実用的なバランスが取れています。クラスベースのアプローチなので、TypeScriptやJavaScriptの標準的なコードスタイルに近いです。でも、関数型プログラミングの重要な要素はしっかり押さえています。

• イミュータブルな状態管理（`readonly`の使用）
• 状態遷移で新しいインスタンスを返す
• 副作用を Effect として分離
• 型安全な状態遷移

つまり、「関数型の良いところを取り入れつつ、実用性も保つ」というアプローチです。オブジェクト指向に慣れた開発者でもすぐに理解できるし、それでいて型安全性や拡張性も確保されています。

今回の課題である「ECサイトの注文から配送までのドメインモデリング」という実務的なユースケースを考えると、Kiroのコードの方が現場で使いやすいと感じました。状態と振る舞いが Order クラスに集約されているので、コードの見通しが良く、新しいメンバーがジョインしたときにも理解しやすいと思います。

どこが違うのか

両方使ってみて感じた違いをいくつか挙げます。

ワークフローの始まり方

Kiroは「要件定義から始める」というシンプルなアプローチです。いきなり本題に入れます。

Claude Code Spec Workflowは「既存コードベースの理解から始める」というアプローチです。新規プロジェクトでなければ、こちらの方が理にかなっています。

バリデーション機構

Claude Code Spec Workflowの大きな特徴は、専用のバリデーションエージェントがいることです。要件定義書や設計書の品質をチェックしてくれるので、仕様の穴を早期に発見できます。

Kiroにはこの機能がありません。もちろん、書かれる仕様自体は十分に詳細ですが、第三者的なチェックがないのは少し心細く感じました。

タスクの粒度

両方ともタスクを細かく分解してくれますが、Claude Code Spec Workflowの方が若干詳細です。各タスクに「Purpose」「Leverage」「Requirements」が明記されていて、なぜこのタスクが必要なのかがわかりやすいです。

Kiroのタスクも十分に細かいですが、どちらかというと「何をするか」に重点が置かれている印象です。

結局どちらを使うべきか

ここまで読んで、「じゃあClaude Code Spec Workflowの方がいいじゃないか」と思った人もいるかもしれません。

確かに、バリデーション機構や詳細なタスク定義は魅力的です。でも、実際に使ってみると、Kiroの方が使いやすいと感じる場面も多かったです。

Kiroの良さ

まず、シンプルさです。「要件書いて、設計書いて、実装する」という流れがストレートでわかりやすいです。余計なステップがありません。

次に、スピード感です。Kiroは要件定義から実装まで、一気通貫で進められます。途中でバリデーションを挟まないので、テンポよく開発が進みます。

Claude Code Spec Workflowは、バリデーションでいったん止まって修正を求められるので、リズムが途切れがちです。

最後に、学習コストです。Kiroは機能がシンプルで、エディタ上でボタンを押していくだけで進んでいくのですぐに使いこなせます。

まとめ

どちらも優れたツールですが、使い分けが大事だと思います。

大規模プロジェクトや、複数人で仕様レビューが必要な場合は、Claude Code Spec Workflowのバリデーション機構が活きます。既存のコードベースに追加開発する場合も、コードベース分析機能が便利です。エンジニア向けのサービスだと感じました。

一方で、小〜中規模のプロジェクトや、個人開発、プロトタイプ作成などでは、Kiroの方が適しています。シンプルで早く、それでいて品質も高いです。特に、スピードを重視したい場合や、少人数のチームで素早く開発したい場合には、Kiroの一気通貫のワークフローが効果を発揮すると思いました。

（今回は関数型プログラミングという高度なお題でしたが、Kiroはもっとシンプルなタスク、例えばCRUD操作やAPIの実装などにも使えます。そういった一般的なタスクであれば、エンジニア経験の浅い方でもKiroを使ってプロトタイプを作ることができるのではないかと思いました。）

個人的には、Kiroの「シンプルだけど必要十分」なアプローチが気に入っています。AIツールは複雑化しがちですが、Kiroは必要な部分に集中していて、かつ使いやすさも工夫されているなと思いました。