AI時代の見積書の作り方。4ブロックの値付けと、売上に直結しないシステムの成果報酬設計
はじめに
本連載の第1回 人月見積りはどこへ消えるのか では、AIが「工数と価値の比例関係」を壊し、人月見積りが説明力を失っていく構造を論じました。では、人月をやめたら見積書は具体的にどんな項目になるのか。今回はそこに踏み込みます。
特に難しいのが、「成果報酬」をどう設計するかです。ECサイトなら売上連動でわかりやすいのですが、採用システムや調達システム、基幹システムのように売上に直結しないものでは、何を「成果」と数えればいいのかが見えにくい。この具体論を、日本の現場での作られ方まで含めて整理します。
この記事のポイント
- AI時代の見積書は「固定（判断と設計）＋ 従量（AI実行コスト）＋ 運用（保守）＋ 成果連動」の4ブロックで組む
- AIの実行コストはトークン実費を2〜5倍にバッファし、モデル変更時のパススルー条項を入れる
- 売上に直結しないシステムは、業務KPIを金銭換算し、ベースライン合意と上限、下限付きゲインシェアで設計する
AI時代の見積書は、どんな項目で構成されるのか？
結論から言えば、「人月 × 単価」の一枚岩を、性質の違う4つのブロックに分けて値付けします。採用システムの刷新を例にすると、見積書はこう組み替わります。
| 区分 | 項目 | 価格形態 | 中身 |
|---|---|---|---|
| ①初期、固定 | 業務分析、要件定義 | 固定 | 現行フローのヒアリングと課題の洗い出し（＝判断の対価） |
| アーキテクチャ設計、技術選定 | 固定 | データモデルや外部連携、セキュリティ方針の設計 | |
| 実装（AI支援前提） | 固定（縮小） | Claude Code/Codex 前提で圧縮。「手を動かす時間」はここだけ | |
| 品質保証、セキュリティレビュー | 固定 | テスト設計や脆弱性レビュー、受け入れ条件の作成 | |
| ②変動と実費 | AIエージェント実行コスト | 従量（実費＋マージン） | トークン実費をバッファ＋モデル変更時のパススルー条項 |
| クラウドインフラ | 従量 | 推論コストの10〜15%目安の監視とホスティング | |
| ③運用、継続 | 保守リテーナー（準委任） | 月額固定 | 障害対応や小改修、SLA。保守リザーブを年間で計上 |
| ④成果連動 | KPI達成ボーナス | 成果連動（上限と下限付き） | 後述のKPIへのゲインシェア。総額の一部に限定 |
ここで効いてくるのは、縮むのは①の「実装」行だけだという点です。AIで圧縮されるのは手を動かす時間であり、設計や品質保証、運用の対価はむしろ相対的に厚くなります。だから総額を一律に下げるのではなく、内訳を組み替えるのが本質です。
AIの実行コストは、見積りにどう乗せるのか？
AIコーディングは「タダ」ではないため、②の変動費を正直に見積書へ乗せる必要があります。海外の実務では、トークンの実費を見積もったうえで 2〜5倍のバッファ を掛けて固定見積りに織り込む、という考え方が定着しています（pickaxe「How to Price AI Services」）。
契約には「使用量が倍増、またはモデルが変わった場合は再見積りする」というパススルー条項を入れておきます。クラウドの従量課金にすでに慣れた発注側にとって、これは説明すれば受け入れられる範囲です。
③の保守リテーナーには、年間で構築費の 15〜30% 程度を保守リザーブとして見込むのが目安とされます（同）。インフラ監視の間接費は推論コストの10〜15%程度。この月額の保守こそが、人月に頼らない安定収益の柱になります。一過性の構築費ではなく、運用と改善を継続的に対価化する発想への転換です。
売上に直結しないシステムで、成果報酬をどう設計するか？
原則は、売上が使えないなら「金銭換算できる業務KPI」に翻訳することです。採用や調達、基幹のいずれも、業務の改善を数値化すれば成果指標になります。
| システム | 金銭換算できるKPI | 非金銭KPI（閾値ボーナス型） |
|---|---|---|
| 採用システム | 採用単価の削減、採用担当の工数（人時）削減 | 応募〜内定リードタイム、辞退率 |
| 調達システム | 調達コスト削減率、管理下支出（SUM）の拡大 | Procure-to-Pay サイクルタイム、例外発注やコンプラ違反の削減 |
| 基幹、会計 | 手作業工数の削減（人時×人件費）、運用保守費の削減 | 月次決算の締め日数、入力エラー率、ダウンタイム |
調達であれば「承認リードタイムを平均5日→2日に短縮」「手作業の発注処理を月200時間削減（＝人件費換算◯円）」をKPIにし、削減額の一部を報酬にします。プロセス調達のサイクルタイムやコスト削減率は、CIPS など調達の標準KPIとしても整理されています。
ただし、売上連動より設計が難しい。外せないのは3点です。
- ベースライン合意（＝検収）: before の数値を契約時に確定する。これがないと成果が測れません。
- 上限と下限（caps & floors）: 外部要因でKPIは振れるため、ベンダーが青天井で得も損もしないよう pains/gains を分け合う設計にします（California Management Review の outcome-based 設計でも標準）。
- 帰属の切り分け: 成果が顧客側の運用変更やデータ品質に依存する分は、成果連動から外す。
売上に直結しないシステムほど、成果の帰属（その改善はベンダーの実装によるものか、顧客の業務改革によるものか）が曖昧になります。だからこそ成果連動は「総額の一部」に留め、ベースラインと上限と下限をセットで握ることが、紛争を避ける生命線になります。
日本の現場では、この見積りはどう作られるか
日本で「完全成果報酬」が広く馴染むことは当面ないでしょう。第1回でも触れたとおり、多重下請け、稟議の積み上げ予算文化、計測や帰属を嫌う関係性重視、ベンダーの低リスク許容度という4つの壁があるためです。
だから日本の見積書は、いきなり④を大きく取るのではなく、①固定 ＋ ②従量 を主役にし、③保守を安定収益の柱に据え、④成果連動はコスト削減額の数％で上限付きにして小さく添える形が現実解になります。稟議を通すコツも同じで、「成果が出たら払う」の不確実性を前面に出さず、固定と従量で総額の予見性を担保したうえで、④を「うまくいったら追加で支払うアップサイド」として位置づけると承認が下りやすくなります。
順序としては、まずクラウドで慣れている②の従量を入れ、次に③保守のSLAで成果連動の感覚を共有し、最後に④のゲインシェアへ、という段階導入が、日本の商習慣には最も馴染みます。値付けの単位を「人月」から「解決した課題」へ、稟議の通る形で少しずつ移していく。その設計こそが、これからの受託の競争力になります。
よくある質問
Q. AIの実行コストはクライアントに転嫁してよいのですか？
A. はい。クラウドの従量課金と同じ考え方です。トークン実費を2〜5倍でバッファした固定見積りにするか、実費＋マージンのパススルーにします。モデル変更時の再見積り条項を添えるのが安全です。
Q. ベースライン（before の数値）が取れない場合はどうしますか？
A. 成果連動は見送り、まず①固定＋②従量＋③保守で受けます。最初の数か月でベースラインを計測し、データが揃ってから④成果連動を後付けで導入するのが堅実です。
Q. 上限と下限（caps & floors）はなぜ必要ですか？
A. KPIは外部要因でも振れるためです。下限はベンダーの最低保証、上限はクライアントの支払い上限。双方の不確実性を分け合うことで、成果連動を「揉める契約」ではなく「続く契約」にできます。
Q. 保守リテーナーはどのくらいの規模が目安ですか？
A. 海外の実務では年間で構築費の15〜30%程度が一つの目安です。障害対応や小改修、SLA、AI実行コストの監視を含めて設計します。
まとめ
AI時代の見積書は、人月の積み上げから「固定＋従量＋運用＋成果連動」の4ブロックへ組み替わります。縮むのは実装の対価だけで、設計や品質保証、運用の比重はむしろ増します。
売上に直結しないシステムでも、業務KPIを金銭換算し、ベースライン合意と上限と下限を握れば成果報酬は設計できます。日本ではそれを、稟議の通る形で段階導入していくのが現実解です。
ZenChAIne は Claude Code と Codex 前提の開発と、この4ブロック型の見積り設計の両面で、移行期の受託の値付けを支援しています。連載第1回 人月見積りはどこへ消えるのか と合わせてご覧ください。