はじめに
最近、発注側からこう聞かれることが増えました。「AIで作るなら、もっと安くなりますよね？」半分はその通りで、半分は違います。
実際に値引きを求められたときは、こう説明しました。
意思決定が不要なフェーズであれば、短縮可能です。しかし、何を目的として何を実現したいか、それはどういうものか（画面デザイン）、何が必要か（機能一覧）、どうなっていたら実現できたと言えるか（受入テスト）といった、人間の意思が必要な部分は短縮が難しいです。
本音を言えば、全部AIが出した案で良ければいくらでも短縮できます。ただし、それでダメだったとしても責任は取れません。
この記事では次の3つを扱います。
- 見積もりの「単位」がどう変わってきたか（コード行数→機能数→画面数・API数）
- AI（バイブコーディング）で何が縮み、何が縮まないか
- AI時代の見積もり書の考え方と、そのまま使えるテンプレート
想定読者は、受託開発のPM・営業・見積もり担当の方と、見積もりを受け取る発注側の担当の方です。
見積もり単位の変遷を振り返る
見積もりの単位は、その時代に「一番重い作業」を数えようとして変わってきました。大まかには次の流れです。
| 時期（目安） | 主な単位 | 数えていたもの | 前提 |
|---|---|---|---|
| 〜1980年代 | コード行数・ステップ数（KSLOC） | 書くコードの量 | 言語・開発方法がほぼ固定。実装が工数の中心 |
| 1980年代〜 | ファンクションポイント（FP） | 入力・出力・照会・ファイルなど機能の量 | 要件が決まれば機能を数えられる |
| 2000年代〜 | 画面数・帳票数・バッチ数 | 成果物の個数×難易度 | 業務システムは画面と帳票でできている |
| 2010年代〜 | API数・バックエンド構築・テスト件数 | エンドポイント、基盤、テストケース | Web・スマホ・クラウドで「画面の裏」が重くなった |
| 2025年〜 | ？ | ？ | AIがコードを書く |
FPは1979年、IBMのAllan Albrecht氏が「物理的な量ではなく機能で規模を測る」考え方として発表したものです。後にIFPUG法として整備されました。国内でもIPAの「ソフトウェア開発データ白書」（後継は「ソフトウェア開発分析データ集」）が、数千件のプロジェクトの規模と工数を公開してきました。ただし分析データ集は2022年版で発行が終わっています。
正直に言うと、ステップ数や画面数で見積もっていた頃は楽でした。処理を複雑にしたり、不要な画面や機能を増やしたりすれば、見積もり金額を上げることもバッファを積むことも可能だったからです。
各単位の前提と限界
どの単位も「作る量が工数に比例する」という前提に立っていました。限界もそこから来ます。
| 単位 | 強み | 限界 |
|---|---|---|
| コード行数 | 実績と比べやすい | 要件が決まる前には数えられない。言語や書き方で大きく変わる |
| FP | 言語に依存しない。発注側と共通言語になる | 計測にスキルと時間が要る。非機能要件や移行は拾いにくい |
| 画面数・帳票数 | 発注側にも分かりやすい | 「1画面」の重さが案件ごとに違う。画面の裏の処理が見えない |
| API数・テスト件数 | バックエンドや品質の重さを拾える | 外部連携やデータ移行の不確実さは個数に出ない |
共通する弱点は、要件定義・合意形成・移行のような「個数にならない作業」を、係数やバッファに押し込んできたことです。実装が重かった時代は、それでも大きく外れませんでした。AIはその前提を崩します。
AI（バイブコーディング）で何が変わったか
「バイブコーディング」は2025年2月にAndrej Karpathy氏が使った言葉です。本来は、AIが書いたコードを読まずに受け入れ、結果と追加の指示だけで進めるやり方を指します。受託開発では、人がレビューするAI活用が前提になります。この記事では、AIにコードを生成させる開発全般を、広い意味でバイブコーディングと呼びます。
効果は条件で大きく振れます。
- GitHub Copilotの実験（2023年）：95人がJavaScriptでHTTPサーバーを実装する課題で、Copilotありの群が55.8%速く終えた。
- METRの実験（2025年）：経験5年以上の開発者16人が、自分のオープンソースの実課題246件に取り組んだ。AIありの方が19%遅かった。本人たちは20%速くなったと感じていた。
新規で小さく閉じた実装は縮みます。既存の大きなコードや、曖昧な要件を含む作業は縮みにくいです。工程別に並べるとこうなります。
| 工程 | AI活用前 | AI活用後 | 見積もりへの影響 |
|---|---|---|---|
| 要件定義・合意形成 | 打ち合わせと議事録で詰める | 要件一覧や議事録の整理は速い。決めるのは人 | ほぼ縮まない |
| 設計 | 設計書を手で書く | たたき台は速い。業務との整合は人が見る | 少し縮む |
| 実装 | 画面・APIごとに書く | 生成が中心。新規・定型は大きく速い | 大きく縮む（幅が大きい） |
| コードレビュー・検証 | 他人のコードを抜き取りで確認する | 生成量が増え、読む量も増える | 増えることもある |
| テスト | ケース作成と実施 | ケース生成は速い。受入判定は人 | 少し縮む |
| 移行・リリース | リハーサルと切り替え | スクリプトは速い。現場調整は変わらない | ほぼ縮まない |
つまり「画面数×人月」のように実装量を起点にした見積もりは、AIで実装が縮むとその他の工程まで一緒に小さく見えてしまいます。
AI時代の見積もり書の考え方
結論から言うと、「何を数えるか」より「工程ごとに何が残るか」を積み上げるのが、今のところ一番説明しやすいと考えています。画面数やAPI数は、実装工程を見積もるための材料の1つに戻ります。
1. 工程別に積み上げる
要件定義・設計・実装・レビュー検証・テスト・移行・PMを別々に出します。実装の積算に係数を掛けて他工程を出すやり方は、AIで実装が縮むと他工程まで過小に見積もってしまいます。
2. 不確実性を幅で出す
AIの効き方は案件で大きく違います。実装は「標準」だけでなく「楽観・悲観」の幅を付け、どこで確定させるか（要件定義完了時に再見積もり、など）を書きます。
3. AI生成コードのレビュー・検証工数を別行にする
生成されたコードを読む・直す・脆弱性やライセンスを確認する作業は、実装に含めず別行にします。ここを削ると、品質の負担がテスト工程や保守に回ります。
最近は、不正アクセスなどAIによる攻撃が増えていることもあり、AIスクリーニングによるセキュリティチェックや非機能要件の要望が増えているように感じます。ただし、セキュリティ面の強化はUI/UXの不便さを伴う場合もあります。発注側には、作るサービスやシステムでどこまでやるかというバランス感覚が必要です。
4. AI利用の前提を明記する
使うツール、顧客のコードやデータをAIに渡してよいか、生成物の権利の扱いを前提条件に書きます。「AI利用不可」なら見積もりが変わることも並べて書きます。
5. 契約形態を工程で分ける
要件が固まるまでは準委任（工数ベース）、固まってから請負、という多段階契約と相性がよいです。AIで実装が速い分、小さく作って見せてから次の段階を見積もる進め方も現実的になりました。
見積もり書テンプレートとチェックリスト
そのままコピーして使える形にしました。数値は書き方の例で、実績値ではありません。
# 御見積書（AI活用前提）
## 1. 対象範囲
- 対象：画面 ○画面／API ○本／帳票 ○本／外部連携 ○件
- 対象外：（明記する）
## 2. 工程別の工数（人日）
| 工程 | 楽観 | 標準 | 悲観 | 積算の根拠 |
| --- | --- | --- | --- | --- |
| 要件定義（機能要件） | | | | 業務フロー数、機能一覧の項目数、打合せ回数×参加者 |
| 要件定義（非機能要件：性能・可用性・運用・セキュリティ） | | | | 非機能要件の項目数、セキュリティ要件（認証・権限・ログ・暗号化）の対応範囲 |
| 設計 | | | | 業務フロー数、画面・API数 |
| 実装（AI生成含む） | | | | 画面・API数×難易度 |
| AI生成コードのレビュー・検証 | | | | 生成範囲、ライセンス確認 |
| セキュリティ検証 | | | | 脆弱性診断・AIスクリーニングの対象範囲と回数 |
| テスト（結合・総合・受入支援） | | | | テスト観点数・ケース数 |
| 移行・リリース | | | | 移行対象データ、リハーサル回数 |
| プロジェクト管理 | | | | 期間×管理率 |
| 合計 | | | | |
## 3. 前提条件
- 使用するAIツール：○○
- 顧客のコード・データをAIに入力できる範囲：○○
- AI利用不可となった場合：実装工数を再見積もり
- セキュリティ要件の水準：○○（UI/UXへの影響を含めて合意した範囲）
- 生成物の権利・責任の扱い：契約書第○条に従う
## 4. 再見積もりのタイミング
- 要件定義完了時に、設計以降を確定見積もりとする
## 5. 契約形態
- 要件定義：準委任／設計〜テスト：請負／移行支援：準委任
提出前のチェックリストです。
- 実装の積算に係数を掛けて他工程を出していないか
- 要件定義・合意形成の工数を、打合せ回数など具体的な根拠で出したか
- 非機能要件・セキュリティ要件を機能要件と分けて見積もり、どこまでやるかをUI/UXへの影響も含めて発注側と合意したか
- AI生成コードのレビュー・検証を別行にしたか
- 実装に楽観・悲観の幅を付けたか
- AI利用の前提（ツール、データの扱い、利用不可時の扱い）を書いたか
- 対象外を明記したか
- 再見積もりのタイミングと契約形態を工程ごとに決めたか
- 移行・リリースを「一式」で済ませていないか
おわりに
コード行数も、FPも、画面数も、その時代の「一番重い作業」を数えるための道具でした。AIで実装が軽くなった今、重いのは「何を作るか決める」「作ったものを確かめる」作業です。
実装はAIによる開発が主流になり、開発チームはフルスタックエンジニア1名ということも当たり前になってきました。その分、メンバーのほとんどは構想策定・要件定義・設計、リリース後のマーケティングや運用設計を担う人たちです。そのため、開発のわかるビジネスメンバーの単価が急激に上がっているように感じます。
だから見積もり書も、工程ごとに何が残るかを書き、前提と幅を正直に見せる形に変える必要があります。「AIで安くなりますよね？」と聞かれたとき、どの工程が安くなり、どの工程が変わらないかを表で説明できれば、値引き交渉ではなく中身の話ができます。
皆さんの現場では、AI活用を見積もりにどう反映していますか。コメントで教えていただけると嬉しいです。