AI-DLC Whitepaper の翻訳
Whitepaper: https://prod.d13rzhkk8cj2z0.amplifyapp.com/
AI駆動型開発ライフサイクル（AI-DLC）手法の定義
Raja SP、Amazon Web Services
I. 背景
ソフトウェアエンジニアリングの進化は、開発者が低レベルの差別化されていないタスクを抽象化することで、複雑な問題解決に集中できるようにする継続的な探求でした。初期の機械語から高水準プログラミング言語、APIやライブラリの採用に至るまで、各ステップは開発者の生産性を大幅に向上させてきました。現在、大規模言語モデルの統合により、コード生成、バグ検出、テスト生成などのタスクに対して会話型の自然言語インタラクションを導入し、ソフトウェア作成方法に革命をもたらしています。これはAIアシスト時代の幕開けであり、AIがこのような細かく特定のタスクを強化しています。
AIが進化するにつれ、その応用はコード生成を超えて、要件の詳細化、計画、タスク分解、設計、開発者とのリアルタイムコラボレーションにまで拡大しています。この変化はAI駆動時代の始まりを告げ、AIが開発プロセスを積極的に調整します。しかし、既存のソフトウェア開発手法は人間主導の長期プロセス向けに設計されており、AIの速度、柔軟性、高度な能力（例：エージェント型）と完全に一致していません。手動ワークフローと硬直した役割定義への依存は、AIを十分に活用する能力を制限しています。AIをこれらの手法に後付けすることは、その可能性を制限するだけでなく、時代遅れの非効率性を強化することにもなります。AIの変革力を最大限に活用するには、SDLCメソッドを再考する必要があります。この再考には、AIを中心的な協力者として位置づけ、より迅速な意思決定、シームレスなタスク実行、継続的な適応性を可能にするようにワークフロー、役割、反復を調整することが必要です。
本論文では、AIの能力を完全に統合するように設計された、再考されたAIネイティブな方法論であるAI駆動型開発ライフサイクル（AI-DLC）を紹介し定義します。これはソフトウェアエンジニアリングの次の進化の基礎を築くものです。
II. 主要原則
このセクションの原則は、AI-DLCを定義するための基盤を形成し、そのフェーズ、役割、成果物、儀式を形作ります。これらの前提は提案された手法を検証するために重要であり、その設計の背後にある基本的な理論的根拠を提供します。
1. 後付けではなく再考する
既存のSDLCやアジャイル（例：スクラム）などの手法を維持してAIを後付けするのではなく、開発手法を再考することを選択します。これらの伝統的な手法は、より長い反復期間（月や週単位）のために構築され、デイリースタンドアップやレトロスペクティブなどの儀式につながりました。対照的に、AIの適切な適用は、時間や日単位で測定される急速なサイクルにつながります。これには継続的なリアルタイムの検証とフィードバックメカニズムが必要であり、多くの伝統的な儀式の関連性が低くなります。AIが単純、中程度、困難なタスク間の境界を減少させる場合、労力の見積もり（例：ストーリーポイント）は重要でしょうか？速度のような指標は関連性があるのか、それともビジネス価値のような指標に置き換えるべきでしょうか？また、AIは計画、タスク分解、要件分析、設計技術の適用（例：ドメインモデリング）などの手動の実践を自動化する方向に進化しており、意図からコードへの移行に必要なフェーズの数を短縮しています。これらの新しい力学は、後付けではなく、第一原理思考に基づく再考を必要とします。私たちに必要なのは、より速い馬車ではなく自動車です。
2. 会話の方向を逆転させる
AI-DLCは、人間がAIと会話を開始してタスクを完了するのではなく、AIが人間との会話を開始し指示するという基本的な転換をもたらします。AIは高レベルの意図（例：新しいビジネス機能の実装）を実行可能なタスクに分解し、推奨事項を生成し、トレードオフを提案することでワークフローを駆動します。人間は承認者として機能し、重要な分岐点で選択肢を検証、選択、確認します。このAI駆動型アプローチにより、開発者は高価値の意思決定に集中でき、AIは計画、タスク分解、自動化を処理します。伝統的なダイナミクスを逆転させることで、AI-DLCは人間の関与が目的を持ち、監視、リスク軽減、戦略的整合性に集中することを保証し、速度と品質の両方を向上させます。これを説明する類推はGoogleマップです：人間は目的地（意図）を設定し、システムはステップバイステップの指示（AIのタスク分解と推奨事項）を提供します。途中で、人間は必要に応じて監視し、旅程を調整します。
3. 設計技術をコアに統合する
スクラムやカンバンなどのアジャイルフレームワークは、設計技術（例：ドメイン駆動設計）を範囲外とし、チームに独自の選択を推奨しています。これにより、全体的なソフトウェア品質の低下につながる重要な空白が生じました。米国だけでも、ソフトウェア品質の問題は2022年に2.41兆ドルのコストがかかると推定されています（調査）。設計技術を切り離すのではなく、AI-DLCはそれらを不可欠なコアとして持ちます。ドメイン駆動設計（DDD）、振る舞い駆動開発（BDD）、テスト駆動開発（TDD）をそれぞれ採用するチームのために、AI-DLCには異なるフレーバーが存在します。本論文ではAI-DLCのDDDフレーバーについて議論し、システムを独立した適切なサイズの境界コンテキストに分解するためにDDD原則を使用し、それらを並行して迅速に構築できるようにします。AIは計画とタスク分解の過程でこれらの技術を本質的に適用し、開発者には検証と調整のみを要求します。この統合は、時間単位または日単位の反復サイクルを可能にし、手動の重労働を排除しながらソフトウェア品質を維持する（「より良いシステムをより速く構築する」という標語）ための鍵です。
4. AI能力と整合させる
本論文はAIの将来の可能性について楽観的ですが、その現状について完全に現実的です。AI-DLCは、現在のAIが進歩しているものの、高レベルの意図を実行可能なコードに自律的に変換したり、解釈可能性と安全性を確保しながら人間の監視なしに独立して運用したりする信頼性はまだないことを認識しています。同時に、開発者が大部分の知的重労働を行い、AIが単に拡張を提供するAIアシストパラダイムは、開発におけるAIの潜在能力を完全に解放できません。AI-DLCは、人間の関与と現在のAIの能力と限界のバランスを取るAI駆動パラダイムを採用しています。この中で、開発者は検証、意思決定、監視の最終的な責任を保持します。このバランスにより、開発者の判断によって提供される重要な安全装置を損なうことなく、AIの強みが効果的に活用されることを保証します。
5. 複雑なシステム構築に対応する
AI-DLCは、継続的な機能適応性、高度なアーキテクチャの複雑性、多数のトレードオフ管理、スケーラビリティ、統合とカスタマイズの要件を要求するシステムの構築に対応しています。これらは、高度な設計技術、パターン、ベストプラクティスの適用を必要とし、通常は大規模および/または規制された組織内で複数のチームが結束して作業することを伴います。トレードオフ管理がほとんどまたは全く必要ない、非開発者ペルソナによって開発できるより単純なシステムは、AI-DLCの範囲外であり、ローコード/ノーコードアプローチに適しています。
6. 人間との共生を強化するものを維持する
手法を再考する際、人間の検証とリスク軽減に不可欠な既存の手法からの成果物とタッチポイントを維持します。例えば、ユーザーストーリーは、何を構築する必要があるかについての人間とAIの理解を整合させ、明確に定義された契約として機能します。再考された手法でもユーザーストーリーを維持します。もう一つの例は、AIが生成した計画とコードが組織のリスクフレームワークに準拠することを保証するリスク登録簿です。これらの維持された要素は、整合性や安全性を損なうことなく迅速な反復を可能にするために、リアルタイムでの使用に最適化されます。
7. 親しみやすさを通じた移行を促進する
新しい手法は広範な訓練を要求せず、既存の実践者は1日で方向付けを行い、実践を開始できるべきです。連想学習を通じた容易な採用をサポートするために、AI-DLCは古い手法の馴染みのある用語間の基本的な関係を保持しながら、現代化された用語を導入します。例えば、スクラムのスプリントは、構築と検証のための反復サイクルを表します。しかし、スプリントは通常、AI以前の時代では4〜6週間の長さです。AI-DLCでは、反復サイクルは継続的で、時間または日単位です。したがって、スプリントを意図的に改名する必要があります。AI-DLCはスプリントをボルト（Bolts）として再ブランド化し、前例のない速度を提供する迅速で集中的なサイクルを強調します。
8. 効率性のための責任を合理化する
AIのタスク分解と意思決定能力を活用することで、開発者はインフラストラクチャ、フロントエンド、バックエンド、DevOps、セキュリティなどの伝統的な専門化サイロを超越する力を得ます。この責任の収束により、複数の専門的な役割の必要性が減少し、開発プロセスが合理化されます。しかし、プロダクトオーナーと開発者はフレームワークに不可欠であり、監視、検証、戦略的意思決定のための重要な責任を保持します。これらの役割は、ビジネス目標との整合性を確保し、設計品質を維持し、リスク管理フレームワークへの準拠を維持し、自動化と人間の説明責任のバランスを保ちます。手法の定義では、第一原則に固執し、役割を最小限に保ち、追加の役割は重要に必要な場合にのみ導入します。
9. ステージを最小化し、フローを最大化する
自動化と責任の収束を通じて、AI-DLCは引き渡しと移行を最小化し、継続的な反復フローを可能にすることを目指しています。しかし、AIが生成したコードが硬直化（「クイックセメント」）せず、将来の反復のために適応可能であることを確保するために、人間の検証と意思決定は依然として重要です。これに対処するために、AI-DLCは重要な決定分岐点での人間の監視のために特別に設計された最小限だが十分な数のフェーズを組み込んでいます。これらの検証は、無駄な下流の努力を発生する前に特定し、除去する「損失関数」の形として機能します。
10. ハードワイヤードで独断的なSDLCワークフローなし
AI-DLCは、異なる開発経路（新システム開発、リファクタリング、欠陥修正、マイクロサービススケーリングなど）に対して独断的なワークフローを規定することを避けます。代わりに、AIが与えられた経路の意図に基づいてレベル1の計画を推奨する真のAIファーストアプローチを採用します。人間はAIとの対話的な対話を通じてこれらのAI生成計画を検証し調整し、このプロセスをレベル2（サブタスク）および後続の階層レベルを通じて継続します。タスク実行レベルでは、AIがタスクを実装し、人間は結果の検証と検証を通じて監視を維持します。この柔軟なアプローチにより、方法論は適応可能であり、重要な決定に対する人間の制御を維持しながらAI能力と共に進化することができます。
III. コアフレームワーク
このセクションでは、AI-DLCのコアフレームワークの概要を説明し、そのフェーズ、役割、ワークフロー、主要な成果物について詳述します。
1. 成果物
意図（Intent） はAI-DLCにおいて、ビジネス目標、機能、または技術的成果（例：パフォーマンススケーリング）など、達成すべきことをカプセル化した高レベルの目的声明です。これはAI駆動の分解の出発点として機能し、実行可能なタスクに分解され、人間の目標とAI生成の計画を整合させます。
ユニット（Unit） は、意図から派生した結束力のある自己完結型の作業要素を表し、測定可能な価値を提供するように特別に設計されています。例えば、ビジネスアイデアを実装するための意図は、DDDのサブドメインやスクラムのエピックに類似した、独立した機能ブロックを表すユニットに分解されるかもしれません。各ユニットは、その機能的範囲を明確に表現するタスク（この場合はユーザーストーリー）のセットを包含します。AI-DLCのコンテキストでは、意図をユニットに分解するプロセスはAIによって駆動され、開発者および/またはプロダクトオーナーが結果のユニットを検証し、ビジネスおよび技術的目標との整合性を確保するために洗練します。ユニットは疎結合であり、下流での自律的な開発と独立したデプロイメントを可能にします。
ボルト（Bolt） はAI-DLCにおける最小の反復であり、ユニットまたはユニット内のタスクセットの迅速な実装のために設計されています。ボルト（スクラムのスプリントに類似）は、週単位ではなく時間または日単位で測定される構築-検証サイクルで、集中的な焦点と高速度の配信を強調します。各ボルトは明確に定義された作業範囲（例：ユニット内のユーザーストーリーのコレクション）をカプセル化し、サポートするユニットの全体的な目標との整合性を維持しながら、段階的な進捗を可能にします。ユニットは1つ以上のボルトを通じて実行でき、それらは並行または順次実行される場合があります。AIはボルトを計画し、開発者/プロダクトオーナーがそれを検証します。
ドメイン設計 成果物は、インフラストラクチャコンポーネントとは独立してユニットのコアビジネスロジックをモデル化します。AI-DLCの最初のバージョンでは、AIはドメイン駆動設計の原則を使用して、集約、値オブジェクト、エンティティ、ドメインイベント、リポジトリ、ファクトリを含む戦略的および戦術的モデリング要素を作成します。論理設計 はドメイン設計を拡張し、適切なアーキテクチャ設計パターン（例：CQRS、サーキットブレーカーなど）を使用して非機能要件を満たすために変換します。AIは開発者による検証のためにアーキテクチャ決定記録（ADR）を作成します。論理設計仕様により、AIは適切なAWSサービスとコンストラクトを選択することで、十分にアーキテクチャ化された原則に準拠したコードとユニットテストを生成します。この段階で、AIエージェントはユニットテストを実行し、結果を分析し、開発者に修正の推奨事項を提供します。
デプロイメントユニット は、パッケージ化された実行可能コード（例：Kubernetes環境用のコンテナイメージ、AWS Lambdaなどのサーバーレス関数）、構成（例：Helmチャート）、およびインフラストラクチャコンポーネント（例：TerraformまたはCFNスタック）を包含する運用成果物であり、機能的受け入れ、セキュリティ、NFR、およびその他のリスクについてテストされています。AIはすべての関連テスト（機能テスト、静的および動的セキュリティテスト、負荷テストシナリオを含む）を生成します。テストシナリオとケースに関する人間の検証と調整の後、AIエージェントはテストスイートを実行し、結果を分析し、障害点をコード変更、構成、またはその他の依存関係と相関付けます。したがって、これらのユニットは機能的受け入れ、セキュリティコンプライアンス、非機能要件（NFR）の遵守、および運用リスクの軽減について厳格にテストされ、シームレスなデプロイメントの準備が整っていることを保証します。
2. フェーズと儀式
構想フェーズ は、意図をキャプチャし、それらを開発のためのユニットに変換することに焦点を当てています。このフェーズでは、協力的な要件の詳細化と分解の儀式である「モブエラボレーション」を使用します。これは、ファシリテーターが主導する共有画面を持つ単一の部屋で行われます。モブエラボレーション中、AIは意図をユーザーストーリー、受け入れ基準、ユニットに初期分解を提案する中心的な役割を果たし、ドメイン知識、および下流での迅速な並列実行のための疎結合と高凝集の原則を活用します。プロダクトオーナー、開発者、QA、およびその他の関連するステークホルダー（モブ）は、過剰設計または過小設計の部分を調整し、実世界の制約と整合させることで、これらのAI生成の成果物を協力的にレビューし洗練します。このフェーズの出力には、a）PRFAQ、b）ユーザーストーリー、c）非機能要件（NFR）の定義、d）リスクの説明（組織のリスク登録簿がある場合はそれと一致）、e）ビジネス意図に追跡可能な測定基準、f）ユニットを構築できる提案されたボルトを含む、明確に定義されたユニットとそれぞれのコンポーネントが含まれます。モブエラボレーションは、モブ内およびモブとAI間の深い整合性を達成しながら、数週間または数ヶ月の連続的な作業を数時間に凝縮します。
構築フェーズ は、構想フェーズで定義されたユニットをテスト済みの運用準備完了のデプロイメントユニットに変換する、タスクの反復的な実行を包含します。このフェーズは、AIが技術的考慮とは独立してビジネスロジックをモデル化するドメイン設計から、非機能要件と適切なクラウド設計パターンが適用される論理設計へと進行します。AIは論理設計から詳細なコードを生成し、コンポーネントを適切なAWSサービスにマッピングし、十分にアーキテクチャ化された原則に準拠します。このフェーズは、機能性、セキュリティ、および運用準備を確保するための自動テストで締めくくられます。開発者は各ステップでAI生成の出力を検証し、重要な決定を行うことに集中し、各反復での品質と適応性を確保します。ブラウンフィールド（既存のアプリケーション）シナリオでは、構築フェーズには最初にコードをセマンティックリッチなモデリング表現に昇格させ、AIへのコンテキストを簡潔かつ正確にすることが含まれます。提案されるモデリング表現は静的モデル（ドメインコンポーネント、責任、およびそれらの関係のみ）と動的モデル（コンポーネントが重要なユースケースを実現するためにどのように相互作用するか）です。
AIはこのフェーズ全体で重要な役割を果たし、各タスクでタスクとオプション（設計パターン、ユーザーエクスペリエンス、テストなど）を推奨します。AI-DLCは、モブエラボレーションと同様に、すべてのチームが単一の部屋に配置されることを推奨しています。チームは統合仕様（ドメインモデルステージから）を交換し、決定を行い、ボルトを提供します。AI-DLCはこれをモブ構築儀式と呼びます。
運用フェーズ はAI-DLCにおいて、運用効率のためにAIを活用したシステムのデプロイメント、観測可能性、およびメンテナンスに焦点を当てています。AIはメトリクス、ログ、トレースを含むテレメトリデータを積極的に分析し、パターンを検出し、異常を特定し、潜在的なSLA違反を予測し、積極的な問題解決を可能にします。さらに、AIは事前定義されたインシデントランブックと統合し、リソースのスケーリング、パフォーマンスチューニング、または障害分離などの実行可能な推奨事項を提案し、開発者によって承認された場合に解決策を実行します。開発者は検証者として機能し、AI生成のインサイトと提案されたアクションがSLAとコンプライアンス要件に整合していることを確保します。
3. ワークフロー
ビジネス意図（例：グリーンフィールド開発、ブラウンフィールド強化、近代化、または欠陥修正）が与えられると、AI-DLCはAIに意図を実装するためのワークフローを概説するレベル1の計画を生成するよう促すことから始まります。この計画は初期提案として機能し、その後、ビジネス目標とエンジニアリング制約との整合性を確保するために、人間によって透過的にレビュー、検証、洗練されます。AI-DLCの中核には、各ステップの成果物を次のステップのためのセマンティックリッチなコンテキストに変換するために、人間の監視を段階的に適用する原則があります。各ステップは戦略的決定点として機能し、人間の監視が損失関数のように機能し、エラーが下流に雪だるま式に増えるのを早期に捕捉して修正します。これは再帰的に繰り返されます。レベル1の計画の各ステップは、AIによってさらに細かい粒度の実行可能なサブタスクに分解され、再び人間の監視の下で、正確性と文脈的適切性を確保します。
生成されたすべての成果物（意図、ユーザーストーリー、ドメインモデル、またはテスト計画）は保持され、ライフサイクル全体でAIが参照する「コンテキストメモリ」として機能します。伝統的なSDLC手法と同様に、AI-DLCは本質的に反復的であり、継続的な洗練と適応を可能にします。さらに、すべての成果物はリンクされており、後方および前方のトレーサビリティ（例：ドメインモデル要素を特定のユーザーストーリーに接続する）を可能にし、AIが各段階で正確で最も関連性の高いコンテキストを取得することを保証します。プロセス全体を通じて、AIは戦略的計画、タスク分解、生成などを実行し、人間は監視と検証を提供します。
IV. AI-DLCの実践：グリーンフィールド開発
プロダクトオーナーが「製品のクロスセリングのためのレコメンデーションエンジンを開発する」などの高レベルの意図を表明することからプロセスを開始するシナリオを検討します。AIはこれを新しいアプリケーションを構築する意図として認識し、上記のセクションのワークフローステップのようなレベル1の計画を作成します。チームは検証、確認し、レベル1の計画のステージを追加/修正します。最終的なレベル1の計画により、AIは構想フェーズに進みます。付録Aの指示を参照して、AIとの対話方法と監視の提供方法を確認してください。
1. 構想フェーズ
以下の箇条書きは、モブエラボレーション儀式における主要な対話を概説しています。
a. AIは明確化のための質問をします（例：「主要なユーザーは誰ですか？このシステムが達成すべき主要なビジネス成果は何ですか？」）、目標の包括的な理解を確保し、元の意図の曖昧さを最小限に抑えます。
b. AIは明確化された意図をユーザーストーリー、非機能要件（NFR）、リスク説明に詳細化します。チームはこれらの成果物を検証し、監視を提供し、AIに必要な修正を行います。
c. AIは高凝集のストーリーをユニットにまとめます。例えば、「ユーザーデータ収集」、「レコメンデーションアルゴリズム選択」、「API統合」などです。
d. プロダクトオーナーはこれらの出力を検証し、必要に応じて調整してユニットを洗練します。例：プロダクトオーナーはユーザーデータ収集にプライバシーコンプライアンスの詳細が不足していることに気づき、要件を調整してGDPR固有の考慮事項を含めます。
e. AIはモジュールのPRFAQ（オプション）を生成し、ビジネス意図、機能、期待される利益を要約します。
f. 開発者とプロダクトオーナーはPRFAQと関連リスクを検証し、全体的な目標との整合性を確保します。
2. 構築フェーズ
以下の箇条書きは、モブプログラミングとモブテスティングの儀式に焦点を当てたこのフェーズの主要な活動を概説しています。
a. 開発者はAIとのセッションを確立します。AIは開発者に割り当てられたユニットから始めるよう促します。
b. AIはドメイン駆動設計の原則を使用して、割り当てられたユニットのコアビジネスロジックをモデル化します。例：「レコメンデーションアルゴリズム」ユニットでは、AIは製品、顧客、購入履歴などの関連エンティティとそれらの関係を特定します。
c. 開発者はドメインモデルをレビューし検証し、ビジネスロジックを洗練し、実世界のシナリオとの整合性を確保します（例：新規顧客の購入履歴の欠如をどのように処理するか）。
d. AIはドメインモデルを論理設計に変換し、スケーラビリティと耐障害性などのNFRを適用します。例：AIはアーキテクチャパターン（例：イベント駆動設計）とテクノロジー（例：サーバーレス計算のためのAWS Lambda）を推奨します。
e. 開発者はAIの推奨事項を評価し、トレードオフを承認し、必要に応じて追加の考慮事項を提案します。（例：スケーラビリティのためにLambdaを受け入れるが、より高速なクエリパフォーマンスのためにストレージをDynamoDBに上書きします）
f. AIは各ユニットの実行可能なコードを生成し、論理コンポーネントを特定のAWSサービスにマッピングします。
g. また、機能、セキュリティ、パフォーマンステストを自動生成します（例：「レコメンデーションアルゴリズム」ユニットでは、AIは協調フィルタリングを実装するコードを作成し、DynamoDBデータソースと統合します）
h. 開発者は生成されたコードとテストシナリオ/ケースをレビューし、品質とコンプライアンスを確保するために必要に応じて調整を行います。
テストと検証：
a. AIはすべてのテスト（機能、セキュリティ、パフォーマンス）を実行し、結果を分析し、問題を強調表示します。
b. 失敗したテストの修正を提案します。例：より良いパフォーマンスのためにクエリロジックを最適化します。
c. 開発者はAIの発見を検証し、修正を承認し、必要に応じてテストを再実行します。
3. 運用フェーズ
デプロイメント：
a. AIはモジュールをデプロイメントユニット（例：コンテナイメージ、サーバーレス関数）にパッケージ化します。
b. 開発者はデプロイメント構成を承認し、ステージングおよび本番環境へのロールアウトを開始します。
観測可能性とモニタリング：
a. AIはメトリクス、ログ、トレースを分析して異常を特定し、潜在的なSLA違反を予測します。例：AIはピーク使用時の遅延スパイクを検出し、増加したトラフィックを処理するためにレコメンデーションエンジンのスケーリングを提案します。
b. AIは運用上の問題に対するアクションを提案するためにプレイブックと統合します。APIの応答時間が低下した場合、AIはDynamoDBスループットの増加またはAPI Gatewayトラフィックの再バランスを推奨します。
c. 開発者はAIの推奨事項を検証し、緩和策を承認し、解決結果をモニタリングします。
V. AI-DLCの実践：ブラウンフィールド開発
ブラウンフィールドとは、新機能の追加、非機能要件の最適化、またはリファクタリングや欠陥修正を含む技術的負債の修正など、既存のシステムに変更を加えることを指します。このコンテキストでは、プロダクトマネージャーが既存のアプリケーションに新機能を追加する必要があるシナリオを検討します。
1. 構想フェーズ
ブラウンフィールドにおける構想フェーズの活動はグリーンフィールドと同じです。
2. 構築フェーズ
a. AIはコードをより高レベルのモデリング表現に昇格させます。モデルは静的モデル（コンポーネント、説明、責任、関係）と動的モデル（コンポーネントが最も重要なユースケースを実現するためにどのように相互作用するか）で構成されています。
b. 開発者はプロダクトマネージャーと協力して、AIによってリバースエンジニアリングされた静的および動的モデルをレビュー、検証、修正します。
c. これらの追加ステップにより、構築フェーズの残りはグリーンフィールドシナリオと同様です。
3. 運用フェーズ
ブラウンフィールドにおける運用フェーズの活動はグリーンフィールドと同じです。
VI. AI-DLCの導入
AI-DLCは既存のアジャイル手法から大きく逸脱せず、より容易な採用を主要な成果として設計されています。それでも、伝統的な手法を長期間実践している組織や、独自のAIネイティブ手法のバリエーションを発明するプロセスにある組織は、AI-DLCを採用するための特定の戦略を必要とします。以下の2つのアプローチがこれを容易にすると考えています。
a. 実践による学習 – AI-DLCは実際にはグループとして実践できる一連の儀式（モブエラボレーション、モブ構築など）です。文書や伝統的なトレーニングを通じて手法を学ぶのではなく、実践者が現在解決している複数の実世界のシナリオでAI-DLCガイドと共に儀式を実践することで学びます。AWSソリューションアーキテクトは、大規模組織での採用を超スケールするためのこのアプローチをパッケージ化したAI-DLCユニコーンジムというフィールドオファリングを作成しました。
b. 新しい開発者エクスペリエンスツールにAI-DLCを組み込む – 顧客はSDLCを横断し、開発者に統一されたエクスペリエンスを提供する独自のオーケストレーションツールを構築しています（例：CognizantのFlowSource、AspireのCodeSpell、HCLのAIForceなど）。これらのツールにAI-DLCを組み込むことで、大規模組織の開発者は重要な採用ドライブなしにシームレスにAI-DLCを実践できるようになります。
付録A
以下の指示はAI-DLCを実践するためにAIとの対話に使用できます。
セットアッププロンプト
今日はアプリケーションの構築に取り組みます。すべてのフロントエンドとバックエンドコンポーネントに対してプロジェクトフォルダを作成します。すべての文書はaidlc-docsフォルダに保存されます。セッション全体を通じて、先に作業を計画し、その計画のためのmdファイルを作成するよう依頼します。私が承認した後にのみ作業を進めることができます。これらの計画は常にaidlc-docs/plansフォルダに保存されます。md形式で多くの種類の文書を作成します。要件、機能変更文書はaidlc-docs/requirementsフォルダに保存されます。ユーザーストーリーはaidlc-docs/story-artifactsフォルダに保存する必要があります。アーキテクチャと設計文書はaidlc-docs/design-artifactsフォルダに保存する必要があります。すべての指示は順番にaidlc-docs/prompts.mdファイルに保存する必要があります。この指示の理解を確認してください。必要なフォルダとファイルがまだ存在しない場合は、保存用に作成してください。
構想
ユーザーストーリー
あなたの役割：あなたは専門のプロダクトマネージャーであり、以下のタスクセクションで言及されているシステムを開発するための契約となる明確に定義されたユーザーストーリーを作成する任務を負っています。先の作業を計画し、各ステップにチェックボックスを付けたmdファイル（user_stories_plan.md）にステップを書き込みます。ステップに私の明確化が必要な場合は、私の確認を得るためにステップにメモを追加してください。重要な決定を自分で行わないでください。計画を完了したら、私のレビューと承認を求めてください。私の承認後、同じ計画を一度に1ステップずつ実行することができます。各ステップを完了したら、計画のチェックボックスを完了としてマークしてください。
あなたのタスク：ここに記述されている高レベルの要件に対するユーザーストーリーを構築します << 製品説明を記述 >>
<<< 計画をレビューして変更した後 >>>
はい、<< mdファイル >>の計画が気に入りました。今、正確に同じ計画に従ってください。計画で指定されているように私と対話してください。各ステップを完了したら、計画のチェックボックスをマークしてください。
ユニット
あなたの役割：あなたは経験豊富なソフトウェアアーキテクトです。以下で言及されているタスクを開始する前に、計画を立て、計画の各ステップに対してチェックボックスを付けたunits_plan.mdファイルにステップを書き込んでください。ステップに私の明確化が必要な場合は、私と対話して確認を得るためにステップに追加してください。重要な決定を自分で行わないでください。計画を作成したら、私のレビューと承認を求めてください。私の承認後、同じ計画を一度に1ステップずつ実行することができます。各ステップを完了したら、計画のチェックボックスを完了としてマークしてください。
あなたのタスク：ユーザーストーリーmvp_user_stories.mdファイルを参照してください。ユーザーストーリーを独立して構築できる複数のユニットにグループ化します。各ユニットには、単一のチームによって構築できる高凝集のユーザーストーリーが含まれています。ユニットは互いに疎結合です。各ユニットについて、それぞれのユーザーストーリーと受け入れ基準をdesign/フォルダの個別のmdファイルに書き込みます。
<<< 計画をレビューして変更した後 >>>
承認します。進めてください。
構築
ドメイン（コンポーネント）モデル作成
あなたの役割：あなたは経験豊富なソフトウェアエンジニアです。以下で言及されているタスクを開始する前に、計画を立て、計画の各ステップに対してチェックボックスを付けたdesign/component_model.mdファイルにステップを書き込んでください。ステップに私の明確化が必要な場合は、私と対話して確認を得るためにステップに追加してください。重要な決定を自分で行わないでください。計画を作成したら、私のレビューと承認を求めてください。私の承認後、同じ計画を一度に1ステップずつ実行することができます。各ステップを完了したら、計画のチェックボックスを完了としてマークしてください。
あなたのタスク：design/seo_optimization_unit.mdファイルのユーザーストーリーを参照してください。すべてのユーザーストーリーを実装するためのコンポーネントモデルを設計します。このモデルには、すべてのコンポーネント、属性、振る舞い、およびコンポーネントがユーザーストーリーを実装するためにどのように相互作用するかが含まれる必要があります。まだコードを生成しないでください。コンポーネントモデルを/designフォルダの別のmdファイルに書き込みます。
<<< 計画をレビューして変更した後 >>>
計画を承認します。進めてください。各ステップを完了した後、計画ファイルのチェックボックスをマークしてください。
コード生成
あなたの役割：あなたは経験豊富なソフトウェアエンジニアです。以下で言及されているタスクを開始する前に、計画を立て、計画の各ステップに対してチェックボックスを付けたmdファイルにステップを書き込んでください。ステップに私の明確化が必要な場合は、私と対話して確認を得るためにステップに追加してください。重要な決定を自分で行わないでください。計画を作成したら、私のレビューと承認を求めてください。私の承認後、同じ計画を一度に1ステップずつ実行することができます。各ステップを完了したら、計画のチェックボックスを完了としてマークしてください。
タスク：search_discovery/nlp_component.mdファイルのコンポーネント設計を参照してください。設計にある自然言語処理（NLP）コンポーネントの非常にシンプルで直感的なPython実装を生成します。processQuery(queryText)メソッドには、クエリテキストからエンティティを抽出するためにamazon bedrock APIを使用します。クラスをそれぞれ個別のファイルに生成しますが、vocabMapperディレクトリに保持してください。
vocabMapperディレクトリで生成されたコードを参照してください。EntityExtractorコンポーネントがGenAIを呼び出すようにしたいです。現在の実装はローカルのvocabulary_repositoryを使用しています。エンティティ抽出と意図抽出の両方にGenAIをどのように活用できるか分析し、計画を提供してください。
アーキテクチャ
あなたの役割：あなたは経験豊富なクラウドアーキテクトです。以下で言及されているタスクを開始する前に、計画を立て、計画の各ステップに対してチェックボックスを付けたdeployment_plan.mdファイルにステップを書き込んでください。ステップに私の明確化が必要な場合は、私と対話して確認を得るためにステップに追加してください。重要な決定を自分で行わないでください。計画を作成したら、私のレビューと承認を求めてください。私の承認後、同じ計画を一度に1ステップずつ実行することができます。各ステップを完了したら、計画のチェックボックスを完了としてマークしてください。
タスク：コンポーネント設計モデル：design/core_component_model.md、UNITS/フォルダのユニット、ARCHITECTURE/フォルダのクラウドアーキテクチャ、BACKEND/フォルダのバックエンドコードを参照してください。以下を完了してください：
- [CloudFormation、CDK、Terraform]を使用してAWSクラウドにバックエンドをデプロイするためのエンドツーエンドの計画を生成します。
- デプロイメントの前提条件があれば、すべて文書化します。
計画を承認した後： - クリーンでシンプル、説明可能なコーディングのベストプラクティスに従ってください。
- すべての出力コードはDEPLOYMENT/フォルダに入れます。
- 検証計画を作成し、検証レポートを生成することで、生成されたコードが意図したとおりに機能することを検証します。
- 検証レポートをレビューし、特定されたすべての問題を修正し、検証レポートを更新します。
IaC/Rest APIの構築
あなたの役割：あなたは経験豊富なソフトウェアエンジニアです。以下で言及されているタスクを開始する前に、計画を立て、計画の各ステップに対してチェックボックスを付けたmdファイルにステップを書き込んでください。ステップに私の明確化が必要な場合は、私と対話して確認を得るためにステップに追加してください。重要な決定を自分で行わないでください。計画を作成したら、私のレビューと承認を求めてください。私の承認後、同じ計画を一度に1ステップずつ実行することができます。各ステップを完了したら、計画のチェックボックスを完了としてマークしてください。
タスク：construction/<>/フォルダのservices.pyを参照してください。そこにある各サービスのpython flask apiを作成します。
Discussion