システム開発の仕様変更と追加費用―依頼・影響評価・合意・中止時の確認事項（AI作成）

第１　仕様変更と追加費用を分けて確認する

システム開発で当初の予定と異なる対応が必要になったときは，①契約内の作業か，②変更によってどのような影響が生じるか，③費用や納期を変更する合意があるかを順に確認する。
ユーザーが修正を求めたことだけで追加費用が決まるわけではなく，ベンダーが作業したことだけで提示した見積額の支払義務が確定するわけでもない。
本記事は，令和８年１０月４日時点で確認した民法と，IPAが公開する「情報システム・モデル取引・契約書（第二版）」の開発モデル契約を基に，契約審査と開発中の協議で確認すべき事項を整理する。

IPAのモデル契約は，その条項が当事者の契約に採用されて初めて契約上の手続となる。
すべてのシステム開発契約にそのまま適用される法令ではないため，以下のモデルの説明と，自社の基本契約・個別契約・変更合意の内容を照合する必要がある。

第２　元の契約範囲と変更対象を特定する

１　契約書と仕様書の版をそろえる

仕様変更の契約書審査では，業務上の必要性を判断する人と，技術的な影響を判断する人を区別する。双方の情報を集めた上で，変更の費用・納期を決める権限者へ上げる。次の表は役割分担の提案であり，個々の担当者の法的義務が一律に決まるという意味ではない。

パッケージの標準機能で対応するか，設定変更か，個別開発かによって，費用と保守の前提が変わる。採用する方法を決めず，機能名だけを追加して合意したことにしない。

基本契約，個別契約，見積書，要件定義書，外部設計書，検査仕様書及び承認済みの中間資料を集め，どの文書のどの版が合意の対象となったかを確かめる。
提案書や議事録についても，契約内容に取り込まれた部分，説明の前提にすぎない部分及び後で変更された部分を区別する。
文書の優先関係，対象外業務，前提条件及び未確定事項の一覧を確認してから，現在の依頼と比較する。

IPAの開発モデル契約３４条は，システム仕様書，検査仕様書及び承認済みの中間資料を変更管理の対象としている。
同３６条は，未確定事項の内容と確定予定時期等を事前に書面で整理し，確定後の追完・修正を変更管理手続に乗せる構成である。
「未確定だったからすべて契約内」又は「承認後だからすべて追加費用」と決めつけず，未確定事項をどの条件で引き受けたかを確認する。

２　不具合の修正と機能の追加を区別する

合意済みの仕様に合致しない部分を直すのか，合意済みの仕様自体を変えるのかを，該当する文書と検査結果で説明できるようにする。
IPAの開発モデル契約２８条は，検査不合格の具体的な理由を明示し，理由が認められる場合に無償で修正して再検査する手続を定める。
同２９条は，検収後のシステム仕様書との不一致を契約不適合として扱う。

このため，契約上必要な修正を「変更依頼」と呼び替えるだけで，追加報酬の根拠にすることはできない。
他方，仕様を変更する依頼については，元の契約に含まれる変更対応の範囲と条件を確認する。
当事者の見解が異なる場合は，争いのある箇所，それぞれの根拠及び調査に必要な資料を残し，分類が未確定のまま費用だけを確定させない。

第３　変更依頼と影響評価を別の記録にする

１　依頼する側が示す事項

変更依頼には，対象文書と版，変更前後の内容，変更を求める理由，希望時期，依頼者及び承認者を記載する。
必要性が高い項目と，後の開発に回せる項目を分け，優先順位を伝える。
IPAの開発モデル契約３４条は，変更の内容や理由等を明記した変更提案書を相手方に交付する形を採っている。

依頼の受付は，その内容，金額及び納期への同意とは区別する。
会議で検討対象に加えたこと，作業の可否を調査すると回答したこと，又は見積書を受領したことが，どこまでの合意を意味するかが曖昧にならないよう，その時点の決定事項と保留事項を示す。

２　対応する側が示す事項

影響評価では，変更の詳細，必要な費用，検討期間を含めた作業予定及び契約条件への影響を整理する。
IPAの開発モデル契約３７条１項は，これらに加え，変更の名称，提案責任者，年月日及び理由を変更管理書に記載して協議する構成である。

実務上は，費用の算定対象，追加の調査・設計・実装・検査，既に行った作業の手戻り，関連する機能への影響及び見積りの前提を説明すると，判断材料を共有しやすい。
これは同モデルの費用・予定・契約条件への影響を具体化する確認項目であり，すべての変更で同じ追加作業が生じるという意味ではない。
変更案をそのまま実施する場合だけでなく，対象を減らす，実施時期を分ける，又は変更しない選択肢も比較する。

第４　費用・納期・着手条件まで合意する

１　技術的な承認と契約条件の変更

仕様の内容に賛成したことと，追加費用や納期の変更を承認したことを区別する。
IPAの開発モデル契約３７条２項・３項は，双方の責任者が変更管理書を承認し，記名押印する手続を定め，契約条件に影響する場合は３３条の変更契約を変更確定の条件としている。

変更合意では，変更する業務，対象外，報酬額又は算定方法，支払時期，作業期間又は納期，検査基準及び元の契約との関係を確定する。
必要な調査を先に行う場合は，調査の範囲，費用，上限及び調査後の継続判断を別に合意する方法も考えられる。
現場担当者が持つ権限と，契約金額や期限を変更する権限も確認する。

２　書面がない場合の判断を急がない

民法５２２条２項によれば，法令に特別の定めがある場合を除き，契約の成立に書面その他の方式は必要とされない。
したがって，変更契約書が見当たらないという理由だけで，変更合意が一切ないと結論付けることはできない。

一方，当事者が書面による変更手続を定めていた場合は，その条項と実際のメール，議事録，注文書，承認記録及び履行経過を併せて検討する。
IPAのモデルが書面手続を採用していることと，個々の契約でメールのやり取りがどのような法的意味を持つかは，別に判断する必要がある。
後から合意内容を確定できない状況を避けるため，合意した内容と着手してよい範囲を，承認者と日付を含めて記録する。

第５　協議中の作業と納期を曖昧にしない

IPAの開発モデル契約３７条４項は，変更の可否を協議している間も，特段の事情がない限り，変更要請に従前の条件での業務遂行を妨げる効力はないとする構成である。
変更協議が始まっただけで，すべての業務を中断できる，又は納期が自動的に延長されるという手続ではない。

自社の契約に従って，継続する作業，中断する作業，変更への着手を留保する作業，回答期限及び期限までに合意できなかった場合の対応を確認する。
既存の作業にも影響が生じる場合は，どの作業がどの理由で進められないか，必要な回答と期限，納期への影響及び回避策を示す。
一方から送った影響通知は，通知した事実の記録にはなるが，それだけで相手方が新しい金額や期限に同意したことを証明するものではない。

第６　合意できず中止するときの精算

１　中止の根拠を確認する

IPAの開発モデル契約３８条には，変更協議が不調に終わった場合の契約終了について，ユーザーによる解約を定めるＡ案と，一定の条件でベンダーによる解約も定めるＢ案がある。
どちらを採用したかによって手続が異なり，変更協議の不調から直ちに，どちらの当事者も自由に無償で撤退できるわけではない。

請負については，民法６４１条が，仕事の完成前に注文者が損害を賠償して解除できる旨を定める。
準委任については，同６５６条を通じて適用される同６５１条が任意解除と一定の場合の損害賠償を定める。
契約上の解約，任意解除，債務不履行解除及び合意解約を区別し，通知の要件，精算条項及び損害賠償の有無を検討する。

２　作業時間と利用できる成果を分ける

通常の有償準委任の中途終了では，民法６４８条３項の既にした履行の割合に応じた報酬が問題となる。
成果に対する報酬を約した準委任では，同６４８条の２第２項が同６３４条を準用するため，可分な部分の給付によって委託者が利益を受けるかと，その利益の割合を確認する。
請負の中途解除でも，同６３４条に基づく可分な仕事の結果と注文者の利益が問題となる。

いずれの場合も，契約上の報酬条件と精算条項を確認した上で，作業記録，納品物，承認状況及び利用できる部分を整理する。
前払金，未払報酬，中止に伴う損害及び同じ費用の重複計上を分け，作業時間だけで成果報酬の割合を決めない。
終了時には，資料とデータの返還，成果物の利用権，引継ぎの範囲及びその費用も合意する。

第７　契約審査と協議に持参する記録

記録には，変更依頼者，技術評価者，契約変更を承認する人，回答期限及び未回答時の扱いを加える。現場の技術的な了解を，追加代金や納期変更の承認として扱わない。合意した条件は締結用の本文又は別紙へ回収し，最終版の参照先も直す。修正コメントの書き方と最終確認及び契約書審査の共通手順を参照されたい。

まず，元の契約書類とその優先関係，承認済みの仕様の版，未確定事項の一覧を用意する。
次に，変更ごとの依頼，影響評価，見積り，承認，着手日及び完了確認をひも付け，どの時点で何が合意されたかを追えるようにする。
承認が未了である事項，分類が争われている事項及び納期に影響する回答待ちを別に一覧化する。

法務担当者は，変更の必要性だけでなく，費用と期限を決める権限，協議中に継続すべき業務及び中止時の精算まで確認する。
モデル条項を契約に写すだけで終わらせず，誰がどの記録を作り，いつ判断するかを実際の開発体制と対応させることが，紛争予防のための契約運用となる。

第８　関連記事と出典

①　コンサル契約で提案書だけが残ったとき―成果物，実行支援，検収，KPI及び中途解約の契約設計
②　発注確定と言われて要員を確保したのに破談になったら―個別契約の成立と交渉上の損害賠償

出典は，民法５２２条，６３４条，６４１条，６４８条，６４８条の２，６５１条及び６５６条と，IPA「情報システム・モデル取引・契約書（第二版）」の開発モデル契約２８条，２９条及び３３条から３８条並びにその解説である。
モデルの書面手続，協議中の取扱い及び終了条項を説明した部分と，その運用を具体化する確認項目として提案した部分を区別して記載した。
本記事は，個別の非公開事案又は有料資料に掲載された裁判例の事実関係を記事化したものではなく，特定の裁判例の結論を根拠とする説明はしていない。

松尾剛行『実務の落とし穴がわかる！契約書審査のゴールデンルール３０』（学陽書房，２０２４年）の，取引の実態・リスク・交渉・最終確認に関する着眼点も参照した。本稿の審査・記録方法は実務上の整理であり，法定の統一書式ではない。