「AIで書けるなら、もっと安く・速くできるはずですよね?」——2026年に入ってから、受託システム開発の見積りを提示すると、発注側からこう問われる機会がはっきり増えました。生成AIによるコーディングが日常になったのだから、人月もコストも下がって当然だ、という感覚です。気持ちは分かります。実装の一部はたしかに速くなりました。
ですが、私たちが実際に受託の現場で経験しているのは、それとは少し違う変化です。コードを「書く」時間は減った一方で、AIが書いたコードを「読んで、直して、本番に出してよいか見極める」時間がはっきり増えた。総量で見ると、必ずしも安くも速くもなっていない案件が少なくありません。本記事では、この実感が単なる気のせいではないことを公開データで確認しつつ、AI以後の受託開発で見積り・品質保証・発注側との関係がどう変わるのかを、受託を請け負う立場から整理します。
「速くなった」という感覚と、計測結果のズレ
まず押さえておきたいのは、AIで速くなったという感覚が、必ずしも実測の生産性と一致しないことです。
非営利の研究組織 METR が2025年に行ったランダム化比較試験は、この点を冷静に突きつけます。自分が5年以上関わってきた成熟したオープンソースリポジトリで、経験豊富な開発者16人が246のタスクをこなした実験です。開発者たちは「AIを使えば24%速くなる」と予測していました。ところが結果は逆で、AIを許可した条件では、むしろ完了までに19%長くかかった。しかも作業後の自己評価では「20%速くなった」と感じていた、という体感と実測のねじれまで観測されています。
この結果を「AIは使えない」と読むのは早計です。簡単で定義の明確なタスク（たとえばゼロから小さなHTTPサーバを書く）では、別の調査でAI支援が55%速いという数字も出ています。重要なのは、速くなる仕事と、かえって遅くなる仕事がはっきり分かれることです。仕様が固まったゼロイチの実装は速い。一方、既存の文脈が複雑で、暗黙のルールや過去の経緯を踏まえないと壊してしまう改修——つまり受託で最も多い「他人が作ったシステムに手を入れる」仕事ほど、AIの提案を一つずつ検証する手間がかさみ、素朴な期待ほどは速くなりません。
受託開発の主戦場は、まさに後者です。AIが当たり前になっても受託の難所が消えないのは、難所がコードを書く速さではなく、既存システムの文脈を正しく読むことにあるからです。この構図は、レガシー移行をAI支援で進める難しさを整理したAI支援によるレガシー移行の記事でも繰り返し現れます。
重心は「書く」から「評価する」へ移った
では、AI以後の受託開発で、工数の重心はどこへ移ったのか。端的に言えば、コードを生み出す工程から、生み出されたコードを評価する工程へ移りました。
業界全体で、いまやコミットされるコードの約4割がAIによって生成されるという調査があります。生成量が増えれば、そのぶん「これは本番に出してよいか」を判断する負荷も増えます。実際、2026年の品質保証の動向をまとめた調査では、67%の開発者がAI導入後にデバッグへ費やす時間が増えたと回答し、生産性向上分が保守負担に食われている実態が報告されています。AIが書くコードのかなりの割合は、何らかの介入なしには本番に出せない、ということです。
この変化は、コードの「質」を測る別の指標でも裏づけられます。GitClear が2020〜2024年の2億行超の変更を分析したところ、書いてすぐ捨て・直しになるコード（チャーン）は3.1%から5.7%へ、コードの重複は8.3%から12.3%へ増えました。重複が増えると、一か所の修正が思わぬ別の場所に波及しやすくなります。この「似て見えるコードを安易にまとめた結果、触ると壊れる」構造そのものについては、共通化しすぎたコードを重複へ戻す記事で詳しく扱いました。AIは、放っておくとこの種の負債を高速に積み上げます。
つまり、受託で求められるスキルの希少性が入れ替わりました。「コードを書ける人」より、「このコードを本番に出してよいかを評価できる人」のほうが、いまは貴重です。受託の付加価値も、そこへ寄っていきます。
見積りの根拠が説明しづらくなった理由
この重心の移動は、見積りの説明をやりにくくします。発注側の頭の中では「AI=実装が速い=安い」という素朴な式が成り立っているのに、私たちが計上するのは実装よりレビュー・検証・修正の工数だからです。「書く時間が減ったのに、なぜ総額が下がらないのか」という質問は、ここから生まれます。
加えて、AIを組み込む案件そのものに、従来開発にはない不確実性が乗ります。AI開発の費用を解説する2026年版のガイドでも指摘されるとおり、AIを使う機能は「作ってみないと、どの精度が出るか分からない」ため、PoC（検証）工程やトライ&エラーのリスク分を上乗せせざるを得ません。同じ業務でも会社によって2〜10倍の価格差が生まれるのは、この不確実性をどう見積りに織り込むかが各社で大きく異なるからです。
| 工程 | AI以前の受託の重み | AI以後の受託の重み |
|---|---|---|
| 要件の言語化・文脈把握 | 中 | 高（AIに正しく指示する前提） |
| 実装（コードを書く） | 高 | 低〜中（部分的に高速化） |
| レビュー・検証・修正 | 中 | 高（生成コードの評価が中心） |
| テスト・品質保証 | 中 | 高（AI生成分の確からしさ担保） |
人月という単位の意味も、静かに変わりました。かつて人月は「一人が一か月でこなせる実装量」の代理指標でした。実装がAIで部分的に肩代わりされるいま、受託で売っているのは実装量そのものより、文脈を読み、AIの出力を評価し、責任を持って本番に出す判断です。だから「実装が速くなったぶん人月を削れ」という交渉は、実は提供価値の中身とずれています。見積りの根拠が説明しづらくなったのは、単位の意味が変わったのに、言葉が追いついていないからです。
弊社の事例: 「AIで作った試作」を引き継いだとき
具体例を一つ挙げます。ある中堅のサービス事業者（社名は伏せます）から、社内の担当者が生成AIで作った在庫管理ツールの試作を、本番運用に耐える形へ仕上げてほしい、という相談を受けました。担当者いわく「8割はAIが書いてくれた。残り2割を整えるだけのはず」。見積り前提も、その「2割」でした。
ところが実際にコードを読むと、画面ごとに同じ在庫計算ロジックが少しずつ違う形で重複し、入力チェックが抜けている箇所が散在し、エラー時にデータがどうなるかが定義されていませんでした。動くデモにはなっていても、複数人が同時に在庫を更新したときの整合性や、通信が途中で切れたときの扱いといった「業務で必ず起きる状況」が考慮されていない。AIは「それらしく動くもの」を速やかに生んでいましたが、誰も本番に出してよいかを評価していなかったのです。
私たちが実際にやったのは、新しく華やかな機能を足すことではありませんでした。重複した在庫ロジックを一つの信頼できる土台へ寄せ直し、入力と境界条件の検証を全面的に入れ、同時更新とエラー時の振る舞いを定義する。要するに、AIが省略した「評価と責任」の工程を、後から人手で埋め直したわけです。担当者が見積もっていた「2割」は、実際には案件全体の大半を占めました。どこに業務知識を置くべきかという観点は、ドメイン知識の置き場所をリファクタリングで整理する記事で扱った考え方と、まさに同じ判断軸でした。
この案件が教えてくれたのは、AIで「動くもの」を作る難易度は確かに下がった一方で、「本番で壊れないものにする」難易度は下がっていない、ということです。むしろ、それらしく動く試作が増えたぶん、「動く」と「出せる」の落差を埋める仕事が、受託に集中するようになりました。
AI以後、発注側と受託側が握っておくべきこと
ここまでを踏まえると、AI時代の発注で損をしないために、発注側と受託側が最初に握っておくべき点が見えてきます。
第一に、「実装が速い」と「総額が安い」を切り離して考えること。AIで速くなるのは主に実装で、受託の費用はレビュー・検証・品質保証へ移っています。見積りを比較するときは、コード生成の速さではなく、「誰がどう品質を担保するのか」を尋ねるほうが、本質を突けます。
第二に、AIで作った試作の引き継ぎは、ゼロからの開発と同等以上に見積もること。先の事例のとおり、試作が8割できていることと、本番に出せることの間には、大きな隔たりがあります。「ほぼできている」という前提で発注すると、後から評価・修正の工数が膨らみます。
第三に、AIを使うこと自体を成果物の品質保証とみなさないこと。重要なのはAIを使うかどうかではなく、生成されたコードを誰がどんな基準でレビューし、テストで担保しているかです。受託側に「AI生成分をどう検証しているか」を説明できる体制があるかは、発注時の有力な判断材料になります。
AIで作った試作をどう本番化すればよいか分からない、AIを使った見積りの妥当性を判断したい、生成されたコードの品質を第三者の目で確かめたい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行のコードや試作を拝見し、どこまでがそのまま使えて、どこに評価と作り直しの工数が必要かを率直にお見立てしたうえで、本番運用に耐える形へ段階的に仕上げる設計をご一緒に組みます。
