目次
はじめに
こんにちは。
アプリケーションエンジニア3年目のKokiです。
AWSやAIサービスの知見がまだまだ少ない部門に所属しています。
私が「AI-DLC」という言葉を初めて聞いたのは、AWS Summit 2026の会場でした。
正直なところ、その場では概念をふんわり理解した程度で、「これ、実際に自分でやったらどうなるんだろう？」というモヤモヤが残ったまま持ち帰ることになりました。
そこで今回、社内ハッカソンという機会があり、チームメンバーにAWSの有識者の方がいらっしゃり、その方が「AI-DLCで開発をしよう！」と方針を決めてくださり、「AI-DLC」を実際に手を動かして試してみることになりました。
概念だけふんわり理解していたことを実践で使える機会を作っていただき、感謝です。
この記事では、以下の3つを、私と同じように「AI-DLCって聞いたことはあるけど実態がよくわからない」という方に向けてまとめます。
- AI-DLCとは何なのか（初心者向けにかみ砕いた説明）
- 実際にハッカソンでどう進めていったか
- やってみてわかった成果と気づき
💡 なお、記事中では Claude Code の「skills」 という言葉が何度か登場します。skillsとは、Claude Codeに特定の作業手順やノウハウをテンプレート的に持たせておける拡張機能のことです。あらかじめ用意しておくことで、毎回イチから指示しなくても、特定のタスクをスムーズにこなせるようになる仕組み、とイメージしてください。※理由はハッカソンのプロダクトテーマにしたからです。
AI-DLCとは何か
先に結論から書きます。
AI-DLC（AI-Driven Development Lifecycle）とは、要件定義から設計・実装・テスト・運用までの開発工程全体をAIが主導し、人間は"監督・承認する側"に回る、AWSが提唱する新しい開発ライフサイクルの考え方です。
私が知っていた開発方法は、人間がAIに指示を出し、その内容を作成してもらうという伴走支援型の開発形式でした。
一方でAI-DLCは、「AIにコードを書いてもらう」という単純な話ではなく、開発プロセスそのものの主従関係を見直すアプローチ、と捉えると理解しやすいと思います。
詳しい仕組みは次の章で、具体的な用語とともに整理していきます。
従来のAI活用との違い
これまで多くの現場で使われてきた「AIアシスタント的な活用」と、AI-DLCが提案する考え方には明確な違いがあります。
| 観点 | 従来のAIアシスタント活用 | AI-DLC |
|---|---|---|
| AIの役割 | 人間の作業を補助する | 開発プロセスを主導する |
| 人間の役割 | 手を動かす主体 | 判断・承認を行う監督者 |
| 開発単位 | スプリント（1〜2週間） | Bolt（数時間〜数日の超短期サイクル） |
| 進め方 | 個人が順番にタスクをこなす | 人とAIが一体となって並走する |
※ Bolt：AI-DLCが提唱する開発単位。時間や日単位で測定される、より短く集中的な作業サイクルのこと。
AI-DLCに登場する重要キーワード
- Inception フェーズ：要件定義・設計を行う最初の段階。中心概念は「モブエラボレーション」。
- Construction フェーズ：実装・テストを行う段階。中心概念は「モブコンストラクション」。
- Operations フェーズ：リリース・運用を行う段階。
- モブエラボレーション：人間とAIが対話しながら要件や仕様を練り上げていく進め方。モブプログラミングのAI版、と考えるとイメージしやすいです。
- モブコンストラクション：同様に、実装フェーズで人とAIが一体となってコードを組み立てていく進め方。
- 人間は"承認ゲート"になる：各フェーズの節目で、AIの提案や成果物を人間がレビュー・承認するという役割に変わります。
一言でまとめると、「AIに仕事を渡す」のではなく「AIと一緒に、より小さいサイクルで企画・開発を回す」という発想の転換がAI-DLCの核だと理解しています。
なぜハッカソンでAI-DLCを選んだか
今回のハッカソンでは1日、対面で作業できる時間が設けられており、みんなでAIが考えた要件から設計・開発までを評価・レビューする時間を確保できるため、AI-DLCという進め方を選びました。
それに加えて、一気通貫してAIが主導して思考してくれるため、精度の高い成果物を作成できるという点も選定理由のひとつです。
ハッカソンの概要
- テーマ：AIネイティブ化するために有用なこと
- チーム構成：3人
- 期間：1日
ハッカソン実況：AI-DLCで実際に開発してみた
ここからは、実際にAI-DLCのフェーズに沿ってどう進めていったかを時系列で振り返ります。
環境準備フェーズ
GitHubにAI-DLCを実施するために必要なアセットが公開されています。利用するコーディングエージェントに合わせて環境を設定していきます。今回はClaude Codeを用いて作業を実施しました。
🔗 https://github.com/awslabs/aidlc-workflows
Inceptionフェーズ：要件定義でのモブエラボレーション
事前にテーマの構想を練っていたため、その企画書をAIに渡して、要件定義を深化させていきました。
今回のテーマは「Claude Code初心者がskillsを活用するための支援アプリ」です。
当初の構想では、有識者が作成したskillsを共通のGitHub上で共有し、Claude Code初心者がユースケースに合ったskillsを選択して利用できるようにする、という流れを考えていました。
しかし、AIと要件定義を進める中で、「ユースケースは人それぞれ異なるため、AIがそれぞれの人に対しておすすめのskillsを生成して共有する方が良いのではないか」という提案が出てきました。
そのため、最終的にはユーザーが抱えている課題を入力すると、それを基にAIがskillsを生成して提供してくれるアプリを開発することになりました。
🗒️ 当初の構想からAIとの対話を通じて方向転換が起きた、というのはまさに「モブエラボレーション」を体感できた瞬間でした。
Constructionフェーズ：モブコンストラクションでの実装
AIがアーキテクチャ案を考える前に、実行環境や制約などを事前に入念に尋ねてくれたため、出てきたアーキテクチャ案は想像通りの内容でした。
また、今回の環境上、LLMのAPIキー発行が難しい状況だったため、Claude CLI経由でLLMを呼び出し、skillsの生成を実行するというシステム構成にしてもらいました。
（今回は時間の関係上、ローカル環境で動けばOKという方針にしました。）
Operationsフェーズ：リリースと振り返り
Constructionフェーズで作成してもらったアーキテクチャを基にコードを作成してもらいました。
その後AIにレビューをしてもらい、影響度が高い内容だけ修正を依頼しました。
そして実際に実行してみると、LLMの出力箇所が固定値で返ってきており、Claude CLI経由の処理がうまくいっていないことがわかりました。AIに原因を尋ねると、フロントエンドからバックエンドにJSONを渡す際に形式が崩れてしまい、「echo」の情報しか渡っていないという事象が起きているようでした。
その事象を解決するように依頼すると、無事にLLMがオリジナルの出力をしてくれるようになりました。
成果
定量的な成果
- 開発にかかった時間：7時間
- 完成した機能の範囲：プロンプトを入力すると、その内容に応じたskillsを出力する機能
- ※出力の質に関する課題は後述します
定性的な成果
- AIとの役割分担についての実感：AIが主導し、人間はレビュー・評価をするだけでプロダクトが開発できることに驚きました。
- 想定外だった学び：AI-DLCを用いることで、AI側が質問や効率的な進め方の提案をしてくれるため、円滑に作業を進めることができました。
課題
- 本来はLLM自身にskillsのファイルそのものを生成させたかったが、実際には「Claude Codeへの指示プロンプト」が出力されてしまう状態だった
- 画面UIが平成チックで古臭い印象になってしまった
今後の展望
AWS Summitで感じた「AIエージェントの企業導入が本格化しつつある」という流れと、今回のハッカソンでの体験は地続きだと感じました。
AI・AWSの知見がまだ少ない自部門だからこそ、
- 小さく試して学ぶ（Boltのような超短期サイクルの考え方）
- AIに丸投げせず、要所要所で人間が判断する
というAI-DLCの姿勢は、むしろ知見が少ないチームにとって取り入れやすい考え方なのではないかと感じています。
理由は大きく2つあります。
-
サイクルが短いぶん、間違った方向に進んでもすぐ軌道修正できる点
知見が少ないチームは「何が正解かわからない」状態から始まることが多いですが、1〜2週間のスプリント単位だと手戻りのコストが大きくなりがちです。Boltのように数時間〜数日で1周する仕組みであれば、小さく試してすぐ修正する、というループを高速に回しながら知識不足を補っていけます。 -
AI-DLCの構造自体に「人間が承認する節目」が組み込まれている点
知見が少ないとAIの提案をそのまま鵜呑みにしてしまいがちですが、各フェーズの節目で人間が判断・承認するステップがあることで、暴走を防ぐ安全弁として機能します。
つまり、「サイクルが短いから間違えてもすぐ修正できる」「人間の承認ポイントがあるから暴走しない」という2点から、知見が少ないチームでもAI-DLCはハードルを低く取り入れられる考え方だと感じています。
一方で、導入にあたっては
- AIが生成したコードや設計を正しく評価できるスキルが人間側にも必要
- チーム全体でAI-DLC的な進め方への理解を揃える必要がある
といったハードルも感じました。
おわりに
AI-DLCという言葉を初めて聞いたときは正直「最先端技術（AWSやAI）を知らないと利活用できない手法」だと思い込んでいました。
しかし、実際にハッカソンで手を動かしてみると、初心者エンジニアでも理解でき、AI主導で作業を進められる画期的な手法だとわかりました。
今回のプロダクト開発では、当初思っていたものとは違う結果が生まれました。ですが、そういった場合もAIがプロダクト開発のための設計書や資料を多く残してくれているため、途中の段階に立ち返って修正を依頼すれば改善できると感じています。
これらのことから、AI-DLCを用いることで、すぐにアイデアを形にすることができるとわかりました。今後、PoCで新しいプロダクト開発をしようと思った際には、この手法を用いて実施したいと感じました。
初めて記事を書いてみました。
ハッカソンのチームメンバーの方に「記事を書いてみるといいよ！」とアドバイスをいただき、早速書いてみました。（その方は毎月1本の投稿をしているみたいです！すごいです…）
実際に書いてみると、実施したことを整理でき、知識として定着した感じがします。
また、私自身が超が付くほどの初心者なので、そういった初心者の方から非エンジニアの方にも「これはこういう意味だったんだ！」「こうすると新しいプロダクトが簡単に作れるんだ！」といったご紹介ができればと思っています。
初心者だからこそ難しいことを噛み砕いてわかりやすい記事を目指して、継続して書いていこうと思っています。
これからも読んでいただけるとうれしいです。
それでは、また次の記事でお会いましょう！