2026.10.15

仕様変更で追加費用が発生するのはなぜ？開発中のトラブルを防ぐ合意の取り方

システム開発の途中で「この項目を追加してほしい」「承認の流れを一段増やしたい」と依頼したところ、開発会社から追加費用の見積もりが届いて驚いた、という経験を持つ発注担当者は多いはずです。発注側からすると小さな変更に見えるのに、なぜ費用がかかるのか納得しにくいこともあります。

一方、開発会社の側にも言い分があります。契約時に合意した範囲で見積もりを出しているため、範囲の外の作業を無償で引き受け続ければ、他の作業の品質や納期に影響が出ます。追加費用の話がこじれる原因の多くは、どちらかの悪意ではなく、何が契約の範囲で何が変更なのかを、双方が同じ基準で判断できていないことにあります。

仕様変更そのものは、悪いことではありません。開発が進んで画面を見て初めて分かることもあり、業務に合わせて仕様を見直すほうが、結果として使えるシステムになることもあります。問題は、変更の扱いを決めないまま作業が進むことです。

この記事では、仕様変更で追加費用が発生する理由、変更と不具合の境目、契約形態による違い、揉めないための合意の取り方、発注側が今日から始められる予防策を解説します。

なぜ仕様変更で追加費用が発生するのか

システム開発の見積もりは、合意した仕様を作るのに必要な工数をもとに算出されています。仕様が変われば必要な工数も変わるため、増えた分の費用が発生するのが基本的な考え方です。

発注側が「小さな変更」と感じても費用がかかるのは、変更の影響が見た目以上に広がるためです。たとえば、入力画面に項目を一つ追加する場合でも、実際には次のような作業が発生します。

データベースに項目を追加し、既存のデータとの整合を取る
入力画面だけでなく、一覧画面、検索条件、帳票、データ出力に反映するかを決める
入力チェックのルールを決めて実装する
他の機能との連携や、外部システムに渡すデータへの影響を確認する
すでに終わったテストのうち、影響を受ける部分をやり直す
設計書や操作マニュアルを更新する

もう一つの理由は、変更のタイミングです。同じ変更でも、設計の段階で決まれば設計書を直すだけで済みますが、実装やテストが終わった後に決まれば、作り直しとテストのやり直しが発生します。工程が進むほど、同じ変更にかかる工数は大きくなります。

また、変更によって全体の納期が延びる場合、開発会社はその期間も人員を確保し続ける必要があります。追加費用には、変更作業そのものの工数に加えて、期間の延長による影響が含まれることもあります。

変更か不具合か、境目はどこにあるか

追加費用をめぐる話し合いで最もこじれやすいのが、発注側は「不具合だから無償で直すべき」と考え、開発会社は「仕様変更だから有償」と考えるケースです。この境目を判断する基準は、合意した仕様です。

状況	一般的な扱い	判断の拠り所
合意した仕様と違う動きをする	不具合として開発会社が修正する	仕様書、設計書
仕様どおりだが、使ってみると業務に合わない	仕様変更として費用と期間を協議する	仕様書、承認の記録
仕様書に記載がなく、どちらとも読める	個別に協議する	要件定義の議事録、メール、打ち合わせ資料
発注側の指示や提供資料に誤りがあった	原則として発注側の負担で修正する	指示の記録、提供資料

四つ目の状況については、民法にも関係する規定があります。民法第636条は、請負の目的物の不適合が注文者の提供した材料や注文者の指図によって生じた場合、注文者はそれを理由に修補などを請求できないと定めています。ただし、請負人がその指図が不適当であると知りながら告げなかった場合は除かれます。発注側の指示どおりに作られた結果の問題は、原則として発注側の負担になると考えておく必要があります。

三つ目の「どちらとも読める」状況を減らすには、仕様書の書き方が重要です。「必要に応じて」「適切に」「など」といった曖昧な表現は、発注側は広く、開発会社は狭く解釈しがちです。仕様書の確認段階で、こうした表現が残っていないかを見直しておくことが、後の追加費用の話し合いを楽にします。

発注側として押さえておきたいのは、仕様書の確認と承認が、後の判断の基準を自ら決める作業だということです。承認を急いで内容を読み込まないまま進めると、後から「業務に合わない」と気づいても、それは仕様変更として扱われることになります。承認の前に、現場の担当者にも仕様書を読んでもらう時間を確保してください。

参考：民法／e-Gov法令検索（デジタル庁）

契約形態で追加費用の扱いはどう変わるか

仕様変更に伴う費用の扱いは、契約形態によって考え方が異なります。システム開発でよく使われるのは、請負契約と準委任契約です。

契約形態	報酬の考え方	仕様変更の扱い
請負契約	仕事の完成に対して報酬を支払う（民法第632条）	完成させる対象が変わるため、変更契約で金額と納期を改める
準委任契約	作業の遂行に対して報酬を支払う	作業時間の範囲内であれば追加費用なしで優先順位を入れ替えられるが、期間や人数が増えれば費用も増える

請負契約では、契約時に完成させるものの範囲を決め、その範囲に対して金額が決まっています。範囲が変われば、変更契約を結んで金額と納期を見直すのが原則です。仕様が固まっている案件に向いている一方、開発中の変更が多いと、そのたびに見積もりと合意の手続きが必要になります。

準委任契約では、一定期間の作業に対して報酬を支払います。作業の中身を途中で入れ替えやすいため、仕様を固めながら作る案件に向いています。ただし、変更によって作業量が増えれば期間の延長や人員の追加が必要になり、総額は増えます。準委任契約だから変更が無料になるわけではなく、費用の増え方が見えにくくなる点に注意が必要です。

判断の目安としては、仕様が固まっていて変更が少ない見込みなら請負、要件を詰めながら進める必要があるなら準委任、という使い分けになります。工程ごとに契約を分け、要件定義は準委任、仕様が確定した後の開発は請負とする組み合わせも一般的です。

法律の規制がかかる取引かを確認する

発注側と開発会社の規模の組み合わせによっては、法律上の規制にも注意が必要です。2026年1月に施行された中小受託取引適正化法（取適法）は、プログラムの作成委託について、中小受託事業者の責任がないのに発注内容を変更したり、無償でやり直しや追加作業をさせたりすることを禁止しています。公正取引委員会の資料によると、プログラム作成の委託では、資本金3億円超の会社が資本金3億円以下の会社に委託する場合、資本金1千万円超3億円以下の会社が資本金1千万円以下の会社に委託する場合、従業員300人超の会社が従業員300人以下の会社に委託する場合などが対象です。中小企業同士の取引でも、資本金の組み合わせによっては対象になりえます。

また、個人のフリーランスに委託する場合は、2024年11月に施行されたフリーランス・事業者間取引適正化等法の対象になります。いずれの場合も、変更に伴う費用を相手に負担させない形で合意しておくことが、法令上も実務上も安全です。自社の取引が対象かどうかは、公正取引委員会の資料で確認してください。

参考：取適法（中小受託取引適正化法）リーフレット／公正取引委員会

参考：フリーランス・事業者間取引適正化等法（リーフレット）／公正取引委員会

揉めないための合意の取り方

仕様変更のトラブルを防ぐには、変更が出たときにどう扱うかの手順を、開発が始まる前に決めておくことが最も効果的です。IPAと経済産業省が公開している「情報システム・モデル取引・契約書」（第二版）では、変更を提案する側が変更提案書を出し、受け取った側が変更の内容、費用、スケジュール、契約条件への影響などを記載した変更管理書を作成して協議する手順が示されています。双方の責任者が承認して初めて変更が確定し、金額や納期に影響する場合は変更契約を結ぶ流れです。

このモデルを参考に、中小規模の開発でも使える形に整理すると、次の手順になります。

変更の依頼は、口頭ではなく決まった書式で出す（メールでもよいが、件名や書式を統一する）
開発会社は、変更の内容、理由、影響範囲、追加費用、スケジュールへの影響を回答する
発注側は、変更する、変更しない、次の段階に回す、のいずれかを判断する
双方の責任者が承認した内容を記録し、費用や納期が変わる場合は書面で合意する
承認された変更の一覧を、定例の打ち合わせで双方が確認する

この手順で重要なのは、承認されるまで変更の作業を始めないことです。現場の担当者同士で「ついでにやっておきます」と進めた作業が、後から費用の請求や納期の遅れとして表面化するケースは少なくありません。発注側の担当者も、開発者に直接変更を依頼せず、決まった窓口を通すようにします。

また、変更を判断するときは、今回のリリースに入れる必要があるかどうかを必ず検討します。業務の開始に必須でない変更は、リリース後の改修に回すことで、当初の納期と予算を守りやすくなります。変更の一覧に「今回対応」「次回以降」の区分をつけて管理すると、判断の経緯が残ります。

追加費用の見積もりを受け取ったときの見方

変更に対する追加費用の見積もりを受け取ったら、金額だけでなく、その根拠を確認します。確認したいのは、影響を受ける機能や画面の範囲、作業の内訳（設計、実装、テスト、資料の更新）、納期への影響の三つです。影響範囲が具体的に示されていれば、発注側も「この帳票には反映しなくてよい」「データ出力は次回でよい」といった形で範囲を絞り込み、費用を調整できます。

反対に、「一式」で金額だけが示されている場合は、内訳の提示を依頼してください。内訳を見ると、発注側が想定していなかった作業が含まれていることに気づく場合もあれば、変更の範囲を誤解していたことが分かる場合もあります。いずれにしても、根拠を見たうえで判断すれば、後から不満が残りにくくなります。追加作業の単価を契約時に決めておけば、こうした見積もりの妥当性も確認しやすくなります。

参考：情報システム・モデル取引・契約書（第二版）／IPA（情報処理推進機構）

発注側が今日から始められる予防策

仕様変更をゼロにすることはできませんが、後半の大きな変更を減らすことはできます。発注側が取り組める予防策を、開発の段階ごとに整理します。

段階	予防策
発注前	システムで実現したい業務の流れと例外を、現場の担当者と一緒に書き出す。決まっていない事項を一覧にしておく
契約時	変更の手続き、追加作業の単価、変更の判断者を契約書や覚書で決める
要件定義・設計	画面イメージや試作品を見て確認する。曖昧な表現が仕様書に残っていないかを確認する
開発中	途中段階の画面を定期的に見せてもらい、早い段階で違和感を伝える
テスト前	変更の一覧と承認の記録を双方で照合する

特に効果が大きいのは、発注前の準備と、開発中に画面を確認する機会を設けることです。文書だけで仕様を確認すると、実際の画面を見たときに初めて違和感に気づき、後半の大きな変更につながります。設計の段階で画面のモックアップを作ってもらう、開発の途中で動く画面を見せてもらうといった機会を、スケジュールにあらかじめ組み込んでおきます。

また、社内で変更の判断者を一人に決めておくことも重要です。複数の部署から別々に要望が出ると、開発会社はどれを優先すべきか分からず、発注側の中でも合意が取れていない変更が積み重なります。社内の要望を集約し、優先順位をつけてから開発会社に伝える役割を誰が担うのかを、発注前に決めてください。

まとめ

仕様変更で追加費用が発生するのは、見積もりが合意した仕様を前提に算出されており、変更の影響が見た目以上に広がるためです。変更のタイミングが遅いほど、作り直しとテストのやり直しで費用は大きくなります。

トラブルを防ぐために押さえておきたい点は次のとおりです。

変更か不具合かは、合意した仕様書と記録で判断するため、要件定義の議事録や承認の記録を残しておく
仕様が固まっているなら請負、詰めながら進めるなら準委任と、契約形態を案件に合わせて選ぶ
変更の依頼、影響の回答、判断、承認の手順を開発前に決め、承認前に作業を始めない
リリースに必須でない変更は、次の段階に回す選択肢を常に検討する

開発がすでに進んでいる場合は、これまでに出した変更の依頼を一覧にし、それぞれが承認済みか、費用や納期への影響が合意されているかを開発会社と確認するところから始めてください。これから発注する場合は、契約書案に変更の手続きが書かれているかを確認し、書かれていなければ覚書などで追加することを開発会社に相談してみてください。