結論

AI開発プロジェクトで発注側とベンダーの信頼関係が壊れる典型パターンは、変更要求のたびに「これは追加費用です」「いや当初範囲のはずだ」という交渉を場当たりで繰り返すことです。解決策は、変更要求を1件ずつ受け付けて有償・無償を判定し、判定理由と契約条項の対応を記録する変更管理台帳を、プロジェクト開始週から運用することです。判定基準は契約時に3区分(明記済み・解釈補充・範囲外)で合意しておき、判定の場をベンダーとの週次定例に固定します。

変更要求台帳とは何か

変更要求台帳とは、仕様変更・追加要望・前提変更のすべてを起票し、契約範囲との対応、有償・無償の判定、金額、承認者、対応スプリントを1行で管理する一覧表のことです。課題管理表との違いは、「契約のどの記述を根拠に判定したか」の列を必ず持つ点です。

AI開発では、精度改善の要望、プロンプト調整、評価データの追加、誤出力パターンへの対処など、従来のシステム開発より「仕様と言い切れないグレーな要望」が多く発生します。台帳がないと、ベンダーが善意で無償吸収した作業が積もって後半に破綻するか、逆にすべて有償と言われて予算が崩れるかの二択になりがちです。

有償・無償の判定基準を3区分で作る

判定基準は契約時に次の3区分で合意します。

運用のコツは、B区分に工数閾値(例: 1件あたり2人日以内)を設けることです。閾値以内はベンダーが吸収、超える場合は協議に上げると決めておくと、少額案件の交渉コストが消えます。また「精度をもう少し上げてほしい」という要望は、当初契約に精度目標が数値で書かれていない限りC区分になることを、発注側の業務部門にも周知してください。ここの期待値ずれが最も多い紛争源です。

台帳の列設計と記録要件

台帳は次の列で作ります。スプレッドシートで十分ですが、行の削除・改変履歴が残るツールを使ってください。

判定理由は後から第三者が読んで追跡できる粒度で書きます。下請法の適用がある取引では、発注後の一方的なやり直し要求や代金減額が問題になり得るため、発注側にとってもこの台帳は「不当な無償要求をしていない」ことの証跡になります。

定例での判定運用と紛争予防

判定は週次定例の固定議題にします。その場で決められない案件は「保留」のまま作業着手しないのが原則です。着手後に有償と判明した作業の費用負担は必ず揉めます。

紛争予防の観点では、C区分の見積を承認せず口頭で「進めておいて」と言う運用が最も危険です。IPAのモデル取引・契約書でも変更管理手続きの書面化が繰り返し強調されており、承認前着手を認める場合でも、上限金額つきの包括承認枠(月あたりの変更予算)として契約に書くのが安全です。

コスト管理への接続

台帳を月次で集計すると、C区分の累計金額とB区分の消化工数が見えます。C区分累計が当初契約額の15%を超えたら、個別変更の積み上げをやめて契約変更(スコープ再定義)の協議に切り替えるのが目安です。変更が多いこと自体は失敗ではなく、要件が学習によって精緻化しているサインですが、単価の高い緊急変更が増えている場合は、要件定義のやり直しのほうが安くつきます。

実務チェックリスト

• 変更判定の3区分(明記済み・解釈補充・範囲外)を契約時に合意したか
• B区分の工数閾値と超過時の協議ルールを決めたか
• 台帳に根拠文書の列を設け、判定理由を記録しているか
• 判定を週次定例の固定議題にしたか
• 承認前着手の禁止、または包括承認枠を契約に書いたか
• 口頭の変更依頼を当日中に起票する運用を周知したか
• C区分累計が契約額の15%を超えた際の契約再協議ルールを決めたか

図解で確認するポイント

この記事の画像は、複数の変更要求が判定の分岐を通り、有償・無償に振り分けられて台帳へ記録される流れを文字なしで図解しています。判定と記録が一本の流れでつながっていることが台帳運用の要点です。

AllAI内での次の行動

変更管理の全体像はAI開発の変更依頼管理ガイド、スコープ膨張の抑え方はスコープクリープ防止ガイドが隣接テーマです。契約前の要件整理はAI発注診断で行い、変更管理プロセスを提示できる開発会社をAI開発パートナーで比較してください。全体の進め方はAI開発外注完全ガイドにまとまっています。

FAQ

Q. 台帳は発注側とベンダーのどちらが管理すべきですか? A. 起票は両者可、台帳のマスター管理は発注側が持つのが原則です。ベンダー管理に任せると、無償吸収した作業が記録されず、後から「これだけ無償対応した」という主張の根拠がベンダー側にだけ蓄積します。

Q. アジャイル型契約でも有償・無償判定は必要ですか? A. 準委任のアジャイル契約では、変更は費用でなくバックログの優先順位で吸収されます。それでも台帳は必要で、判定列の代わりに「スプリント投入判断と押し出されたアイテム」を記録すると、スコープと予算の対応が追跡できます。

Q. ベンダーが軽微な変更をすべて有償と言ってきます。 A. B区分(解釈補充)の定義と閾値が契約にないことが原因です。追補覚書で3区分と閾値を合意し直してください。それでも全件有償を主張する場合、要件定義書の粒度が粗すぎる可能性が高く、要件の再確定に投資するほうが総額は下がります。

Q. 精度改善の要望はどう扱えばよいですか? A. 契約に精度目標が数値で書かれていればA区分、書かれていなければC区分が原則です。ただし明らかなバグ(実装ミス)起因の精度低下は瑕疵対応であり、変更要求とは別の欠陥管理で扱ってください。

出典と確認日

• 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・データの利用に関する契約ガイドライン」: https://www.meti.go.jp/press/2018/06/20180615001/20180615001.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)