Kiro IDE で作成した Spec を Claude Code で実装したら Kiro IDE 単体より約 4 倍速かった

Kiro IDE で作成した Spec を Claude Code で実装したら Kiro IDE 単体より約 4 倍速かった

2026.02.26

はじめに

本記事は企業で Kiro を安全に使うシリーズの第 3 弾です。

記事 内容
① 前提知識編 企業利用の前提知識・リスクと対策方針
② Kiro IDE 単体編 Windows 環境への導入・ Spec 機能による分析ツール開発
③ 本記事 Kiro IDE で作成した Spec を Claude Code で実装・比較
④ Kiro CLI 編(予定) WSL への導入・読み取り専用プロファイルでの AWS リソース確認

前回の②では Kiro IDE 単体で Spec を作成し、タスクを順番に実行しました。
実装は完成しましたが、以下の 2 点が気になりました。

気になった点 内容
コンテキスト上限 大量のタスクを同じセクションで実行すると後半でコンテキストウィンドウの上限に達し、過去の会話が要約されて詳細が失われた
総実行時間 14 タスクの実行に 2 時間 57 分 24 秒を要した

本記事では同じ Spec・同じタスクリストを使い、タスク実行を WSL 上の Claude Code に任せたらどうなるかを検証します。

Claude Code とは

Claude Code は Anthropic が提供する AI コーディングアシスタントです。
VS Code 拡張機能として動作し、コードの生成・編集・テスト実行を自動化できます。
本記事では WSL2(Ubuntu)上で Claude Code を実行し、Kiro IDE で作成した Spec に基づいてタスクを実装します。

検証環境

項目 内容
OS Windows 11
Kiro IDE Windows ネイティブ版・ Kiro Enterprise( Spec 作成・タスクリスト生成に使用)
Claude Code 実行環境 WSL2( Ubuntu )
Claude Code モデル claude-sonnet-4
AWS 認証 IAM Identity Center 経由・読み取り専用( ReadOnly )プロファイル
プロジェクトパス /mnt/c/Users/yoshi.tatsushiro/projects/kiro-claude-project/test_kiro_ide_claudecode
準備するファイル 記事②で使用した report/ ディレクトリ、作成した requirements.mddesign.md

今回実装するツール

記事②と同じ AWS Organizations 組織ビューレポート分析ツールです。

入力: AWS Organizations の組織ビューレポート( JSON 形式・ 13 アカウント・ 55 チェック結果)

出力:

  • output/01_priority_list.md — 緊急度別是正対応リスト(高 / 中 / 低)
  • output/02_remediation_plan.md — 高優先度是正対応全体計画( 3 フェーズ)
  • output/03_persuasion_plan/ — アカウント別説得プラン( 13 アカウント分)

Kiro IDE + Claude Code の連携フロー

本記事での役割分担は以下の通りです。

Kiro IDE( Windows
 Spec 作成(要件定義・設計書・タスクリスト自動生成)
 タスクリストに Claude Code 実行環境を指定する指示を追加

WSL2( Ubuntu )上の Claude Code
 タスクリストを 1 タスクずつ実行
 307 件全テスト通過・出力ファイル 3 種生成

記事②との最大の違いは② タスクリストに Claude Code 実行環境を指定する指示を追加するステップです。

1. タスクリストへの Claude Code 実行環境指定

Kiro IDE でタスクリストを生成する際の追加指示

記事②と同じ仕様書をプロジェクトディレクトリにコピーしておき Spec でタスクリスト生成時に以下の指示を追加しました。また、作成されたタスクリストは WSL 上の Claude Code 実行において問題無いかレビューしました。

このプロジェクトのタスクは WSL 上の Claude Code で実行します。
以下の前提でタスクリストを生成してください。

実行環境: WSL2( Ubuntu )上の Claude Code
プロジェクトパス: /mnt/c/Users/test/projects/kiro-claude-project/test_kiro_ide_claudecode
Python コマンド: python3
Checkpoint: WSL 上で python3 -m unittest discover -s tests -v で実行する
ファイル配置:
メインスクリプト: /mnt/c/.../analyze_report.py
テストファイル: /mnt/c/.../tests/ 配下
入力ファイル(既存): /mnt/c/.../report/ 配下
出力ファイル(自動生成): /mnt/c/.../output/ 配下
統合テストは report/ ディレクトリの既存 JSON ファイルを使用する(新規ダミーファイルは作成しない)
データモデル・例外クラスは analyze_report.py 内に単一ファイルで定義する

この指示により、Kiro IDE が生成するタスクリストにパス・コマンド・テスト方針が明示され、
Claude Code が実行しやすい形式になりました。

2. Claude Code のセットアップ

kiro IDE から新しいターミナルを開き Ubuntu(WSL) を開く。

参考記事:
Kiro のターミナルで Windows Subsystem for Linux (WSL2) に接続する簡単な方法

claude を起動してプロジェクトディレクトリであることを確認。

3. タスク実行

今回は kiro IDE 単体との実行時間を比較したかったので以下のルールで先ずは Task 1 を実行。

  • タスクリストは 1 タスクずつ Claude Code で実行する。
  • Claude Code の実行結果をレビューしながら進める。
  • レビュー時に実行時間も取得して記録させる。
.kiro/specs/aws-organizations-report-analyzer/ Implementation Plan に従って
Task 1 を実行してください。

全 13 タスクの実行結果サマリーは以下の通りです。

タスク実行サマリー

タスク 内容 テスト件数(累計) 結果
Task 1 プロジェクト構造・データモデル
Task 2.1〜2.3 Report_Parser 実装
Task 3 Checkpoint Parser 動作確認 42 ✅ 全件 pass
Task 4 Priority_Classifier 実装
Task 5 Checkpoint Classifier 動作確認 73 ✅ 全件 pass
Task 6 Output_Generator 基本構造
Task 7 generate_priority_list
Task 8 generate_remediation_plan
Task 9 generate_persuasion_plans
Task 10 Checkpoint Output_Generator 動作確認 224 ✅ 全件 pass
Task 11 main() オーケストレーター
Task 12 統合テスト
Task 13 Final Checkpoint 全テスト最終確認 307 ✅ 全件 pass

記事②との実行時間比較

Checkpoint の速度差が特に顕著です。
Kiro に公平じゃないと怒られそうですが、その他タスク実行時間の速度差も速いです。

タスク 記事②( Kiro IDE 単体) 記事③( Claude Code ) 速度比
Task 1 4 分 58 秒 1 分 13 秒 約 1/4
Task 2.1〜2.3 26 分 56 秒 4 分 20 秒 約 1/6
Task 3 Checkpoint 23 分 22 秒 1 分 26 秒 約 1/16
Task 4 26 分 24 秒 2 分 54 秒 約 1/9
Task 5 Checkpoint 11 分 21 秒 30 秒 約 1/23
Task 6 6 分 43 秒 2 分 53 秒 約 1/2
Task 7 9 分 1 秒 2 分 28 秒 約 1/4
Task 8 10 分 23 秒 9 分 49 秒 約 1/1
Task 9 10 分 55 秒 5 分 52 秒 約 1/2
Task 10 Checkpoint 11 分 50 秒 51 秒 約 1/14
Task 11 8 分 19 秒 2 分 37 秒 約 1/3
Task 12 11 分 16 秒 2 分 47 秒 約 1/4
Task 13 Final Checkpoint 9 分 10 秒 1 分 20 秒 約 1/7
合計 2 時間 57 分 24 秒 約 39 分 0 秒 約 1/4

4. 実行結果確認

生成されたファイルの構成は以下の通りで Kiro IDE 単体と同様でした。

ファイル 内容 サイズ
output/01_priority_list.md 緊急度別是正対応リスト 5,525 bytes
output/02_remediation_plan.md 高優先度是正対応全体計画 7,485 bytes
output/03_persuasion_plan/ アカウント別説得プラン 13 ファイル

Kiro 単体で作成した内容との違いを確認

緊急度別是正対応リスト、アカウント別是正対応プランはほぼ同じ内容でした。
高優先度是正対応全体計画だけ各フェーズ毎に担当者アサイン表が作成されており、CCoE 観点だとこちらの全体計画の方が活用しやすいと感じました。

# 高優先度是正対応全体計画

生成日時: 2026 年 02 月 25 日 19:35:29(JST)

## エグゼクティブサマリー

高優先度項目 **19 件**(影響アカウント数: 13 アカウント)について、3フェーズの是正対応計画を策定しました。

| フェーズ | 対象期間 | 件数 |
|---------|---------|------|
| Phase 1 | Week 1-2 | 18 |
| Phase 2 | Week 2-4 | 1 |
| Phase 3 | Month 2  | 8 |

## Phase 1(Week 1-2): 廃止済みランタイムを使用する Lambda 関数

### 対象アカウント一覧

| AccountId | AccountName | AccountParentName |
|-----------|-------------|------------------|
| 111111111111 | acme-prod | ProductionOU |
| 222222222222 | acme-dev | DevelopmentOU |
| 333333333333 | acme-stg | StagingOU |
| 444444444444 | acme-data | DataOU |
| 555555555555 | acme-security | SecurityOU |
| 666666666666 | acme-shared | SharedServicesOU |
| 777777777777 | acme-ml | MLOU |
| 888888888888 | acme-network | NetworkOU |
| 999999999999 | acme-analytics | AnalyticsOU |
| 101010101010 | acme-integration | IntegrationOU |
| 121212121212 | acme-cache | CacheOU |
| 131313131313 | acme-messaging | MessagingOU |
| 141414141414 | acme-media | MediaOU |

### 対応内容

廃止済みランタイムを使用している Lambda 関数を最新のサポート対象ランタイムに更新します。

### 具体的な対応手順

1. 対象 Lambda 関数の現在のランタイムバージョンを確認
2. サポート対象の最新ランタイムバージョンを選定
3. 開発環境で新ランタイムでの動作検証を実施
4. 本番環境でランタイムバージョンを更新
5. 更新後の動作確認とログ監視を実施

### 担当者アサイン

| AccountId | AccountName | 担当者 | 完了予定日 |
|-----------|-------------|--------|-----------|
| 111111111111 | acme-prod |  |  |
| 222222222222 | acme-dev |  |  |
| 333333333333 | acme-stg |  |  |
| 444444444444 | acme-data |  |  |
| 555555555555 | acme-security |  |  |
| 666666666666 | acme-shared |  |  |
| 777777777777 | acme-ml |  |  |
| 888888888888 | acme-network |  |  |
| 999999999999 | acme-analytics |  |  |
| 101010101010 | acme-integration |  |  |
| 121212121212 | acme-cache |  |  |
| 131313131313 | acme-messaging |  |  |
| 141414141414 | acme-media |  |  |

### 完了確認方法

Trusted Advisor の再スキャンを実施し、対象 Lambda 関数の廃止済みランタイム警告が解消されていることを確認します。

---

## Phase 2(Week 2-4): ELB リスナーセキュリティおよびその他のセキュリティ ERROR

### 対象アカウント一覧

| AccountId | AccountName | AccountParentName |
|-----------|-------------|------------------|
| 111111111111 | acme-prod | ProductionOU |

### 対応内容

安全なプロトコルを使用していない ELB リスナー、およびその他のセキュリティ設定エラーを修正します。

### 具体的な対応手順

1. 対象 ELB リスナーの現在のセキュリティポリシーを確認
2. 推奨セキュリティポリシー(TLS 1.2 以上)を選定
3. リスナー設定を更新してセキュリティポリシーを適用
4. 接続テストを実施し、クライアント互換性を確認

### 担当者アサイン

| AccountId | AccountName | 担当者 | 完了予定日 |
|-----------|-------------|--------|-----------|
| 111111111111 | acme-prod |  |  |

### 完了確認方法

セキュリティスキャンを実施し、対象リソースのセキュリティ警告が解消されていることを確認します。

---

## Phase 3(Month 2): セキュリティ WARN およびフォールトトレランス ERROR

### 対象アカウント一覧

| AccountId | AccountName | AccountParentName |
|-----------|-------------|------------------|
| 111111111111 | acme-prod | ProductionOU |
| 222222222222 | acme-dev | DevelopmentOU |
| 444444444444 | acme-data | DataOU |
| 666666666666 | acme-shared | SharedServicesOU |
| 888888888888 | acme-network | NetworkOU |
| 101010101010 | acme-integration | IntegrationOU |
| 141414141414 | acme-media | MediaOU |

### 対応内容

セキュリティ設定の警告事項およびフォールトトレランスのエラーを修正します。

### 具体的な対応手順

1. 対象リソースの現在の設定とセキュリティ状態を確認
2. セキュリティベストプラクティスに基づく是正方針を策定
3. 是正対応を実施(設定変更、リソース更新等)
4. 是正後のセキュリティ状態を検証し、再スキャンで確認

### 担当者アサイン

| AccountId | AccountName | 担当者 | 完了予定日 |
|-----------|-------------|--------|-----------|
| 111111111111 | acme-prod |  |  |
| 222222222222 | acme-dev |  |  |
| 444444444444 | acme-data |  |  |
| 666666666666 | acme-shared |  |  |
| 888888888888 | acme-network |  |  |
| 101010101010 | acme-integration |  |  |
| 141414141414 | acme-media |  |  |

### 完了確認方法

Trusted Advisor の再スキャンを実施し、対象リソースの警告が解消されていることを確認します。

---

## トラッキングテーブル

| AccountId | AccountName | CheckName | Status | フェーズ |
|-----------|-------------|-----------|--------|---------|
| 111111111111 | acme-prod | ELB リスナーのセキュリティ | ERROR | Phase 2 |
| 111111111111 | acme-prod | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 111111111111 | acme-prod | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 222222222222 | acme-dev | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 222222222222 | acme-dev | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 222222222222 | acme-dev | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 333333333333 | acme-stg | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 333333333333 | acme-stg | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 444444444444 | acme-data | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 555555555555 | acme-security | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 666666666666 | acme-shared | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 666666666666 | acme-shared | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 777777777777 | acme-ml | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 888888888888 | acme-network | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 999999999999 | acme-analytics | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 101010101010 | acme-integration | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 121212121212 | acme-cache | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 131313131313 | acme-messaging | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |
| 141414141414 | acme-media | 廃止されたランタイムを使用する AWS Lambda 関数 | ERROR | Phase 1 |

5. コスト比較

Kiro IDE 単体との比較

タスクを Kiro Claude Code それぞれで実行した際のコストをクレジットを記録して比較しました。

項目 Kiro IDE 単体 Claude Code
総実行時間 2 時間 57 分 24 秒 約 39 分 0 秒
コスト 23.83 クレジット( Kiro Enterprise ) $17.60 USD
主要モデル auto claude-sonnet-4

Claude Code のキャッシュ効果

claude-sonnet-4 の cache read が 14.2M トークンに達していました。

Claude Code がタスク実行のたびに Spec ファイルと既存コードを参照する際、
キャッシュが効いてコストを大幅に抑制しているのかもしれません。

また claude-haiku-4claude-sonnet-4 を自動で使い分けており、
軽量タスクには Haiku を割り当てることでコスト効率を高めていそうです。

6. Kiro + Claude Code 連携のメリット

メリット 1: コンテキスト上限の問題が解消される

記事②では大量のタスクを Kiro IDE 単体で実行した際、
後半でコンテキストウィンドウの上限に達し、過去の会話が要約されて詳細が失われました。

Claude Code では各タスクを独立したセッションとして実行できるため、
コンテキスト上限の影響を受けません。
また Spec ファイルをキャッシュとして参照するため、
タスクをまたいでも設計の一貫性が保たれます。

メリット 2: 実装速度が約 4 倍向上

全タスクの合計実行時間を比較すると、 Claude Code を使った場合は
Kiro IDE 単体と比べて約 4 倍の速度で実装が完了しました。

特に実装系タスク( Task 1〜2・ Task 4 )での速度差が顕著で、
最大で約 1/6 の時間で完了しています。

一方、複雑なロジックを含む Task 8( generate_remediation_plan )では
記事②と同程度の時間を要しており、タスクの複雑度によって速度差は変わります

7. 気づき

Kiro IDE と Claude Code の役割分担が明確になった

今回の検証を通じて、以下の役割分担が有効であることがわかりました。

役割 適したツール 理由
仕様の言語化・要件定義 Kiro IDE 対話形式でのレビュー・修正が得意
設計書・タスクリスト生成 Kiro IDE Spec 機能で構造化されたドキュメントを自動生成
タスクの実装・テスト実行 Claude Code 高速・コンテキスト上限なし・キャッシュ効果大

タスクリストの品質が最終成果物の品質を決める

今回の検証で Claude Code はタスクリストに書かれた内容を忠実に実行してくれました。
しかし、そのためにはタスクが設計通りなのか、設計も要件通りなのか各フェーズでレビューをおこなう。
また、実行環境・パス・既知の問題点などを明示すると、手戻りなく実装が進められた。

Kiro IDE で Spec を作成する際に「どれだけ丁寧にタスクリストを仕上げるか」が、
Claude Code との連携品質を左右する最大のポイントかもしれません。

まとめ

本記事では Kiro IDE で作成した Spec を WSL 上の Claude Code で実装し、Kiro IDE 単体との比較検証を行いました。

検証結果

項目 Kiro IDE 単体 Kiro IDE + Claude Code
総実行時間 2 時間 57 分 24 秒 約 39 分 0 秒(約 1/4)
コンテキスト上限 後半で発生 発生なし

Kiro IDE + Claude Code 連携のポイント

  • タスクリスト生成時に Claude Code 実行環境(パス・コマンド・テスト方針)を明示する
  • Kiro IDE は「設計」、 Claude Code は「実装」と役割を明確に分担する

次回の④ Kiro CLI 編では、 WSL に Kiro CLI を導入して
読み取り専用プロファイルで AWS リソースを確認する手順を紹介します。

シリーズ構成

記事 内容
① 前提知識編 企業利用の前提知識・リスクと対策方針
② Kiro IDE 単体編 Windows 環境への導入・ Spec 機能による分析ツール開発
③ 本記事 Kiro IDE で作成した Spec を Claude Code で実装・比較
④ Kiro CLI 編(予定) WSL への導入・読み取り専用プロファイルでの AWS リソース確認

この記事が誰かのお役に立てれば幸いです。以上 Yoshi でした。

参考

この記事をシェアする

FacebookHatena blogX

関連記事