AIを使う開発会社の見積もり｜どこが減り、どこが減らないか

開発を工程で並べると、AIの効き方は同じではありません。見積書がこの単位で割られていれば、どこが減っているかを自分で確かめられます。

1社だけ極端に安いなら、その差がどの工程から来ているのかを聞いてください。工程で答えが返ってくれば、出どころまでは分かります。妥当かどうかは、同じ工程の人日を他社と並べて判断することになります。答えが返ってこないか、全体で何割という言い方しか出てこないなら、削っているのは工数ではなく工程そのものかもしれません。

実装が短くなれば全体も短くなる、とは限りません。ここを工程別に測った研究があります。カーネギーメロン大学とスタンフォード大学などの研究者が、1社の開発現場を追ったものです。次の表は、AIが書いたプルリクエストと人が書いたものを比べた差です。同じ会社の同じ時期のもので、作成者・月・変更量をそろえてあります。

調査の対象は開発者802名、プルリクエスト196,212件で、観測した期間は2024年1月から2026年4月までです。ただし上の区間別の数字は、そのうちマージされてレビューが付いたものだけを対象にしています。期間も、2025年6月の方針表明より後に絞ってあります。4つとも論文の表に載っている係数を百分率に直したもので、区間ごとに別々に推定しています。そのため、合計の約22%は前の3区間を足したものではありません。論文の図では待ち時間の側が約9%と表示されていて、表と図が揃っていない箇所もあります。論文はarXiv に2026年7月2日付で公開されています。方針を掲げた前後では、人がレビューしたプルリクエストの割合が89%から68%へ下がりました。代わりに、自動のAIレビューが付く割合が約19%から約84%へ増えています。論文は、レビュアー1人あたりの負担が約2倍になったとしています。ただし増えたのは無言の承認のほうで、コメントを書くレビューは中央値で月3件のまま横ばいだったとも書いています。

先に押さえておきたいのは、この論文が追った会社で、1人あたりのプルリクエスト件数そのものは2.09倍になっている点です。稼働している開発者1人あたりの月間件数が、方針表明前の21.2件から44.3件へ増えています。件数は増えましたが、1件が着手から取り込まれるまでにかかる時間は延びています。この研究が示しているのはそこです。

読み方には条件が付きます。1社のデータです。しかもその会社は、「1人あたりのマージ済みプルリクエスト数を倍にする」という目標を全社で掲げていました。無作為に割り付けた実験ではないので、論文はプルリクエスト単位の比較を相関であって因果ではないとしています。ただし、処理量が倍になったという中心の結果については、書き方が違います。因果関係とまでは言い切れないと断ったうえで、導入と利用の蓄積を強く示唆する証拠だとしています。効き方はコードの新しさでも割れていました。2022年以降に作られたものでは処理量が44%増えた一方、それより古いものでは12%で、統計的に有意ではありませんでした。

発注する側にとって意味があるのは、次の1点です。実装の工数が減ったという説明を受けたら、レビューの工数がどうなっているかを同じ見積書の中で確かめてください。実装だけ減ってレビューが据え置き、あるいは一緒に減っているなら、その根拠を聞く価値があります。

このとき、順番を待つ時間が伸びたことは根拠になりません。待ち時間は請求される工数ではないので、そこを持ち出すと話がかみ合いません。同じ論文で持ち出せるのは、レビュアー1人あたりの負担が約2倍になったところです。その会社ではプルリクエストの量が3.1倍に増えた一方で、レビュアーは1.5倍しか増えませんでした。ただし増えた分は無言の承認で、コメントを書くレビューは中央値で月3件のまま横ばいでした。量が増えれば見る側に積み上がる、という順序で聞くことになります。

レビューが増える分をどちらが負担するかは、それ自体が話し合う対象です。開発の進め方をAIに寄せると決めているのは開発会社の側です。そこで増えた社内のレビュー工数が、そのまま請求に乗るとは限りません。実装が減った分と、レビューが増えた分を差し引きしていくらになるのかを、工程別に出してもらってください。

見積書の書かれ方は3つあります。一式でまとめる形、工数と単価に分ける形、AI活用による削減を別行にする形です。どれで来たかによって、読み取れることも聞くべきことも変わります。これに、開発ツールの利用料が項目として立っているかどうかが加わります。

一式でまとめて書かれているとき

「システム開発一式」で1行、金額だけが書かれている形です。ここからは何も読み取れません。安いか高いかも判断できません。聞くのは金額の根拠ではなく、工程ごとの人日です。分けて出せない理由が説明されるなら、そこも判断の材料になります。

まだ範囲が固まっていないので分けられない、という答えなら、その通りのこともあります。その場合は、範囲を決めるところまでを別の見積もりにしてもらえます。ただしこれは有償の発注になることが多いので、先に2つ決めておくと後の選択肢が狭まりません。そこで作った資料を他社にもそのまま渡せる形で受け取れるかどうかと、本体を別の会社に発注した場合にその費用がどう扱われるかです。

工数と単価に分かれているとき

工程ごとに人日と単価が並んでいる形です。ここまで割れていれば、他社と比べられます。見るのは合計だけではありません。工程ごとの人日を、他社の同じ工程の人日と並べてください。比率だけで見ると、総額そのものが違うときに差の出どころが見えなくなります。実装の人日だけ他社より少なく、レビューとテストは変わらない、という並びになることがあります。この場合は、実装の見積もりに何かが乗っているか、他社が実装を多めに見ているかのどちらかです。どちらなのかは、聞かないと分かりません。

AI活用による削減が別の行になっているとき

工程ごとの人日を出したうえで、最後に「AI活用による効率化」としてまとめて何割か引いてある形です。これは、引いている根拠が読み取れないという意味では一式と同じです。聞くのは、その割合をどの工程に掛けたのかです。全工程に一律で掛けているなら、要件定義とテストと移行にも同じ割合が掛かっていることになります。

AIの機能そのものを作る案件では、従来のシステム開発には無い費目が並びます。このうち開発ツールの利用料だけは、AIの機能を作らない案件でも発生します。見積書に載っていなければ、後から請求される分だと考えて聞いておいてください。

合格ラインに届かなかったときの扱いは、後から争点になりやすいところです。作る前に精度を約束するのが技術的に難しい以上、届かなかったときにどうするかは、契約の形と一緒に決めておくことになります。

契約の形と精度の関係はAIエージェント開発の外注に、届かなかったときに何を変えるかはAI PoCの本番化にまとめています。

安い見積もりの中身を工程で割ると、削られやすい場所は決まっています。次の3つです。

• レビュー — 出てくる量が増えているのに、見る工数が据え置きか減っている
• テスト — 作る量に対して、確かめる工数の比率が他社より小さい
• 要件定義 — 打ち合わせの回数が少なく、範囲を決める前に金額が出ている

逆に、高いほうが正しいとも限りません。レビューとテストの人日だけが他社を大きく上回っている見積もりは、増えている理由を聞く対象です。AIを使うと書いてあるのに実装の人日が他社と変わらない場合も同じです。ただしレビューが厚いこと自体は、増える前提を金額に織り込んだ結果であることもあります。理由が説明されるかどうかで、削られている側と同じように判断が付きます。

レビューについては、外から見た数字もあります。Googleの研究プログラムDORAが、毎年の調査を公表しています。2025年版は「State of AI-assisted Software Development 2025」です。AIの利用が多いほど、本人の申告による処理量も多いという関係が見られたとしています。同時に、リリース後に不具合が出たり切り戻したりする度合いも高いとも書いています。前年の版では速さのほうも下がる向きだったので、ここは向きが変わりました。不具合のほうは、両方の版で同じです。

この調査は本人の申告に基づくアンケートで、実験ではありません。実査は2025年6月13日から7月21日、回答したのは技術職の約5,000名です。回答者の90%が業務でAIを使っています。一方で30%は、AIが生成したコードをあまり信頼していない、またはまったく信頼していないと答えています。DORAはこの2つを矛盾ではなく、使いながら確かめる成熟した姿勢だと読んでいます。裏を返せば、確かめる手間は人の工数として残るということです。見積書でレビューの工数が削られていたら、そこを聞いてください。あわせて、リリース後に見つかった不具合を誰が直し、その費用をどちらが負担するかも、契約の形と一緒に決めておいてください。

要件定義は、金額そのものが動く原因になります。範囲が決まる前に出た金額は、範囲が固まった時点で開発会社が出し直します。安い見積もりを選ぶことより、出し直しが起きたときの扱いを先に決めておくほうが、あとで効いてきます。決めるのは線引きです。範囲が増えたことによる差額と、範囲は変わらないまま人日の見立てが外れた分を分けます。それぞれどちらが持つのかを、金額が動く前に書き残しておいてください。

AIで何割速くなるか、という話は、調べると数字が大きく割れています。どれかが間違っているというより、測ったものが違います。

並べると、向きは1つに揃いません。ゼロから小さいものを書く課題では55.8%速くなりました。一方、すでにあるシステムに手を入れる作業では、結果が分かれます。全体で遅くなった研究と、書く工程だけ短くなって合計はむしろ長くなった研究が並びます。それでも、新規に作る案件と、既存のシステムに機能を足す案件で同じ削減率が提示されていたら、その根拠を聞く理由にはなります。

1つ補足があります。METRの19%という数字は2025年2月から6月に測ったものです。METRは2026年2月に、続きの実験の結果を書いています。当初から参加している開発者では18%速い、新しく募集した開発者では4%速いという推定でした。ただしどちらも、区間は遅くなるほうにかかっています。

METR自身は、この推定に偏りがあると述べています。AIなしで作業したくない人ほど、参加や提出を避けるためです。そのため、いまの効果を測る手がかりとしては信頼できないとしています。そのうえで、2026年初頭の開発者は2025年初頭の推定より速くなっている可能性が高い、という見方も示しています。根拠は参加者との会話です。測り直した数値ではなく、聞き取りに基づく見立てです。数字を引くときは、いつ測ったものかを添えてください。この分野は、測った時期が半年違うと前提が変わります。

見積書の外側で効いてくるのが、稼働してからの利用料です。ここを単価に件数を掛けて見積もると外れます。単価だけでなく、何を数えるかが変わるためです。次に挙げる3つのうち、稼働後の請求として自社に乗り続けるのは推論の利用料だけです。前の2つは開発側が使うツールなので、原価に含めるか別途請求かという別の話になります。それでも、数え方そのものが変わるという点は同じなので、ここに並べます。

• GitHub Copilot の数え方は、2026年6月1日に変わりました。プレミアムリクエスト（premium request units）の回数で数える方式から、トークン量に応じた GitHub AI Credits で数える方式へ移っています。座席の単価は据え置きですが、含まれる利用量がクレジットに置き換わっているので、同じ使い方でも足が出ることがあります。個人向けの年額プランは契約が切れるまで従来の方式に残るとされていて、切り替えは一律ではありません。法人向けは、既存の Business と Enterprise の契約に限って、2026年6月から8月の3か月だけ含まれるクレジットが増えています。この上乗せが続かなければ、9月分以降の請求は見え方が変わります。公開の時点ではまだその請求が出ていないので、実際の金額は管理画面で確かめてください
• Cursor の Teams プランは、座席が Standard と Premium の2種類に分かれています。Premium は Agent の上限が Standard の5倍で、2026年8月時点の公式の料金ページでは1人あたり月40ドルと120ドルです
• 主要な大規模言語モデルのAPIは、入力と出力で単価が分かれ、さらにキャッシュの扱いが別建てになっています。Gemini のAPIには、キャッシュしたトークンの保管料という項目もあります。100万トークンを1時間置くといくら、という数え方です。ここまでの3つは、各社の公式の料金ページで2026年8月に確認しました

見積書には、開発費とは別に、稼働後の月額として1年分を出してもらってください。件数の前提もあわせて書いてもらうと、実際の件数が想定と違ったときに、どこがずれたのかを確かめられます。

金額が2倍も3倍も違うとき、まず疑うのは、各社が違うものを見積もっている可能性です。前提を揃えて渡すと、比べられる形になります。渡すのは仕様書でなくて構いません。【対象の業務】【データ】【合格の考え方】【時期】は自社で埋める欄です。AIの機能そのものを作る案件でなければ、【データ】と【合格の考え方】は空欄で構いません。含めていただきたいものも、3から5と、8と9は飛ばして構いません。埋めたうえで1枚にまとめ、同じものを全社へ送って、この前提で出し直してもらってください。手元にある見積もりと比べるのは、出し直しが揃ってからです。

【対象の業務】
  いま誰が、何を、月に何件やっているか
  そのうちAIに任せたい範囲

【データ】
  元になるデータの種類と、おおよその件数
  形式（紙／PDF／表計算／既存システムの中）
  正解を付けられる人が社内にいるか

【合格の考え方】
  いま人がやったときに、後工程でどのくらい差し戻されているか
  どの水準なら実用に足りると考えているか

【見積もりに含めていただきたいもの】
  1. 工程ごとの人日と単価（要件定義／設計／実装／レビュー／
     テスト／データ移行／運用設計）
  2. AI活用による削減がある場合、どの工程に何%掛けたか
  3. 評価用データを誰が用意する前提か
  4. 試す回数の上限と、超えたときの扱い
  5. 合格ラインに届かなかった場合の進め方
  6. 稼働後の月額（1年分。推論の利用料と、前提となる件数もあわせて）
  7. 開発中に使うAIツールの利用料が原価に含まれるか
  8. 使っているモデルが入れ替わったときの測り直しが保守に含まれるか
  9. 稼働後の推論の利用料を誰の名義で契約するか、
     使用量の上限を誰が設定できるか
 10. 開発中にお渡しする資料やデータをAIに入れる場合、
     どのサービスの、法人と個人のどちらの契約で使うか
 11. 範囲が固まった時点で見積もりを出し直す場合、
     範囲が増えた分と、人日の見立てが外れた分の
     それぞれをどちらが負担するか
 12. リリース後に見つかった不具合を誰が直し、
     その費用をどちらが負担するか

【時期】
  いつまでに動かしたいか、その理由

10番は、開発中にこちらが渡す仕様書やサンプルデータの話です。開発会社がそれを自社のAIツールに入れて作業することがあります。同じサービスでも、法人の契約と個人の契約では、入れたものが学習に使われるかどうかの扱いが変わります。見積もりが安い理由がここにあることもあるので、金額の話と一緒に聞いておくほうが早いです。

範囲を決める工程そのものの進め方はシステム開発の要件定義の進め方に、立ち上げの段階ごとにいくら掛けるかはスタートアップの開発費用にまとめています。

• AIで短くなるのは実装が中心。要件定義・データ移行・運用設計は変わらず、テストは短くならず、レビューはむしろ増える
• 短くなった分が総額から引かれるとは限らない。カーネギーメロン大学とスタンフォード大学などが1社の802名・196,212件を追った研究では、1人あたりの処理量は2.09倍になった。ただしこの件数は、その会社が全社の目標に掲げた指標そのものでもある。一方で、1件が書き始めから取り込まれるまでにかかる時間は約22%長くなった
• 見積書は3つの書かれ方に分かれる。一式は読み取れない。削減率が別行なら、どの工程に掛けたかを聞く
• AIの案件にだけ出る費目は6つ。評価用データ、試す回数、届かなかったときの扱い、推論の利用料、開発ツールの利用料、モデル入れ替えへの追従
• 削られていて危ないのはレビューとテストと要件定義
• 研究の数字が割れるのは、測ったタスクも、測り方も、測った時期も違うため。ゼロから小さいものを書く課題では大きく速くなり、既存に手を入れる作業では結果が揃わない
• 稼働後の費用は、単価より数え方が変わる。上限を設定できるかで見る
• 相見積もりは前提を揃えて渡す。仕様書でなく1枚で足りる

当社は受託開発を行っていて、見積もりを出す側です。他社から受け取った見積もりを工程で読み直すところだけでも構いません。社名と金額を伏せた状態でも読み直せます。当社が同じ案件で見積もりを出す立場になりうるときは、お引き受けする前にその旨をお伝えします。前提を揃える1枚を作り、そのまま各社へ送れる状態にしてお返しすることもできます。必要でしたらお問い合わせからお声がけください。