システム開発の追加費用相場｜発生原因と防ぎ方

システム開発の追加費用は、小規模修正で5万〜30万円、画面・帳票の追加で20万〜200万円、外部連携やデータ構造の変更では100万〜500万円以上が一般的な目安です。ただし、当初合意との差分、影響範囲、契約形態で負担は変わります。発注前に変更管理ルールと見積内訳を決めることが最大の対策です。

追加費用そのものが問題なのではありません。事業環境の変化や利用者からの意見を受け、開発途中で仕様を変更することはあります。問題になりやすいのは、「何が当初費用に含まれ、どこからが追加なのか」を発注者と開発会社が共有していない状態です。

本記事では、システム開発の発注者に向けて、追加費用の相場、無償修正との見分け方、見積もり・契約の確認項目、追加依頼の進め方を解説します。

監修：株式会社GeekBridge 代表取締役 板橋 晟星

• システム開発の追加費用相場
  • 追加費用の内訳
  • 追加を依頼する時期でも費用は変わる
• 追加費用が発生する原因と無償修正との違い
  • 固定金額の契約でも追加費用は発生する
  • 追加費用が生じやすい典型例
• 見積もり・契約で追加費用を防ぐ確認項目
  • 発注前に確定しておきたい基準
  • 追加見積もりで確認する内訳
  • 予備費は承認ルールとセットで持つ
• 追加開発を依頼する手順と会社の見極め方
  • 追加依頼の7ステップ
  • 追加機能を削るときの判断基準
  • 追加費用の説明が信頼できる開発会社の特徴
  • 追加依頼で避けたい失敗
• まとめ
• よくある質問
  • 開発会社から追加費用を請求されたら、必ず支払う必要がありますか？
  • 請負契約なら追加費用は発生しませんか？
  • 追加費用に備えた予備費はいくら必要ですか？
  • 追加開発の調査や見積もりが有料でも問題ありませんか？

システム開発の追加費用相場

追加費用は、依頼する機能の大きさだけでなく、すでに完成した部分への影響によって決まります。同じ「入力項目を1つ増やす」という依頼でも、画面表示だけで済む場合と、データベース、帳票、検索、権限、外部連携まで変更する場合では費用が大きく異なります。

以下は、開発途中または納品前後に追加対応を外注する場合の一般的な目安です。金額は税別を想定していますが、案件の規模、品質要件、既存設計の状態、納期によって変動します。

このほか、追加機能を作る前の影響調査に5万〜50万円程度かかることがあります。既存システムの設計書がない、他社が開発したプログラムを解析する、データの状態を確認しなければ変更可否が分からない、といった場合です。

追加費用の内訳

追加開発の見積もりは、プログラムを書く作業だけではありません。一般には次の費用が含まれます。

• 仕様確認・影響範囲の調査
• 設計書や画面案の修正
• 開発・設定作業
• 単体テストや結合テスト
• プロジェクト管理と発注者への説明
• テスト環境・本番環境への反映
• 操作マニュアルや運用手順の更新
• 外部サービスの利用料やライセンス料
• 公開後の初期確認と不具合対応

発注者が見落としやすいのは、テストと既存成果物の修正です。たとえば、会員種別を追加すると、会員登録画面だけでなく、ログイン、検索、権限、請求、メール配信、管理画面にも影響する可能性があります。見た目は小さな変更でも、確認対象が広いほど費用は増えます。

追加を依頼する時期でも費用は変わる

同じ変更でも、要件定義（＝作るものを決める工程）の途中であれば、資料の修正だけで済む場合があります。開発やテストが進んだ後では、完成済みの設計・プログラム・テスト項目を作り直す必要があります。

「後で頼んでも同じ金額」とは限りません。事業上必要な変更だと分かった時点で、正式な依頼前でも開発会社へ早めに共有すると、手戻りを抑えやすくなります。

追加費用が発生する原因と無償修正との違い

追加費用の妥当性を判断するには、「当初合意した成果物を変える依頼か」「合意済みの仕様を満たすための修正か」を分ける必要があります。前者は追加費用、後者は当初費用内の是正となるのが基本ですが、実際には契約書や要件定義書の記載によって判断が変わります。

固定金額の契約でも追加費用は発生する

発注者によくある誤解は、「請負契約なら、完成するまで定額で何でも対応してもらえる」というものです。請負契約（＝合意した成果物の完成に対して報酬を支払う契約）で固定金額になっていても、契約時に合意していない機能を増やせば、追加費用が発生し得ます。

一方、開発会社から「仕様書に細部まで書かれていないため、すべて追加費用です」と言われても、そのまま承認する必要はありません。提案書、見積書、要件定義書、画面案、議事録、メール、受入条件などを確認し、当初合意の範囲を整理します。

契約形態による考え方の違いは次のとおりです。

準委任契約では、個々の変更に追加見積もりが出なくても、予定していた工数（＝作業量）を新しい依頼に使うことで、他の機能が翌月以降へずれる場合があります。金額だけでなく、何を後回しにするのかも確認してください。

追加費用が生じやすい典型例

発注のご相談を受ける立場では、次のような状況で追加費用の認識違いが起きやすいと感じます。

• 「一般的な機能は当然入っている」と考え、機能一覧に記載しなかった
• 社内の複数部署から要望が後出しされた
• 利用中の表計算ファイルや既存帳票を開発会社へ共有していなかった
• 外部システムの連携仕様や利用条件を確認していなかった
• データ移行の件数・項目・品質を調査せずに契約した
• セキュリティ、バックアップ、監査ログなどの非機能要件を後から追加した
• 経営者、現場責任者、担当者の間で完成イメージが異なっていた
• 口頭の相談が正式な追加依頼として処理されていた

すべての変更を事前に予測することは困難です。しかし、開発対象と対象外を言語化するだけでも認識違いは減らせます。発注前の整理方法は、開発スコープの決め方｜要件定義前の整理手順も参考にしてください。

見積もり・契約で追加費用を防ぐ確認項目

追加費用を完全になくすことよりも、「発生条件、金額、納期への影響を承認前に把握できる状態」を作ることが重要です。そのためには、発注時に基準となる資料と変更管理の手続きを決めます。

発注前に確定しておきたい基準

最低限、次の項目を書面で確認してください。

• 開発する機能と対象外の機能
• 対象となる画面、帳票、利用者、端末
• 対応するデータ量と同時利用者数
• 外部システムとの連携範囲
• データ移行の対象、件数、変換方法
• 発注者と開発会社の作業分担
• 発注者が素材や情報を提供する期限
• 成果物と納品形式
• 受入テスト（＝発注者が納品物を確認する試験）の項目
• 不具合と仕様変更を分ける基準
• 無償修正の対象と期間
• 追加変更の申請・見積もり・承認手順

要件定義が完了した段階では、合意済み資料をベースライン（＝変更前後を比較する基準版）として保存します。資料を上書きし続けるのではなく、版番号、更新日、変更理由、承認者を記録することが大切です。

追加見積もりで確認する内訳

「追加開発一式100万円」という見積もりでは、妥当性も削減可能な範囲も判断できません。少なくとも次の内訳を確認します。

• 変更前と変更後の仕様
• 追加・修正する画面や機能
• 影響を受ける既存機能
• 調査、設計、開発、テスト、公開の作業量
• 開発会社側の役割と人数
• 外部サービスやライセンスの費用
• 一時費用と公開後の月額費用
• 追加納期と当初計画への影響
• 見積もりに含まれない作業
• 再変更があった場合の扱い

作業量が大きい場合は、一括承認する前に「調査・設計」と「実装・テスト」を分ける方法があります。まず上限付きで調査を依頼し、その成果物を基に確定見積もりを出してもらえば、曖昧な状態のまま大きな予算を承認するリスクを抑えられます。

予備費は承認ルールとセットで持つ

開発予算には、仕様変更や調査に備えた予備費を設けます。一般的には、要件が比較的固まっている案件で開発費の10％前後、外部連携、データ移行、新規性の高い機能がある案件では10〜20％程度が一つの目安です。

ただし、予備費を最初から開発会社へ一括発注する必要はありません。社内予算として確保し、次の条件を満たした変更だけに使います。

• 事業上の必要性が説明できる
• 代替手段と比較している
• 費用と納期への影響が明示されている
• 責任者が書面で承認している
• 変更後の予算残高が更新されている

予備費は曖昧な仕様を放置するための資金ではなく、事前に確定できない変化へ対応するための資金です。

追加開発を依頼する手順と会社の見極め方

追加依頼では、すぐに実装を始めてもらうのではなく、変更内容を記録し、必要性・費用・納期を比較してから承認します。口頭で依頼すると、後から「相談だった」「発注だった」という認識違いが生まれます。

追加依頼の7ステップ

1. 変更内容を一文で定義する
   誰が、どの場面で、何をできるようにしたいのかを整理します。「使いやすくしたい」ではなく、「管理者が注文一覧をCSV形式で出力できるようにしたい」のように記載します。

2. 変更理由と優先順位を示す
   法令対応、売上への影響、業務時間の削減、利用者からの要望など、必要な理由を伝えます。理由が分かれば、開発会社から安価な代替案が出やすくなります。

3. 当初合意との差分を確認する
   要件定義書や画面案と照合し、追加機能、仕様変更、不具合のどれに当たるかを双方で整理します。

4. 影響調査と見積もりを依頼する
   費用だけでなく、既存機能、テスト、公開日、運用、月額費用への影響も提示してもらいます。調査が有料の場合は、上限金額と成果物を決めます。

5. 実装案と代替案を比較する
   完全な自動化、手作業を残した簡易対応、公開後の第2段階へ延期する案などを比較します。

6. 書面で承認してから着手する
   変更内容、金額、納期、検収条件、支払条件を記載した変更注文書や合意書を交わします。社内の承認者も一本化します。

7. テストと資料更新を行う
   追加部分だけでなく、影響を受ける既存機能も確認します。要件定義書、操作マニュアル、テスト項目、運用手順も更新します。

追加機能を削るときの判断基準

予算内に収まらない場合は、単純な値引き交渉より、範囲を分割する方が品質を維持しやすくなります。

たとえば、管理画面から複雑な集計を行う機能が高額であれば、初期段階ではデータを出力し、表計算ソフトで集計する方法もあります。運用負担と開発費を比較し、利用頻度が高まった段階で自動化する判断も現実的です。

追加費用の説明が信頼できる開発会社の特徴

追加費用が安い会社ではなく、根拠を説明し、代替案を提示できる会社を選ぶことが重要です。次の点を確認してください。

• 当初仕様と変更後仕様の差分を示している
• 影響する既存機能を具体的に説明している
• 調査・設計・開発・テストの内訳がある
• 追加しない場合の影響も説明している
• 予算に応じた縮小案や段階導入案を出している
• 金額だけでなく納期と品質への影響を示している
• 承認前に作業を進めないルールがある
• 変更履歴と最新版の資料を管理している
• 不具合修正と仕様変更を一律に扱っていない

反対に、根拠を示さず毎回「想定外」と説明する、口頭で着手して後から請求する、見積もりの質問に回答しない会社には注意が必要です。商談時の確認事項は、開発会社への質問リスト｜商談での見極め方も参考になります。

すでに追加費用が膨らみ、仕様や見積もりの整理が難しい場合は、第三者を交えて当初範囲と変更範囲を棚卸しする方法もあります。開発のご相談はこちらから、契約前の見積もり確認や進行中案件の整理についてご相談ください。

追加依頼で避けたい失敗

最後に、追加費用を増やしやすい進め方を確認しておきましょう。

• 口頭やチャットだけで発注する：正式依頼と相談を区別し、承認番号や注文書を付けます。
• 希望納期を変えずに機能だけ増やす：人員追加、品質低下、他機能の延期のいずれかが起こり得ます。
• 総額だけで承認する：作業内訳と影響範囲がなければ、削減案を検討できません。
• 社内要望をそのまま全件依頼する：事業責任者が優先順位を付けてから開発会社へ渡します。
• 追加後に資料を更新しない：次の改修や保守で旧仕様が参照され、再び認識違いが起こります。
• 不具合か仕様変更かを感情的に判断する：当初の合意資料と受入条件を基準に整理します。

追加費用について対立が生じた場合も、まずは「誰の責任か」ではなく、「当初の基準は何か」「現在の差分は何か」「公開に必要な対応は何か」を分けて協議することが重要です。契約上の解釈や損害に関する争いがある場合は、必要に応じてシステム開発契約に詳しい弁護士へ相談してください。

まとめ

• システム開発の追加費用は、軽微な変更で5万〜30万円、画面・帳票の追加で20万〜200万円、外部連携やデータ構造変更では100万〜500万円以上が一般的な目安です
• 費用は機能の見た目ではなく、設計、データ、テスト、既存機能への影響範囲で決まります
• 合意済み仕様を満たさない不具合修正と、発注者による機能追加・仕様変更は分けて扱います
• 請負契約の固定金額でも、当初合意を超える依頼には追加費用が発生し得ます
• 発注前に開発範囲、対象外、受入条件、変更管理の手順を明文化することが重要です
• 追加依頼は、差分確認、影響調査、代替案比較、書面承認、資料更新の順に進めます
• 予算が合わない場合は、値引きだけでなく、簡易対応や段階導入を検討します
• 開発会社は価格だけでなく、見積もり根拠、影響説明、代替案、変更履歴の管理方法で見極めます

よくある質問

開発会社から追加費用を請求されたら、必ず支払う必要がありますか？

必ずではありません。契約書、見積書、要件定義書、議事録などを基に、当初合意の範囲内の不具合修正か、発注者の仕様変更かを確認します。判断が割れる場合は、変更点と根拠、作業内訳を書面で提示してもらい、着手前に協議してください。

請負契約なら追加費用は発生しませんか？

請負契約でも、当初の成果物や前提条件を超える追加・変更を依頼すれば、追加費用が発生し得ます。一方、合意済み仕様を満たさない部分の是正は、原則として追加開発と分けて扱います。最終判断は個別の契約条件によります。

追加費用に備えた予備費はいくら必要ですか？

要件確定度が高い案件では開発費の10％前後、外部連携やデータ移行など不確実性が高い案件では10〜20％程度を一つの目安にします。予備費を使う条件と承認者も決め、使い切る前提にはしないことが重要です。

追加開発の調査や見積もりが有料でも問題ありませんか？

既存コードの解析、影響範囲の確認、データ調査が必要な場合は有料でも不自然ではありません。調査費の上限、成果物、調査後の概算または確定見積もりの提出条件を先に合意してください。