追加開発と仕様変更の違い｜受託開発で見積もり直しになる判断基準

受託開発では、かなりの確率で「これは追加費用ですか？」「このくらいなら仕様変更で対応できますか？」という話が出ます。
最初の見積もりどおりに全部進む案件の方が、むしろ珍しいかもしれません。

問題は、追加開発と仕様変更の言葉が曖昧なまま進むことです。
クライアント側は「少し直すだけ」と感じていても、開発側から見るとデータ構造、画面、テスト、運用手順まで変わることがあります。逆に、開発側が何でも追加費用に見せると、信頼を失います。

この記事では、受託開発で追加開発と仕様変更をどう分けるか、どこから見積もり直しにするか、クライアントへどう説明すると揉めにくいかを整理します。
納品後の保守費用との違いまで見たい場合は、受託開発の保守費用をどう説明する？範囲・金額・契約の決め方 もあわせて読むとつながりやすいです。 変更管理より前に、そもそも何を要件定義で決めておくべきかを整理したい場合は、要件定義で最低限決めることは？受託開発であとから揉めやすい項目を整理 も近い論点です。

この記事では、2026年4月21日時点でIPAの情報システム開発向け契約書（第二版）とアジャイル開発版の公開情報を確認しながら、受託開発で使いやすい実務上の判断基準として整理しています。個別契約の法的判断は、契約書と専門家確認を優先してください。

まず言葉を分ける

追加開発と仕様変更は、似ていますが見ている場所が少し違います。

大事なのは、「追加開発か仕様変更か」という名前だけで費用を決めないことです。
実際には、合意済みの範囲から外れるか、影響範囲が広がるか、検収条件が変わるかで見ます。

見積もり直しになる判断基準

見積もり直しになるかどうかは、作業時間だけでは決まりません。
たとえ実装自体が1時間でも、仕様の責任範囲やテスト範囲が変わるなら、見積もりや納期の見直し対象になります。

判断しやすいように、次の観点で見ると整理しやすいです。

このどれかに当てはまるなら、「いったん影響を確認して、見積もりとスケジュールを出し直します」と言ってよい場面です。
逆に、文言だけ、配置だけ、合意済み仕様内の軽微な調整だけなら、都度見積もりにせず既存範囲で吸収する判断もあります。

追加開発になりやすい例

追加開発は、比較的説明しやすいです。
「最初の見積もりに入っていなかったものが増えた」からです。

よくある例です。

• 管理画面を追加したい
• CSV出力を追加したい
• LINE通知やSlack通知を追加したい
• 会員ランク機能を追加したい
• 複数店舗対応にしたい
• 決済手段を増やしたい
• 外部API連携を追加したい
• 予約、請求、在庫、承認などの業務機能を増やしたい

この場合は、クライアント側も追加費用を理解しやすいことが多いです。
ただし「小さなボタンを1つ足すだけ」に見えても、裏側では権限、データ、通知、テストが増えることがあります。

たとえば、CSV出力の追加は簡単そうに見えます。
しかし実際には、出力項目、文字コード、権限、個人情報の扱い、ダウンロードログ、件数が多い場合の負荷、Excelで文字化けしないかまで見る必要があります。表面のUIだけで見積もると危険です。

仕様変更になりやすい例

仕様変更は、追加開発より揉めやすいです。
なぜなら、クライアント側から見ると「作るものは同じで、少し動きを変えるだけ」に見えるからです。

よくある例です。

• 申請フローを「上長承認」から「部署長と経理の二段階承認」に変える
• 注文キャンセルの期限を、日付基準から発送状態基準に変える
• 料金計算を税込固定から税率別・割引別に変える
• 管理者だけ見られる予定だった情報を、店舗担当者にも見せる
• 単一拠点前提だった画面を、複数拠点対応にする
• 一覧の検索条件を増やし、並び順や絞り込みの意味を変える
• 既存データを新しいルールへ変換する必要が出る

仕様変更で見落としやすいのは、すでに作った部分のやり直しです。
新規に作るより、途中から変える方が重いこともあります。コードだけでなく、設計、テスト、説明、検収の前提が変わるからです。

軽微修正として扱いやすいもの

何でも見積もり直しにすると、プロジェクトは進みにくくなります。
軽微修正として扱いやすいものもあります。

• 誤字脱字の修正
• ボタン文言の変更
• 余白や色の小さな調整
• 合意済み項目の表示順変更
• バリデーション文言の調整
• 合意済み仕様どおりに動いていない箇所の修正

ただし、軽微かどうかは「作業が簡単そうか」ではなく、「合意済み仕様の範囲内か」「他の箇所に影響しないか」で見ます。

たとえば、ボタン文言の変更は軽微に見えます。
でも「仮予約」を「予約確定」に変える場合、業務上の意味が変わるなら軽微ではありません。表示文言の変更に見えて、契約や業務フローの変更になることがあります。

判断に迷ったときの5つの質問

追加費用にするか迷ったら、次の5つを確認します。

1. 最初の見積もり、要件定義、議事録、チケットに入っていたか
2. 画面、DB、API、権限、通知、帳票、テストのどれかが変わるか
3. 既に作ったものを作り直す必要があるか
4. 納期を変えずに対応すると、品質確認の時間が削られるか
5. この変更を無料で受けると、次も同じ扱いだと期待されるか

このうち複数に当てはまるなら、見積もり直しを検討した方がよいです。
特に5つ目は大事です。一度「これくらい無料で大丈夫です」と言うと、次から境界線が下がります。

変更依頼を受けたときの進め方

変更依頼が来たら、すぐに「できます」「無料です」「追加費用です」と返さない方が安全です。
まず影響を確認します。

おすすめの流れは次の通りです。

1. 依頼内容をその場で言い換えて確認する
2. 現在の合意範囲に含まれるか確認する
3. 影響する画面、データ、連携、テストを洗い出す
4. 軽微修正、仕様変更、追加開発、不具合修正に仮分類する
5. 費用、納期、検収条件への影響を出す
6. 対応するか、次フェーズに回すかを合意する
7. チケット、議事録、メールなどに残す

ここで重要なのは、影響調査自体にも時間がかかる場合があることです。
大きな変更なら、「調査費用」「調査期間」「調査後に正式見積もり」という段階に分けた方が誠実です。

クライアントへの説明例

言い方を間違えると、正しい追加見積もりでも角が立ちます。
「それは契約外です」とだけ返すより、何が変わるのかを具体的に伝える方が納得されやすいです。

追加開発として説明する例

ご依頼のCSV出力機能は、当初のお見積り範囲には含まれていない新規機能になります。
出力項目、権限、文字コード、ダウンロード時の負荷確認が必要になるため、追加開発として別途お見積りします。

仕様変更として説明する例

承認フローを一段階から二段階に変更する場合、画面表示だけでなく、承認状態、通知、権限、既存データの扱いが変わります。
既存設計への影響があるため、仕様変更として影響範囲を確認したうえで、費用とスケジュールを再提示します。

軽微修正として受ける例

ボタン文言の変更は、既存仕様の範囲内で他機能への影響も小さいため、今回の修正範囲で対応します。
ただし、文言変更により業務上の意味が変わる場合は、仕様確認の対象とさせてください。

ポイントは、費用の話をする前に「影響範囲」を説明することです。
相手が納得できないのは金額そのものより、「なぜそれが別費用なのか」が見えていないときです。

契約書や見積書に入れておきたい文言

小規模案件でも、変更管理の文言は入れておく方が安全です。
厳しい文章にする必要はありませんが、境界線がないと後で苦しくなります。

たとえば、見積書や提案書には次のような考え方を入れます。

本見積もりは、提案書・要件一覧・画面一覧に記載した範囲を対象とします。
記載のない新機能、業務フロー変更、外部サービス連携、データ移行、
既存仕様の変更、検収条件の変更は、影響確認のうえ別途お見積りとなります。

仕様変更が発生した場合は、費用、納期、品質確認範囲への影響を確認し、
双方合意のうえ対応します。

契約書では、変更管理の手続き、検収条件、成果物、役割分担、協力義務などを決めます。
IPAの情報システム開発向け契約書（第二版）でも、契約のタイミングで仕様、プロジェクト管理方法、検収方法などを共通理解のもとで対話することが重視されています。

アジャイル開発なら無料で変更できる、ではない

アジャイル開発では、途中で優先順位や内容を調整しながら進めます。
そのため「アジャイルなら仕様変更は無料で柔軟にできる」と誤解されることがあります。

これは危険です。
アジャイルでも、予算、期間、体制、優先順位、完了条件は必要です。変更を入れるなら、代わりに何を後ろへ回すのか、何をやめるのかを決めます。

ウォーターフォール型では、合意済み仕様から外れる変更は見積もり直しになりやすいです。
アジャイル型では、同じ予算と期間の中でバックログの優先順位を入れ替える、またはチーム稼働期間を追加する、という整理になりやすいです。

どちらの場合も、「変更できる」と「無料で何でも増やせる」は違います。

よくある失敗

口頭で受けてしまう

打ち合わせ中に「それくらいならやっておきます」と言ってしまうと、あとで範囲が曖昧になります。
軽微な内容でも、チケットや議事録に残します。

見積もりの前提を書いていない

見積書に画面数、機能数、対象データ、連携範囲、テスト範囲が書かれていないと、何が範囲外なのか説明しづらくなります。
金額だけの見積もりは、変更管理に弱いです。

不具合修正と仕様変更が混ざる

合意済み仕様どおりに動いていないなら不具合修正です。
しかし、合意後に「やっぱりこうしたい」と変えるなら仕様変更です。ここを混ぜると、どちらかが不満を抱えます。

納期だけ固定して作業を増やす

費用を増やせない、納期も延ばせない、でも変更は入れたい。
この状態をそのまま受けると、テスト時間や品質確認が削られます。結果的に納品後の不具合や保守負担が増えます。

実務で使える変更管理メモ

変更依頼を受けたら、最低限これだけ残すと後で助かります。

これは大げさな契約管理ではなく、プロジェクトを守るためのメモです。
発注側にとっても、なぜ費用が増えたのか、なぜ納期が変わったのかを社内説明しやすくなります。

まとめ

追加開発と仕様変更の違いは、言葉だけで決めるより、合意済み範囲から何が変わるかで判断する方が現実的です。
新しい機能や対象を足すなら追加開発。合意済みの動き、条件、前提、成果物を変えるなら仕様変更。合意済み仕様どおりに動いていないなら不具合修正です。

見積もり直しにするかは、要件、画面、データ、外部連携、テスト、納期、責任範囲への影響で見ます。
小さく見える変更でも、裏側で影響が広がるなら、影響調査と再見積もりを出す方が誠実です。

受託開発で大事なのは、追加費用を取ること自体ではありません。
変更が起きたときに、何が変わり、費用と納期と品質にどう影響するのかを、発注側と受注側が同じ紙の上で見られる状態にすることです。

参考リンク

• IPA: 情報システム開発向け契約書（第二版）公開ページ
• IPA: アジャイル開発版の契約書公開ページ
• IPA: 契約書見直しのポイント