とりあえずKiroを触ってみる（spec編）

はじめに

巷で話題のKiroを使ってみます。何事もスピードが大事！

Kiroとは？

CursorのようなAIエージェント内蔵型IDEで、2025年7月15日にプレビュー版が公開されました。
詳しくは下記から。

環境

• OS: Windows 11
• Kiro: v0.1.0
• 利用モデル: Claude Sonnet 4

インストールとセットアップ

1. 公式サイト（上記）から Windows 版をダウンロードし、ウィザードを進めます
2. 起動するとログイン画面が表示されます。今回は GitHub でサインインします
3. 初回起動時にVS Code設定をインポートできるので、インポートしておきます

IDEの実際の画面です。VS CodeそっくりのUIに“Kiro”タブが追加されてますね。

今回やること

今回は、Claude Codeで個人的に作っていたオーディオビジュアライザーと同様の要件を与えて、どんな感じで実装してくれるのか試します。

オーディオビジュアライザーはこんな感じの再生されてる音楽によって波形とかいろいろ動いて楽しいやつです。

やってみる

とりあえずプロジェクトをつくります。

最初にvibeとspecの2つのモードが選べます。vibeはいつものバイブコーディングですが、specがKiro特有のやつです。

Kiro スペック (spec) は、機能を深く考える必要がある時、事前計画が必要なリファクタリング作業、システムの動作を理解したい時など、プロダクションに移行するために必要なほとんどの場面で有用な成果物です。開発を始める時、要件は通常不明確なので、開発者は計画と明確化のために仕様を使用します。仕様は同じ方法で AI エージェントをより良い実装に導くことができます。
https://aws.amazon.com/jp/blogs/news/introducing-kiro/

specを使って下記の要件をぶち込んでみます。
要件はClaude Codeに作らせました。

要件のプロンプト

下記の要件を満たすWebアプリケーションを作成して。

# 🎵 オーディオビジュアライザー 要件定義書

## 1. プロジェクト概要

### 1.1 プロジェクト名
**Kiro-Test**

### 1.2 概要
音楽ファイルを読み込み、リアルタイムで美しいビジュアルエフェクトを生成するWebアプリケーション。複数のビジュアライザーモードを提供し、ユーザーが音楽を視覚的に楽しめる体験を実現する。

### 1.3 目的
- 音楽をより豊かに楽しむための視覚的体験を提供
- 複数のビジュアライザーモードで様々な表現を可能にする
- 直感的で使いやすいインターフェースを提供

## 2. 機能要件

### 2.1 ファイル処理機能
- **オーディオファイル対応**
  - 対応フォーマット：MP3、WAV、OGG、AAC、FLAC
  - ドラッグ&ドロップによるファイル選択
  - ファイル署名検証とMIMEタイプチェック
  - 進捗表示付きファイルアップロード

- **画像ファイル対応**
  - 対応フォーマット：JPEG、PNG、GIF、WebP
  - センター画像として設定可能
  - ビジュアライザー背景との統合

### 2.2 オーディオ再生機能
- **基本操作**
  - 再生・一時停止・停止
  - シークバーでの再生位置制御
  - 音量調整（0-100%）
  - 現在時刻・総時間表示

- **高度な機能**
  - Web Audio APIを活用した高品質再生
  - リアルタイム音響解析
  - オーディオコンテキストの適切な管理

### 2.3 ビジュアライザー機能
- **ビジュアライザーモード**
  - 🌀 円形（Circular）：クラシックな円形周波数ビジュアライザー
  - 〰️ 波形（Waveform）：リアルタイム音声波形表示
  - 📊 周波数バー（Frequency Bars）：周波数スペクトラム棒グラフ
  - 🪐 太陽系（Solar System）：惑星軌道ビジュアライザー
  - ✨ パーティクルフィールド（Particle Field）：ダイナミックパーティクルシステム

- **設定機能**
  - 各モードの個別ON/OFF切り替え
  - 感度調整（0.1x - 3.0x）
  - リアルタイム設定反映

- **レンダリング**
  - HTML5 Canvasを使用したハードウェアアクセラレーション
  - グラデーション効果とアニメーション
  - 60FPSでの滑らかな描画

### 2.4 BPM検出機能
- **リアルタイム検出**
  - 音楽のBPM（テンポ）を自動検出
  - 検出されたBPMの表示
  - 再生中の動的BPM更新

### 2.5 UI/UXコンポーネント
- **レスポンシブデザイン**
  - デスクトップ・タブレット・モバイル対応
  - グリッドレイアウトでの最適化

- **通知システム**
  - 成功・エラー・情報メッセージ
  - トースト通知でのユーザーフィードバック

- **テーマ・デザイン**
  - グラデーション背景（Aurora テーマ）
  - ガラス効果（Glassmorphism）
  - 直感的なアイコンとUI

## 3. 非機能要件

### 3.1 性能要件
- **レスポンス時間**
  - ファイル読み込み：2秒以内
  - ビジュアライザー開始：1秒以内
  - 設定変更の反映：即座（100ms以内）

- **フレームレート**
  - ビジュアライザー描画：60FPS維持
  - CPUエフィシェントなレンダリング

### 3.2 互換性要件
- **ブラウザ対応**
  - モダンブラウザ（Chrome、Firefox、Safari、Edge）
  - Web Audio API対応必須
  - ES2020以上のJavaScript対応

- **デバイス対応**
  - デスクトップPC
  - タブレット
  - スマートフォン

### 3.3 セキュリティ要件
- **ファイル検証**
  - ファイル署名による偽装防止
  - サイズ制限によるDoS攻撃防止
  - 悪意のあるファイルの検出

- **データ保護**
  - ファイルはローカル処理のみ
  - 外部サーバーへの送信なし
  - メモリリークの防止

### 3.4 保守性要件
- **コード品質**
  - TypeScript完全対応
  - ESLint/Prettier準拠
  - テストカバレッジ80%以上

- **アーキテクチャ**
  - クリーンアーキテクチャ（3層分離）
  - 依存性注入パターン
  - 単一責任原則の徹底

## 4. 技術仕様

### 4.1 フレームワーク・ライブラリ
- **フロントエンド**
  - Remix（React フルスタックフレームワーク）
  - TypeScript
  - Tailwind CSS

- **オーディオ処理**
  - Web Audio API
  - AnalyserNode（周波数解析）
  - AudioContext（音声コンテキスト）

- **テスト**
  - Vitest（単体テスト）
  - React Testing Library
  - Playwright（E2Eテスト）

### 4.2 アーキテクチャ構成

app/
├── domain/          # ビジネスロジック層
│   ├── entities/    # エンティティ
│   ├── repositories/ # リポジトリインターフェース
│   └── usecases/    # ユースケース
├── infrastructure/ # インフラストラクチャ層
│   ├── audio/      # オーディオサービス
│   └── repositories/ # リポジトリ実装
└── presentation/   # プレゼンテーション層
    ├── components/ # UIコンポーネント
    └── hooks/      # カスタムフック


### 4.3 状態管理
- **カスタムフック**
  - `useAudio`：オーディオ再生状態
  - `useVisualizer`：ビジュアライザー状態
  - `useFileUpload`：ファイルアップロード状態
  - `useBPM`：BPM検出状態

### 4.4 データフロー
1. ファイルアップロード → エンティティ作成
2. オーディオ再生 → Web Audio API
3. リアルタイム解析 → ビジュアライザー更新
4. Canvas描画 → 視覚的表現

## 5. 品質保証

### 5.1 テスト戦略
- **単体テスト**：コンポーネント、フック、ビジネスロジック
- **統合テスト**：層間の相互作用
- **E2Eテスト**：ユーザーワークフロー

### 5.2 コード品質
- **静的解析**：ESLint、TypeScript
- **フォーマット**：Prettier
- **型安全性**：TypeScript strict mode

### 5.3 パフォーマンス監視
- **メモリ管理**：リソースの適切なクリーンアップ
- **CPU使用率**：効率的なアニメーションループ
- **レンダリング**：フレームドロップの最小化

## 6. 運用・保守

### 6.1 開発環境
- **開発サーバー**：`npm run dev`
- **ビルド**：`npm run build`
- **テスト**：`npm test`

### 6.2 デプロイ
- **静的サイトホスティング対応**
- **CDN配信最適化**
- **ブラウザキャッシュ活用**

### 6.3 モニタリング
- **エラー追跡**：クライアントサイドエラー
- **パフォーマンス**：Core Web Vitals
- **ユーザビリティ**：UI/UX改善指標

## 7. 制約事項

### 7.1 技術制約
- Web Audio API対応ブラウザ必須
- HTTPS環境でのみ完全動作
- ファイルサイズ制限（メモリ使用量考慮）

### 7.2 機能制約
- オフライン利用（ファイル処理のみ）
- 単一ファイル処理（プレイリスト非対応）
- リアルタイム音声入力非対応

### 7.3 運用制約
- クライアントサイドアプリケーション
- サーバーサイド処理なし
- 外部API依存なし

---

モデルはClaude Sonnet 4でいきます。

specの実行

1. Requirements（要件定義）

最初の入力内容に基づいて、要件定義ファイルを作ってくれます。.kiro\specs\audio-visualizer\requirements.mdに下記のようなファイルを作ってくれました。(抜粋）

# 要件定義書

## はじめに

音楽ファイルを読み込み、リアルタイムで美しいビジュアルエフェクトを生成するWebアプリケーション「Kiro-Test」を開発します。このアプリケーションは、複数のビジュアライザーモードを提供し、ユーザーが音楽を視覚的に楽しめる体験を実現します。Web Audio APIを活用したハイパフォーマンスなオーディオ処理と、HTML5 Canvasによる滑らかなビジュアル表現を特徴とします。

## 要件

### 要件 1: ファイル処理機能

**ユーザーストーリー:** 音楽愛好家として、様々な形式の音楽ファイルを簡単にアップロードして、すぐにビジュアライザーで楽しめるようにしたい

#### 受け入れ基準

1. WHEN ユーザーがMP3、WAV、OGG、AAC、FLACファイルをドラッグ&ドロップした時 THEN システムはファイルを受け入れて処理を開始する
2. WHEN ユーザーが対応していないファイル形式をアップロードした時 THEN システムはエラーメッセージを表示して処理を拒否する
3. WHEN ファイルアップロード中 THEN システムは進捗バーを表示してユーザーに処理状況を知らせる
4. WHEN ユーザーがJPEG、PNG、GIF、WebP画像ファイルをアップロードした時 THEN システムは背景画像として設定する
5. IF ファイルサイズが制限を超えている場合 THEN システムはアップロードを拒否してエラーメッセージを表示する

### 要件 2: オーディオ再生機能

**ユーザーストーリー:** ユーザーとして、音楽ファイルを自由に操作（再生、停止、音量調整など）して、快適に音楽を楽しみたい

#### 受け入れ基準

1. WHEN ユーザーが再生ボタンをクリックした時 THEN システムは音楽の再生を開始する
2. WHEN ユーザーが一時停止ボタンをクリックした時 THEN システムは音楽を一時停止する
3. WHEN ユーザーがシークバーをドラッグした時 THEN システムは指定された位置から再生を再開する
4. WHEN ユーザーが音量スライダーを調整した時 THEN システムは音量を0-100%の範囲で変更する
5. WHEN 音楽が再生中 THEN システムは現在の再生時間と総時間を表示する
6. WHEN オーディオファイルが読み込まれた時 THEN システムはWeb Audio APIを使用して高品質な音響解析を開始する
...

ユーザーストーリーまで作ってくれてます。内容は良さそうなので、次に進みます。

2. Design（設計）

最初に技術調査をして、実際の設計書であるdesign.mdを作っています。

Kiroの応答

## 技術調査

### Web Audio API の機能調査

Web Audio API は以下の主要コンポーネントを提供します：

* **AudioContext**: オーディオ処理のメインコンテキスト
* **AnalyserNode**: リアルタイム周波数・時間領域解析
* **GainNode**: 音量制御
* **AudioBuffer**: オーディオデータの格納

### ビジュアライザーの実装アプローチ

* **Canvas 2D API**: 高性能な 2D 描画
* **requestAnimationFrame**: 60 FPS での滑らかなアニメーション
* **FFT 解析**: 周波数スペクトラムの取得（通常 1024 または 2048 サンプル）

### BPM 検出アルゴリズム

* **Beat Detection**: ピーク検出とテンポ解析
* **Autocorrelation**: 周期性の検出
* **Moving Average**: ノイズ除去

### アーキテクチャパターン

* **Clean Architecture**: ドメイン・インフラ・プレゼンテーション層の分離
* **Repository Pattern**: データアクセスの抽象化
* **Observer Pattern**: 状態変更の通知

---

## design.md

設計書を作成しました。この設計書では以下の主要な要素を詳細に定義しています：

### アーキテクチャ設計

* Clean Architecture（3 層分離）の採用
* プレゼンテーション、ドメイン、インフラストラクチャ層の明確な分離
* データフローの可視化

### 技術設計

* Web Audio API を活用したオーディオ処理システム
* TypeScript による型安全なインターフェース定義
* Canvas 2D による高性能ビジュアライザー

### エラーハンドリング

* カスタムエラークラスによる分類
* 重要度別のエラー処理戦略
* グローバルエラーハンドラー

### テスト戦略

* テストピラミッドに基づく包括的テスト
* 単体・統合・E2E テストの具体的な実装例
* パフォーマンステストの考慮

実際に作られた設計書はこんな感じです。(抜粋）

# 設計書

## 概要

音楽ビジュアライザーWebアプリケーション「Kiro-Test」は、Web Audio APIとHTML5 Canvasを活用したリアルタイム音楽ビジュアライゼーションシステムです。Clean Architectureパターンを採用し、TypeScript + Remix + Tailwind CSSで構築します。

## アーキテクチャ

### 全体アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│                    Presentation Layer                        │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐ │
│  │   Components    │  │     Hooks       │  │    Pages     │ │
│  │                 │  │                 │  │              │ │
│  │ - AudioPlayer   │  │ - useAudio      │  │ - Index      │ │
│  │ - Visualizer    │  │ - useVisualizer │  │              │ │
│  │ - FileUpload    │  │ - useFileUpload │  │              │ │
│  │ - Controls      │  │ - useBPM        │  │              │ │
│  └─────────────────┘  └─────────────────┘  └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────┐
│                     Domain Layer                            │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐ │
│  │    Entities     │  │   Use Cases     │  │ Repositories │ │
│  │                 │  │                 │  │ (Interface)  │ │
│  │ - AudioFile     │  │ - PlayAudio     │  │ - IAudioRepo │ │
│  │ - VisualizerData│  │ - AnalyzeAudio  │  │ - IFileRepo  │ │
│  │ - BPMData       │  │ - DetectBPM     │  │              │ │
│  │ - Settings      │  │ - ProcessFile   │  │              │ │
│  └─────────────────┘  └─────────────────┘  └──────────────┘ │
└─────────────────────────────────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────┐
│                Infrastructure Layer                         │
│  ┌─────────────────┐  ┌─────────────────┐  ┌──────────────┐ │
│  │ Audio Services  │  │ File Services   │  │ Repositories │ │
│  │                 │  │                 │  │ (Concrete)   │ │
│  │ - WebAudioAPI   │  │ - FileReader    │  │ - AudioRepo  │ │
│  │ - AnalyserNode  │  │ - FileValidator │  │ - FileRepo   │ │
│  │ - BPMDetector   │  │ - ImageProcessor│  │              │ │
│  └─────────────────┘  └─────────────────┘  └──────────────┘ │
└─────────────────────────────────────────────────────────────┘

### データフロー
...

エラー処理もマーメイド図で見やすい！
大丈夫そうなので次に進みます。

3. Tasks（タスクリストの作成）

作成した設計書に基づいて、実行可能なタスクに分解していくフェーズとのこと。

実際にお出しされたものがこれです。（抜粋）

# 実装タスクリスト

- [ ] 1. プロジェクト基盤とアーキテクチャ設定
  - Remix + TypeScript + Tailwind CSSプロジェクトの初期化
  - Clean Architectureディレクトリ構造の作成（app/domain, app/infrastructure, app/presentation）
  - ESLint、Prettier、Vitestの設定
  - 基本的な型定義ファイルの作成
  - _要件: 要件6（パフォーマンスとセキュリティ）_

- [ ] 2. ドメインエンティティとインターフェースの実装
  - AudioFile、VisualizerData、BPMData、Settingsエンティティの作成
  - ユースケースインターフェース（IPlayAudioUseCase、IAnalyzeAudioUseCase、IDetectBPMUseCase）の定義
  - リポジトリインターフェース（IAudioRepository、IFileRepository）の定義
  - エンティティの単体テスト作成
  - _要件: 要件1（ファイル処理機能）、要件2（オーディオ再生機能）_

- [ ] 3. ファイル処理インフラストラクチャの実装
  - FileRepositoryの具象実装（ファイル検証、ArrayBuffer読み込み）
  - 対応ファイル形式の検証ロジック（MP3、WAV、OGG、AAC、FLAC、JPEG、PNG、GIF、WebP）
  - ファイルサイズ制限とセキュリティ検証
  - ファイル処理の単体テスト作成
  - _要件: 要件1（ファイル処理機能）、要件6（パフォーマンスとセキュリティ）_
...

タスクの実行順序はTDDに基づいて行われている模様。
また、クリーンアーキテクチャも要件に含めたため、それを満たすように、ドメイン層とインターフェース層から段階的にタスクを進めるような計画になっています。
ここで気になる部分があったら、人間が適宜修正を挟んでいく感じですね。

この工程も大丈夫そうなら、Specの実行が完了になります。
この後の実装は、Tasks.mdファイルを開いて各タスクの横にある「Start task」ボタンを押すことで実施を指示できます。

ボタンを押すと、右タブのチャット画面でタスクが実行されます。あとはAgentの実行完了を待ちましょう。

…と思っていたのですが、リクエストが多いのか、タスクを実行させようとすると頻繁に An unexpected error occurred, please retry. が出てしまう事態に。

ですので今回はここまで。

エージェントの設定関連メモ

AutopilotモードとSupervisedモード

AIの操作権限を制御できる設定です。自走させたいならAutopilot、随時確認でも破壊的変更を避けたいならSupervisedを使うべき？

• Autopilot
  • ファイルの作成・編集・削除をAIが自動で行うことができます
• Supervised
  • すべての操作を実行前にユーザーの承認が必要になります

コマンドの実行について

現状では完全にすべてのコマンドを実行させていいような設定はなさそうです。代わりに自動実行を許可するコマンドを自分で設定できます。

この設定はコマンドの実行を確認されたときに、右から2番目の再生ボタンを押すと「どの範囲までコマンドを許可しますか？」というサジェストが出ます。
好きなやつをクリックすると、それが登録されて以降は自動実行されるという感じです。

まとめ

Claude Codeのように爆速で作業を進めるよりは、要件定義⇒設計⇒タスク分解のように丁寧なフローで前準備を進めていけるのが良いところだと思いました。なによりこのフローがIDEの機能として備わっているのが画期的です。
今回はspecを試しただけになりましたが、設計はKiroに任せて実装はClaude Codeにやらせる、のようなやり方もあるみたいなので、次はそれを試そうと思います。

あと、何より良いのはKiroくんがかわいいことですね！癒しは重要！