拡張 SDLC（SDLC augmenté）とは、AI 時代における開発チームの組織化 - Part III で示された提案であり、AI エージェントが実行の多くを担う開発に向けて、ソフトウェア開発ライフサイクル（Software Development Life Cycle）を定義し直すものである。変わらないサイクルにエージェントを差し込むのではなく、サイクルそのものを知識変換の連続的なループ、すなわち「理解する → 明示する → 設計する → 実行する → 検証する → 学ぶ → 充実させる」として定義し直し、それをビジネスと足並みをそろえたチームが、ビジネスエキスパート、プロダクトマネージャー、UX デザイナー、エージェントとともに回す。このサイクルでは、ソフトウェアは共有された知識体系（ビジネス上の意図、ドメインモデル、意思決定、仕様、ルール、テスト、アーキテクチャ上の選択、本番環境から得た教訓）を実行可能な形で表現したものとして描かれ、その知識体系を人間が絶えず充実させ、エージェントが利用する。
用法
この提案はサイクルを 5 つのモーメントを軸に組み立てており、それらを新たな逐次的段階ではなく、連続的な参照枠として提示している。
- Discover（発見） — ビジネス、ユーザー、機会を理解する。事前の分析フェーズとしてではなく継続的に行い、プロダクトディスカバリー、UX リサーチ、デザイン思考、EventStorming といった実践を通じて進め、エージェントがワークショップの内容を記録し統合する。
- Design（設計） — 知識をビジネスモデルへと構造化し、解決策を準備する。ドメイン駆動設計、Example Mapping、Gherkin シナリオが 仕様駆動開発 のツールに入力を与える。
- Build（構築） — 知識と意思決定をソフトウェアに変える。リビング仕様を共有された信頼できる唯一の情報源とし、複数の専門化されたエージェントが並行して作業し、開発者がそれらをオーケストレーションする。
- Validate & Deploy（検証とデプロイ） — ソフトウェアが期待される振る舞いと一致していることを、リビング仕様、ハーネスエンジニアリング、自動テスト、継続的インテグレーションのパイプラインによって継続的に検証する。従来のサイクルでは独立した段階だった品質保証は、この前の活動に組み込まれる。
- Learn & Evolve（学習と進化） — 本番環境を恒常的な知識の源として扱う。オブザーバビリティ基盤に接続されたエージェントが改善を提案し、その妥当性の判断はチームの責任として残る。
記事は、従来の 6 つの段階（分析、設計、実装、品質保証、デプロイ、サポートと保守）のそれぞれを拡張されたサイクルのいずれかのモーメントに対応づけ、その対応関係を使って、拡張 SDLC を従来のものとの断絶ではなく自然な進化として提示している。このサイクルは、ビジネス領域をエンドツーエンドで担う各チームにローカルなガバナンスの枠組みとして意図されており、企業全体にまたがる中央集権的なプロセスとして意図されているわけではない。
適用される場面
- 条件。 エージェントがエンジニアリング活動のうち増え続ける割合を担う組織、そして自らがライフサイクルを担うビジネス領域に沿って編成されたチームに向けて提案されている。
- 前提。 エージェントに与えるコンテキストの質がその有効性を左右する主要な要因であること、そしてエージェントが実行を加速させる一方で、製品を形づくる意思決定の責任はチームが保持し続けることを前提としている。
- 失敗モード。 記事はこれを、歴史的な構造を維持したまま単にステップを追加したり人間のアクターをエージェントに置き換えたりする、提案済みの AI SDLC やエージェント型開発ライフサイクル（Agentic Development Lifecycle）と対比している。そうしたものは実行の加速に焦点を当てており、モデルが最も広く普及した実践に収束するため、競合他社が生み出せるものに近いソフトウェアを生むおそれがあると論じている。また、製品のアイデンティティを定める意思決定を AI に委ねることにも警鐘を鳴らしている。
- 確立度。 拡張 SDLC はブログシリーズにおける 1 人の著者の提案であり、シリーズ自身の立場として提示されている。評価は報告されていない。