Kiro IDE の Spec 機能で AWS Organizations レポートを CCoE 観点で分析してみた（Windows 環境）

はじめに

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

前回の①前提知識編ではデータ漏洩防止・権限制御・プラン選択の観点を整理しました。
本記事では実際に Kiro IDE を Windows 環境に導入し、 AWS Organizations の組織ビューレポート（ JSON 形式）を CCoE 観点で分析するユースケースを検証した内容をお届けします。

具体的には以下の 2 パターンを比較しています。

• Kiro IDE 単体: Spec 機能で仕様書・要件定義・設計・タスク分解を行い、そのままタスクを実行
• Kiro IDE + Claude Code: Spec で設計した内容を WSL 上の Claude Code に渡して実装・実行まで自動化

Kiro IDE とは

Kiro IDE は AWS が開発した AI 駆動の統合開発環境です。
通常の IDE としてコードを書く用途に加え、 Spec 機能が特徴的です。

Spec 機能とは、自然言語で記述した仕様から以下を自動生成する機能です。

• 要件定義（ Requirements Document ）
• 設計書（ Design Document ）
• タスクリスト（ Implementation Plan ）

例えば「ユーザー認証機能を実装してください」と入力すると、
要件定義・設計書・実装タスクが自動生成され、そのままタスクを実行して実装まで進められます。

また Claude Code との連携も可能で、 Spec で定義した設計を WSL 上の Claude Code に渡すことで、実装タスク等を処理できます。
Claude Code との連携については次回の③ Kiro IDE + Claude Code 編で詳しく紹介します。

Kiro の詳細な機能説明については、社内メンバーが執筆した以下のブログも参照してください。

• 【アップデート】 Kiro 一般提供開始！ Amazon Q Developer CLI は Kiro CLI へ統合されました
• Kiro CLI に入門

AWS Organizations の組織ビューレポートとは

AWS Organizations の管理アカウントから、配下の全メンバーアカウントにおける Trusted Advisor の推奨アクション（セキュリティ、コスト最適化など）や AWS Health のイベントを一元的に集約し、CSV や JSON 形式でダウンロードできる機能です。

組織ビューレポートの取得方法等については、社内メンバーが執筆した以下のブログも参照してください。

• AWS Organizations 管理下の全アカウントの Trusted Advisor による指摘事項を確認できる「組織ビュー」のレポートで確認・可視化できる内容を調べてみた

1. Kiro IDE のインストール（Windows）

インストール概要

• Kiro 公式サイト からインストーラーをダウンロードしてインストール
• 初回起動時に IAM Identity Center 経由で認証（企業利用推奨）
• 認証完了後、プロジェクトフォルダを開いて利用開始

詳細なインストール・認証手順は別記事で紹介予定です。

2. 検証ユースケース：AWS Organizations レポートの CCoE 観点分析

背景

CCoE では AWS Organizations の 組織ビューレポート（ Trusted Advisor の結果を組織全体で集約した JSON レポート）を定期的に取得し、ガバナンス状況を把握していることとした。

今回、サンプルで作成して使用したレポートのファイル構成は以下の通りです。

test_kiro_ide/
└── report/
├── summary.json      # 組織全体・アカウント別のカテゴリステータスサマリー
├── resources-0.json  # 個別リソースの詳細チェック結果（分割ファイル 1/5）
├── resources-1.json
├── resources-2.json
├── resources-3.json
├── resources-4.json
└── schema.json       # チェック ID とフィールド定義のマッピング

summary.json には組織全体のカテゴリ別ステータス集計が含まれています。
今回の検証環境では以下の状況でした。

このレポートを手動で分析するには多くの時間がかかります。
Kiro IDE の Spec 機能を使って 緊急度別の是正優先度付け → 高優先度の全体計画 → 担当者説得プランの生成 までを自動化できるか検証しました。

検証環境

本記事の検証は以下の環境で実施しています。

3. Kiro IDE 単体での検証：Spec 機能を使った分析ツール開発

Spec 機能とは

Spec 機能は Kiro IDE のサイドバーから起動できる機能です。
自然言語で仕様を入力すると、以下の 3 つのドキュメントを自動生成します。

3-1. 仕様書の入力

Kiro IDE で test_kiro_ide フォルダを開き、 Spec 機能を起動して以下の仕様書を入力しました。

入力した仕様書の要点は以下の通りです。

# AWS Organizations 組織ビューレポート CCoE 分析ツール
## 概要
AWS Organizations の組織ビューレポート（ Trusted Advisor の結果を組織全体で集約した JSON レポート）を
CCoE 観点で分析し、以下の 3 つのアウトプットを生成するツールを作成してください。
1. 緊急度別（高・中・低）の是正対応対象リストと優先度付け
2. 高優先度項目の是正対応全体計画
3. 各アカウント担当者向けの是正対応説得プラン
---
## 入力ファイル
### ファイル保存パス

C:\Users\test\projects\kiro-claude-project\test_kiro_ide\report

### ファイル構成

| ファイル名 | 内容 |
|-----------|------|
| summary.json | 組織全体およびアカウント別のカテゴリステータスサマリー |
| resources-0.json | 個別リソースの詳細チェック結果（分割ファイル 1/5） |
| resources-1.json | 個別リソースの詳細チェック結果（分割ファイル 2/5） |
| resources-2.json | 個別リソースの詳細チェック結果（分割ファイル 3/5） |
| resources-3.json | 個別リソースの詳細チェック結果（分割ファイル 4/5） |
| resources-4.json | 個別リソースの詳細チェック結果（分割ファイル 5/5） |
| schema.json | チェック ID とフィールド定義のマッピング |

### ファイル仕様

#### summary.json の構造

- `numAccounts`: 組織内のアカウント総数
- `categoryStatusMap`: カテゴリ別（セキュリティ・コスト最適化・フォールトトレランス等）のステータス集計
- `accountStatusMap`: アカウント ID をキーとしたアカウント別カテゴリステータス

#### resources-*.json の構造

個別リソースのチェック結果の配列。各レコードに以下のフィールドを含む。

- `AccountId`: AWS アカウント ID
- `AccountName`: AWS アカウント名
- `AccountParentName`: 所属 OU 名
- `Category`: チェックカテゴリ（セキュリティ・コスト最適化等）
- `CheckName`: チェック名
- `CheckId`: チェック ID（ schema.json と紐付け）
- `ステータス`: 赤（ ERROR ）・黄（ WARN ）・緑（ OK ）
- `リージョン`: リソースが存在する AWS リージョン
- その他チェック固有のフィールド（ schema.json で定義）

#### schema.json の構造

チェック ID をキーとしたフィールド定義のマッピング。
`resources-*.json` の各レコードのフィールド名を解決するために使用する。

---

## 緊急度判定ロジック

以下の基準で緊急度を判定してください。

### 高（即時対応：今すぐ対応が必要）

以下のいずれかに該当するリソース。

- カテゴリ: `security`（セキュリティ）、ステータス: `ERROR`（赤）
- 廃止済みランタイムを使用している Lambda 関数（ CheckId: `L4dfs2Q4C5` ）
- 安全なプロトコルを使用していない ELB リスナー（ CheckId: `a2sEc6ILx` ）かつステータス: `ERROR`（赤）

### 中（30 日以内に対応が必要）

以下のいずれかに該当するリソース。

- カテゴリ: `security`（セキュリティ）、ステータス: `WARN`（黄）
- カテゴリ: `fault_tolerance`（フォールトトレランス）、ステータス: `ERROR`（赤）
- RDS 保管時暗号化未設定（ CheckId: `c18d2gz134` ）

### 低（90 日以内に対応が必要）

以下のいずれかに該当するリソース。

- カテゴリ: `cost_optimizing`（コスト最適化）、ステータス: `WARN`（黄）
- カテゴリ: `operational_excellence`（運用上の優秀性）、ステータス: `WARN`（黄）
- カテゴリ: `fault_tolerance`（フォールトトレランス）、ステータス: `WARN`（黄）

---

## 出力仕様

Output 1: 緊急度別是正対応リスト
出力形式: Markdown ファイル（ output/01_priority_list.md ）

以下の構成で出力してください。
ファイル構成イメージ

# 緊急度別是正対応リスト

## サマリー
対応期限ごとの件数を表形式で出力する。
- 高: 即時対応
- 中: 30 日以内
- 低: 90 日以内

## 緊急度：高（即時対応）
アカウント ID・アカウント名・所属 OU・チェック名・リージョン・詳細を表形式で出力する。

## 緊急度：中（30 日以内）
アカウント ID・アカウント名・所属 OU・チェック名・リージョン・詳細を表形式で出力する。

## 緊急度：低（90 日以内）
アカウント ID・アカウント名・チェック名・月間削減可能額・詳細を表形式で出力する。

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

出力形式: Markdown ファイル（ `output/02_remediation_plan.md` ）

以下の構成で出力してください。
ファイル構成イメージ

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

## エグゼクティブサマリー
対象アカウント数・高優先度件数・対応完了目標日を記載する。

## Phase 別対応計画

### Phase 1（Week 1-2）: 最も緊急度の高いチェック名
- 対象アカウント一覧
- 対応内容
- 対応手順
- 担当者アサイン欄（空欄）
- 完了確認方法

### Phase 2（Week 2-4）: 次に緊急度の高いチェック名
Phase 1 と同じ構成で出力する。

### Phase 3（Month 2）: その次のチェック名
Phase 1 と同じ構成で出力する。

## 対応状況トラッキング表
Phase・チェック名・対象アカウント・担当者・期限・ステータスを表形式で出力する。

Output 3: アカウント担当者向け説得プラン
出力形式: アカウントごとに個別の Markdown ファイル
（ output/03_persuasion_plan/[アカウント ID]_[アカウント名].md ）_

高優先度（緊急度：高）の是正対象が存在するアカウントのみ生成してください。
各ファイルは以下の構成で出力してください。
ファイル構成イメージ

# [アカウント名] 是正対応のお願い

## 対応が必要な項目サマリー
緊急度・チェック名・リソース・対応期限を表形式で出力する。

## なぜ今すぐ対応が必要か

### [チェック名 1]

現状のリスク:
- リスクの内容を具体的に記載
- 該当リソース名・ARN を明示
- 廃止済みの場合は廃止日と経過日数を記載

ビジネスインパクト:
- セキュリティインシデントが発生した場合の影響範囲
- コンプライアンス上のリスク
- AWS サポート対象外となるリスク

推奨アクション:
- 具体的な対応手順（ステップバイステップ）
- 移行先の推奨バージョン・設定値
- 対応後の確認方法

### [チェック名 2]
チェック名 1 と同じ構成で出力する。

## 対応スケジュール案
対応内容・推奨期限・工数目安を表形式で出力する。

## 参考リンク
AWS 公式ドキュメントへのリンクを記載する。

---
## 非機能要件
- 出力ファイルはすべて UTF-8 で保存する
- 出力先ディレクトリ `output/` が存在しない場合は自動作成する
- resources-*.json は 0 〜 4 の連番で存在するが、ファイルが存在しない場合はスキップする
- アカウント ID はそのまま出力する（マスキング不要）
- 金額は USD で小数点以下 2 桁まで表示する
- 日付は YYYY 年 MM 月 DD 日形式で表示する
---
## 実装言語
Python 3.x を使用してください。
外部ライブラリは標準ライブラリのみ使用し、 pip install 不要で動作するようにしてください。
---
## 実行方法
以下のコマンドで実行できるようにしてください。
python analyze_report.py

3-2. 要件定義の自動生成と修正

仕様書を入力すると Kiro が Requirements Document を自動生成しました。
生成された要件定義は 8 つの主要機能に分解されていました。

自動生成された要件定義をレビューした結果、以下の修正を加えました。

修正 1: Phase 分類基準の明示

是正対応全体計画の Phase 分類基準が曖昧だったため、以下を明示しました。

• Phase 1（ Week 1-2 ）: 廃止済みランタイム Lambda（ CheckId: L4dfs2Q4C5 ）
• Phase 2（ Week 2-4 ）: ELB リスナーセキュリティ（ CheckId: a2sEc6ILx ）およびその他セキュリティ ERROR
• Phase 3（ Month 2 ）: セキュリティ WARN およびフォールトトレランス ERROR

修正 2: ビジネスインパクトの具体的数値の追加

担当者説得プランに以下の具体的数値を含めるよう追加しました。

• 廃止済みランタイム: 廃止日・経過日数・ 1 日あたりの平均呼び出し回数
• コスト最適化: 月間削減可能額・削減率
• セキュリティ: 該当リソース名または ARN・非準拠の理由

修正 3: 重複判定の優先順位の追加

同一リソースが複数の緊急度ルールに該当する場合、
最高緊急度を適用して 1 件のみ出力するルールを追加しました。

3-3. 設計書の自動生成と修正

要件定義が確定すると Kiro が Design Document を自動生成しました。
設計は以下の 3 層アーキテクチャで構成されています。

システム構成

• analyze_report.py（エントリーポイント）
• Report_Parser: JSON ファイル読み込み・データ検証・ CheckResult オブジェクトへの変換
• Priority_Classifier: 緊急度ルール適用・チェック結果分類（高・中・低）
• Output_Generator: Markdown ファイル生成・フォーマット処理

設計書のレビューで以下の修正を加えました。

修正 1: テストライブラリの制約

設計書に hypothesis（外部ライブラリ）が含まれていたため、
Python 標準ライブラリの unittest のみを使用する方針に修正しました。

修正 2: metadata フィールドの取り扱い

resources-*.json の元フィールド（日本語キー含む）をそのまま格納し、
参照時は dict.get() で存在チェックを行う方針を明記しました。

修正 3: JST タイムスタンプの実装方針

datetime.timezone(datetime.timedelta(hours=9)) を使用し、
外部ライブラリ（ pytz 等）を使用しない方針を明記しました。

3-4. タスクリストの自動生成と修正

設計書が確定すると Kiro が Implementation Plan を自動生成しました。
14 の主要タスクに分解され、 Parser → Classifier → Generator の順で
段階的に実装する構成になっていました。

• Task 1: プロジェクト構造とデータモデルの作成
• Task 2: Report_Parser の実装
• Task 3: Checkpoint - Parser の動作確認
• Task 4: Priority_Classifier の実装
• Task 5: Checkpoint - Classifier の動作確認
• Task 6: Output_Generator の実装（基本機能）
• Task 7: Output_Generator の実装（優先度リスト）
• Task 8: Output_Generator の実装（是正対応計画）
• Task 9: Output_Generator の実装（説得プラン）
• Task 10: Output_Generator の統合とフォーマット検証
• Task 11: Checkpoint - Generator の動作確認
• Task 12: メインオーケストレーターとエラーハンドリングの実装
• Task 13: 統合テストと最終検証
• Task 14: Final Checkpoint - 全テストの実行と確認

タスクリストのレビューで以下の修正を加えました。

修正 1: ファイル生成パスの明示

Claude Code が意図しない場所にファイルを生成しないよう、
以下のパス構成を明示しました。

• test_kiro_ide/analyze_report.py: メインスクリプト
• test_kiro_ide/report/: 入力ファイル（既存）
• test_kiro_ide/output/: 出力ファイル（自動生成）
• test_kiro_ide/tests/: テストファイル

修正 2: 統合テストの入力ファイル明示

統合テストは report/ ディレクトリの既存 JSON ファイルを使用し、
新規ダミーファイルは作成しないことを明記しました。

3-5. タスクの実行結果

タスクリストが確定後、 Kiro IDE 単体でタスクを順番に実行しました。
各タスクの実行時間と消費クレジットは以下の通りです。

3-6. 実行結果

全タスク完了後、以下のコマンドで動作確認しました。

cd /mnt/c/Users/test/projects/kiro-claude-project/test_kiro_ide
python3 analyze_report.py

実行結果は以下の通りです。

AWS Organizations Report Analyzer
==================================================
Loading reports from report/ directory...
✓ Loaded 55 check results from 13 accounts
Classifying check results by urgency...
✓ Classified: 19 high, 8 medium, 4 low priority items
Generating output files...
✓ Generated output/01_priority_list.md
✓ Generated output/02_remediation_plan.md
✓ Generated 13 persuasion plans in output/03_persuasion_plan/
==================================================
Analysis completed successfully!

生成されたファイルの構成は以下の通りです。

• output/01_priority_list.md: 緊急度別是正対応リスト
• output/02_remediation_plan.md: 高優先度是正対応全体計画
• output/03_persuasion_plan/（ 13 アカウント分）

テスト結果は以下の通りです。

python3 -m unittest discover -s tests -v 2>&1 | tail -5

テスト実行結果を確認。

Ran 42 tests in 0.195s

OK
✓ Successfully converted 55 check results

4. 生成されたファイル確認

果たしてどんな感じに作成されたのか内容を Backlog に貼り付けて確認してみました。

緊急度別是正対応リスト

緊急度別でサマリーされた内容から高緊急度: 19 件を確認できた。

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

続いて全体計画も確認。Phase 1 では Lambda に関する 13 アカウントの対応計画が確認できた。

Phase 2 では ELB リスナーのセキュリティポリシーに関する 1 アカウントの対応計画が確認できた。またトラッキングテーブルも使えそうだ。

アカウント別是正対応プラン

アカウント ID 111111111111 の担当者の気持ちになってアカウント別是正対応プラン内容を確認。ELB リスナーのセキュリティポリシーに関して内容に問題はなさそうだ。作業時のダウンタイム有無などの情報があると担当者的にはありがたいかもしれない。

Lambda に関しては、移行先ランタイムによって必要な改修の程度が大きく異なるのでそういった観点も考慮されると担当者的にありがたいと感じた。

5. Kiro IDE 単体での気づき

Spec 機能により仕様入力から要件定義・設計・タスク生成まで自動化できました。
一方で以下の気になった点も明確に。

良かった点

• 自然言語の仕様書から要件定義・設計書・タスクリストが自動生成された
• 要件定義・設計書のレビューと修正を対話形式で進められた
• Checkpoint タスクにより段階的な品質確保ができた

気になった点

もう少し kiro を使いこなせば気になった点を改善できるかもしれませんが、次回の③ Kiro IDE + Claude Code 編で、これらのポイントを解消する
Kiro IDE と WSL 上の Claude Code の連携方法を紹介します。

まとめ

本記事では Kiro IDE を Windows 環境に導入し、
AWS Organizations の組織ビューレポートを CCoE 観点で分析するツールを
Spec 機能で開発する検証を行いました。

Spec 機能で実現できたこと

• 自然言語の仕様書から要件定義・設計書・タスクリストを自動生成
• 14 タスクの実装を段階的に実行し、 42 件のテストが全 Pass
• python3 analyze_report.py の単一コマンドで以下を自動生成
  • 緊急度別是正対応リスト（高 19 件・中 8 件・低 4 件）
  • 高優先度是正対応全体計画（ Phase 1〜3 ）
  • アカウント担当者向け説得プラン（ 13 アカウント分）

企業利用における Kiro IDE のポイント

• IAM Identity Center 経由で認証することでアクセスキーの漏洩リスクを排除できる
• Enterprise プランではデータが学習に利用されないため安心して業務利用できる

シリーズ構成

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

参考

• Kiro 公式サイト
• Kiro 公式ドキュメント - Data protection
• 【アップデート】 Kiro 一般提供開始！ Amazon Q Developer CLI は Kiro CLI へ統合されました
• Kiro CLI に入門