※この記事は「エムティーアイ Blog Summer 2026」の 6/29 の記事です。
こんにちは、AOE部の妹尾です。
2025年12月から現在（2026年6月）にかけて、AIを活用した開発手法をプロジェクトに導入してきた経緯をまとめました。
何度も試行錯誤を重ねた結果、現在の形になるまでの変遷を振り返ります。
ベストプラクティスではないかもしれませんが、一例として認識していただければと思います。
そもそも何をやっているのか
最近、AIに開発を手伝わせることで「速く・安く・品質を保って」開発できるんじゃないかという話をよく聞くようになりました。
ただ、「何を作るか」「どう設計するか」という判断をそのままAIに丸投げすると、思ってたのと全然違うものが出てきたり、後から大量に手直しが発生したりします。
AI-DLC（AI-Driven Development Lifecycle、AI駆動開発ライフサイクル）はその問題に対する1つの答えです。
「人間が計画して、AIが実装する」という役割分担を前提にして、要件・設計・テストシナリオを先に言語化・合意してから実装に入ります。
計画の質が、そのままコードの質を決めます。
なぜ AI-DLC を取り入れたのか
当時、AIを使った開発といえばコードの調査、修正やレビューくらいで、要件定義や設計には全然使えていませんでした。
2025年10〜11月頃にAI-DLCとCC-SDD（Claude Code Spec-Driven Development、仕様駆動開発の方法論）という考え方を知って、高品質かつ高速な開発を低コストで回せるようにしたいと思って導入を始めました。
導入の流れ
振り返ると、AI駆動開発手法の改善は「計画フェーズをどんどん厚くする」という一本の方向で進んできました。
最初はシンプルなフローから始めて、そこで出てきた課題をもとに計画フェーズを順番に足していった感じです。
2025年12月：仕様駆動開発の初回導入
OSSの cc-sdd（Kiro の仕様駆動開発フローをClaude Codeのスキル群として実装したツールキット）をプロジェクトに導入しました。
ただ、正直うまく定着しませんでした。
うまくいかなかった理由： cc-sddは多機能なツールキットで、一度に大量の概念・ドキュメント・コマンドが入ってきたため、何から使えばいいかを汲み取りきれなかった。
どう使えばいいか自分たちでも掴めていない状態では、チームへの展開もできなかった。
2026年2月：AI-DLC の導入
そこで、よくわからないものをそのまま使い続けるより、自分たちで理解しながら組み立てた方がいいと判断しました。
AI-DLCをベースに独自のスキル群を構築して、cc-sddと並立で動かし始めました。
フローをプロジェクトに合わせたことでチームを巻き込みやすくなりましたが、ドキュメントはよくなってきた一方で、実装はまだ意図とズレることがありました。
この時点のフロー
ユーザーストーリー作成 → ユニット分割 → ドメインモデル設計 → 実装
まだ足りなかったこと： チケット起票が手作業のままだったこと、あと「こう実装してほしい」とAIが実際に書いたものの間にけっこうズレが出ていた。
2026年3月：実装フェーズの補完
「こう作りたかったのに全然違う」というケースが続いたので、実装に入る前に一度レビューできるフェーズを入れることにしました。
実装プランを作るスキルを追加し、あわせてチケット起票も自動化しました。
実装プランをちゃんとレビューするようにしたことで、実装の方向性がかなり揃ってきました。
気づきをステアリングドキュメント（AIへの文脈指示書）に積み上げていったことで、手戻りも徐々に減っていきました。
この時点のフロー
ユーザーストーリー作成 → ユニット分割 → チケット起票 → ドメインモデル設計 → 実装プラン → 実装
2026年5月：cc-sdd を廃止し AI-DLC に一本化
cc-sddのスキルとAI-DLCのスキルが並立で動いていたことで、ドキュメントの置き場やフローが混在してきて「結局どっちを使えばいいの？」という状態になっていました。
cc-sddの良い部分はAI-DLCに取り込んだうえで完全に廃止して、管理を一本化しました。
2026年6月：AI-DLC の大幅機能強化
しばらく運用してみて、課題がいくつか見えてきました。実装に入ってから要件確認が必要になって手戻りが発生すること、外部APIに変更があったときにAIが現状を調査せず既知の情報だけで実装を進めてしまうこと、テストによる品質担保が弱いこと、フェーズ間のドキュメントの整合性が担保されていないことです。
そのタイミングでOSSの Spec Kit の存在を知って、参考にしながら以下の4つのスキルを追加しました。
- 要件明確化：実装前に要件や前提の曖昧さを潰す
- バックエンド調査：実装に必要な既存バックエンドのデータ・APIを調査し、既存実装の活用箇所と新規実装が必要な箇所を整理する
- テストシナリオ定義：実装前にテスト観点を言語化する
- 整合性チェック：各フェーズ間のドキュメントの整合性を確認する
改善後のフロー
ユーザーストーリー作成 → 要件明確化 → ユニット分割 → チケット起票 → バックエンド調査 → ドメインモデル設計 → テストシナリオ定義 → 実装プラン → 整合性チェック → 実装
苦労した点・教訓
誰を巻き込むかが全て
AI-DLCは「仕様を決めてから作る」プロセスなので、仕様確認が必要な場面で人待ちが発生しやすいです。
| 体制 | 結果 |
|---|---|
| 開発だけで回す | 効果は限定的。「企画に確認しよう」が待ち時間になってフローが止まる |
| 開発 ＋ 企画 | 確認ラリーは減るが、今度は「顧客に確認しよう」がボトルネックになる |
| 開発 ＋ 企画 ＋ 顧客 | 三者が同じフローに乗ることで、確認待ちの連鎖がなくなりAI-DLCが最大限機能する |
おおよその機能はAIが構築してくれるため、ボトルネックは技術の問題じゃなくて、誰をどれだけ巻き込むかという話になります。
認識を揃えるために、企画・開発・顧客の三者を最初から同じフローに乗せることが、AI-DLCの前提にして最大の障壁です。
※ ここでいう「顧客」はBtoBで意思決定できる顧客側の担当者を指しています。BtoCのように顧客が不特定多数の場合は、そのまま適用するのは難しいと思います。
会議が長くなりやすい
各フェーズでちゃんと合意を取ろうとするので、会議が長引きやすく終わった後の疲労感が大きいです。
三者を巻き込めば巻き込むほど調整コストも上がります。
セッションを短く区切ったり非同期で進めたりといった工夫が必要です。
プロジェクトに合わせて育てていく
AI-DLCは汎用的なプロセスなので、そのまま使うのは正直難しいです。
必要な部分だけ取り入れて、実運用でフィードバックを積み重ねながら自分たちのプロセスとして育てていくのが現実的だと思っています。
Operations（運用フェーズ）はまだ手つかず
AI-DLCは「Inception（要件定義）」「Construction（実装）」「Operations（運用）」の3フェーズで構成されています。
InceptionとConstructionはある程度形になってきましたが、3つ目のOperationsについてはまだ答えが出ていません。
AIを運用にどう活かすか、これからの課題です。
おわりに
AI-DLCに「これが正解」という固定の形はなく、プロジェクトの状況やチームの習熟度に応じて継続的に見直していくものだと考えています。
この記事で紹介したフローも、今後また変わっていくと思います。
試行錯誤の途中ですが、同じように導入を検討している方の参考になれば幸いです。
