AI駆動開発とアジャイル開発の違い｜両立するのか、置き換わるのか

生成AIはコードだけでなく、要件の整理、仕様書、設計案、テストケースまで短時間で作れるようになりました。 仕様から実装までを一気に進められるなら、変化へ少しずつ対応するアジャイル開発は不要になるのでしょうか。

この疑問には、タスク単位の作業とプロダクト全体の学習を分けて考える必要があります。 AI駆動開発では、一つのタスクが仕様、設計、実装、テストの順に高速で進むため、局所的には小さなウォーターフォールのように見えます。 一方、何を作るべきかは利用者や市場からの反応で変わるため、プロダクト全体ではアジャイルの反復が残ります。

AI駆動開発とアジャイル開発は対立する方法論ではない

両者は、そもそも答えようとしている問いが異なります。

アジャイル開発は、不確実な状況で価値のあるソフトウェアを継続的に届け、得られた反応に応じて計画を変えるための価値観と原則です。 アジャイルソフトウェア開発宣言は、計画に従うことにも価値を認めたうえで、変化への対応をより重視しています。 したがって、アジャイルは「計画を立てない方法」でも「文書を書かない方法」でもありません。

AI駆動開発が答えるのは、別の問いです。 具体的には、仕様化、実装、テストなどの作業を生成AIへどこまで任せ、人間がどこで判断し検証するかを組み替える開発スタイルを指します。 定義と従来の開発との違いは、AI駆動開発（AIDD）の解説で詳しく整理しています。

アジャイルが扱う中心課題は、顧客価値と計画の不確実性です。 AI駆動開発が扱う中心課題は、生成AIと人間の役割分担です。 生成AIを使いながらアジャイルに開発することも、要件を固定した案件で生成AIを使うこともできます。

同じ理由で、アジャイルとスクラムも同義ではありません。 スクラムは、経験から得た情報を検査し、計画や成果物を適応させるための具体的なフレームワークです。 Scrum Guideも、スクラムが反復的かつ漸進的なアプローチを採用すると説明しています。 AI駆動開発と比較するときは、アジャイルの価値観、スクラムの運用、個々の技術プラクティスを分けておくと混乱を避けられます。

AIによって実装だけでなく、仕様化と設計まで高速になった

従来の生成AI活用は、入力中のコードを補完するところから始まりました。 現在のAIコーディングエージェントは、コードベースを調査し、実装計画を立て、複数のファイルを編集し、テストを実行するところまで進められます。

変化は実装速度だけにとどまりません。 会議のメモから要件候補を抽出し、曖昧な条件を質問に変え、仕様書、設計案、タスクリスト、テストケースの下書きを連続して作れます。 人間が白紙から文書を書く時間が減った結果、以前は省かれがちだった中間成果物も、小さなタスクごとに作りやすくなりました。

仕様を速く書けることと、正しい仕様を決められることは別です。 生成AIは「無料期間中に解約した場合の請求をどう扱うか」という選択肢を整理できますが、どの扱いが顧客との契約や事業方針に合うかまでは決められません。 AIが作った仕様の下書きを、事業責任者や開発者が検証して初めて実装の基準になります。

この使い方は、システム全体の仕様書を最初に完成させることとも異なります。 一つの機能に必要な仕様だけを作り、実装中に分かったことを反映して更新するからです。 仕様を生成AIへの入力として管理する考え方は、SDD（仕様駆動開発）の解説で扱っています。

文書作成の費用が下がると、開発の詰まりどころは文書を書く作業から、内容を承認する判断へ移ります。 AI駆動開発で見直すべきなのは、成果物の生成速度だけでなく、仕様確認やレビューの待ち時間です。

1つのタスクは「仕様、設計、実装、テスト」の極小ウォーターフォールになる

一つの機能変更を生成AIへ任せる場面では、作業に明確な前後関係が生まれます。 受け入れ条件を決める前にテストの正解は定まらず、設計を選ぶ前に変更対象も確定しないためです。

たとえば、請求に失敗したときの再試行機能は、次の順序で進みます。

1. 仕様：再試行の回数、間隔、利用者への通知、最終失敗時の扱いを決めます。
2. 設計：状態の持ち方、実行方法、二重請求を避ける仕組みを選びます。
3. 実装：生成AIが既存コードを調べ、必要な変更を加えます。
4. テスト：成功、途中失敗、最終失敗、重複実行などの受け入れ条件を検証します。

各工程の成果を次の工程へ渡す形だけを見ると、ウォーターフォールに似ています。 生成AIによって、一連の作業は数時間から数日で回ります。 極小ウォーターフォールの高速反復と表現できる形です。

ただし、「極小ウォーターフォール」は確立した開発手法の名称ではなく、タスク内の順序を説明するための比喩です。 従来型の大きな工程分割と違い、対象は独立して検証できる一つの変更に限られます。 テストで仕様の不足が見つかれば仕様へ戻り、設計が成立しなければ別案を選ぶため、一方向にしか進めないわけでもありません。

この形が機能するのは、タスクを小さく切り、完了条件を検証できる場合です。 「販売管理システムを作る」のような大きな要求を一つの連鎖で処理すると、生成AIが速くても巨大な仕様と差分が返り、検証できなくなります。 小ささは所要時間ではなく、変更の正しさを独立して判断できる範囲で決めます。

プロダクト全体では、アジャイルのフィードバックループが残る

タスク内の検証が終わっても、その機能が利用者に価値をもたらすかは確定しません。 すべての自動テストに合格した新しい検索画面が、実際には使われないこともあります。 技術的に正しく作れたことと、作る対象が正しかったことは別の判定です。

後者を確かめるには、動くソフトウェアを利用者へ届け、利用状況、問い合わせ、売上、業務時間などの変化を見る必要があります。 アジャイル宣言の背後にある原則が、価値のあるソフトウェアの早期かつ継続的な提供と、要求変更の受け入れを掲げている理由もここにあります。

生成AIは、一回の仮説を実装する費用と時間を下げます。 そのため、検証する仮説を小さくできれば、アジャイルの学習速度を上げられます。 一方、利用者へ届けて反応を観察する工程を省けば、生成量だけが増え、誤った仮説を従来より速く積み上げます。

市場、契約、法令、社内運用から得るフィードバックは、モデルの推論だけでは代替できません。 AI駆動開発によって短くなるのは主に技術的な作業時間であり、関係者の合意や利用データの蓄積に必要な時間は別に残ります。 プロダクトバックログの優先順位を変え、次に試す仮説を決めるループは、引き続き人間と利用者の側にあります。

スプリントやレビューなど、アジャイルのプラクティスはAI駆動開発でも機能する

AIコーディングエージェントが数時間で実装できるようになると、二週間のスプリントが長すぎるように見えるかもしれません。 しかし、スプリントはコード生成の待ち時間だけを区切るものではなく、チームと関係者が同じ目標を共有し、成果を検査して計画を調整する周期でもあります。

Scrum Guideでは、スプリント中に複数のインクリメントを作り、スプリントレビューより前に価値を提供できるとされています。 したがって、AIが完成させた変更をスプリント末までリリースせずに待たせる必要はありません。 技術的な変更は随時届けながら、スプリントを人間の意思決定と適応の周期として残せます。

既存のプラクティスは、次のように役割を調整すると機能します。

• バックログリファインメントとスプリントプランニング：生成AIに実装案を出させても、プロダクト目標、優先順位、受け入れ条件はチームが決めます。
• デイリースクラム：生成したコード量の報告ではなく、依存関係、判断待ち、レビューの滞留、生成AIが解けなかった問題を共有します。
• コードレビュー：仕様との対応、設計の妥当性、保守性、セキュリティを確認し、生成AIが示したテスト結果だけで承認しません。
• スプリントレビュー：コードの出来ではなく、完成したインクリメントが利用者と事業にもたらした結果を関係者と検査します。
• レトロスペクティブ：指示の粒度、テスト基盤、権限、レビュー負荷を振り返り、生成AIを含む作業方法を更新します。

Definition of Doneにも、生成AIが実行できる検査を具体的に含めます。 自動テスト、型検査、静的解析、必要な文書更新などが機械的に判定できれば、AIコーディングエージェントは失敗を検出して修正を繰り返せます。 自動検証の必要性は、AI駆動開発におけるテスト基盤の解説で詳しく扱っています。

スプリントより短い作業単位へ全面的に置き換える方法も提案されていますが、用語だけを変えてもレビューや承認が速くなるわけではありません。 AIの速度に合わせて開発プロセスを再設計する方法論は、AI-DLCの解説で確認できます。

ミクロではウォーターフォール、マクロではアジャイルと考える

二つの時間軸を分けると、AI駆動開発とアジャイル開発の関係を整理できます。

ミクロでは極小ウォーターフォール、マクロではアジャイルという整理は、この二層を短く表したものです。 ただし、タスクが独立して検証でき、プロダクトの反応を次の判断へ戻せる場合に限って成り立ちます。

自動テストがなければ、タスク内の高速反復は人間の目視確認で止まります。 利用者からのフィードバックがなければ、プロダクト全体の反復はアジャイルではなく、作業量を増やすだけになります。

AI駆動開発はアジャイルを置き換えるものではありません。 仕様まで速く書けるようになったからこそ、タスク内では検証できる順序を明確にし、プロダクト全体では何を作るかを短い間隔で見直す必要があります。