この記事は#GauDev Advent Calendar 2025の15日目です。
はじめに
こんにちは、Gaudiyでエンジニアをしている@mrskiroです。
私が所属するチームでは、新規事業の複数立ち上げに向けてより高速に開発を行える、AIネイティブな開発フローを模索していました。AI駆動開発というキーワードは盛り上がり始めていましたが、コード生成の話が中心で開発プロセス全体をどう回すかのベストプラクティスはまだ見当たりませんでした。
そんな中で出会ったのがAWSの提唱する「AI-DLC（AI-Driven Development Lifecycle）」です。この記事では、AI-DLCを実践したこの3ヶ月間の取り組みについて紹介します。
AI-DLCとは
AI-DLC（AI-Driven Development Lifecycle）は、AWSが提唱した開発ライフサイクルの考え方です。
AI-DLCでは、「人間が主導し、AIがアシストする」という従来の形を逆転させています。AIが開発を主導し、人間はAIの成果物をレビューして意思決定に責任を持つという考え方です。
また、AIを中心にプロダクト開発を進めると、AIのアウトプット速度に対して人間のレビュー・意思決定がボトルネックになりやすいため、チーム内での同期コミュニケーションが重視されています。
AI-DLCはInception、Construction、Operationの3つのフェーズで構成されています。
| フェーズ | AIの役割 | 人間の役割 |
|---|---|---|
| Inception | 人間との対話を通じて仕様書・ユーザーストーリーを生成し、構想を具体化 | ビジネスの目的や作りたい機能の概要をインプット |
| Construction | 設計・コード・テストなどを自律的に生成 | AIが生成した成果物を専門家としてレビュー・検証 |
| Operation | パフォーマンス監視、エラー検知、ログ分析を実施。問題発見時は原因分析と修正案を提示 | AIからの報告や提案を評価し、本番適用の可否を最終判断 |
具体化するまで
AI-DLCはあくまで考え方や方法論なので、実際にどうやるかは自分たちで決める必要がありました。そのため、まずはホワイトペーパーの末尾にあるプロンプト例をClaude Codeのスラッシュコマンドとして実装し、Inceptionを試したのちに、ドキュメントの構造や保存方法を検討していきました。
0→1で作るときはプロトタイプでチーム内認識を合わせるフェーズがほしかったので、α ConstructionやInception Refiningといった独自のフェーズも追加することにしました。一方で、AI-DLCには「Bolt」というイテレーションの単位が定義されていますが、聞き慣れない用語を増やすよりシンプルにフェーズ単位で進める方が浸透しやすいと判断し、導入しませんでした。
フェーズを検討していた時期は、チームメンバーが整理してくれたFigJamを見ながら「次は何なんだっけ」「ここに戻ってもいいんだっけ」といった議論を都度していました。Unitの依存関係やデザインを反映するタイミングなど、実際に回しながら考えることも多かったです。
ツール面での苦労もあり、スラッシュコマンドを改善するたびにClaude Codeで動作確認が必要で、レートリミットに達したりAIの出力に揺れがあったりして難航することもありました。
現在運用中のフロー
Inceptionの進め方
Inceptionでは、PdM・エンジニア・デザイナーなどプロジェクトメンバーが参加し、ビジネス目標を元にIntentとユーザーストーリーを作ります。
スラッシュコマンドを実行すると、AIが「このプロダクトで解決したい課題は？」「ターゲットユーザーは？」といった質問を投げかけてきます。対話を通じて要件を具体化し、Intent（プロダクトの目的、スコープ、成功指標などをまとめたPRDに近いドキュメント）とユーザーストーリーを生成します。
実際の進め方としては、PdMが要件の言語化に集中し、エンジニアは技術的な観点から補足を入れる形で対話しながら進めています。1セッションは1時間程度で終わることが多いです。
雰囲気を伝えるため、実際のスラッシュコマンドを抜粋して紹介します。
# AI-DLC Inception Phase 現在のプロジェクトのインセプションフェーズを実行します。 AI が主導して、Intent 発見から User Stories 作成、Units 分解まで一連の流れで進めます。 ## このセッションの概要 AI-DLC 思想に基づき、以下を一連の流れで実施します： 1. **ビジネス価値の明確化** - 段階的な対話で真の Intent を発見 2. **Intent Statement 生成** - 価値、ユーザー、メトリクス、MVP を統合 3. **User Stories 作成** - Intent を User Stories に分解 4. **Units 分解** - User Stories を独立開発可能な Units に設計 5. **計画承認プロセス** - 各ステップでチェックボックス付き計画をレビュー・承認 ## Phase 1: Intent Discovery ### Intent番号の確認 1. `aidlc-docs/requirements/` ディレクトリ内の最新Intent番号（3桁: 001, 002...）を確認 2. 最新Intent番号+1を `NEXT_INTENT_NUM` とする 3. 既存Intentがあれば Brown-Field、なければ Green-Field として判定 ### Intent Discovery プロセス 私（AI）がファシリテーターとなり、対話を通じてあなたの Intent を明確にしていきます。 状況に応じて適切な質問を行いながら、以下の要素を明確化していきます： - 解決すべき問題または追求する機会 - 価値を受けるターゲットユーザー - 成功の測定方法 - MVP（数日〜1 週間で実現可能なもの） Green-Field（新規開発）でも Brown-Field（既存改善）でも、まずはあなたが取り組みたいことについて自由にお話しください。私が適切な質問で詳細を引き出していきます。 ### Intent Statement 生成 対話を通じて収集した情報を基に、Intent Statement を生成します。以下の形式でまとめます： # Intent-XXX: [簡潔で明確なビジネス目標] ## Business Value [実現するビジネス価値] ## Target Users [価値を受けるターゲットユーザー] ## Success Metrics [成功を測定する指標] ## MVP Scope [最初に実現する最小限の機能 - 数日〜1 週間で実現可能] （以下、Phase 2: User Stories 作成、Phase 3: Units 分解と続く）
α Constructionの進め方
α Constructionでは、PdM・エンジニア・デザイナーなどプロジェクトメンバーが参加し、Inceptionの内容を元にプロトタイプを作成します。
プロトタイプ用の設計を生成し、Next.jsやExpo等でプロトタイプを自動生成します。ここで作るのは「動くもの」であって、「完成品」ではありません。実際に触ってみて「これで合ってる？」を確認するのが目的です。
Inception Refiningの進め方
プロトタイプを触ると、だいたい何かしら課題が見つかります。「この画面遷移、分かりにくいな」「この機能、実は要らないかも」といった気づきです。
そういった課題をインプットすると、AIが対話を通じてIntentとユーザーストーリーを更新します。α ConstructionとInception Refiningは2〜3回繰り返すことが多いです。
β Constructionの進め方
β Constructionでは、クローズドベータ向けのプロダクトを構築します。ここからは本番を見据えた実装になります。
設計フェーズでは、まず全体設計としてDDD戦略的設計とUnit分割を行います。その後、Unitごとにドメイン設計、DB設計、API設計、UIフロー設計を進めます。設計ドキュメントは実装時に参照することが多いため、時間をかけてレビューします。
最初はチーム全員で進めていましたが、慣れてきた後半からはエンジニアのみで行うようになりました。InceptionやRefiningと違って、技術的な判断が中心になるためです。
実装フェーズでは、設計ドキュメントを参照しながらClaude CodeのSubAgentなどを用いて各メンバーが実装を進めます。いわゆる仕様駆動開発（SDD）と同様のアプローチで、Inceptionで作成したIntentやユーザーストーリーが仕様として機能するので、ある程度精度よく実装を進められます。デザインがある場合は、MCPでFigmaデータを参照しながら実装します。こちらについては@minamiが記事を書いているので、ぜひご覧ください。
なお、フローチャートに記載したConstruction以降のフェーズは、AI主体で実行していく部分をまだ模索中です。
プラグイン化
AI-DLCを実践していく中でやり方が固まってきましたが、プロジェクト固有のスラッシュコマンドとして実装していたため、他のプロジェクトでも使えるようにClaude Codeのプラグインとして切り出しました。
Claude Codeは他のCLIツールと比べてチームで設定を共有する機能が豊富で、プラグイン化に手間がかからなかったのはありがたいポイントでした。「aidlc-kit」という名前で、各フェーズに対応した以下のスラッシュコマンドを用意しています。
| コマンド | 説明 |
|---|---|
setup |
プロジェクトのセットアップ |
inception-new |
新規Intent作成 |
inception-fix |
Intent修正 |
alpha-design |
プロトタイプ用設計 |
prototype |
プロトタイプ生成 |
design-overview |
全体設計 |
design-unit |
Unit個別設計 |
task |
実装タスク生成 |
実践してみて
プロジェクトメンバーが同期でAIと一緒に要件を整理していくので、機能の実装優先度や仕様の背景について認識が揃いやすくなっています。
実際に、エンジニア3名で開発を始め、途中から1名が加わり計4名で約2ヶ月と少し、Web・モバイル・バックエンドを含むプロダクトをデリバリー直前の状態まで開発しました（リリース時期はビジネス上の理由で調整中）。
α Constructionでプロトタイプ作成とユーザーテストを何度も繰り返したおかげで、β Construction以降はほとんど手戻りなく進められました。また、AI-DLCのフロー構築自体も並行して検証していたのもあり、フローが固まった今後はもっと短縮できる余地があると考えています。
課題
AIのアウトプットが早く多いため、人間のレビューがボトルネックになりやすいです。β Constructionの設計ドキュメントのレビューだけで1〜2時間かかることもあり、レビューしやすいフォーマットの検討を進めています。
現状はClaude Codeのスラッシュコマンドやプラグインとして実装していますが、今後AIモデルや開発ツールが変わる可能性もあります。MCPやシェルスクリプトを活用し、ツールに依存しない形への切り出しも検討しています。
他チームへの展開の難しさも課題の一つです。AI-DLCの用語や、カスタマイズしたフローの学習コストが一定存在します。途中のフェーズからでも使える形や、通常の開発でも便利なコマンドを一緒に配布するなど、小さく始められる状態を目指しています。
おわりに
AI-DLCを3ヶ月実践してきました。ホワイトペーパーの概念を自分たちなりに解釈し、Claude Codeで運用できるようにしました。まだまだ課題は多いですが、従来よりスピード感を持って開発を進められています。
AI-DLCの実践に関心がある方や、すでに取り組まれている方にとって、一つの事例として参考になれば嬉しいです。
なお、私たちが独自に実践を始めた後、AWSからAI-DLCのワークフローがオープンソースとして公開されました。これから始める方はこちらも参考になると思います。
GaudiyではAI駆動開発に興味のあるエンジニアを募集しています。カジュアル面談も歓迎ですので、気になった方はぜひお声がけください。
次回の#GauDev Advent Calendar 2025はameさんの記事です。お楽しみに！
