# AI駆動開発とは？従来の開発との違い・工程別の変化・始め方を解説

- URL: https://www.waltsu.co.jp/magazine/ai/ai-driven-development/
- カテゴリ: AI活用 > AI開発ツール
- 執筆: 藤井 俊輔（代表取締役） / 監修: 小洞 映（システムエンジニア）
- 公開日: 2026-09-10 / 最終更新日: 2026-10-29
- 発行: waltsu株式会社（waltsu MAGAZINE）

## こんな人におすすめ

- AI駆動開発が何を指す言葉なのか、一言で説明できるようにしたい
- 開発の工程がどう変わり、人がどこに残るのかを知りたい
- 自社の開発に何から取り入れるか、最初の1つを決めたい

コード生成ツールを入れた会社は増えました。ところが納期を聞くと、以前と変わらないという話も同じくらい聞きます。書く速度は上がったのに、完成までの時間が縮まらない。この食い違いを説明する言葉が、AI駆動開発（AIDD）です。 AI駆動開発とは、AIを補助ツールではなく、開発プロセスの前提に据える進め方です。実装だけでなく、要件定義から保守までの全工程を対象にします。速くなるのは作る工程だけで、決める工程と確かめる工程はむしろ増えます。本記事で整理するのは、従来の開発との違い、工程別の変化、人の役割、失敗の型、始め方、経営が見るべき指標です。

**この記事のゴール（読了目安 約10分）**：速くなる工程と速くならない工程を分けて説明でき、自社で最初に任せる工程を1つ決め、その確かめ方を先に用意できるようになる。

## この記事の結論

- AI駆動開発は、AIを開発プロセスの前提に据えて工程と役割を組み替える進め方
- 速くなるのは実装とテスト。要件定義と設計は変わらず、レビューと保守はむしろ増える
- 人の役割は「書く」から「決める・確かめる」へ移る。作業は移るが責任は移らない
- 始め方は、任せる工程を1つ決め、その確かめ方を先に紙1枚で決めるところから

## AI駆動開発とは

AI駆動開発は、AIを開発プロセスの前提に据え、工程と役割の配置を組み替える進め方です。手元でAIに補完させる開発との境目もあわせて示します。

### AI駆動開発の定義

AI駆動開発とは、AIを補助的な道具ではなく、開発プロセスの前提に据える進め方です。頭文字からAIDDとも呼ばれます。要件定義から保守までの工程について、どこにAIを置き、どこに人を残すかを設計し直すところまで含みます。**変えるのはツールではなく、工程と役割の配置です。**

### 「AIを使う開発」との違い

個々の開発者が手元でAIに補完させるのは、AI支援の開発です。成果物の作り方もレビューの型も従来のままで成立します。AI駆動開発は、AIが最初の成果物を出す前提で、誰が何を決め、どこで確かめるかまで組み替えます。**境目は、AIを使っているかではなく工程を組み替えたかです。**

![AIを横のツールとして使う開発と、6工程の前提にAIを敷いて人が決める・確かめる位置に立つAI駆動開発の対比](https://www.waltsu.co.jp/wp-content/uploads/2026/09/ai-driven-development01.png)

## なぜ今注目されているのか

背景は3つあります。

- **エージェントの実用化**: 複数ファイルにまたがる変更まで任せられる道具が実務に入った
- **利用が既定になった**: [GitHub の Octoverse 2025](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/) では、GitHub に新しく参加した開発者のほぼ80%が最初の1週間のうちに GitHub Copilot を使っているとされる
- **国内の人材制約**: [IPA（情報処理推進機構）](https://www.ipa.go.jp/digital/ai/software-engineering.html)も「AIを用いたソフトウェア開発」を課題として調査の対象に置いている

**道具が揃ったから注目されたのではなく、使う前提が先に固まりました。**

## 従来の開発との違い

違いは、誰が最初の成果物を出すかにあります。従来は人が書き、AIが横で助けました。AI駆動開発ではAIが最初の案を出し、人は採るか捨てるかを決めます。**「人が作り、AIが助ける」から「AIが作り、人が決める」への反転です。**

| 観点 | 従来の開発 | AI支援の開発 | AI駆動開発 |
|---|---|---|---|
| 主体 | 人が全工程 | 人が主、AIが補助 | AIが担い人が判断 |
| 成果物の起点 | 人が白紙から | 人が書きAIが補完 | AIが最初案を出す |
| 人の主な作業 | 調べる・書く・直す | 書く量が減る | 決める・確かめる |
| 品質の担保 | 熟練とレビュー | 熟練とレビュー | 受け入れ基準と自動検証 |
| 速さの出どころ | 人数と稼働時間 | 個人の作業速度 | 待ち時間の短縮 |

## 要件定義と設計はどう変わるか

要件定義では、曖昧なまま渡した部分をAIが勝手に補います。設計は、AIに渡す前提を人が言語化する作業に変わります。

### 要件定義：曖昧さが命取りになる

曖昧な仕様は、人に渡せば質問になって戻ってきますが、AIに渡すと戻ってきません。**足りない前提を勝手に補い、それらしい成果物が出てきます。**決めていなかったことに気づくのが遅れます。

waltsu の制作案件の見積もりでも、日程を縮めるのは手を動かす人数ではなく、要件・素材・承認者・更新ルールが先に決まっているかどうかでした。要件が具体的に整理されていた案件は、通常より短い期間で見積もれると判断しています。決まっていない部分は、AIに渡しても決まりません。

### 設計：AIに渡す前提を作る

AIの出力の質は、渡した前提の質で決まります。境界、命名、使ってよい依存、やらないことを、人がテキストで先に置きます。仕様を確定させてから渡す進め方が、仕様駆動開発です。**設計はAIに任せる作業ではなく、AIに渡すために言語化する作業になります。**詳しくは[AI時代に効く設計スキル](https://www.waltsu.co.jp/magazine/ai/ai-ddd-skills/)で解説しています。

## 実装とレビューはどう変わるか

実装では、書く仕事が指示して採否を決める仕事に移ります。レビューは、件数が増えるのではなく1件あたりの差分が大きくなります。

### 実装：書く人から指示する人へ

コードを書く時間が減るのは確かです。ただし減るのは打鍵の時間で、判断の時間ではありません。仕事は、何を作らせるかを言葉にし、出てきたものを採るか捨てるかを決めることに移ります。**指示の粒度が、そのまま成果物の粒度になります。**どこまで任せるかは[自律型AIエージェント](https://www.waltsu.co.jp/magazine/ai/autonomous-ai-agent/)の記事で整理済みです。

### レビュー：量が一気に増える

作る速度が上がると、確かめる対象が同じだけ増えます。[Apiiro の調査](https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/)では、AIを使う開発者のコミット数は、そうでない開発者の3〜4倍になっています。一方でプルリクエストの本数は3分の1近く減っており、**1回のレビューで見る差分は以前より大きくなりました。**件数が増えるのではなく、1件が大きくなります。

## テストと保守はどう変わるか

テストで人が確かめるのは網羅性より、守りたいものが守られているかです。保守では、その作りを選んだ理由の記録を残します。

### テスト：網羅より意図の確認

テストケースの生成はAIが得意で、境界値も異常系も人より早く並びます。AIが決められないのは、**何を守りたいのかという受け入れ基準**です。書かれた条件は再現できても、書かれていない前提は再現できません。人が確認するのは網羅性ではなく、守りたいものが守られているかです。

### 保守：説明できるコードを残す

AIは実装と同時に説明文も出せるので、ドキュメント不足は減ります。減らないのは、なぜその作りを選んだかという判断の記録です。選ばなかった案、諦めた条件、当時の制約は生成物に残りません。**半年後に役立つのは、動くコードではなく直す理由を説明できる記録です。**

## 速くなる工程とならない工程

工程が一律に速くなると考えると、判断を誤ります。**効果は、速くなった工程ではなく、増えた工程を吸収できたかで決まります。**

| 工程 | 変化 | 速さが変わる理由 |
|---|---|---|
| 要件定義 | ほぼ変わらない | 決めるのは人。曖昧さは埋まらない |
| 設計 | ほぼ変わらない | 渡す前提の言語化がむしろ増える |
| 実装 | 速くなる | 生成そのものは確実に速い |
| レビュー | むしろ増える | 1件あたりの差分が大きくなる |
| テスト | 速くなる | ケースの生成を任せられる |
| 保守 | むしろ増える | 判断の記録が残らないと読み解けない |

速くなる2工程で得た時間の行き先は、増える2工程です。

## 人の役割はどこへ移るか

人の仕事は、何を作り何を作らないかを決めることと、権限や外部との接続点を確かめることに移ります。責任は人に残ったままです。

### 決める人になる

AIが案を出せるようになったぶん、選ぶ回数が増えます。何を作るか、どこまで作らないか、複数案のどれを採るか。**捨てる判断が、人にしかできない仕事になりました。**作らない範囲を決めないと、選択肢の管理が仕事になります。

### 確かめる人になる

もう1つは、確かめる役割です。受け入れ基準、権限の境界、外部との接続点。ここは動作確認では確かめられません。**作業は移りますが、責任は移りません。**発注する側も同じで、[誰が仕様を決めるか、誰がレビューを持つか、保守を引き継げるか](https://www.waltsu.co.jp/magazine/ai/forward-deployed-engineer/)を確認します。

![書く・調べる・直すの作業がAI側へ移り、決める・確かめる・責任を人が持つ役割の移動を示す横フロー](https://www.waltsu.co.jp/wp-content/uploads/2026/09/ai-driven-development02.png)

## うまくいかない3つの型

現場で起きる失敗は3つです。手当てする場所がそれぞれ違います。

### レビューが追いつかない

作る速度だけを上げると、確かめる工程で滞留します。生成は1日で終わり、レビュー待ちが2週間並ぶ。**ボトルネックは消えたのではなく、下流へ移動しただけです。**納期が変わらない現場の多くは、この形をしています。

### 仕様が曖昧なまま流れる

決まっていないことが、決まったものとして実装されます。AIは質問を返さないので、曖昧さは指摘されないまま成果物へ変換されます。**戻りは実装中ではなく、受け入れの段階でまとめて出ます。**

### 誰も読めないコードが増える

動くけれど、なぜその作りなのかを誰も説明できない。動作確認では見つかりません。

表示が遅いという相談で既存サイトを診断したときも、原因は画面を出す前に全データを生成する作りでした。エラーは出ず、表示も正しい。動くかどうかでは気づけず、なぜその作りにしたのかの記録も残っていませんでした。

## AI駆動開発の始め方

任せる工程を1つ決め、前提をテキストで置き、レビューの型を作ってから、範囲を広げる順番を決めます。この4つを順に説明します。

### 任せる工程を1つ決める

全工程に一度に入れると、どこで効果が出たのか分かりません。最初は構成案、下書き、テストケースのような中間成果物から任せます。**捨てても損失が小さいものが、最初に任せる対象に向いています。**

### 前提をテキストで置く

制約、命名、使ってよい依存、やらないこと。これを人が書いて、毎回同じものを渡します。**ここを自動化すると、AIが自分の前提を自分で決めることになります。**

### レビューの型を先に作る

生成を始める前に決めるのは、見る場所と見ない場所です。紙1枚に3つ書けば足ります。

- **必ず人が見る**: 権限、外部連携、個人情報を扱う箇所
- **機械に見せる**: 書式、命名、既存テストの通過
- **見ない**: 生成物の書き方の好み

### 範囲を広げる順番を決める

広げる順番は、影響範囲が小さく戻せるものからです。社内向けから社外向けへ、参照だけの機能から更新を伴う機能へ。**戻せない範囲から始めると、1回の失敗で全体が止まります。**

## 品質をどう担保するか

人が必ず見る場所を3つに絞り、人が見ない部分は機械で止める仕組みを置きます。

### 人が必ず見る場所を決める

全部を人が見るのは量の面で続きません。決めるのは見る場所です。次の3つは、動いてしまうと問題が表に出ません。

- **権限**: 想定より広い権限を要求していないか
- **外部連携**: どのサービスと、どのデータをやり取りするか
- **個人情報**: どこに保存し、誰が参照できるか

**危ないのは動かないコードではなく、想定より広く動くコードです。**任せるときのリスクは[AIエージェントのセキュリティ](https://www.waltsu.co.jp/magazine/security/ai-agent-security/)で整理しています。

### 自動で止める仕組みを置く

人が見ない部分は、機械で止めます。既存テストの通過、検証環境での確認、1回の変更の大きさの上限。**安心して捨てられる範囲を先に作ると、任せられる範囲が広がります。**

## 経営が見るべき指標

生成した行数や体感の速さは指標に向きません。リードタイム、デプロイ頻度、変更失敗率、復旧時間の4つを、速さと安定性の対で見ます。

### 行数や速度を成果にしない

生成した行数、コミットの本数、体感の速さ。どれも増やそうと思えば増やせるので、指標には向きません。**生成量は成果ではなく、確かめる仕事の量です。**

### 4つの指標で対にして見る

見るのは、リードタイム、デプロイ頻度、変更失敗率、復旧時間の4つです。前2つは速さ、後ろ2つは安定性を示します。[DORA が2025年に公開した調査](https://cloud.google.com/blog/ja/products/ai-machine-learning/announcing-the-2025-dora-report)では、世界のIT専門家およそ5,000人を対象に、AIの活用がスループットと製品パフォーマンスには正の関係、デリバリの安定性とは負の関係を示したとの報告です。**速さと安定性は、必ず対で見ます。**

## 【プロの視点】欠陥は設計側に出る

一般的な解説は、AIが書いたコードは必ずレビューしましょう、で終わります。更新されていないのは、そのレビューが何を見つけるためのものかです。

見るべきは、**コードが動くかどうかではなく、どこに境界と権限の線を引いたか**です。

セキュリティ企業の Apiiro は、AIが関与したコードの解析として、構文エラーが76%、ロジックの誤りが60%減った一方、権限昇格につながる経路が322%、アーキテクチャ設計の欠陥が153%増えたとしています。比較対象はAIを使わない開発者です。**細かい間違いは減り、設計レベルの間違いは増えます。**

にもかかわらず、現場のレビューは行を追う形のままです。誤字、命名の揺れ、書式は、AIが得意な領域です。人が重ねて見ても新しい発見は多くありません。**AIが減らした欠陥を人が探し、増やした欠陥を誰も見ていない**という配置になります。

判定基準を置き換えます。この変更はどこまでの権限を要求しているか。外部との接続点は増えていないか。読む場所を変えるだけで、同じ時間のレビューで別の問題が見つかります。

![構文エラーとロジックの誤りが減る一方、権限昇格の経路とアーキテクチャ設計の欠陥が増えることを示す上下比較](https://www.waltsu.co.jp/wp-content/uploads/2026/09/ai-driven-development03.png)

## 【waltsu視点】速さより確かめる力

waltsu の編集軸は、価値は時短ではなく試行回数にある、というものです。AI駆動開発では、**試行回数を決めるのは作る速度ではなく、確かめて捨てる速度**になります。

作る速度が10倍になっても、確かめる速度が変わらなければ、試せる回数は変わりません。増えるのは、確かめられていない成果物です。

DORA の2025年の報告は、AIについて、チームを直すのではなくそこにあるものを増幅すると表現しています。**強いチームはより強くなり、弱さのあるチームは弱さが拡大されます。**確かめる仕組みが無い組織がAIを入れると、増えるのは試行ではなく手戻りです。

だから最初の投資先は、生成ツールではありません。テスト、検証環境、レビューの型。**安心して捨てられる範囲の広さが、そのまま試行回数の上限になります。**

明日やる一歩は1つです。任せる工程を1つ選び、その工程の確かめ方を紙1枚に書いてください。何を見るか、誰が見るか、何をもって合格とするか。この3行が決まれば、その工程は今日から任せられます。

![作る・確かめる・決める・捨てるか進めるかの循環と、その中心にある試行回数を示す循環図](https://www.waltsu.co.jp/wp-content/uploads/2026/09/ai-driven-development04-1.png)

## まとめ

AI駆動開発とは、AIを開発プロセスの前提に据え、工程と役割を組み替える進め方です。速くなるのは実装とテスト、ほぼ変わらないのが要件定義と設計、むしろ増えるのがレビューと保守です。

人の役割は、書く人から決める人・確かめる人へ移ります。移るのは作業であって責任ではありません。だから最初に用意するのは生成ツールではなく、確かめる型と、安心して捨てられる範囲です。全社の進め方は[AX推進](https://www.waltsu.co.jp/magazine/ai/ax-promotion/)で扱っています。

まずは、任せる工程を1つ決め、その確かめ方を紙1枚に書くところから始めてみてください。どの工程から任せるか、レビューの型をどう置くかに迷う場面が出てきたら、waltsu が業務の棚卸しから確認工程の設計までご支援します。

## よくある質問

**Q. バイブコーディングとの違いは？**  
A. バイブコーディングは、細かい仕様を決めずに勢いで作らせ、動くものを早く見る探索的なやり方です。AI駆動開発は、その探索と、仕様を固めて収束させる工程の両方を含む進め方全体を指します。

**Q. 仕様駆動開発とは何が違う？**  
A. 仕様駆動開発は、AI駆動開発の中の1つの型です。受け入れ基準まで含めた仕様を先に確定させ、人が承認してからAIに実装させます。曖昧なまま流れる失敗を防げます。

**Q. 非エンジニアでも始められる？**  
A. 試作までは可能です。画面のたたき台や社内向けの道具なら、専門知識が無くても形にできます。本番は別で、障害時に誰が直すか、権限をどこまで絞るかの設計が必要です。

**Q. どのツールから始めるべき？**  
A. 製品名から選ばず、任せる工程から選びます。実装なのか、テストなのか、レビューの下支えなのかで適した種類が変わります。開発環境の具体例はOrcaの開発環境で紹介しました。

**Q. エンジニアの仕事はなくなる？**  
A. なくなりません。評価される対象が移ります。書いた量ではなく、決めた内容の的確さと、確かめた精度です。

## 執筆者

**藤井 俊輔**（代表取締役）ベンチャー企業の外部CMOや水族館のマーケティング担当などに従事。オンライン/オフライン問わず集客を中心としたマーケティング施策に強み。

プロフィール: https://www.waltsu.co.jp/magazine/supervisor/shunsuke-fujii/

この記事は waltsu 公式ブログの記事（https://www.waltsu.co.jp/blog/ai-driven-development/）をもとに再編集したものです。