Open24日前にコメント追加2
AI主導型開発ライフサイクル (AI-DLC）について。amazonのkiroなどのAI前提となる設計思想

参考資料

 概要AI主導型開発ライフサイクル (AI-DLC) は、ソフトウェア開発プロセスを根本から再構築し、AIの能力を最大限に統合するために設計された新しいアプローチです。AI-DLCは、既存のソフトウェア開発手法をAIの速度、柔軟性、および高度な機能と完全に連携させることを目指しています。

 AI主導型開発ライフサイクル (AI-DLC) 概要AI-DLCは、開発者がより複雑な問題解決に集中できるように、低レベルの定型的なタスクを抽象化するというソフトウェアエンジニアリングの継続的な探求から生まれました。大規模言語モデル (LLM) の登場は、コード生成、バグ検出、テスト生成などのタスクに自然言語対話を導入することで、ソフトウェアの作成方法に革命をもたらしました。これにより、AIが特定のタスクを強化する「AIアシスト時代」が到来しました。
しかし、AIの進化に伴い、その応用範囲は要件の精緻化、計画、タスクの分解、設計、開発者とのリアルタイムコラボレーションにまで拡大しています。この変化は、AIが開発プロセスを積極的に調整する「AI主導時代」の始まりを告げるものです。既存のソフトウェア開発手法は、人間主導の長期プロセス向けに設計されており、AIの能力とは完全に一致していません。AIを既存の手法に後付けすることは、その潜在能力を制限し、時代遅れの非効率性を助長するため、SDLC手法を再構築する必要があります。AI-DLCは、AIを中核的な協力者と見なし、ワークフロー、役割、イテレーションを連携させ、より迅速な意思決定、シームレスなタスク実行、継続的な適応性を可能にするように設計されています。

 主要原則AI-DLCの設計の根底には以下の原則があります：
再構築 vs. 後付け (Reimagine Rather Than Retrofit)
AI-DLCは、既存のSDLCやアジャイル（例：スクラム）のような開発手法を維持し、そこにAIを後付けするのではなく、開発手法そのものを再構築することを選択します。
従来の開発手法は、数週間から数ヶ月という長いイテレーション期間向けに構築されており、デイリースタンドアップやレトロスペクティブのような儀式を生み出しました。
対照的に、AIの適切な適用は、数時間から数日という迅速なサイクルをもたらします。これにより、従来の多くの儀式は関連性が薄くなります。例えば、AIが簡単なタスク、中程度のタスク、難しいタスクの境界を曖昧にする場合、工数見積もり（例：ストーリーポイント）はそれほど重要ではなくなります。ベロシティのようなメトリクスも、ビジネス価値に置き換えるべきかもしれません。
AIは、計画、タスク分解、要件分析、設計技法の適用（例：ドメインモデリング）などの手動プラクティスを自動化し、意図からコードへの移行に必要なフェーズ数を短縮しています。
これらの新しいダイナミクスは、後付けではなく、第一原理思考に基づく再構築を必要とします。
会話の方向性の逆転 (Reverse the Conversation Direction)
AI-DLCは、人間がAIにタスクの完了を指示するのではなく、AIが人間との会話を開始し、指示を出すという根本的な転換を導入します。
AIは、高レベルの意図（例：新しいビジネス機能の実装）を実用的なタスクに分解し、推奨事項を生成し、トレードオフを提案することで、ワークフローを推進します。
人間は承認者として、重要な分岐点で選択肢を検証し、決定を確定します。このAI主導型のアプローチにより、開発者は高価値な意思決定に集中でき、AIが計画、タスク分解、自動化を処理します。
従来のダイナミクスを逆転させることで、AI-DLCは人間の関与が目的意識的であり、監視、リスク軽減、戦略的調整に集中することを保証し、速度と品質の両方を向上させます。
Googleマップを例にとると、人間が目的地（意図）を設定し、システムが段階的な指示（AIのタスク分解と推奨事項）を提供し、その過程で人間は監視を維持し、必要に応じて旅を調整します。
設計技法の統合 (Integration of Design Techniques into the Core)
スクラムやカンバンなどのアジャイルフレームワークは、ドメイン駆動設計（DDD）などの設計技法を範囲外とし、チームに独自の選択を推奨してきました。これにより、ソフトウェア品質全体に影響を与える重要な空白が生じました。
AI-DLCは、設計技法を分離するのではなく、不可欠な中核として統合します。
AI-DLCには、**ドメイン駆動設計（DDD）、ふるまい駆動開発（BDD）、テスト駆動開発（TDD）**にそれぞれ従う様々なフレーバーがあります。この文書では、DDDの原則を使用してシステムを独立した適切なサイズの境界コンテキストに分解し、並行して迅速に構築できるDDDフレーバーのAI-DLCについて説明します。
AIは、計画とタスク分解中にこれらの技法を本質的に適用し、開発者は検証と調整のみを行います。この統合は、手作業を排除し、ソフトウェア品質を維持しながら、時間単位または日単位のイテレーションサイクルを可能にする鍵となります。
AI機能との整合性 (Align with AI Capability)
AI-DLCは、現在のAIが進歩しているものの、高レベルの意図を自律的に実行可能なコードに変換したり、人間による監視なしに独立して運用したりすることがまだ信頼できるレベルではないことを認識しています。
同時に、開発者が知的重労働の大部分を行い、AIが単に強化を提供する「AIアシスト型パラダイム」では、AIの潜在能力を十分に引き出すことができません。
AI-DLCは、人間の関与と現在のAIの能力および限界とのバランスをとる「AI主導型パラダイム」を採用しています。これにより、開発者は検証、意思決定、監視に対する最終的な責任を保持します。
複雑なシステム構築への対応 (Cater to Building Complex Systems)
AI-DLCは、継続的な機能適応性、高いアーキテクチャの複雑性、多数のトレードオフ管理、スケーラビリティ、統合およびカスタマイズの要件を必要とするシステムの構築に対応します。
これらのシステムは、高度な設計技法、パターン、ベストプラクティスの適用を必要とし、通常、大規模な、または規制された組織内で複数のチームが連携して作業します。
開発者以外のペルソナによって開発でき、トレードオフ管理がほとんどまたはまったくないシンプルなシステムは、AI-DLCの範囲外であり、ローコード/ノーコードアプローチに適しています。
人間との共生を強化する要素の保持 (Retain What Enhances Human Symbiosis)
AI-DLCは、既存の手法から、人間の検証とリスク軽減に不可欠な成果物とタッチポイントを保持します。
例えば、ユーザー・ストーリーは、人間とAIの「何を構築する必要があるか」の理解を一致させ、明確な契約として機能します。再構築された手法でも、ユーザー・ストーリーは保持されます。
もう一つの例は、AIが生成する計画とコードが組織のリスクフレームワークに準拠していることを保証する「リスクレジスター」です。
これらの保持された要素は、リアルタイム使用に最適化され、整合性や安全性を損なうことなく迅速なイテレーションを可能にします。
親しみやすさを通じた移行の促進 (Facilitate Transition Through Familiarity)
新しい手法は、広範なトレーニングを必要とせず、既存のプラクティショナーが1日で順応して実践を開始できることを目指します。
連想学習を通じて導入を容易にするため、AI-DLCは、古い手法で馴染みのある用語間の根底にある関係性を維持しつつ、現代的な用語を導入します。
例えば、スクラムの「スプリント」は、構築と検証の反復サイクルを表しますが、AI以前の時代では通常4〜6週間でした。AI-DLCでは、イテレーションサイクルは継続的であり、時間単位または日単位で測定されます。
そのため、AI-DLCはスプリントを意図的に**「ボルト (Bolt)」と改称**し、前例のない速度を実現する迅速で集中的なサイクルを強調しています。
効率のための責任の合理化 (Streamline Responsibilities for Efficiency)
AIのタスク分解と意思決定能力を活用することで、開発者は、インフラストラクチャ、フロントエンド、バックエンド、DevOps、セキュリティなどの従来の専門分野のサイロを超越できるようになります。
この責任の収束により、複数の専門的な役割の必要性が減り、開発プロセスが合理化されます。
しかし、プロダクトオーナーと開発者はフレームワークにとって不可欠な存在であり、監視、検証、戦略的意思決定に対する重要な責任を保持します。これらの役割は、ビジネス目標との整合性を確保し、設計品質を維持し、リスク管理フレームワークへの準拠を維持し、自動化と人間の説明責任のバランスを保ちます。
段階の最小化、フローの最大化 (Minimise Stages, Maximise Flow)
AI-DLCは、自動化と責任の収束を通じて、ハンドオフと移行を最小限に抑え、継続的な反復フローを可能にすることを目指します。
ただし、人間による検証と意思決定は、AIが生成したコードが「すぐに固まるセメント」のように硬直せず、将来のイテレーションのために適応性を保つために不可欠です。
これに対処するため、AI-DLCは、重要な意思決定の分岐点での人間の監視のために特別に設計された、最小限で十分な数のフェーズを組み込みます。これらの検証は、浪費的な下流の努力が発生する前に特定し、排除する「損失関数」として機能します。
固定的なSDLCワークフローなし (No Hard-Wired, Opinionated SDLC Workflows)
AI-DLCは、新しいシステム開発、リファクタリング、欠陥修正、マイクロサービスのスケーリングなど、さまざまな開発パスに対して固定的なワークフローを処方することを避けます。
代わりに、AIが与えられた意図に基づいてレベル1の計画を推奨する真に「AIファースト」なアプローチを採用します。
人間はAIとの対話を通じて、AIが生成した計画を検証し、調整し、このプロセスをレベル2（サブタスク）およびそれ以降の階層レベルで継続します。
タスク実行レベルでは、AIがタスクを実装し、人間は成果物の検証と妥当性確認を通じて監視を維持します。この柔軟なアプローチにより、人間が重要な決定を制御しながら、AIの能力とともに方法論が適応し、進化することができます。

 コアフレームワークAI-DLCのコアフレームワークは、そのフェーズ、役割、ワークフロー、および主要な成果物を詳細に記述しています。

 成果物 (Artefacts)インテント (Intent)
インテントは、ビジネス目標、機能、技術的成果（例：パフォーマンススケーリング）など、達成すべき目的を要約する高レベルのステートメントです。
これは、AI駆動型分解の出発点となり、人間の目標とAIが生成する計画を一致させます。
ユニット (Unit)
ユニットは、インテントから派生したまとまりのある自己完結型の作業要素であり、測定可能な価値を提供するように設計されています。
例えば、ビジネスアイデアを実装するというインテントは、DDDのサブドメインやスクラムのエピックに類似した、独立した機能ブロックを表すユニットに分解されることがあります。
各ユニットには、一連のタスク（この場合はその機能範囲を明確にするユーザー・ストーリー）が含まれます。
AI-DLCでは、インテントをユニットに分解するプロセスはAIによって駆動され、開発者やプロダクトオーナーは、ビジネス目標や技術目標との整合性を確保するために、生成されたユニットを検証し、洗練させます。
ユニットは疎結合されており、自律的な開発と独立した下流のデプロイメントを可能にします。
ボルト (Bolt)
ボルトは、AI-DLCにおける最小のイテレーションであり、ユニットまたはユニット内のタスクセットの迅速な実装のために設計されています。
スクラムの「スプリント」に類似しており、数週間ではなく数時間または数日で測定されるビルド・検証サイクルを伴う、集中的なフォーカスと高速配信を強調します。
各ボルトは、明確に定義された作業範囲（例：ユニット内のユーザー・ストーリーの集合）をカプセル化し、サポートするユニットの全体目標との整合性を維持しながら、段階的な進捗を可能にします。
1つのユニットは、1つ以上のボルトを通じて実行でき、これらは並行して、または順次実行される場合があります。AIがボルトを計画し、開発者/プロダクトオーナーがそれを検証します。
ドメイン設計 (Domain Design)
この成果物は、インフラストラクチャコンポーネントとは独立して、ユニットのコアビジネスロジックをモデル化します。
AI-DLCの最初のバージョンでは、AIはドメイン駆動設計の原則を使用して、集約、値オブジェクト、エンティティ、ドメインイベント、リポジトリ、ファクトリなどの戦略的および戦術的モデリング要素を作成します。
論理設計 (Logical Design)
論理設計は、ドメイン設計を拡張し、非機能要件を満たすために適切なアーキテクチャ設計パターン（例：CQRS、サーキットブレーカーなど）を使用して変換します。
AIは、開発者による検証のためのアーキテクチャ決定記録（ADR）を作成します。
論理設計仕様に基づいて、AIはコードとユニットテストを生成し、適切なAWSサービスと構成を選択することで、「よく設計された」原則への準拠を保証します。この段階で、AIエージェントはユニットテストを実行し、結果を分析し、開発者に修正の推奨事項を提供します。
デプロイメントユニット (Deployment Units)
デプロイメントユニットは、機能的な受容、セキュリティ、非機能要件（NFR）、その他のリスクについてテストされたパッケージ化された実行可能コード（例：Kubernetes環境のコンテナイメージ、AWS Lambdaなどのサーバーレス関数）、構成（例：Helmチャート）、インフラストラクチャコンポーネント（例：TerraformまたはCFNスタック）を包含する運用成果物です。
AIは、機能テスト、静的および動的セキュリティテスト、ロードテストシナリオなど、関連するすべてのテストを生成します。
人間がテストシナリオとケースを検証および調整した後、AIエージェントはテストスイートを実行し、結果を分析し、障害点とコード変更、構成、またはその他の依存関係を関連付けます。
したがって、これらのユニットは、機能的な受容、セキュリティコンプライアンス、NFRへの準拠、運用リスクの軽減のために厳密にテストされ、シームレスなデプロイメントの準備が保証されます。

 フェーズと儀式 (Phases & Rituals)AI-DLCは、以下の主要なフェーズと儀式で構成されます。
インセプションフェーズ (Inception Phase)
インセプションフェーズは、インテントを捉え、それを開発用のユニットに変換することに重点を置いています。
このフェーズでは、「モブ・エラボレーション (Mob Elaboration)」という共同要件精緻化および分解の儀式を使用します。
これは、ファシリテーターが主導する共有スクリーンを持つ単一の部屋で行われます。
モブ・エラボレーション中、AIは、ドメイン知識と、下流の迅速な並行実行のための疎結合と高凝集の原則を活用して、インテントをユーザー・ストーリー、受け入れ基準、ユニットに最初に分解する上で中心的な役割を果たします。
プロダクトオーナー、開発者、QA、およびその他の関連するステークホルダー（モブ）は、AIが生成した成果物を共同でレビューおよび洗練し、不足している部分や過剰な部分を調整し、実際の制約と整合させます。
このフェーズの成果物には、a) PRFAQ、b) ユーザー・ストーリー、c) 非機能要件（NFR）の定義、d) リスクの説明（組織のリスクレジスターと一致する）、e) ビジネス意図に遡ることができる測定基準、f) ユニットを構築するための提案されたボルトを含む、適切に定義されたユニットとそのそれぞれのコンポーネントが含まれます。
モブ・エラボレーションは、数週間または数ヶ月の連続した作業を数時間に凝縮し、モブ内およびモブとAIの間の深い整合性を実現します。
コンストラクションフェーズ (Construction Phase)
このフェーズは、インセプションフェーズで定義されたユニットを、テスト済みで運用準備の整ったデプロイメントユニットに変換するタスクの反復実行を包含します。
このフェーズは、AIがビジネスロジックを技術的考慮事項とは独立してモデル化するドメイン設計から、非機能要件と適切なクラウド設計パターンが適用される論理設計へと進行します。
AIは、論理設計から詳細なコードを生成し、コンポーネントを適切なAWSサービスにマッピングし、適切に設計された原則に準拠させます。
このフェーズは、機能性、セキュリティ、運用準備が整っていることを確認するための自動テストで終了します。
開発者は、各ステップでAIが生成した出力を検証し、重要な決定を下すことに集中し、各イテレーションでの品質と適応性を保証します。
ブラウンフィールド（既存のアプリケーション）シナリオでは、コンストラクションフェーズは、まずコードをセマンティックリッチなモデリング表現に昇格させ、AIへのコンテキストが簡潔で正確になるようにします。提案されるモデリング表現は、静的モデル（ドメインコンポーネント、責任、それらの関係のみ）と動的モデル（コンポーネントがどのように相互作用して重要なユースケースを実現するか）です。
このフェーズ全体を通して、AIは中心的な役割を果たし、各タスクでタスクを推奨し、オプション（設計パターン、ユーザーエクスペリエンス、テストなど）を提供します。AI-DLCは、すべてのチームがモブ・エラボレーションと同様に、単一の部屋に集まってこれを実施することを推奨しています。チームは統合仕様（ドメインモデル段階から）を交換し、決定を下し、ボルトを配信します。AI-DLCはこれを**モブ・コンストラクション (mob-construction)**儀式と呼びます。
オペレーションフェーズ (Operations Phase)
AI-DLCのオペレーションフェーズは、運用効率のためにAIを活用し、システムのデプロイメント、可観測性、メンテナンスに重点を置いています。
AIは、メトリクス、ログ、トレースなどのテレメトリーデータを積極的に分析し、パターンを検出し、異常を特定し、潜在的なSLA違反を予測することで、プロアクティブな問題解決を可能にします。
さらに、AIは、事前に定義されたインシデントランブックと統合し、リソースのスケーリング、パフォーマンスチューニング、フォールト分離などの実行可能な推奨事項を提案し、開発者によって承認された場合に解決策を実行します。
開発者はバリデーターとして機能し、AIが生成したインサイトと提案されたアクションがSLAとコンプライアンス要件に合致していることを確認します。

 ワークフロー (The Workflow)AI-DLCは、ビジネス意図（例：グリーンフィールド開発、ブラウンフィールド拡張、モダナイゼーション、欠陥修正）が与えられると、AIに意図を実装するためのレベル1計画の生成を促すことから始まります。この計画は初期提案として機能し、ビジネス目標とエンジニアリング制約との整合性を確保するために、人間によって透過的にレビュー、検証、洗練されます。
AI-DLCの核となるのは、各ステップの成果物を段階的に豊かにし、次のステップのためのセマンティックな豊富なコンテキストに変換するために人間による監視を適用する原則です。各ステップは、人間による監視が「損失関数」のように機能し、エラーが下流で雪だるま式に増える前に早期に捕捉・修正する戦略的な決定点として機能します。このプロセスは再帰的に繰り返されます。レベル1計画の各ステップは、AIによってさらに細かい、実行可能なサブタスクに分解され、正確性と文脈の適切性を確保するために再び人間による監視の下で行われます。
生成されたすべての成果物（インテント、ユーザー・ストーリー、ドメインモデル、テスト計画など）は永続化され、AIがライフサイクル全体で参照する「コンテキストメモリ」として機能します。従来のSDLC手法と同様に、AI-DLCは本質的に反復的であり、継続的な洗練と適応を可能にします。さらに、すべての成果物はリンクされており、後方および前方への追跡可能性（例：ドメインモデル要素と特定のユーザー・ストーリーの接続）を可能にし、AIがすべての段階で正確で最も関連性の高いコンテキストを取得することを保証します。プロセス全体を通して、AIは戦略的計画、タスク分解、生成などを行い、人間が監視と検証を提供します。

 AI-DLCの実践例AI-DLCがどのように機能するかを理解するために、新規アプリケーション開発（グリーンフィールド開発）と既存アプリケーションへの変更（ブラウンフィールド開発）のシナリオを見てみましょう。

 グリーンフィールド開発 (Green-Field Development)プロダクトオーナーが「クロスセル製品のレコメンデーションエンジンを開発する」という高レベルのインテントを明確にするところからプロセスが始まります。AIはこれを新しいアプリケーションを構築する意図として認識し、前述のワークフローセクションのようなレベル1計画を生成します。チームはレベル1計画の段階を検証、確認、追加/修正します。最終決定されたレベル1計画に基づいて、AIはインセプションフェーズに進みます。
インセプションフェーズ
AIが「主なユーザーは誰ですか？どのような主要なビジネス成果を達成すべきですか？」などの明確化の質問を行い、目標の包括的な理解を確保し、元の意図の曖昧さを最小限に抑えます。
AIは明確化された意図をユーザー・ストーリー、非機能要件（NFR）、リスク記述に精緻化します。チームはこれらの成果物を検証し、監視を提供し、AIに必要な修正を行います。
AIは、凝集度の高いストーリーをユニットに編成します（例：「ユーザーデータ収集」、「レコメンデーションアルゴリズム選択」、「API統合」）。
プロダクトオーナーはこれらの出力を検証し、必要に応じて調整してユニットを洗練させます（例：ユーザーデータ収集にプライバシーコンプライアンスの詳細が不足していることに気づき、GDPR固有の考慮事項を含めるように要件を調整します）。
AIは、ビジネス意図、機能、および期待されるメリットを要約するPRFAQをモジュール用に生成します（オプション）。
開発者とプロダクトオーナーはPRFAQと関連するリスクを検証し、全体目標との整合性を確保します。
コンストラクションフェーズ
開発者がAIとのセッションを確立し、AIは開発者に割り当てられたユニットから開始するように促します。
AIは、ドメイン駆動設計の原則を使用して、割り当てられたユニットのコアビジネスロジックをモデル化します（例：「レコメンデーションアルゴリズム」ユニットの場合、AIは製品、顧客、購入履歴などの関連エンティティとその関係を特定します）。
開発者はドメインモデルをレビューおよび検証し、ビジネスロジックを洗練させ、実世界のシナリオ（例：新規顧客の購入履歴がない場合の処理方法）との整合性を確保します。
AIはドメインモデルを論理設計に変換し、スケーラビリティやフォールトトレランスなどのNFRを適用します（例：AIはアーキテクチャパターン（例：イベント駆動型設計）と技術（例：サーバーレスコンピューティングのためのAWS Lambda）を推奨します）。
開発者はAIの推奨事項を評価し、トレードオフを承認し、必要に応じて追加の考慮事項を提案します（例：スケーラビリティのためにLambdaを受け入れますが、より高速なクエリパフォーマンスのためにストレージをDynamoDBにオーバーライドします）。
AIは各ユニットの実行可能なコードを生成し、論理コンポーネントを特定のAWSサービスにマッピングします。
また、機能、セキュリティ、パフォーマンステストを自動生成します（例：「レコメンデーションアルゴリズム」ユニットの場合、AIは協調フィルタリングを実装するコードを作成し、それをDynamoDBデータソースと統合します）。
開発者は生成されたコードとテストシナリオ/ケースをレビューし、品質とコンプライアンスを確保するために必要に応じて調整します。

テストと検証:
AIはすべてのテスト（機能、セキュリティ、パフォーマンス）を実行し、結果を分析し、問題を強調表示します。
失敗したテストの修正を提案します（例：パフォーマンス向上のためのクエリロジックの最適化）。
開発者はAIの発見を検証し、修正を承認し、必要に応じてテストを再実行します。

オペレーションフェーズ

デプロイメント:
AIはモジュールをデプロイメントユニット（例：コンテナイメージ、サーバーレス関数）にパッケージ化します。
開発者はデプロイメント構成を承認し、ステージングおよび本番環境への展開を開始します。


可観測性とモニタリング:
AIはメトリクス、ログ、トレースを分析して異常を特定し、潜在的なSLA違反を予測します（例：AIはピーク使用時にレイテンシースパイクを検出し、増加したトラフィックを処理するためにレコメンデーションエンジンをスケーリングすることを提案します）。
AIはプレイブックと統合して運用上の問題に対するアクションを提案します（API応答時間が低下した場合、AIはDynamoDBのスループットを増加させるか、API Gatewayトラフィックを再バランスすることを推奨します）。
開発者はAIの推奨事項を検証し、緩和策を承認し、解決策の結果を監視します。


 ブラウンフィールド開発 (Brown-Field Development)ブラウンフィールドとは、新しい機能の追加、非機能要件の最適化、リファクタリングや欠陥修正を含む技術的負債の修正など、既存のシステムに変更を加えることを指します。このコンテキストでは、プロダクトマネージャーが既存のアプリケーションに新機能を追加する必要があるシナリオを検証します。

インセプションフェーズ: ブラウンフィールドのインセプションフェーズ活動は、グリーンフィールドの場合と同じです。

コンストラクションフェーズ:
AIはコードをより高レベルのモデリング表現に昇格させます。モデルは、静的モデル（コンポーネント、説明、責任、関係）と動的モデル（コンポーネントが最も重要なユースケースを実現するためにどのように相互作用するか）で構成されます。
開発者はプロダクトマネージャーと協力して、AIによってリバースエンジニアリングされた静的モデルと動的モデルをレビュー、検証、修正します。
これらの追加ステップを除けば、残りのコンストラクションフェーズはグリーンフィールドのシナリオと同様です。


オペレーションフェーズ: ブラウンフィールドのオペレーションフェーズ活動は、グリーンフィールドの場合と同じです。

 AI-DLCの採用AI-DLCは既存のアジャイル手法から大きく逸脱しておらず、容易な導入が主要な成果として設計されています。しかし、伝統的な手法を長く実践している組織や、独自のAIネイティブ手法を考案中の組織には、AI-DLCを導入するための特定の戦略が必要です。
AI-DLCの導入を容易にするために、以下の2つのアプローチが提案されています。
実践による学習 (Learning by Practicing)
AI-DLCは、グループで実践できる一連の儀式（モブ・エラボレーション、モブ・コンストラクションなど）です。
ドキュメントや従来のトレーニングを通じて手法を学習する代わりに、プラクティショナーは、現在プラクティショナーによって解決されている複数の実世界のシナリオでAI-DLCガイドと一緒に儀式を実践します。
AWSソリューションアーキテクトは、大規模組織での導入をハイパースケーリングするためのアプローチをパッケージ化したAI-DLCユニコーンジムというフィールドオファリングを作成しています。
新しい開発者エクスペリエンスツールへの組み込み (Embedding in New Developer Experience Tooling)
顧客は、SDLC全体を横断し、開発者に統合されたエクスペリエンスを提供する独自のオーケストレーションツールを構築しています（例：CognizantのFlowSource、AspireのCodeSpell、HCLのAIForceなど）。
AI-DLCをこれらのツールに組み込むことで、大規模組織の開発者は、大規模な導入推進を必要とせずにAI-DLCをシームレスに実践できるようになります。

 付録提供された情報には、AI-DLCの実践にAIと対話するために使用できるプロンプトの例が記載されています。これらのプロンプトは、「セットアッププロンプト」、「インセプション」フェーズの「ユーザー・ストーリー」と「ユニット」、および「コンストラクション」フェーズの「ドメイン（コンポーネント）モデル作成」、「コード生成」、「アーキテクチャ」、「IaC/Rest APIの構築」などの具体的なタスクにおいて、AIに指示を出し、その出力を検証する方法を示しています。これらのプロンプトは、AI-DLCにおけるAIと人間のコラボレーションの具体的な手順と、人間の承認と監視の重要性を強調しています。