こんにちは。デジタルイノベーション推進室の戦闘員Oです。


今回は、Kiroの最新機能「Analyze Requirements」を使って、AWSインフラの要件定義に潜む矛盾や曖昧さを、CloudFormationの作成前に検出する方法をご紹介します。

なぜこの記事が必要なのか?

SI案件でAWSインフラを構築する際、こんな経験はありませんか?

 

  •  CloudFormationを書き始めてから「あれ、この要件矛盾してない?」と気づく
  • 構築後にお客様から「要件と違う」と指摘される
  • 要件定義書の曖昧な表現を、開発者が独自に解釈してしまう

 

これらの問題は、要件定義の段階で矛盾や曖昧さを検出できれば防げます。

 

Kiro Specsの新機能「Analyze Requirements」は、LLMとSMTソルバー(自動推論エンジン)を組み合わせて、要件全体を分析し、論理的な矛盾を検出してくれます。

アジェンダ

  1. 今回のゴール:設計前の要件品質チェック
  2. Kiro Specsとは?(おさらい)
  3. Analyze Requirementsとは?(新機能紹介)
  4. 仕組み:LLM + SMTソルバー
  5. 実践:AWSインフラ要件で試してみる
  6. 検出された問題と修正
  7. まとめ

1. 今回のゴール:設計前の要件品質チェック

今回は、AWSインフラの要件定義をKiro Specsに入力し、Analyze Requirementsで矛盾を検出してから、CloudFormationを作成する流れを実践します。


達成したいこと:

  • AWSインフラ要件の矛盾を設計前に検出
  • 曖昧な表現を明確化
  • 要件の品質を向上させてからCloudFormationを作成
  • 手戻りを削減

 

完成イメージ:

  1. お客様からAWSインフラ要件を受領
     ↓
  2. Kiro Specsに要件を入力
     ↓
  3. Analyze Requirementsを実行
     ↓ 矛盾・曖昧さを自動検出
  4. 問題を修正(お客様に確認)
     ↓
  5. 修正後の要件でCloudFormationを作成
     ↓
  6. 品質の高いインフラ構築が完成!

 

従来の方法との比較:

工程

従来の方法

Analyze Requirements活用

効果

要件レビュー

人手で確認

(見落としあり)

自動検出

(論理的な矛盾を検出)

検出率向上

矛盾の発見タイミング

構築中・構築後

設計前

手戻り削減

曖昧さの解消

レビュー会議で議論

具体的な質問として提示

時間短縮

手戻りコスト

高(構築やり直し)

低(要件修正のみ)

コスト削減

2. Kiro Specsとは?(おさらい)

Kiro Specsは、機能開発の仕様を管理するKiroの中核機能です。

2-1. Specsの基本的な流れ

Requirements(要件定義)
  ↓ ★ここでAnalyze Requirementsを実行
Design(設計)
  ↓
Tasks(実装タスク)
  ↓
Implementation(実装)

2-2. Specsの特徴

項目

説明

目的

機能開発の仕様管理

ファイル形式

Markdown(.md)

配置場所

`.kiro/specs/`

構成

requirements.md → design.md → tasks.md

同期

コードと仕様が同期

2-3. SI設計書との違い(再確認)

項目

Kiro Specs

SI設計書

対象読者

AIエージェント + 開発者

お客様 + 開発者

目的

実装の指示・管理

合意形成・ドキュメント

フォーマット

Markdown

Excel/Word

更新

コードと同期

手動更新

検証

Analyze Requirements

人手レビュー

重要なポイント:
> Kiro Specsは「AI向けの指示書」ですが、Analyze Requirementsを使うことで、
> SI案件の要件定義書の品質チェックにも活用できます。
 

3. Analyze Requirementsとは?(新機能紹介)

2026年5月にリリースされた新機能です。
(参考: https://kiro.dev/changelog/ide/0-12/

3-1. 概要

Analyze Requirementsは、要件定義の矛盾・曖昧さ・抜け漏れを自動検出する機能です。


特徴:

  • 要件を個別ではなく、全体を横断的に分析
  • 要件の論理的な矛盾を検出(人間のレビューでは見落としがちな問題を検出)
  • 修正案を提示
  • 数分で分析完了

3-2. 検出できる問題

問題の種類

説明

論理的矛盾

個別には正しいが、組み合わせると不可能

24時間稼働 vs メンテナンス時間

曖昧な表現

実装者によって解釈が分かれる

「高速な応答」「大容量」

制約の衝突

機能要件と非機能要件の矛盾

高可用性 vs コスト最小化

暗黙の前提

未定義の概念への参照

「既存のVPC」(どのVPC?)

エッジケースの欠落

異常系・境界条件の未定義

障害時のフェイルオーバー未定義

3-3. 使い方

Specsの要件定義後に、以下の2箇所から実行できます:

  1. チャット画面:「Analyze Requirements」オプションを選択
  2. エディタ:「Continue」ドロップダウンから「Analyze Requirements」を選択

3-4. 仕組み

自然言語の要件
  ↓ LLM(大規模言語モデル)
形式論理に変換
  ↓ SMTソルバー(自動推論エンジン)
要件の論理的な矛盾を検出
  ↓
問題を検出・修正案を提示

4. 仕組み:LLM + SMTソルバー

Analyze Requirementsの技術的な仕組みを理解しましょう。

4-1. ニューロシンボリックAI

この機能は「ニューロシンボリックAI」と呼ばれる手法を使っています。

要素

役割

得意なこと

LLM(ニューロ)

自然言語を形式論理に変換

言語理解、文脈把握

SMTソルバー(シンボリック)

論理的な矛盾を検出

厳密な推論、矛盾検出

4-2. 処理の流れ

ステップ1:LLMが要件を形式論理に変換
   自然言語:「RDSはマルチAZ構成で高可用性を確保する」
     ↓
   形式論理:RDS.MultiAZ = true ∧ RDS.AvailabilityZones ≥ 2

 

ステップ2:SMTソルバーが矛盾を検出

   要件A:RDS.MultiAZ = true(高可用性)

   要件B:RDS.MultiAZ = false(コスト削減のためシングルAZ)
     ↓
   SMTソルバー:「要件Aと要件Bは同時に満たせない」(論理的矛盾を検出)

 

ステップ3:修正案を提示
   検出された矛盾:
    - 要件A「マルチAZ構成で高可用性を確保」
    - 要件B「コスト削減のためシングルAZ構成」

 

   修正案:
    1. 本番環境はマルチAZ、開発環境はシングルAZとする
    2. コスト削減の要件を緩和し、マルチAZを優先する
    3. 高可用性の要件を緩和し、シングルAZとする

4-3. なぜ人間のレビューでは見落とすのか?

人間のレビューの限界:

  • 要件が多い場合(50件以上)、全組み合わせの確認は困難
  • 異なるセクションに書かれた矛盾は見落としやすい
  • 暗黙の前提に気づきにくい
  • レビュアーの経験に依存


Analyze Requirementsの強み:

  •  要件の組み合わせを網羅的にチェック
  • 要件の論理的な矛盾を検出(見落としなし)
  • 暗黙の前提を明示化
  • 経験に依存しない一貫した品質

5. 実践:AWSインフラ要件で試してみる

それでは、実際にAWSインフラの要件をKiro Specsに入力し、Analyze Requirementsを実行してみましょう。

5-1. シナリオ設定

お客様から以下のようなAWSインフラ要件を受領したとします。

 

プロジェクト概要:

  • 社内業務システムのAWS移行
  • Webアプリケーション + データベース
  • 本番環境と開発環境を構築
     

5-2. 受領した要件(意図的に矛盾を含む)

お客様から受領した要件定義書(抜粋):

[markdown]
# AWSインフラ要件定義書

 

## 1. ネットワーク要件
- VPCを作成し、CIDRは10.0.0.0/16とする
- パブリックサブネットとプライベートサブネットを各2つ作成する
- インターネットからのアクセスはALB経由のみとする
- すべてのリソースはプライベートサブネットに配置する

 

## 2. サーバ要件
- EC2インスタンスはt3.mediumを使用する
- Auto Scalingで最小2台、最大10台とする
- EC2インスタンスにはパブリックIPを付与する
- SSHアクセスは社内ネットワーク(10.0.0.0/8)からのみ許可する

 

## 3. データベース要件
- RDS PostgreSQLを使用する
- マルチAZ構成で高可用性を確保する
- コスト削減のため、シングルAZ構成とする
- 暗号化を有効にする
- バックアップは7日間保持する

 

## 4. ストレージ要件
- S3バケットを作成する
- パブリックアクセスを許可し、静的コンテンツを配信する
- すべてのデータは暗号化し、外部からのアクセスを禁止する
- バージョニングを有効にする

 

## 5. セキュリティ要件
- すべてのリソースにタグを付与する
- セキュリティグループは最小権限の原則に従う
- 開発環境では迅速なデバッグのため、すべてのポートを開放する
- WAFを導入し、不正アクセスを防止する

 

## 6. 可用性要件
- 本番環境のSLAは99.99%とする
- メンテナンスウィンドウは毎週日曜日AM2:00〜AM6:00とする
- システムは24時間365日無停止で稼働する
- 障害時は5分以内に自動復旧する

 

## 7. コスト要件
- 月額コストは50万円以内に抑える
- リザーブドインスタンスは使用しない(柔軟性を確保)
- すべてのリソースは冗長化する

5-3. Kiro Specsに入力

Kiroで新しいSpecを作成し、上記の要件を入力します。


手順:

  1. コマンドパレット(Ctrl+Shift+P)を開く
  2.  "Kiro: New Spec" を選択
  3. 「AWSインフラ構築」と入力
  4. 要件を入力

5-4. Analyze Requirementsを実行

要件入力後、「Analyze Requirements」を実行します。


手順:
5.    要件が生成されたら、チャット画面で「Analyze Requirements」を選択

6.    分析が開始される(数分かかります)
7.    結果がチャットに表示される

6. 検出された問題と修正提案

Analyze Requirementsが検出した問題を確認し、修正していきましょう。

6-1. 検出結果一覧

#

問題の種類

関連する要件

内容

1

論理的矛盾

2-3, 2-4

EC2にパブリックIP付与 vs プライベートサブネット配置

2

論理的矛盾

3-2, 3-3

マルチAZ vs シングルAZ

3

論理的矛盾

4-2, 4-3

S3パブリックアクセス許可 vs 外部アクセス禁止

4

制約の衝突

5-3, 5-2

全ポート開放 vs 最小権限の原則

5

論理的矛盾

6-1, 6-2, 6-3

SLA 99.99% vs メンテナンスウィンドウ vs 24時間無停止

6

制約の衝突

7-1, 7-3

月額50万円以内 vs すべて冗長化

7

曖昧な表現

1-4

「すべてのリソース」の範囲が不明確

7. まとめ

今回は、Kiro Specsの新機能「Analyze Requirements」を使って、AWSインフラ要件の矛盾を設計前に検出する方法を解説しました。
Kiroを活用して、より高品質な要件定義を実現しましょう!