AI-DLCの進め方・実践手順とは？

AI-DLCでは、目的を渡した後の質問や作業計画もAIに提案させます。人は業務と技術の判断を加え、確認した内容を次の作業へ引き継ぎます。

AI-DLCは、AWSが提唱したAI駆動開発ライフサイクル（AI-Driven Development Life Cycle）です。必要な機能や動作の条件を「要件」と呼び、要件の整理から設計・実装・検証・運用までをAIと進めます。

AWS原典の区切りは「開始・構築・運用」の3フェーズです。本記事の5手順は、実際にすることが分かるように整理したものです。手順1・2が開始、手順3と手順4の検証が構築、利用開始後の手順5が運用に対応します。手順4は構築から運用への引き継ぎも含みます。

「承認してください」と言われても、根拠が分からなければ決められません。AIには参照した資料、選択肢、それぞれの影響を示させます。業務担当者は現場の事実を、技術者は実現方法や検証結果を確かめます。

原典が主に想定するのは、複数のシステムやチームが関わる複雑な開発です。新しいサービスの開発、既存システムの刷新、部門をまたぐデータ連携でも、この進め方を適用できます。規模を広げるほど、分担と連携の約束が大切になります。

以降は、複数拠点の受注・在庫・出荷をつなぐ開発を、説明用の架空例として使います。営業が出荷状況を画面で確認し、倉庫への電話を減らすことが最初の目標です。最終的には、拠点をまたぐ在庫や出荷の連携へ広げます。

準備するのは、判断を担う人、現在の業務とシステムが分かる資料、AIで開発できる環境です。業務担当者は実現したいことと現場の情報を持ち寄り、技術担当者と開発の始め方を決めます。

• 業務の担当：目的、現場の決まり、例外、完成の条件を決めます。
• 技術の担当：設計、コード、連携、AIの操作権限を確認します。
• 品質・運用の担当：検証、利用開始、監視、障害対応を受け持ちます。兼務する場合も、誰が判断するかを決めます。

業務担当者は、現在の仕事の流れと、実際に困った注文の記録を用意します。技術担当者は、既存システムの仕様・プログラム（コード）や接続先を調べます。きれいに整った説明資料だけでなく、例外が起きたときの手順や、現場で補っている作業も材料にします。

資料は、開発用AIが参照できる場所へ整理します。全体で守るルールと、今回の業務に必要な資料を分け、どの作業で何を使うかを指定します。AIへ渡せるデータ、利用料の予算、許可する操作は技術担当者と決めます。

技術担当者は、開発用AIがAI-DLCの手順を参照できる環境を整えます。その選択肢の一つが、AWS Labsの公開手順「AI-DLC Workflows 2.0」です。導入・設定・診断は導入・開始ガイドに沿って行います。開始コマンドの例は記事末尾の補足にまとめています。

環境が整ったら、AIに開発の目的と資料を渡し、現状の整理と不足情報の質問を依頼します。その回答をもとに、どの順序で開発し、利用を始めるかを計画させます。利用者が実際の仕事で使う環境を「本番」と呼びます。

AIから質問が返ってきたら、分かる範囲を答え、判断が必要な点は担当者へ回します。ここから、漠然とした希望を「何ができれば完成か」という条件へ変えていきます。

目的と現状の資料をAIへ渡し、必要な機能と「どうなれば合格か」を提案させます。人は現場の事実を確かめ、最初に作る範囲と完成の条件を決めます。

実現したい目的をIntent（インテント）と呼びます。AIには「目的・対象の仕事・守る条件を整理し、不明点を質問してください」と依頼します。既存システムの改修では、技術者がAIとコード・仕様を調べ、現場担当者が実際の使い方と照合します。

機能を決める前に、困りごとの原因を確かめます。架空例で営業から倉庫への電話が多い原因は、情報を見られないこと、出荷記録が遅いこと、表示の意味が曖昧なことなどが考えられます。原因が違えば、作るべき機能も変わります。

受け入れ条件は、通常の注文だけでなく、一部出荷や情報更新の遅れでも確かめます。出荷は倉庫から商品を送り出すことで、顧客への配達完了とは別です。画面の速さ、情報を見られる範囲、障害からの復旧も技術・運用担当者と決めます。改善前の作業時間と問い合わせ件数も記録しておきます。

業務と技術の判断が関係する問いは、担当者が同じ場でAIの質問と提案を検討すると、希望と実現方法をその場ですり合わせられます。原典では、この共同作業をMob Elaboration（モブ・エラボレーション）と呼びます。

作るものが決まったら、次は、どのまとまりに分け、誰がどの順序で作るかを決めます。

決めた要件をAIへ渡し、開発をどう分け、どの順序で進めるかを提案させます。人は、各担当の仕事に抜けや重複がないか、別の担当が作る機能とうまくつながるかを確かめます。

関連する要件をまとめた開発単位をUnit（ユニット）と呼びます。AIには「各Unitの担当業務、受け取る情報、返す情報、先に必要な機能を一覧にしてください」と依頼します。受注管理・在庫確保・出荷指示のように、仕事の責任を説明できる単位へ分けます。

図4で出荷結果が戻らなければ、営業は画面を見ても出荷を確認できません。別チームの情報や機能が必要になる関係を「依存関係」と呼びます。各チームの完成条件に加え、つないだときの完成条件も決めておきます。

受注管理と出荷指示の担当で「出荷完了」の意味が違えば、別々に開発する前にそろえます。どの記録を正しい情報として使うか、誰が更新するか、連携失敗を誰が引き取るかを決めます。合意は、決定内容・理由・見送った案・決定者・影響するUnitの形で残します。

Unitの中で、一部を作って試す短い反復をBolt（ボルト）と呼びます。AWS原典では時間〜日単位の反復として説明されていますが、実際の範囲と期間は案件に合わせます。図5のように、最初から業務が一巡する組み合わせを計画すると、連携の問題を早く確認できます。

図5はAWS原典のUnit・Boltを使った説明です。実行ツールによって計画の区切り方は異なるため、技術担当者は利用する版の定義に合わせます。

担当と順序が決まれば、各チームは同じ要件と連携の約束を使って、設計・実装へ進めます。

合意した要件と計画をAIへ渡し、設計案を作らせます。業務担当者と技術者が案を確かめたら、AIにプログラムとテストの作成・実行を依頼し、結果を確認します。

まず、扱う情報と仕事のルールを、AIに図や一覧へまとめさせます。受注の例なら、注文・商品・在庫の関係や、注文取消で在庫をどう戻すかです。業務担当者は実際の仕事と照らして、抜けや誤りを直します。この業務の仕組みを決める作業が、ドメイン設計です。

次に、データの保存先やシステム同士のつなぎ方など、実現するための構成を考えます。これが論理設計です。技術責任者は、必要な速度・安全性・復旧の条件を満たすか、費用や構成が過大にならないかを確かめます。

設計案は、普段と違う注文でも使えるかを確かめます。AIには「一部出荷や情報が届かない場合も含めて、画面に何を表示するか示してください」と依頼します。非エンジニアも、図6のように実際の仕事の条件を当てはめて検討できます。

ここには費用と使い勝手の選択もあります。常に最新の情報を得る連携を作るか、確認時点を明示して一部を人が確かめるかです。営業が顧客へ何を約束するために使うか、倉庫がどの頻度で更新できるかを照合して選びます。「未確認」を増やしすぎて電話が減らないなら、目的に戻って連携方式を見直します。

設計が決まったら、AIにコードとテストを作成・実行させます。開発者は、変更したコードと実際のテスト結果を確認します。業務担当者は画面や操作の流れを見て、要件どおりに仕事を進められるか確かめます。

原典では、担当者がAIと設計・実装を進める共同作業をMob Construction（モブ・コンストラクション）と呼びます。業務の疑問に答える場面とコードを詳しく調べる場面で、必要な人が参加します。

共同作業は、参加する目的も決めます。AWSとタイミーの実践報告には、長い共同作業による疲労や、実装中に非エンジニアが議論を追いにくくなる課題があります。本記事では、業務上の決定は関係者で確認し、コードの詳細な検証は技術担当者を中心に進める使い分けを勧めます。

修正を頼むときは、「どの操作をしたか」「本来どうなるはずか」「実際にどうなったか」をAIへ伝えます。人が直接コードを直した場合も、変更と理由を記録へ反映します。次の作業で、AIや別の担当者が古い仕様を使わないためです。

AIにテストも作らせる場合、人は元の業務条件と照合します。実装とテストが同じ誤解に基づいていれば、テストは通ってしまいます。「必要な項目があるか」という機械の検査に加え、「この結果で現場が判断できるか」を業務担当者が確かめます。

ここまでで、各担当範囲の機能ができました。次は、機能をつないでも仕事を最後まで進められるかを確かめます。

各Unitの機能をつなぎ、利用者が業務を最後まで進められるかを試します。データ移行や障害時の復旧も準備し、社内の責任者が利用開始を承認してから、本番へ移します。

AIへ渡すのは、承認した要件、各Unitのコードとテスト結果、システム間の連携仕様です。要件ごとに「どのテストで確かめるか」を対応づけさせ、業務全体の動作、既存機能への影響、性能やアクセス権を検証します。

業務担当者は、手順1の受け入れ条件に沿って実際に操作し、期待した結果になるか確かめます。技術・品質担当者は、システム間で正しく情報が渡るか、障害時にどう動くかを検証します。不合格なら、要件・設計・コードのどこを直すかを切り分け、修正後は影響する機能も再び試します。

検証結果がそろったら、移行するデータ、対象拠点、開始時期、利用者への案内を決めます。移行・復旧は検証環境で試し、残る課題と影響を責任者が確認します。図9の戻り道を用意したうえで、承認した範囲から利用を始めます。

AIには、システムを本番へ配置する手順や設定ファイル、確認項目の作成・実行を支援させます。操作権限と実行時点は社内のルールで管理し、利用開始後も動作とデータを確かめます。

使い始めた後は、安定して動くかに加えて、当初の困りごとが解消したかを確かめます。開発前に残した業務の記録を、ここで比較に使います。

利用開始後は、AIにシステムの稼働記録や利用者からの相談を整理させ、運用担当者が対応を判断します。業務責任者は仕事がどう変わったかを確かめ、次の開発で解く課題を決めます。

AIには、エラーの記録、処理にかかった時間、利用者が困った操作などを渡し、原因の候補と対応案を出させます。運用担当者が実際の状態と照合し、影響のある変更は確認・承認を経て実施します。

図10の「改善前」では、営業が画面で出荷状況を確認できるようになっても、倉庫は旧システムと新システムへ同じ内容を入力しています。この場合、部署間で仕事が移っただけかもしれません。「改善案」のような連携で二重入力をなくせるか、更新の遅れや訂正まで扱えるかを検討します。

業務の効果は、開発前と同じ対象・条件で比べます。問い合わせ件数や作業時間に加え、処理の誤り、システムの応答時間、運用費用も確認します。開発の効果は、AIが作った量だけで判断せず、要件整理から利用開始までの時間に、人の確認待ちと修正も含めて測ります。

AIには影響範囲の調査と改定案の作成を任せられますが、業務ルールの正式な変更と配布する版は責任者が決めます。AIを使った機能自体を作った場合は、モデル変更も再評価の対象です。以前うまく動いた入力と、問題が起きた入力の両方で確かめます。

自社に業務と技術の判断者がおり、要件の合意と検証を進められるなら、その体制でAI-DLCを始められます。部門間で判断が止まる場合や、運用・改善まで手が回らない場合は、止まっている仕事を具体化して支援を依頼します。

AIは、要件の草案も設計の選択肢も作れます。自社で使える形にするには、どの情報を正しいとするか、部門間の負担をどう引き受けるか、何を根拠に利用開始するかを決める仕事が残ります。支援を頼むときは、助言に加えて、誰と何を決め、何を検証し、自社に何が残るかまで確かめます。

規模を広げるときは、次の拠点や別の業務でも使えた要件・検査・判断理由を再利用します。たとえば、どの注文を優先するか、欠品時に代替案を出す条件は、営業方針や供給体制によって異なります。こうした自社の判断基準を、現場が直せる要件と検査へ残します。顧客への回答の速さや、欠品時の提案の質まで改善できたかで、その価値を評価します。

最初の打ち合わせでは、この材料をAIへ渡して不足情報を洗い出します。完成の条件を決めたら、分担、設計・実装、業務全体の検証へ進みます。利用後の結果を次の要件へ戻すところまでを、一周の仕事として計画してください。

支援が必要な範囲を整理したい場合は、VCのコンサルティング相談窓口で相談できます。

方法論はAWSの原典、実行ツールはAWS Labsの公式文書を参照しています。方法論の3フェーズ、本記事で整理した5手順、Workflows 2.0の5フェーズ・33ステージは、それぞれ別の区切りです。公開実践の報告は、対象・条件を保って要約し、本記事の考察と区別しています。

1. AWS：AI-Driven Development Life Cycle — 2025年7月31日。3フェーズ、AI主導の計画と人による判断、工程間で引き継ぐ文脈。
2. AWS：AI-DLC Method Definition（原典） — 複雑な開発への適用、Intent・Unit・Bolt、共同作業と各工程の成果物。
3. AWS Labs：Workflows 2.0の導入・開始手順 — 2026年9月8日に取得した版。実行環境の導入、プロジェクト設定、開始方法。
4. AWS Labs：Workflows 2.0の工程と成果物 — 5フェーズ・33ステージの体系。方法論の3フェーズと区別して参照。
5. AWS Labs：対象工程・説明の深さ・テスト方針 — 案件に応じた工程・説明の深さ・テスト方針の選択。記事末尾「33ステージ」の補足に対応。
6. AWS・タイミー：11チームでのAI-DLC実践 — 2026年3月5日。1月26〜28日の実践、チーム別の到達点、既存開発と共同レビューの課題。
7. AWS：AI活用を開発工程全体につなぐ — 2026年8月24日。工程をまたぐ文脈の共有と、開発全体で効果を測る考え方。
8. タイミー：失敗から学んだ仕様駆動開発 — 2026年2月19日公開、9月12日確認。標準策定の失敗、手順と知識の整備、デプロイ頻度と残る課題。仕様駆動開発の記録として参照。
9. タイミー：複雑な顧客企業データ統合へのAI-DLC適用 — 2026年9月3日公開、9月12日確認。業務理解、共同設計と分担、終盤に見つかった考慮漏れ。

受注・在庫・出荷の例と机上レビューは、本記事が判断方法を説明するために作成した架空の設計例です。実在案件の再現、顧客発言の引用、導入効果の実証ではありません。公開事例の事実と、そこから本記事が提案する進め方を区別し、期間や成果を他社へ一般化していません。