LIFULL Advent Calendar 2025

AI-DLCスターターキットで始める、一人AI駆動開発

Last updated at 2025-12-08Posted at 2025-12-06

はじめに

「AIを使って開発効率を上げたい」——多くの開発者がそう考える時代になりました。

ChatGPTやClaude、GitHub Copilotなど、AIツールは日々進化しています。しかし、「とりあえずAIに聞いてみる」という使い方では、場当たり的になりがちです。

本記事では、AWSが提唱するAI-DLC（AI-Driven Development Lifecycle）という開発手法と、それを実践するためのスターターキットを紹介します。さらに、筆者が約1ヶ月間、一人でAI-DLCを実践した体験談もお伝えします。

想定読者:

AIを活用した開発に興味がある方
一人開発や小規模チームで効率化を図りたい方
「AIとの協働」を体系的に行いたい方

AI-DLCとは

AI-Driven Development Lifecycle

AI-DLC（AI-Driven Development Lifecycle）は、AWSが提唱するAIを開発プロセスの中心に据えた新しい開発手法です。2025年にAWS公式ブログで発表され、awslabs/aidlc-workflowsリポジトリも公開されています。

従来のSDLC（Software Development Lifecycle）やAgileが「人間中心・長期サイクル」を前提としているのに対し、AI-DLCは「AI主導・短サイクル」で開発を推進します。

参考: AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 | Amazon Web Services ブログ

LIFULLでのワークショップ

AI-DLCは机上の空論ではなく、実際の企業での適用も始まっています。LIFULLでもAWS様の協力のもとによるAI-DLC Unicorn Gymワークショップが開催され、組織的なAI活用による開発生産性向上に取り組んでいます。

参考: 株式会社 LIFULL 様の AI-DLC Unicorn Gym 実践レポート | Amazon Web Services ブログ

3つのフェーズ

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

Inception Phase（要件定義）

開発の目的と狙い（Intent）を定義し、それを独立した価値提供ブロック（Unit）に分解するフェーズです。

Intent: 開発の目的と狙いを明確化
Unit: Epic/Subdomainに相当する独立した作業単位
ユーザーストーリーの作成と優先順位付け

AIが対話形式で要件を整理し、人間は方向性の確認と承認を行います。

Construction Phase（実装）

Inceptionで定義されたUnitを実装するフェーズです。

ドメイン設計: DDDに従ったビジネスロジックの構造化
論理設計: 非機能要件を反映したアーキテクチャ設計
コード生成・テスト: BDD/TDDに従った実装

AIが設計ドキュメントとコードを生成し、人間はレビューと承認を担当します。

Operations Phase（運用）

実装したシステムをデプロイし、運用するフェーズです。

デプロイ手順の策定と実行
監視・ロギングの設定
運用ドキュメントの整備

従来手法との比較

観点	SDLC	Agile	AI-DLC
主導者	人間	人間（チーム）	AI
サイクル	長期（ウォーターフォール）	中期（スプリント）	短期（Unit単位）
設計手法	事前に詳細設計	反復的に改善	AIが自動適用（DDD/BDD/TDD）
ドキュメント	重厚	軽量	AIが自動生成・更新
人間の役割	作業者	協調者	承認者・判断者

SDLCとの違い

SDLCは要件定義→設計→実装→テスト→運用という直線的なプロセスを人間が主導します。各フェーズの成果物は人間が作成し、次のフェーズへ引き継ぎます。AI-DLCでは、これらの成果物をAIが生成し、人間は品質チェックと承認に集中します。

Agileとの違い

Agileはチームの協調と反復的な改善を重視し、短いスプリントで価値を提供します。AI-DLCはさらに短いサイクル（Unit単位）で動作し、AIがスプリントプランニングやタスク分解を担当します。人間はプロダクトオーナーとして方向性を示し、最終判断を下す役割を担います。

AI-DLCの主要原則

会話の反転

従来: 人間が質問し、AIが回答する
AI-DLC: AIが計画を提示し、人間が承認・判断する

この反転により、人間は細かい作業から解放され、意思決定に集中できます。AIは「次に何をすべきか」を提案し、人間は「それでよいか」を判断します。

設計技法の統合

AI-DLCでは、以下の設計技法をAIが自動的に適用します。

DDD（Domain-Driven Design）: ビジネスドメインを反映した設計
BDD（Behavior-Driven Design）: 振る舞いを起点としたテスト設計
TDD（Test-Driven Development）: テストファーストの実装

人間がこれらの技法を意識的に適用する必要はなく、AIが適切なタイミングで適用します。

適応的インテリジェンス

awslabs/aidlc-workflowsでは「適応的インテリジェンス」という特性が強調されています。

コンテキスト認識: プロジェクトの状況を理解した上での提案
リスク評価: 変更のリスクを評価し、適切な対応を提案
質問駆動型アプローチ: 不明点を質問で解消しながら進行
ユーザーコントロール: 最終判断は常に人間が行う

冪等性の保証

各ステップで既存成果物を確認し、差分のみを更新します。これにより：

同じ操作を複数回実行しても結果が変わらない
中断からの再開が容易
変更の追跡と履歴管理が明確

AI-DLCは、AWSが提唱するAIの能力を最大限に活かすための開発手法です。人間は作業者から判断者へと役割を変え、AIがドキュメント生成や実装の大部分を担当します。

では、このAI-DLCを実際に使うにはどうすればよいのでしょうか。次のセクションでは、筆者が作成した「スターターキット」を紹介します。

AI-DLCスターターキット

スターターキットとは

AI-DLCスターターキットは、AI-DLCを実践するためのテンプレート集です。

前述のLIFULLでのAI-DLC Unicorn Gymワークショップに参加した後、AWSの公式ホワイトペーパーに影響を受けながら作成しました。ホワイトペーパーは概念とワークフロー定義が中心ですが、スターターキットはそれを実際のプロジェクトで使えるプロンプトとテンプレートとして具体化したものです。

リポジトリ: ikeisuke/ai-dlc-starter-kit

スターターキットの構成

スターターキットは主に以下の2つで構成されています。

prompts/: フェーズ別プロンプト

各フェーズで「何をすべきか」が記載されたプロンプトファイルです。AIにこのプロンプトを読み込ませることで、AI-DLCのワークフローが開始されます。

inception.md: Intent定義、Unit分解、ユーザーストーリー作成
construction.md: ドメイン設計、論理設計、コード・テスト生成
operations.md: デプロイ、監視設定、運用引継ぎ

templates/: ドキュメントテンプレート

各種成果物のテンプレートです。AIがこれらを参照してドキュメントを生成します。

Intent、Unit定義、ユーザーストーリー
ドメインモデル、論理設計
実装記録、テスト記録
デプロイチェックリスト、監視戦略

使い方フロー

1. セットアップ

まず、AI-DLCスターターキットをCloneします。次に、開発するリポジトリ上でコーディングエージェント（Claude Code等）を起動し、スターターキットのセットアッププロンプトを指定して実行します。

以下のファイルを読み込んで、サイクル v1.0.0 のセットアップを実行してください：
/path/to/ai-dlc-starter-kit/prompts/setup-prompt.md

AIが開発リポジトリ内にサイクル用のディレクトリ構造と初期ファイルを作成します。

2. Inception Phase

要件定義とUnit分解を行います。

以下のファイルを読み込んで、サイクル v1.0.0 の Inception Phase を開始してください：
docs/aidlc/prompts/inception.md

AIが対話形式でIntent（開発目的）を明確化し、それを独立したUnit（作業単位）に分解します。

ここで最も重要なのは、人間が自分の目指す方向を明確にすることです。AIは質問を投げかけ、選択肢を提示しますが、最終的な判断は人間が行います。「なんとなくAIに任せる」のではなく、自分が何を作りたいのか、どこに向かいたいのかを明確に持って承認・却下を判断してください。方向性が曖昧なままAIの提案を承認し続けると、よくわからないものにたどり着いてしまいます。

成果物:

Intent（開発目的と狙い）
ユーザーストーリー
Unit定義と依存関係

3. Construction Phase

設計と実装を行います。

以下のファイルを読み込んで、サイクル v1.0.0 の Construction Phase を開始してください：
docs/aidlc/prompts/construction.md

AIがUnit単位で設計ドキュメントとコードを生成します。人間は各ステップでレビューと承認を担当します。

成果物:

ドメインモデル設計
論理設計
実装コード
テストコード

4. Operations Phase

デプロイと運用を行います。

以下のファイルを読み込んで、サイクル v1.0.0 の Operations Phase を開始してください：
docs/aidlc/prompts/operations.md

AIがデプロイ手順、監視設定、運用ドキュメントを作成します。

成果物:

デプロイチェックリスト
監視・アラート設定
運用引継ぎドキュメント

実際の使用例

この記事自体がスターターキットで作成されている

実は、この記事自体がスターターキットを使って作成されています。

サイクル名: extra-adventcalendar-2025
Intent: AI-DLCとスターターキットを紹介するアドベントカレンダー記事を執筆する
開発ブランチ: cycle/extra-adventcalendar-2025

アプリケーション開発ではないため、簡易的な利用として記事の各セクションをUnitとして定義しています。

Unit	内容	状態
Unit-1	AI-DLC概念説明セクション	完了
Unit-2	スターターキット解説セクション	完了
Unit-3	一人AI-DLC体験談セクション	完了
Unit-4	本質と一人実践の差異考察	完了
Unit-5	記事全体の構成・まとめ	完了

AIが計画を提示し、人間（著者）が承認して進める—まさにAI-DLCの「会話の反転」を実践しています。

スターターキット自体もスターターキットで開発されている

さらに面白いことに、スターターキット自体もスターターキットを使って開発・改善されています。

プロンプトやテンプレートを改善する際も、AI-DLCのワークフローに従って進めています。つまり、スターターキットは「自分自身を使って自分自身を進化させる」というメタ構造を持っています。

この構造により、スターターキットの改善がそのまま次回の開発体験の改善につながります。

スターターキットのメリット

構造化された進行: 何をどの順番でやるべきかが明確
中断と再開が容易: progress.mdで進捗を管理し、途中からでも再開可能
履歴の自動記録: history.mdに作業履歴が自動で追記される
冪等性: 同じプロンプトを再実行しても、完了済みの作業はスキップされる

AI-DLCはAI Driven Development Life Cycleの名の通り、基本的にはソフトウェア開発ワークフローに特化した手法ですが、このように記事執筆などにも応用できます。

スターターキットの説明は以上です。次のセクションでは、筆者が実際にAI-DLCを1ヶ月間実践した体験談をお伝えします。

一人AI-DLC体験談

実践したプロジェクト

2025年11月から約1ヶ月間、以下のiOSアプリでAI-DLCを実践しました。

MimiLoop: 英語発音練習アプリ
のりごろ: バス時間案内アプリ
Tumblium: Tumblrクライアント（参考：AI-DLC未使用）

リリース頻度の変化

AI-DLCを本格的に導入したのは11月7日頃です。導入前後でのリリース申請頻度を比較してみます。

導入前: 10/16, 10/29, 11/2 x 2
導入後: 11/9, 11/14, 11/28, 12/5

リリース頻度は変わらないですね。AIを使った開発と言う意味では一定の成果は挙げられています。
AI-DLCスターターキットを整備しながらと言うことでまだ型ができていないのでスピードは上がっていないですが、リリースノートなどの管理含めとても良くなる未来が見えています。

過去との比較

参考として、Tumbliumは10年以上前から開発しているアプリですが、当時はリリース申請まで短くても数日〜1週間かかっていました。AI-DLCというよりもAIでの時間差というのは大きいですが、開発サイクル自体も今とは比較にならないほど遅かったです。

工夫した点

スターターキットによる「型」の確立

AI-DLCを実践する以前も、GitHub Issueを活用したり、リポジトリ上で管理したりしていました。しかし、一定の手順で進めることが難しく、都度やり方がブレていました。

スターターキットを作成したことで「型」ができました。型があることで：

毎回同じ手順で進められる
その場での多少のアレンジも柔軟にできる
ドキュメントがしっかり残る

この「型」の存在が最も大きな変化でした。

サイクル間の情報共有

AI-DLCを進める中で、サイクル間での情報共有が課題になりました。各サイクルは独立していますが、実際には前のサイクルの知見を次に活かしたい場面が多々あります。

工夫として：

バックログを共有場所に配置: サイクルをまたいで参照できるようにした
デプロイ手順の共通化: 継続的に実行する部分は共通の場所に置き、Operations Phaseから参照して同じことができるようにした

一人+AI二体の「三人体制」

一人開発でも、AIを複数活用することでチーム開発に近い体制を構築しました。

Claude Code: メインの開発作業を担当
Codex（MCP経由）: レビューを担当

レビューを別のAIに投げることで、一人+AIというより「三人で進めている」感覚で開発できました。

課題

チーム開発機能の不足

AI-DLCは本来、プロダクトマネージャー、エンジニア、QAなど複数人が一堂に会して進めることを想定しています。スターターキットでは、この部分を十分に担保できていません。

一人開発では、これらの役割を自分一人（+AI）で担う必要があり、本来のAI-DLCの強みを完全には活かせていないという課題があります。

学び

インテントは人間の責任

インテント（開発の目的と狙い）はAIには用意できない部分です。そして、AIの出力結果の責任は、指示をした人間が負うべきです。

各ステップの出力を自分が理解し、責任を持って承認することがとても大事だと考えています。

AIの出力品質も人間の責任

AIの性能がかなり向上している今、本当に人間がやる数倍の速度で高品質なものをアウトプットしてくれます。しかし、その品質さえも自分自身の指示やレビューの責任です。

「なんとなくAIに任せる」のではなく、出力を理解し、必要に応じて修正指示を出し、最終的な品質に責任を持つ。この姿勢がAI-DLCを成功させる鍵だと感じています。

体験談は以上です。ここまで読んで「AI-DLCは本来チーム向けなのでは？」と思った方もいるかもしれません。次のセクションでは、AI-DLCの本質と一人実践の違いについて考察します。

AI-DLCの本質と一人実践の差異

AI-DLCの本質的な前提

AI-DLCはAWSが提唱する開発手法です。LIFULLでのワークショップ事例を見ても分かるように、本来は組織・チームでの活用を想定しています。

チームでの役割分担

AI-DLCの「会話の反転」という原則は、本来以下のような役割分担を前提としています。

プロダクトマネージャー: Intentの設定、優先順位の決定
エンジニア: AIが生成したコードのレビュー、技術的判断
QA: テスト戦略の承認、品質基準の設定
AI: 計画の提案、ドキュメント・コード生成

各役割の専門家が、AIの出力を自分の専門領域でレビュー・承認します。これにより、多角的な視点での品質担保が可能になります。

組織的な知見共有

チーム開発では、AI-DLCを通じて以下の効果が期待できます。

AIとの対話ログがナレッジとして蓄積
同じプロンプトパターンの共有による生産性向上
レビュープロセスを通じたチーム内のスキル標準化

一人実践で活かせる点

では、一人開発ではAI-DLCは無意味なのでしょうか。そうではありません。以下の点は一人でも十分に活かせます。

「型」による開発プロセスの標準化

スターターキットによる「型」の存在が最大の価値です。

毎回同じ手順で進められる安心感
場当たり的な開発からの脱却
ドキュメントが自然と残る仕組み

一人開発こそ、自分なりのルールが曖昧になりがちです。AI-DLCの型がこれを防いでくれます。

AIとの対話による要件の明確化

Inception Phaseでの対話は、一人でも有効です。

AIに「何を作りたいのか」を説明する過程で、自分自身の考えが整理されます。言語化することで、曖昧だった要件が明確になっていきます。これは「ラバーダック・デバッグ」に近い効果です。

冪等性による中断・再開の容易さ

AI-DLCの冪等性の原則は、一人開発で特に重要です。

作業の途中で中断しても、progress.mdを見れば状態が分かる
数日後に再開しても、前回の続きからスムーズに始められる
AIのコンテキストがリセットされても、ドキュメントから復元できる

副業や趣味で開発する場合、まとまった時間が取れないことも多いです。冪等性があれば、細切れの時間でも開発を進められます。

一人実践の限界

一方で、以下の点は一人実践では限界があります。

複数視点によるレビューの欠如

チーム開発では、PM、エンジニア、QAがそれぞれの視点でレビューします。一人だと、どうしても視野が狭くなります。

自分では気づけないUXの問題
専門外の領域での判断ミス
「これでいいか」と妥協しがち

インテント設定の責任が一人に集中

AI-DLCで最も重要なのはIntent（開発の目的と狙い）です。これはAIには設定できません。

チームなら複数人でIntentを議論し、洗練できます。一人だと、自分の思い込みがそのままIntentになってしまうリスクがあります。「本当にこれが必要か」を問い直す機会が少ないのです。

対話が自問自答になりがち

Inception Phaseでの対話は、本来は異なる立場の人との議論です。一人だと、AIとの対話が「自分の考えをAIに言わせている」だけになることも。

多様な意見がぶつかることで生まれるイノベーションは、一人実践では期待しにくい部分です。

一人でも工夫できる点

限界はありますが、工夫次第で軽減できます。

複数AIの活用

「三人体制」は有効なアプローチです。

開発用AI: メインの実装を担当
レビュー用AI: 別のAI（または別セッション）でレビュー

同じAIでも、「レビュアーとして批判的に見てください」とプロンプトを変えれば、異なる視点を得られます。

時間を置いてのセルフレビュー

書いた直後は気づけない問題も、時間を置くと見えてきます。

1日寝かせてからレビュー
別の作業をしてから戻ってくる
印刷して紙で読む（視点が変わる）

コミュニティでの知見共有

一人開発でも、コミュニティとつながることで「チーム」に近い効果を得られます。

勉強会やカンファレンスでの発表
ブログやSNSでの情報発信
OSS活動を通じたフィードバック

この記事自体も、その一環です。

一人AI-DLCの価値

一人実践は、本来のAI-DLCとは確かに異なります。チーム開発の強みを完全に再現することはできません。

しかし、AI-DLCのエッセンスは一人でも十分に活用可能です。

観点	チーム実践	一人実践
型・プロセス	完全に活用可能	完全に活用可能
AIとの対話	チーム全員で活用	一人で活用可能
多角的レビュー	自然に発生	工夫が必要
Intent設定	議論で洗練	自己責任
知見共有	チーム内で自然に	コミュニティで補完

重要なのは、「完璧なAI-DLC」を目指すのではなく、自分の状況に合わせてエッセンスを取り入れることです。

おわりに

AI-DLCがもたらす変化

本記事では、AWSが提唱するAI-DLC（AI-Driven Development Lifecycle）と、それを実践するためのスターターキットを紹介しました。

AI-DLCの核心は 「会話の反転」 です。人間が質問してAIが答えるのではなく、AIが計画を提示して人間が承認する。この発想の転換により、人間は細かい作業から解放され、本当に重要な意思決定に集中できます。

一人でも始められる

AI-DLCは本来チーム向けの手法ですが、一人開発でも十分に価値があります。

「型」による開発プロセスの標準化で、場当たり的な開発から脱却
冪等性と進捗管理で、細切れの時間でも開発を継続
複数AIの活用で、擬似的なチーム体制を構築

完璧を目指す必要はありません。自分の状況に合わせて、使えるところから取り入れてみてください。

スターターキットを試してみる

AI-DLCに興味を持った方は、ぜひスターターキットを試してみてください。

リポジトリ: ikeisuke/ai-dlc-starter-kit

プロンプトを読み込ませるだけで、AI-DLCのワークフローが始まります。この記事自体がスターターキットで作成されているように、コード開発以外のタスクにも応用できます。

参考リンク

この記事がAI-DLCの理解と実践の一助になれば幸いです。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up