ITシステム軽微改修の費用は、1.5万円〜20万円程度の幅で変わります。その差を生むのは、保守契約の有無、改修範囲、担当者の単価の3つです。同じ作業でも、保守契約の枠内で処理するか別途見積にするかで、金額は大きく変わります。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
ITシステム軽微改修の費用相場と保守費全体での位置づけ
軽微改修の費用は、単独の金額で決まるというより、月額保守契約の枠内で決まることが多くあります。そのため相場を知るには、保守費全体の構造と、そのなかで軽微改修が占める割合を見る必要があります。
保守費全体に占める軽微改修の割合（10〜15%）
月額保守費は、初期開発費を基準にした年間契約として設定されるのが一般的です。保守費の内訳の中心となるのは、次の3つの作業です。
- 定期保守・メンテナンス：安定稼働を保つための定例作業
- 障害対応：障害や不具合への対応
- 軽微な改修・改善：小規模な変更や改善に充てる作業
月額保守費は、業界の一般的な目安として、初期開発費の年間15〜20%程度です。
たとえば1,000万円で構築したシステムなら、年間150〜200万円となり、月額にすると12〜17万円前後の保守費に相当します。
標準的な内訳では、定期保守・メンテナンスが20〜30%、障害対応が25〜35%です。一方、軽微な改修・改善は、10〜15%が一つの目安になります。
残りは問い合わせ対応、ドキュメント更新、監視などに充てられます。
たとえば月額15万円の保守契約なら、軽微改修の枠は1.5万円から2.3万円程度です。
この割合は、保守費の内訳が適正かを判断する基準になります。軽微改修が保守費の半分近くを占めるなら、仕様変更が含まれている可能性があります。
本来は追加開発に分類すべき作業が、軽微改修として計上されていることもあります。
単価ベースで見た軽微改修の費用感
保守枠とは別にスポットで発注する場合、費用は単価と作業工数の掛け算で決まります。作業の種類によって工数の重さは大きく違うため、その差がわかりやすい代表的な作業を3つ挙げます。
- 文言修正：画面の表示や文言の調整
- 帳票改修：出力される項目の追加
- マスタ拡張：項目数を増やす対応
フリーランスやSESエンジニアの開発系単価は、月70〜76万円前後が中心です。人日に換算すると、1人日あたり3.5万円から4万円前後が目安になります。画面の文言修正や表示調整は0.5〜1人日ほど、帳票への項目追加やマスタの項目拡張は2〜5人日ほどが目安です。
この工数に単価を掛けると、単純計算では文言修正が2万円前後、帳票改修が7万円から20万円程度になります。ただし、見積によっては、テストやリリース、ドキュメント更新が含まれていない場合があります。
提示された金額は、そのまま実費とは限りません。内訳を見て、どの作業にどれだけの工数がかかっているかを確かめることが大切です。
上流工程を担うITコンサルやプロジェクトマネージャーは、月295万円に達することもあります。担当者の職位や生産性しだいで、同じ作業でも費用が数倍に変わることがあります。そのため、見積の判断では単価の安さに加えて、総工数を抑えられる体制かどうかを見ることが重要です。
軽微改修の見積を算出する2つの手法
見積の妥当性を判断するには、ベンダーがどの手法で金額を算出したかを知る必要があります。
代表的な手法は工数積算法と機能ポイント法の2つで、改修内容に応じて使い分けると、金額の根拠を確認しやすくなります。
工数積算法による見積の組み立て方
工数積算法は、作業を工程ごとに分けて、人日と単価から費用を算出する手法です。工程に分けておくと、見積にどの作業が入っていて、どれが抜けているかを、次の6つの工程で確かめやすくなります。
- 影響調査
- 設計
- 実装
- 単体テスト
- リリース
- ドキュメント更新
軽微改修であっても複数の工程が発生するため、漏れなく洗い出しておくことが正確な見積の前提になります。
発注者は、提示された工数に実装以外の工程が含まれているかを確かめる必要があります。実装だけが0.5人日で示され、テストやリリースは後から別請求されるケースもあります。
改修では、実装よりもテストや影響範囲の確認に時間がかかることがあります。たとえば実装が0.5人日であっても、テストやリリースに1人日以上必要になる場合があります。
見積を受け取ったら、工程ごとの内訳と工数が妥当かを確かめることが重要です。工程に分けられた見積であれば、無駄や過小評価を見つけて交渉の材料にできます。一方、総額だけの見積では、想定外の作業を理由に追加費用が発生する余地が残ります。
機能ポイント法による複雑さの数値化
機能ポイント法は、影響を受ける機能の数や複雑さを数値にして、工数や費用を算出する手法です。評価の対象は次の3つです。
- 入力項目：追加する項目の数
- 画面：追加や変更の複雑さ
- データ連携：データベースの参照や更新
各要素に重みを付けて合計すると、その改修のポイントが求まり、工数や費用の算出につなげられます。担当者の勘に頼りきらず、同じ基準で見積を組める点が特徴です。
見た目は小さくても内部の影響範囲が広い改修を、適切に評価できます。実際に、画面に項目を1つ追加するだけでも、複数のテーブルに連動する場合があります。帳票やバッチ処理、外部連携に影響すれば、機能ポイントは大きくなります。
表示だけの単純な改修であればポイントは小さくなり、過大な見積を防ぐ根拠になります。見た目の軽さと実際の作業量のずれを、数値で確かめられる点が機能ポイントの強みです。
ベンダーと発注者が同じ基準で、費用の理由を議論できます。さらに、相見積もりではポイント単価を比べることで、実質的なコスト効率を評価できます。
「軽微改修」と「仕様変更」を分ける境界線
費用のトラブルの多くは、保守内か別途費用かという境界線が曖昧なまま進むことから生じます。そのため、発注前に線引きを共有しておくことが、費用を適正化する出発点になります。
判定の基本原則とよくある誤解
判定では、作業の見た目よりも、内部の改修範囲と影響度を確認することが基本です。
- 保守内：バグ修正や障害対応など、根本修正を伴わない作業
- 別途見積：大幅なデザイン変更や新機能追加などの仕様変更
- 判定軸：プログラムの根本修正を伴うかどうか
一般的な保守契約では、バグ修正や障害対応は月額保守費の範囲に含まれます。OSやミドルウェアの軽微なアップデート適用も、保守内とされます。一方、大幅な変更は別途の制作作業にあたり、追加費用が発生するのが一般的です。
ボタンの色の変更であっても、共通部品を改修して全画面に影響が及べば、仕様変更に近づきます。反対に、新しい帳票であっても、既存テンプレートを流用するだけなら工数を小さく抑えられます。
契約時には、保守内と別途見積の定義を、具体的な作業例とあわせて文書にしておきます。判定ルールを合意しておけば、改修の依頼ごとに確認する手間を減らせます。
ケース別の「保守内 or 別途見積」早見表
ケースごとの扱いを並べると、保守内と別途見積の境界を具体的に判断できます。
- 画面：文言・ラベルの修正は保守内、新しい画面や機能の追加は別途見積
- 表示・項目：表示崩れは保守内、DB構造を変える項目追加は別途見積
- 帳票・連携：項目順の変更は保守内、新規の外部連携は別途見積
- 障害・業務：障害修正は保守内、業務フローの変更は別途見積
- 更新：マイナー更新は保守内、メジャー更新や大規模改修は別途見積
OS・ミドルウェアのマイナーアップデートは、保守内とされやすい作業です。一方で、OSのメジャーアップデートやブラウザ仕様変更に伴う大規模改修は、別途となります。
法改正対応やOSS（WordPressなどのオープンソース）の更新は、判断が分かれます。外部要因によるものであっても、適用しないとシステムが使えなくなる場合があります。
契約によって保守内にも別途見積にもなるため、事前に取り決めておくことが必要です。取り決めが曖昧なままだと、法改正や脆弱性対応のたびに想定外の出費が生じます。
軽微改修費に潜む隠れコストの見つけ方
軽微改修は、1件ごとの金額は小さいものの、積み重なると保守費を押し上げます。見積額の裏にある費用の構造も確かめることが、適正化の鍵になります。
見積に表れにくい隠れコストの種類
見積書で見落としやすい費用を先に分けておくと、確認すべき項目がはっきりします。
- 時間外対応費：夜間や休日の作業で発生する割増料金
- 更新・テスト費：文書の更新や回帰テストにかかる費用
- 引き継ぎ費：別のベンダーへ切り替える際に生じる費用
営業時間外や休日のリリースは、契約によって割増料金の対象になります。見積に明記されないまま夜間のリリースを選ぶと、費用が想定の1.5倍になる場合もあります。
設計書や運用手順書の更新、改修箇所以外を確かめる回帰テストも必要になります。改修費に含まれるかどうかを確認しておかないと、後から追加請求の原因になります。
システムの仕組みが分かりにくくなっていると、改修のたびに仕様を調べる費用が上乗せされます。
特定のベンダーに任せ続けると、改修の履歴やノウハウがそのベンダーに蓄積していきます。そのため、別のベンダーへ切り替える際には、将来のトランジション（引き継ぎ）コストが発生します。この状態をベンダーロックインといい、長期的に乗り換えの自由を失います。
保守費の内訳を見直して適正化した実例
保守費の内訳と利用実績を分けて見ると、不要な費用を見つけやすくなります。
- 民間企業：未利用サービスの発見
- 政府の情報システム：利用頻度に合わせた契約の見直し
- 利用実績の分解：月ごと・項目ごとのばらつきの確認
ある民間企業では、保守費の内訳を精査して未利用サービスを見つけました。その結果、月額28万円の保守費を20万円まで圧縮し、削減率は28.6%になりました。
年間に換算すると、約96万円の削減になります。保守費には、不要な定型作業やオプションが紛れていることもあります。
政府の情報システムでは、定期保守契約のもとでも実際の故障率が低いことを確認しました。利用が年に数回に限られていたため、スポット保守契約に切り替えて費用を削減しています。
軽微改修も、毎月定額の枠よりも、発生のつどスポットで発注するほうが安い場合があります。まずは利用実績の少ない枠を見つけることが、隠れコストを削減する第一歩になります。
軽微改修費の経理処理（修繕費か資本的支出か）
軽微改修は、会計上どう処理するかによって、税務への影響や費用化の時期が変わります。そのため、情報システム部門は経理部門と連携して、処理を判断する必要があります。
修繕費と資本的支出の分かれ目
改修の目的が現状維持か機能向上かによって、処理の区分が変わります。
- 修繕費：障害の除去や現状維持を目的とする修正
- 資本的支出：新機能の追加や性能向上をもたらす改修
修繕費は、その期の費用として全額を損金にできます。一方、資本的支出は資産に計上し、耐用年数にわたって減価償却するため、費用化は複数年にわたります。
軽微改修の多くは現状維持や不具合の解消が目的なので、修繕費にできるケースが多いです。
発注時には、改修が現状維持か機能向上かを見積書や記録に残しておく必要があります。軽微改修であっても、実質的に機能追加を伴うなら、資本的支出になる可能性があります。
「既存部分の除却」という視点
資本的支出であっても、既存部分の除却を考慮すると、費用として処理できる余地が生まれます。
- 改修で新たに資産計上する部分の切り分け
- 廃止した既存機能のうち、除却できる部分の特定
- 改修内容の記録と、経理部門や顧問税理士による判断
改修で既存機能を作り替える場合、既存部分は除却されたものとして捉えられます。古い機能を新機能に置き換える改修では、未償却残高を除却損にできる可能性があります。その結果、当期の費用処理を増やせる場合があります。
税務の専門領域に関わるため、顧問税理士や経理部門との連携が前提になります。情報システム部門は、廃止する機能と新設する機能を、経理部門が判断できる形で記録しておきます。技術面の改修の実態を文書にまとめておけば、修繕費・資本的支出・除却を適切に判断できます。
支払額だけでなく会計処理まで含めて、改修の総コストを捉えることが重要です。
まとめ
軽微改修の費用は、保守費全体の10〜15%という割合から捉えます。見積では工数積算法と機能ポイント法を使い分け、工程ごとの内訳の開示を求めます。
保守内か仕様変更かの判定ルールを契約時に明文化すると、追加費用を防げます。時間外対応費や更新費、引き継ぎ費は、保守費の内訳と利用実績から確かめます。
不要な枠を削れば、保守費の削減率28.6%のような適正化も可能です。修繕費か資本的支出かの判断も含めて、支払額ではなく総コストで比べます。
軽微改修は精査が後回しになりやすいからこそ、根拠を持っておくことが欠かせません。
軽微改修の進め方や判定フローはITシステム軽微改修の進め方で確認できます。
依頼先の選び方はITシステム軽微改修でおすすめの開発会社6選で解説しています。
発注や委託の進め方はITシステム軽微改修の発注・外注方法で確認できます。
全体像を把握したい方はITシステム軽微改修の完全ガイドもご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。