AI駆動開発で発注側の費用と期間はどう変わるか
AI駆動開発は、コードの生成、テストの作成、設計書や議事録の下書きなどに生成AIを組み込んで進めるシステム開発の進め方です。コーディング支援ツールやAIエージェントが広く使われるようになり、開発会社の提案書にも「AIを活用して効率的に開発します」という一文が入ることが増えました。
発注する側として気になるのは、AI駆動開発なら費用は下がるのか、期間は短くなるのか、品質は大丈夫なのか、という点でしょう。システム開発にAIを活用すると、確かに速くなる作業があります。一方で、要件定義、レビュー、テスト、リリース後の責任の分け方のように、AIを使っても発注側と開発会社が担わなければならない部分は残ります。
公開されている調査を見ても、AIでどれだけ開発が速くなるかは、作業の種類や開発者の置かれた状況によって大きく異なります。「AIで工数が半分になる」といった一律の削減率を前提に予算や納期を決めると、見積もりの比較や進捗の評価を誤りやすくなります。
この記事では、AI駆動開発で費用・期間・品質・見積もりの出し方がどう変わり、何が変わらないのかを、発注側が判断に使える形で整理します。
AI駆動開発で変わる工程と変わらない工程
AI駆動開発といっても、すべての工程が同じように速くなるわけではありません。生成AIが力を発揮しやすいのは、何が正解かがはっきりしていて、出来上がったものを機械的に確かめられる作業です。逆に、何を作るべきかを決める作業や、複数の関係者の合意が必要な作業は、AIを使っても大きくは縮みません。
| 工程 | AIが効きやすい作業 | 人が担い続ける部分 |
|---|---|---|
| 要件定義 | 打ち合わせの要約、要件一覧の下書き、抜け漏れの指摘 | 何を作るかの決定、優先順位、業務ルールの確認 |
| 設計 | 画面案やデータ構造案のたたき台づくり | 既存システムとの整合、性能や権限などの非機能要件、採否の判断 |
| 実装 | 定型的な画面、API、データ変換処理のコード生成 | 生成されたコードの読解と修正、設計どおりかの確認 |
| テスト | テストコードやテストケース案の生成 | 何を確かめるべきかの決定、受入テスト、結果の判断 |
| 運用・保守 | ログの要約、障害原因の候補出し | 本番環境の操作、影響範囲の判断、利用者への対応 |
この表から分かるのは、案件全体に占める実装の割合が大きいほどAIの効果が出やすく、要件の調整や既存システムの調査が大半を占める案件ほど効果が出にくいということです。
公開された調査結果にも、この傾向が表れています。GitHubが2022年に公表した実験では、95人の開発者にJavaScriptでHTTPサーバーを書く課題を与え、GitHub Copilotを使ったグループは平均約1時間11分、使わなかったグループは約2時間41分で、使ったグループが55%速く終えたと報告されています。仕様が明確で、ゼロから書く小さな課題での結果です。
一方、AIの能力評価を行う非営利の研究機関METRが2025年7月に公表した研究では、経験豊富なオープンソース開発者16人が、自分が普段関わっているリポジトリの実際の課題246件に取り組んだところ、AIツールの使用を許可した課題の方が19%長くかかりました。開発者自身は事前に24%速くなると予想し、終了後も約20%速くなったと感じていたと報告されています。METRはこの結果を2025年初頭のツールと条件に限ったものとしており、のちに現在のツールの実態を必ずしも反映しない過去の結果だと位置づけています。
どちらか一方の数字だけを取り上げて「AIで55%速くなる」「AIはかえって遅い」と判断するのは適切ではありません。読み取るべきなのは、効果は課題の性質や既存コードの規模、開発者の慣れによって大きく振れ、体感と実測がずれることもある、という点です。
参考：Research: quantifying GitHub Copilot’s impact on developer productivity and happiness／GitHub
参考：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity／METR
費用はどう変わるか｜下がりやすい部分と下がりにくい部分
システム開発にAIを活用したときの費用への影響は、見積もりの内訳ごとに分けて考えると判断しやすくなります。
下がりやすいのは、次のような作業の費用です。
- 一覧・登録・編集といった定型的な画面や、APIの実装
- 画面のモックアップやプロトタイプの作成
- テストコードの作成や、既存コードの説明資料の作成
- データ形式の変換処理など、入出力がはっきりした処理
これに対して、次のような費用は下がりにくく、場合によっては増えます。
- 要件定義や仕様調整の打ち合わせ
- AIが生成したコードのレビュー（生成される量が増えるほど確認する量も増える）
- セキュリティの確認や性能の検証
- 既存システムの調査、データ移行の設計と検証
- 開発会社が支払うAIツールの利用料
どの程度費用に効くかは、案件の性質によって変わります。目安を表にまとめます。
| 案件の特徴 | 費用への効果 | 理由 |
|---|---|---|
| 新規の社内ツールや管理画面で、仕様がはっきりしている | 出やすい | 実装の比率が高く、生成したものを動かして確かめやすい |
| 要件がまだ固まっていない | 総額では出にくい | 調整の時間が大半を占める。ただし試作が安くなるので要件を早く固めやすい |
| 既存システムの改修やデータ移行が中心 | 出にくい | 既存の仕様の調査と影響範囲の確認に時間がかかる |
| 個人情報や金銭を扱い、高い品質が求められる | 出にくい | レビュー、テスト、記録を省けない |
もう一つ確認したいのが、契約の形と料金の決め方です。人月単価で費用を出す準委任契約では、作業が速くなれば請求額も減る形になりやすい一方、完成物に対して固定額を払う請負契約では、効率化の分がそのまま開発会社の利益になることもあります。どちらが良い悪いではなく、AI活用による効率化を見積もりにどう反映しているのかを、開発会社に尋ねてよい項目だと考えてください。
期間はどう変わるか｜発注側の確認が新しいボトルネックになる
AI駆動開発で短くなりやすいのは、最初に動くものが出てくるまでの期間です。画面の試作や機能の初版が早く出てくるため、発注側が実物を見て判断できるタイミングは前倒しになります。
ただし、プロジェクト全体の期間は、開発会社の作業時間だけで決まるわけではありません。次のような作業は、AIを使っても短くなりません。
- 発注側の社内での意思決定や決裁
- 試作を見たうえでの確認と、修正方針の回答
- 受入テストの実施と、本番データの準備
- 外部サービスや既存システムの担当者との調整
- 利用者への説明や、本番切り替えの段取り
開発会社の作業が速くなるほど、こうした発注側の作業の比重は相対的に大きくなります。試作が毎週出てくるのに確認の返事に2週間かかる、という状態では、AIで短縮した分はそのまま待ち時間に変わってしまいます。
開発会社から「AI活用で期間を短縮できます」と提案されたときは、スケジュールの中で発注側の確認や受入テストにどれだけの期間が置かれているかを見てください。発注側の作業が短く見積もられすぎている場合は、実際には守れない計画になっている可能性があります。
期間の短縮を実際に得るために、発注側で用意しておきたいのは次のようなものです。
- 仕様の判断ができる担当者と、その人が確認に使える時間
- 確認の回答期限を決めた定例の場
- 受入テストの担当者とテスト用データ
- 決裁が必要な事項の一覧と、決裁者のスケジュール
これらが揃っていれば、AIで早く出てくる試作を判断材料として使い、手戻りの少ない進め方ができます。
品質はどう変わるか｜レビュー・テスト・責任分界は残る
AIが生成するコードは、一見もっともらしく動くものの、細かい条件で誤っている、不要な外部ライブラリを持ち込む、権限チェックが抜けている、といった問題を含むことがあります。そのため、AI駆動開発で品質を保つには、生成されたものを確かめる仕組みがこれまで以上に重要になります。
Google Cloudが2025年9月に公表した「2025 DORA Report: State of AI-Assisted Software Development」では、世界の技術者約5,000人の回答のうち90%が仕事でAIを使っており、80%超が生産性が上がったと感じている一方、30%がAIの生成したコードをほとんど、あるいはまったく信頼していないと回答しています。また、AIの導入とソフトウェアの提供の安定性には、引き続き負の関係が見られるとしています。速く作れるようになっても、それだけでは安定した品質にはつながらないということです。
発注側として、開発会社に確認しておきたい点を表にまとめます。
| 確認する点 | 質問の例 |
|---|---|
| レビュー体制 | AIが生成したコードを、誰がどの基準で確認していますか |
| テストの自動化 | どの範囲を自動テストで確かめていますか。テストもAIが書く場合、何を確かめるかは誰が決めますか |
| セキュリティ | 認証や権限、入力値のチェックは、どの段階で確認していますか |
| データの扱い | 当社のソースコードやデータを、どのAIサービスに入力しますか。入力内容が学習に使われない設定になっていますか |
| 保守性 | 別の担当者が読めるように、設計の意図や仕様は文書で残りますか |
このうちデータの扱いは、契約や秘密保持の取り決めにも関わります。開発会社がどのAIツールを使い、自社の情報がどこに送られるのかを確認し、必要であれば利用できるツールや入力してよい情報の範囲を契約や覚書で決めておきます。
責任分界も変わりません。AIが書いたコードであっても、納品物の不具合への対応や、検収の基準は、これまでと同じく契約で決めた内容に従います。契約書にAIの生成物を特別扱いする条項がない限り、「AIが書いたので分からない」という説明は通りません。逆に言えば、発注側が受入テストで業務上の正しさを確かめる役割も、これまでどおり残ります。
参考：Announcing the 2025 DORA Report: State of AI-Assisted Software Development／Google Cloud
見積もりの出し方はどう変わるか｜比較するときの判断基準
AI活用を前提にした見積もりでは、「AI活用による削減」として一定の割合を差し引いた形や、従来より少ない人月で出された形を見かけるようになりました。こうした見積もりを比べるときは、金額の大小より、削減の根拠と作業範囲を確かめることが大切です。
判断の目安は次のとおりです。
| 見積もりの状態 | 受け止め方 |
|---|---|
| 削減が実装やテストコードなど特定の作業に限られ、レビューや確認の工数は据え置き、または増えている | 現実的な見積もりと考えやすい |
| 削減率の根拠を、同種の案件での自社の実績で説明できる | 信頼しやすい。どの案件の実績かを確認する |
| 全工程から一律に何割かを差し引いている | 根拠を尋ねる。要件定義や受入支援まで減っていないか確認する |
| 他社より大幅に安いが、レビュー、テスト、ドキュメントの記載がない | 範囲が違う可能性が高い。含まれる作業を揃えて比べ直す |
また、AIで試作が安く速く作れるようになったことは、発注の分け方を見直すきっかけにもなります。要件が固まっていない段階でいきなり総額を固めるより、要件整理と試作を先に短い期間で発注し、試作を見て仕様を固めてから本開発を見積もる方が、見積もりの精度は上がります。最初の段階を準委任、仕様が固まった後を請負にするなど、契約の形をフェーズごとに分ける方法もあります。
開発会社と話す際は、次の三つを聞くと、AI活用の中身が見えやすくなります。
- この案件のどの作業で、どんなAIツールを使う予定ですか
- その結果、どの工程の工数がどれくらい変わると見込んでいますか。根拠は何ですか
- AIが生成したものの確認は、誰がどのように行いますか
この三つに具体的に答えられる開発会社であれば、AIを使う範囲と人が責任を持つ範囲を区別して計画していると判断できます。答えが「全体的に効率化します」にとどまる場合は、見積もりの前提をもう一段詳しく確認した方が安全です。
まとめ
AI駆動開発では、定型的な実装、試作、テストコードの作成などが速くなり、その分の費用や期間が下がる可能性があります。ただし効果の大きさは、仕様の明確さ、既存システムの有無、求められる品質によって大きく変わり、公開された調査でも一律の削減率は示されていません。
要件定義、生成されたものの確認、受入テスト、契約に基づく責任の分け方は、AIを使っても残ります。むしろ開発会社の作業が速くなるほど、発注側の確認や意思決定の速さが全体の期間を左右するようになります。
見積もりを比べるときは、削減がどの作業に効いているのか、その根拠は実績に基づくのか、レビューとテストが含まれているのかを確かめてください。まずは今検討している案件について、どの工程が実装中心でどの工程が調整中心かを書き出し、開発会社にAIを使う範囲と確認の方法を尋ねるところから始めるとよいでしょう。