仕様変更対応の費用は、変更規模や保守範囲、契約形態で大きく変わります。月額保守費用は12万〜17万円程度が目安で、中規模の機能追加に2人月かかる場合は150万円前後です。
費用の分かれ目は、保守の範囲内か別途制作かです。全体像は、ITシステム仕様変更対応の完全ガイドもご覧ください。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム仕様変更対応の費用全体像と相場
仕様変更対応の費用は、変更の規模や内容、契約形態によって決まります。同じ改修でも、保守の範囲に入るか別途見積になるかで、金額は大きく変わります。
費用は大きく、月額保守費用と、保守範囲外の別途制作費用の二つに分かれます。この構造をつかまないまま見積を受け取ると、見積に出てきた追加費用が妥当かどうかを判断できません。
月額保守費用に含まれる仕様変更の範囲
月額保守に含まれる範囲は、軽微な改修かどうかを基準に見ていきます。発注側は契約の前に、どこまでが保守内かを開発会社と擦り合わせておきます。
- 対象：根本構造に手を入れない小規模な変更
- 扱い：改修枠内なら追加費用は発生しない
- 確認点：契約書に書かれた月あたりの対応時間
月額保守費用は、初期開発費の年間5〜20%が目安です。業界標準は15〜20%で、1,000万円の開発なら年150万〜200万円になります。これを月額に直すと、12万〜17万円程度が相場です。
月額費用の内訳では、定期保守・メンテナンスが20〜30%、障害対応が25〜35%です。軽微な改修・改善は、10〜15%が標準的です。
文言の修正やボタンの配置、入力チェックは、軽微な改修に当たります。また、帳票レイアウトの微修正も、軽微な改修の範囲に入ります。月額保守には一定の改修工数が含まれているため、その枠内に収まる作業なら別料金は発生しません。
ただし、改修枠が「月◯時間まで」のように契約書へ明記されているかは、必ず確認しておきます。枠が不明確なままだと、ベンダーの判断で枠外とされ、追加費用が発生することがあります。
別途見積になる仕様変更の費用構造
根本修正を伴う変更は、保守範囲外の別途制作として扱われます。
- 新機能：新しい画面・帳票・機能の追加
- 構造変更：データベース構造の変更
- 新規連携：外部システムとの新たな連携
- 大幅改修：デザインやUI/UXの大きな変更
別途制作の費用は、月額保守費用とは切り離したうえで、工数積算によって算出するのが一般的です。
フリーランスやSESエンジニアの単価は、月70万〜76万円前後が中心です。一方で、上流工程を担うITコンサルやPMクラスでは、最高で月295万円の水準もあります。
中規模の機能追加に2人月かかる場合、単価75万円なら150万円前後が目安になります。ここでいう2人月とは、エンジニア2人が1か月、または1人が2か月稼働する工数のことです。
設計書の改訂やテストは、付帯コストとして費用に含まれます。リリースや変更管理の文書整備も、同じように上乗せされます。そのため、見積が機能開発費の1.5倍前後になることも珍しくありません。
「保守内か別途見積か」を判定する境界線の早見表
費用のトラブルは、保守の範囲に含まれると思っていた変更が別料金になっていた、という認識のズレから起きることが多いです。そこで、代表的なケースを保守内と別途見積に分けて判定しておきます。
ケース別の判定早見表
代表的な仕様変更は、根本構造への影響の大きさと作業範囲で分類できます。
- 画面調整：文言・ラベル、ボタンの色や配置の変更は保守内
- 入力・帳票：軽微な修正は保守内の改修枠に収まる
- 保守作業：OSやミドルウェアのパッチ対応は保守内
- 法改正：計算ロジックの変更は規模により別途見積
- 根本改修：新規開発、DB変更、API連携、大幅なUI/UX変更は別途見積
判定の基本は、プログラムの根本構造に手を入れるかどうかです。表示や値の調整であれば保守内に収まり、新たなロジックやデータ構造を作る変更であれば別途見積になります。
判断が分かれるグレーゾーンの扱い方
法改正やOSのメジャーアップデートに起因する不具合修正は、保守内か別途かの判断が分かれやすい変更です。
- 軽微修正：計算ロジックの軽微な変更は、保守内に入ることが多い
- 根本改修：帳票や集計を変えるインボイス対応は、別途見積の対象
契約書や保守仕様書に範囲を明記しておかないと、同じ変更でも発注側と開発会社の見方がずれ、請求の段階で食い違いが出やすくなります。また、OSの更新やブラウザの変更で生じた不具合の費用負担も、契約前に取り決めておくのが望ましいです。
迷う変更は、保守内か別途見積かと、別途の場合の概算工数を文書で確認しておくのが確実です。口頭だけで進めると、後から想定外の請求が届くおそれがあります。
仕様変更費用の算出方法と見積の読み解き方
別途見積の費用は、いくつかの算出手法で計算されます。算出方法の違いを知っておくと、提示された金額が妥当かどうかを評価しやすくなります。
工数積算・開発費ベース・機能ポイント法
代表的な算出方法は、何を基準に計算するかで分かれます。
- 工数積算：変更にかかる時間（人月・人日）に単価を掛けたもの
- 開発費ベース：初期開発費の何%相当かによる概算
- 機能ポイント法：機能の複雑さを数値化し、大規模な変更で使う
見積書が、設計や開発、テストなどの工程ごとに分かれているかを確認しておきます。一式でまとめられた見積では、テストや文書整備が後から追加される余地が残ります。一方で、フェーズごとの工数と単価が書かれた見積は透明性が高く、複数社の比較にも使いやすいです。
隠れコストと過剰請求の見抜き方
仕様変更の見積には、開発費として見えている部分の外に、隠れコストが含まれることがあります。
- 時間外対応：休日を含む時間外の作業に上乗せされる割増分
- 緊急対応：緊急時に発生するスポット料金
- 再テスト：変更に伴う既存テストの再実施にかかる費用
- SESマージン：中間に入る会社が乗せるマージン
SESの企業側マージン率は平均35〜40%、エンジニアへの還元率は約60%です。そのため、同じ作業でも発注側の負担額は、商流の段数によって変わってきます。
軽微な改修の割合が10〜15%の目安を大きく超える場合は、内訳を精査する必要があります。保守内の軽微な変更が続けて別途見積になっているなら、請求の根拠を確かめることが欠かせません。
内訳を精査して見直した例として、ある事例では未利用サービスを見つけたことで、月額28万円を20万円に28.6%削減できました。年間では96万円の削減になっています。
費用は、単価と工数を掛け合わせた総コストで評価するのが基本です。
変更管理で費用を膨らませないための運用ルール
費用を膨らませる最大の要因は、仕様変更の積み重ねを管理しないことです。変更管理（チェンジマネジメント）を決まった手順にまとめておくと、追加費用が見えるようになります。また、スコープクリープ（要件が際限なく膨らむこと）を防ぐ効果もあるため、運用ルールとして欠かせません。
変更要求の起票と影響評価のフォーマット
仕様変更は、口頭やメールのやり取りだけで進めず、変更要求書（チェンジリクエスト）に起票しておきます。
- 理由・目的：変更の背景を書く
- 影響範囲：影響を受ける機能の範囲
- 工数・コスト：想定する作業量と費用
- 未実施のリスク：変更しない場合のリスク
変更しない場合のリスクを書いておくと、その変更が本当に必要かを判断しやすくなります。不要な改修を抑えられるため、費用増の防止にもつながります。
影響評価では、ほかの機能や既存データにどこまで波及するかを、事前に洗い出しておきます。設計書やソースコードのバージョンは、まとめて管理し、変更の理由と履歴をたどれる状態にします。
どの変更がどの費用に当たるかが明確になり、見積の中身も検証できるようになります。この仕組みが整っているベンダーは、追加費用の根拠を示せるため、発注側にとって安心材料になります。
請負契約と準委任契約による費用構造の違い
仕様変更対応の費用は、請負契約か準委任契約かで性質が変わります。
- 請負契約：完成の形が明確で、仕様が固まった変更の場合
- 準委任契約：変更が多く、柔軟性を重視する場合
請負契約には、仕事を完成させる義務と、契約不適合責任（瑕疵担保）が伴います。一度きりで完了する変更には向いていますが、変更のたびに再見積と再契約が必要です。特に、要件が頻繁に変わる場合は、その手間とコストが積み重なっていきます。
準委任契約は、善管注意義務に基づいて作業を進めるため、変更にも柔軟に対応できます。仕様変更が継続的に発生するシステムでは、準委任が向いているケースが多いです。
準委任では、月額や時間単位で工数を確保し、その枠の中で変更に対応する形になります。費用は「確保した工数の単価×期間」で見通しを立てられます。
ただし、準委任では作業の完成までは保証されないため、合意形成と進捗管理が費用対効果を左右します。
仕様変更費用の税務・会計処理（修繕費と資本的支出）
仕様変更費用は、会計処理の仕方によって、その期の損益やキャッシュフローへの影響が変わります。そのため、修繕費と資本的支出の区別は、費用の総額を管理するうえで大切な視点になります。この点は、発注側の情報システム部門や経理担当が見落としやすい論点でもあります。
修繕費として費用処理できる仕様変更
仕様変更費用の税務上の処理は、目的が現状維持か機能向上かで分かれます。
- 修繕費：バグの除去や障害の修正など、現状維持のための対応
- 資本的支出：新機能の追加や性能向上
修繕費は支出した期の費用として計上でき、全額を損金に算入できます。そのため、その期の税負担を軽くできます。
資本的支出に当たる変更は、ソフトウェアの取得価額に加算して資産計上し、耐用年数にわたって減価償却します。発注の段階から処理の違いを押さえておけば、予算計画に反映できます。
「既存部分の除却」という会計視点
資本的支出として処理する場合は、既存部分の除却についても検討します。
- 対象：作り直しで使われなくなる既存機能
- 処理：既存の資産計上部分を除却できる可能性
- 前提：具体的な処理は税理士などへの相談
大幅な仕様変更で古い機能を作り直すと、その機能は実質的に使われなくなります。建物の一部を壊して建て替えるのに近い考え方です。
新しい機能は資産計上し、置き換えた既存部分は除却として捉えられる可能性があります。改修の実態に応じて費用処理の余地を探れる点は、CFOや情報システム部門にとって有効です。
処理の判断は改修の内容と既存機能の扱いで変わるため、発注前に整理しておくのが望ましいです。この論点を知っておくことは、トータルコストの適正化にもつながります。
仕様変更コストを適正化する実践アプローチ
仕様変更対応のコストは、依頼の仕方と運用の工夫で抑えられます。また、費用が高止まりしている場合も、構造を理解すれば改善の余地があります。
内訳の可視化と相見積もりによる適正化
費用の適正化は、いまの保守費用と仕様変更費用の内訳を一覧にすることから始まります。
- 内訳確認：未利用サービスや過剰な項目の洗い出し
- 相見積もり：工数や保証範囲をそろえた比較
- 契約見直し：継続依頼での費用の定期的な交渉
月額28万円を20万円に28.6%削減できた事例もあります。平均や合計だけでなく、作業量のばらつきも見ておくことが大切です。
大きな変更では、総額だけでなく、テストと保守の有無も含めて比べます。そのうえで、自社の要件に照らして確認すると、総コストで発注先を選べます。
標準化・自動化による工数削減
手作業が多いことと、システムがブラックボックス化していることは、費用が高止まりする原因になります。
- 文書整備：設計書とドキュメントの整理
- 定型作業：バックアップなどのスクリプト化
- 運用移管：クラウドの利用
文書がないと、ベンダーは変更のたびに既存の仕様を調べ直すことになります。そのため、調査工数が費用に上乗せされ、仕様変更1件あたりのコストを押し上げます。設計書やソースコードをまとめて管理し、特定の人しか分からない状態をなくすことが、コスト削減の出発点になります。
バックアップやログ削除、再起動といった定型作業を自動化すると、手作業を減らせます。さらに、デプロイも自動化の対象になります。
OSやミドルウェアの保守を事業者に任せれば、保守工数も軽減できます。変更を反映する運用作業まで含めて見直すと、トータルコストを削減できます。
riplaでは、コンサルティングから開発、運用まで一貫して支援できます。仕様変更の費用構造を整理するところから、変更管理の仕組みづくりまでサポートしています。費用の適正化で悩んでいる場合は、お気軽にご相談ください。
ITシステム仕様変更対応の関連情報
費用以外にも、変更対応の進め方や発注方法、変更管理や契約形態の選び方など、あわせて理解しておきたいテーマがあります。発注の失敗を抑えるには、こうした周辺の情報も一緒に押さえておくと効果的です。
あわせて読みたい関連記事
関連情報は、進め方、発注先、外注方法、全体像の4テーマに分けて、下の記事で確認できます。
- ITシステム仕様変更対応の進め方/やり方/流れや方法/手法/工程/手順：変更要求の起票から、影響評価、承認、反映までの流れを詳しく解説
- ITシステム仕様変更対応でおすすめの開発会社/ベンダー6選と選び方：変更管理プロセスや準委任の柔軟性で比較する視点
- ITシステム仕様変更対応の発注/外注/依頼/委託方法について：発注の進め方や契約形態の選び方
- ITシステム仕様変更対応の完全ガイド：進め方、費用、発注方法をまとめて把握
費用の検討と並行して読んでおくと、見積を比べる際の観点が増えます。
まとめ
仕様変更対応の費用は、月額保守の範囲内にある軽微な改修と、保守範囲外の別途制作に分かれます。月額保守費用は初期開発費の年間5〜20%が相場で、内訳は定期保守20〜30%、障害対応25〜35%、軽微改修10〜15%が標準です。
文言修正や軽微な調整は保守内に収まり、新機能追加やデータ構造の変更は別途見積になります。別途見積は、工数積算、開発費ベース、機能ポイント法のいずれかで算出されます。
見積書は、フェーズごとの内訳を確かめたうえで、隠れコストを含む総額で評価することが大切です。変更管理や契約形態、修繕費と資本的支出の違いを理解しておくことも、費用の適正化に役立ちます。
未利用サービスの見直しで28.6%削減した事例もあります。本記事の判断の目安を使って、納得のいく仕様変更対応を進めてください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。