AI開発 変更要求の有償無償判定台帳
AI受託開発の変更要求を、PM・PMO・経理が有償か無償かで判定する基準、台帳の付け方、合意記録、費用の見方を整理します。
結論
AI受託開発の変更要求は、その都度の口頭合意ではなく、有償か無償かを一定の基準で判定して台帳に残すことが重要です。開発PM、PMO、経理が、変更依頼票、判定記録、合意記録を1つの台帳に集約すると、追加費用の妥当性と当初契約範囲の線引きを説明できます。
この記事は、開発の途中で「これは仕様なのか追加なのか」で揉める発注者向けに、変更要求を仕分ける基準と記録の残し方をまとめます。台帳がないと、無償対応の押し付けと不当な追加請求の両方が起きます。
変更要求の判定台帳とは何を決める仕組みか
判定台帳とは、開発中に出た変更要求を受け付け、当初合意の範囲内か外かを判定し、有償・無償と対応可否を記録する一覧です。ベンダーとの対立を避けるためではなく、契約範囲と追加の境界を客観的に管理し、予算とスケジュールを守るための仕組みです。
台帳を運用する前に、当初のスコープ定義、要件書、受入基準、前提条件を確定しておきます。基準となる「元の合意」が曖昧だと、何を変更と呼ぶかで判断がぶれます。変更管理の手順(受付、判定、承認、実施)は契約段階で合意しておきます。
有償無償の判定基準表
変更要求は、次の観点で区分します。表は契約のスコープ定義に合わせて調整します。
| 判定区分 | 例 | 台帳での扱い |
|---|---|---|
| 当初範囲内(無償) | 要件書に含む機能の不具合修正 | 修正として記録、追加費用なし |
| 前提変更(要協議) | 提供データや連携先の仕様変更 | 影響と費用を協議、合意記録 |
| 追加要求(有償) | 新機能、対象業務の拡張 | 見積提示、承認後に着手 |
| 保留・見送り | 優先度が低い改善案 | 次フェーズ候補として記録 |
表で区分するだけでなく、判定の理由(要件書のどこに含む・含まないか)を文章で記録します。特に「前提変更」は、発注者側の都合で前提が変わった場合とベンダー側の見落としで分岐するため、原因の記録が重要です。
変更管理と承認の進め方
変更要求は、受付番号を付けて台帳に登録し、判定→見積→承認→実施の順で進めます。有償と判定した要求は、見積(工数、費用、納期影響)を提示し、承認者の合意を記録してから着手します。承認前に着手すると、後で費用負担で揉めます。台帳には、要求日、判定日、判定者、承認者、実施状況を残します。
データ・記録・ログの扱い
変更に伴ってデータ項目や連携仕様が変わる場合、影響範囲(既存データの移行、再評価の要否)を記録します。判定記録と合意記録は、メールやチャットの断片ではなく、台帳に集約して版管理します。誰がいつ何を承認したかが追える状態を保ちます。
費用と予算管理の見方
変更の費用は、当初予算とは別の変更予備費として管理すると、都度の稟議を減らせます。有償変更が積み上がると総額が膨らむため、台帳で累計を可視化し、一定額を超えたら見直し会議を開くルールにします。無償対応が多い場合も、当初スコープの精度に問題があった可能性を記録し、次回の見積に反映します。
実務チェックリスト
- 当初スコープ・要件書・受入基準を確定したか
- 変更管理の手順(受付・判定・承認・実施)を契約で合意したか
- 変更要求に受付番号を付けて台帳に登録しているか
- 有償・無償・要協議・保留の判定基準を決めたか
- 判定理由を要件書のどこに基づくか記録しているか
- 有償変更は見積・承認後に着手しているか
- 変更費用の累計を可視化しているか
- 無償対応の多さをスコープ精度の改善に反映しているか
チェックリストは、契約時、フェーズ切替時、予算見直し時に確認します。台帳を累計つきで運用すると、追加費用の妥当性を稟議で説明しやすくなります。
図解で確認するポイント
この記事の画像は、変更要求を受け付けてから有償・無償を判定し記録するまでの流れを、複数のカードと接続線で表しています。文字や宣伝を入れず、どの段階でどの記録を残すかを視覚的に確認できるようにしています。
AllAI内での次の行動
まず AI発注診断 で当初スコープと変更の想定を整理してください。関連する実務は AI開発 見積前提条件の差分管理ガイド と AI開発 追加開発の単価改定通知フロー で確認できます。開発会社の比較は AI開発の発注支援、既製サービスの選択肢は AI/SaaS比較 も合わせて確認します。
FAQ
Q. 変更が仕様の範囲内か追加かは誰が決めますか? A. 台帳の判定者が要件書と受入基準に基づいて判定し、争いがある場合は協議記録を残します。判定基準を事前に合意しておくと揉めにくくなります。
Q. 無償で対応してもらえる変更はどこまでですか? A. 当初範囲に含む機能の不具合修正が中心です。前提や範囲が変わる要求は、原則として協議または有償になります。
Q. 承認前に着手してもよいですか? A. 避けるべきです。有償変更は見積と承認を記録してから着手しないと、後で費用負担で揉めます。
Q. 変更が多発した場合はどうしますか? A. 累計費用を可視化し、一定額を超えたら見直し会議を開きます。スコープ定義の精度に問題があれば次回見積に反映します。
出典と確認日
- 独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html (確認日: 2026-07-10)
- 公正取引委員会・中小企業庁「下請取引適正化」: https://www.jftc.go.jp/shitauke/ (確認日: 2026-07-10)
- 経済産業省・総務省「AI事業者ガイドライン」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。