みなさん、こんにちは。AWS CLI が好きな AWS サポート課の市野です。
2025年12月1日からラスベガスで開催されている re:Invent 2025 に現地参加し、「Rapid prototyping with Kiro CLI [REPEAT] (ARC308-R)」の ワークショップに参加しました。
Event Catalog での説明
Overview:
Learn to build serverless applications rapidly using the (AI-Driven Development Lifecycle) methodology combined with Kiro-CLI's AI-powered code generation.
In this hands-on workshop, you'll build two real applications from scratch, learning by doing rather than reading theory. Description
Join the AWS Prototyping & Cloud Engineering (PACE) and get hands-on experience in building functional prototypes using our proven techniques. Learn how to leverage Kiro CLI to go beyond "vibe-coding", and transform ideas into fully functional prototypes while validating technical approaches. Discover effective spec-driven development and prompt engineering techniques combining generative AI capabilities with AWS services for rapid iteration and refinement.
(機械翻訳による和訳)
AL-DCL(AI駆動開発ライフサイクル)手法とKiro-CLIのAIを活用したコード生成を組み合わせ、サーバーレスアプリケーションを迅速に構築する方法を学びます。
このハンズオンワークショップでは、2つの実際のアプリケーションをゼロから構築し、理論を読むのではなく、実際に体験しながら学習します。
説明
AWS Prototyping & Cloud Engineering (PACE) に参加して、実績のある手法を用いて機能プロトタイプを構築する実践的な経験を積みましょう。Kiro CLIを活用して「バイブコーディング」の域を超え、アイデアを完全な機能プロトタイプへと変換し、技術的なアプローチを検証する方法を学びます。生成AI機能とAWSサービスを組み合わせた効果的な仕様駆動開発と迅速なエンジニアリング手法を習得し、迅速な反復と改良を実現します。
実施したシナリオの例
貯金管理アプリ「Piggy Bank」を作成する想定のシナリオで、要件定義(Inception)、設計・実装(Construction)、デプロイ(Operations)までを、AI-DLC(AI-Driven Development Lifecycle)の文脈で習熟していくコンテンツでした。
AL-DCL(AI-Driven Development Lifecycle)については、以下の AWS 公式ブログに詳細が書かれていますが、AI が開発プロセスを積極的に調整するような時代背景に合うように設計された、ソフトウェア開発を根本から再考する AI ネイティブの方法論とのことです。
また、弊社の針生さんが解説してくれた社内勉強会の資料が上がっていますので、合わせて紹介します。
シナリオ中にあった考え方
AI-DLC とは?
AI が開発プロセスを積極的に統制する時代のために設計された、原理から再考された AI ネイティブな手法である、と解説されていました。
マインドセットの変換の必要性
AI が質問し、あなたが答える のように逆転した会話と捉えることが肝要とありました。
従来のアプローチの場合、「AI、貯蓄アプリを作って」のようになると思います。
これを AI-DLC によるアプローチで考えた場合、AI が「このアプリを誰が使用しますか? 貯蓄の動機は何ですか? 進捗はどのように視覚化すべきですか?」と尋ねるような逆転です。
この逆転により、考慮していなかった質問を AI が尋ねることにより、良い要件につながるとありました。
AI が提案 → 人間が検証 → AI が実装 というように AI に主導権を渡さず、実装の詳細ではなく、人間はより重要なことに時間を費やすことを実現するための方法論と理解しました。
AI-DLC の3つのフェーズ
フェーズ 1: 要件定義
従来の開発では、要件定義書の作成に要していた時間を、AI-DLC では、適切な質問をする AI プロダクトオーナーと会話し、包括的な要件の生成を目指します。
実際のワークショップではインテントファイル(intent.md)として作成し、以下を確定させていました。
- 構築したいもの - 高レベルの機能説明
- 誰が使用するか - ターゲットユーザーとその目標
- 成功基準 - 「完了」とは何かを示す
ここインテントファイルをプロジェクトオーナーエージェントとして、設定し AI からの 逆転した質問 に答えつつをユーザーストーリー作成します。
ユーザーストーリーの作成完了を人間が承認することで、以下のような要件定義ドキュメントが完成します。、
- プロセスチェックリスト
- Q&Aドキュメント
- ユーザーストーリー
フェーズ2: 構築フェーズ
ワークショップの中ではさらに細分化していましたが、実装部分のみではなく各種設計にあたる工程も含め分類されていました。
ドメイン設計
ユーザーストーリーからビジネス概念を抽出し、エンティティやビジネスルール、関係を持つ構造化されたドメインモデルの作成をめざします。
実際のワークショップではドメインアーキテクトエージェントとして設定した上で、再び逆転した質問に答えながら明確化させていき、人間が承認するプロセスでした。
技術設計
前工程て完成したドメインモデルを AWS サービスを使用した技術アーキテクチャに変換させるプロセスです。
技術アーキテクトエージェントとして設定した AI とともに開発者向けの実装ガイダンスとしての確立をめざします。
コード生成
前項までに確定した設計仕様をもとに構築します。
フルスタックエンジニアエージェントとして設定した AI とともに以下を構成するコードを作成します。
- バックエンドコード
- フロントエンドコード
- データベースセットアップ
- インフラストラクチャ
- テスト
フェーズ3: 運用
生成されたコードが AWS 上で実行可能なアプリケーションとして構築する段階です。
今回のワークショップでは設計に基づいて、以下の構築物が作成されました。
- インフラストラクチャのプロビジョニング: AWS リソース(DynamoDB、Lambda、API Gateway)の作成
- コードデプロイ: Lambda 関数とフロントエンドアセットをAWSにアップロード
- 設定: フロントエンドをバックエンドエンドポイントに接続
- 検証: クラウド環境ですべてが機能することをテスト
- 監視: 可観測性のために CloudWatch を設定
まとめ
今回 2 時間のワークショップでしたが、残念ながらデプロイの完成まで見届けるには時間が足りませんでした。
ただ、方法論としては学んだので、まずは小さなプロジェクトから実践してみようと考えています。
自己紹介として AWS CLI が好きですと名乗ることもあり、シェルスクリプトを作成することが多いです。
個人で完結することが多く自分がわかっていればいいと、ドキュメントが残りにくく、ちょっとした開発物にこそ有益であるのは、以下の AWS 公式ブログでも言及のある通りです。
ですので、今回学んできた方法論を活用してみたいと考えています。
本記事がどなたかのお役に立てば幸いです。
ではまた。