AI 駆動開発ライフサイクル（AI-DLC）を試してみた

はじめに

こんにちは、リテールハブ開発部の杉森です。

近年、AIを活用した開発ツールが急速に普及しています。私たちのチームでも積極的にAIツールを導入し、要件定義でのユーザーストーリー作成、設計ドキュメントの生成、コードの自動補完、テストコードの生成など、各開発フェーズの作業効率化を図ってきました。

しかし、個々の作業は確かに早くなっているのに、プロダクト開発フロー全体を見ると期待したほどの生産性向上を実感できないという課題に直面しました。

本記事では、この課題に対するアプローチとして導入を検討しているAI-DLC（AI-Driven Development Lifecycle）について紹介します。

AI-DLCとは

AI-DLCは、AWSが提唱するAIネイティブな開発方法論です。方法論のホワイトペーパーで理論的な枠組みが定義されており、これを実装するためのワークフローがaidlc-workflowsとしてGitHub上で公開されています。

AWSの公式ブログでは、現在のAI活用における2つのアンチパターンが指摘されています。

AI-Assisted: 人間が設計を主導し、AIはコード補完など狭い範囲の支援にとどまる。生産性向上は限定的で、AIの能力を十分に引き出せない
AI-Managed: 複雑な問題をAIに丸投げし、自律的にすべてを解決することを期待する。出発点が曖昧なためAIが多くの仮定を立て、プロトタイプ以外ではほぼ機能しない

AI-DLCは、これらのアンチパターンに対するアプローチとして設計されています。AIが作業計画の作成やタスク分解を主導し、人間がその内容を検証・承認し、AIが承認された計画に基づいて実行するというサイクルで、開発ライフサイクル全体を進めます。

従来の開発手法との違い

AI-DLCは、既存の開発手法にAIを後付けするのではなく、AIを前提とした開発プロセスをゼロから設計しています。ホワイトペーパーでは、以下の設計思想が示されています。

AIが会話を主導する: 従来は人間がAIに指示を出していたが、AI-DLCではAIがタスク分解や提案を行い、人間は承認・判断に集中する
Intent / Unit / Bolt: ビジネス目標（Intent）を作業単位（Unit）に分解し、数時間〜数日の短いサイクル（Bolt）で実装を回す。ScrumのSprintに近いが、サイクルが短い
各ステップで人間がチェックする: AIの出力を段階ごとに検証し、誤りを早期に検出する。ホワイトペーパーでは「損失関数のように機能する」と表現されている
設計技法を方法論に組み込む: ScrumやKanbanがチームに委ねていたDDD等の設計技法を、方法論の一部として標準化する

aidlc-workflowsの設計原則

aidlc-workflowsは、上記の設計思想を実装するにあたり、以下の5つの設計原則に基づいています。

原則	説明
No Duplication	設定やルールを一箇所で管理し、重複を排除する
Methodology First	特定のツールに縛られず、方法論そのものを軸にする
Reproducible	ルールを明文化し、使うAIモデルが変わっても結果がぶれないようにする
Agnostic	IDE・エージェント・モデルを問わず動作する
Human in the Loop	重要な判断には必ず人間の承認を挟む

3フェーズ構成

AI-DLCは、以下の3つのフェーズで構成されています。

INCEPTION PHASE: WHATとWHYの決定
CONSTRUCTION PHASE: HOWの実装
OPERATIONS PHASE: デプロイと監視（aidlc-workflows上は未実装）

INCEPTION PHASE

「何を作るか（WHAT）」「なぜ作るか（WHY）」を決定するフェーズです。方法論のホワイトペーパーでは「Mob Elaboration」というプラクティスとして定義されており、共有画面を使ってチーム全体でAIの質問と提案を検証します。AIがビジネス意図（Intent）を明確化する質問を投げかけ、ユーザーストーリー、非機能要件、リスク記述を生成し、凝集度の高い作業単位（Unit）へ分割します。

aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。

ステージ	説明
Workspace Detection	プロジェクトの状態を分析（新規/既存の判定）
Reverse Engineering	既存コードベースの理解（Brownfieldの場合）
Requirements Analysis	要件の収集と整理
User Stories	ユーザーストーリーの作成
Workflow Planning	実行計画の策定
Application Design	アプリケーション設計
Units Generation	作業単位への分割

CONSTRUCTION PHASE

「どう作るか（HOW）」を決定し、実際にコードを生成するフェーズです。方法論のホワイトペーパーでは、Domain Design（ビジネスロジックのドメインモデリング）→ Logical Design（非機能要件を含むアーキテクチャ設計）→ Code & Unit Tests（コードとテストの生成）→ Deployment Units（デプロイ可能な成果物の構築）という流れで進みます。「Mob Construction」でチームがリアルタイムで技術的決定とアーキテクチャの選択を行います。

aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。

ステージ	説明
Functional Design	機能設計（ユニットごと）
NFR Requirements/Design	非機能要件の設計
Infrastructure Design	インフラ設計
Code Generation	コード生成
Build and Test	ビルドとテスト

OPERATIONS PHASE

デプロイと監視を担当するフェーズです。方法論としては定義されていますが、aidlc-workflowsには含まれておらず、将来的にワークフローが追加される予定です。

対応プラットフォーム

公式では以下のプラットフォームがサポートされています。

Kiro CLI
Amazon Q Developer IDE plugin
Kiro IDE（Coming Soon）

試してみる

導入の背景

私たちのチームの課題は、まさにAI-Assistedパターンに該当します。AIを個々の作業の効率化には活用できているものの、生産性向上は限定的にとどまっていました。

私たちのチームでは、Kiro CLIをすぐに使える環境ではなかったため、Claude Code向けにカスタマイズして使用しました。AI-DLCはツールに依存しない設計を謳っているため、ルールファイルを調整すれば他のAIツールでも問題なく適用できると考えています。

Claude Code向けのカスタマイズ

以下のようにClaude Code向けにカスタマイズしました。

1. カスタムコマンド（スキル）の作成

.claude/commands/aidlc.md にワークフロー定義を配置し、/aidlc コマンドで起動できるようにしました。

.claude/
├── commands/
│   ├── aidlc.md          # メインワークフロー
│   ├── aidlc-pr.md       # PR作成用
│   └── aidlc-archive.md  # アーカイブ用
└── aidlc-rule-details/
    ├── common/           # 共通ルール
    ├── inception/        # INCEPTIONフェーズ
    ├── construction/     # CONSTRUCTIONフェーズ
    └── operations/       # OPERATIONSフェーズ

2. ルールファイルの分割

各ステージの詳細指示を .claude/aidlc-rule-details/ 以下に分割配置しています。これにより、AIが必要なタイミングで必要なルールのみを読み込み、コンテキストを効率的に使用できます。

クーポン機能を題材にした検証

AI-DLCの有効性を検証するため、小売向けアプリのクーポン機能開発を題材に検証を実施しました。

検証概要

対象システム: Flutter + Laravel + Vue.js + Goで構成されたマルチプラットフォームアプリ
題材: ポイント後付けクーポンと即時値引きクーポンの2種類
検証範囲: モバイルアプリ、管理画面、バックエンドAPI、バッチ処理
チーム構成: PdM1人+エンジニア2人

検証の進め方

「クーポン機能を追加したい」というビジネス意図（Intent）を起点に、AI-DLCのフェーズに沿って進めました。

INCEPTION PHASE（3人で実施）: AIが要件を深掘りする質問を投げかけ、ユーザーストーリーや非機能要件を生成。PdMとエンジニアがその内容を検証・修正し、作業単位（Unit）に分割
CONSTRUCTION PHASE（1人で実施）: Unitごとにドメイン設計、コード生成、テスト生成を実施。各ステージでAIの出力を確認し、承認・修正を繰り返した

今回は検証目的だったこともあり、各フェーズ半日ずつの計1日で実際に動くものまで作成できました。Inceptionフェーズの要件・設計をより作り込み、Constructionフェーズではガードレールの整備やAIが自律的に改善できる体制を組むことで、さらに短縮できる余地があると感じています。

実際の様子

AIからの深掘り質問（Inceptionフェーズ）

Requirements Analysisでは、AIが要件の曖昧な部分を選択肢付きで質問してきます。以下はその一例です。

AI: クーポン利用状態の管理について確認させてください。ユーザーがクーポンを「利用」した後の状態管理はどうなりますか？

A) 1回利用したら即座に使用済みになる（再利用不可）

B) 有効期限内であれば何度でも利用可能

C) クーポンごとに利用回数を設定可能（1回、3回、無制限など）

AI: クーポンの種類と適用範囲について確認させてください。

A) 全ての種類が両方のクーポンタイプで使用可能

B) クーポンタイプごとに使用可能な種類が決まっている

このように、AIが仕様の選択肢を提示し、人間が判断するというサイクルでRequirements Analysisが進みます。初回の質問10問、追加の深掘り質問6問を経て、要件定義ドキュメントが生成されました。

人間による設計修正（Inceptionフェーズ）

Application Designでは、AIが設計の選択肢を提示し、人間が判断するケースがありました。

人間: アクティブユーザーではないユーザーにもレコードが作成されてしまいませんか？

AI: 2つの選択肢があります。

A) クーポン公開時に全ユーザー分のuser_couponsレコードを作成

B) クーポン利用開始時にのみuser_couponsレコードを作成

人間: B

生成されたユーザーストーリー（Inceptionフェーズ）

User Storiesでは、管理者向け6件、会員ユーザー向け6件、システム向け1件の計13件が生成されました。以下はその一部です。

US-01: クーポン新規作成

As a 管理者 I want to 管理画面から新しいクーポンを作成したい So that 会員ユーザーに対してキャンペーンを提供できる

Acceptance Criteria:

クーポンタイプ（ポイント後付け/即時値引き）を選択できる

クーポン名と説明文を入力できる

有効期限（開始日・終了日）を設定できる

対象店舗を選択できる

生成されたコード（Constructionフェーズ）

Constructionフェーズでは、Unitごとにドメイン設計 → コード生成 → テスト生成が進みます。最終的に以下の規模のコードが生成されました。

Unit	対象	生成ファイル数	主な成果物
Backend	Laravel	51ファイル	Enum, Model, Migration, Service, Controller, Test
Dashboard	Vue.js	16ファイル	Composable, Component, Schema, Page
Mobile	Flutter	38ファイル	Entity, Repository, Provider, Widget, Page

わかったこと / 今後の展望

良いと感じた点

実際にAI-DLCを触ってみて、以下の点が良いと感じました。

Human in the Loopの実現: AIが実行し、人間が監視するという関係性が明確。各ステージで人間の承認が必要なため、重要な意思決定は人間がコントロールできる
コンテキストの保存と再開: aidlc-state.mdでプロジェクトの状態を追跡しているため、セッションが途切れても前回の続きから再開できる
ドキュメント化による追跡可能性: audit.mdにすべてのやり取りが記録されるため、なぜその決定をしたのかを後から追跡できる
適応的なワークフロー: プロジェクトの複雑さに応じて、実行するステージが自動的に調整される

試した上で見つかった課題

Inception前の準備の必要性

今回「クーポン機能を追加したい」というリクエストからInceptionを開始しましたが、背景知識や「なぜこの機能が必要なのか」がアウトプットに反映されにくいことがわかりました。また、要件の解像度が低い状態でInceptionを始めると、議論が発散しやすくなります

AI-DLCのInceptionに入る前に、ビジネス背景や目的を整理するステップが必要だと感じました。

仕様とAI実装のギャップ

Inceptionフェーズで仕様を決め切った上でも、以下の2つの問題が発生しました。

仕様の記載漏れ: Inceptionフェーズで決めた仕様に漏れがあり、Constructionフェーズで初めて気づくケース。例えば、APIレスポンスのラッパー形式やお気に入り店舗のパラメータなど、実装段階で判明した考慮漏れがありました
仕様通りに実装されない: 仕様として記載されているにもかかわらず、AIが異なる実装をするケース。例えば、既存の認証方式と異なるパターンで実装したり、既存のアーキテクチャパターンに従わない実装が生成されることがありました

前者は要件定義やアプリケーション設計の精度を上げていく必要があります。今回検証だったので細部まで確認できていないところがありました。そのため、実業務に導入した場合はよりこの部分に時間を使うべきだと思いました。後者はモデルの進化を待ちつつ、コンテキストの渡し方の工夫や、実装が仕様に準拠しているかを監査するサブエージェントの整備など、ガードレールを張っていくことが必要だと感じました。

コンテキスト管理の課題

AIツール固有の課題として、コンテキスト管理の難しさがあります。実装フェーズではコードの読み書きが多く発生するため、auto-compact（コンテキストの自動圧縮）が頻発しました。その結果、audit.mdへの書き込みが不安定になったり、要件定義ファイルへの指摘を繰り返してもアウトプットに反映されないことがありました。

対策として、コンテキストの使用量を抑えるためにルールファイルを分割して必要なタイミングでのみ読み込む方式にしたり、サブエージェントを活用して処理を分散させるなどの工夫が必要です。

レビュー負荷への対応

AIのアウトプット量が増えることで、人間のレビュー負荷が増大するという課題があります。この課題に対しては、以下のアプローチを検討しています。

レビューを軽減するプロセスの構築: 自動テストやLintの活用
AIの出力品質を上げる工夫: プロンプトの改善、ルールの整備
段階的なレビュー: 各ステージでの承認による分散

これらの最適解は、チームやプロダクトによって異なるため、継続的に改善していく必要があります。

最後に

AI-DLCは、AIを活用した開発における「ボトルネックを特定し、解消していく」ためのフレームワークとして有望だと感じています。

今回見えてきた課題はAI-DLCのフレームワーク自体の問題ではなく、AIと人間が協働する上で必然的に発生する問題です。今後も継続的に活用しながら、チームに最適な形にカスタマイズしていきたいと考えています。

every Tech Blog

株式会社エブリーのTech Blogです。