こんにちは。デジタルイノベーション推進室の戦闘員Oです。
今回は、Kiroの最新機能「Analyze Requirements」を使って、AWSインフラの要件定義に潜む矛盾や曖昧さを、CloudFormationの作成前に検出する方法をご紹介します。
なぜこの記事が必要なのか?
SI案件でAWSインフラを構築する際、こんな経験はありませんか?
- CloudFormationを書き始めてから「あれ、この要件矛盾してない?」と気づく
- 構築後にお客様から「要件と違う」と指摘される
- 要件定義書の曖昧な表現を、開発者が独自に解釈してしまう
これらの問題は、要件定義の段階で矛盾や曖昧さを検出できれば防げます。
Kiro Specsの新機能「Analyze Requirements」は、LLMとSMTソルバー(自動推論エンジン)を組み合わせて、要件全体を分析し、論理的な矛盾を検出してくれます。
アジェンダ
- 今回のゴール:設計前の要件品質チェック
- Kiro Specsとは?(おさらい)
- Analyze Requirementsとは?(新機能紹介)
- 仕組み:LLM + SMTソルバー
- 実践:AWSインフラ要件で試してみる
- 検出された問題と修正
- まとめ
1. 今回のゴール:設計前の要件品質チェック
今回は、AWSインフラの要件定義をKiro Specsに入力し、Analyze Requirementsで矛盾を検出してから、CloudFormationを作成する流れを実践します。
達成したいこと:
- AWSインフラ要件の矛盾を設計前に検出
- 曖昧な表現を明確化
- 要件の品質を向上させてからCloudFormationを作成
- 手戻りを削減
完成イメージ:
- お客様からAWSインフラ要件を受領
↓ - Kiro Specsに要件を入力
↓ - Analyze Requirementsを実行
↓ 矛盾・曖昧さを自動検出 - 問題を修正(お客様に確認)
↓ - 修正後の要件でCloudFormationを作成
↓ - 品質の高いインフラ構築が完成!
従来の方法との比較:
|
工程 |
従来の方法 |
Analyze Requirements活用 |
効果 |
|
要件レビュー |
人手で確認 (見落としあり) |
自動検出 (論理的な矛盾を検出) |
検出率向上 |
|
矛盾の発見タイミング |
構築中・構築後 |
設計前 |
手戻り削減 |
|
曖昧さの解消 |
レビュー会議で議論 |
具体的な質問として提示 |
時間短縮 |
|
手戻りコスト |
高(構築やり直し) |
低(要件修正のみ) |
コスト削減 |
2. Kiro Specsとは?(おさらい)
Kiro Specsは、機能開発の仕様を管理するKiroの中核機能です。
Requirements(要件定義)
↓ ★ここでAnalyze Requirementsを実行
Design(設計)
↓
Tasks(実装タスク)
↓
Implementation(実装)
|
項目 |
説明 |
|
目的 |
機能開発の仕様管理 |
|
ファイル形式 |
Markdown(.md) |
|
配置場所 |
`.kiro/specs/` |
|
構成 |
requirements.md → design.md → tasks.md |
|
同期 |
コードと仕様が同期 |
|
項目 |
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/ )
Analyze Requirementsは、要件定義の矛盾・曖昧さ・抜け漏れを自動検出する機能です。
特徴:
- 要件を個別ではなく、全体を横断的に分析
- 要件の論理的な矛盾を検出(人間のレビューでは見落としがちな問題を検出)
- 修正案を提示
- 数分で分析完了
|
問題の種類 |
説明 |
例 |
|
論理的矛盾 |
個別には正しいが、組み合わせると不可能 |
24時間稼働 vs メンテナンス時間 |
|
曖昧な表現 |
実装者によって解釈が分かれる |
「高速な応答」「大容量」 |
|
制約の衝突 |
機能要件と非機能要件の矛盾 |
高可用性 vs コスト最小化 |
|
暗黙の前提 |
未定義の概念への参照 |
「既存のVPC」(どのVPC?) |
|
エッジケースの欠落 |
異常系・境界条件の未定義 |
障害時のフェイルオーバー未定義 |
Specsの要件定義後に、以下の2箇所から実行できます:
- チャット画面:「Analyze Requirements」オプションを選択
- エディタ:「Continue」ドロップダウンから「Analyze Requirements」を選択
自然言語の要件
↓ LLM(大規模言語モデル)
形式論理に変換
↓ SMTソルバー(自動推論エンジン)
要件の論理的な矛盾を検出
↓
問題を検出・修正案を提示
4. 仕組み:LLM + SMTソルバー
Analyze Requirementsの技術的な仕組みを理解しましょう。
この機能は「ニューロシンボリックAI」と呼ばれる手法を使っています。
|
要素 |
役割 |
得意なこと |
|
LLM(ニューロ) |
自然言語を形式論理に変換 |
言語理解、文脈把握 |
|
SMTソルバー(シンボリック) |
論理的な矛盾を検出 |
厳密な推論、矛盾検出 |
ステップ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とする
人間のレビューの限界:
- 要件が多い場合(50件以上)、全組み合わせの確認は困難
- 異なるセクションに書かれた矛盾は見落としやすい
- 暗黙の前提に気づきにくい
- レビュアーの経験に依存
Analyze Requirementsの強み:
- 全要件の組み合わせを網羅的にチェック
- 要件の論理的な矛盾を検出(見落としなし)
- 暗黙の前提を明示化
- 経験に依存しない一貫した品質
5. 実践:AWSインフラ要件で試してみる
それでは、実際にAWSインフラの要件をKiro Specsに入力し、Analyze Requirementsを実行してみましょう。
お客様から以下のようなAWSインフラ要件を受領したとします。
プロジェクト概要:
- 社内業務システムのAWS移行
- Webアプリケーション + データベース
- 本番環境と開発環境を構築
お客様から受領した要件定義書(抜粋):
[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万円以内に抑える
- リザーブドインスタンスは使用しない(柔軟性を確保)
- すべてのリソースは冗長化する
Kiroで新しいSpecを作成し、上記の要件を入力します。
手順:
- コマンドパレット(Ctrl+Shift+P)を開く
- "Kiro: New Spec" を選択
- 「AWSインフラ構築」と入力
- 要件を入力
要件入力後、「Analyze Requirements」を実行します。
手順:
5. 要件が生成されたら、チャット画面で「Analyze Requirements」を選択
6. 分析が開始される(数分かかります)
7. 結果がチャットに表示される
6. 検出された問題と修正提案
Analyze Requirementsが検出した問題を確認し、修正していきましょう。
|
# |
問題の種類 |
関連する要件 |
内容 |
|
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を活用して、より高品質な要件定義を実現しましょう!


