本資料はAIに書かせていますが、私（人間）が気合いを入れてレビューしております。3つのソースに基づいて作成しており、AIの独自の解釈は含みません。引用元は末尾に記載しております。

1. AI-DLC とは

AI-Driven Development Lifecycle（AI駆動開発ライフサイクル） の略称で、AIを開発プロセスの中心的な協力者・チームメイトとして位置づけ、ソフトウェア開発ライフサイクル全体を通じてその能力を活用する新しい方法論です。一連のプラクティス（セレモニー）、ツール、役割で構成され、ウォーターフォールやアジャイルといった従来の開発方法論そのものをAI時代に合わせてアップデートするガイドラインと位置づけられています。特定のツールに依存した方法論ではなく、AIツールの進化に左右されず適用できる点が重要な特徴です。

2. AI-DLC が解決しようとしている課題

従来の開発手法の根本的な問題

既存の開発手法は人間主導の長期的プロセスとして設計されています
プロダクトオーナー・開発者・アーキテクトが、計画・会議・各種開発（SDLC）セレモニーなど本質的でない活動に時間の大部分を費やしています
最大のボトルネックは人間同士の認識合わせで、具体的には詳細なドキュメンテーション、断続的な会議、複数回のレビューゲートウェイ等が挙げられます
人間がアウトプットを担当する限り、その準備に時間がかかるため、構造的に解決できない問題です

2つのアンチパターン

こうした従来手法にAIを後付けしても問題は解決しません。100社以上との協働から、2つのアンチパターンが特定されています。

	AI自律型（AI-Managed）	AI支援型（AI-Assisted）
概要	複雑な問題をAIに丸投げし、エンドツーエンドでの自律的な構築を期待	人間が計画・タスク分解を行い、限定的な領域（関数のコーディング等）にのみAIを使用
問題点	AIが多くの仮定を立て、大量のコードが開発者に投げられるが信頼度が低い	知的な重労働は人間のままで、AI以前と本質的に変わらない
プロセス	出発点が曖昧なまま開始	AI以前の時代のプロセス（スクラム会議等）がそのまま残存
結果	プロトタイピング以外ではほとんど機能しない	AI活用で節約した時間が会議で消費される

生産性ギャップの実態

調査	結果
ThoughtWorks研究	実際のベロシティ向上は10〜15%
METR実験（開発者16名、issue約250件）	下記参照

METR（LLM評価の非営利団体）は、オープンソースリポジトリで16名の開発者を8名ずつ2チームに分け、一方にはAIツールの使用を指示し、もう一方にはAIなしで作業させました。約250件のissueに取り組んだ結果、AI使用チームの開発者は自己申告で+23%の生産性向上を感じていました。研究者もさらに掘り下げて+20%程度の向上があったのではと推定しました。しかし、両チームの実際の成果を比較分析したところ、AI使用チームは実際には−20%生産性が低かったことが判明しました。認識される生産性と実際の生産性の間に大きな乖離があることを示す結果です（※本研究は2025年初頭に実施されたもので、LLMは大きく進化している点に留意）。

既存手法のままAIを導入してもパラダイムシフトには至らず、段階的な増加に留まることを示しています。

3. AI-DLC の核心：何が従来と違うのか

コア原則

AIに丸投げする（AI自律型）わけでも、人間の計画の一部を手伝わせる（AI支援型）わけでもない、第三のアプローチとして、2つのコア原則を掲げています。

原則	内容
AIが実行し、人間が監視する	AIが作業計画を作成し、すり合わせを求め、人間が重要な意思決定を行う。従来の「人間が実行、AIが支援」の逆転
ダイナミックなチームコラボレーション	AIがルーティンタスクを処理し、チームはリアルタイムの問題解決・創造的思考・迅速な意思決定に集中。孤立した作業から活気あるチーム作業への転換

図1：AI中心のソフトウェア開発アプローチ（出典：AWS公式ブログ）

ボトルネックの解消メカニズム

AIが瞬時にアウトプットを生成するため、関係者がその場に集まり、リアルタイムで意思決定用のアウトプットを作成できるようになります

	サイクル
従来	準備→会議→持ち帰り→再準備→再会議
AI-DLC	リアルタイムの意思決定サイクル

AI-DLCは「AIをうまく使うための方法」ではなく、AIによって人と人のコミュニケーションをより活発に、円滑にするものです

4. AI-DLC のメンタルモデルとフェーズ

計画 → すり合わせ → 実装のサイクル

すべての開発活動に対して、以下のサイクルを高速に繰り返します。このサイクルは、後述する各フェーズの中でそれぞれ繰り返されます。

AIが計画を作成します
AIが文脈理解のためにすり合わせの質問をします
人間が検証・コース修正を行います（不要なもの、追加すべきこと、仮定の特定）
検証後にAIが実装します

図2：AI-DLCのメンタルモデル（出典：AWS公式ブログ）

3つのフェーズ

図3：AI-DLCの3つのフェーズ（出典：AWS公式ブログ）

フェーズ	プラクティス	AIの役割	人間の役割
1. 開始（Inception）	モブエラボレーション	ビジネス意図をUnits of Workに分解し、要件・ストーリー・ユニットに変換	AIの質問・提案を検証し「何を作るか」の共通理解を形成
2. 構築（Construction）	モブコンストラクション	Units of Work単位で論理アーキテクチャ、ドメインモデル、コード実装、テストを提案	Units of Work単位で技術的決定とアーキテクチャ選択をリアルタイムで明確化
3. 運用（Operation）	—	Units of Work単位で蓄積コンテキストを適用し、IaCとデプロイメントを管理	監督

※モブエラボレーションの「エラボレーション（精緻化）」とは、新しい情報を既存の知識と関連付け、What（何を）よりもHow（どのように）やWhy（なぜ）に重きを置いて詳細を付け加えるプロセスです。

各フェーズは次のフェーズにより豊富なコンテキストを提供します
AIはプロジェクトリポジトリに計画・要件・設計成果物を保存し、永続的なコンテキストを維持します

新しい用語体系

従来のアジャイル用語	AI-DLC の用語	変更の意図
スプリント	ボルト（Bolts）	週単位→時間・日単位の短く集中的な作業サイクル
エピック	作業単位（Units of Work）	スピードと継続的デリバリーの重視

5. AI-DLC がもたらすメリット

メリット	内容
開発速度	AIが要件・設計・コード・テストを迅速に生成・改良し、数週間→数時間〜数日に短縮
品質	継続的な意図のすり合わせにより正確な構築が可能。組織固有の標準を一貫適用し、要件〜デプロイのトレーサビリティが向上
イノベーション	AIが重労働を肩代わりし、創造的なソリューション探求の時間を確保
市場対応力	迅速な開発サイクルにより市場の需要・ユーザーフィードバックに即応可能
開発者体験	日常的タスク→重要な問題解決にフォーカスを移し、認知負荷を軽減

6. AI-DLC 実践のベストプラクティス

100社以上との協働およびAWS内部の実験から得られた、AI-DLCを効果的に実践するための具体的な知見です。

タスク分解と指示の与え方

プラクティス	内容
タスクは狭く定義する	「ECサイトを構築して」ではなく「SQLインジェクションの脆弱性がないか確認して」のように、スコープを限定する。AIへの指示が広すぎると多くの仮定を立て、不要な変更が大量に発生する
トークンあたりのセマンティクス比を意識する	「builder patternでリファクタリングして」（4語・高セマンティクス）は、同じ意味を冗長に説明するより正確な結果を生む。指示やコンテキスト構築において、少ないトークンで意味の密度を高めることが重要
コードそのものよりコードの意味を渡す	大規模コードベースの全体を渡すのではなく、コールグラフ・クラス構造・各関数の役割など意味的なコンテキストを構築して渡す方が、AIは正確に機能する

コンテキストウィンドウの管理

プラクティス	内容
投入量を絞る	大量のコードを一括投入するとAIが混乱し、無関係なファイルまで変更する無限ループに陥りやすい。多ければ良いわけではない
過去のやり取りを定期的にリセットする	関連性の低い過去のインタラクションがノイズになる。「AIの仕事を単純化すれば、自分の仕事も単純化される」
不要なMCPサーバーを無効化する	大量のMCPサーバーを有効にしていると、ツール説明だけでコンテキストの60〜70%が消費される。現時点では手動管理が必要

既存コードベースへの適用

プラクティス	内容
セマンティックコンテキストの構築	既存コードベースのアーキテクチャ構造、データフロー、コンポーネント間の関係性をリバースエンジニアリングし、意味的に豊かなコンテキストを作る
既存コードをリファレンスとして指し示す	「X認証、Yロギング、Zエラーハンドリングを備えた新サービスを作って」と説明するより、既存の実装を指して「これをリファレンスにして」と言う方がはるかに正確。LLMのattention mechanismはパターンの模倣に強い

開発環境とCI/CDパイプライン

プラクティス	内容
CI/CDが新たなボトルネックになることを認識する	AIにより開発速度が劇的に向上すると、コーディング〜ユニットテストの高速化にデプロイ・テスト環境が追いつかなくなる
dev / integration / pre-prod環境を整備する	テスト環境が正常に機能していないと、AIで生成したコードの検証手段がなくなり、速度の恩恵が失われる
節約した時間をQAとCI/CDに再投資する	パラダイムシフトを実現するには、開発の高速化で生まれた余剰をテスト・デプロイ基盤の強化に充てることが鍵

チームの働き方

プラクティス	内容
連続した集中時間の確保	AIと協働する際はフロー状態の維持が重要。会議による中断はAIのコンテキスト喪失にもつながる。Amazonの一部チームでは「午後は会議なし」を実践
チームサイズの縮小	AIがより大きな役割を担うため、2ピザチームよりさらに小さい「シングルピザチーム」（フルスタック開発者1名＋ビジネス1名＋スペシャリスト1名）でも機能する
モデルの訓練データを意識する	言語とデザインパターンの組み合わせには相性がある（例：GolangでDDDは訓練データにほぼ存在しないため機能しにくい）。AIに無理な組み合わせを強制しない

AIとの向き合い方

プラクティス	内容
AIは上級エンジニアではなくインターン	自信を持って発言するが間違うこともある。人間が所有者として検証・ガイドする姿勢が不可欠
コードの全行を理解する	AIが生成したコードでも、デバッグ・保守できるレベルで理解していなければ本番投入すべきではない。自分の名前がチェックインに残る以上、所有者としての責任がある
品質基準を引き上げる	開発速度が上がれば同じ期間でのバグ数も増加しうる。包括的なユニットテスト・統合テストの整備が必須

7. 実務適用に向けた課題

AI-DLCの導入は単なる技術導入ではなく、組織文化と制度の変革を伴うものです。2026年1月開催の11社合同AI-DLC Unicorn Gymでは以下の課題が挙がっています。

課題	内容
セキュリティ・コンプライアンス	社内のセキュリティ統制、個人情報・機密情報の取り扱い
既存制度との整合	社内の承認プロセスや既存制度とのすり合わせ
コードレビュー体制	AIが生成したコードに対して「レビューする側の知識が追いつかない」

8. 始め方・リソース

リソース	概要
AI-DLC Method Definition Paper	AI-DLCの方法論を体系的に定義したホワイトペーパー。3フェーズの詳細、AIと人間の役割分担、具体的な実践手法を網羅。理論的基盤を理解したい方向け
Building with AI-DLC using Amazon Q Developer	Amazon Q Developerを活用した実践ガイド。コード例付きのステップバイステップ解説。すぐに実践したい開発者向け
AI-Driven Development Lifecycle Workshop	ハンズオン形式のセルフペースワークショップ。AWSサービスを使い3フェーズを体験学習。約2-3時間で完了
AWS Builder Center	開発者向け総合コミュニティハブ。AI-DLC含む最新の開発手法・ベストプラクティス・学習リソースを集約
Introduction to AI-DLC（AWS Skill Builder）	公式学習コース。基礎概念〜実践的な適用方法まで構造化されたカリキュラム。修了証取得可能
awslabs/aidlc-workflows（GitHub）	構造化・ガバナンス付きワークフローフレームワーク。Amazon Q Developer/Kiroと連携し、Steering Filesによる制御、各フェーズの人間承認、audit.mdへの監査証跡記録を実現

引用元

AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 — AWS公式ブログ, 2025年8月
11社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト — AWS公式ブログ, 2026年2月
re:Invent 2025: AI-DLC手法による人間とAIの協調開発とベストプラクティス — Zenn, 2025年12月

免責事項： 本資料は引用元の情報を要約・整理したものであり、正確性・完全性を保証するものではありません。最新情報や正式な内容については、必ず引用元の原典をご確認ください。また、本資料の利用により生じたいかなる損害についても、作成者は責任を負いかねます。