AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと

2025/12/15に、Amazon Q Developer&Kiro Meetup #5で発表した松尾の資料になります。

Transcript

1. AI-DLC を 現場に インストール してみた： プロトタイプ開発 で分 ったこと ･やめたこと 松尾 裕幸 株式会社リクルート 住まいプロダクト開発 1 グループ 2025/12/15　Amazon Q Developer & Kiro Meetup #5
2. 自己紹介 松尾 裕幸 (まつ ひろゆ ) • 2019 年 株式会社リクルート 新卒入社 • ｢Airレジ オーダー」など い つ のサービス開発を担当 • その後、現部署 (住まい開発) で SUUMO 関連周辺システムの 開発リーダーを担当
3. Agenda 1. AI-DLC の概要を さらい 2. 実プロジェクトに導入してみた 3. AI-DLC 成功のカギ 3
4. 1. AI-DLC の概要を さらい 4 Agenda 1. AI-DLC の概要を さらい 2. 実プロジェクトに導入してみた 3. AI-DLC 成功のカギ
5. AI-DLC : AI-Driven Development Lifecycle • AWS さん 提唱する新しい開発ライフサイクル ◦ AI の能力を “フル活用” し、各種リードタイム短縮・DX 向上 5 AI-DLC のポイント 従来の AI 利用 (バイブコーディング等) では…… • 設計・実装フェーズに入って ら AI を利用 • 人間 タスク分解 し、タスクの 一部 を AI に指示 • プランニング、タスク分解・着手をすべて AI 主体で行う ◦ 要件定義 も AI 主導で実施 ◦ AI の 成果物のレビューに人間は徹する 1 参考：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 – Amazon Web Services ブログ 　　　https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/
6. AI-DLC : AI-Driven Development Lifecycle • AWS さん 提唱する新しい開発ライフサイクル ◦ AI の能力を “フル活用” し、各種リードタイム短縮・DX 向上 6 参考：AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 – Amazon Web Services ブログ 　　　https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/ AI-DLC のポイント • プランニング、タスク分解・着手をすべて AI 主体で行う ◦ 要件定義 も AI 主導で実施 ◦ AI の 成果物のレビューに人間は徹する 1 • 関係者 リアルタイムに集い、密にコラボレーション ◦ 人間側の意思決定のリードタイムも短縮 2
7. Inception AI にビジネス要求を整理させ、要件定義をさせる 7 • ステークホルダー・ユーザーストーリー・受 入れ条件の整理 ◦ それらを作業単位 (ユニット) に分割 • アーキテクチャ設計、モデリング・コーディング • IaC の設計・実装、開発環境へのデプロイ • 本番環境へのデプロイ、インシデント対応 ライフサイクル: Inception , Construction , Operation れらを モブ で実施 Construction 要件に従い、AI に設計・実装させる Operation AI に運用作業をさせる
8. AI-DLC の別側面: AI の効果的な使い方 (1) • フェーズやタスクの 進め方を AI にプランニングさせる ◦ 最初に計画を立てさせ、人間 チェック → AI の意図せぬ暴走を防 ◦ 人間による知的労働の工程を削減 → 人間 ボトルネックになる とを防 8 1 • 検討結果は AI にドキュメント化させる ◦ チャット (コンテキスト) 内だ で完結させない → 以降の工程のインプット資料になる 2
9. AI-DLC の別側面: AI の効果的な使い方 (2) • AI の成果物は人間 レビュー し、承認するまで 次に進ませない ◦ 人間 ゲートとなり、品質を担保 9 3 • AI に独自の判断をさせず、質問させる ◦ その時点で考慮 足りていない部分 浮 彫りに → モブ中の関係者間で議論しな ら進める 4 れらは各フェーズ (Inception, Construction, Operation) で 共通 のテクニック
10. AI-DLC ＝ “ライフサイクル ” ＋ “AI の使い方” AI-DLC として決まっているのは れ らい • 具体的なツール あるわ ではない • スクラム開発のようなフレームワークもまだない 10 各組織・チームの実態に合わせてカスタム し、 柔軟に運用する必要あり
11. 2. 実プロジェクトに導入してみた 〜 流れとカスタマイズ内容 〜 11 Agenda 1. AI-DLC の概要をおさらい 2. 実プロジェクトに導入してみた 3. AI-DLC 成功のカギ
12. 適用したプロジェクトの概要 • 既存システムの サブシステムのプロトタイプ開発 を AI-DLC で実施 ◦ 本番稼働もさせるものの、サービスレベルは低 て OK ◦ 一部既存システムとの結合あり ◦ 開発期間: 約 1.5 ヶ月間 12 PO Plan ner Plan ner Eng Eng Eng Eng Eng 準備 Pre-Inception Inception Pre-Construction Construction リリース • 体制: PO ＋ プランナー 2 名 (＋企画数名) ＋ エンジニア 5 名 ◦ 必要に応じてモブチーム結成 ◦ スクラム開発を一部取り入れ
13. 流れ①-1 バックログの作成 ・整理 • Epic / Story (＝検証したいもの) 粒度で バックログ を整理 • 以降、Story の単位で AI-DLC のライフサイクルを実施 13 • スクラム開発との違い ◦ 着手可能なタスクレベルにまでの分解は行わない → プランニングは AI 行う ため PO Plan ner Plan ner ! 準備 Pre-Inception Inception Pre-Construction Construction リリース
14. 流れ①-2 環境整備 (1) • 並行して、AI-DLC 実施のための 足回りを整備 ◦ AI の手綱を握り、後工程をスムーズに進めるため 14 Eng Eng Eng Eng Eng • AI 向 に 成果物 (ドキュメント) の標準ディレクトリ構成 を定義 ◦ 成果物の格納場所の一貫性を保つため ◦ 中間成果物と最終成果物を区別するため 1 • 必要最低限の情報 を 正確 にインプットで る • 手戻り発生時、最小限の成果物の修正 で済む 後工程にて 準備 Pre-Inception Inception Pre-Construction Construction リリース ※　 : オリジナルの AI-DLC からのカスタマイズ箇所
15. AI 向けの成果物の標準構成例 aidlc-docs/ ├── inception/ # Inception 関連 . │ ├── user_stories/ # ユーザーストーリー関連 │ │ ├── **.md # 最終成果物 （ユーザーストーリーの一覧など ） │ │ └── tmp/ # 中間成果物 . │ │ ├── plan.md # 作業計画 . │ │ └── ** # その他の中間成果物 . │ └── units # ユニット関連 │ ├── **.md # 最終成果物 （分割後のユニットなど ） │ └── tmp/** # 作業計画 , 中間成果物 . ├── construction/ # Construction 関連 . │ └── <ユニット名 >/ # 各ユニットの成果物 │ ├── domain_models/ # ドメインモデリング関連 │ │ ├── **.md # 最終成果物 （コンポーネントモデルなど ） │ │ └── tmp/** . │ ├── domain_code/ # コーディング関連 │ │ └── tmp/** . │ └── architecture/ # アーキテクチャ関連の成果物 │ ├── **.md # 最終成果物 （アーキテクチャコンポーネントなど ） │ └── tmp/** . └── backlog.md # バックログ 15 参 考
16. AI 向けの成果物の標準構成例 aidlc-docs/ ├── inception/ # Inception 関連 . │ ├── user_stories/ # ユーザーストーリー関連 │ │ ├── **.md # 最終成果物 （ユーザーストーリーの一覧など ） │ │ └── tmp/ # 中間成果物 . │ │ ├── plan.md # 作業計画 . │ │ └── ** # その他の中間成果物 . │ └── units # ユニット関連 │ ├── **.md # 最終成果物 （分割後のユニットなど ） │ └── tmp/** # 作業計画 , 中間成果物 . ├── construction/ # Construction 関連 . │ └── <ユニット名 >/ # 各ユニットの成果物 │ ├── domain_models/ # ドメインモデリング関連 │ │ ├── **.md # 最終成果物 （コンポーネントモデルなど ） │ │ └── tmp/** . │ ├── domain_code/ # コーディング関連 │ │ └── tmp/** . │ └── architecture/ # アーキテクチャ関連の成果物 │ ├── **.md # 最終成果物 （アーキテクチャコンポーネントなど ） │ └── tmp/** . └── backlog.md # バックログ 16 参 考 各フェーズの成果物の 格納先を明確化
17. AI 向けの成果物の標準構成例 aidlc-docs/ ├── inception/ # Inception 関連 │ ├── user_stories/ # ユーザーストーリー関連 │ │ ├── **.md # 最終成果物 （ユーザーストーリーの一覧など ） │ │ └── tmp/ # 中間成果物 . │ │ ├── plan.md # 作業計画 . │ │ └── ** # その他の中間成果物 . │ └── units # ユニット関連 │ ├── **.md # 最終成果物 （分割後のユニットなど ） │ └── tmp/** # 作業計画 , 中間成果物 . ├── construction/ # Construction 関連 │ └── <ユニット名 >/ # 各ユニットの成果物 │ ├── domain_models/ # ドメインモデリング関連 │ │ ├── **.md # 最終成果物 （コンポーネントモデルなど ） │ │ └── tmp/** . │ ├── domain_code/ # コーディング関連 │ │ └── tmp/** . │ └── architecture/ # アーキテクチャ関連の成果物 │ ├── **.md # 最終成果物 （アーキテクチャコンポーネントなど ） │ └── tmp/** . └── backlog.md # バックログ 17 参 考 最終成果物と中間成果物を区別 (後工程では最終成果物のみ参照)
18. 流れ①-2 環境整備 (2) • カスタム指示ファイル や プロンプト の整備 ◦ AI はまだ AI-DLC の進め方を知らない ◦ 各工程で適切な資料を参照し、 適切なアウトプットを出してもらうための前提知識や指示 18 Eng Eng Eng Eng Eng 2 • プロジェクトテンプレート の整備 ◦ ➊, ❷ をリポジトリに配置 ◦ 組織・チームと相性の良い技術スタックをある程度選定 → スケルトンリポジトリ として整備 3 準備 Pre-Inception Inception Pre-Construction Construction リリース
19. AI 向けのカスタム指示ファイル例 AI-DLC の開発は以下の流れで進めます: 1. (Inception) ユーザーストーリーの作成 2. (Inception) 並行して実装できる粒度でユニットへ分割 3. (Construction) ユニット単位で以下を実施 a. ドメインモデリング b. コーディング c. アーキテクチャ設計（必要に応じて） あなたに与える指示は、上記のいずれかの段階に該当します。 自分が今どの段階の作業を行なっているのかに注意してください。 必要に応じて適宜、前工程の成果物を参照するようにしてください。 成果物の修正を指示した際も、前後の工程の最終成果物を合わせて確認し、 それらと矛盾が生じないように注意してください。 矛盾を発見した場合は、修正方針について確認を求めてください。 私の説明が必要な場合は、適宜私に回答を求めるようにしてください。 独自の判断や決定は行わないように注意してください。 (※前述の成果物の標準構成についても以降で説明) 19 参 考 AI-DLC 全体の流れを説明 (先走らないように釘も指す) まで紹介した テクニックも指示
20. 流れ② Pre-Inception の実施 • い なり Inception を開始すると 問題発生 ◦ テーマ ふわっとしていて 議論 発散 し続 る ◦ 切り口 二転三転し、やり直し 続発 する 20 準備フェーズとして Pre-Inception を明確に設 た • 作りたいものを 事前にざっ り認識合わせ ◦ 共通の “軸” (ペルソナや優先ユースケース等) を予めチームに作って ◦ Inception で論点になりそうな部分を想定して Plan ner Eng Eng Mob 準備 Pre-Inception Inception Pre-Construction Construction リリース
21. 流れ③ Inception の実施 • 企画の 頭の中にある要求仕様を言語化 ◦ ユーザーストーリー・受入れ条件 21 Plan ner Eng Eng Mob • エッジケース や 仕様上の論点 を洗い出し ◦ AI に質問させる (前述のテクニック参照) • 作業単位で ストーリーを分割 し､“ユニット”(＝作業単位) 化 ◦ Construction フェーズではユニット単位で着手 ◦ 並列で着手で るように分割で ると◎ 準備 Pre-Inception Inception Pre-Construction Construction リリース
22. Pre-Inception & Inception でのポイント① 作りもののスコープは小さ する • AI は決して万能ではない • スコープ 大 なると…… 22 補 足 • イテレーティブな開発 を念頭に、1 サイクルのスコープは適切に絞る ◦ AI 混乱 したり、誤ったアウトプット を出す可能性アップ ◦ 人間 成果物をレビューする際の負荷 も高まる ▪ 負荷 高まれば 判断ミス もしやす なる ▪ AI の手綱を握るの しんど なる (次スライド)
23. Pre-Inception & Inception でのポイント② AI “やり過 ” たと は軌道修正する • “やり過 ” ◦ 先のフェーズ・ステップで検討すべ 内容を 先走る ▪ 例: Inception 中に技術的な詳細設計を行 うとする ◦ オーバーエンジニアリング 気味な設計・実装を行う 23 補 足 • れら AI の “やり過 ” には付 合わない ◦ 容赦無 差し戻しを指示、成果物 らも削除させる ◦ 今決める必要 ない事項は「未定」と伝える
24. 流れ④ Pre-Construction の実施 • い なり Construction を開始すると 問題発生 ◦ ユニット (＝作業単位) 間の関係性 定まって らず、 手戻り や 考慮漏れ の原因に ◦ どのユニットにも属さない タスク漏れ の発生 24 Eng Eng Eng Eng Eng 準備フェーズとして Pre-Construction を明確に設 た • 全体的な アーキテクチャ や データフロー、 API 契約 (I/F や共通テーブル等) を事前に設計・ドキュメント化 • ユニットを俯瞰し、必須タスクを追加 準備 Pre-Inception Inception Pre-Construction Construction リリース
25. 流れ⑤ Construction の実施 • ユニット単位 (＝作業単位) で 並列 に設計・実装 ◦ AI に プランニング させる (前述のテクニック参照) 25 Eng Eng Mob Eng Eng Mob Eng • デリバリー優先に振り切った ◦ 小〜中論点の 意思決定は開発に移譲 し、定期的に企画と SYNC ▪ 開発期間中、企画もずっとモブに入るのは難しいため ◦ 今回は Pull Request のレビューを実施しない ととした ▪ 代わりに 開発チーム内での動作確認 を丁寧に実施 準備 Pre-Inception Inception Pre-Construction Construction リリース
26. 流れ⑥ 受け入れテスト ・リリース・振り返り • 各ユーザーストーリーの受入れ条件を満たせている 、 プロジェクトメンバー全員で確認 ◦ バグや実装漏れ あれば Construction に戻る • 受 入れ完了次第、リリース実施 • サイクルの最後に全体で振り返り (レトロスペクティブ相当) → 次の Inception へ…… 26 PO Plan ner Plan ner Eng Eng Eng Eng Eng 準備 Pre-Inception Inception Pre-Construction Construction リリース
27. 3. AI-DLC 成功のカギ 27 Agenda 1. AI-DLC の概要をおさらい 2. 実プロジェクトに導入してみた 3. AI-DLC 成功のカギ
28. どんなプロジェクトが向いているか AI 活躍で るように 膳立て出来る ？ • AI-DLC 採用のメリットは “リードタイム短縮” にピン留めすべ ◦ AI は アウトプット 高速 で、トライ＆エラーも多 まわせる ◦ 品質の維持 には 人間による準備・レビューコスト 不可欠 28 前提 • AI に過度に期待せず、人間と同様の “いち実務担当者” として、 AI パフォーマンスを出しやすい環境を整えられる (＝ 膳立て) 大切 • 膳立てのしやすさ ら、小規模開発 や 0 → 1 開発 にはフィットしやすい QCD のうち QC と D を天秤に掛 る必要あり
29. お膳立て① 成果物を “短期間運用 ” “使い捨て” にで る ？ • 　　 とりあえず動 ば良い ▪ 細 い部分は AI に丸投 で良 、品質は気にしない • プロトタイプ開発など 29 Yes • 　　 デリバリー優先の判断をしやす 、リードタイムも短縮しやすい • 　　 後の運用やエンハンスに耐えうる品質 必要 ▪ 品質維持のためのコスト (コードレビューやリファクタ等) 増え、 リードタイムも増えやすい ▪ “事前準備” (次スライド) にコストを払えれば緩和可能 No
30. お膳立て② AI への良質なインプットを用意で る ？ AI のアウトプット品質を高めるための “事前準備” 30 れら 充実すれば、品質を維持 しつつ AI の速さを享受で る • 充実した既存の ユニットテスト や、関連システムの 仕様書、 周辺システムを含めた アーキテクチャ・データフロー図 等を AI-readable な形 で用意で る？ • プロジェクトテンプレート や スケルトンリポジトリ を準備で る？ • MCP サーバー等の AI 向 ツール を利用で る？
31. お膳立て③ 適切なチームの立ち上げ で る ？ • アジャイル的な開発手法に対する、企画を含めた周辺 らの理解 ◦ イテレーティブな進め方 ◦ 企画・開発間での日常的なコミュニケーションを当たり前に 31 1 • ミドル 〜 シニアレベルのエンジニアを最低一名はアサイン ◦ AI の暴走やオーバーエンジニアリングは必至 ◦ それらを見極め、AI に修正を指示で る開発スキル 必要 2 • フルスタックな開発チーム、フルスタックエンジニアの育成 ◦ AI-DLC をフルスペックで実践で るのは、フルスタックなチーム 3 • AI-DLC を中長期的に実践し､ チューニングする覚悟と周辺 らの理解 4