AI-DLC（AI-Driven Development Lifecycle：AI駆動開発ライフサイクル）とは、クラウドコンピューティングサービス大手のAWS（Amazon Web Services）が提唱する、要件定義から設計、実装、テスト、改善までの開発工程全体に生成AIを組み込み、AIが計画・実行を主導し、人間が監督・承認を担う開発アプローチです。AIをツールとして使うのではなく、開発の進め方そのものをAI前提で再設計するという点で、従来のAI活用とは異なります。

本記事では、FindyがAI-DLCワークショップへの参加で得た実体験も交えながら、基本概念、従来手法との違い、導入時に見落としやすい論点などを解説します。

AI-DLCとは何か

AI-DLC（AI駆動開発ライフサイクル）の定義

AI-DLCを理解するうえでカギとなるのが、AI-Assisted（補助的なAI活用）とAI-Driven（主導的なAI活用）の違いです。

従来のAI活用（AI-Assisted）では、人間が要件を整理・設計・実装し、レビューする一連の工程を主導し、AIはその補助として機能していました。コード補完や文書生成など、特定のタスクを速くする道具として使われるイメージです。そしてその活用は、基本的に個人単位で完結していました。

一方、AI-DLCが前提とするAI-Drivenでは、大きく分けて2つのことが大きく変わります。

ひとつは人間の役割です。人間がビジネス上の意図と制約を与えると、AIがそれをタスクに分解し、設計案・実装案・テストケースを生成して進めます。人間はその出力を確認し、方向を決め、承認する側に回ります。いわば、「手を動かす側」から「監督する側」へのシフトです。人間の主な役割が変わります。

もうひとつはチームの協働様式です。AIがルーティンタスクを担うことで、人間はリアルタイムでの判断・問題解決・認識合わせに集中できるようになります。つまり、個人がそれぞれAIを使って作業するスタイルではなく、AIを中心に置いたチーム全体の協働が基本単位となります。

ソフトウェア開発でのAI活用が浸透した今、メンバーが個人ごとにAIを使う段階から、チームとしてどう役割分担し、どこで人間が判断を担い、どこをAIに任せるかを設計すべき段階へと移ってきました。AI-DLCは、AIの出力だけに着目するのではなく、チームの意思決定や認識合わせまで含めて再設計する方法論だと言えます。

AI-DLCが注目される背景

AIを使った開発支援は、すでに多くの企業や組織で導入されています。ただ、その多くは従来の開発プロセスの中で部分的にAIを活用するにとどまっていました。

部分適用ではスピードの向上やアウトカムの改善に限界があり、プロセス全体をAI前提で見直さなければ劇的な変化は起きにくい——そういった認識が広まりつつあることで、よりAI-DLCが注目されるようになっています。

AI-DLCによって実現できうることは、大きく分けて次の2点です。まずは、 要件定義からテストまでを含む開発全体のリードタイムを縮めながら品質を維持すること 、そしてAI活用が個人の工夫に依存して属人化する状態から脱し、チームとして再現可能な開発プロセスを作ることです。

従来の開発手法とAI-DLCの違い

SDLCとの違い

SDLC（Software Development Life Cycle）は、ソフトウェア開発を要件定義、設計、実装、テスト、運用といった工程で整理する一般的な考え方です。SDLCとAI-DLCの最大の違いは 「成果物の生成主体がAIに変わる」だけでなく「チームの協働構造と意思決定の設計思想ごと変わる」という点 です。

SDLCでは人間が工程ごとの成果物を主導して作りますが、AI-DLCではAIが初期案を高速に生成し、人間がそれを評価・修正・監督する形に変わります。それだけでなく、チームの協働様式も変わります。個人がそれぞれAIを使う形ではなく、AIを中心に置いたチーム全体の協働が基本単位となるよう、プロセスそのものを設計し直します。なお、AI-DLCは工程間の往復は速くなりますが、仕様の曖昧さや意思決定がボトルネックになりやすいため、人間側の要件整理力とレビュー力がより強く求められます。

アジャイル開発との違い

アジャイル開発は、短いサイクルで価値を検証しながら反復的に改善していく考え方です。AI-DLCは、AIを開発プロセスの中心的な協力者として組み込み、人間との役割分担を見直す考え方です。両者は対立するものではなく、見ている対象が異なります。

アジャイル開発が反復サイクルと価値検証を中心に据えるのに対し、AI-DLCは各工程でのAIと人間の役割分担により焦点を当てています。AI-DLCはアジャイル開発を置き換えるのではなく、既存の反復型プロセスの中によりAIを深く組み込み、要件整理・設計・実装・テストの速度と往復回数を変えていくものとして捉えるほうが実態に合います。

従来の開発手法との関係

AI-DLCは既存の開発プロセスと対立するものではなく、AIに合わせて最適化し進化したものです。

ただし、既存のプロセスにAIツールを組み込むだけではAI-DLCにはなりません。要件の書き方、レビューの観点、意思決定のタイミングまで含めて見直す必要があります。特に変わるのがレビューの重みです。AIが成果物を早く作れるようになるほど、人間は「書く人」よりも「読む人」「判断する人」としての比重が増します。

だからこそAI-DLCの導入では、既存のスクラムイベントや開発フローを残しながらも、要件の明確化とレビューの設計を先に整えることが求められます。

AWSの公式ドキュメントで示されていること

ここからは、AI-DLCを理解するうえで、AWSが公開したAI-DLCの公式ドキュメント「AI-Driven Development Lifecycle (AI-DLC) Method Definition」という資料に記載されている内容を紹介します。概念的な説明にとどまらず、各フェーズの成果物、プロセスの進め方、人間とAIの役割分担まで具体的に記述されています。

原文（英語）をお読みになりたい方は下記のリンクをご覧ください。

関連リンク：AI-Driven Development Lifecycle (AI-DLC) Method Definition

AI-DLC 10の設計原則

この資料では、AI-DLCを構成する10の設計原則が述べられており、フェーズ・役割・成果物・リチュアル（習慣的な作業）すべての設計根拠となっています。

1. Reimagine Rather Than Retrofit（後付けではなく再構想する）：既存のSDLCやアジャイルにAIを追加するのではなく、AIを前提にゼロから開発手法を再設計する
2. Reverse the Conversation Direction（会話の主導権を逆転させる）：人間がAIに指示するのではなく、AIが質問・提案・タスク分解を主導し、人間は承認・選択・修正を担う
3. Integration of Design Techniques into the Core（設計技法をコアに組み込む）：スクラムなどが設計手法を各チームの裁量に委ねていたのに対し、AI-DLCはDDD（ドメイン駆動設計）などを方法論の中核に組み込む
4. Align with AI Capability（AIの現在の能力に合わせる）：現在のAIは、高レベルの意図を自律的に実行コードに変換することや、解釈可能性や安全性を確保しつつ人間による監督なしに自律的に動作するには、まだ信頼できる水準にないことを前提に、人間の監督と判断を必須の要素として設計する
5. Cater to Building Complex Systems（複雑なシステムの構築に対応する）：高い設計複雑性・多くのトレードオフ管理・複数チームの協働が必要なシステムを対象とし、単純なシステムはノーコード/ローコードに委ねる
6. Retain What Enhances Human Symbiosis（人間との協働を支える要素は残す）：ユーザーストーリーやリスク登録簿など、人間の検証とリスク管理に不可欠な既存の成果物・接点は保持し、リアルタイム活用に最適化する
7. Facilitate Transition Through Familiarity（親しみやすさで移行を促進する）：1日で実践を始められる習得しやすさを目指す。スクラムの「スプリント」をAI-DLCでは「Bolt」と呼び替えるなど、既存用語との対応関係を保ちながら現代化する
8. Streamline Responsibilities for Efficiency（責任をシンプルに整理して効率を高める）：AIのタスク分解能力を活用することで、開発者はインフラ・フロントエンド・バックエンド・DevOps・セキュリティといった専門サイロを横断できるようになる。役割は最小限を原則とし、必要な場合のみ追加する。なお、プロダクトオーナーと開発者は引き続き監督・検証・戦略的意思決定の責任を担う
9. Minimise Stages, Maximise Flow（ステージを最小化し、フローを最大化する）：自動化と責任の収束によってハンドオフと待ち時間を最小化する。AIが生成したコードが硬直化（”quick-cement”）しないよう、重要な判断ポイントでの人間の検証フェーズを最低限必要な数だけ確保する
10. No Hard-Wired, Opinionated SDLC Workflows（固定されたSDLCワークフローを持ち込まない）：新規開発・リファクタリング・バグ修正・マイクロサービスのスケーリングなど、開発の種類に応じてAIが最適なワークフローを推奨する。人間はAIが生成したプランを対話的に検証・修正しながら進める

これら10の設計原則すべてに共通するのは、「AIが自動化して人間の関与を減らす」のではなく、「AIが主導しながら、人間の判断と監督をより重要な位置に置き直す」 という設計思想です。

Mob Elaboration：協働作業の基本単位

このドキュメントで特徴的なのは、Mob Elaboration（モブ エラボレーション）という作業形式を中心に据えている点です。

Mob Elaborationとは、要件を持つPM/PO、実装を担うエンジニア、品質観点を持つQAエンジニアが一室に集まり、AIと対話しながら要件を具体化していく作業形式です。

Findyの開発チームが参加したワークショップのインタビューの中でもこの作業が触れられていますが、AIが「誰のための機能か」「例外ケースはどう扱うか」といった質問を次々に投げかけ、その場で答えが出るたびにユーザーストーリーや受け入れ基準、非機能要件（NFR）に落とし込んでいきます。

Inception（開始）フェーズでのこのAIとの協働作業が、後工程のConstruction（構築）フェーズを速く進めるための前提になります。

開発期間の変化：ホワイトペーパーと国内実践事例が示すこと

このドキュメントでは、AI以前の開発サイクルが「週～月単位」であるのに対し、AIを適切に活用した場合のサイクルは「数時間〜数日単位」になると述べています。また、Mob Elaborationにより「数週間〜数ヶ月掛かっていた作業を数時間に凝縮できる」としています。ただし、これが設計からデプロイまでの具体的な所要日数を一般値として示しているわけではない点には留意する必要があります。

より現実に即した数字感を掴みたい場合は、日本国内でのワークショップの実践事例が参考になります。AWSが2026年1月に開催した11社合同AI-DLC Unicorn Gymの記事「11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト」では、「当初8週間想定の開発が2日間で完了」「当初6ヶ月想定の内容を2日間で進められた」といった実績が報告されています。ただし、こちらはいずれもPoC文脈での結果であり、通常の実務開発に直接あてはまる数字ではない点は踏まえておく必要があります。

より実践的に手を動かすためにすべきこと

ここまででAI-DLCの設計原則の大筋を理解しても、一足飛びに実践しようとするのはなかなか難しいです。そこで、より実践的に取り組むために、AWSが公開しているawslabs/aidlc-workflows（GitHub）を見てみるのがオススメです。

これはAI-DLCの基本的概念を実際のプロンプトとテンプレートとして具体化したリポジトリで、Amazon QやKiroといったAWSが提供している開発ツールと組み合わせて使えます。概念を理解した後、手を動かすステップへ進む際の参考にできます。

関連リンク：awslabs/aidlc-workflows

AI-DLCで実際に変わること

要件定義

AI-DLCでは、要件定義の重要性が上がります。人間主体の開発では曖昧さをコミュニケーションや文脈で補える場面もありますが、AIに対しては前提条件や制約が曖昧なままだと出力の質が大きくぶれます。

AIに任せるほど要件を定義する人間側の責任が大きくなり、何を作るのか、誰のための機能か、どんな制約があるのかなど、これらを言語化する力が以前より問われることになります。

設計

たたき台の作成スピードは大きく上がります。ただし、AIが出す設計案は、前提となる業務知識や既存システムの制約を十分に理解していないこともあります。

そのため人間の役割は、設計をゼロから作り上げることよりも、前提を与え、抜けや矛盾を見つけ、どこを採用するかを判断（意思決定）する側へと移ります。

実装

雛形づくりや定型的なコード生成、複数案の比較検討が速くなりますが、実装の高速化は諸刃の剣です。AIが速くコードを書けることと実運用に耐えるコードであるかどうかということは全く別の話です。既存コードベースとの整合、チームの実装規約、保守性の観点まで含めて妥当かどうかについては、最後に人間側が判断する必要があります。

テスト

テストケースのたたき台や観点出しがしやすくなります。一方で、何をもって十分とみなすか、どのリスクを優先的に検証するかといった判断は依然として人間の責任です。

AIは網羅的な候補を出す助けにはなりますが、プロダクト文脈に照らして何が本当に問われているかを決める作業は人間側のタスクとして残ります。

レビュー

AI-DLCで従来の開発手法から最も大きく変わるのは、レビューの位置づけかもしれません。AIによって短いスパンで生成される大量の成果物に人間が対応する必要があります。

コードや設計を読み解く力、前提を疑う力、判断の根拠を言語化する力、意思決定力がより問われるようになります。

また、これらでの副次的な影響として、人間側に「レビュー疲れ」や「認知負荷（Cognitive Load）」が発生しやすくなる点も気にかけておく必要があります。

AI-DLCの具体的な進め方

AI-DLCは3つのフェーズで進む

AI-DLCは大きく3つのフェーズで進められます。

• Inception（開始）
• Construction（構築）
• Operation（運用）

Inception（開始）フェーズでは、ビジネス意図を要件や作業単位に落とし込みます。Construction（構築）フェーズでは設計・実装・テストを進め、Operationフェーズではデプロイや監視、改善までを扱います。

どのフェーズでも、AIが作業のたたき台を高速に生み出し、人間が前提を与え、判断し、軌道修正する構造は変わりません。

Inception（開始）フェーズ

Inception（開始）フェーズの目的は、「何を作るのか」をAIと人間の双方が扱える形まで明確にすることです。

要件をきれいに書くことよりも、曖昧さを放置しないことが中心になります。AIは曖昧な要件からもそれらしいアウトプットを返すことはできますが、それが正確であるとは限りません。この段階で人間がやるべきことは、AIが誤った判断を行ったり、不正確なアウトプットを作らないように次のような点を言語化することです。

• 背景
• 目的
• 制約
• 優先順位

また、成果物としては次のようなものが中心になります。

• 目的整理
• 要件定義
• ユーザーストーリー
• 作業単位の分解
• 前提条件の整理

たたき台の作成、抜け漏れの洗い出し、整理された文書への変換はAIが担います。 ただし、最終的に「その要件で本当に良いのか」を決めるのは人間です。

Construction（構築）フェーズ

Construction（構築）フェーズでは、開始フェーズで整えた前提を基に、設計・実装・テストを進めます。

このフェーズは「AIがコードを書いてくれる工程」と理解されがちですが、コード生成は一部に過ぎません。設計の前提を保ったまま、実装とテストまでを連続的に進められることがこのフェーズのポイントです。AIに任せる対象は次のようになります。

• 設計のたたき台
• 実装案の生成
• テストケースの草案作成

また、人間側は次の観点で判断を行います。

• アーキテクチャ上の妥当性
• 既存システムとの整合
• セキュリティ
• 保守性
• 採用する案と修正すべき点

ここで、AI-DLCのチームで同じ画面を見ながら進める協働スタイルが有効に機能します。個人がAIに向かって黙々と作業するのではなく、関係者がその場でAIの提案を確認し、方向を合わせながら進めることで、レビュー待ちや認識ズレを減らしやすくなります。

このフェーズで広く使われるのがClaude Codeです。Claude CodeはAnthropic社が開発したCLIエージェントで、コードベースを読み込みながら複数ファイルにまたがる変更や実行を自律的に行います。

Operation（運用）フェーズ

Operationフェーズでは、デプロイ、監視、分析、改善までを扱います。

AIが力を発揮しやすい領域は次の通りです。

• ログや指標の整理
• 改善仮説のたたき台作成
• 運用手順の文書化

どの問題を優先するか、どのリスクを許容しないかは人間の判断に依存します。運用フェーズまでAIを組み込むことで、要件定義から改善までが分断されにくくなります。開発チームの責任者やSRE、QAの視点を早い段階から巻き込んでおくと、後工程での手戻りを減らしやすくなるでしょう。

各フェーズでの人間とAIの役割分担

「人間の仕事が減る」「AIに置き換わる」と単純化しないことが、AI-DLCを実践するうえでの前提になります。

ここまでの3つのフェーズを見てきましたが、各フェーズでの人間とAIの役割分担を整理すると、次のようになります。

フェーズ	AIが担うこと	人間が担うこと
Inception（開始）	要件の整理・文書化、ユーザーストーリーのたたき台作成、抜け漏れの洗い出し	目的・背景・制約の定義、優先順位の決定、要件の最終確認
Construction（構築）	設計案・実装案・テストケースの生成、複数案の比較提示	アーキテクチャ妥当性の判断、既存システムとの整合確認、セキュリティ・保守性の評価、採否の決定
Operation（運用）	ログ・指標の整理、改善仮説のたたき台作成、運用手順の文書化	問題の優先順位付け、リスク許容の判断、次サイクルへの要件フィードバック

どのフェーズでも「AIがたたき台を作り、人間が判断・確定する」という構造は一貫しています。

公開事例から見えるAI-DLCの実践

AI-DLCは、海外だけでなく国内でも検証が始まっています。

東京海上日動システムズの事例では、2025年8月に金融業界で初めてとなる「AI-DLC Unicorn Gym」が実施され、4つの異なるシステム・部署のチームが参加しました。システム部門だけでなく、ビジネス部門やパートナーも加わり、1日半という集中形式で4チームが動作する初期版を完成させ、うち1チームはテスト環境へのデプロイまで完了したとされています。

注目したいのは、AI-DLCが単なるコード生成の話として扱われていない点です。ビジネス側と開発側が同じ場で要件と判断をすり合わせながら、短いサイクルで形にしていく開発手法として実践されています。

関連記事：Amazon Web Services ブログ「東京海上日動システムズ株式会社様の AWS 生成 AI 事例：金融業界初 AI-DLC Unicorn Gym による開発変革への挑戦」

AI-DLCの実践でつまずきやすいポイント

AI-DLCを実践するにあたってつまずきやすいポイントがいくつかあります。

ひとつは、AIが要件の曖昧さを増幅してしまうことです。入力が曖昧でもAIは出力を返してしまうため、一見すると前に進んでいるように見えます。前提がズレたまま進むと、後工程で大きな手戻りが発生しやすくなります。修正は後工程ほどコストが掛かるため、AI-DLCでは要件定義の曖昧さの排除がより重要となってきます。

もうひとつは、人間側のレビュー負荷や認知負荷が見落とされやすいことです。AI-DLCでは人間側が成果物を評価し意思決定する役割が増えますが、レビュー疲れや認知負荷が大きくなりがちである点には注意が必要です。

さらに、AI-DLCはフレームワークを導入しさえすれば自動的に回り始めるものでもありません。役割分担、レビュー体制、合意形成の進め方まで含めた組織全体の再設計が必要で、社内推進役の推進力や組織の意思決定力がより問われることとなります。

Findyが体験した「AI-DLC Unicorn Gym」参加者インタビュー

2025年11月にAWSが主催するAI-DLCを実践できるワークショップ「AI-DLC Unicorn Gym」に、当社Findyの開発チームが参加しました。

この章では、全日程の3日間にわたって参加した本田陽平さん、萩原大地さんのお二人に、このワークショップを通じて得られた学びや実務に活かせた点についてお話を伺いました。

参加者プロフィール

• 本田 陽平さん（ファインディ株式会社 CTO室 Tools開発 エキスパート）：既存プロダクトの新機能開発を行うチームとして参加

• 萩原 大地さん（ファインディ株式会社 Team+開発部 Enhance マネージャー）：新規プロダクトのプロトタイプ開発を行うチームとして参加

ワークショップ参加の背景

――まず、今回のワークショップに参加した背景を教えてください。

本田：
もともと、AIを使ってコードを書くこと自体は既にある程度できていました。それよりもさらに手前の抽象的な領域、たとえば「何を作るか」「UIや仕様をどう詰めるか」といった部分にも、AIを活用して効率化できるのではないかと考えていました。

当時は、チームとしての課題で施策の立ち上げや仕様整理の進め方がありました。そのため、「関係者を集めて短期間で一気に整理し、開発まで進める」というAI-DLCの進め方を聞き、チームの課題解決につながるのではないかという期待を持って参加しました。

萩原：
当時からAI駆動開発や仕様駆動開発が注目されていた一方で、現場で実践するためのベストプラクティスを体系的に学ぶ機会は多くありませんでした。

また、ちょうど新規プロダクトのPoC開発も進めていたため、AIとの協働をより効率的に進められれば、開発スピードをさらに高められるのではないかと考えて参加しました。

AIを議論に巻き込む開発プロセス

――ワークショップでは、どのようなことを行ったのでしょうか。

本田：
ワークショップでは、Inception（開始）とConstruction（構築）を細かい単位で区切り、繰り返しながら開発を進めました。

エンジニア、デザイナー、PdM、QAが一堂に会し、ゼロベースで議論を重ねながら1日かけて方向性を固めていく進め方は、これまでになかったので新鮮でした。

また、その議論の中にAIを参加させていたのですが、AWSの講師の方から言われて印象に残っているのは「5分以上AIを触っていないなら、まずAIに投げてみましょう」という考え方です。人間だけで議論を固めてからAIに渡すのではなく、議論の途中からAIを巻き込む。これは普段の進め方との大きな違いでした。

――このやり方は、通常の開発プロセスと比べると、生産性の面でどう変わりましたか？

本田：
フロー効率の観点では、一定の効果があったと感じました。普段はリモートで開発に携わっているメンバーも、今回は3日間集中的に集まり一気に開発を進めることができました。参加したメンバーからも「実感として速かった」という声が多かったです。より同期的に開発を進められたことが良かったのだと思います。

――AIにはどのようなことを行わせたのでしょうか。

本田：
コードを書くことは基本的にAIに任せていました。そのうえで人間がレビューを行うという役割分担を行っていました。また、タスク分解やスコープ整理、進める順番の検討といった、プロジェクトマネジメント寄りの作業にもAIを積極的に参加させていました。

共通フレームワークによる推進力

――AI-DLCには、どのようなメリットを感じましたか。

萩原：
私にとって大きかったのは、AIとの協働を進めるためのフレームワークが明確になったことです。ワークショップを通してプロンプトや進め方を学べたことで、ワークショップ後もチームでAIとの協働を進めやすかったと感じています。

また、同期的に集まって進めることで、仕様の認識合わせがとてもしやすかったですね。レビュー負荷が上がる面はあるものの、その分、後戻りを減らせるメリットも感じました。

開発スピードやアウトプット量についても、ある程度慣れてくると徐々に上がってきた実感があります。最初から一気に効果が出るというより、チーム内で慣れが進むほど効果が大きくなっていく感覚に近いです。

本田：
私の場合は意識の変化も大きかったです。それまでは「使えるところだけAIを使う」という感覚だったのが、ワークショップ以降は「まずAIに任せてみて、人間は本当に必要な判断に集中する」という発想に切り替わりました。

体験して見えた壁――コンテキスト整備、レビュー負荷、意思決定

――一方で、難しさを感じる点や、浮かび上がってきたチームの課題はありましたか。

本田：
はい。特に既存プロダクト側では、プロダクトの背景や過去の仕様、デザインなど、AIに渡すべきコンテキストが多く、それらをきちんと整備する必要性を感じました。議論を進める中で、「もともとの仕様はどうなっているのか」「影響範囲はどのくらいあるのか」といった話になり、「まず整理しよう」という流れになりました。さらには「その整理自体にもAIを活用できるのではないか」という話にもなりました。

萩原：
私が強く感じたのは、そのまま実務に適用することの難しさです。ワークショップでは、モブプログラミングのような形でPdMを含めて全員で集まって進める前提がありましたが、実務でその状況を常に作るのはなかなか難しいのが現実です。そのため、私達のチームでは、フレームワーク自体は活かしつつ、実務に合わせる形にアレンジして活用しました。

――レビューの観点ではどうですか？

本田：
まさにレビューも課題です。AIは短時間で大量のアウトプットを返してくるため、人間側のレビュー負荷が一気に高くなります。

Inception（開始）では膨大なユーザーストーリーを出してくれるので、それをみんなで見ていきました。さらにコードレビューまで進むと、「これを全部見るのか…」と感じるほど大変で正直かなり疲れました。

AIは止まらずに出力できますが、人間の集中力には限界があります。AI-DLCでは、レビューをどう設計するか、という点がかなり重要だと感じました。

また、人間による意思決定がボトルネックになりやすいため、意思決定できる人や責任を取れる人が中心となって仕切ってどんどん進めていくことがスピードの面でも改めて重要だと分かりました。

萩原：
意思決定については、チーム全員で行うのは負荷が高い印象です。なので、濃淡をつけて、システム全体の設計に関わるものは全員で意思決定を行い、影響がそこまで大きくないものは小規模チームに分けて、そのチーム内で意思決定するといった工夫が必要だと感じました。

新規プロダクトと既存プロダクトにおける導入難易度の違い

――新規プロダクトと既存プロダクトでは、AI-DLCの導入のしやすさに違いはありましたか。

萩原：
はい、違いはあると思います。まず、AI-DLCを実施するためには、プロダクトのコンテキストを持っておく必要があります。具体的には、プロダクトの仕様や、課題に対してどのような解決策を提供するか、ドメイン知識といった情報です。そうしたものを整えておかないと、AIに仕様書を作ってもらう際の精度が下がってしまいます。

新規プロダクトであれば、前提となるコンテキストをゼロから整えやすいです。また、AI-DLCを回す過程でドキュメントが蓄積されていくため、それらを次のプロダクト開発に活かしやすく、サイクルも回りやすいんです。そういった意味で、新規プロダクトの方がよりAI-DLCを導入しやすいと言えます。

一方で、既存プロダクトでは、過去の仕様や開発者の異動で失われてしまったコンテキスト、暗黙知などがあるため、それをどうAIに渡すかで苦労したと聞きました。最初にコンテキストを残すところから始まるので、その点で既存プロダクトでAI-DLCを実施する難しさがあると感じました。

本田：
既存プロダクトのチームでは、まさにその点が顕在化しました。AI-DLCを回す前に、AIが読める形でコンテキストを整える必要があります。逆に言えば、その必要性がはっきり分かったこと自体が、ワークショップでの大きな収穫だったと思います。

ワークショップ後の実務への定着と開発フローの変化

――今回の体験は、その後の開発にどう活きていますか。

萩原：
ワークショップで得たフレームワークをベースにしながら、AIとの協働の進め方をキャッチアップできたことは大きな収穫でした。実際にフレームワークをチームへ導入し、少しずつアレンジを加えていったことで、今ではチームにフィットしたAI駆動の開発フローをかなり形にできています。その点が一番の学びになりました。

また、新機能開発のたびにそのフローに基づいて開発を進めており、非常に効率的に進められています。プルリクエスト数や開発スピードの面でも、向上を実感しています。

本田：
もともと開発でAIは使っていましたが、ワークショップを通じて、より積極的にAIを活用し、任せる範囲を広げていく意識が高まったと思います。

ワークショップから数カ月経った今も、仕様を整理したり、やるべきことを言語化したりする段階でAIをかなり使っています。まずAIに叩き台を作らせて、人間が意思決定する。この流れはこれからますます当たり前になっていくと思います。

改めて感じるのは、AI活用が進んでも、最後に効いてくるのは人間側の意思決定の速さだということです。そこが詰まってしまうと全体のスピードも上がりません。AI-DLCは、AIの使い方だけでなく、組織の意思決定のあり方まで問い直させられる取り組みなのだと思います。

萩原：
また、重いタスクから軽いタスクまである中で、すべてのタスクにAI-DLCを適用すべきかというと、そうではありません。軽いタスクであれば、AI-DLCを使わず、そのまま実装した方が速い場合もあります。どこで使うか、どこでは使わないかの見極めも必要だと思います。

――最後に、AI-DLCに興味を持たれている方に向けた一言をお願いします。

萩原：
私自身、ワークショップに参加するまでAI-DLCがどんなものか全く分からないまま参加しました。だからこそ、まずは実際に参加してみて、どの要素が自分達の開発に合っているのかを知り、使えそうなものから少しずつ試してみることがAI-DLCによって開発生産性を高めるポイントだと思います。

本田：
私は、ワークショップを通してチーム全体がAIにより多くの作業を任せ、活用していく方向へ大きく意識転換できたと感じました。AI活用を進めるうえで、チームやプロセスの課題を見つける良い機会になると思います。

インタビューまとめ：AI-DLCで開発生産性を高めるための実践ポイント

今回のインタビューを通じて、AI-DLCを機能させるうえで重要なのは、AIの活用範囲を広げることだけではなく、開発プロセスそのものを見直すことだと分かりました。

AIを議論の初期段階から巻き込み、活用に必要なコンテキストを蓄積しながら、人間側ではレビューと意思決定の進め方を整えていく。こうした前提がそろって初めて、AI-DLCは実務の中で効果を発揮します。

そのうえで、今回のインタビューで見えてきたAI-DLCの実践ポイントは、以下の3つです。

• AIを早い段階から議論に巻き込む
• 仕様や経緯をAIが読める形で残していく
• 人間によるレビューと意思決定がボトルネックにならない進め方を設計する

実務導入の課題

AI-DLCを導入すると、まず何が起きるのか

「コードを書く速度が上がるなら、開発全体もそのまま速くなるのではないか」という期待が生まれますが、現実ではそうなるとは限りません。

例えば、これまで半日かけて書いていた設計のたたき台が30分で出るようになる。その代わり、レビューすべき文章やコードの量は一気に増える。プロダクトマネージャーが「この仕様でいきたい」と思っていたことも、AIに渡すコンテキストが曖昧で思った内容のアウトプットが得られない。ジュニアエンジニアは、単純実装をゼロから書く機会は減る一方で、AIが出したコードを「なぜこの実装なのか」と読み解く場面が増える、といった具合です。

AI-DLCの導入で最初に起きるのは「作業が楽になる」よりも先に「人間の判断が必要な場所がはっきり見えるようになる」ことです。

レビュー待ちが新しいボトルネックになりやすい

AI-DLCを試したチームが最初にぶつかりやすいのが、レビューの詰まりです。

例えば、AIが1時間で3案の設計と実装のたたき台を出したとします。すると、レビューする人間側は3案分を短時間で読み込まなければなりません。もしレビュー担当が1人しかいないと、AIによる生成速度に人間の判断速度が追いつかず、そこがボトルネックになります。

また、従来の開発手法では、設計者や実装者の頭の中にあった背景がそのままレビューの前提になっていました。一方、AI-DLCでは「なぜその設計になったか」がコードからだけでは見えにくいことがあります。そのため、レビューの負荷がより大きくなりやすい傾向があります。

仕様の曖昧さは、そのまま「出力のズレ」になる

曖昧な仕様でもAIが一見それらしい答えを返してくる点には注意が必要です。

人間同士なら「たしかにそこは決め切れていないですね」とコミュニケーションの中で情報を補完して作り込んでいく場面があります。一方でAIの場合は、あらかじめガードレールを敷いていなければ、指示の曖昧さを勝手に解釈して作ってくれるので、一見まともに見えるコードでも内容がズレてしまうことがあります。人間がそのズレに気づけなければ、後工程での手戻りにつながってしまいます。

実務導入は、小さく始めて 学びを標準化する

AI-DLCの導入は一気に広げることより、まずは小さく試してうまくいった条件を言語化することの方がおすすめです。

最初の1カ月でやることは、1つの小さな機能から始めて、次の4つのポイントを確認するだけでも十分です。

1. 要件をどこまで明文化するとAIが機能するかを見る
2. 設計・実装・テストのどこでレビュー負荷が増えるかを見る
3. 誰が判断するとスムーズかを見る
4. その結果を次につながる形で残す

人間がどこで考え、どこで止め、どこで責任を持つかをはっきりさせるほど、AI-DLCは機能しやすくなります。

既存プロダクトは新規開発より難しい

AI-DLCの話を聞くと、新規プロダクトをゼロから作る場面を想像しやすいかもしれません。しかし実際に多くの企業が向き合うのは既存プロダクトだと思います。

新規プロダクトの開発なら「今回の認証方式はこうする」「命名規則はこうする」と最初からルールを揃えられます。一方、既存プロダクトでは、過去の事情で設計が分かれていたり、コードには書かれていない運用ルールが残っていたりします。そのような暗黙知は、AIが最も苦手な領域です。AIはドキュメント化された形式知しか理解できないからです。

AIが既存コードを読んでそれらしい改善案を出したものの、実は過去の経緯や業務制約に触れていた、というケースが実務では起きやすくなります。

そのため、既存プロダクトへのAI-DLCの導入では、最初の適用範囲を小さく切ることが現実的です。

• 変更範囲が閉じている機能改修
• 比較的ドキュメントが残っている領域
• 影響範囲を追いやすいバックオフィス機能
• テスト観点が明確な小規模改善

ドキュメント化されていない暗黙知を形式知に変換し、AIに読ませる前提資料を最低限でも整えておくと、出力の精度はかなり変わります。

導入前に決めておきたい運用ルール

運用がうまくいくチームは、使い始める前に最低限どこまでルール化するかを決めています。

例えば、次のような点は最初に決めておくと動きやすくなります。

• どの工程でAIを使うか
• プロンプトやAI出力をどこまで記録するか
• 設計判断の根拠をどこに、どのように残すか
• セキュリティや権限まわりは誰が最終責任を持つか

粗くても共通ルールがあれば、うまくいった理由も失敗した理由もチームに知見が蓄積されます。

FAQ

AI-DLC（AI駆動開発ライフサイクル）とは何ですか？

AI-DLC（AI-Driven Development Lifecycle：AI駆動開発ライフサイクル）とは、クラウドコンピューティングサービス大手のAWS（Amazon Web Services）が提唱する、要件定義から設計、実装、テスト、改善までの開発工程全体に生成AIを組み込み、AIが計画・実行を主導し、人間が監督・承認を担う開発アプローチです

アジャイル開発とAI-DLCの違いは何ですか？

アジャイル開発は、短いサイクルで価値を検証しながら改善を重ねる進め方です。AI-DLCは、要件定義から改善までの各工程にAIを前提として組み込む方法論です。対立関係にはなく、既存のアジャイル運用の上にAI-DLC的な進め方を重ねることが現実的です。

AWS以外のクラウド環境でもAI-DLCは実践できますか？

はい、実践できます。AI-DLCは「どのクラウドを使うか」ではなく「AIに何を任せ、人間がどこで判断するか」を開発プロセスとして設計できるかどうかです。

AI-DLCワークショップには誰が参加すべきですか？

要件を説明できる人、技術的な妥当性を判断できる人、品質やレビュー観点を持てる人がそろうチームが向いています。PM、QA、デザイナーなど異なる職種の面々が同じ画面を見ながら進める形が機能しやすくなります。

導入前に最低限そろえるべきものは何ですか？

小さく試せるテーマ、判断できるメンバー、要件の前提をそろえる場の3つです。

何人規模のチームから始めるのが現実的ですか？

最初の実践なら3〜5人程度の少人数から始めるのが現実的です。

アジャイルをすでに導入している場合、AI-DLCへ移行すべきですか？

全面的に置き換える前提で考えなくてかまいません。既存のアジャイル運用の上に、要件整理・設計・レビューの一部からAI-DLC的な進め方を重ねて小さく検証する方が現実的です。

AWS AI-DLCワークショップはどこで申し込めますか？

AI-DLC Unicorn Gymなどのワークショップは、AWSの担当者やパートナー経由で案内されるケースが多いです。ワークショップの体験を検討したい場合は、担当のAWSアカウントチームに相談してみるのがよいでしょう。

まとめ

AI-DLCは、AIを開発の一部分に使う考え方ではなく、要件定義から設計、実装、テスト、改善までのプロセス全体を、AI前提で組み直していくアプローチです。

実務の場面で変わるのは、コードを書く速度だけではありません。要件の曖昧さを早い段階で洗い出し、設計や実装のたたき台を素早く作り、短いサイクルで認識を合わせながら開発を進めていく。そうしたプロセス全体の進め方が変わることこそがAI-DLCの本質です。

その一方で、人間の役割が小さくなるわけではありません。むしろAIに任せる範囲が広がるほど、人間には要件を明確にする力、出力を読み解く力、そして意思決定する力がこれまで以上に求められます。

ぜひAI-DLCの考え方やメリットを理解して自分たちの組織に合うかどうか一度検討してみてはいかがでしょうか。

関連記事

• 「3カ月かかる開発を3日で」── AWSの支援によるAI-DLC体験から見えたAI駆動開発のプロセス変革（マイナビニュース）

• AIが書き、人が読む時代、読書がスキルになる（Findy Tech Blog）

参考資料・関連リンク

• ※1 AWS「AI-Driven Development Life Cycle: Reimagining Software Engineering」AWS DevOps & Developer Productivity Blog, 2025年7月31日

• ※2 AWS「AI-Driven Development Lifecycle (AI-DLC) Method Definition」（ホワイトペーパー）, 2025年

• ※3 AWS「Open-Sourcing Adaptive Workflows for AI-Driven Development Life Cycle (AI-DLC)」AWS DevOps & Developer Productivity Blog, 2025年11月30日

• ※4 awslabs「aidlc-workflows」GitHub, 2025年〜

• ※5 AWS「AI 駆動開発ライフサイクル: ソフトウェアエンジニアリングの再構築」Amazon Web Services ブログ（日本語）, 2025年

• ※6 AWS「東京海上日動システムズ株式会社様の AWS 生成 AI 事例：金融業界初 AI-DLC Unicorn Gym による開発変革への挑戦」Amazon Web Services ブログ, 2025年9月26日

• ※7 AWS「11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト」Amazon Web Services ブログ, 2026年2月6日

• ※8 「AI-DLC 導入を加速させたのは「人」の「つながり」だった」AWS builders-flash,2026年1月5日