🔥
AI-DLCワークショップ体験記：3日間で学んだAI駆動開発の実践と課題

s_machi
2025/11/18に公開
こんにちは！ディップ株式会社スポットエンジニアリング部で、スポットバイトルの開発を担当している町永俊介です。
本日は、AI-DLCという開発手法を学ぶために、AWSさんにワークショップを開催していただきました！
AI中心の開発フローを体験しながら、実際の業務課題に取り組む貴重な機会となりましたので、その内容をレポートします。

 ワークショップのきっかけ今回のワークショップのきっかけは、2025年6月に行われたAWS Summitでした。AWSの金森さん、福井さんよりEBC（Executive Briefing Center）にご招待いただき、そこでAI-DLCというものについてご紹介いただいたのです。
これまでディップでも、AIコーディングなどを通じてAIを活用できていると思っていました。しかし、EBCでAI-DLCを紹介いただいた際に「AIをソフトウェア開発サイクルの中心に置いて開発を行う手法」ということをお聞きして、まだまだAI活用の余地が多分にある状況だと認識しました。
ディップではAIの積極活用を進めており、ぜひ学びたいということでワークショップをお願いし、今回の開催が実現しました！

 リアーキテクチャプロジェクトとの関連また、私はスポットバイトルをDDD（ドメイン駆動設計）にリアーキテクチャするプロジェクトを推進しています。
エンハンスが随時入る中、少人数で推進するこのプロジェクトにおいても、AI-DLCの考え方や手法を活用できるのではないかという期待もありました。

 AI-DLCとは？AI-DLC（AI-Driven Development Life Cycle）は、前述の通り、「AIを開発プロセスの中心的な協力者およびチームメイトとして位置づけ、ソフトウェア開発ライフサイクル全体に組み込む手法」です。
2つの特徴があります：

 1. AIが実行し、人間が監視する開発ワークフローはAIが中心となり、実行計画を立案し、それを実行します。では、人間は何をするかというと、計画・実行の検査を行います。
つまり、人間の仕事が「判断・意思決定」に注力されるということです。

 2. 意思決定のためのステークホルダーと協業し、リアルタイムで問題解決・意思決定を行うAI-DLCでは、人間がリアルタイムで意思決定を行うため、意思決定のためのステークホルダーとの協業体制が構築された環境での実施が必要となります。
そのため、ステークホルダーとの物理的な空間を共有することが推奨されます。

 AI-DLCの3つのフェーズAI-DLCは大きく3つのフェーズに分かれています。
Inceptionフェーズ

Constructionフェーズ（設計・開発フェーズ）

Operationフェーズ（運用・保守フェーズ）


概要はAWSから共有されたスライドを参照
今回のワークショップでは時間の関係でOperationフェーズは実施できませんでした。
各フェーズで、AIは計画の立案と人間への積極的な質問を行います。
人間は質問に答えながらAIとすり合わせを行い、計画が承認された場合AIが計画を実行します。人間はまた成果物の検査を行い、問題があればAIとすり合わせを行いながら修正を依頼します。


全てのフェーズで、この「計画→レビュー→実行→レビュー」を繰り返し、開発フローが進行していきます。

 ワークショップの概要ワークショップは10/7〜9の3日間、弊社ディップカフェで開催されました。
参加者構成：
ディップからは35名
スポットバイトルチームとバイトルチーム
POとエンジニアが参加
弊社CTOも参戦し、一人でモクモクとAI-DLCを体験していました


前日、Amazon Q Developerのセットアップを完了させてウキウキのCTO

 1日目: AI-DLCの基礎とInceptionフェーズ
 概要説明1日目は、AWSさんからAI-DLCの概要について説明がありました。


AI-DLCの座学の様子
ここで印象に残ったお話がありましたのでご紹介させていただきます。
AI開発のアプローチは主に2つあるが、いずれも良いアプローチとは言えない

一つはAIに任せすぎるアプローチ

→最近ではVibe Codingと呼ばれ、単純なシナリオ以外は品質が安定しない
もう一つはAIの活用が限定的すぎるアプローチ

設計の大部分を人間が行い、限定的なコーディングをAIが行う

→品質は安定するがAIのポテンシャルを活かしきれていない
この説明を聞くまでは2つめのアプローチが最適だと思っていたのですが、さらなるAIのポテンシャルに目を向けられていない自分に気付かされました。

 サンプルテーマでのハンズオンまずは感触を掴むために、架空ECサイトを作るというサンプルテーマでのハンズオンからスタート。
ここで初めてAI-DLCを体験し、進行の大枠を理解することができました。


サンプルのお題でAI-DLCを実践している様子
AWS福井さんの進行についていく形で、AIにプロンプトを投げ込んでいき、各フェーズの「計画→レビュー→実行→レビュー」のサイクルを体験しました。
KiroのようなIDEを使わずとも、それほど複雑ではないプロンプトで安定した開発フローで進行していくので少し驚きました。
このようなプロンプトを投げ込んでいきます
## ユーザーストーリー計画
あなたの役割: あなたは熟練したプロダクトマネージャーです。以下のタスクセクションに記載されているシステムを開発するための契約となる、明確に定義されたユーザーストーリーを作成する任務を担っています。ドキュメントはすべて日本語で生成してください。

作業の計画を立て、aidlc-docs/inception/user_stories_plan.md ファイルにステップを記載してください。各ステップにチェックボックスを付けてください。いずれかのステップで私の説明が必要な場合は、[Question] タグを付けて質問を追加し、私が回答を記入するための空の [Answer] タグを作成してください。独自の判断や決定は行わないでください。計画を作成したら、私のレビューと承認を求めてください。承認後、その計画を 1 ステップずつ実行できます。各ステップが完了したら、計画のチェックボックスに完了マークを付けてください。また、作業内容のレビューを求めてください。

あなたのタスク: シンプルなECサイトを構築したいと考えています


出力されたユーザーストーリー計画
大雑把な要求なのですが、計画内でのAIからの質問に答えながら具体化していきます。
実際の業務課題では、積極的にインプットを行いAIと認識を合わせることも重要です。

 実際の施策でのInceptionフェーズ開始サンプルでの体験後は、いよいよ実際の施策をテーマにしたワークショップに移行。
今回我々スポットバイトルチームがテーマにしたのは、使用者都合でワーカーの早退が発生した場合の運用フロー改善に向けた改修施策でした。
この施策は、以下の2つの面で両者を守るために非常に重要な施策です：
ワーカーが本来得られるはずの賃金を確実に得られるようにする。
使用者が賃金の未払いリスクを抱えることがないようにする。
（ということをInceptionフェーズで全員が共通認識を持つことができました）

 AIとの対話でのユーザーストーリー整理Inceptionフェーズでは、チーム全員で主にユーザーストーリーの整理を行います。
Mob Elaborationと呼ばれ、チーム全員が空間を共有し、AIとの対話を通じてビジネス意図が詳細なユーザーストーリーに変換されていきます。

 チーム全員参加のメリットチーム全員の時間を使うということには抵抗感を覚える人もいると思いますが、以下のような利点があり結果としてプロダクト品質の向上が期待できると考えます：
重要なビジネス意図を全員で共有できる
後続フェーズでも共有された意図をもとに判断できる土台ができあがる

 法的見解も含めた検討スポットバイトルでは労働法が関わる要素が多いため、法的見解を踏まえたストーリー整理ができますし、そういった背景を関係者が正確に認識している事は最重要であると考えています。**
法的観点は最終的には専門家への確認が必要ですが、企画段階で精度高く効率的に検討できることは大きなメリットです。
PO陣からは「AI、わかってるな〜」という微妙に上から目線の驚きの声が多く聞かれました。


Inceptionフェーズでの作業風景

 2日目: ユーザーストーリーの整理とユニット分け/Constructionフェーズスポバチームは1日目だけではユーザーストーリーの整理をしきれず、1日目の続きからスタートです。
2日目午後まで時間をかけ、ユニット分けフェーズに移行しました。

 ユニット分けユーザーストーリーをシステムに落とす際に、並行で作業可能な単位に分割するユニット分けを行います。
基本的には、DDDのアプローチで境界づけられたコンテキストを基準としてユニットを分け、ユニット毎に独立して開発を行えるようにします。
AIからコンテキストに基づいたユニット提案がありましたが、今回我々は既存システムとの整合性を考慮し、従来の(DDDでない)基準でユニットを再編成して進めました。

 Constructionフェーズへ移行ユニット分けが行えると、その後はConstructionフェーズとなります。
Mob Constructionと呼ばれ、数名のユニットごとにチームが分かれて並行で作業を行っていくことができます。
2日目はユニットごとの設計に差し掛かったフェーズで終了となりました。

 3日目: 実装と成果発表
 ユニットごとに分かれてのコーディングフェーズユニットごとに分かれ、設計からコーディングフェーズに進みました。
チーム構成：
ワーカーチーム
クライアントチーム


ユニットごとに分かれて集中して作業に取り組む参加者たち

 既存システムとの統合課題実装フェーズで最も大きな課題となったのは、既存システムとの統合の難しさでした。
ユーザーストーリーをコードに落とす際、AI-DLCの手法であればドメイン→コードの開発フローがつながっているのでDDDのアプローチが自然に行えます。
しかし、DDDでないシステムに合流させようとした場合、ドメインとコードの機能マッピングのような追加のコンテキストを大量に渡す必要性が出てくるので、AIコーディングの旨味が薄くなってしまうと感じました。
この経験から、AI時代における設計アプローチの重要性を強く実感することとなりました。

 成果発表会さて、3日目も終わりに近づきワークショップの最後は、各チームでの成果発表会です。
スポットバイトルチームは、ユーザーストーリーの整理と既存のコードへの合流部分で手間取ったこともあり、成果発表はモックを使ったものが中心となりました。
正直なことを言うと、もう少し形になったものができれば良かったのですが、3日間ということを考えればまずまずの成果かなと思っています。
法律観点をしっかりクリアし、ユーザーストーリーの整理を行えたという事は大きな収穫でした。


我らがスポットバイトルチーム小森谷氏、吉田氏、高山氏からの成果発表

 CTOチーム発表CTOチーム（メンバー1人）が開発した成果物の発表もありました。
MBO・社員の目標設定を評価するシステムをテーマに、AI-DLCのフローで一人で開発を行っていたらしく、生成AIとも連携しての評価システムを3日間（たぶん実働はもっと少ないです）で開発していました。
CTOの立場でAI-DLCを体験し、その有用性を実感してもらえたことは、今後の組織全体でのAI-DLC推進において非常に大きな意味を持つものとなってきそうです。


成果発表の前にプレゼンがありました

 ワークショップを終えて
 施策全体でのAI活用フローの体験価値これまで、企画時の壁打ちやAIコーディングといった断片的なAI活用はできていましたが、施策全体でAIを活用した開発フローの体験は大きな価値があります。
AI活用の最大化、ソフトウェア開発においてそれを行うために、この手法は現時点で最適な選択肢である可能性が高いと感じています。

 気づきと学びこのワークショップを通じて得た学びをご紹介します。

 計画が大事まず、計画の品質が成果物の品質に直結するということです。
作成する計画の品質が、成果物の品質を左右するため、計画が合理的なものであることをレビューすることも重要だと感じました。

流れがわからないうちは提示された計画ありきで進行させてしまいがちですが、何度かサイクルを経験する事で感覚を掴めてきます。また、状況に応じて計画を修正して対応することも重要です。

 AIとの認識合わせが重要そのためには、各フェーズでAIと認識を合わせる意識を持つことが重要だと感じています。
AIが意図しない挙動を取るのは大抵インプットとなる情報が足りないときです。必要なインプットを与えてあげればほとんどの場面で人間（主語が大きいので訂正）私より良いアウトプットを生みます。

 AIは開発パートナーAIとの議論は学びとなるものが多く、開発プロセスにおいても積極的に意見を求めるなど、良き開発パートナーとして位置づけることでAIのポテンシャルを引き出せると感じました。
逆に、AIを作業者と捉え、指示ばかりになると、AIの探索能力を殺すこととなり能力を発揮できません。
やることが明確である場合を除き、AIと協業し、ポテンシャルを引き出すことを意識したコミュニケーションが重要です。

 即時判断をする為にAI-DLCでは即時の意思決定が求められます。しかし、これは高い能力がないと難しいことです。
判断をする人間の能力が伴わなければ、アウトプットの良し悪しの判断も難しくなります。
つまり、AI中心の開発となったところで、結局のところAIのアウトプット品質は人間の能力に依存するところが大きいというのが私の見解です。
これからの時代、人間に求められる能力は高くなる一方になりそうです。

 DDDとの相性の良さAI-DLCはドメイン駆動設計（DDD）との相性が非常に良いことを実感しました。
ユーザーストーリーから境界づけられたコンテキストへの分割、そしてドメインモデルからコードへの変換という一連の流れが、AIの得意とする抽象化と具体化のプロセスと自然に合致します。
特に以下の点でシナジーを感じました：
AIがドメインの概念を理解し、適切な境界でユニット分割を提案してくる
ドメインモデルが明確であれば、AIが生成するコードの品質が格段に向上する
既存システムがDDDで設計されていれば、AIとのコンテキスト共有が最小限で済む
逆に、DDDでない既存システムとの統合では追加のコンテキスト情報が大量に必要となり、AI活用の効果が薄れてしまいます。
AI時代においては、DDDのようなドメイン中心の設計アプローチがより重要になると感じています。

 計画のファイル管理が効果的また、今回のワークショップでは「計画をファイルに出力して管理する」という手法を採用していましたが、私はこれがとても気に入りました。
AIエージェントにもplanモードといった計画機能がありますが、計画をファイルに出力することで以下のメリットがあり、非常にコントロールしやすいと感じました：
計画の修正方法が、AIの指示以外にファイル修正の選択肢もあり柔軟性がある
計画フェーズでも実行フェーズでもチェックポイントに戻りやすい
AIエージェントのplanモード、計画の修正を指示したら意図がうまく伝わらずに時間を浪費したこと、ありませんか...？

 参加者アンケート結果ワークショップ終了後、参加者アンケートを実施しました。

 満足度と活用予定
ワークショップの満足度: 4.66 / 5

今後の開発に活かせそうか: 4.13 / 5
全体的に高い評価で、コメントも肯定的なものが多かったです。
今後の開発に活かせそうかという項目が、満足度と比較して低いのは、次に触れる課題を感じる人が多かったためと思われます。

 今後の課題として挙げられた点アンケートでは、今後AI-DLCを実践する上での課題についても率直な意見が寄せられました。
主な課題として以下の3点が挙げられました：
技術的なスキル・知識の不足

AI駆動開発を効果的に進めるためには、まだまだ学ぶべきことが多いという声が多数ありました。
実践するための時間確保

同期的な時間を共有することが前提とされているので、時間確保が課題という意見が目立ちました。この声が一番多かったです。
適切なテーマ（課題）設定

どのような施策や課題にAI-DLCを適用するのが効果的かの判断が難しいという声もありました。

 各課題に対する個人的見解1. 技術的なスキル・知識の不足について
これに関しては経験を積み、知見を蓄積していくことで改善していくべきものと捉えています。
2. 実践するための時間確保について
打ち合わせ等で参加者の都合を調整するのが難しかったりといった現実がありますが、個人的には人間の都合をつける話なので、AI-DLCの開発プロセスに人間側が適応する必要があると考えています。
こういった環境を整えるための働きかけを行い変えていかなければいけないものと考えています。
3. 適切なテーマ（課題）設定について
確かに小さすぎると過剰という印象です。大きすぎても大変ですが、MVPの検討にもAIが良きパートナーとなってくれることがわかったので一定規模以上の施策には適用していく価値があると感じます。
上記はあくまで個人的な感想なので、これからの取り組みにおいて関係者とコミュニケーションを取りながら解消を目指していきたいです。

 今後の展開
 スポットバイトルでのAI-DLC適用早速、スポットバイトルではリアーキテクチャプロジェクトにAI-DLCの適用を行って進め始めるというとりくみを行いました。
ワークショップで学んだ手法を実際のプロジェクトで活用し、効果を検証しています。
また、エンハンス施策においても部分的に手法を取り入れるなど、我々にフィットした方法を模索しているところです。

 継続的なAI-DLC開発の推進今回のワークショップを通じて、AI駆動開発の可能性と実用性を強く実感できました。
今後も継続的にAI-DLCの手法を取り入れ、より効率的で質の高い開発を目指していきます。

 おわりに3日間という短期間でしたが、AI-DLCの全体像を体験し、実際の業務に活用できる具体的な手法を学ぶことができました。
ワークショップを実施してくださった福井さん、加藤さん、三浦さん、坂本さん、堀田さん、古川さん、本当にありがとうございました！
新しいアプローチを学べただけでなく、実際のプロジェクトで活用できる実践的なスキルを身につけることができました。
今後もAI-DLCの手法を活用しながら、より良いプロダクト開発を進めていきたいと思います。
AIの可能性はまだまだ広がりを見せるものと感じており、これからの展開が非常に楽しみです！


3日間のワークショップを終えて、みんなで記念撮影！