はじめに
本記事はiimon Advent Calendar 2025 12日目の記事となります！
こんにちは！
ｉｉｍｏｎでフロントエンドを担当しております、まつむらです！
本日は12月12日、ちょうどクリスマスまでの折り返し地点ですね！
今年は洒落たことしちゃおうかな！？紅茶のアドベントカレンダーとか購入しちゃおうかな！？
とソワソワしていたらあっという間に今日を迎えたというわけです、えぇ。
時は金なり！ということで本題に入っていきましょうかね。
弊社では11月からClaude Codeがエンジニア全員に配布されてから早くも1ヶ月経ちました。
テストコードや実装、修正にPR作成、はたまたレビューに至るまで幅広く活用されてます。
単純に実装して！とAIに指示を出すだけでなく、レビューや実装方針の壁打ちとしても活用しているメンバーもいます。
その中で気づいたのが、営業さんがよく使うオープンクエスチョンの有効性です。
せっかく色々なことを知っているAIを相手にYes/Noで会話を終わらせるのはもったいないですからね！
そうした気付きがあったのと同時に、いっそのことAIにああしたい、こうしたいと伝えるだけで全てを解決してくれないかなーと思った矢先、社内の勉強会にてAI-DLCというものについて学ぶ機会があり興味を持ったので、調べて分かったこと・個人的に今やるべきことの備忘録として記していければと思います！
AI-DLCとは
なんの略称やねん
さて、いきなり横文字が飛んできたぞ、と。
AIはAIそのものでしょ？DLC……ダウンロードコンテンツ？？
と、冗談はさておき、DDDやTDDといった~Driven Developmentの一種だろうなとは察しがつきましたが、どうやら今までと様子が違う。。
AI-Driven Development……？
(じゃあLCはどこからきたんだ、、ローコスト……？)
正解は AI-Driven Development Lifecycle でした。
(今度はDがどこか行っちゃったよ……)
と、勉強会にて脳内でツッコミを入れてました（笑）
SDLCというものを理解している方であれば、「あー、そういうことね！」とピンときたのかもしれませんが、お恥ずかしながらSDLCというものをあまり理解していませんでした。。
念の為、補足しておくと、ソフトウェア開発ライフサイクル （Software-Development Life Cycle）とは、ソフトウェアを計画・開発・テスト・デプロイ・保守するための体系的なプロセスのことです。
ウォーターフォールやアジャイル、DevOpsなどがこのSDLCモデルに該当するとのことです。（ここでやっとワードが繋がりました、、）
詳細はAWSの記事があるので、そちらを参照していただければと思います。
さて、AI-DLCがAI駆動開発ライフサイクルと訳せることは分かりました。
「ということはSDLCにAIを組み込んだものがAI-DLCだ！！」となりかけましたが、どうやらそういうわけでもないようです。
AI-Driven Development Lifecycleの概念
「AIによる支援を受けながらSDLCを回す」というわけではない。
ではAI-DLCとは何者なのか？
AIとの対話がこちらが投げかけるのではなく、AIに投げかけられたことを元にエンジニアが評価・指示を出すというサイクルになるらしいです。
AI-DLCを提唱したAWSのホワイトペーパーによると以下が本質であるとのことです。
AI-DLC の本質は、新しいメンタルモデルを通じて AI にワークフローを開始させ、指示することです
人がAIにやりたいこと（ビジネス意図）を投げるところからスタートして、
- AIが計画を作成する。
- AIが不明点等を人に確認する。
- 人が検証・回答する。
- AIが実装し、1に戻る。
このパターンを新しいメンタルモデルと定義しているようです。
人が介入するのはAIからの質問に回答するときだけ。
こちらが想像している有名な人物やキャラクターを当てるのが得意なランプのおじさんみたいですね！
これを核として開始 →構築 → 運用の3フェーズでAI主体の開発を行っていきます。
開始( Inception )フェーズ
開始( Inception )フェーズでは、AI がビジネス意図を詳細な要件、ストーリー、ユニットに変換します。これは「モブエラボレーション( Mob Elaboration (※) )」を通じて行われ、チーム全体が AI の質問や提案を積極的に検証します。( ※訳註: elaboration は”推敲”や”入念な準備”と言う意味を持つ英単語です)
このフェーズでは、どういうものを作りたいのかをAIが質問してくるので、その解釈で合ってる？これはこうじゃない？と回答していき、ビジネス要件を詳細設計に落とし込んでもらう、という解釈でいいのかなと思います。
どちらかというとビジネス寄りですね！
構築( Construction )フェーズ
構築( Construction )フェーズでは、開始フェーズで検証されたコンテキストを使用して、AI が論理アーキテクチャ、ドメインモデル、コードによる実装、テストを「モブコンストラクション ( Mob Construction )」を通じて提案します。そこでは、チームが技術的決定とアーキテクチャの選択についてリアルタイムで明確化していきます。
このフェーズでは、今後の拡張性やテスト戦略などのAIの提案を検証していく流れになります。
Inceptionフェーズがビジネス寄りなのに対してこちらはエンジニアリング寄りですね！
運用( Operation )フェーズ
運用( Operation )フェーズでは、AI が前のフェーズから蓄積されたコンテキストを適用して、チームの監督のもとで Infrastructure as Code とデプロイメントを管理します。
このフェーズでは、デプロイ可能な状態にするためのパイプラインを整えます。
インフラ専門の方々よりは疎いのですが、インフラ構成をYAMLで書いて、GitHub Actionsでマージされたものを自動でデプロイしてくれるまでの流れを整備してくれる、といった感じですかね？
また、この3フェーズ全体をスプリントより短いボルトという単位で回します。
スプリントでは遅い！？ボルトという単位
畳と平米、人日とストーリーポイント。
今まで色々な単位に触れてきましたが、またまた新しい単位が出てきちゃいました。
どうやらスプリントが通常1〜2週間で1サイクルするのに対し、ボルトはわずか数時間・日単位で1サイクルするようです。
スプリント、もといスクラムに関してはまだチームでは導入できていませんが、「スプリントって密度はあるけどあっという間に過ぎ去っていくものだな」と感じてます。
導入に向けて2週間単位の実績ベースでプランニングポーカーをしているフェーズなので本当に感覚値にはなりますが。。（早く追い越せるように頑張ります！）
それよりも短期間、簡単なタスク1つ分くらいの時間のサイクルで物事を進めていくことに対して凄さよりもむしろ恐怖すら覚えます。
ふと思ったのですが、これだけ早いとスプリントで重要なレトロスペクティブ（振り返り）はどうするんでしょ……？
AWSのホワイトペーパーに言及している箇所がありました！
prod.d13rzhkk8cj2z0.amplifyapp.com
伝統的な手法は、数ヶ月〜数週間といった長いイテレーションを前提としており、その結果としてデイリースクラムやレトロスペクティブといった儀式が生まれた。
一方で、AI を適切に適用した場合、開発サイクルは数時間〜数日単位の高速なサイクルになる。
これには、継続的かつリアルタイムな検証・フィードバック機構が必要であり、多くの従来型の儀式は相対的に重要性が低くなる。
原文
These traditional methods were built for longer iteration duration (months and weeks), which led to rituals like daily standups and retrospectives. In contrast, proper application of AI leads to rapid cycles, measured in hours or days. This needs continuous, real-time validation and feedback mechanisms, rendering many of the traditional rituals less relevant. Would effort estimation (ex. story points) be as critical if AI diminishes the boundaries between simple, medium and hard tasks?
今までの振り返りでは遅いので、継続的かつリアルタイムな検証・フィードバックできる仕組みが必要になってきそうです。
LIFULL社の事例では「プラン→レビュー→実行→レビュー」のサイクルを回す機会が増えたとのことで、これ自体が従来の振り返りに変わる継続的な検証プロセスなのでは？と思います！
ボルト時代の「振り返り」は、週次のミーティングではなく、開発の流れの中に溶け込んでいくのかもしれませんね。
では、このような高速サイクルを実現するために、実際に導入した企業ではどのような工夫をしているのでしょうか？
AI-DLC実践事例
そもそもこの記事を書こうと思った理由
さて、AI-DLCの概念は理解できました。
では実際にどう導入するのか？導入した事例を紹介！
……といきたいところですが、改めてこの記事を書くに至った経緯を話しますね。
冒頭で述べた社内勉強会にて「プロジェクトの開始時に導入できれば、0→1開発であれば得意そうだけど、既存プロダクトの追加開発や保守フェーズで導入するのって難しいんじゃない？」という疑問がディスカッションの中で出てきました。
確かにお作法やら設計思想などのしがらみがない状態であれば、[さくせん▶︎ガンガンいこうぜ]が使えるところですが、既存プロダクトの場合はそうもいかない。
じゃあ結局のところ、MVP（Minimum Viable Product）開発くらいしか出番がないんじゃないの？？と勉強会を主催したEMに質問しに行ったのですが、「途中からでも導入した事例はあるよ！」と事例を教えていただきました！
せっかくなので、その記事だけでなく、AWS主催のワークショップに参加した企業の記事も併せて紹介します！
事例1：CyberAgent社 - 既存フローへの統合
EMに教えていただいたCyberAgent社の記事によると、最初は新規プロジェクトを対象にAI-DLCを導入していたようです。
ただ、既存のプロジェクトへの導入に関しては「挑戦」しましたとのことで、ハードルは高かったそうです。
既存のOSSプロジェクトをベースに開発を進める場合、AIがプロジェクト構成や依存関係を正確に理解していないと、出力の精度がブレるという課題があったとのことでした。
そのために、初期学習をしっかりと実施したとのことです。
- プロジェクト全体の構造
- 設計思想
- 命名規則
- etc……
確かにこの辺の情報がないとAIにお願いするにしてもVibe Codingになってしまうのかなと感じました。
自分も「他のテストみていい感じに実装よろしく！」なんて雑な投げ方をしていたのを思い出しました（苦笑）
初期学習を経たAIの出力を、人間が検証・評価するという流れで実践されていたそうです。
このワークフローをClaude CodeやCursorなどのエディタ上で再現できるようにカスタムコマンドやプロンプトドキュメントの整備も併せて進めたそうです。
その結果、ベロシティは安定的に高い出力を維持できているとのことでした。
記事では、既存のプロジェクトでも上手く適用できた要因として2点挙げられてました。
1つ目は「コンテキストを絶やさない」こと。
AIの提案を検証・改善するプロセスを構築し、一貫性を保ちながら開発を進められたとのこと。
2つ目は「事前の土台準備」。
命名規則や設計パターンをAIに学習させ、品質を維持できる状態を初期に作ったことが大きかったそうです。
1つ目の「コンテキストを絶やさない」プロセス構築については、正直まだ具体的なイメージが湧いていません。。
ここは弊チームでの今後の課題になりそうです。
2つ目に関しては、弊チームのnakamさん筆頭にドキュメンテーションを進めているところで、この記事を読んで「やっぱりこの方向であっていたんだ！」と確信が持てました！
事例2：カカクコム社 - ワークショップで得た学び
厳密にはAI-DLCの導入事例ではありませんが、AWS主催のワークショップに参加された際のレポートがとても参考になったので紹介します。
開発効率1.x倍の壁
AIに対するマイクロマネジメント
こちらではCursorを使用されているとのことです。
Cursorに関しては弊社でもAI検証メンバーで1ヶ月だけ触れましたが、確かにジュニアエンジニアとして扱ってる感覚はありました。
その時は特にテストコード周りの実装に注力していたのですが、mock周りの理解が浅く既存のコードを参照しながら進めていく、ということはしてくれなかったと記憶してます。（当時は知見もなく、コンテキストの与え方が悪かったのかもしれませんが……）
実装指示を厚くすることでカバーされたとのことですが、確かにAIに対するマイクロマネジメントをしているのかも……と感じました。
そろばんから電卓になっただけでは足りない！
弊チームでは毎週末、完了タスクの予定工数と実績の差分が±30%以上あれば振り返りを実施しています。
Claude Codeを導入してからどうなったのかな？（ワクワク！）と週末にチームメンバーの工数表を確認しにいったのですが、今のところ工数が30%以上削減されて振り返り対象になったのは1件だけでした。
ただ、これに関しては裏を返せば30%超過分やギリセーフだけど怪しいから振り返った方がいいよね？といったタスクがなくなったとも取れるかなと思います。
記事の方でも設計から実装とユニットテストまでであれば、案件によっては1.2倍や1.5倍の効果が出ているとのことでした。
ここに関しても似たような境遇で共感しました！当然このままではいけない、もっとAIを活用していくぞ！という気概も！
各フェーズの中でもステップごとに成果物を残す
「各ステップで成果物を細かく残しておくことで、後から戻りやすくなる」という工夫も紹介されていました。
AI-DLCの作業中にこまめにセーブポイントを作るイメージですかね？
設計手法に依存しない汎用性
AI-DLCの説明を読んでいると、ドメインモデルやらDDDやらの単語が出てきて「うちDDDやってないし……」と思った方もいるかもしれません。
というか私ですね、はい。（苦笑）
DDD勉強会も社内でやったので、学ばねば！と思って「ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法」をポチってはみたものの、今はそれじゃない！と後回しにして積み本が消化しきれてません。
記事では「ユニットという作業単位であれば、設計手法やアーキテクチャの影響を全く受けないため、非常に汎用的」と述べられており、DDDを採用していなくても導入のハードルにはならないとのことでした。（ユニットの詳細な考え方は元記事が参考になります）
これは個人的にかなり安心材料でした。（やることやってから本は消化していきます）
他の事例
他にもAWS主催のAI-DLC Unicorn Gymに参加した企業の事例が公開されています。
東京海上日動システムズ社では、金融業界初のワークショップとして1.5日で4チームが動作するシステムの初期版を完成させたとのことです。
東京海上日動システムズ株式会社様の AWS 生成 AI 事例：金融業界初 AI-DLC Unicorn Gym による開発変革への挑戦 | Amazon Web Services ブログ
LIFULL社では、前述の通り「プラン→レビュー→実行→レビュー」のサイクルを日常的に回すようになったそうです。
詳細は各記事を参照してみてください。
うちのコードベース、AIに説明できる状態ですか？
ここまで事例を見てきましたが、共通して言えるのは「AIが理解できる状態を作る」ことの重要性です。
ドキュメントが整備されて、構成・そしてドメイン知識をエンジニア側がちゃんと持っていて、初めてAIに説明できる状態になるのかなと。
裏を返せばこれができていないと導入も何もないです。
併せてAIが提案したものを判断する基礎力・レビュー力も必須ですね。
ノールックアプルーブ、ダメ絶対！
弊チームの現状
KPT風に整理すると以下のようになりました。
[Keep]できていること
[Problem]現状の課題
- コンテキストを絶やさないプロセス構築（まだ勉強不足）
- 既存プロダクトへの適用方法
[Try]これからやること
- プロダクトに関する説明の整備
- プロジェクト構造のドキュメント化
- 設計思想の言語化
- 依存関係の可視化
ちなみに依存関係の可視化をClaudeにお願いしたところ、色々と見えてきてしまい「ぐぬぬ……」となっています。
技術負債解消リストが日に日に厚みを増していく……
気になりすぎて脱線→暴走してEMやCTOとの1on1時にDDDで解消できますかね？UIだけReact移行すればUIのバグが減りそうな気がしてます！！といった謎な質問や雑な提案をしに行って困惑させる、という事件も起こしました（すみませんでした）。
AI-DLCを導入するしない以前に、「AIに説明できる状態」を作ること自体が、コードベースの健全性を見直す良い機会になるのかもしれません。間違えても飛躍することのないようにしたいですね（自省）。
一歩一歩、進んでいければと。
まとめ
AI-DLC導入は「AIに説明できるコードベースか？」を問われるので、実装者のプロダクトへの理解力・解像度が求められるのかなと思いました。
逆に言えば、導入のために技術的負債・ドキュメント整備と向き合うきっかけになるので、情報整理や現在地の確認のプロセスの一環としてAI主体で進めるという想像をするのもありかもしれませんね！
おまけ
ちなみにこの記事の構成についてはClaudeと壁打ちしながら整理していました。
人間が書きたいことをAIに補助してもらうはずが、AIに質問されてこちらが答えてる時間の方が正直長かったです（苦笑）
Claudeに質問しているつもりがClaudeに質問されているという、ある意味AI-Drivenな記事になったのかなと思います。
AI-DLC、思ったより人間側の言語化能力が問われるかもしれない。。。
さいごに
さて、オチもついたことですし、次の方へとバトンを渡すとしましょうかね！バトンを渡すのだけは人の責務ですし！
次回は何故かプライベートでもエンカウントすることが多いimaiさんです！
過去にも面白い技術を拾ってはブログで共有してくれてましたが、アドベントカレンダーではどんなものを持ってくるのか、とても楽しみです！
最後までお付き合いいただきありがとうございます！ 弊社ではエンジニアを募集しております。 ご興味がありましたらカジュアル面談も可能ですので、下記リンクより是非ご応募ください！ iimon採用サイト / Wantedly
