こんにちは！
この記事は、Japan AWS Jr.Champions Advent Calender 2025 シリーズ1・23日目の記事となります。
0. はじめに
本日は、AWSが提唱する新しい開発サイクルの概念「AI-DLC（AI-Driven Development Life Cycle）」をテーマにしたワークショップのレポートをお届けします。
このワークショップは非常にボリュームもあり、多くのフェーズが含まれています。今回はその第一歩として、**「Inception」フェーズにおける「要件分析」**にフォーカスして紹介します。
- 個人の見解: 本記事の内容は筆者個人の意見であり、所属する組織の見解を代表するものではありません
- AIの活用: 本記事は、生成AIおよびGoogle Chromeの翻訳機能を活用して執筆しています。AI翻訳特有の表現が含まれる場合がありますが、あらかじめご了承ください
この記事のターゲット
- 「AI-DLC」という言葉を耳にして、その実態を知りたい方
- AWSのAI-DLCワークショップで具体的に何をやるのか、そのプロセスに興味がある方
本記事で話すこと
- AI-DLCの概要（ざっくりと）
- ワークショップの具体的な構成
- **Inception（要件分析）**におけるAmazon Q Developerとの対話体験
本記事で話さないこと
- AI-DLCの詳細な技術仕様や各AWSサービスの深い設定方法
1. ワークショップについて紹介
ワークショップの概要
このワークショップの目的は、AI駆動開発ライフサイクル（AI-DLC）への理解を深めることです。Amazon Q DeveloperなどのAIツールを活用し、ソフトウェア開発ライフサイクル（SDLC）の全フェーズをどのように変革できるかをハンズオン形式で体験できます。
体験方法（※公式サイトから引用。今回は2のセルフサービスモードで体験）
- プロビジョニングされたアカウントを使用するAWSイベントとして。ワークショップでは、AWS Builder IDを使用してAmazon Q Developerで使用できるVisual Studio IDEを作成します
- セルフサービスモードで、AWS Builder ID またはお持ちの Pro ライセンスを使用して、KIRO/Amazon Q Developer を使用したワークショップの手順をウォークスルーします
概要（※公式サイトから引用）
- レベル: 300
- 所要時間：5～8時間
- 対象者: ソフトウェア開発者、アプリケーション アーキテクト、製品オーナー
- 必要なスキル: このワークショップではソフトウェア開発ライフサイクルのすべてのフェーズを網羅するため、受講者は少なくとも要件分析、ソフトウェア アーキテクチャ、設計、コーディング、およびさまざまな技術スタックを使用したテストに関する基本的な知識を持っている必要があります
- 前提条件: 参加者は、Web ブラウザー経由で Code Server でホストされている Visual Studio Code IDE にアクセスするため、デバイスからインターネットに接続できる必要があります
- 学習目標/成果: このワークショップでは、参加者は、SDLC における AI の現状、メンタルモデル、原則、フェーズ、環境設定手順、AI 支援開発をグリーンフィールドとブラウンフィールドの両方のソフトウェア プロジェクトに統合するための実用的な実装手法など、AI-DLC の基礎を学習します
- 推奨リージョン: 最新の Amazon Q Chat/CLI 機能は us-east-1 で利用できるため、このワークショップは us-east-1 リージョンで実行することをお勧めします
ワークショップの章立て
| モジュール | トピック | レベル | 所要時間 |
|---|---|---|---|
| モジュール1 | SDLCにおけるAIの現状 | 300 | 5分 |
| モジュール2 | AI-DLCメンタルモデル | 300 | 7分 |
| モジュール3 | AI-DLCの原則 | 300 | 10分 |
| モジュール4 | AI-DLCフェーズ | 300 | 10分 |
| モジュール5 | ワークショップポータルにログイン | 100 | 10分 |
| モジュール6 | ラボのセットアップ | 200 | 10分 |
| モジュール7 | Amazon Q認証 | 100 | 10分 |
| モジュール8 | AI-DLCワークフローのセットアップ | 100 | 10分 |
| モジュール9 | AI-DLCを使用してアイデアポータルを作成する | 300 | 4~6時間 |
| モジュール10 | クリーンアップ | 100 | 5分 |
| モジュール11 | まとめ | 100 | 15分 |
2. AI-DLCについて紹介
詳細はホワイトペーパーに詳しく記載されていますが、ここでは要点を絞って紹介します。
AI-DLCとは、AIがSDLCにおける計画、タスク分解、アーキテクチャ設計を主導し、プロセス全体を制御する考え方です。大きく以下の3つのフェーズで構成されています。
- Inception（何を構築するか、なぜ構築するかを決定する）
- 要件分析と検証
- ユーザーストーリーの作成（該当する場合）
- アプリケーション設計と並行開発のための作業単位の作成
- リスク評価と複雑性評価
- Construction（どのように構築するかを決定します）
- 詳細なコンポーネント設計
- コード生成と実装
- ビルド構成とテスト戦略
- 品質保証と検証
- Operations（展開と監視）
- 導入の自動化とインフラストラクチャ
- 監視と観測可能性の設定
- 生産準備の検証
今回のレポートでは、この中のInceptionの要件分析を深掘りします。
3. ワークショップで行ったこと：Inception 要件分析
モジュール9では、Ideation Portalというシステムの構築に挑戦します。
Ideation Portalの概要
構築するシステムは、従業員が革新的なアイデアを提出し、透明性のある評価・採点・表彰を行うためのプラットフォームです。
- ユーザーフレンドリーな提出インターフェース
- 堅牢な評価フレームワーク（実現可能性、影響度、革新性の3軸）
- リアルタイムダッシュボードとリーダーボード
ワークショップの実践フロー
このワークショップでは、公式ワークフローを利用します。プロンプトは提供されていますが、AIと対話しながら進める「AI駆動」の実感が得られる作りになっています。
ステップ1：インテントステートメントの入力
まずは、上記で説明した「どんなものを作りたいか」という英文のステートメント（インテント）を入力します。
Ideation Portal: A digital platform that enables employees to submit innovative ideas for transparent evaluation, scoring, and recognition to foster a culture of innovation within the organization.
1. A user-friendly submission interface with structured idea input fields and draft saving functionality.
2. A robust evaluation framework with quantifiable metrics (feasibility, impact, innovation) enabling independent assessment by authorized panel members.
3. Secure, role-based access allowing panel members to independently review and score submitted ideas across multiple evaluation dimensions.
4. Real-time dashboards and leaderboards displaying aggregated panel scores for all ideas with multi-dimensional comparative views.
5. Analytics capabilities highlighting top-performing ideas and providing detailed comparative analysis across evaluation criteria.
6. A recognition system to formally acknowledge and reward the three highest-scoring innovative ideas.
ステップ2：Amazon Qとの対話とブラッシュアップ
インテントを入力すると、AI（Amazon Q）がルールファイルを基にフォルダやファイルを自動生成します。特筆すべきはここからです。AIが内容の曖昧な点を見つけ出し、requirement-verification-questions.mdというファイルを作成して、こちらに「逆質問」を投げてきます。
Amazon Qから逆質問として、questionが与えられ、開発者（私）がAnswerを回答していくことで、Amazon Qと開発を進めやすくしつつ、ドキュメント整備やアイデアのブラッシュアップが可能になります。下図はVSCode上の例になります。
また、実際に出力された質問と私が行った回答は下記になります。
# Requirements Verification Questions
以下の質問にお答えいただき、要件を明確化させてください。各質問の [Answer]: タグの後に、選択肢の文字（A、B、C等）を記入してください。提供された選択肢が合わない場合は、最後の選択肢（Other）を選び、[Answer]: タグの後に詳細を記述してください。
## Question 1
このシステムのユーザー認証方式はどのようなものを想定していますか？
A) 既存の社内認証システム（SSO、Active Directory等）と連携
B) システム独自のユーザー名・パスワード認証
C) 多要素認証（MFA）を含む独自認証
D) Other (please describe after [Answer]: tag below)
[Answer]:
B
## Question 2
アイデア提出者と評価パネルメンバーの他に、どのようなユーザーロールが必要ですか？
A) 提出者と評価者のみ（2ロール）
B) 提出者、評価者、管理者（3ロール）
C) 提出者、評価者、管理者、閲覧者（4ロール）
D) Other (please describe after [Answer]: tag below)
[Answer]:
B
## Question 3
アイデアの評価基準（feasibility、impact、innovation）について、各基準のスコアリング方式はどのようなものですか？
A) 1-5点のスケール（各基準）
B) 1-10点のスケール（各基準）
C) パーセンテージ（0-100%）
D) Other (please describe after [Answer]: tag below)
[Answer]:
B
## Question 4
評価パネルメンバーは何名を想定していますか？
A) 3-5名
B) 6-10名
C) 11名以上
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 5
アイデアの提出から評価完了までのワークフローはどのようなものですか？
A) 提出 → 全パネルメンバーが評価 → 自動集計 → 結果表示
B) 提出 → 管理者承認 → パネル評価 → 管理者最終承認 → 結果表示
C) 提出 → パネル評価 → 管理者レビュー → 結果表示
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 6
アイデアの下書き保存機能について、どのような動作を想定していますか？
A) 自動保存（一定時間ごと）
B) 手動保存ボタンのみ
C) 自動保存と手動保存の両方
D) Other (please describe after [Answer]: tag below)
[Answer]:
B
## Question 7
リアルタイムダッシュボードの「リアルタイム」とは、どの程度の更新頻度を想定していますか？
A) 即座（評価が入力されたら即座に反映）
B) 数分ごとの更新
C) 手動リフレッシュ
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 8
トップ3のアイデアに対する表彰システムは、どのような形式を想定していますか？
A) システム内でのバッジ・証明書の表示のみ
B) システム内表示 + メール通知
C) システム内表示 + 管理者への通知（実際の表彰は別途）
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 9
このシステムのデプロイ環境はどこを想定していますか？
A) AWS クラウド
B) オンプレミス
C) 他のクラウドプロバイダー（Azure、GCP等）
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 10
想定されるユーザー数（従業員数）の規模はどのくらいですか？
A) 小規模（100名未満）
B) 中規模（100-1000名）
C) 大規模（1000名以上）
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 11
アイデアの提出フォームには、どのような入力フィールドが必要ですか？
A) タイトル、説明、カテゴリーのみ
B) タイトル、説明、カテゴリー、期待される効果、必要なリソース
C) タイトル、説明、カテゴリー、期待される効果、必要なリソース、添付ファイル
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 12
評価パネルメンバーは、他のメンバーの評価スコアを見ることができますか？
A) 評価中は見えない（独立評価）、評価完了後に全員の評価が見える
B) 常に他のメンバーの評価が見える
C) 管理者のみが全員の評価を見ることができる
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 13
アイデアの分析機能について、どのような比較分析が必要ですか？
A) 評価基準別のランキング（feasibility順、impact順、innovation順）
B) カテゴリー別の比較
C) 時系列での傾向分析
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 14
システムのユーザーインターフェースは、どのようなタイプを想定していますか？
A) Webアプリケーション（デスクトップブラウザ）
B) レスポンシブWebアプリケーション（デスクトップ + モバイル）
C) ネイティブモバイルアプリ
D) Other (please describe after [Answer]: tag below)
[Answer]:
A
## Question 15
データの保存期間やアーカイブポリシーについて、要件はありますか？
A) 全てのアイデアを永続的に保存
B) 一定期間後にアーカイブ（読み取り専用）
C) 特に要件なし（後で決定）
D) Other (please describe after [Answer]: tag below)
[Answer]:
B
このように、Amazon Qから提示された質問（認証方式は？ユーザーロールの種類は？スコアリングの尺度は？）に対し、回答を埋めていくことで要件が具体化されます。
ステップ3：要件定義書（requirements.md）の完成
対話（Answer）が終わると、Amazon Qは最終的なrequirements.mdを出力します。 生成されたドキュメントには、以下のような項目が網羅されていました。
- Functional Requirements（機能要件）: FR1〜FR8
- Non-Functional Requirements（非機能要件）: パフォーマンス、セキュリティ、スケーラビリティ等
- Data Model: User, Idea, Evaluation等のデータ構造定義
出力されたrequirements.mdは下記になります。
# Ideation Portal - Requirements Document
## Intent Analysis Summary
### User Request
デジタルプラットフォーム「Ideation Portal」の構築：従業員が革新的なアイデアを提出し、透明性のある評価、スコアリング、表彰を通じて組織内のイノベーション文化を促進するシステム。
### Request Type
**新規プロジェクト（New Project）** - グリーンフィールド開発
### Scope Estimate
**システム全体（System-wide）** - 完全な新規Webアプリケーション
### Complexity Estimate
**中程度（Moderate）** - 複数のユーザーロール、評価ワークフロー、リアルタイムダッシュボード、分析機能を含む
---
## Functional Requirements
### FR1: User Management and Authentication
- **FR1.1**: システム独自のユーザー名・パスワード認証機能
- **FR1.2**: 3つのユーザーロール：提出者（Submitter）、評価者（Evaluator）、管理者（Administrator）
- **FR1.3**: ロールベースのアクセス制御（RBAC）
### FR2: Idea Submission Interface
- **FR2.1**: ユーザーフレンドリーなアイデア提出フォーム
- タイトル（必須）
- 説明（必須）
- カテゴリー（必須）
- **FR2.2**: 下書き保存機能（手動保存ボタン）
- **FR2.3**: 提出されたアイデアの編集・削除機能（提出者のみ、評価開始前）
### FR3: Evaluation Framework
- **FR3.1**: 3つの評価基準
- Feasibility（実現可能性）
- Impact（影響度）
- Innovation（革新性）
- **FR3.2**: 各基準のスコアリング：1-10点のスケール
- **FR3.3**: 評価パネル：3-5名のメンバー
- **FR3.4**: 独立評価システム：評価中は他のメンバーのスコアが見えない
- **FR3.5**: 評価完了後に全員の評価が表示される
### FR4: Evaluation Workflow
- **FR4.1**: ワークフロー
1. アイデア提出
2. 全パネルメンバーが独立して評価
3. 自動集計（全員の評価完了後）
4. 結果表示
- **FR4.2**: 評価ステータス管理（未評価、評価中、評価完了）
### FR5: Real-time Dashboards and Leaderboards
- **FR5.1**: リアルタイム更新（評価入力後即座に反映）
- **FR5.2**: 集計スコア表示（全パネルメンバーの平均スコア）
- **FR5.3**: リーダーボード：総合スコア順のランキング
- **FR5.4**: 多次元ビュー
- 総合スコア順
- Feasibility順
- Impact順
- Innovation順
### FR6: Analytics Capabilities
- **FR6.1**: 評価基準別ランキング
- Feasibility順のランキング
- Impact順のランキング
- Innovation順のランキング
- **FR6.2**: トップパフォーマンスアイデアのハイライト表示
- **FR6.3**: 詳細な比較分析レポート
- **FR6.4**: 評価基準別の統計情報（平均、最高、最低スコア）
### FR7: Recognition System
- **FR7.1**: トップ3アイデアの自動識別（総合スコア基準）
- **FR7.2**: システム内でのバッジ・証明書の表示
- **FR7.3**: 表彰履歴の記録と表示
### FR8: Administrative Functions
- **FR8.1**: ユーザー管理（作成、編集、削除、ロール割り当て）
- **FR8.2**: カテゴリー管理
- **FR8.3**: 評価パネルメンバーの割り当て
- **FR8.4**: システム設定管理
---
## Non-Functional Requirements
### NFR1: Performance
- **NFR1.1**: ページロード時間：3秒以内
- **NFR1.2**: リアルタイム更新：評価入力後1秒以内に反映
- **NFR1.3**: 同時ユーザー数：100名未満をサポート
### NFR2: Security
- **NFR2.1**: パスワードの暗号化保存（bcrypt等）
- **NFR2.2**: セッション管理とタイムアウト
- **NFR2.3**: ロールベースのアクセス制御
- **NFR2.4**: SQLインジェクション、XSS等の脆弱性対策
- **NFR2.5**: HTTPS通信の強制
### NFR3: Scalability
- **NFR3.1**: 小規模組織（100名未満）向けの設計
- **NFR3.2**: 将来的な拡張性を考慮したアーキテクチャ
### NFR4: Usability
- **NFR4.1**: 直感的なユーザーインターフェース
- **NFR4.2**: レスポンシブデザイン不要（デスクトップブラウザのみ）
- **NFR4.3**: アクセシビリティ基準への準拠（WCAG 2.1 AA推奨）
### NFR5: Reliability
- **NFR5.1**: システム稼働率：99%以上
- **NFR5.2**: データバックアップ：日次
- **NFR5.3**: エラーハンドリングとユーザーフレンドリーなエラーメッセージ
### NFR6: Maintainability
- **NFR6.1**: クリーンなコード構造
- **NFR6.2**: 包括的なドキュメント
- **NFR6.3**: ユニットテストとインテグレーションテスト
### NFR7: Data Management
- **NFR7.1**: 全てのアイデアを永続的に保存
- **NFR7.2**: 一定期間後にアーカイブ（読み取り専用）
- **NFR7.3**: データ整合性の保証
### NFR8: Deployment
- **NFR8.1**: デプロイ環境：AWS クラウド
- **NFR8.2**: インフラストラクチャ as Code（推奨）
- **NFR8.3**: CI/CDパイプライン（推奨）
---
## User Roles and Permissions
### Submitter（提出者）
- アイデアの提出
- 自分のアイデアの編集・削除（評価開始前）
- 下書きの保存
- 全てのアイデアとスコアの閲覧
- リーダーボードとダッシュボードの閲覧
### Evaluator（評価者）
- 提出されたアイデアの評価
- 自分の評価の編集（評価期間中）
- 全てのアイデアとスコアの閲覧
- リーダーボードとダッシュボードの閲覧
- 評価完了後の全評価者スコアの閲覧
### Administrator（管理者）
- 全ての提出者・評価者権限
- ユーザー管理
- カテゴリー管理
- 評価パネルメンバーの割り当て
- システム設定管理
- 全データへのアクセス
---
## Data Model (High-Level)
### User
- ID
- Username
- Password (encrypted)
- Email
- Role (Submitter/Evaluator/Administrator)
- Created Date
### Idea
- ID
- Title
- Description
- Category
- Submitter ID
- Status (Draft/Submitted/Under Evaluation/Evaluated)
- Submission Date
- Last Modified Date
### Evaluation
- ID
- Idea ID
- Evaluator ID
- Feasibility Score (1-10)
- Impact Score (1-10)
- Innovation Score (1-10)
- Total Score (calculated)
- Evaluation Date
- Status (Pending/Completed)
### Category
- ID
- Name
- Description
### Recognition
- ID
- Idea ID
- Rank (1/2/3)
- Award Date
- Badge/Certificate Details
---
## Success Criteria
1. **機能完全性**: 全ての機能要件が実装され、正常に動作する
2. **ユーザビリティ**: ユーザーが直感的にシステムを使用できる
3. **パフォーマンス**: 全てのNFR要件を満たす
4. **セキュリティ**: 認証・認可が適切に機能し、脆弱性がない
5. **テストカバレッジ**: 主要機能のユニットテストとインテグレーションテストが完備
---
## Out of Scope (Phase 1)
- モバイルアプリケーション
- 多要素認証（MFA）
- SSO連携
- メール通知機能
- 添付ファイルのアップロード
- コメント・ディスカッション機能
- アイデアのバージョン管理
- 高度な分析（時系列分析、予測分析等）
---
## Assumptions
1. ユーザーは基本的なWebブラウザの操作ができる
2. インターネット接続が安定している
3. AWSアカウントとリソースが利用可能
4. 初期ユーザーデータ（管理者アカウント等）は手動で設定可能
---
## Constraints
1. 予算制約：小規模組織向けのコスト効率的なソリューション
2. 技術制約：AWS サービスを使用
3. 時間制約：合理的な開発期間内での実装
4. リソース制約：小規模チームでの開発・運用
---
## Dependencies
1. AWS アカウントとサービスへのアクセス
2. 開発環境のセットアップ
3. データベース設計の完了
4. UI/UXデザインの承認（簡易的なもの）
これにより、次のステップである「ユーザーストーリー生成」への準備が整います。
所感
「作りたいもの」のイメージをざっくり伝えるだけで、AIが不足している情報を特定し、質問形式で深掘りしてくれる体験は非常に新鮮でした。
体験して感じたポイント：
- スピード感: 迷うことなく数分でドラフトが完成する
- 気づき: 自分一人では漏れがちな「認証方式」や「データ保持ポリシー」などの非機能要件をAIが指摘してくれるのが心強い
- 繰り返しの重要性: 生成自体は一瞬なので、納得がいくまでプロンプトや回答を修正してサイクルを回すのが良さそうです
要件分析をどこまでAIに任せ、どこまで人間が時間をかけるべきか、実戦投入に向けた良い示唆が得られました。
次回は、この要件を元にしたInception ユーザーストーリー作成編をお届けします。お楽しみに！
参考資料
- AI-DLC ホワイトペーパー
- 今回体験したworkshop
- AWS SA 金森さんによるAI-DLCに関する紹介資料
- Skill BuilderでのAI-DLC紹介（※英語のみ。日本語準備中だそうです）