ブログ
AI 導入・活用に関する最新情報、技術トレンド、事例紹介をお届けします。
AI 導入・活用に関する最新情報、技術トレンド、事例紹介をお届けします。

AWSが「AI-DLC(AI-Driven Development Lifecycle、AI駆動開発ライフサイクル)」という開発方法論を提唱し、国内でもデブサミなどのカンファレンスで取り上げられる機会が増えてきました。この記事では、AI-DLCの概要を新しい用語とフェーズ構成から解説し、gaipackが実践しているAIDD(AI駆動開発)のプロセスと読み比べます。
AI-DLCは、AWSが提唱するAI中心のソフトウェア開発方法論です。AWSの公式ブログでは、AIをコード補完のような「ツール」としてではなく、開発プロセスの中核的な協力者として位置づけると説明されています。
基本原則は「AIが実行し、人間が監視する」です。AIが詳細な作業計画を作成し、意図のすり合わせを求めながら作業を進め、重要な決定は人間に委ねます。AIに丸投げするのでも、人間の作業をAIが部分的に手伝うのでもなく、AIが作業の主体になり、人間が判断の主体になるという分担です。
AI-DLCは、従来のアジャイル用語を置き換える新しい用語体系を持っています。
| AI-DLCの用語 | 置き換える対象 | 意味 |
|---|---|---|
| Bolt | スプリント | 週単位ではなく、時間・日単位で回す短期集中の作業サイクル |
| ユニットオブワーク | エピック | AIと人間が協働する作業単位 |
| Mob Elaboration | 要件レビュー | チーム全体でAIの質問や提案を検証しながら要件を固めるプロセス |
| Mob Construction | 設計・実装レビュー | 構築中の技術的決定をチームでリアルタイムに明確化するプロセス |
フェーズは3つに分かれます。開始(Inception)でAIがビジネス意図を要件・ストーリーに変換し、Mob Elaborationで人間が検証します。構築(Construction)でAIが論理アーキテクチャ・ドメインモデル・実装・テストを提案し、Mob Constructionで明確化します。運用(Operation)では、蓄積されたコンテキストを活用してAIがInfrastructure as Codeとデプロイを管理します。
各フェーズで計画・要件・設計の成果物をリポジトリに保存し、コンテキストを永続化する点も特徴です。前のフェーズの検討結果が次のフェーズのAIへの入力になるため、フェーズをまたいでも文脈が失われません。
従来のSDLC(Software Development Life Cycle)では、要件定義や設計といった工程は人間が担い、AIはコード補完などの局所的な支援に使われてきました。AI-DLCはこの前提を裏返し、各工程のドラフト作成をAIに任せ、人間の仕事を検証と意思決定に寄せます。
計画の単位も変わります。スプリントのような週単位の計画は、AIの作業速度に対して粗すぎるため、時間・日単位のBoltに置き換えられます。作業が速くなるほど、人間側の検証と承認がボトルネックになるので、チーム全体で一気に検証するMob形式が組み込まれている、という構造です。
gaipackのAIDDは、AI-DLCの登場より前から実案件で運用してきた開発スキームですが、読み比べると設計思想に共通点が多いことがわかります。
1つ目は、人間とAIの分担です。gaipackのAIDDでは、人間が実施すべき判断や創造的なタスクまでAIに任せるのではなく、人間の判断をより正確で高速にするための支援ツールとしてAIを位置づけています。AIが要件整理の補助や設計・実装・テストのドラフト生成を担い、人間は判断・顧客説明・最終承認に集中します。「AIが実行し、人間が監視する」というAI-DLCの原則と同じ構図です。
2つ目は、段階的レビューです。gaipackのAIDDは「①要件定義 → ②設計(概要) → ③設計(詳細)+デザイン+総合テスト設計 → ④実装・機能テスト」の4フェーズで進み、各ステップで承認を得たうえで次へ進みます。判断基準・承認フロー・責任者を事前に明記しておく運用は、AI-DLCがMob ElaborationやMob Constructionで人間の検証を各フェーズに埋め込んでいるのと同じ発想です。
3つ目は、成果物の連鎖です。gaipackのAIDDでは、ヒアリング文字起こしからPRD、UIモック、設計、計画タスク、実装、テストへと、各フェーズの出力が次フェーズの入力になります。AI-DLCの「成果物をリポジトリに保存してコンテキストを永続化する」という考え方と重なります。
AI-DLCは方法論であり、体制や契約の形までは規定していません。一方、gaipackのAIDDは受託開発の実案件で回すためのスキームなので、方法論に加えて運用の仕組みを持っています。
たとえば体制面では、承認ゲートの運用をPMの責務として定義し、AIDDスキームをプロジェクト全体へ浸透させるPMOや、リポジトリと開発ツールをメンテナンスするプラットフォームエンジニアを配置します。プロジェクト管理の実務は、AIDD PMOとしてサービス化しており、Claude/GPT/Geminiなどのマルチモデル構成やAWS/Googleの選択といったクラウド運用上の判断も、プロジェクト初期から管理論点として整理します。
また、AI-DLCの「AIがビジネス意図を要件に変換する」に相当する部分は、gaipackではAIDD 要件定義として提供しています。会議の文字起こしや既存ドキュメントといった非定型なインプットをAIで解析し、定型フォーマットのPRDとEPICを生成するサービスです。
方法論として何を目指すかは共通しつつ、それを顧客との契約・体制・承認フローに落とし込んだ点がgaipackのAIDDの特徴だと言えます。
| 観点 | AI-DLC | gaipack AIDD |
|---|---|---|
| 位置づけ | AWSが提唱する開発方法論 | 実案件で運用している開発スキーム |
| 人間とAIの分担 | AIが実行し、人間が監視する | AIがドラフトを生成し、人間が判断・承認する |
| 進め方 | 3フェーズ+Bolt単位の短サイクル | 4フェーズ+各ステップでの承認 |
| 人間の検証 | Mob Elaboration / Mob Construction | 段階的レビューと承認ゲートの運用 |
| コンテキスト | 成果物をリポジトリに保存して永続化 | 各フェーズの出力を次フェーズの入力に接続 |
AI-DLCのような方法論がクラウドベンダーから提唱されたことで、「AIがドラフトを作り、人間が検証して進める」という開発の形は、業界標準の方向性になりつつあります。AI駆動開発の全体像はAI駆動開発(AIDD)とは?導入手順を解説でも解説しています。自社の開発プロセスへの取り込みを検討している方は、お気軽にKDDIアイレットへお問い合わせください!
※ 本記事の内容は公開時点の情報です。サービスの名称・内容・料金は予告なく改訂されることがあります。