😎

Kiro実践レポート - インフラエンジニアが感じた『vibe coding』から『viable code』への転換点

に公開
AWS
生成 AI
開発効率化
Kiro
idea

Kiroとは

様々なブログで紹介されていますが、Amazon発のIDE「Kiro」がリリースされました。
Kiroのコンセプトは Vibe coding（なんとなくコーディング）ではなく、Viable Code（実用的なコード）です。

https://kiro.dev/

「spec-driven development（仕様駆動開発）」というアプローチが採用されており、単なるコード生成ツールではなく要件定義から設計、実装、テストまでの全工程を構造化してくれます。
これにより、「仕様書が生きている」状態が実現され、コードと設計意図の乖離を防ぐことができます。

インフラ開発におけるKiroの活用

では、インフラ開発においてKiroを有効活用できるのか？を試してみます。
今回は、実際にWeb3層のインフラをKiroのSpecモードを使用して設計します。

1. 要件定義フェーズ

まずは要件定義です。要件は以下としました。

要件定義:

Webサイトのバックエンドシステムを構築したい。
- 商品管理、ユーザー管理、注文処理機能が必要
- 将来的にはモバイルアプリからもアクセス予定
- できるだけコストを抑えたい
- 規模・性能:
  - 初期ユーザー数: 1,000名
  - 月間アクティブユーザー: 10,000名（1年後目標）
  - ピーク時同時接続: 50接続
  - 商品数: 初期1,000点、1年後10,000点
  - 1日あたり注文数: 初期50件、1年後500件
  - API応答時間: 95%が500ms以内
  - 可用性: 99.9%以上
- セキュリティは重要
- 予算:
  - 月額運用費用: $500以下（初期）
  - 成長時の予算上限: $2,000/月
- 技術制約:
  - 開発チーム: Node.js経験あり
  - 運用チーム: AWS基本サービス経験あり
  - 既存システム: なし（新規構築）

要件定義書の作成:
上記要件に基づき、要件定義書を作成しました。
最初にKiroが生成した要件定義書は内容が機能要件に偏っていたため、非機能についても整理を依頼。
最終的に以下の内容で整理しましたが、一度でこの内容を生成することは難しく、人によるレビューを通じて内容の網羅性や妥当性のチェックが必須だと感じました。

**機能要件（FR-1～4）**:
- ユーザー管理システム
- 商品管理システム
- 注文処理システム
- API設計

**非機能要件（NFR-1〜6）**:
- 性能・拡張性: 応答時間、同時接続数、スケーラビリティ
- 可用性: システム稼働率、障害対応、バックアップ
- セキュリティ: 認証・認可、暗号化、監査証跡
- 運用・保守性: ログ、モニタリング、CI/CD、ドキュメント
- 移植性: 技術スタック活用、コンテナ化、環境依存最小化
- 効率性（コスト）: 予算制約、リソース最適化、監視コスト

2. 設計フェーズ

次は設計フェーズです。

設計方針の明確化:
Kiroは要件定義書に基づいて設計書を作成しましたが、最初の生成では設計方針と設計根拠が不明瞭だったため改善を依頼。設計方針と設計根拠を明確化するとともに、要件定義との整合性が確認できるよう設計書にまとめてもらいました。このあたりも、しっかりと内容のチェックが必要です。

設計方針:
コスト効率性優先 - 初期投資最小化、段階的スケール
既存技術スタック活用 - Node.js、AWS経験の活用
段階的スケーラビリティ - 需要に応じた拡張
セキュリティファースト - 多層防御の実装
運用自動化 - 手動運用の最小化
設計根拠:

設計根拠：
アーキテクチャ選択: マイクロサービス、Fargate、PostgreSQL、Redisの選択理由
技術選択: Node.js + TypeScript、Express.js、JWT認証の選択理由
セキュリティ設計: 多層防御、最小権限、監査証跡の実装理由
パフォーマンス設計: キャッシュ戦略、DB最適化、Auto Scalingの実装理由
コスト設計: 段階的投資、使用量ベース課金、Reserved Instancesの活用理由

設計書の作成:
最終的な設計書の目次は以下の通りです。
設計の妥当性が段階的に理解できる構成になっており、設計書として必要な内容を網羅できていることはもちろん、人が見て理解しやすい構成になっています。

設計書の目次と構成を整理しました。以下の9つの主要セクションに再構成しています：

概要 - システムの全体像
設計方針と根拠 - 設計の考え方と選択理由
要件定義との整合性 - 要件との対応関係
システムアーキテクチャ - 全体構成と技術スタック
詳細設計 - コンポーネント、データモデル、API設計
品質設計 - セキュリティ、パフォーマンス、可用性
運用設計 - 監視、CI/CD、災害対策
コスト設計 - 見積もりと最適化戦略
テスト戦略 - テスト方針と実装

3. 実装計画の生成

続いての実装計画では、要件定義書と設計書に基づいた段階的な計画が作成されました。

実装計画を作成しました。12の主要フェーズに分けて、段階的にeコマースバックエンドシステムを構築します：

フェーズ1-2: プロジェクト基盤とデータモデル
TypeScript + Express.js基盤
PostgreSQL接続とデータモデル

フェーズ3-4: 認証・ユーザー管理
JWT認証システム
ユーザー登録・プロフィール管理

フェーズ5-6: 商品管理・注文処理
商品CRUD・検索・在庫管理
カート・注文処理・トランザクション制御

フェーズ7-8: API統合・パフォーマンス最適化
RESTful API統一・エラーハンドリング
Redis キャッシュ・DB最適化

フェーズ9-10: 監視・テスト自動化
構造化ログ・ヘルスチェック
単体・統合・E2Eテスト

フェーズ11-12: 本番環境・運用準備
Docker化・ECS設定
インフラ構築・CI/CD・監視設定

まとめ

作成されたドキュメント

  • 要件定義書 - 機能、非機能を踏まえた要件の定義
  • 設計書 - 設計方針・根拠と要件との整合性を含む包括的な設計
  • 実装タスク - 12フェーズ、37タスクの段階的実装計画

インフラ開発におけるKiroの活用

インフラ開発において、Kiroは「なんとなく動くインフラ」から「意図が明確で保守しやすいインフラ」への転換を技術的にサポートしてくれる強力なツールになり得ると感じました。
ポイントは以下の2点です。

「なぜこの設計なのか」を明確化：
特に印象的だったのは、Kiroが設計判断の根拠を明確に示してくれることです。
一度の生成でこれらを網羅する設計書を作るのは難しいと感じましたが、Kiroとの対話を通じて設計の妥当性が確認できました。

「viable code」への道筋：
Kiroのspec-driven development（仕様駆動開発）を通じて実感したのは、設計思考そのものを構造化し、品質を担保する新しいアプローチです。
従来の生成AIツールから、開発プロセス全体を構造化し、設計意図を明確にし、品質を担保するという考え方への転換をKiroが技術的にサポートしてくれます。

是非、実際に触って実感してみてください。

Discussion