Waitlistからメールが届き、話題の kiro.dev 触ってみた

https://kiro.dev/

先月プレビュー版として話題になった、AWSが開発した kiro.dev のエディタを触ることができました。
7月15日に登場してから予想以上の反響があり、試してみようと思ったときにはすでに Waitlist 状態。
自分のところにも2日前にようやくメールが届き、話題に乗り遅れること約1ヶ月、やっと実際に触れるようになりました。

メールが届くとサインアップ用のコードが発行され、OSに応じてダウンロードしてコードを入力すると利用できます。

Kiro.dev とは？

kiro.dev は、AWSが開発したAI駆動のコードエディタです。
Devin や Cursor、Claude Code と同じように、自律的にコードを生成することができます。

現在はプレビュー版ということもあり動作は不安定ですが、無料で利用可能です。

特徴

Kiroの特徴は、他のAI駆動エディタと異なり Vibe と Spec の2つのモードが搭載されていることです。

• Vibe: チャットベースでコードを生成するモード
• Spec: コードの仕様を定義するモード

触ってみた感想

課題のコードは、以前Devinに書かせた 家計簿アプリ のコードを題材に Kiro を試しました。

https://zenn.dev/redamoon/articles/article21-devin-kakeibo

前回のDevin利用分が無料枠を使い切ってしまったため、今回は kiro が無料の範囲で後続タスクを実行できるか を検証しました。

Vibeモード

まずは、Vibeモードで家計簿アプリに対して「動いていなかった部分を修正できるか」を試しました。
前回Devinで生成したコードを Kiro が解析して、後続タスクを実装できるかを確認しました。

結果として、コードを読み取って「直っていない部分を修正したい」という要望に対し、ある程度理解をして修正や追加機能の実装を行ってくれました。

お願いしたこと

• テンプレート管理画面の並び替え修正
• ログイン機能の実装
  • ログイン周りの確認と修正
• ユーザ設定
• ダークモード対応
• 口座の追加・削除機能（月次集計でも表示）
  • 口座残高の計算不具合を修正
  • 口座管理ページの実装

Vibeモードではチャットベースで機能実装や修正を進められました。
Devin や Cursor、Claude Code などの他のAIエディタと比べると劣る部分もありますが、やりとりはスムーズでした。

プレビュー版のため、正式リリース後には実装力も向上するのではないかと思います。
現状は kiro を使いつつ、Claude Code を併用するのが良さそうです。

セッションが長くなると新しいセッションが要求される

プレビュー版だからか、無料枠の仕様なのかは不明ですが、セッションが長くなると新しいセッションを開始するよう求められました。

Session Too Long
Continue
Summarize and continue in a new session.

Specモード

最後に Specモードを使って、集計ページへグラフ表示機能を追加実装してみました。

• 月の切り替えで、その月を終点としたグラフを表示したい

新しいセッションから Spec を選択して依頼すると、リポジトリ内に .kiro/specs フォルダが生成され、そこに仕様ファイルが作られます。

Specでは以下3つのファイルが生成されます。

• requirements.md（要件定義書）
• design.md（設計書）
• tasks.md（実装計画）

Requirements Document では要件定義をまとめた内容が生成されます。
今回は「やりたいこと」だけを投げましたが、最初のプロンプトを具体的にすれば、さらに詳細な要件定義を作ってくれそうです。

# Requirements Document

## Introduction

月次集計画面のグラフ表示機能を改善し、ユーザーが選択した年月を基準として、その月を最後の月とした過去数ヶ月分のデータをグラフに表示する機能を実装します。現在のグラフは常に現在日時を基準とした過去6ヶ月分を表示していますが、ユーザーが過去の月を選択した場合でも、その選択した月を最後として適切な期間のデータを表示できるようにします。

## Requirements

### Requirement 1

**User Story:** As a user, I want the monthly trend charts to show data ending with my selected month, so that I can analyze historical trends for any specific time period.

#### Acceptance Criteria

1. WHEN ユーザーが年月を選択 THEN 月次推移グラフ SHALL その選択した月を最後の月として過去6ヶ月分のデータを表示する
2. WHEN ユーザーが2024年8月を選択 THEN グラフ SHALL 2024年3月から2024年8月までのデータを表示する
3. WHEN ユーザーが月を変更 THEN 全てのグラフ（月次推移、月別収支比較） SHALL 自動的に新しい期間のデータで更新される

### Requirement 2

**User Story:** As a user, I want consistent chart behavior across all graph types, so that all visualizations reflect the same time period I have selected.

#### Acceptance Criteria

1. WHEN ユーザーが年月を選択 THEN 月次推移ラインチャート SHALL 選択した月を終点とした期間のデータを表示する
2. WHEN ユーザーが年月を選択 THEN 月別収支比較バーチャート SHALL 選択した月を終点とした期間のデータを表示する
3. WHEN グラフデータが更新される THEN ローディング状態 SHALL 適切に表示される

### Requirement 3

**User Story:** As a user, I want the chart data to be efficiently fetched based on my selection, so that the interface remains responsive.

#### Acceptance Criteria

1. WHEN ユーザーが年月を変更 THEN システム SHALL 新しい期間に基づいてmonthlyTrendsクエリを実行する
2. WHEN monthlyTrendsクエリが実行される THEN システム SHALL 選択された年月とmonths数を適切にバックエンドに送信する
3. IF データ取得中 THEN UI SHALL ローディング状態を表示する

### Requirement 4

**User Story:** As a user, I want the backend to calculate trends based on any end date, so that I can view historical trend analysis.

#### Acceptance Criteria

1. WHEN バックエンドがmonthlyTrendsリクエストを受信 THEN システム SHALL 指定された終了年月から逆算して期間を計算する
2. WHEN 終了年月が指定される THEN システム SHALL その月の最終日を終了日として設定する
3. WHEN 期間が計算される THEN システム SHALL 指定されたmonths数分の過去データを取得する

Design Document では設計書が生成され、アーキテクチャやコンポーネント、インターフェイスなどがコードベースでまとめられます。

例：GraphQL Query Update

export const GET_MONTHLY_TRENDS = gql`
  query GetMonthlyTrends($userId: String!, $months: Int!, $endYear: Int!, $endMonth: Int!) {
    monthlyTrends(userId: $userId, months: $months, endYear: $endYear, endMonth: $endMonth) {
      year
      month
      monthName
      income
      expense
      balance
    }
  }
`;

Tasks Document では実装計画が生成されます。英語で出力されましたが、日本語で指示すれば日本語版も作れそうです。

# Implementation Plan

- [x] 1. Update backend GraphQL resolver and service method
  - Modify TransactionResolver to accept endYear and endMonth parameters
  - Update findMonthlyTrends method to calculate period based on end date
  - Add parameter validation for year and month values
  - _Requirements: 4.1, 4.2, 4.3_

- [x] 2. Update frontend GraphQL query definition
  - Modify GET_MONTHLY_TRENDS query to include endYear and endMonth parameters
  - Update query variables type definitions
  - _Requirements: 3.1, 3.2_

- [x] 3. Update SummaryPage component to pass selected date parameters
  - Modify useQuery call to include selectedYear and selectedMonth variables
  - Ensure query refetches when year/month selection changes
  - Handle loading states appropriately during data updates
  - _Requirements: 1.1, 1.2, 1.3, 2.1, 2.2, 2.3, 3.3_

- [x] 4. Test the implementation with different date selections
  - Write unit tests for the updated findMonthlyTrends method
  - Test edge cases like year boundaries and invalid dates
  - Verify frontend correctly displays updated chart data
  - _Requirements: 1.1, 1.2, 1.3, 2.1, 2.2_

出来上がったUI

Specモードから、月ごとにグラフを表示する一般的なUIを実装できました。
ただし、Vibeモード同様にコード品質には気になる点もあるので、生成されたSpecをもとに Claude Code を使ったほうが良いかもしれません。

作業時間

正確に計測はしていませんが、5つほどの機能追加や修正依頼をやりとりして、約2時間で実装が完了しました。

• Vibe/Specモードでのやりとり：約2時間
• 実装した機能：5つ
  • ログイン機能
  • ダークモード
  • 入れ替え機能
  • グラフ
  • 口座管理

まとめ

Kiro.dev を使って、既存アプリの修正や機能追加を試しました。
触ってみた感覚としては、特に Specモードが仕事で役立ちそう に感じました。

コード実装力はまだ高いとは言えず、Devin に近い印象を受けました。
ただしIDE上で要件定義などを生成してくれる点はユニークで、エンジニアよりも PM やディレクター が活用しやすいかもしれません。

Devinでも似たことは可能ですが、正式リリース以降に改めて試しつつ、切り替えも視野に入れて使い分けを考えていきたいです。

最後に補足ですが、Kiroが作業するときの「キョロキョロするアイコン」が可愛らしく、愛着のわくIDEだと感じました。