Slide 1

Slide 1 text

AI駆動開発ライフサイクル(AI-DLC) の基本と仕様駆動開発について AI-DLCのホワイトペーパーを解説 アプリケーションサービス部 針生 泰有 2025/11/5 株式会社サーバーワークス

Slide 2

Slide 2 text

https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ AI-DLC(AI駆動開発ライフサイクル) 2025/11/5 株式会社サーバーワークス 2

Slide 3

Slide 3 text

https://prod.d13rzhkk8cj2z0.amplifyapp.com/ AI-DLC(AI駆動開発ライフサイクル) 2025/11/5 株式会社サーバーワークス 3

Slide 4

Slide 4 text

1. 背景 2. 主要原則(AI-DLCを形成する10の設計原則) 3. コアフレームワーク フェーズとイベント インセプションフェーズ コンストラクションフェーズ オペレーションフェーズ 4. 開発期間の比較 5. AI-DLC実践:グリーンフィールド開発 6. AI-DLC実践:ブラウンフィールド開発 7. ツール 8. 付録 目次 2025/11/5 株式会社サーバーワークス 4

Slide 5

Slide 5 text

1. 背景 2025/11/5 株式会社サーバーワークス

Slide 6

Slide 6 text

ソフトウェア開発の進化:抽象化レベルの向上 機械語時代 〜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

Slide 7

Slide 7 text

2. 主要原則 AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス

Slide 8

Slide 8 text

1. 後付けではなく再構想 既存の開発手法にAIを後付けするのではなく、ゼロベースで再構想 します 従来のアジャイルは数週間〜数ヶ月単位のイテレーションが前提で した AIを活用すると、開発サイクルは数時間〜数日単位へ短縮されます この速度では従来の定期的なイベントの多くは不要になります 必要なのは自動車であり、より速い馬車ではありません 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 8

Slide 9

Slide 9 text

2. 会話の方向を逆転 従来は人間がAIに指示していましたが、AI-DLCでは関係が逆転しま す AIが目標を受け取り、タスクに分解して実行計画を提案します 人間は重要な判断ポイントで選択肢を評価し、意思決定を行います Google Mapsの例:目的地を設定すれば、システムが最適ルートを 提示します あなたは全体を監督しながら、必要に応じて経路を調整します 開発者は戦略的な判断に集中し、AIが計画立案やタスク管理を担当 します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 9

Slide 10

Slide 10 text

3. 設計技法のコアへの統合 従来のアジャイルフレームワークは設計技法をチームの裁量に委ね ています AI-DLCは設計技法を開発プロセスの中核に据えます DDD、BDD、TDDの各実践に対応したフレーバーを提供します DDDフレーバーでは、AIがシステムを適切なサイズのコンテキスト へ自動分解します AIが計画とタスク分解を担当し、開発者は検証と調整に集中します 手作業の負担を減らしながら品質を維持し、高速なイテレーション を実現します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 10

Slide 11

Slide 11 text

4. AIの能力に合わせた設計 現在のAIは完全な自律動作にはまだ課題があります 一方で、人間主導でAIが補助するだけでは、AIの真の力を引き出せ ません AI-DLCはこの両極端の中間を目指します AIが積極的に開発を推進し、開発者が検証・意思決定・監視の最終 責任を担います AIの強みを最大限に活用しながら、人間の判断という安全装置も確 保します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 11

Slide 12

Slide 12 text

5. 複雑なシステムの構築に対応 AI-DLCはエンタープライズレベルの複雑なシステム開発に特化して います 専門的な設計パターンやベストプラクティスを適用します 複数のチームが協調して開発を進めます 単純なシステムや技術判断が少ないアプリケーションは対象外です それらはローコード・ノーコードツールで十分に対応できます 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 12

Slide 13

Slide 13 text

6. 慣れ親しんだ要素で円滑な移行を実現 手法を再構想しても、人間による検証とリスク管理に必要な要素は 残します ユーザーストーリー 人間とAIが「何を作るか」の認識を合わせる明確な契約 リスクレジスター AIが生成する計画やコードが組織の基準を満たすことを保証 リアルタイム対応に最適化し、品質と安全性を維持しながら素早い 改善サイクルを実現します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 13

Slide 14

Slide 14 text

7. 親しみやすさが、円滑な移行を実現 AI-DLCは既存の実践者が1日で習得できる設計です 従来の開発手法の馴染みのある概念を活かしながら、AI時代の新し い用語を取り入れています 開発サイクルの呼び方 従来のスクラム:スプリント(4〜6週間の反復サイクル) AI-DLC:ボルト(数時間〜数日単位の継続的なサイクル) ボルトという名称で、より迅速で集中的な開発の進め方を表現して います 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 14

Slide 15

Slide 15 text

8. 役割の集約による効率化 AI活用により、開発者は複数の専門領域を横断して作業できます インフラ、フロントエンド、バックエンド、DevOps、セキュリティ の壁を越えて作業できます 一人で幅広い開発業務を担えるため、チームに必要な専門役割の数 を減らせます プロダクトオーナーと開発者の役割は引き続き不可欠です 責任範囲 ビジネス目標との整合性確認 設計品質の維持 リスク管理の遵守 自動化と人間の判断のバランスを保ちます 役割は最小限に留め、真に必要な場合のみ追加します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 15

Slide 16

Slide 16 text

9. 工程を最小化、フローを最大化 AI-DLCは自動化によって引き継ぎを最小化し、継続的な開発フロー を実現します 重要な局面で人間による検証フェーズを設けています これらの検証は「損失関数」として機能し、手戻りや無駄な作業を 事前に防ぎます 最小限の介入で、最大限の適応性を確保します 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 16

Slide 17

Slide 17 text

10. 固定的・独断的なワークフローからの脱却 AI-DLCは決まったワークフローを押し付けません AIが開発の目的を理解して最適な計画を提案します 人間はAIとの対話を通じて計画を確認・調整します 大きな計画から細かいタスクまで段階的に詰めていきます 実際の作業はAIが担当し、人間は結果の確認と承認に集中します 重要な判断は人間が握りつつ、AIの進化に合わせて柔軟に対応でき ます 2. 主要原則 - AI-DLCを形成する10の設計原則 2025/11/5 株式会社サーバーワークス 17

Slide 18

Slide 18 text

3. コアフレームワーク 2025/11/5 株式会社サーバーワークス

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

意図(Intent) 達成すべき目的を表す高レベルの記述(例:新 機能追加、パフォーマンス向上など) AIが実行可能なタスクに分解する起点となりま す 人間の目的とAI生成計画を結びつけます 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 20

Slide 21

Slide 21 text

ユニット(Unit) 意図から派生した自己完結型の作業要素 測定可能な価値を提供する独立した機能ブロッ ク DDDのサブドメイン、スクラムのエピックに相 当 ユーザーストーリーのセットで機能範囲を定義 疎結合で自律的開発・独立デプロイが可能 AIが分解提案、人間が検証・改良 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 21

Slide 22

Slide 22 text

ボルト(Bolt) AI-DLCの最小イテレーション単位 時間または日数単位で完了する高速構築-検証 サイクル 従来のスプリント(4〜6週間)を超高速化 1つのユニットまたはユニット内のタスクセッ トを実装 AIが計画立案、人間が検証・承認 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 22

Slide 23

Slide 23 text

ドメイン設計 インフラから独立したコアビジネスロジックのモデル化 DDD原則で集約、エンティティ、値オブジェクト等を定義 論理設計 非機能要件と適切なアーキテクチャパターン(CQRS等)を適用 AIがADRを作成、開発者が検証 コード&テスト 論理設計から適切なAWSサービスを選択しコード生成 AIがユニットテストを実施、結果分析、修正提案 デプロイメントユニット 運用準備完了した実行可能パッケージ(コンテナ、Lambda等) 機能・セキュリティ・NFRテストを完全実施済み 3. コアフレームワーク - 用語解説 2025/11/5 株式会社サーバーワークス 23

Slide 24

Slide 24 text

インセプションフェーズ (Inception Phase) 意図(Intent)を捉え、開発可能なユニット(Unit) に変換するフェーズです。 発生するイベント:モブエラボレーション 単一の部屋で共有画面を使った協働作業 ファシリテーターが主導 3. コアフレームワーク - フェーズとイベント 2025/11/5 株式会社サーバーワークス 24

Slide 25

Slide 25 text

主要なポイント AIの役割 意図をユーザーストーリー、受け入れ基準、ユ ニットに分解提案 ドメイン知識と疎結合・高凝集の原則を活用 並行実行を可能にする構造を設計 人間の役割 プロダクトオーナー、開発者、QA等が協力し てレビュー 過小/過剰設計を調整 実世界の制約と整合 成果物 PRFAQ ユーザーストーリー 非機能要件(NFR)定義 リスクの説明 測定基準 提案されたボルト 効果 数週間〜数ヶ月の作業を数時間に凝縮 モブ内およびAIとの深い整合を実現 3. コアフレームワーク - 開始フェーズ 2025/11/5 株式会社サーバーワークス 25

Slide 26

Slide 26 text

コンストラクションフェーズ (Construction Phase) インセプションフェーズで定義されたユニットを、 テスト済みの運用準備が整ったデプロイメントユニ ットに変換するフェーズです。 発生するイベント:モブコンストラクショ ン 全チームが単一の部屋に集まる 統合仕様を交換、決定、ボルトを提供 3. コアフレームワーク - フェーズとイベント 2025/11/5 株式会社サーバーワークス 26

Slide 27

Slide 27 text

主要なポイント 段階的な進行 ドメイン設計 → ビジネスロジックを技術から 独立してモデル化 論理設計 → 非機能要件とクラウド設計パター ンを適用 コード生成 → AWSサービスにマッピングして コード生成 自動テスト → 機能・セキュリティ・運用準備 を確保 ブラウンフィールド対応 既存コードをモデリング表現に昇格(静的・動 的モデル) AIへのコンテキストを簡潔・正確に AIの役割 タスク推奨と各タスクでオプション提供(設計 パターン、UX、テスト等) ウェルアーキテクテッド原則に準拠したコード 生成 テスト実行、結果分析、修正提案 人間の役割 各ステップでAI生成出力を検証 重要な決定を行う 品質と適応性を確保 3. コアフレームワーク - 構築フェーズ 2025/11/5 株式会社サーバーワークス 27

Slide 28

Slide 28 text

オペレーションフェーズ (Operations Phase) AIを活用してシステムのデプロイメント、可観測 性、保守を行うフェーズです。 具体例 レイテンシスパイク検出 → エンジンスケーリン グ提案 API応答時間低下 → DynamoDBスループット増 加提案 3. コアフレームワーク - フェーズとイベント 2025/11/5 株式会社サーバーワークス 28

Slide 29

Slide 29 text

主要なポイント デプロイメント デプロイメントユニット(コンテナイメージ、 サーバーレス関数等)のパッケージ化 ステージング・本番環境へのロールアウト 可観測性と監視(AIによる分析) テレメトリデータ(メトリクス、ログ、トレー ス)の積極的分析 パターン検出と異常の特定 潜在的なSLA違反の予測 プロアクティブな問題解決の実現 AIによる運用対応 インシデントランブックとの統合 実行可能な推奨事項の提案 リソーススケーリング パフォーマンスチューニング 障害分離 開発者承認後の解決策実行 人間の役割 検証者として機能 AI生成の洞察と提案アクションの検証 SLAおよびコンプライアンス要件との整合確認 3. コアフレームワーク - 運用フェーズ 2025/11/5 株式会社サーバーワークス 29

Slide 30

Slide 30 text

開発期間の比較 2025/11/5 株式会社サーバーワークス

Slide 31

Slide 31 text

開発期間の⽐較:従来⼿法 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

Slide 32

Slide 32 text

4. AI-DLC実践 - グリーンフィールド開発 新規システムの開発 2025/11/5 株式会社サーバーワークス

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

5. AI-DLC実践 - ブラウンフィールド開発 既存システムへの変更 2025/11/5 株式会社サーバーワークス

Slide 37

Slide 37 text

コンストラクションフェーズ ブラウンフィールド開発 - 構築フェーズ インセプションフェーズ 成果物を受領 コード昇格(既存システム分析) 既存コードベース ━━━━━━━━━━━ • レガシーコード • ドキュメント不⾜ • 暗黙知の蓄積 AI がコード解析 ━━━━━━━━━━━ • コード構造の理解 • 依存関係の特定 • ビジネスロジックの抽出 • パターンの識別 AI がモデル⽣成 ━━━━━━━━━━━ 【静的モデル】 • コンポーネント • 責任と役割 • 関係性 【動的モデル】 • 重要ユースケースの 相互作⽤フロー モデル検証・修正 開発者・PM が 協⼒してレビュー ━━━━━━━━━━━ • 静的モデルの妥当性確認 • 動的モデルの正確性検証 • ビジネスロジックの整合性 • ドメイン知識との照合 修正・補完 ━━━━━━━━━━━ • 誤解釈の修正 • ⽋落情報の追加 • ドメイン知識の反映 • 暗黙知の明⽰化 検証済みモデル ━━━━━━━━━━━ ✓ 正確な静的モデル ✓ 正確な動的モデル ✓ 共通理解の確⽴ ✓ AI への正確な コンテキスト提供 修正必要 再確認 グリーンフィールドと同じフロー ドメイン設計 AI がDDD で モデリング 開発者が レビュー 論理設計 AI がNFR 適⽤ パターン推奨 開発者が トレードオフ 評価 コード⽣成 AI がコード テスト⽣成 開発者が レビュー テスト実⾏ AI がテスト 実⾏・分析 開発者が 検証 承認 承認 承認 ブラウンフィールドの特徴 ━━━━━━━━━━━━━━━ 既存コードをセマンティックに 豊かなモデルに昇格させることで: ✓ AI へのコンテキストが簡潔・正確に ✓ 開発チーム間で共通理解が確⽴ ✓ 変更影響範囲が明確に ✓ 技術的負債の可視化 この後の流れは グリーンフィールドと同⼀ モデル昇格の利点 • 静的モデル: コンポーネント、責任、関係性を可視化 • 動的モデル: 重要なユースケースでの相互作⽤を明⽰ • AI が正確なコンテキストで作業できる • チーム全体が現状システムへの共通理解を持てる デプロイメントユニット完成 ✓ テスト済みコード ✓ 機能テスト合格 ✓ セキュリティテスト合格 ✓ NFR テスト合格 ✓ 運⽤準備完了 運⽤フェーズへ 承認 【追加ステップ】既存システムの理解 【標準フロー】 5. AI-DLC実践 - ブラウンフィールド開発 2025/11/5 株式会社サーバーワークス 37

Slide 38

Slide 38 text

ツール 2025/11/5 株式会社サーバーワークス

Slide 39

Slide 39 text

AI-DLCを実践するための主要ツール Amazon Q Developer Kiro GitHub Spec Kit ツール 2025/11/5 株式会社サーバーワークス 39

Slide 40

Slide 40 text

付録 2025/11/5 株式会社サーバーワークス

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

ユーザーストーリー作成プロンプト システム開発の契約となるユーザーストーリーを作成するためのプロンプトです。 【あなたの役割】 専門のプロダクトマネージャーとして、開発契約となる明確なユーザーストーリーを作成してください。 【作業の進め方】 1. 作業計画を立て、各ステップにチェックボックス付きで「user_stories_plan.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画完成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 以下の高レベル要件からユーザーストーリーを構築してください << ここに製品説明を記述 >> --- 【計画レビュー後の承認プロンプト】 計画を承認します。<< mdファイル名 >> の計画に従って作業を進めてください。 計画どおりに私と対話し、各ステップ完了時にチェックボックスをマークしてください。 付録 - インセプション 2025/11/5 株式会社サーバーワークス 42

Slide 43

Slide 43 text

ユニット分割プロンプト ユーザーストーリーを独立した開発可能なユニットに分割するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアアーキテクトとして、ユーザーストーリーを最適なユニットに分割してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きで「units_plan.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「mvp_user_stories.md」のユーザーストーリーを参照し、以下の条件でユニットに分割してください: - 各ユニットは独立して構築可能 - 各ユニットには単一チームで構築できる高凝集のストーリーを含む - ユニット同士は疎結合である - 各ユニットのストーリーと受け入れ基準を「design/」フォルダーに個別のmdファイルで記述 --- 【計画レビュー後の承認プロンプト】 承認します。計画に従って作業を進めてください。 付録 - インセプション 2025/11/5 株式会社サーバーワークス 43

Slide 44

Slide 44 text

ドメインモデル作成プロンプト ユーザーストーリーからコンポーネントモデルを設計するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアエンジニアとして、コンポーネントモデルを設計してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きで「design/component_model.md」に記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「design/seo_optimization_unit.md」のユーザーストーリーを参照し、コンポーネントモデルを設計してください。 モデルには以下を含めてください: - すべてのコンポーネント - コンポーネントの属性と動作 - ユーザーストーリー実装のためのコンポーネント間の相互作用 注意:この段階ではコードを生成しないでください。 コンポーネントモデルは「/design」フォルダーに別のmdファイルとして記述してください。 --- 【計画レビュー後の承認プロンプト】 計画を承認します。作業を進めてください。 各ステップ完了後、計画ファイルのチェックボックスをマークしてください。 付録 - コンストラクション 2025/11/5 株式会社サーバーワークス 44

Slide 45

Slide 45 text

コード生成プロンプト コンポーネント設計から実装コードを生成するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアエンジニアとして、設計からコードを実装してください。 【作業の進め方】 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

Slide 46

Slide 46 text

デプロイメント計画プロンプト 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

Slide 47

Slide 47 text

REST API構築プロンプト サービスからREST APIを構築するためのプロンプトです。 【あなたの役割】 経験豊富なソフトウェアエンジニアとして、REST APIを実装してください。 【作業の進め方】 1. タスク開始前に計画を立て、各ステップにチェックボックス付きでmdファイルに記述 2. 私の確認が必要な箇所はメモで明示 3. 重要な決定は独断で行わず、必ず私に確認を求める 4. 計画作成後、私のレビューと承認を待つ 5. 承認後、計画を一度に1ステップずつ実行 6. 各ステップ完了時、計画のチェックボックスをマークする 【あなたのタスク】 「construction/<>/services.py」を参照してください。 各サービスに対してPython Flask APIを作成してください。 付録 - コンストラクション 2025/11/5 株式会社サーバーワークス 47

Slide 48

Slide 48 text

2025/11/5 株式会社サーバーワークス