ビジネス活用2026年10月更新

システム改修の費用|作業別の目安と内訳、既存システムの改修が高くなる6つの条件

公開日: 2026/09/14
更新日: 2026/10/10
システム改修の費用|作業別の目安と内訳、既存システムの改修が高くなる6つの条件

この記事のポイント

システム改修の費用を、作業別の目安(文言修正3万〜10万円、CSV出力項目の追加10万〜80万円など)と、調査・改修・テスト・本番反映・外部利用料の内訳で整理。ソースやテスト環境の有無で見積どおりに進められるかの見分け方、費用が高くなる6つの条件、他社製システムに画面や帳票を足すときの確認点も解説します。

システム改修の費用は、作業の中身で大きく変わります。開発会社のripla社が公開している目安では、文言修正は3万〜10万円、入力項目やCSV出力項目の追加は10万〜80万円、データベースの変更を伴う改修は30万〜200万円です。

金額の差を生むのは、プログラムを直す作業そのものより、影響範囲の調査、テスト、本番環境(実際に業務で使っている環境)への反映と、ソースコードやテスト環境がそろっているかどうかです。この記事では、作業別の早見表、費用の内訳、見積どおりに進められるかの確認表、費用が高くなる6つの条件、他社製のシステムに画面や帳票だけを足すときの確認点、本番を止めずに確かめる方法を順に説明します。当社(AI革命)の既存システムの改修は100万円〜(税別)です。

システム改修の費用|作業別の目安と、金額の幅が出やすい作業の早見表

まず、直したい内容がどの金額帯に入るかを確かめてください。下の表は、ripla社が2026年6月11日に公開したITシステム軽微改修の費用相場の作業別の目安(2026年10月9日確認)に、金額の読みやすさの見立てを当社が3段階で加えたものです。

  • 〇:見た目や表示だけが変わり、金額が読みやすい
  • △:影響範囲と調査の量で、同じ作業でも金額が数倍変わる
  • ×:データベースの変更を伴い、確かめる画面・帳票・連携が増えるため高くなりやすい

作業

費用の目安

金額の読みやすさ

文言修正、表記変更

3万〜10万円

〇

画像差し替え、バナー変更

3万〜15万円

〇

軽微なデザイン調整

5万〜30万円

〇

表示順、一覧項目の変更

5万〜30万円

〇

入力項目の追加

10万〜50万円

△

検索条件、絞り込み項目の追加

10万〜80万円

△

CSV出力項目の追加、変更

10万〜80万円

△

帳票レイアウトの一部修正

10万〜100万円

△

管理画面の軽微な改善

20万〜100万円

△

軽微な不具合の修正

5万〜100万円

△

データベースの変更を伴う改修

30万〜200万円

×

本番環境への反映、リリース対応

5万〜50万円

上の作業に加算されることがある

〇が付いているのは、画面の見た目や表示だけが変わる作業です。△の作業は、同じ「項目を1つ足す」でも10万円で済むこともあれば、80万〜100万円かかることもあります。なぜこれほど差が出るのかは、次の章で費目ごとに分けて説明します。

表の最後の行にも気をつけてください。ripla社の目安では、本番環境への反映・リリース対応だけで5万〜50万円です。見積を受け取ったら、この項目が入っているか、別料金になっていないかを必ず確かめてください。

「軽微改修」「小規模改修」「部分改修」は何が違うのか

似た言葉がいくつも使われていますが、公的な定義はありません。たとえばripla社は軽微改修を「大規模な機能追加ではなく、小さな修正や調整を行う対応」と説明し、文言変更、入力項目の追加、表示順の変更、軽微な不具合修正、CSV項目の追加、管理画面の一部改善などを例に挙げています。「小規模改修」「部分改修」がどこまでを指すかは、会社ごとに決めています。

そのため、「軽微な修正です」と伝えるか「小規模改修です」と伝えるかで、相手が見積もる作業の範囲がずれることがあります。見積を頼むときは、呼び方ではなく、どの画面のどの項目をどんな条件で直したいかで伝えるのが確実です。

システム改修費用の内訳|調査・改修・テスト・本番反映・外部利用料

見積の総額だけを見ても、高いか安いかは判断できません。ripla社は、軽微改修の費用は「修正内容の規模 × 影響範囲 × 調査工数 × テスト範囲」で決まることが多いと説明しています。システム改修の見積は、おおむね次の費目に分かれます。

費目

中身

見積で確かめること

調査(既存の仕様・データ構造の確認)

直す箇所が、どの画面・帳票・連携・データにつながっているかを調べる

調査が終わったら何を受け取れるか(影響する機能の一覧など)

改修(設計・修正)

画面・帳票・CSV・処理を直す

どの画面のどの項目を直すかが書かれているか

テスト・動作確認

直した箇所と直していない箇所に、不具合が出ていないかを確かめる

どの機能を確認するか(テスト対象の一覧)

本番反映・反映後の確認

業務で使っている環境に変更を入れ、正しく動くか確かめる

反映前のバックアップと、元に戻す手順が入っているか

外部利用料(実費)

クラウド、外部API、ソフトウェアのライセンスなど

改修費に含むのか、実費として別に払うのか

(必要な場合)引継ぎの調査

作った会社以外が初めて触るときの現状調査

改修と別の見積か、調査の結果を見て改修するかを選べるか

ripla社は、「管理画面の一覧に項目を1つ追加し、CSV出力にも同じ項目を追加する」場合の内訳の例として、次の金額を挙げています。

工程

ripla社の目安

既存仕様、データ構造の確認

5万〜20万円

画面表示の修正

10万〜30万円

CSV出力処理の修正

10万〜30万円

テスト、動作確認

5万〜20万円

本番反映、リリース後確認

5万〜20万円

合計

30万〜120万円前後

合計はripla社の記載どおりです(各工程の下限を足すと35万円になります)。「項目を1つ足す」だけでも、確認・テスト・反映まで含めると100万円を超えることがある、という例です。当社の場合も、既存システムの改修(100万円〜・税別)とは別に、クラウド・外部API・ライセンスなどの実費がかかります。また、既存のコードやシステムの調査報告だけを頼む場合は有償で、着手の前に範囲と金額をお示しして合意をいただきます。

「CSVに1列足すだけ」でもシステム改修の費用が高くなる理由

ソフトウェア・メトリクス調査を行う日本情報システム・ユーザー協会(JUAS)のロゴ

出典: JUAS(日本情報システム・ユーザー協会) 公式サイト

たとえば「CSVに1列足してほしいと頼んだら、50万円と言われた」とします。発注する側は納得しにくいところですが、ripla社の目安でもCSV出力項目の追加は10万〜80万円で、見積が不当だとは限りません。

100万円は、エンジニア1人の何日分か(仮定に基づく試算)

改修の見積は、基本的に「作業する人の日数 × 単価」で出されます。公開されている単価から逆に計算すると、当社の改修の開始価格である100万円で頼める作業の量の見当がつきます。次の表は、1か月を20営業日と仮定し、「100万円 ÷(月単価 ÷ 20日)」で計算した当社の試算です。

単価の根拠

1人日あたり

100万円で頼める日数

ripla社が示すエンジニアの月単価80万〜150万円

4万〜7.5万円

約13〜25人日

JUAS「ソフトウェア・メトリクス調査2025」のスクラッチ開発99件の加重平均単価96万円/人月

約4.8万円

約21人日

※「人日」は1人が1日で行う作業量、「人月」は1人が1か月で行う作業量です。JUASの同じ調査では、規模の小さい区分(10人月未満、6件)の加重平均単価は185万円/人月で、この単価なら100万円は約11人日分です。

つまり、100万円はエンジニア1人のおおむね13〜25日分の作業です。この日数の中で、次の工程をすべて終わらせる必要があります。

  1. 依頼内容の整理:「ここを直したい」を、どの画面のどの項目をどんな条件で変えるのか、という形に置き換える
  2. 影響範囲の調査:直す箇所が、ほかのどの機能とつながっているかを確認する
  3. 修正:プログラムを直す
  4. テスト:直した箇所が正しく動くか、直していない箇所に不具合が出ていないかを確認する
  5. 本番環境への反映:実際に使っている環境に変更を入れる
  6. 反映後の確認

プログラムを書く時間は、このうちの一部にすぎません。調査に日数がかかれば、その分だけ修正とテストに使える日数が減ります。

見た目の小ささと、裏側の作業量は一致しない

「CSVに1列足す」を例に、影響範囲の調査で何を確認するのかを並べると、次のようになります。

確認すること

当てはまったときに起きること

出したい項目が、そもそもデータとして保存されているか

保存されていなければ、入力画面とデータベースの両方を直すことになる(早見表の×の帯)

同じ項目を使っている帳票や画面が、ほかにもあるか

そちらも合わせて直すか、そのままにするかを決める必要がある

そのCSVを誰が出力できるか

個人情報や金額が入る項目なら、見られる人の範囲(権限)を見直す

夜間などに自動で動く集計や連携の処理が、そのCSVを使っていないか

列が1つ増えただけで、CSVを取り込む側のシステムが止まることがある

直していない機能に影響が出ていないか

確認する機能が多いほど、テストの日数が増える

ripla社も、データベースやAPI、権限、帳票、バッチ処理(夜間などの自動処理)に影響する場合は個別の見積が必要になることが多いと説明しています。JUASの調査では、プロジェクト全体の作業量(工数)のうち約25%が総合テストの工程です(ユーザー側の総合テストや稼働直後のフォローを含む工程で、5%刻みに丸めた値)。ただし大規模な案件も含めた比率なので、参考程度に見てください。

「1列足すだけ」が50万円になるのは、たいてい上の表の2行目より下のどれかに当てはまったときです。見積の金額に納得できないときは、「どの確認に何日かかると見ていますか」と聞くと、内訳が分かります。

システム改修の相場が、記事によって大きくばらつく理由

ソフトウェア開発分析データ集を公開していた情報処理推進機構(IPA)のロゴ

出典: IPA(情報処理推進機構) 公式サイト

「システム改修 費用」で調べると、記事ごとに数十万円から数百万円まで違う金額が出てきて、どれを信じればよいのか迷います。数字がばらつくのには理由があります。

100万円くらいの改修を集めた公的な統計はない

IPA(情報処理推進機構)が公開していた「ソフトウェア開発分析データ集」は2022年版が最新で、事業終了に伴い今後の発行予定はありません。いま参照できる業界調査は、JUASが2025年4月に出した「ソフトウェア・メトリクス調査2025」です。

ところが、この調査でいちばん小さい区分(10人月未満)でも、外注コストの平均は850万円、工数の平均は5人月です。しかも、この区分に入るスクラッチ開発の案件は6件しかありません。数十万円から100万円くらいの改修をまとめた統計は見当たらない、ということです。

公開されている「相場」は、各社が自社の受注実績や経験をもとに出した目安です。ripla社の目安でも、同じ「入力項目の追加」が10万〜50万円、「データベースの変更を伴う改修」が30万〜200万円と、1つの作業の中で数倍の幅があります。どれか1つの数字が正しいわけではありません。その会社が「改修」に調査・テスト・反映のどこまでを含めているかによって、数字が変わっていると考えるのが正確です。比べるときは、前の章の費目ごとに見積を並べてください。

「改修だから新規開発より安い」とは限らない

JUASの同じ調査では、500人月未満のプロジェクトについて、新しく作る場合と改修する場合とで、工程ごとの比率に大きな差はないと分析しています。改修でも、調査・設計・テストといった、新しく作るときと同じ種類の作業が同じように必要になるということです。

また、50人月未満の小さなプロジェクトは56%が、規模から見た標準的な工期(標準工期)を超えていました(500人月以上では71%が標準工期以内に収まっています)。JUASは、小さなプロジェクトでは標準工期に余裕を持って工期を計画することが望ましいとしています。100万円くらいの改修そのものを調べた統計ではありませんが、スケジュールに余裕を持たせる理由にはなります。

見積どおりに進められるかの確認表|ソース・テスト環境・接続方法ごと

早見表で〇や△に入る作業でも、システムの状態によっては見積どおりに進められません。次の表は、当社が相談を受けたときに最初に確かめる点を、説明用にまとめたものです。実案件を集計した結果ではありません。

確かめること

見積どおりに進めやすい状態

先に別の作業が必要になる状態

ソースコード

自社か今の保守会社の手元にあり、受け取れる

手元になく、作った会社とも連絡がつかない → 本体を直さず外側で対応するか、作り直しを検討する

変更してよい権利

契約で、成果物の権利と他社による改修の可否がはっきりしている

契約書が見つからない、製品の利用規約で改変が認められていない → 契約・規約の確認から始める

設計書・資料

直す箇所のまわりだけでも、画面の仕様やデータ項目の説明がある

資料がなく、分かる人もいない → 改修の前に調査を入れ、調査の結果で範囲を決める

テスト環境

本番とは別に、試せる環境がある(または作れる)

本番環境しかない → テスト環境の用意を先に見積もる

本番への反映

反映の手順が決まっていて、サーバーやアカウントの権限を受け取れる

権限が作った会社にしかない → 反映を誰が行うかを先に決める

データとのつなぎ方

公開API、CSV出力、データベースの読み取りのどれかで必要なデータを取り出せる

画面操作でしか取り出せない、出力の仕様が分からない → つなぎ方の検証から始める

影響範囲

直す箇所を使う画面・帳票・連携が少ない

夜間の自動処理や別のシステムがそのデータを使っている → 確認するテストが増える

左の列にすべて当てはまれば、調査にかかる日数が少なく済み、見積の多くを修正とテストに充てられます。右の列に1つでも当てはまるときは、改修そのものの前に「調査と範囲決め」に費用と日数がかかります。ソースや資料がそろわない他社製システムの引継ぎ調査は、他社が作ったシステムを引き継いでもらうにはで詳しく解説しています。

既存システムの改修が高くなる6つの条件

IT企画・設計書の復元・通常の開発の流れを示したNTTデータの図

出典: NTTデータ 公式サイト

ここがこの記事でいちばんお伝えしたいところです。次の条件のどれかに当てはまるなら、最初に考えていた予算では終わらない前提で考えてください。

条件1:データベースの構造を変える必要がある

データベースは、システムがデータをしまっておく台帳です。この台帳に新しい欄を足したり、欄の意味を変えたりする場合、ripla社の目安では30万〜200万円かかります。台帳を変えると、その台帳を使っているすべての画面・帳票・連携処理を確認し直す必要があるためです。

条件2:直す箇所が、ほかの多くの機能とつながっている

見た目は小さな修正でも、裏でデータベース、外部との連携、権限、帳票、自動処理に影響する場合、ripla社は個別に見積もりが必要になることが多いとしています。前の章の「確認すること」の表で、いくつもの行に当てはまるのがこのケースです。

条件3:設計書がない、または中身が分かる人がいない

費用が最もふくらみやすい条件です。設計書がなく中身が分かる人もいない場合、改修の前に、どこで何が処理されているかを調べる作業(初期調査)が別に必要になります。見積は「調査費」と「改修費(調査のあとに見積)」の2段階で出されることがあり、設計書がないと、改修に入る前に調査で予算の多くを使うことがあります。

現実的な進め方は、システム全体の設計書を作り直すことではありません。よく使う機能から順に仕分けし、画面操作を録画したりテスト用のデータを入れたりして動きを外から記録したうえで、改修する箇所のまわりだけを文書にまとめます。

最近は、生成AIにプログラムを読み込ませて設計書を復元する方法も、実際の案件で使われ始めています。NTTデータは2025年7月、古いプログラムから設計書を自動で復元し、テストの項目やデータの作成にも生成AIを使う方法を紹介しています。ただし同社も、復元した設計書の正確さは詳しい人が確認する前提としており、どれだけ作業が減るかの数値は示していません。調査の日数が縮む可能性はありますが、調査そのものがいらなくなるわけではありません。

条件4:システムを作った会社以外に頼む

作った会社と連絡がつかない、保守契約が終わった、担当者が辞めた、といったケースです。新しい会社は、ソースコードや環境を受け取り、中身を把握するところから始めます。保守ごと別の会社に移す場合は、現状調査、契約と体制づくり、新旧の会社が並行して対応する期間が加わり、その分だけ期間と費用が増えます。

改修を1件頼むために引継ぎから始めれば、引継ぎの調査の分だけ合計が増える前提で考えてください。引き継ぐときに確認しておくことは、よくある質問のQ1で説明します。

条件5:新しい外部連携、業務の流れを変える機能、複数画面の追加

別のシステムと新しくデータをやり取りする、承認の手順を変える、新しい画面をいくつも作る、といった作業は、小さな修正や調整の範囲に入りません。連携先の仕様を調べるところから始まるため、作業日数が読みにくくなります。ここまでの規模になると、1回の改修ではなく、段階を分けた追加開発として予算を組んだほうが実態に合います。

条件6:テストの範囲が広い、または古い技術で作られている

直していない箇所に不具合が出ていないかを確認する範囲が広いシステムほど、テストの日数は増えます。また、古い技術で作られたシステムほど、扱える技術者や動かせる環境を探す手間が加わり、改修費が高くなりやすくなります。

見積どおりに改修が終わりやすいのは、この6条件のどれにも当てはまらず、確認表の左の列に当てはまる案件です。

他社製システムに画面や帳票だけ追加したいとき

「今の画面は残したまま、検索条件を1つ足したい」「月次の集計表を1枚出したい」という相談で、つまずきやすいのは、システムを作ったのが別の会社である場合です。このときは、技術的にできるかどうかより先に、誰が変更してよいかと、改修後の不具合を誰が直すか(保守の分担)を決める必要があります。

先に確かめる3つのこと

  1. 変更してよい権利:開発を委託して作ったシステムなら、契約で成果物の権利と、他社による改修の可否を確かめます。パッケージ製品やクラウドサービスなら、利用規約で改変やデータの取り出しが認められている範囲を確かめます。
  2. 今の保守会社との分担:他社が直した部分に不具合が出たとき、今の保守会社は対応しない契約になっていることがあります。追加した画面や帳票を誰が保守するかを、改修の前に書面で決めます。
  3. 本体を直すか、外側に足すか:本体のソースコードを直せない場合でも、公開API、CSV出力、データベースの読み取りでデータを取り出せれば、本体には手を入れず、外側に画面や帳票を作る方法があります。本体の保守契約に影響しにくい一方で、データが反映されるタイミングや、取り出せる項目の範囲に制約が出ます。

追加する画面・帳票の仕様例(説明用)

以下は架空の例です。相談の前にこの程度まで書いておくと、影響範囲の確認が早くなります。

項目

書く内容(例)

追加したいもの

受注一覧に「出荷予定日」で絞り込む検索条件を追加し、絞り込んだ結果をCSVで出力する

使う人

営業事務の3名。ほかの部署には表示しない

元になるデータ

受注データの「出荷予定日」(今の入力画面で入力済み)

出力の形式

今の受注CSVと同じ列に出荷予定日を加える。文字コードは今のCSVと同じ

今のやり方

全件をCSVで出し、Excelで並べ替えて手で絞っている

変えないもの

既存の受注一覧の表示、既存CSVの列の並び

影響範囲の確認表

確認すること

どこで確かめるか

当てはまったときの対応

出したい項目がデータとして保存されているか

データベースの項目一覧、今の入力画面

保存されていなければ入力画面とデータベースの改修になり、範囲が広がる

同じデータを使う画面・帳票・連携があるか

ソースコード、今の保守会社

既存の出力は変えず、新しい出力を別に作る

見られる人の範囲(権限)

今の権限設定

個人情報や金額が入るなら、追加する画面の権限を先に決める

夜間の自動処理や、CSVの取込先のシステム

運用手順書、今の保守会社

既存CSVの列は変えない。変える場合は取込先の確認も範囲に入れる

今の保守会社の契約条件

保守契約書

他社が直した部分を保守の対象外にするか、追加分の保守を誰が持つかを決める

改修後の受入条件(例)

  • 同じ条件で今のExcel作業をした結果と、新しい絞り込みの結果が一致する(テスト用のデータで確かめる)
  • 既存の受注一覧と既存CSVの列・件数が、改修前と変わらない
  • 権限のない利用者には、新しい検索条件と出力ボタンが表示されない
  • 反映後に問題が出たとき、改修前の状態に戻す手順が文書になっている

画面や帳票を追加したときに、ソースコード・仕様書・テスト結果のどれを受け取るかは、システム開発の納品物一覧でも整理しています。

開発費用の目安を出す

5つの質問に答えると、改修・PoC・本開発のどれに当たるかの目安と、次に決めることを表示します。

質問 1 / 5何をしたいですか

本番を止めずに確認する方法と、改修後の検収・戻し方

直す範囲が小さくても、業務で使っているシステムを直す以上、反映に失敗すれば業務が止まります。次の順で進めると、本番を止めずに確かめられます。

  1. テスト環境で直す:本番と同じ構成の環境を用意し、そこで修正とテストを行います。本番データの写しを使う場合は、個人情報を伏せた状態にします。
  2. 反映の前にバックアップを取る:プログラムとデータの両方を、反映直前の状態で保存します。
  3. 戻す手順を決めておく:「何が起きたら戻すか」「誰が戻すか」「戻すのにどれくらいかかるか」を反映の前に決めます。
  4. 業務の少ない時間に反映し、すぐに確認する:受入条件の項目を、実際に使う担当者と一緒に確かめます。

検収で確かめること

検収(納品物が約束どおりかを確かめること)では、直した箇所が動くかだけでなく、次の点を確かめます。

  • 事前に決めた受入条件を、すべて満たしているか
  • テスト対象に入れた、直していない機能が改修前と同じように動くか
  • 変更した箇所の説明(どのファイル・どの設定を変えたか)を受け取ったか
  • 不具合を無償で直す期間と範囲が、書面で決まっているか

調査のあとで範囲を小さくする例(説明用)

架空の例です。「一覧画面・CSV・帳票の3か所に『担当店舗』を出したい」という依頼で調査したところ、担当店舗はデータベースに保存されていて、一覧画面とCSVは直せる一方、帳票は別の会社の帳票製品で作られており、変更にはその会社の作業が必要だと分かった、とします。

最初の依頼のまま進めると、他社製品の改修まで含むことになり、費用も期間も読みにくくなります。そこで、①まず一覧画面とCSVにだけ項目を足す、②帳票は次の段階で帳票製品の会社と相談する、と分けると、最初の改修は範囲を絞って始められます。調査の結果を見て範囲を決め直せるように、調査と改修を分けて頼むのが安全です。

保守契約で頼むか、スポットで頼むか、作り直すか

ベンダーロックインの調査報告を公表した公正取引委員会のシンボルマーク

出典: 公正取引委員会 公式サイト

システム改修の費用は、1回ごとの金額だけで判断すると失敗します。年に何回くらい直すのか、そのシステムをこの先も使い続けるのかによって、合った頼み方が変わるからです。

自社の状況

考えられる頼み方

費用の考え方

直したいのは年に1〜2回で、内容は早見表の〇〜△

必要なときにスポットで改修を頼む

1件ごとに見積(数万〜数十万円)

毎月のように小さな修正がある

保守契約に「月◯時間までの改修」を含める

月額に含める作業時間と、超えた分の単価を契約で決める

改修のたびに影響範囲の調査がふくらむ/設計書がなく、古い技術で作られている

作り直すか、少しずつ新しい仕組みに移す

新規開発の費用(下の関連記事を参照)

新しい機能の効果がまだ読めない

小さく試して効果を確かめてから決める(PoC)

当社の場合は300万円〜(税別)。検証を始めるための価格で、本番システムの完成価格ではない

保守費の考え方に幅があるのは、月額にどこまでを含めるかが契約ごとに違い、業界で決まった基準がないためです。

注意したいのは、小さな改修を何年も重ねるうちに、そのシステムの中身を分かっているのが1社だけになってしまうことです。公正取引委員会は官公庁の情報システム調達についての調査(2022年2月)で、この状態を「特定のシステムベンダーを利用し続けなくてはならない状態」(いわゆるベンダーロックイン)と定義しました。避ける方法の1つとして、発注する側が知識を蓄えることを挙げています。官公庁向けの調査ですが、この考え方は民間企業にも当てはまります。改修を頼むたびに、何をどう直したかの記録を自社で持っておくだけでも、あとで選べる道が増えます。

作り直す場合の費用は業務システム開発の費用相場で、小さな修正を重ねるうちに保守費がふくらむ仕組みはRPAの保守コストが高くなる理由で解説しています。

システム改修の費用|当社の場合(既存システムの改修100万円〜・税別)

既存システムの改修を受託するAI革命のロゴ

出典: AI革命 公式サイト

ここまでは特定の会社に寄らない情報をお伝えしました。当社の価格と対象範囲も、同じ見方で示します。

メニュー

費用(税別)

対象になる作業

既存システムの改修

100万円〜

今あるシステムへの機能や画面・帳票の追加、他のシステムとのデータ連携など

PoC(小さく試して効果を確かめる)

300万円〜

検証内容の整理、PoCの設計と開発、評価結果のまとめ。検証を始めるための価格で、本番システムの完成価格ではありません

本開発

個別見積

機能数、利用者数、外部連携、データ移行、セキュリティ要件から見積

クラウドの利用料、外部APIの利用料、ソフトウェアのライセンスなどの実費は、どのメニューでも別にかかります。

100万円は開始価格で、定額ではありません。 早見表の△や×に入る作業が重なる場合や、確認表の右の列に当てはまるシステムでは、これを超えます。100万円で収まるかどうかは、直したい画面と項目、ソースコードと環境の状態を伺ったうえでお答えします。早見表の〇に入る作業を1件だけ直したいなら、今の保守会社かシステムを作った会社への依頼が早道です。

言語やフレームワークを問わず、既存システムの改修に対応できます。他社が作ったシステムの調査・引継ぎ・改修(調査のみ、調査と改修のどちらも可)、画面や帳票の追加、CSV・APIでの連携、kintoneやfreeeなどのSaaSとの公開APIでの連携、権限の見直しもご相談ください。どの方法でつなぐかは、今のシステムの状態を見て一緒に決めます。最初に、ソースコード・仕様書・環境情報があるかと、それらを使う権利を確かめます。

公開している実績は、通信事業での数万件の請求情報の取込・集計・確認画面と、薬局での複数店舗・数千人分の記録管理・権限・確認工程です。どちらも既存システムの改修だけの事例ではありませんが、既存のデータを取り込む処理や、誰がどの記録を見られるかの権限は、画面やCSV出力を足す改修でも同じように確かめます。

初回相談は無料・30分(オンライン、Google Meet)で、要件が決まっていなくても大丈夫です。今のシステムと困っている操作を伺い、相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。初回の30分で確定見積はお出ししません。対象範囲と進め方は受託開発サービスの費用と対象範囲に載せています。

▶ 既存システムの改修を相談する

改修の範囲を超え、効果を確かめてから投資を決めたい場合はAI PoCの費用を、AIの機能を組み込む改修を考えている場合はAI受託開発の費用相場もあわせてご覧ください。

改修費に見合うかを確かめる(仮定に基づく試算)

ここからは仮の条件を置いて計算します。担当者1人が、ある作業に毎月20時間かけているとします。時給3,000円で計算すると月6万円、1年で72万円です。100万円の改修でこの作業がなくなれば、100万円 ÷ 月6万円 で約17か月(1年5か月ほど)で改修費を取り戻せます。

1年で取り戻すには、改修でなくなる作業が月28時間ほど(月8.4万円分)必要な計算です。反対に、月2時間しかかからない作業なら月6,000円分なので、100万円を取り戻すには約167か月(13年以上)かかります。この場合は、改修するよりも作業のやり方を工夫するほうが合理的です。発注する前に、その作業に毎月何時間かかっているかを実際に測ってください。 測り方は自動化の効果測定で解説しています。

改修の見積を早く・正確にするために揃えるもの

影響範囲の調査にかかる日数は、発注する側が渡す情報によって大きく変わります。調査の日数が減れば、見積のうち修正とテストに使える日数が増えます。

揃えるもの

役に立つ理由

直したい画面のキャプチャ(今の画面と、直したあとのイメージ)

「どこを」「どう直すか」の食い違いがなくなる。依頼がうまく伝わらないと、間違った前提で作業が進み、費用がふくらむ

ふだんの操作を録画した動画(数分でよい)

設計書がないシステムでも、動き方を外から把握できる

出力しているCSVや帳票のサンプル(個人情報は隠す)

データの持ち方が分かり、表記ゆれの整理などの手間を先に見積もれる

直したい理由と、その作業に毎月何時間かかっているか

費用に見合うか、ほかの直し方がないかを一緒に判断できる

今の開発・保守の契約書

プログラムなどの成果物が誰のものか、解約を何か月前に伝える必要があるかが分かる

ソースコード、設計書、データベースの構成資料があるかどうか

自社にあるのか、作った会社が持っているのかで、調査の進め方が変わる

サーバーや外部サービスのアカウントが誰の名義か

改修した内容を反映するには、サーバーや各種アカウントの権限が必要になる

利用者からの問い合わせや不具合の記録

どこから直すべきか、優先順位を付けやすくなる

テストで確認してほしい機能の一覧

直していない箇所の確認漏れを防げる

最初の相談の段階では、資料が「あるかどうか」が分かれば十分です。パスワードなどの本番の認証情報、実際の顧客データ、社外秘の資料は送らないでください。

見積を受け取ったら、「影響範囲の調査」「テスト」「本番環境への反映」「反映後の確認」「改修前のデータのバックアップ」が入っているかを確かめてください。安い見積では、このうちどれかが「別途」になっていることがあります。

見積を頼むときの資料の作り方はシステム開発の相見積もりとRFPで、複数社の見積の比べ方は開発の見積もり比較で詳しく解説しています。

AIで自分で進められる部分と、会社に頼む部分

ChatGPTやClaudeなどの生成AIを使えば、発注する側でもかなりの準備ができます。ソースコードが手元にあれば、どのファイルがどの画面に当たるかの説明、直す箇所の候補、変更案の下書き、テスト項目の洗い出しまで、AIを使って進められます。テスト環境があれば、小さな画面の修正を自社で済ませられることもあります。

会社に頼んだほうがよいのは、次のような部分です。

  • 本番環境・サーバー・各種アカウントの権限を扱い、反映と元に戻す作業に責任を持つこと
  • 契約や保守の分担をふまえて、どこまで変えてよいかを決めること
  • 実際のデータにある例外(表記ゆれ、過去データの欠け)を見つけて、テストに入れること
  • 直していない機能に不具合が出ていないかを確かめ、検収できる形で結果を残すこと
  • 改修後の不具合や、次の変更に続けて対応すること

当社の相談では、自社でAIを使って進める部分と、任せる部分を一緒に切り分けます。

既存システムの改修の依頼から完了までの流れと期間

段階

やること

期間が延びやすいところ

1. 相談

直したい内容と、困っている理由を伝える

―

2. 課題・要件の整理

直したい内容を、画面・項目・条件の形にまとめる

社内で「何を直したいか」がまとまっていない

3. 影響範囲の調査・見積

直す箇所がどこにつながっているかを確認し、金額を出す

設計書がなく、調査に時間がかかる

4. 修正・テスト

プログラムを直し、直していない箇所も含めて確認する

テストで確認する機能が多い/テスト環境がない

5. 本番環境への反映・確認

実際に使っている環境に変更を入れ、正しく動くか確かめる

社内で確認する人の都合がつかない

(別途)他社からの引継ぎ

保守を別の会社に移す場合

現状調査と、新旧の会社が並行して対応する期間が加わる

前の試算のとおり、100万円の改修はおおむね13〜25人日分の作業ですが、これはカレンダー上の日数ではありません。発注側の確認を待つ時間や、テストの日程を調整する時間があるので、実際の期間はこれより長くなります。当社の受託開発ページでも、開発期間は決まった日数ではなく、対象範囲と確認の工程によって変わると説明しています。先に紹介したとおり、50人月未満のプロジェクトの56%が標準工期を超えていたという調査結果もあります。「この日までに必ず必要」という期限があるなら、最初の相談で日付を伝えてください。

進め方の詳細は受託開発サービスのページでご確認いただけます。依頼先を選ぶポイントは開発会社の選び方でも解説しています。

よくある質問

Q1. システムを作った会社以外に、改修だけを頼むことはできますか。

頼めます。ただし依頼先を変える前に、次の3点を確認してください。①今の契約書で、プログラムなどの成果物が自社のものになっているか、保守契約を解約するには何か月前に伝える必要があるか。②作った会社から、ソースコード、設計書、データベースの構成、サーバーの権限や各種アカウント、運用手順書を受け取れるか。③作った会社から、引継ぎへの協力費を請求されないか。保守ごと別の会社に移す場合は、新旧の会社が並行して対応する期間の保守費の二重払い、解約を伝えてから契約が終わるまでの保守費、足りない資料を作る費用も見落としがちです。改修が1回だけで、作った会社との関係が続いているなら、作った会社に頼むほうが合計は安くなる可能性が高いと考えてください。引継ぎの調査で何を頼めるかは、他社が作ったシステムを引き継いでもらうにはで解説しています。

Q2. 保守費を毎月払っているのに、改修は別料金だと言われました。妥当ですか。

契約書の内容によっては、妥当なこともあります。月々の保守費に何が含まれるかは契約ごとに違い、決まった基準はありません。月額に「月◯時間までの軽微な改修」を含め、超えた分を時間単価で精算する契約もあれば、月額に改修を含めない契約もあります。まずは契約書で「保守」の範囲がどう書かれているかを確かめてください。書かれていなければ、具体的な作業を例に挙げて、含まれるかどうかを書面で確認しましょう。毎月のように修正を頼んでいるなら、改修の時間を月額に含める契約に見直せないか相談してみる価値があります。

Q3. 見積が「調査費」と「改修費」の2つに分かれています。なぜですか。

直す箇所がどこまで影響するかは、調べてみないと分からないからです。とくに設計書がないシステムでは、まず調査費で影響範囲を確かめ、その結果から改修費を出す2段階の見積が使われることがあります。発注する側にとっても、調査の結果を見てから改修するかどうかを決められるため、いきなり全額を払うより損をしにくい方法です。依頼する前に、調査が終わったら何を受け取れるか(影響する機能の一覧、直す箇所を説明した資料など)を確認しておきましょう。そうすれば、その会社に改修を頼まなかったときにも、調査費がむだになりません。当社でも、既存のコードやシステムの調査報告は有償で、着手の前に範囲と金額をお示しします。

Q4. 小さな改修は、1件ずつ頼むのとまとめて頼むのでは、どちらが安いですか。

同じ画面や同じデータに関わる改修なら、まとめて頼むほうが安くなりやすいです。影響範囲の調査やテスト、本番環境への反映は、改修の件数ではなく反映する回数ごとに必要になるからです。本番環境への反映だけで5万〜50万円かかることもあるので、3件を別々に反映すれば、その費用が3回分かかります。反対に、関係のない機能の改修までまとめると、1回あたりの影響範囲が広がってテストが重くなり、問題が起きたときに原因を探す手間も増えます。同じ画面・同じデータに関わるものはまとめ、関係のないものは分けるのが基本です。

Q5. 改修のあと、直していない機能が動かなくなりました。費用は誰が負担しますか。

契約の種類によって変わります。請負契約(できあがった成果物に対してお金を払う契約)なら、約束した内容を満たしていなければ、受注した会社が修正するのが原則です。準委任契約(作業に対してお金を払う契約)では、成果物を完成させる約束をしていないので、修正にも費用がかかることがあります。どちらの契約でも、「改修後いつまでに見つかった不具合なら無料で直すか」「どの機能をテストするか」を、発注する前に書面で決めておくのが確実です。テストの対象に入れていなかった機能の不具合は、どちらの責任かがあいまいになりやすいためです。契約の種類の違いは開発の契約形態で詳しく解説しています。

Q6. ソースコードが手元になく、作った会社とも連絡がつきません。改修はできますか。

システム本体を直すのは難しくなります。まず昔の契約書を探し、成果物の権利が自社にあるか、ソースコードを引き渡す約束が契約に入っていたかを確認してください。入っていれば、ソースコードの引き渡しを求める根拠になります。どうしても手に入らない場合、現実的な方法は2つです。1つ目は、システム本体には手を入れず、システムが出力するCSVなどのデータを外側で加工し、ほかのシステムにつなぐ方法です。この記事の「他社製システムに画面や帳票だけ追加したいとき」で説明した、外側に足す方法にあたります。2つ目は、そのシステムを使い続けるかどうかを見直し、作り直しや既製サービスへの乗り換えを検討する方法です。ソースコードがないまま本体の改修を続けても、そのたびに調査費がかさむためです。

Q7. システム改修の費用に補助金は使えますか。

自社専用のシステムを改修する費用には、基本的に使いにくいと考えてください。代表的な「デジタル化・AI導入補助金」の通常枠は、事務局に登録されたITツール(業務の手順を1つ以上こなせるソフトウェア)を導入する場合が対象です。補助の対象になる費用も、ソフトウェアの購入費やクラウドの利用料が中心です。既存システムの改修やゼロからの開発が対象になるかどうかは、通常枠の公式ページ(2026年10月9日確認)に書かれていません。そのため、今のシステムを直す場合と、補助金を使って既製のサービスに乗り換える場合で、どちらが安くなるかを比べる考え方もあります。乗り換えが合うのは、直したい業務が多くの会社に共通するもので、自社専用の画面や帳票を残す必要がない場合です。締切や入金までの期間はデジタル化・AI導入補助金の締切で、保守費などが対象外になるケースは補助金で保守費が対象外になるケースで解説しています。

システム改修の費用でお悩みの方へ

システム改修の費用は、ripla社の公開目安で、文言修正なら3万〜10万円、入力項目・検索条件・CSV出力の追加なら10万〜80万円、データベースの変更を伴うと30万〜200万円です。金額の差は、調査・テスト・本番反映の量と、ソースコード・テスト環境・変更してよい権利がそろっているかで生まれます。当社の改修の開始価格である100万円は、試算でエンジニア1人のおおむね13〜25日分で、その中に調査とテストも含まれます。

  • 「1列足すだけ」の見積が高く、妥当かどうか判断できない
  • 他社製のシステムに、画面や帳票だけを足したい
  • 作った会社と連絡がつかず、どこに頼めばいいか分からない
  • 今のシステムを直すべきか、作り直すべきか決められない

1つでも当てはまれば、まずは初回相談をご利用ください。初回相談は無料・30分(オンライン、Google Meet)で、要件が決まっていなくても大丈夫です。相談後に、依頼範囲の候補・進め方・費用の目安をまとめた相談メモをお送りします。当社の価格は、既存システムの改修が100万円〜、PoCが300万円〜、本開発が個別見積です(すべて税別、クラウドなどの実費は別)。

ご相談の際に、①直したい画面のキャプチャ、②直したい理由とその作業に毎月かかっている時間、③システムを作った会社と今の契約の状況(ソースコードを受け取れるか)、の3つをお知らせいただくと、話が早く進みます。パスワードや実際の顧客データは送らないでください。

▶ 既存システムの改修を相談する

関連記事:業務システム開発の費用相場/AI受託開発の費用相場/開発の見積もり比較/内製と外注の判断/開発会社の選び方/開発が失敗する原因

依頼範囲と費用の目安を30分で整理します

この記事の著者

AI革命

AI革命

編集部

AI革命株式会社の編集部です。最新のAI技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。

AI・システム開発は、開始価格を公開しています

既存システムの改修 100万円〜・PoC 300万円〜(税別)。相談内容を送っていただくと、2営業日以内に担当者からご返信します