AI駆動開発ライフサイクル(AI-DLC)のホワイトペーパーを解説

株式会社サーバーワークスの社内勉強会でAI駆動開発ライフサイクル(AI-DLC)や仕様駆動開発についての発表をしたときに作成した資料です。

この勉強会の内容を記事にしたブログも公開しています。
ブログ記事も参考にしてください。
https://blog.serverworks.co.jp/ai-dlc-study-session-insights

Transcript

1. AI駆動開発ライフサイクル(AI-DLC) の基本と仕様駆動開発について AI-DLCのホワイトペーパーを解説 アプリケーションサービス部　針生 泰有 2025/11/5 株式会社サーバーワークス
2. https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ AI-DLC（AI駆動開発ライフサイクル） 2025/11/5 株式会社サーバーワークス 2
3. https://prod.d13rzhkk8cj2z0.amplifyapp.com/ AI-DLC（AI駆動開発ライフサイクル） 2025/11/5 株式会社サーバーワークス 3
4. 1. 背景 2. 主要原則（AI-DLCを形成する10の設計原則） 3. コアフレームワーク フェーズとイベント インセプションフェーズ コンストラクションフェーズ オペレーションフェーズ 4. 開発期間の比較 5. AI-DLC実践：グリーンフィールド開発 6. AI-DLC実践：ブラウンフィールド開発 7. ツール 8. 付録 目次 2025/11/5 株式会社サーバーワークス 4
5. 1. 背景 2025/11/5 株式会社サーバーワークス
6. ソフトウェア開発の進化：抽象化レベルの向上 機械語時代 〜1950 年代 01001000 01100101 01101100 01101100 01101111 • 低レベル • ハードウェア依存 • 開発者の負担⼤ • ⽣産性：極めて低い ⾼級⾔語時代 1960 〜1980 年代 printf("Hello"); for (i=0; i<10; i++) { process(data[i]); } • C, FORTRAN, COBOL • ⼈間が読める • 抽象化レベル向上 • ⽣産性：低〜中 API/ ライブラリ時代 1990 〜2000 年代 import library result = library .process(data) .filter(x => x > 0) • 再利⽤可能な部品 • フレームワーク登場 • 複雑さの隠蔽 • ⽣産性：中〜⾼ AI ⽀援時代 2020 年代前半 💬 • LLM による⽀援 • コード⽣成 • バグ検出 • テスト⽣成 • ⽣産性：⾼ AI 駆動時代（AI-DLC ） 2020 年代後半〜 🤖➡ • AI が主導的役割 • 要件詳細化 • 計画・タスク分解 • 設計・実装 • リアルタイム協働 • ⽣産性：極めて⾼ パラダイムシフト ⽣産性の向上 開発者 ⽣産性 機械語 ⾼級⾔語 API/ ライブラリ AI ⽀援 AI 駆動 (AI-DLC) 従来⼿法の限界 • 週・⽉単位のイテレーション → AI の⾼速性と不整合 • ⼿動ワークフローと硬直的役割定義 → AI の能⼒を制限 • AI の後付けは真価を発揮できない → 再構想が必要 解決 AI-DLC の提案 • AI をコアに据えたゼロベース再設計 • 時間・⽇単位の超⾼速イテレーション（Bolt ） • AI による能動的ワークフロー主導、⼈間は検証と意思決定に専念 1. 背景 2025/11/5 株式会社サーバーワークス 6
7. 2. 主要原則 AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス
8. 1. 後付けではなく再構想 既存の開発手法にAIを後付けするのではなく、ゼロベースで再構想 します 従来のアジャイルは数週間〜数ヶ月単位のイテレーションが前提で した AIを活用すると、開発サイクルは数時間〜数日単位へ短縮されます この速度では従来の定期的なイベントの多くは不要になります 必要なのは自動車であり、より速い馬車ではありません 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 8
9. 2. 会話の方向を逆転 従来は人間がAIに指示していましたが、AI-DLCでは関係が逆転しま す AIが目標を受け取り、タスクに分解して実行計画を提案します 人間は重要な判断ポイントで選択肢を評価し、意思決定を行います Google Mapsの例：目的地を設定すれば、システムが最適ルートを 提示します あなたは全体を監督しながら、必要に応じて経路を調整します 開発者は戦略的な判断に集中し、AIが計画立案やタスク管理を担当 します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 9
10. 3. 設計技法のコアへの統合 従来のアジャイルフレームワークは設計技法をチームの裁量に委ね ています AI-DLCは設計技法を開発プロセスの中核に据えます DDD、BDD、TDDの各実践に対応したフレーバーを提供します DDDフレーバーでは、AIがシステムを適切なサイズのコンテキスト へ自動分解します AIが計画とタスク分解を担当し、開発者は検証と調整に集中します 手作業の負担を減らしながら品質を維持し、高速なイテレーション を実現します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 10
11. 4. AIの能力に合わせた設計 現在のAIは完全な自律動作にはまだ課題があります 一方で、人間主導でAIが補助するだけでは、AIの真の力を引き出せ ません AI-DLCはこの両極端の中間を目指します AIが積極的に開発を推進し、開発者が検証・意思決定・監視の最終 責任を担います AIの強みを最大限に活用しながら、人間の判断という安全装置も確 保します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 11
12. 5. 複雑なシステムの構築に対応 AI-DLCはエンタープライズレベルの複雑なシステム開発に特化して います 専門的な設計パターンやベストプラクティスを適用します 複数のチームが協調して開発を進めます 単純なシステムや技術判断が少ないアプリケーションは対象外です それらはローコード・ノーコードツールで十分に対応できます 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 12
13. 6. 慣れ親しんだ要素で円滑な移行を実現 手法を再構想しても、人間による検証とリスク管理に必要な要素は 残します ユーザーストーリー 人間とAIが「何を作るか」の認識を合わせる明確な契約 リスクレジスター AIが生成する計画やコードが組織の基準を満たすことを保証 リアルタイム対応に最適化し、品質と安全性を維持しながら素早い 改善サイクルを実現します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 13
14. 7. 親しみやすさが、円滑な移行を実現 AI-DLCは既存の実践者が1日で習得できる設計です 従来の開発手法の馴染みのある概念を活かしながら、AI時代の新し い用語を取り入れています 開発サイクルの呼び方 従来のスクラム：スプリント（4〜6週間の反復サイクル） AI-DLC：ボルト（数時間〜数日単位の継続的なサイクル） ボルトという名称で、より迅速で集中的な開発の進め方を表現して います 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 14
15. 8. 役割の集約による効率化 AI活用により、開発者は複数の専門領域を横断して作業できます インフラ、フロントエンド、バックエンド、DevOps、セキュリティ の壁を越えて作業できます 一人で幅広い開発業務を担えるため、チームに必要な専門役割の数 を減らせます プロダクトオーナーと開発者の役割は引き続き不可欠です 責任範囲 ビジネス目標との整合性確認 設計品質の維持 リスク管理の遵守 自動化と人間の判断のバランスを保ちます 役割は最小限に留め、真に必要な場合のみ追加します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 15
16. 9. 工程を最小化、フローを最大化 AI-DLCは自動化によって引き継ぎを最小化し、継続的な開発フロー を実現します 重要な局面で人間による検証フェーズを設けています これらの検証は「損失関数」として機能し、手戻りや無駄な作業を 事前に防ぎます 最小限の介入で、最大限の適応性を確保します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 16
17. 10. 固定的・独断的なワークフローからの脱却 AI-DLCは決まったワークフローを押し付けません AIが開発の目的を理解して最適な計画を提案します 人間はAIとの対話を通じて計画を確認・調整します 大きな計画から細かいタスクまで段階的に詰めていきます 実際の作業はAIが担当し、人間は結果の確認と承認に集中します 重要な判断は人間が握りつつ、AIの進化に合わせて柔軟に対応でき ます 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 17
18. 3. コアフレームワーク 2025/11/5 株式会社サーバーワークス
19. ROLES / RITUALS プロダクトオーナー, 開発者, AI [Mob Elaboration] 開発者, AI [Mob Programming] プロダクトオーナー, 開発者, AI PHASES Inception Construction Operation Intent Unit 1 Bolt 1 Unit 2 Unit n ARTEFACTS PRFAQ 、ユーザーストー リー、NFR 、リスク、メ トリクス、ボルト計画 ドメイン設計、論理設 計、コードとユニットテ スト デプロイメントユニット 🚀 🔴 🟢 🔵 🔴 🟢 🔵 🔴 🟢 🔵 🚀 🚀 🚀 Bolt 2 Bolt n Bolt n+1 🔴 🟢 🔵 プロダクトオーナー, 開発者, AI [Mob Testing] 3. コアフレームワーク 2025/11/5 株式会社サーバーワークス 19
20. 意図(Intent) 達成すべき目的を表す高レベルの記述（例：新 機能追加、パフォーマンス向上など） AIが実行可能なタスクに分解する起点となりま す 人間の目的とAI生成計画を結びつけます 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 20
21. ユニット(Unit) 意図から派生した自己完結型の作業要素 測定可能な価値を提供する独立した機能ブロッ ク DDDのサブドメイン、スクラムのエピックに相 当 ユーザーストーリーのセットで機能範囲を定義 疎結合で自律的開発・独立デプロイが可能 AIが分解提案、人間が検証・改良 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 21
22. ボルト(Bolt) AI-DLCの最小イテレーション単位 時間または日数単位で完了する高速構築-検証 サイクル 従来のスプリント(4〜6週間)を超高速化 1つのユニットまたはユニット内のタスクセッ トを実装 AIが計画立案、人間が検証・承認 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 22
23. ドメイン設計 インフラから独立したコアビジネスロジックのモデル化 DDD原則で集約、エンティティ、値オブジェクト等を定義 論理設計 非機能要件と適切なアーキテクチャパターン(CQRS等)を適用 AIがADRを作成、開発者が検証 コード&テスト 論理設計から適切なAWSサービスを選択しコード生成 AIがユニットテストを実施、結果分析、修正提案 デプロイメントユニット 運用準備完了した実行可能パッケージ(コンテナ、Lambda等) 機能・セキュリティ・NFRテストを完全実施済み 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 23
24. インセプションフェーズ （Inception Phase） 意図（Intent）を捉え、開発可能なユニット（Unit） に変換するフェーズです。 発生するイベント：モブエラボレーション 単一の部屋で共有画面を使った協働作業 ファシリテーターが主導 3. コアフレームワーク - フェーズとイベント 2025/11/5 株式会社サーバーワークス 24
25. 主要なポイント AIの役割 意図をユーザーストーリー、受け入れ基準、ユ ニットに分解提案 ドメイン知識と疎結合・高凝集の原則を活用 並行実行を可能にする構造を設計 人間の役割 プロダクトオーナー、開発者、QA等が協力し てレビュー 過小/過剰設計を調整 実世界の制約と整合 成果物 PRFAQ ユーザーストーリー 非機能要件（NFR）定義 リスクの説明 測定基準 提案されたボルト 効果 数週間〜数ヶ月の作業を数時間に凝縮 モブ内およびAIとの深い整合を実現 3. コアフレームワーク - 開始フェーズ 2025/11/5 株式会社サーバーワークス 25
26. コンストラクションフェーズ （Construction Phase） インセプションフェーズで定義されたユニットを、 テスト済みの運用準備が整ったデプロイメントユニ ットに変換するフェーズです。 発生するイベント：モブコンストラクショ ン 全チームが単一の部屋に集まる 統合仕様を交換、決定、ボルトを提供 3. コアフレームワーク - フェーズとイベント 2025/11/5 株式会社サーバーワークス 26
27. 主要なポイント 段階的な進行 ドメイン設計 → ビジネスロジックを技術から 独立してモデル化 論理設計 → 非機能要件とクラウド設計パター ンを適用 コード生成 → AWSサービスにマッピングして コード生成 自動テスト → 機能・セキュリティ・運用準備 を確保 ブラウンフィールド対応 既存コードをモデリング表現に昇格（静的・動 的モデル） AIへのコンテキストを簡潔・正確に AIの役割 タスク推奨と各タスクでオプション提供（設計 パターン、UX、テスト等） ウェルアーキテクテッド原則に準拠したコード 生成 テスト実行、結果分析、修正提案 人間の役割 各ステップでAI生成出力を検証 重要な決定を行う 品質と適応性を確保 3. コアフレームワーク - 構築フェーズ 2025/11/5 株式会社サーバーワークス 27
28. オペレーションフェーズ （Operations Phase） AIを活用してシステムのデプロイメント、可観測 性、保守を行うフェーズです。 具体例 レイテンシスパイク検出 → エンジンスケーリン グ提案 API応答時間低下 → DynamoDBスループット増 加提案 3. コアフレームワーク - フェーズとイベント 2025/11/5 株式会社サーバーワークス 28
29. 主要なポイント デプロイメント デプロイメントユニット（コンテナイメージ、 サーバーレス関数等）のパッケージ化 ステージング・本番環境へのロールアウト 可観測性と監視（AIによる分析） テレメトリデータ（メトリクス、ログ、トレー ス）の積極的分析 パターン検出と異常の特定 潜在的なSLA違反の予測 プロアクティブな問題解決の実現 AIによる運用対応 インシデントランブックとの統合 実行可能な推奨事項の提案 リソーススケーリング パフォーマンスチューニング 障害分離 開発者承認後の解決策実行 人間の役割 検証者として機能 AI生成の洞察と提案アクションの検証 SLAおよびコンプライアンス要件との整合確認 3. コアフレームワーク - 運用フェーズ 2025/11/5 株式会社サーバーワークス 29
30. 開発期間の比較 2025/11/5 株式会社サーバーワークス
31. 開発期間の⽐較：従来⼿法 vs AI-DLC 従来の開発⼿法（ウォーターフォール / アジャイル） 要件定義 ━━━━━━━ 2-4 週間 設計 ━━━━━━━ 2-3 週間 開発 ━━━━━━━ 4-8 週間 テスト ━━━━━━━ 2-4 週間 デプロイ ━━━━━━━ 1-2 週間 運⽤開始 合計開発期間：11 〜21 週間（約3 〜5 ヶ⽉） AI-DLC （AI 駆動開発ライフサイクル） インセプション フェーズ ━━━━━━━ 数時間〜1 ⽇ コンストラクション フェーズ ━━━━━━━ 1 〜5 ⽇ 運⽤開始 合計開発期間：1 〜6 ⽇ 0 週 5 週 10 週 15 週 20 週 開発期間の比較 2025/11/5 株式会社サーバーワークス 31
32. 4. AI-DLC実践 - グリーンフィールド開発 新規システムの開発 2025/11/5 株式会社サーバーワークス
33. 1. インセプションフェーズ ⾼レベルの意図 例: レコメンデーション エンジン開発 事前計画 AI がレベル1 計画を⽣成 ⼈間が 検証・修正 修正 Mob Elaboration （協働作業） 1. 明確化 AI が質問 ━━━━━━━ • 主要ユーザーは? • ビジネス成果は? • 制約条件は? ⼈間が回答 ━━━━━━━ 曖昧さを解消 2. 詳細化 AI が作成 ━━━━━━━ • ユーザーストーリー • 受け⼊れ基準 • NFR • リスク チーム検証 PO/ 開発/QA 修正 3. Unit 構成 AI がUnit 化 ━━━━━━━ • ユーザーデータ収集 • アルゴリズム選択 • API 統合 PO 検証 例:GDPR 要件追加 修正 最終化 AI: PRFAQ ⽣成 ━━━━━━━ • ビジネス意図 • 機能概要 • 期待利益 開発者/PO 最終検証 修正 成果物 ✓ PRFAQ ✓ ユーザーストーリー ✓ NFR 定義 ✓ リスク説明 ✓ 測定基準 ✓ 提案ボルト 構築フェーズへ 承認 承認 承認 承認 4. AI-DLC実践 - グリーンフィールド開発 2025/11/5 株式会社サーバーワークス 33
34. 2. コンストラクションフェーズ インセプションフェーズ 成果物を受領 Mob Construction 開始 ━━━━━━━ 全チームが単⼀部屋に集合 ドメイン設計 AI がDDD 原則でモデリング ━━━━━━━━━━━ • エンティティ識別 （Product, Customer 等） • 集約定義 • 値オブジェクト • ドメインイベント • リポジトリ • ファクトリ 開発者が レビュー・改良 ━━━━━━━ • ビジネスロジック検証 • エッジケース確認 例: 新規顧客の 購⼊履歴なし処理 修正 論理設計 AI が論理設計に変換 ━━━━━━━━━━━ • NFR 適⽤ （スケーラビリティ等） • アーキテクチャパターン推奨 例: イベント駆動設計 • 技術選定 例: AWS Lambda AI がADR 作成 ━━━━━━━ Architecture Decision Records 開発者が トレードオフ評価 ━━━━━━━ • パターン妥当性確認 • 技術選択承認 例: DynamoDB 選択 修正 コード⽣成 & テスト AI がコード⽣成 ━━━━━━━━━━━ • 論理設計を AWS サービスにマッピング • ウェルアーキテクテッド 原則準拠 • 実⾏可能コード作成 AI がテスト⾃動⽣成 ━━━━━━━━━━━ • 機能テスト • セキュリティテスト • パフォーマンステスト 開発者が レビュー ━━━━━━━ コード・テスト シナリオ確認 修正 テスト実⾏ & 検証 AI がテスト実⾏ ━━━━━━━━━━━ • 全テストスイート実⾏ • 結果分析 • 問題の強調表⽰ AI が修正提案 ━━━━━━━━━━━ 例: クエリロジック 最適化で パフォーマンス改善 開発者が検証 ━━━━━━━ • 修正案評価 • 品質確認 全Unit 完了? 再テスト デプロイメントユニット完成 ✓ テスト済みコード ✓ 機能テスト合格 ✓ セキュリティテスト合格 ✓ NFR テスト合格 ✓ 運⽤準備完了 運⽤フェーズへ 承認 承認 承認 承認 未完了 次Unit へ 完了 Mob Construction 4. AI-DLC実践 - グリーンフィールド開発 2025/11/5 株式会社サーバーワークス 34
35. 3. オペレーションフェーズ デプロイメント ユニット受領 デプロイメント AI がパッケージ化 ━━━━━━━━━━━ • コンテナイメージ作成 （Docker/Kubernetes ） • サーバーレス関数準備 （Lambda 等） • 設定ファイル⽣成 （Helm Charts 等） • IaC スクリプト作成 （Terraform/CFN ） AI がデプロイ構成提案 ━━━━━━━━━━━ • ステージング環境 • 本番環境 • ロールアウト戦略 （Blue/Green 等） 開発者が承認 ━━━━━━━ • 構成確認 • デプロイ戦略評価 修正 デプロイ完了 ━━━━━━━ システム稼働開始 監視・可観測性 AI が継続的に分析 ━━━━━━━━━━━ • メトリクス監視 • ログ分析 • トレース解析 AI がパターン検出 ━━━━━━━━━━━ • 正常動作パターン学習 • 異常パターン識別 異常検知? AI が詳細分析 ━━━━━━━━━━━ • 根本原因特定 • 影響範囲評価 • SLA 違反リスク予測 AI が対応策推奨 ━━━━━━━━━━━ 例: • リソーススケーリング • パフォーマンスチューニング • 障害分離 • DynamoDB スループット増加 • API Gateway トラフィック 再バランス AI がランブック統合 ━━━━━━━━━━━ • 既存プレイブック参照 • 実⾏可能アクション提案 正常 異常あり 対応実⾏ 開発者が検証・承認 ━━━━━━━━━━━ • 推奨事項評価 • SLA 整合確認 • コンプライアンス確認 ⼿動対応 ━━━━━━━ 開発者が直接対処 AI が解決策実⾏ ━━━━━━━━━━━ • ⾃動スケーリング • 構成変更 • リソース調整 結果監視 ━━━━━━━ • 効果測定 • 継続監視 AI が学習 ━━━━━━━ • 対応結果を記録 • パターン更新 • ランブック改善 却下 承認 プロアクティブな問題解決 AI が予測分析 ━━━━━━━━━━━ • 潜在的問題予測 • 容量計画提案 • 最適化機会特定 ━━━━━━━━━━━ 例: • トラフィック増加予測に基づく 事前スケーリング • ストレージ容量不⾜の予測 • コスト最適化提案 開発者が 計画承認 ━━━━━━━ • 予測妥当性確認 • 実施タイミング決定 • リソース承認 予防措置実施 ━━━━━━━ • リソース事前調整 • 構成最適化 • プロアクティブ対応 承認 却下 承認 リアクティブ対応（異常発⽣時） プロアクティブ対応（予測的） 4. AI-DLC実践 - グリーンフィールド開発 2025/11/5 株式会社サーバーワークス 35
36. 5. AI-DLC実践 - ブラウンフィールド開発 既存システムへの変更 2025/11/5 株式会社サーバーワークス
37. コンストラクションフェーズ ブラウンフィールド開発 - 構築フェーズ インセプションフェーズ 成果物を受領 コード昇格（既存システム分析） 既存コードベース ━━━━━━━━━━━ • レガシーコード • ドキュメント不⾜ • 暗黙知の蓄積 AI がコード解析 ━━━━━━━━━━━ • コード構造の理解 • 依存関係の特定 • ビジネスロジックの抽出 • パターンの識別 AI がモデル⽣成 ━━━━━━━━━━━ 【静的モデル】 • コンポーネント • 責任と役割 • 関係性 【動的モデル】 • 重要ユースケースの 相互作⽤フロー モデル検証・修正 開発者・PM が 協⼒してレビュー ━━━━━━━━━━━ • 静的モデルの妥当性確認 • 動的モデルの正確性検証 • ビジネスロジックの整合性 • ドメイン知識との照合 修正・補完 ━━━━━━━━━━━ • 誤解釈の修正 • ⽋落情報の追加 • ドメイン知識の反映 • 暗黙知の明⽰化 検証済みモデル ━━━━━━━━━━━ ✓ 正確な静的モデル ✓ 正確な動的モデル ✓ 共通理解の確⽴ ✓ AI への正確な コンテキスト提供 修正必要 再確認 グリーンフィールドと同じフロー ドメイン設計 AI がDDD で モデリング 開発者が レビュー 論理設計 AI がNFR 適⽤ パターン推奨 開発者が トレードオフ 評価 コード⽣成 AI がコード テスト⽣成 開発者が レビュー テスト実⾏ AI がテスト 実⾏・分析 開発者が 検証 承認 承認 承認 ブラウンフィールドの特徴 ━━━━━━━━━━━━━━━ 既存コードをセマンティックに 豊かなモデルに昇格させることで: ✓ AI へのコンテキストが簡潔・正確に ✓ 開発チーム間で共通理解が確⽴ ✓ 変更影響範囲が明確に ✓ 技術的負債の可視化 この後の流れは グリーンフィールドと同⼀ モデル昇格の利点 • 静的モデル: コンポーネント、責任、関係性を可視化 • 動的モデル: 重要なユースケースでの相互作⽤を明⽰ • AI が正確なコンテキストで作業できる • チーム全体が現状システムへの共通理解を持てる デプロイメントユニット完成 ✓ テスト済みコード ✓ 機能テスト合格 ✓ セキュリティテスト合格 ✓ NFR テスト合格 ✓ 運⽤準備完了 運⽤フェーズへ 承認 【追加ステップ】既存システムの理解 【標準フロー】 5. AI-DLC実践 - ブラウンフィールド開発 2025/11/5 株式会社サーバーワークス 37
38. ツール 2025/11/5 株式会社サーバーワークス
39. AI-DLCを実践するための主要ツール Amazon Q Developer Kiro GitHub Spec Kit ツール 2025/11/5 株式会社サーバーワークス 39
40. 付録 2025/11/5 株式会社サーバーワークス
41. AI-DLCを実践する際にAIと効果的に対話するためのプロンプト例をご紹介します。 セットアッププロンプト アプリケーション開発を開始する際の初期設定用プロンプトです。 今日はアプリケーションを構築します。 プロジェクトフォルダーを作成し、すべてのドキュメントは「aidlc-docs」フォルダーに保存してください。 セッション全体を通じて以下のルールに従ってください： - 作業前に必ず計画を立て、mdファイルにまとめてください - 私が承認した計画のみを実行してください - 計画は「aidlc-docs/plans」フォルダーに保存してください ドキュメントの保存先： - 要件・機能変更ドキュメント → aidlc-docs/requirements - ユーザーストーリー → aidlc-docs/story-artifacts - アーキテクチャ・設計ドキュメント → aidlc-docs/design-artifacts - プロンプト履歴 → aidlc-docs/prompts.md（順番に記録） このルールを理解したら確認してください。 必要なフォルダーとファイルがまだない場合は作成してください。 付録 2025/11/5 株式会社サーバーワークス 41
42. ユーザーストーリー作成プロンプト システム開発の契約となるユーザーストーリーを作成するためのプロンプトです。 【あなたの役割】 専門のプロダクトマネージャーとして、開発契約となる明確なユーザーストーリーを作成してください。 【作業の進め方】 1. 作業計画を立て、各ステップにチェックボックス付きで「user_stories_plan.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画完成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 以下の高レベル要件からユーザーストーリーを構築してください << ここに製品説明を記述 >> --- 【計画レビュー後の承認プロンプト】 計画を承認します。<< mdファイル名 >> の計画に従って作業を進めてください。 計画どおりに私と対話し、各ステップ完了時にチェックボックスをマークしてください。 付録 - インセプション 2025/11/5 株式会社サーバーワークス 42
43. ユニット分割プロンプト ユーザーストーリーを独立した開発可能なユニットに分割するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアアーキテクトとして、ユーザーストーリーを最適なユニットに分割してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きで「units_plan.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「mvp_user_stories.md」のユーザーストーリーを参照し、以下の条件でユニットに分割してください： - 各ユニットは独立して構築可能 - 各ユニットには単一チームで構築できる高凝集のストーリーを含む - ユニット同士は疎結合である - 各ユニットのストーリーと受け入れ基準を「design/」フォルダーに個別のmdファイルで記述 --- 【計画レビュー後の承認プロンプト】 承認します。計画に従って作業を進めてください。 付録 - インセプション 2025/11/5 株式会社サーバーワークス 43
44. ドメインモデル作成プロンプト ユーザーストーリーからコンポーネントモデルを設計するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアエンジニアとして、コンポーネントモデルを設計してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きで「design/component_model.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「design/seo_optimization_unit.md」のユーザーストーリーを参照し、コンポーネントモデルを設計してください。 モデルには以下を含めてください： - すべてのコンポーネント - コンポーネントの属性と動作 - ユーザーストーリー実装のためのコンポーネント間の相互作用 注意：この段階ではコードを生成しないでください。 コンポーネントモデルは「/design」フォルダーに別のmdファイルとして記述してください。 --- 【計画レビュー後の承認プロンプト】 計画を承認します。作業を進めてください。 各ステップ完了後、計画ファイルのチェックボックスをマークしてください。 付録 - コンストラクション 2025/11/5 株式会社サーバーワークス 44
45. コード生成プロンプト コンポーネント設計から実装コードを生成するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアエンジニアとして、設計からコードを実装してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きでmdファイルに記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「search_discovery/nlp_component.md」のコンポーネント設計を参照してください。 以下の要件で自然言語処理（NLP）コンポーネントのPython実装を生成してください： - シンプルで直感的な実装 - processQuery(queryText)メソッドはAmazon Bedrock APIを使用してエンティティを抽出 - 各クラスは個別のファイルに生成し、「vocabMapper」ディレクトリに保存 【追加の分析タスク（必要に応じて）】 現在の実装がローカルのvocabulary_repositoryを使用している場合： EntityExtractorコンポーネントでGenAIを活用する方法を分析し、 エンティティ抽出とインテント抽出の両方にGenAIを活用する計画を提案してください。 付録 - コンストラクション 2025/11/5 株式会社サーバーワークス 45
46. デプロイメント計画プロンプト AWSクラウドへのデプロイメント計画を立てるためのプロンプトです。 【あなたの役割】 経験豊富なクラウドアーキテクトとして、デプロイメント計画を作成してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きで「deployment_plan.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 以下のファイルを参照してください： - コンポーネント設計モデル：design/core_component_model.md - ユニット：UNITS/フォルダー - クラウドアーキテクチャ：ARCHITECTURE/フォルダー - バックエンドコード：BACKEND/フォルダー 以下を完了してください： 1. [CloudFormation/CDK/Terraform]を使用したAWSクラウドへのデプロイメント計画（エンドツーエンド） 2. デプロイメントの前提条件をすべて文書化 【計画承認後の実装】 - クリーンでシンプルで説明可能なコーディングのベストプラクティスに従う - すべての出力コードは「DEPLOYMENT/」フォルダーに保存 - 検証計画を作成し、検証レポートを生成して動作確認 - 検証レポートをレビューし、問題をすべて修正して更新 付録 - コンストラクション 2025/11/5 株式会社サーバーワークス 46
47. REST API構築プロンプト サービスからREST APIを構築するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアエンジニアとして、REST APIを実装してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きでmdファイルに記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「construction/<>/services.py」を参照してください。 各サービスに対してPython Flask APIを作成してください。 付録 - コンストラクション 2025/11/5 株式会社サーバーワークス 47
48. 2025/11/5 株式会社サーバーワークス