AI-DLCは「AI駆動型開発ライフサイクル」の略で、ソフトウェア開発ライフサイクル（SDLC）を拡張したものです。これは、AIを中心に全体を構築するソフトウェア開発手法を意味し、大規模言語モデル（LLM）、またはモデルのグループを、ソフトウェア開発のあらゆる段階で積極的な協力者として扱います。
2025年にAWSのRaja SPによって考案され、彼の「AI駆動型開発ライフサイクル（AI-DLC）メソッド定義」ホワイトペーパー[x]で説明されているAI-DLC方法論は、基本的に人間中心であったアジャイルやスクラムなどの従来の手法とは対照的に、人間と機械のコラボレーションとして提示されています。著者は、この変化を馬車から自動車への移行にたとえています。しかし、アジャイルにAIを追加するだけでは、いわば「より速い馬」にすぎません。これはヘンリー・フォードの言葉だとしばしば誤って伝えられている比喩ですが、AI-DLCはより根本的な進化を表しています。
近年、AIツールはSDLCに統合されてきましたが、AI-DLCはAIをさらに深く統合するものです。つまり、AIは単なるコード生成ツールに限定されるわけではありません。AIは単なる開発の一部ではなく、開発の中心となります。AIと人間の間のコラボレーションは継続的であり、人間のエンジニアはより監督的な役割を担います。
また、ソフトウェアの開発を支援するためにどのように使用されるかではなく、AIモデル自体がどのように構築されるかを表す「AIライフサイクル」という用語とも異なります。
Raja SP氏のホワイトペーパーでは、AI-DLCの基礎を表す10の原則が定義されています。
AIは既存のソフトウェア開発方法論に単純に組み込むべきではありません。AIは単なる生産性向上ツールではなく、中核的な役割を担っています。AI-DLCでは、AIが最初から存在していたとしたら、SDLCはどのようなものになるかを考えます。その結果、AI中心かつAIネイティブなSDLCが実現します。
従来のAI支援開発では、開発者が生成AIに個々のタスクを実行するよう繰り返し指示する形が一般的です。新しいパラダイムでは、開発者がAIに支援を求めてAIがタスクを実行するのを待つのではなく、開発者が意図を説明し、AIがエージェント機能を活用して計画を作成し、質問し、実行、検証、保守まで行い、その過程で人間のパートナーの承認を積極的に求めます。
以前の方法論では、開発チームが独自の設計手法を選択できました。AI-DLCは設計を一元化し、エンジニアリングの分野を方法論自体に取り入れます。ドメイン駆動型デザイン（DDD）、行動駆動型開発（BDD）、テスト駆動型開発（TDD）などのプラクティスが、ワークフローの不可欠な要素となります。これにより、エンジニアリングの品質が標準化されます。
AIは100%自律的に動作できるわけではありません。このホワイトペーパーでは、AIが人間の判断を活用できるよう、AIによる意思決定を人間が関与して検証・監督することを推奨しています。
エンタープライズ・ソフトウェアでは、複雑さは単にコードを書くことだけにとどまりません。大規模なシステムには、複数のサービスやアーキテクチャー、さまざまなユーザーや利害関係者が関わり、必然的に何年にもわたって蓄積された厄介な技術的負債も存在します。AI-DLCの価値の1つは、プロジェクト全体を通じてこれらすべてのコンテキストを保持することで、開発者がこの独自の包括的な理解を継続的に活用できることです。
AI-DLCはソフトウェア開発に革命をもたらしますが、必要な場面では人間が関与する役割を維持します。開発がビジネス目標に沿ったものとなるよう、プロジェクト全体を通じて継続的なフィードバックの文化が維持されます。これらの接点は自動化および文書化されているため、人間は最善の意思決定に集中できます。
著者は、組織が一夜にして新しい方法論に切り替えられるわけではないことを認識していました。このプロセスは段階的に進み、組織がすでに慣れ親しんでいる既存の概念やワークフローと統合されるため、導入による混乱を最小限に抑えられます。
AIは分野を超えて作業を実行し、コンテキストを維持できるため、かつては別々の専門家チームが必要だったタスクを、より高度な理解を備えた統合されたチームで完了できるようになりました。その結果、ハンドオフの頻度が減ります。
従来のSDLCでは、作業を計画、設計、実装、テスト、デプロイメントなどの明確なフェーズに分けて実施します。各フェーズの最後に、情報が次のフェーズに渡されます。AI-DLCでは、これらのフェーズを、タスクが同時かつ非線形に発生する連続的なフローとして扱うことで、フェーズ間の境界を曖昧にします。その結果、フィードバック・ループが短縮され、進捗が迅速化されます。
AI-DLCは、すべてのプロジェクトに厳格なワークフローを規定するのではなく、柔軟に適応します。事前に定義されたプロセスをプロジェクトに強制することはありません。どのようなシナリオでも、AIは目標と制約を分析し、そのプロジェクトに最も適したカスタマイズされたワークフローを生成します。
AI活用のグローバル・トレンドや日本の市場動向を踏まえたDX、生成AIの最新情報を毎月お届けします。本ニュースレターは【日本語】で配信しています。登録の際はIBMプライバシー・ステートメントをご覧ください。
このフレームワークでは、「ソフトウェア開発が人間の限界を中心に構築されていなかったらどうなるか」という問いを提起します。ウォーターフォールやアジャイルのようなこれまでの方法論は、人間のチームが作業を調整できるように設計されていました。AIは、この核となる前提を根本的に変えます。
スペック駆動型開発（SDD）手法を用いるAI-DLCでは、厳格なプロセスではなく意図を重視し、その仕様を最もよく満たすものをどのように構築するかをAIが判断できるようにします。これらの意図から派生する「ユニット」は、意図を達成するためのAIの道筋を示すタスクのセットです。ボルトは、作業単位が実行される反復です。
作業はいくつかのフェーズを経て進行します。インセプション・フェーズでは、意図を把握し、モブ・エボレーションを通じてそれをユニットに変換します。モブ・エボレーションとは、部門横断的なチームとAIシステムが協働し、大まかなビジネス・アイデアをユーザー・ストーリーに変換する共同ソフトウェア・プランニングの手法です。
要件分析はここから始まります。非機能要件（NFR）は、重要な属性、ガードレール、制約を定義します。ここでもリスク・アセスメントが行われますが、リスクと要件の両方がライフサイクル全体を通じて継続的にチェックされ、再評価されます。
ステアリング・ファイルはリポジトリーに保管されるマークダウン文書で、エージェントが従うべきルール、制約、アーキテクチャー標準、ワークフローを定義します。ステアリング・ファイルはインセプション・フェーズで作成されますが、AI-DLCの3つのフェーズすべてにわたって使用されます。プロジェクト全体のAIエージェントにとって、信頼できる唯一の情報源として機能します。
構築フェーズでは、実行が行われます。モブ構築中、人間のチームとAIは共同でコードを記述、テスト、デプロイします。
最終の運用フェーズでは、AIがインセプション・フェーズのビジネス要件と構築フェーズの技術的な決定事項を基に、デプロイメントの管理、インフラストラクチャーの自動化、稼働中のシステムの監視を行います。
SDLCの各段階において、AIは中心的な役割を果たします。
従来のSDLCでは、人間がビジネス目標をプロジェクト計画に手作業で変換します。組織では、AIアシスタントが大まかな目標を計画に落とし込むワークフローが試されています。AI-DLCでは、AIエージェントが明確化のための質問をし、曖昧な点を特定し、提案を行い、見落とされている可能性のある機会を指摘します。これらはストーリーとプロジェクト・ロードマップに変換されます。エージェント型AIは、このコンテキストをプロジェクト全体を通じて維持します。
AI-DLCでは、AIは会議を要約するだけではありません。Eメール、サポート・チケット、トランスクリプト、ドキュメンテーションを分析して、開発開始前に競合やギャップを特定します。ある会議で、別の会議で示されたプロジェクトのスケジュールと矛盾する重要なイベントが取り上げられた場合、エージェントはその潜在的な不一致を検知してフラグを立て、解決策を提示できます。これにより、個人や単一のチームでは維持することが難しい、プロジェクトの開始から終了までを網羅した包括的な理解が得られます。
ソフトウェア・エンジニアリングの中核的なタスクであるコード記述は、SDLCにおいてAIの活用が最も分かりやすく、AIが最も自律的な役割を担える領域です。AIコーディング・エージェントは、プロジェクトのコンテキスト、コーディング標準、ビジネス・ロジックを理解し、それらを踏まえて自律的に構築できます。開発者は意思決定を検証し、AI が生成したコードを改良します。
AIは開発の完了を待つのではなく、開発全体を通じてテストを継続的に生成および実行するため、テストはより広範な検証フェーズに置き換えられます。コードの欠陥を分析し、リグレッションを検知し、アーキテクチャーの制約への適合性を検証します。これは、すべてのステップでバックグラウンドで行われます。
AI-DLCの中でも、デプロイメントは継続的に最適化されるもう1つのプロセスです。エージェントは、リリース計画の準備、インフラストラクチャー構成の検証、ドキュメンテーションの生成、本番環境の展開の監視、CI/CDパイプラインの最適化を行います。AIは、リリースの安定性と安全性を確保するとともに、運用目標に沿ったものとなるよう積極的に支援します。
AI-DLCは、本番システムを継続的なフィードバック源として扱うことで、従来のソフトウェア保守の枠を超えています。AIは、ライフサイクル全体にわたって知識を保持することで、各リリースに以前の開発サイクルで得られた教訓を生かせるようにします。
このホワイトペーパーでは、大幅な見直しの必要性を最小限に抑えることを目指し、組織がさまざまなプラクティスを実践し、AI-DLCを独自のオーケストレーション・ツールに組み込むことを推奨しています。
このフレームワークは、KiroやAmazon Q DeveloperなどのAWSツールを中心に標準化されています。しかし、IBM BobやClaude Codeなどのエージェント型プラットフォームでも使用できます。
例えば、IBM Bobは、AI-DLC向けに構造的に最適化されたエンドツーエンドのエージェント型開発パートナーです。IBM Bobには、上位レベルの意図を受け取り、初期のアプリケーション設計構造に落とし込むAskモードとPlanモードがあります。コードの作成、変更、リファクタリング、バグの修正、新しいファイルの作成には、エージェント・モードを使用できます。ユーザーは、専門的な役割、ツールの制限、チーム・ワークフローを使用してカスタム・モードを構築することで、Bobの動作をカスタマイズすることもできます。