マワルくん
・AI駆動開発が何を指す言葉なのか、一言で説明できるようにしたい
・開発の工程がどう変わり、人がどこに残るのかを知りたい
・自社の開発に何から取り入れるか、最初の1つを決めたい
コード生成ツールを入れた会社は増えました。ところが納期を聞くと、以前と変わらないという話も同じくらい聞きます。書く速度は上がったのに、完成までの時間が縮まらない。この食い違いを説明する言葉が、AI駆動開発（AIDD）です。
AI駆動開発とは、AIを補助ツールではなく、開発プロセスの前提に据える進め方です。実装だけでなく、要件定義から保守までの全工程を対象にします。速くなるのは作る工程だけで、決める工程と確かめる工程はむしろ増えます。本記事で整理するのは、従来の開発との違い、工程別の変化、人の役割、失敗の型、始め方、経営が見るべき指標です。
この記事を監修した人
AIエンジニア
小洞 映ハユル コボラ
この記事のゴール（読了目安 約10分）
速くなる工程と速くならない工程を分けて説明でき、自社で最初に任せる工程を1つ決め、その確かめ方を先に用意できるようになる。
AI駆動開発とは
AI駆動開発の定義
AI駆動開発とは、AIを補助的な道具ではなく、開発プロセスの前提に据える進め方です。頭文字からAIDDとも呼ばれます。要件定義から保守までの工程について、どこにAIを置き、どこに人を残すかを設計し直すところまで含みます。変えるのはツールではなく、工程と役割の配置です。
「AIを使う開発」との違い
個々の開発者が手元でAIに補完させるのは、AI支援の開発です。成果物の作り方もレビューの型も従来のままで成立します。AI駆動開発は、AIが最初の成果物を出す前提で、誰が何を決め、どこで確かめるかまで組み替えます。境目は、AIを使っているかではなく工程を組み替えたかです。
なぜ今注目されているのか
背景は3つあります。
- エージェントの実用化: 複数ファイルにまたがる変更まで任せられる道具が実務に入った
- 利用が既定になった: GitHub の Octoverse 2025 では、GitHub に新しく参加した開発者のほぼ80%が最初の1週間のうちに GitHub Copilot を使っているとされる
- 国内の人材制約: IPA（情報処理推進機構）も「AIを用いたソフトウェア開発」を課題として調査の対象に置いている
道具が揃ったから注目されたのではなく、使う前提が先に固まりました。
従来の開発との違い
違いは、誰が最初の成果物を出すかにあります。従来は人が書き、AIが横で助けました。AI駆動開発ではAIが最初の案を出し、人は採るか捨てるかを決めます。「人が作り、AIが助ける」から「AIが作り、人が決める」への反転です。
要件定義と設計はどう変わるか
要件定義：曖昧さが命取りになる
曖昧な仕様は、人に渡せば質問になって戻ってきますが、AIに渡すと戻ってきません。足りない前提を勝手に補い、それらしい成果物が出てきます。決めていなかったことに気づくのが遅れます。
waltsu の制作案件の見積もりでも、日程を縮めるのは手を動かす人数ではなく、要件・素材・承認者・更新ルールが先に決まっているかどうかでした。要件が具体的に整理されていた案件は、通常より短い期間で見積もれると判断しています。決まっていない部分は、AIに渡しても決まりません。
設計：AIに渡す前提を作る
AIの出力の質は、渡した前提の質で決まります。境界、命名、使ってよい依存、やらないことを、人がテキストで先に置きます。仕様を確定させてから渡す進め方が、仕様駆動開発です。設計はAIに任せる作業ではなく、AIに渡すために言語化する作業になります。詳しくはAI時代に効く設計スキルで解説しています。
実装とレビューはどう変わるか
実装：書く人から指示する人へ
コードを書く時間が減るのは確かです。ただし減るのは打鍵の時間で、判断の時間ではありません。仕事は、何を作らせるかを言葉にし、出てきたものを採るか捨てるかを決めることに移ります。指示の粒度が、そのまま成果物の粒度になります。どこまで任せるかは自律型AIエージェントの記事で整理済みです。
レビュー：量が一気に増える
作る速度が上がると、確かめる対象が同じだけ増えます。Apiiro の調査では、AIを使う開発者のコミット数は、そうでない開発者の3〜4倍になっています。一方でプルリクエストの本数は3分の1近く減っており、1回のレビューで見る差分は以前より大きくなりました。件数が増えるのではなく、1件が大きくなります。
テストと保守はどう変わるか
テスト：網羅より意図の確認
テストケースの生成はAIが得意で、境界値も異常系も人より早く並びます。AIが決められないのは、何を守りたいのかという受け入れ基準です。書かれた条件は再現できても、書かれていない前提は再現できません。人が確認するのは網羅性ではなく、守りたいものが守られているかです。
保守：説明できるコードを残す
AIは実装と同時に説明文も出せるので、ドキュメント不足は減ります。減らないのは、なぜその作りを選んだかという判断の記録です。選ばなかった案、諦めた条件、当時の制約は生成物に残りません。半年後に役立つのは、動くコードではなく直す理由を説明できる記録です。
速くなる工程とならない工程
工程が一律に速くなると考えると、判断を誤ります。効果は、速くなった工程ではなく、増えた工程を吸収できたかで決まります。
速くなる2工程で得た時間の行き先は、増える2工程です。
人の役割はどこへ移るか
決める人になる
AIが案を出せるようになったぶん、選ぶ回数が増えます。何を作るか、どこまで作らないか、複数案のどれを採るか。捨てる判断が、人にしかできない仕事になりました。作らない範囲を決めないと、選択肢の管理が仕事になります。
確かめる人になる
もう1つは、確かめる役割です。受け入れ基準、権限の境界、外部との接続点。ここは動作確認では確かめられません。作業は移りますが、責任は移りません。発注する側も同じで、誰が仕様を決めるか、誰がレビューを持つか、保守を引き継げるかを確認します。
うまくいかない3つの型
現場で起きる失敗は3つです。手当てする場所がそれぞれ違います。
レビューが追いつかない
作る速度だけを上げると、確かめる工程で滞留します。生成は1日で終わり、レビュー待ちが2週間並ぶ。ボトルネックは消えたのではなく、下流へ移動しただけです。納期が変わらない現場の多くは、この形をしています。
仕様が曖昧なまま流れる
決まっていないことが、決まったものとして実装されます。AIは質問を返さないので、曖昧さは指摘されないまま成果物へ変換されます。戻りは実装中ではなく、受け入れの段階でまとめて出ます。
誰も読めないコードが増える
動くけれど、なぜその作りなのかを誰も説明できない。動作確認では見つかりません。
表示が遅いという相談で既存サイトを診断したときも、原因は画面を出す前に全データを生成する作りでした。エラーは出ず、表示も正しい。動くかどうかでは気づけず、なぜその作りにしたのかの記録も残っていませんでした。
AI駆動開発の始め方
任せる工程を1つ決める
全工程に一度に入れると、どこで効果が出たのか分かりません。最初は構成案、下書き、テストケースのような中間成果物から任せます。捨てても損失が小さいものが、最初に任せる対象に向いています。
前提をテキストで置く
制約、命名、使ってよい依存、やらないこと。これを人が書いて、毎回同じものを渡します。ここを自動化すると、AIが自分の前提を自分で決めることになります。
レビューの型を先に作る
生成を始める前に決めるのは、見る場所と見ない場所です。紙1枚に3つ書けば足ります。
- 必ず人が見る: 権限、外部連携、個人情報を扱う箇所
- 機械に見せる: 書式、命名、既存テストの通過
- 見ない: 生成物の書き方の好み
範囲を広げる順番を決める
広げる順番は、影響範囲が小さく戻せるものからです。社内向けから社外向けへ、参照だけの機能から更新を伴う機能へ。戻せない範囲から始めると、1回の失敗で全体が止まります。
品質をどう担保するか
人が必ず見る場所を決める
全部を人が見るのは量の面で続きません。決めるのは見る場所です。次の3つは、動いてしまうと問題が表に出ません。
- 権限: 想定より広い権限を要求していないか
- 外部連携: どのサービスと、どのデータをやり取りするか
- 個人情報: どこに保存し、誰が参照できるか
危ないのは動かないコードではなく、想定より広く動くコードです。任せるときのリスクはAIエージェントのセキュリティで整理しています。
自動で止める仕組みを置く
人が見ない部分は、機械で止めます。既存テストの通過、検証環境での確認、1回の変更の大きさの上限。安心して捨てられる範囲を先に作ると、任せられる範囲が広がります。
経営が見るべき指標
行数や速度を成果にしない
生成した行数、コミットの本数、体感の速さ。どれも増やそうと思えば増やせるので、指標には向きません。生成量は成果ではなく、確かめる仕事の量です。
4つの指標で対にして見る
見るのは、リードタイム、デプロイ頻度、変更失敗率、復旧時間の4つです。前2つは速さ、後ろ2つは安定性を示します。DORA が2025年に公開した調査では、世界のIT専門家およそ5,000人を対象に、AIの活用がスループットと製品パフォーマンスには正の関係、デリバリの安定性とは負の関係を示したとの報告です。速さと安定性は、必ず対で見ます。
【プロの視点】欠陥は設計側に出る
一般的な解説は、AIが書いたコードは必ずレビューしましょう、で終わります。更新されていないのは、そのレビューが何を見つけるためのものかです。
見るべきは、コードが動くかどうかではなく、どこに境界と権限の線を引いたかです。
セキュリティ企業の Apiiro は、AIが関与したコードの解析として、構文エラーが76%、ロジックの誤りが60%減った一方、権限昇格につながる経路が322%、アーキテクチャ設計の欠陥が153%増えたとしています。比較対象はAIを使わない開発者です。細かい間違いは減り、設計レベルの間違いは増えます。
にもかかわらず、現場のレビューは行を追う形のままです。誤字、命名の揺れ、書式は、AIが得意な領域です。人が重ねて見ても新しい発見は多くありません。AIが減らした欠陥を人が探し、増やした欠陥を誰も見ていないという配置になります。
判定基準を置き換えます。この変更はどこまでの権限を要求しているか。外部との接続点は増えていないか。読む場所を変えるだけで、同じ時間のレビューで別の問題が見つかります。
【waltsu視点】速さより確かめる力
waltsu の編集軸は、価値は時短ではなく試行回数にある、というものです。AI駆動開発では、試行回数を決めるのは作る速度ではなく、確かめて捨てる速度になります。
作る速度が10倍になっても、確かめる速度が変わらなければ、試せる回数は変わりません。増えるのは、確かめられていない成果物です。
DORA の2025年の報告は、AIについて、チームを直すのではなくそこにあるものを増幅すると表現しています。強いチームはより強くなり、弱さのあるチームは弱さが拡大されます。確かめる仕組みが無い組織がAIを入れると、増えるのは試行ではなく手戻りです。
だから最初の投資先は、生成ツールではありません。テスト、検証環境、レビューの型。安心して捨てられる範囲の広さが、そのまま試行回数の上限になります。
明日やる一歩は1つです。任せる工程を1つ選び、その工程の確かめ方を紙1枚に書いてください。何を見るか、誰が見るか、何をもって合格とするか。この3行が決まれば、その工程は今日から任せられます。
よくある質問
バイブコーディングとの違いは？
バイブコーディングは、細かい仕様を決めずに勢いで作らせ、動くものを早く見る探索的なやり方です。AI駆動開発は、その探索と、仕様を固めて収束させる工程の両方を含む進め方全体を指します。
仕様駆動開発とは何が違う？
仕様駆動開発は、AI駆動開発の中の1つの型です。受け入れ基準まで含めた仕様を先に確定させ、人が承認してからAIに実装させます。曖昧なまま流れる失敗を防げます。
非エンジニアでも始められる？
試作までは可能です。画面のたたき台や社内向けの道具なら、専門知識が無くても形にできます。本番は別で、障害時に誰が直すか、権限をどこまで絞るかの設計が必要です。
どのツールから始めるべき？
製品名から選ばず、任せる工程から選びます。実装なのか、テストなのか、レビューの下支えなのかで適した種類が変わります。開発環境の具体例はOrcaの開発環境で紹介しました。
エンジニアの仕事はなくなる？
なくなりません。評価される対象が移ります。書いた量ではなく、決めた内容の的確さと、確かめた精度です。
この記事の要点
・AI駆動開発は、AIを開発プロセスの前提に据えて工程と役割を組み替える進め方
・速くなるのは実装とテスト。要件定義と設計は変わらず、レビューと保守はむしろ増える
・人の役割は「書く」から「決める・確かめる」へ移る。作業は移るが責任は移らない
・始め方は、任せる工程を1つ決め、その確かめ方を先に紙1枚で決めるところから
まとめ
AI駆動開発とは、AIを開発プロセスの前提に据え、工程と役割を組み替える進め方です。速くなるのは実装とテスト、ほぼ変わらないのが要件定義と設計、むしろ増えるのがレビューと保守です。
人の役割は、書く人から決める人・確かめる人へ移ります。移るのは作業であって責任ではありません。だから最初に用意するのは生成ツールではなく、確かめる型と、安心して捨てられる範囲です。全社の進め方はAX推進で扱っています。
まずは、任せる工程を1つ決め、その確かめ方を紙1枚に書くところから始めてみてください。どの工程から任せるか、レビューの型をどう置くかに迷う場面が出てきたら、waltsu が業務の棚卸しから確認工程の設計までご支援します。
