AI 駆動開発の話をするとき、受託開発では手応えが出にくいと感じる場面があります。もちろん受託開発にもさまざまな形があり、一律には言えません。それでも差が出やすいのは、AI がコードを書く場面より、その変更を誰が判断し、どう検証し、どの条件で本番に載せるかという場面です。

AI で実装の初速は上げられても、受託開発ではその先に契約、承認、検収、責任分界があります。そこで流れが止まれば、開発者だけが速くなっても仕事全体はあまり速くなりません。この記事では、DORA の State of AI-assisted Software Development 2025、Microsoft Research の The Impact of AI on Developer Productivity、GitHub の Does GitHub Copilot improve code quality? Here’s what the data says を踏まえつつ、なぜ受託開発で AI 駆動開発が進みにくく見えやすいのかを整理します。

AI は個人の実装を速くする

まず、個人の実装タスクが速くなること自体はかなり強く示されています。Microsoft Research の実験では、GitHub Copilot を使った参加者は JavaScript の HTTP サーバー実装タスクを 55.8% 速く終えました。GitHub が公開した調査でも、Copilot を使った開発者は、すべての単体テストを通す可能性が 53.2% 高く、レビューで承認される可能性も 5% 高かったと報告されています。

ここから言えるのは、AI がコードを書く、たたき台を作る、テストを書く、既存コードを読む、といった個人作業を前に進める力を持っていることです。ただし、これらは特定の課題で観測された効果であり、そのままプロジェクト全体の速度を表すわけではありません。ソフトウェア開発には、何を作るかを決めること、できたものを受け入れること、変更を扱うこと、運用に載せることが含まれます。AI が速くするのはその一部です。

DORA が見ているのは AI の導入効果だけではなく組織の受け止め方

DORA の 2025 年レポートで重要なのは、AI を「増幅器」として捉えている点です。AI は、組織の既存の強みと弱みを拡大します。優先順位づけ、ユーザー中心性、レビューの仕組み、データの整備、品質確認の流れが強い組織では、その強みがより速く回ります。逆に、曖昧な仕様、弱い検証、断絶した情報共有、遅い意思決定がある組織では、その弱さも速く増幅されます。

さらに DORA の関連解説では、AI 活用の拡大はソフトウェア開発の流れを速くすることと結びつく一方で、リリースや変更の不安定さの増加とも結びつくと整理されています。つまり、AI を入れるだけで全体がよくなるわけではありません。速くなった変更を安全に扱える仕組みがあるかどうかが重要です。この見方に立つと、受託開発で詰まりやすい理由も見えやすくなります。

比較すると自社プロダクト開発は進めやすく見えやすい

比較対象として自社プロダクト開発を見ると、AI 駆動開発を進めやすく見える理由もはっきりします。作る人、決める人、運用する人、使われ方を観測する人の距離が近いからです。もちろん例外はありますが、プロダクトオーナー、開発者、デザイナー、サポート、営業、運用担当などが同じ事業の成果に向かっていると、AI で作った実装や修正を見ながら、「この変更は入れる」「この仕様は変える」「この影響範囲なら次のリリースに載せられる」といった判断を返しやすくなります。

実装を楽にすることと、良いプロダクトを継続的に出せることは別です。AI は実装、修正、テスト、調査を速くしますが、その価値が大きくなるのは、作ったあとに確認し、影響を見積もり、優先順位やリリース判断を更新できるときです。自社プロダクト開発では、この流れを同じ運営サイクルの中に置きやすいので、AI の効果が組織全体の速度に変わりやすくなります。

受託開発で詰まりやすいのは実装ではなく合意である

ここでいう受託開発は、すべての受託案件を指しているわけではありません。顧客と同じチームのように進める案件もありますし、契約や承認の重さも案件によってかなり違うと思います。

一方で、最初に決めた範囲と検収を前提にした受託案件では、AI が速くする部分と、仕事全体を進めるために必要な部分が分かれやすいです。ベンダー側が実装、修正、調査、テスト作成を前倒しできても、顧客側の判断、契約範囲の確認、受け入れ条件の調整、説明責任の整理は別の流れで進みます。

たとえば、既存システムの法令対応、計算ロジックの変更、連携先システムの仕様変更、性能改善のような仕事では、試作品を見せて反応を見ることが中心ではありません。重要なのは、変更内容が業務ルールに合っているか、既存処理を壊していないか、証跡を残せるか、承認を経て安全にリリースできるかです。AI は調査や実装やテスト作成を速くできますが、受託案件では、その結果をその場で採用できるとは限りません。「これは当初の範囲に含まれるのか」「追加費用が要るのか」「納期はどうするのか」「誰が最終判断者なのか」がすぐに問題になります。

ここで詰まるのは、AI がコードを書けないからではありません。むしろ AI によって、以前なら後工程まで見えなかったズレが早い段階で見えるようになっただけとも言えます。すると、ボトルネックは実装能力より、変更をどう扱うかという合意と運用の方に移ります。

問題は受託そのものではなく判断の距離である

ここで注意したいのは、受託開発には AI 駆動開発を適用できないと言いたいわけではないことです。受託でも、顧客側に判断者がいて、確認、承認、リリース判断までの流れが短ければ、AI の恩恵はかなり受けられます。逆に、自社プロダクト開発でも、意思決定者が遠く、リリース判断が重く、利用データが見えず、責任分界だけが強いなら、AI はうまく回りません。

つまり、差を作っているのは「受託か自社か」そのものではなく、AI が速くした実装をどれだけ速く判断と検証につなげられるかです。受託開発が不利になりやすいのは、最初に決めた範囲、変更管理、検収、階層的な情報伝達が入りやすいからであって、外部委託という契約形態そのものが本質ではないと考えています。

多重下請け構造がある案件では、この問題はさらに大きくなります。発注者、元請け、下請けと層が増えるほど、実装者に届く文脈は薄くなりやすく、疑問が判断者に届くまでの時間も延びます。AI は不足した文脈を自動で補ってくれるわけではないので、必要な文脈が欠けたまま速く進めると、速く間違うだけになりやすいです。

加えて、実装者や判断者の側に技術的な理解が不足していると、この問題はさらに厳しくなります。AI が出した実装案やテスト案がもっともらしく見えても、その妥当性や影響範囲を見極められなければ、どこを確認すべきか、どこからが仕様変更なのか、どのリスクを先に潰すべきかが判断しにくくなります。AI は知識の入口を下げますが、最終的な技術判断まで代わりに引き受けてくれるわけではありません。受託開発ではもともと文脈が分散しやすいため、技術理解の不足は実装ミスだけでなく、合意形成そのものの遅れにもつながります。

受託開発で AI を活かすなら、変えるべきは実装速度だけではない

受託開発で AI を活かしたいなら、ベンダーだけが速くなる形では足りません。顧客と一緒に速く決める形に変える必要があります。ポイントは、AI で早く見えるようになったズレを、早く扱えるようにすることです。

そのためには、顧客側の業務判断者と受け入れ責任者を早い段階から巻き込み、変更内容、影響範囲、テスト結果、リリース可否を短い間隔で確認できるようにする必要があります。すべてを重い変更申請で処理するのではなく、軽微な調整と正式な契約変更を分けて扱う設計も有効です。金融や基幹系のように統制が強い領域では、試作品を早く見せることよりも、変更理由、影響調査、テスト証跡、承認記録を速くそろえられることの方が重要になる場合があります。

言い換えると、AI 駆動開発を受託で成立させるには、「コード生成を導入する」だけではなく、「合意形成の単位を小さくする」「判断者を近づける」「受け入れ条件を更新しやすくする」といった運用設計まで必要になります。

まとめ

受託開発で AI 駆動開発が進みにくく見えやすいのは、AI が実装を速くしても、その先の合意形成、変更管理、受け入れ判断が別の流れで動きやすいからです。AI が得意なのは、まず作ることです。受託開発で難しいのは、その変更を誰がどう引き取るかを決めることです。

比較すると、自社プロダクト開発はその判断の距離を短くしやすいぶん、AI の効果が全体速度に変わりやすく見えます。ただし、本質は契約形態ではありません。AI を活かせるかどうかは、コード生成の巧拙より、その速さを受け止める合意と検証の設計にかかっているのだと思います。

参考

DORA, State of AI-assisted Software Development 2025
DORA, Balancing AI tensions: Moving from AI adoption to effective SDLC use
DORA, Capabilities: Streamlining change approval
Microsoft Research, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
GitHub Blog, Does GitHub Copilot improve code quality? Here’s what the data says