追加開発の見積相場や費用/コスト/値段について

既存システムに機能を追加したい、改修を加えたいと考えたとき、最も読みづらいのが追加開発の費用相場ではないでしょうか。新規開発であれば人月単価×期間で概算が立てやすい一方、追加開発は「動いているものを触る」という性質上、影響範囲調査やリグレッションテスト、デグレ対応など見えづらいコスト要素が積み重なり、見積額が想定の2倍3倍に膨らむケースも珍しくありません。スルガ銀行と日本IBMの訴訟事例では、当初95億円の予算が最終的に127億円の追加請求にまで膨らみ、最高裁まで争われた末に41億7210万円の支払命令が確定するという事態にまで発展しました。

本記事では、追加開発の費用相場を「機能数 × 品質レベル × 人月単価」という独自の算出式から徹底解説し、品質レベル選択が見積額を50%から400%まで動かす実態、商法512条に基づく追加報酬請求の法的要件、影響範囲調査とリグレッションテストの別建てコスト、そしてコンコルド効果に陥らないための中止判断スコアシステムまでを体系的に整理します。発注側として見積書を読み解き、ベンダーに足元を見られず、かつ正当な追加費用は適切に支払うための実務知識を、5000文字を超えるボリュームで網羅的にお届けします。

追加開発の費用構造の全体像

追加開発の費用は新規開発と異なり、既存システムへの影響を考慮した複合的な算出ロジックで決まります。基本構造は「機能数 × 品質レベル × 人月単価」の三要素から成り、ここに影響範囲調査費とリグレッションテスト費が別建てで上乗せされる構造です。人件費が総額の約8割を占めるという業界の傾向は新規開発と同様ですが、追加開発では既存仕様の読み解きコストが工数を押し上げる点が異なります。

追加開発の見積を組み立てる際、最も汎用性が高いのが「機能数 × 品質レベル × 人月単価」という三項式です。機能数は追加する画面数・API数・バッチ処理数の合計で、ベンダーが「ファンクションポイント」や「画面数換算」として算出します。品質レベルとはエラー率の許容度、応答性能、可用性などの非機能要件の水準を指し、これが見積額を最も大きく動かす変数となります。

人月単価は技術者のグレードによって決まり、上級SEで100〜160万円、初級SEで60〜100万円、大手SIerのプログラマーで50〜100万円、下請けや個人事業主では40〜60万円、外国籍プログラマーを起用するオフショア体制では30〜40万円というレンジが一般的です。同じ機能数でも担当者のグレードが上級から下請けに変わるだけで、見積額は3倍前後の開きが生じます。発注側は人月単価レンジを把握したうえで、見積書のグレード配分を確認することが重要です。

同じ機能を追加する場合でも、品質レベルによって費用は劇的に変動します。低品質レベル（社内ツール程度、エラー多少許容、稼働率95%程度）であれば基準値の50〜70%、中品質レベル（業務系標準、稼働率99%、レビュー・テスト一通り実施）で100〜150%、高品質レベル（金融基幹・医療・公共インフラ系、可用性99.99%以上、第三者検証必須）では200〜400%という変動率が現実的なレンジです。

たとえば中品質レベルで500万円と見積もられる機能でも、高品質レベルが要求されると2000万円に跳ね上がります。見積書を受け取った発注側は、自社業務が本当にその品質レベルを必要としているのかを冷静に判断する必要があります。「可用性99.9%」と「99.99%」では年間ダウンタイム許容が8.76時間から52.6分に変わり、冗長構成や監視基盤の作り込みが桁違いに増えるため、業務インパクトから逆算した非機能要件定義が費用最適化の鍵となります。

機能規模別・品質レベル別の費用相場

追加開発の費用相場を具体的にイメージするには、機能規模を「小規模（1〜3画面）」「中規模（4〜10画面）」「大規模（11画面以上）」に分け、それぞれに品質レベルを掛け合わせるのが実用的です。さらにアプリ開発の場合、iOSとAndroidを別実装する必要があり、Webシステムの1.5〜2.5倍の費用が必要になる点も押さえておきましょう。

既存システムに新規画面を1〜3画面追加する程度の小規模追加開発であれば、中品質レベルで100万円〜400万円が一般的な相場です。期間としては1〜2ヶ月で完結し、SE1名とプログラマー1名のチーム編成が標準的なケースとなります。低品質レベル（社内限定の業務効率化ツールなど）であれば50万円から200万円のレンジで収まることもあります。

一方、同じ画面数でも高品質レベル（顧客向けECシステム、決済連携など）が要求される場合、200万円から1600万円という幅広いレンジになります。小規模だからといって油断せず、品質レベル設定と既存システムへの影響範囲を見極めて発注することが肝要です。スマホアプリで同等の機能を追加する場合は、iOS・Android両対応のため、それぞれ1.5倍から2.5倍のコストを見込むのが現実的でしょう。

4〜10画面の中規模追加開発になると、要件定義から始めて設計・実装・テストまで3〜5ヶ月の期間が必要になります。中品質レベルで500万円から1500万円、高品質レベルが要求されるエンタープライズ用途では1000万円から6000万円という相場感です。チーム編成もSE2〜3名、プログラマー3〜5名、テスト担当1〜2名と複線化し、プロジェクトマネジメントコストも顕在化してきます。

11画面以上の大規模追加開発では、既存システムへの影響範囲が広がり、6ヶ月以上の工期と1500万円から1億円超の費用を見込む必要があります。基幹系システムへの大型機能追加では、データ移行やデータ整合性検証も別途必要となり、本体開発費の20〜30%相当の追加コストが発生することも珍しくありません。OSSやパッケージを活用した場合は、フルスクラッチに比べて40〜60%のコスト削減効果が期待できますが、カスタマイズ範囲を絞り込む発注側の覚悟が求められます。

影響範囲調査とリグレッションテストの別建てコスト

追加開発が新規開発と決定的に異なるのは、「動いているシステムを触る」という緊張感です。1箇所の変更が連動する機能・データ・外部連携に波及するため、影響範囲調査とリグレッションテストを別建てコストとして見積に含めることが必須となります。これを「本体開発に含まれている」と思い込み、発注後に追加請求されて揉めるケースが後を絶ちません。

影響範囲調査は、追加開発で変更するモジュールが既存のどのコンポーネント・データ・外部連携に影響するかを洗い出す作業です。実装規模にもよりますが、本体開発費の15〜25%相当を見込むのが妥当な相場です。具体的には、データベースのテーブル間依存関係マッピング、共通ライブラリの利用箇所特定、APIの呼び出し関係調査、バッチ処理のジョブ依存関係分析、外部システム連携インターフェース確認といった複数の作業を伴います。

影響範囲調査を軽視すると、後工程で「想定外の機能が壊れた」「データ不整合が発生した」といった事態に発展し、調査をやり直したうえで追加対応する手戻りコストが本体開発費の50〜100%相当まで膨らむことがあります。フレシットの増田氏は「システム変更はどこを直すかではなく、何が連動して動いているかを理解することから始まる」と指摘しており、影響範囲調査こそが追加開発成功の鍵となります。発注側は見積書に「影響範囲調査」項目が明示されているかを必ず確認してください。

リグレッションテスト（回帰テスト）は、追加開発後に既存の正常箇所が壊れていないかを確認する必須プロセスです。手動でテスト項目を洗い出して実施する場合、本体開発費の20〜30%相当が標準的な相場となります。テスト自動化ツールやCI/CDパイプラインを整備済みであれば10〜15%程度まで圧縮可能ですが、初回導入時には自動化基盤の整備コストとして本体開発費の20〜40%が別途必要です。

金融機関や医療機関のような高品質レベルが要求される領域では、リグレッションテスト費が本体開発費の50%を超えることも稀ではありません。テスト工程の見積額が本体開発費に対して10%以下の場合、テストを意図的に省略している地雷ベンダーの可能性があるため、必ずテスト項目数とテスト体制を質問して回答の精度を確認すべきです。長期的にはテスト自動化への投資が追加開発のたびに発生するコストを大幅に低減します。

初期費用以外のランニングコストと隠れ費用

追加開発の費用は、開発が終わってリリースした瞬間に終わるわけではありません。Day2と呼ばれるリリース後の運用フェーズで継続的に発生するランニングコストも、見積段階で必ず把握しておく必要があります。インフラ費、保守費、監視・SRE体制構築費、SLA対応費など複数の費目が継続発生し、初期開発費の年間15〜25%程度がランニングコストの目安となります。

追加機能を稼働させるためのクラウドインフラ費用は、利用量に応じた従量課金となるため、機能利用が活発になるほど増加します。中規模システムではAWSやAzure、GCPなどのIaaS利用料で月額20万円から100万円、大規模システムでは月額数百万円規模に達することもあります。データベース容量、トランザクション数、ストレージ容量、外部API呼び出し回数といった項目ごとに課金されるため、利用予測の精度が予算精度を決めます。

保守費用は初期開発費の10〜15%が年間相場で、軽微なバグ修正、セキュリティパッチ適用、OSやミドルウェアのバージョンアップ対応、運用問合せ対応などを含みます。保守契約に「軽微な機能改修」が含まれているか、含まれている場合は年間何工数までかを契約段階で明文化しておくことが、後の追加請求トラブルを防ぐポイントです。保守費は安いほど良いと考えがちですが、安すぎる保守費はインシデント対応の遅延につながり、結果として業務損失を拡大させるリスクがあります。

近年の追加開発では、リリース後の安定運用を担うSRE（Site Reliability Engineering）体制の構築費も検討項目に入ってきました。監視ツール導入、ログ集約基盤の構築、アラート設計、オンコール体制整備などで初期費用として500万円から2000万円、月額運用費で30万円から200万円程度を見込みます。可用性99.9%を担保するSLAを要求する場合、エラーバジェット運用とインシデント対応プロセスの構築費が追加で必要です。

ANAのモバイルアプリ事例では、Pivotal Labsを参考に5ヶ月で課題整理・トライアル開発・評価を回し、DevOpsを組織に定着させることに成功しています。SRE体制は単なる監視ツール導入ではなく、組織文化と運用プロセスを伴う投資である点を理解し、追加開発の見積段階から検討に組み込むことで、リリース後のトラブル対応コストを大幅に削減できます。

商法512条と追加報酬請求の法的要件

追加開発で最もトラブルになりやすいのが「契約書に書かれていない追加作業の費用請求」です。発注側からすれば「最初の見積に含まれているはず」と思う一方、ベンダー側は「仕様変更が発生したから追加請求は当然」と主張する構図が典型的です。この対立を整理する根拠となるのが商法512条であり、過去の判例から実務上の判断基準が形成されています。

商法512条は「商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求することができる」と定めており、契約書に明示されていない追加作業であっても、一定の要件を満たせばベンダー側に追加報酬請求権が認められます。実務上の二要件は次の通りです。(1)別途費用が発生することを発注側に文書（議事録・メール）で明示していること、(2)システム会社側が当初の仕様変更取決めを破っていないこと、の双方を満たす必要があります。

これらを満たさず、口頭でのみ「追加作業お願いします」と依頼した場合、ベンダー側が後から追加請求するのは法的に難しくなります。逆に発注側が「追加費用は払わない」と主張しても、(1)(2)を満たす客観証拠があればベンダー側の請求が認められる可能性が高くなります。発注側にとって重要なのは、変更管理プロセスを発注側責任で設計し、変更点と費用扱いを必ず議事録に記録することです。これにより、ベンダー任せの追加請求を防止できます。

象徴的な判例として、開発対象のプログラム数が当初の182本から最終的に414本まで増加したケースで、見積書に「工数が大幅変動した場合は別途相談」と明記されていたため、契約書に追加条項がなくても追加請求が認容された事例があります。この事例から学べるのは、見積書段階で「工数大幅変動時は別途相談」条項を入れているベンダーは、後から追加請求を正当化する伏線を張っている可能性があるという点です。発注側は条項の意図を確認し、変動の閾値を明確化させる必要があります。

もう一つの教訓的事例が、スルガ銀行と日本IBMの訴訟です。当初95億円の予算でスタートし、合意書では89億円とされたものの、開発中断時には日本IBMから127億円の追加請求がなされ、最終的に高裁で日本IBMに41億7210万円の支払命令が確定しました。訴訟記録は72冊にも及び、宴会の箸袋に手書きされた金額交渉メモが証拠として提出されるなど、追加費用を巡る対立が法廷で生々しく争われた事例です。発注側として議事録・記録管理を徹底することの重要性が、この事例から明確に読み取れます。

コンコルド効果回避のための中止判断スコアシステム

追加開発のコスト管理で最も難しいのは「やめる判断」です。すでに数千万円を投じた案件を中止する決断は心理的に困難であり、サンクコストを惜しむあまり損失を拡大させる「コンコルド効果」に陥るケースが少なくありません。これを回避するため、定量的な中止判断スコアシステムをプロジェクト開始時に組み込んでおくことが、経営判断を支える有効な装置となります。

中止判断スコアは、(1)予算超過率（当初予算比で何%増えたか）、(2)スケジュール遅延率（予定リリースから何ヶ月遅れているか）、(3)未解決の重大不具合数、(4)要件変更回数の月次推移、(5)プロジェクトメンバーの離職率という5項目で評価します。それぞれを5点満点で採点し、合計15点以上で「黄信号」、20点以上で「赤信号として中止検討必須」と判定する基準を社内で合意しておきます。

このスコアシステムをプロジェクト開始時にステークホルダー全員で合意しておくことで、いざ赤信号が点灯したときに「ここで中止することは合意済みのルール」として冷静に判断できます。経営層と現場、ベンダーとの間で「やめる勇気」を持つための共通言語となり、コンコルド効果に陥ることなく傷を最小化できる仕組みです。スルガ銀行事例のように100億円を超える損失を出す前に、定量基準で中止判断を下せる体制が組織を守ります。

中止判断スコアを機能させるには、フェーズゲート設計を伴う段階リリース型の契約が有効です。要件定義、基本設計、詳細設計、実装、テストといった各フェーズの終わりに、スコア評価と次フェーズ進行可否のレビューを必ず行います。アジャイル開発であれば、スプリント単位（2週間程度）で評価サイクルを回せるため、中止判断の柔軟性が大幅に向上します。

デンソーのyuriCargoは、スマホ運転スコアリングアプリとして2020年7月にローンチし、5ヶ月で1,700ユーザーを獲得しました。これはユーザーフィードバックを反映する反復改善のアジャイル開発によって、段階リリースを実現した成功事例です。完成形を固定せず短いスプリントで小さくリリースし、フィードバックを受けて段階的に追加開発を進める手法は、追加開発を内包した契約設計として極めて有効であり、中止判断もしやすい構造になります。

追加開発の見積を取る際のポイント

追加開発の見積取得では、新規開発以上に「比較可能性」と「内訳の透明性」が重要となります。複数社から相見積もりを取る際は、機能要件・非機能要件・影響範囲調査の前提条件を統一して提示することが、適正な比較のための最低条件です。同じ条件であっても、ベンダー間で見積額が3〜5倍開くケースは珍しくないため、価格差の根拠を必ず質問してください。

見積取得前に、品質レベルの定義を発注側で明確化しておくことが見積精度を高める最大のコツです。可用性、応答性能、データ整合性、セキュリティ要件、ログ保管要件などを文書化し、各社に同条件で提示します。「業務インパクトから逆算した非機能要件」を発注側が定義できれば、ベンダーから過剰な高品質提案を受けるリスクを抑え、最適な品質レベルで見積を取得できます。

複数社比較では最低3社、理想的には5社程度から相見積もりを取り、価格レンジと内訳項目の差を分析します。極端に安い見積は、テスト工程や影響範囲調査を意図的に削減している地雷ベンダーの可能性が高く、極端に高い見積は不要な高品質提案や中間マージンが乗っている可能性があります。価格レンジの中央値前後で内訳が明瞭な見積を出す会社が、概して信頼に値する候補となります。

商談段階で力量を測るキラークエスチョンとして、(1)影響範囲調査をどう実施するか具体的な手順を説明してほしい、(2)リグレッションテストの自動化実績はあるか、(3)過去のトラブル事例とその対処方法を共有してほしい、(4)安すぎる見積もりの裏側でテスト工程を削減していないか、(5)準委任契約と請負契約のどちらが本案件に適切と考えるか、の5つを必ず投げかけてください。

信頼できるベンダーほど、リスクを正直に開示し、過去の失敗事例も含めて率直に語ります。逆に「弊社は失敗事例はありません」「すべてお任せください」と言い切るベンダーは、リスク認識が低いか実績が浅い可能性があり、追加開発の途中で炎上するリスクが相対的に高くなります。大塚商会のフィッティングコンサル事例では、パッケージ刷新前に5.5ヶ月22週・会議40回弱の重厚な業務フィット分析を実施し、コストは開発費全体の5〜6%に収まりつつ成功着地に貢献しました。事前準備に投資することの価値を理解しているベンダーは、長期パートナーとして信頼できる候補です。

まとめ

追加開発の費用相場は「機能数 × 品質レベル × 人月単価」という三項式を起点に、品質レベル変動率（×50〜400%）で大きく振れる構造を持ちます。さらに影響範囲調査費（本体開発費の15〜25%）とリグレッションテスト費（同20〜30%）を別建てで見込み、リリース後のインフラ・保守・SRE体制構築のランニングコスト（初期費用の年間15〜25%）も合算して総予算を組み立てる必要があります。

追加費用の請求を巡るトラブルでは商法512条が判断基準となり、(1)別途費用発生の文書明示、(2)仕様変更取決めの遵守、の二要件を満たせば「相当な報酬請求」が法的に成立します。スルガ銀行と日本IBMの訴訟（95億→89億→127億要求→41億7210万円判決）が示すように、発注側として議事録・記録管理を徹底し、変更管理プロセスを発注側責任で設計することが炎上回避の鍵となります。

そして最も重要なのは、コンコルド効果に陥らないための中止判断スコアシステムを開始時に組み込むことです。予算超過率、スケジュール遅延率、未解決重大不具合数、要件変更回数、メンバー離職率の5項目を定量評価し、合計15点で黄信号、20点で赤信号として中止検討必須と判定する基準を社内で合意しておけば、サンクコストに引きずられず冷静な経営判断が可能になります。本記事の費用相場と判断軸を活用し、追加開発を成功裏に着地させるパートナー選定と契約設計に役立ててください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。