結論

AI開発の追加費用交渉の大半は、機能の追加ではなく「見積の前提が崩れたこと」から発生します。データがきれいである前提、既存APIが仕様書どおり動く前提、発注側担当者が週N時間関与できる前提、こうした前提条件は見積書の末尾に小さく書かれ、誰も管理しないまま進行し、崩れた瞬間に追加請求として表面化します。対策は、契約時に見積の前提条件をすべて抽出して前提台帳を作り、週次で「崩れた前提」を差分として記録し、費用影響の協議を前提単位で行うことです。

見積前提の差分管理とは

見積前提の差分管理とは、見積金額の根拠になっている条件を一覧化し、プロジェクト進行中に各条件が維持されているか・崩れたかを追跡し、崩れた場合の費用影響を都度合意していく運用のことです。変更管理(仕様変更の管理)と似ていますが、対象が「発注側が依頼した変更」ではなく「両者が置いた仮定の変化」である点が異なります。

AI開発で前提管理が特に重要なのは、見積時点で最大の不確実性がデータにあるからです。データの品質・量・アクセス手段は、実際に触るまで確定しません。経済産業省のAI契約ガイドラインが探索的段階型の契約を推奨するのも、この不確実性を段階ごとに縮めていく構造のためです。

前提台帳の作り方: 見積書から前提を掘り出す

契約前に、見積書・提案書から前提条件をすべて抽出します。明示されている前提だけでなく、金額から逆算される暗黙の前提も、この段階でベンダーに確認して文字にします。

抽出した前提は1件1行で台帳化し、各行に「確認方法」と「崩れた場合の扱い(再見積・協議・リスク費で吸収)」を書きます。契約書には、この台帳を見積の一部として添付し、前提崩れ時の協議手続きを定める条項を入れてください。

週次の差分記録の運用

進行中は、週次定例の議題に「前提の状態確認」を5分入れます。全行を毎週見る必要はなく、直近の工程に関係する前提だけを確認し、状態を「維持・崩れ・崩れの兆候」の3値で更新します。

崩れが確認されたら、その場で金額交渉をせず、まず差分記録(何が、いつ、どちらの領域で崩れたか、一次的な影響見立て)を残します。金額影響の見積はベンダーが5営業日以内に提出、協議して台帳の当該行に決着(追加費用額、スケジュール影響、負担者)を記録する、という流れを型にします。この型があると、追加費用の議論が「言った言わない」から「台帳のどの行がいつ崩れたか」の事実確認に変わります。

責任領域の切り分け

前提崩れの費用負担は、崩れた前提がどちらの責任領域かで決まります。発注側領域(データ提供、環境準備、担当者の関与、社内承認の速度)の崩れは発注側負担、ベンダー領域(技術的な見立て、工数見積、既知技術の習熟)の崩れはベンダー負担が原則です。難しいのは共有領域(外部サービスの仕様変更、法規制の変更)で、ここはリスク分担条項として契約時に負担ルールを決めておきます。

発注側として注意すべきは、自社領域の前提を軽く見積もらないことです。「データはすぐ出せます」と言って3ヶ月かかるのは頻出パターンで、この待機期間の費用はベンダーから正当に請求され得ます。前提台帳は、ベンダーを縛る道具であると同時に、発注側の社内タスク(データ抽出の情シス依頼、環境構築の稟議)の期限管理表でもあります。

リスク費の透明化という副産物

前提を台帳化すると、見積の「リスクバッファ」の議論が透明になります。ベンダーは不確実性が高いほどバッファを積みますが、前提が明文化され崩れ時の協議ルートが保証されると、バッファを減らした見積が出せるようになります。相見積の比較でも、安い見積が「前提を楽観的に置いているだけ」なのか「効率が高い」のかを、前提台帳の粒度で見分けられます。総額だけの比較は、前提の楽観度比較にしかなりません。

実務チェックリスト

• 見積書・提案書から明示・暗黙の前提を全件抽出したか
• 前提台帳を見積の一部として契約に添付したか
• 前提崩れ時の協議手続き(差分記録→5営業日で影響見積→協議)を決めたか
• 週次定例に前提の状態確認を組み込んだか
• 発注側領域・ベンダー領域・共有領域の負担原則を合意したか
• 共有領域(外部API変更等)のリスク分担条項を入れたか
• 発注側の前提(データ提供・環境・関与時間)を社内タスクとして期限管理しているか
• 相見積の比較で前提の楽観度を見たか

図解で確認するポイント

この記事の画像は、当初の見積文書と進行中の状態が比較され、差分が抽出されて協議へ進む流れを文字なしで図解しています。金額ではなく前提の差分を追跡する構造が、この管理手法の中心です。

AllAI内での次の行動

前提が崩れて仕様変更になる場合の処理は変更要求の有償・無償判定台帳の作り方へ接続します。見積の取り方全体はAI開発費用ガイド、RFPでの前提の書かせ方はAI開発RFPの書き方ガイドを確認してください。要件の不確実性が高い段階ならAI発注診断で整理し、AI開発パートナーで見積の前提開示に応じる会社を比較できます。

FAQ

Q. 前提台帳は何件くらいになりますか? A. 中規模のAI開発で20-40件が目安です。10件未満しか出てこない場合は暗黙の前提が抽出できていない可能性が高く、「この金額はどんな条件が変わると成立しなくなりますか」とベンダーに直接聞いてください。

Q. ベンダーが前提の明文化を嫌がりませんか? A. 逆のことが多いです。前提の明文化はベンダーにとっても追加請求の根拠が明確になる仕組みであり、誠実なベンダーほど歓迎します。嫌がる場合は、崩れたときに黙って吸収するか黙って請求するかのどちらかを選ぶつもりだと解釈できます。

Q. 準委任契約でも前提管理は必要ですか? A. 必要です。準委任では追加費用の形ではなく「想定より進まない」形で前提崩れが現れます。台帳があると、ベロシティ低下の原因が前提崩れ(データ遅延等)なのか実力不足なのかを切り分けられ、契約更新判断の材料になります。

Q. 崩れた前提の協議がまとまらない場合は? A. 契約に定めた協議手続きに従い、まとまらない場合の第三者関与(上位者間協議、ADR)まで契約時に決めておくのが理想です。少なくとも、協議中の作業継続可否(中断か、リスク承知で続行か)だけはその場で決めてください。

出典と確認日

• 経済産業省「AI・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.html (確認日: 2026-07-10)
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
• 公正取引委員会「下請法・中小受託取引適正化法」: https://www.jftc.go.jp/shitauke/index.html (確認日: 2026-07-10)
• 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)