AI駆動開発とアジャイルの違い｜ウォーターフォールとの比較

AI駆動開発とアジャイルは、実は同じ軸で比べるものではありません。ウォーターフォールやアジャイルは「開発をどんな順序・単位で進めるか」の型で、AI駆動開発は「開発の作業をAIがどこまで担うか」の考え方です。この記事では、両者の違いを整理したうえで、AIを使うと進め方のどこが変わり、どこが変わらないのかを、新規事業に取り組む会社の目線で解説します。

前提：3つは同じ軸の言葉ではない

「AI駆動開発 アジャイル 違い」と検索する背景には、「AI駆動開発は、アジャイルのような新しい開発手法の一つなのか」という疑問があるのではないでしょうか。結論から言うと、そうではありません。

ウォーターフォールとアジャイルは、「いつ何を決め、どの順序で作るか」という進め方の型です。一方、AI駆動開発は「要件の整理、設計、実装、テスト、レビューといった作業を、AIが担う開発」を指す言葉です。前者は進め方の軸、後者は作業の担い手の軸なので、組み合わせることができます。

たとえば、ウォーターフォールで進める開発の実装工程にAIを使うこともできますし、アジャイルの短い反復の中でAIを使うこともできます。まずは、3つそれぞれの特徴を簡単に確認します。

ウォーターフォール

ウォーターフォールは、要件定義、設計、実装、テスト、リリースという工程を、滝が上から下へ流れるように順番に進める型です。前の工程が終わってから次へ進むため、全体の計画や見積もりを立てやすいことが特長です。

一方で、実際に動くものが見られるのは後半になりがちです。要件定義の段階で食い違いがあっても、実物を見るまで気づきにくく、気づいた時点では戻るコストが大きくなります。仕様が固まっている開発には向きますが、新規事業のように途中で考えが変わりやすい開発では、この点が課題になります。

アジャイル

アジャイルは、短い期間で「作る・見せる・直す」を繰り返しながら進める型です。2001年にまとめられた「アジャイルソフトウェア開発宣言」では、「包括的なドキュメントよりも動くソフトウェアを」「計画に従うことよりも変化への対応を」といった価値観が示されています。代表的な進め方であるスクラムでは、1か月以内の期間（スプリント）を区切って反復します（出典：スクラムガイド）。

実物を見ながら方向を修正できるため、不確実性の高い開発に向きます。ただし、反復のたびに発注側が内容を確認し、優先順位を決める必要があります。決める側の関与が少ないと、進んでいるのに事業の目的から離れていく、ということも起こり得ます。

AI駆動開発

AI駆動開発は、開発の各工程にAIを組み込み、人とAIで役割を分けて進める考え方です。定義は発信者によって幅がありますが、JustFitでは、GPTやClaudeなどのLLM（大規模言語モデル）を「頭脳」として、開発工程ごとに役割を与えた複数の専門AI（要件定義・設計・DB設計・実装・テスト・レビュー）がチームのように動く、独自の開発基盤「LAF（LEGAREA AI Framework）」を使っています。人が担うのは「何を作るかを決めること」と「品質の最終判断」です。

AIと人の役割分担の全体像は、AI駆動開発とは｜AIと人の役割分担と発注側の要点でも解説しています。

AIを使うと、進め方はどう変わるか

進め方の型にAIが加わると、何が変わるのか。ここでは5つの変化に整理します。

1. 実物が見られるまでの距離が短くなる

ウォーターフォールの弱点は「実物が遅い」こと、アジャイルの課題は「1回の反復で動くものを出すのに人手と時間がかかる」ことでした。実装やテストの一部をAIが担うと、構想から動くものができるまでの距離を縮めやすくなります。

JustFitでは、構想をもとに約1ヶ月で実際に動くプロトタイプを開発し、お客様が実物を見てから契約を判断できる進め方をとっています（「先に作って、後から決める」＝PROTOTYPE FIRST）。これは、ウォーターフォールで後半にならないと見えなかった実物を、最初に持ってくる発想です。

ただし、AIを使えばどんな開発でも速くなる、という話ではありません。作る内容が複雑であったり、決めるべきことが決まっていなかったりすれば、時間はかかります。メリットと注意点は、AI駆動開発のメリットとデメリット｜向く開発と注意点で整理しています。

2. 工程の境界が薄くなる

ウォーターフォールでは、要件定義書を作り、それを設計者に渡し、設計書を実装者に渡す、という「受け渡し」が工程の境目でした。AI駆動開発では、要件の整理、設計、実装がAIとのやり取りの中で連続して進みます。実物を触って「ここは違う」と気づき、要件に戻って直す、という往復がしやすくなります。

その分、「何を決めたのか」が記録に残らないまま進んでしまうリスクもあります。工程の境目が薄くなるからこそ、決定事項や設計の意図を残す工夫が必要です。残し方はAI設計書の自動生成は可能？後から困らない残し方をご覧ください。

3. 仕様の文章が、そのまま実装に近づく

ウォーターフォールでは設計書が主役、アジャイルでは動くソフトウェアが主役とされてきました。AI駆動開発では、AIに渡す仕様や指示の文章が、そのまま出来上がるものの質を左右します。仕様があいまいなら、AIはもっともらしく補って作ってしまうことがあります。

つまり、ドキュメントを軽視してよいわけではなく、「AIが読んで正しく実装できる仕様」を書く力が大切になります。作りたいものを言葉にする手順は、AI開発の仕様の伝え方｜作りたいものを言葉にする手順にまとめています。

4. 人の役割が「作る」から「決める・確かめる」へ寄る

実装の多くをAIが担うと、人の仕事は、何を作るかを決めること、出来上がったものを確かめることへ重心が移ります。LAFでも、設計やレビューの場面でLEGAREAの経験と品質基準にもとづいて提案・チェックを行い、最終的な品質の判断は人が担います。

エンジニアの役割の変化については、AI開発でエンジニアの役割はどう変わる？任せる作業と判断で詳しく扱っています。

5. ボトルネックが「実装」から「判断」へ移る

従来の開発では、実装に時間がかかることが全体の速度を決めていました。AIが実装を速めると、次に目立つのは「発注側が決めるまでの時間」です。仕様の確認に数日かかる、優先順位が決まらない、という状況では、AIがどれだけ速くても全体は進みません。

この意味で、発注側に判断の窓口を置くことがこれまで以上に大切になります。役割や判断の仕方は発注側のプロダクトオーナーとは｜役割と判断のしかたで解説しています。

変わらないこと：AIが入っても残る課題

進め方が変わる点がある一方で、変わらない点もあります。

何を作るかは、人が決める

誰のどんな課題を解決するのか、そのために最初に何を作るのか。これはAIが代わりに決めてくれるものではありません。AIは要件の整理を助けてくれますが、事業の目的に照らして選ぶのは人です。整理と決定の線引きは、AI要件定義で変わること｜AIが整理し人が決める範囲で解説しています。

品質の確認は、人が行う

生成AIは、もっともらしいが誤った内容を出力することがあります。コードも例外ではなく、動いているように見えて、想定外の入力で壊れる、権限の扱いが甘いといった問題が混ざる可能性があります。そのため、テストやレビューをAIが担う場合でも、最終的な品質の判断には人の確認が必要です。理由はAI開発でも品質には人の確認が必要な理由で、混ざる誤りの見つけ方は生成AIのハルシネーションが開発に混ざるとき｜見つけ方と防ぎ方で扱っています。

経営陣と現場の合意は、必要なまま

新規事業では、経営陣と現場が同じ目的を見ているのに、判断の材料と進める速度が違うために話が噛み合わないことがあります。ズレているのは目的ではなく進め方です。AIを使っても、この構造は残ります。動く実物を見ながらすり合わせる、という進め方が効くのは、AI駆動開発でも同じです。背景は新規事業で経営陣と現場がすれ違う原因は進め方のズレをご覧ください。

新規事業では、どう使い分けるか

では、新規事業でウォーターフォール、アジャイル、AI駆動開発をどう考えればよいでしょうか。ここでは、一般的な考え方を整理します。

要件が固まっている部分は、計画型が向く

法令や外部の規格に沿う必要があり、手戻りが許されない部分、あるいは既存システムとの接続のように仕様が外から決まっている部分は、ウォーターフォール的に計画を立てて進めるほうが安全です。この場合でも、実装やテストの工程でAIを使うことはできます。

事業の仮説を確かめる段階は、反復型が向く

新規事業の初期は、「本当にこの機能が求められているのか」「利用者はこう使うのか」が分かっていません。計画を細かく固めても、使ってみて変わることが多い段階です。この段階では、アジャイルのように小さく作って確かめ、方向を直していく進め方が向きます。

AI駆動開発は、この「小さく作って確かめる」の1回あたりの負担を軽くしやすい点で、新規事業と相性が良いと私たちは考えています。プロトタイプやMVPなどの言葉の違いはプロトタイプとモックアップ・MVPの違い｜新規事業の使い分けで、小さく確かめる投資判断の進め方は新規事業の開発は小さく作って確かめる投資判断の進め方で解説しています。

確かめたあとは、育てる進め方につなぐ

プロトタイプで手応えを得たあとは、機能を足し、利用者の声を反映しながら育てていく段階に入ります。ここでも、アジャイル的に少しずつ改善していく考え方が合います。納品して終わりではなく、業務に合わせて育て続けることが前提になるためです。考え方はシステムは納品後の改善で育てる｜新規事業の考え方で扱っています。

整理すると、次のようになります。

• 仕様が固まっていて、変更が少ない部分：計画型を軸に、AIで実装やテストを効率化する
• 仮説を確かめる段階：短い反復で実物を見ながら、AIで1回あたりの作る負担を軽くする
• 確かめたあと：少しずつ機能を足し、改善を続ける

どれか一つの型に当てはめるよりも、事業の段階に応じて組み合わせる、という見方が現実的です。

発注側が確認したい5つの点

外部の開発会社にAI駆動開発を依頼する場合、「AIを使っています」という言葉だけでは、進め方は分かりません。確認しておきたい点を5つ挙げます。

1. どの工程でAIを使い、どこを人が判断するか

要件定義から実装、テスト、レビューまでのうち、AIが担う範囲と人が判断する範囲を聞いておきます。人の確認が入る場所が明確であれば、品質への考え方も見えてきます。依頼前に確かめたい点は、AI受託開発に依頼する前に確かめたい6つのことにまとめています。

2. 実物をいつ、どのくらいの頻度で見られるか

ウォーターフォールの弱点は実物が遅いことでした。AIを使う場合でも、実物を見られる時期が後ろにずれていては意味がありません。最初の実物がいつ見られるか、その後どのくらいの間隔で確認できるかを確かめます。進捗の見方はシステム開発の進捗確認のしかた｜定例会とデモの見どころが参考になります。

3. 仕様変更をどう扱うか

実物を見て「ここを変えたい」となるのは自然なことです。変更を受け付けるのか、範囲や条件をどう決めるのかは、事前に擦り合わせておくと行き違いを防げます。システム開発の仕様変更への対応｜追加要望の扱い方をご覧ください。

4. 見積もりの前提と範囲

AIを使うと、工数の積み上げでは説明しにくい部分が出てきます。見積もりでは金額そのものより、何を前提に、どこまでを範囲としているかを先に確認します。考え方はシステム開発の見積もりの違い｜金額より先に見る前提と範囲と、AI開発で人月の考え方はどう変わる？工数で測れない部分で整理しています。

一般に、完成した成果物を約束する請負契約はウォーターフォールと、作業の遂行を約束する準委任契約は反復型と相性が良いと言われます。契約の違いは受託開発とは？メリット・デメリットと依頼の流れ・契約の違いで解説しています。

5. 納品後の保守、権限、セキュリティ

AIが書いたコードを、後から誰が読み、直せるのか。権利や安全性はどう確認するのか。ここは見落としやすい点です。AI生成コードの保守は可能か｜引き継ぎと改修の確認点、AI生成コードのセキュリティ｜確認点と人の役割、AI生成コードの著作権｜事業で使う前の確認点もあわせてご確認ください。

まとめ

AI駆動開発は、ウォーターフォールやアジャイルと並ぶ「もう一つの進め方の型」ではなく、開発の作業をAIがどこまで担うかという別の軸の考え方です。そのため、「どちらが優れているか」ではなく、「進め方の型にAIをどう組み合わせるか」を考えることになります。

AIが入ることで変わるのは、主に次の点です。

• 構想から動く実物までの距離が短くなり、小さく作って確かめる負担が軽くなる
• 要件・設計・実装の境目が薄くなり、決定事項を残す工夫が必要になる
• 仕様の文章がそのまま実装の質に影響する
• 人の役割が「作る」から「決める・確かめる」へ寄る
• ボトルネックが実装から、発注側の判断へ移る

一方で、何を作るかを決めること、品質を人が確認すること、経営陣と現場が目的を共有することは、これまでと変わりません。新規事業では、事業の段階に合わせて計画型と反復型を使い分け、実物を見ながら判断を重ねていくことが、AI時代にも有効な進め方だと私たちは考えています。

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく進め方で、納品後も毎月ひとつの機能追加まで伴走します。仕様が固まっていない段階や、稟議を通す前の段階でもご相談いただけますので、詳しくはJustFitのサービス紹介をご覧ください。