AI開発の途中で要望が増えたとき、追加費用で揉めるかどうかは金額の大小ではなく、「何が契約範囲で、何が範囲外か」を判定する基準が契約時に文章になっているかでほぼ決まります。結論から言えば、必要なのは値引き交渉の技術ではなく、変更が起きる前提で用意する「変更票（変更要望の受付票）」と、仕様変更と不具合を分ける判定基準の2つです。この記事では、発注側の担当者が契約前に決めておく文言と、要望が出た当日に回す手順を具体的に示します。
なぜ追加費用で揉めるのか？
揉める現場をほどいていくと、原因はたいてい次の3つに集約されます。
- 最初の合意が「目的」止まりで「成果物」になっていない。「問い合わせ対応を楽にするAI」とだけ書かれていて、画面数・対応するデータの種類・想定する質問の範囲が書かれていない
- 追加要望が口頭やチャットで流れ込む。打ち合わせの雑談で「ついでにこれも」と言った一言が、ベンダー側では工数として積み上がっている
- AI特有の「やってみないと分からない部分」が、どちらの責任か決まっていない。精度が出ないときの追加調整は、ベンダーの義務なのか、発注側が追加で払う作業なのか
ここで大事なのは、要望が増えること自体は失敗ではないという前提です。業務システム、特にAIを使うものは、動くものを見て初めて「こうしたい」が出てきます。増えることを前提に、増えたときの処理手順を先に決める。これが変更管理（チェンジコントロール＝仕様の追加・変更を記録し、影響と費用を評価してから着手する仕組み）です。
「仕様変更」と「不具合」はどう分ける？
揉め事の大半はこの線上で起きます。発注側は「直してもらって当然（不具合）」と考え、ベンダーは「それは新しい要望（仕様変更）」と考える。判定に使う問いは1つだけで足ります。「合意した文書に、その動作が書かれているか」です。
| 状況 | 区分の目安 | 費用の扱い |
|---|---|---|
| 要件定義書に書かれた動作をしない | 不具合（契約不適合） | 追加費用なしで修正 |
| 書かれていないが、業務上明らかに必要 | 仕様の抜け漏れ | 双方で原因を確認し分担を協議 |
| 書かれた内容と違うことをしたい | 仕様変更 | 見積もりの上で追加 |
| 新しい画面・新しいデータ源の追加 | 追加開発 | 見積もりの上で追加 |
| 合意した精度基準を満たさない | 不具合に近い | 基準の測り方を含めて確認 |
この表を機能させるには、契約時点で「書かれているか」を判定できるだけの文書がいります。逆に言えば、要件定義書が薄いほど、後から全部が「仕様変更」になるということです。契約不適合責任については、民法のほか、独立行政法人情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書」が参考になります。細かな条文の正誤は顧問弁護士に確認する前提で、まずは自社の契約書に変更管理の条項があるかどうかだけでも見ておくとよいでしょう。
AI開発で特に揺れる4つの論点
通常のシステム開発に加えて、AIを使う案件では次の4点が追加費用の火種になりやすいところです。契約前にこの4つだけでも文章にしておくと、後の会話が楽になります。
1. 精度の目標と、測り方
「精度90%」とだけ書いた合意は、ほぼ必ず揉めます。何をもって正解とするか、どのデータで測るか、誰が採点するかがセットでなければ数字は意味を持ちません。評価用データは発注側が用意するのか、件数はいくつか、採点基準は誰が書くのか。検収の考え方はAIの検収は自社データ100件で足りるで整理しています。
2. 間違えてよい範囲
AIは必ず間違えます。問題は「どの間違いなら運用で吸収できるか」です。これを先に決めていないと、出てきた誤りがすべて「不具合」に見えてしまいます。AI外注で先に決める「許していい誤り」の考え方を、要件定義書の中に1節として入れておくのが実務的です。
3. プロンプト調整・再学習の回数
「出力の言い回しをもう少し柔らかく」という要望は、1回なら数十分ですが、10回繰り返せばまとまった工数になります。検収までの調整は何往復まで無償かを回数で書く。これだけで「際限なく直させられる」「際限なく頼まれる」の双方の不安が消えます。
4. 基盤モデルの変更・提供終了
外部の生成AIサービスを使う構成では、モデルの世代交代や提供終了、料金改定が開発期間中に起きることがあります。そのときの移行作業を誰が負担するか。保守・運用の費用設計と合わせて、AI開発の月額費用、契約前に聞く8項目の観点で事前に確認しておきます。
要望が出たとき、その日に何をする？
線引きのルールがあっても、運用の入口が雑だと機能しません。おすすめは、A4で1枚の「変更票」を作り、追加要望は必ずこの票に書いてから相談すると決めることです。項目は次の5つで足ります。
- 要望の内容（画面名・業務の場面まで具体的に）
- なぜ必要か（業務が回らないのか、あれば便利なのか）
- いつまでに必要か（本稼働前か、稼働後でもよいか）
- 発注側の判定（不具合だと思う／仕様変更だと思う／分からない）
- ベンダーの回答欄（区分・追加工数・納期への影響）
そして会議体として、週1回15分の「変更の棚卸し」を置きます。その週に出た変更票を並べ、(A) 今回やる (B) 稼働後の第2期に回す (C) やらない、の3つに仕分ける。たとえば次のような場面です。現場から「帳票の色を変えたい」「集計の切り口を増やしたい」「他部署の様式にも対応したい」と3件出たとき、1件目は(C)、2件目は(A)、3件目は(B)と決めて記録する。決めたこと自体を残すのが重要で、これがないと同じ要望が月をまたいで何度も再燃します。
もう1つ効くのが、追加要望の予算枠を最初から確保しておくやり方です。契約額とは別に変更対応用の枠を持っておき、変更票ごとにそこから引いていく。枠が減っていくのが見えると、現場の要望の出し方も自然に優先順位がつきます。
契約前に書いておきたい線引きの文言
専門的な条文は法務の領域ですが、発注側が「これだけは入れてほしい」と伝えられるポイントは絞れます。
- 変更管理の手続き：変更は書面（変更票）で提出し、双方の合意後に着手する。合意前の作業は費用請求の対象としない
- 区分の判定方法：不具合か仕様変更かは、要件定義書および受入基準書の記載を基準に判定する
- 無償調整の範囲：検収までの出力調整は◯往復まで、それ以降は別途見積もり
- 評価データと採点者：精度の確認に使うデータの提供責任、件数、採点の担当を明記
- 契約形態の区別：精度の達成を約束しにくい検証段階は準委任（作業の遂行を約束する契約）、仕様が固まった実装段階は請負（完成を約束する契約）と、フェーズで分ける
最後の点は特に重要です。AIの精度は事前に保証しにくいため、検証段階まで請負でまとめて契約すると、ベンダーはリスク分を見積もりに上乗せせざるを得ません。経済産業省が公開している「AI・データの利用に関する契約ガイドライン」でも、探索的な段階と開発段階を分ける考え方が示されています。分割して契約すること自体が、追加費用の揉め事を減らす設計になります。
まとめ
追加費用で揉めないための線引きは、交渉力ではなく準備の問題です。やることは3つに整理できます。
- 契約前：要件定義書と受入基準書を、判定に使える粒度で作る。精度の測り方、許容する誤り、無償調整の回数、モデル変更時の扱いを文章にする
- 契約時：変更管理の手続きを条項に入れる。検証段階と実装段階で契約形態を分ける。変更対応用の予算枠を確保する
- 開発中：追加要望は変更票に書いてから相談する。週1回15分で棚卸しし、今回やる／次期に回す／やらないを記録する
明日からできるのは、A4で1枚の変更票を作ることです。項目は5つで足ります。この1枚があるだけで、「言った・言わない」が「書いてある・書いてない」に変わります。それが、追加費用の議論を感情から事実へ移す最初の一歩になります。
この記事は、AI で下書きを作り、益山康秀（運営者）が内容を確認して公開しています
