システム改修の見積書の見方｜工程ごとの内訳・現状調査の費用・相見積で前提をそろえる項目

既存の業務システムを直す見積書を受け取って、金額が妥当か判断できない方に向けた記事です。改修の見積書は合計金額より先に「どの工程が載っているか」と「前提条件・対象外・追加費用になる条件」の欄を読みます。

現状調査（今のプログラムや仕様、データを確かめる作業）が終わる前に出た「改修一式」の見積は、調査で前提が変われば金額も変わりえます。2社の金額が大きく違うときも、どちらが高いか安いかを決める前に、同じ前提を両社に渡して見積をそろえ直すのが先です。

この記事では、工程ごとの「抜けていると後で増える箇所」、調査を別に見積もる見積と一式の見積の違い、2社に同じ条件を送るための記入例、高いと感じたときの選択肢を順に示します。表の金額はすべて説明用の架空の数字で、相場ではありません。

この読み方が合う場合・合わない場合

保守契約や製品の設定変更で済むなら、改修の見積を比べる前にそちらを確かめるほうが早く、費用もかかりません。

改修の見積書に並ぶ工程と、抜けていると後で増える箇所

改修の見積書には、新規開発にはない工程が入ります。今動いているシステムがおかしくならないように直し、元に戻せるようにしておく作業です。下の表は、見積書の工程ごとに「載っていないと後で何が起きうるか」と「相手に聞く質問」をまとめたものです。

「載っていない」と「一式に含まれている」は見分けがつきません。表にない工程を見つけたら、「抜けていますか」と聞くより「この工程は見積のどこに入っていますか」と聞くほうが、相手も答えやすくなります。

現状調査が別立ての見積と、調査なしの「一式」見積の違い

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

調査の前に出た見積は、確定した見積ではない

IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」第二版は、見積を段階に分けて扱っています。構想の段階の「仮試算見積」、計画の段階の「試算見積」、要件定義の後の「概算見積」、画面や帳票などを決める設計（外部設計）を発注者が承認した後の「確定見積」の4段階です。それより前の段階の見積は「確定見積」ではない、とはっきり書かれています。

同じ資料は、前の工程の結果で後の工程の前提が変わった場合に、工程ごとに見積をやり直せるよう、工程ごとに契約を分ける進め方（多段階契約）を採っています。

（出典: IPA「情報システム・モデル取引・契約書」第二版、2026-10-18 確認）

この資料は新規開発を主に想定したものです。ここからは当社の当てはめですが、改修でも、今のシステムの作りを確かめる前に出た見積は、性質としては概算に近いと考えられます。調査で前提が変われば、再見積や追加費用になりうるということです。

「現行どおり」が食い違う理由

同じ資料には、作り直しや改修で「今と同じ動きにする」（現行踏襲）を求めるときの注意も書かれています。発注者は「今動いているシステム」を基準に考え、開発会社は「設計書やソースコード」を基準に考えます。設計書、ソースコード、実際に動いているシステムの三つが一致していないと、「現行どおり」の中身が双方でずれてしまう、という指摘です。

見積書に「現行と同じ動き」「既存仕様どおり」と書かれている箇所は、何を基準にした「現行」なのかを確かめてください。調査が要るのは、このずれを先に見つけるためです。

2種類の見積の比較

元の開発会社と別の会社では、事情が違う

元の開発会社は、自社で作ったシステムなので調査を短くできる場合があります。そのため、元の会社の見積に調査の工程がなくても、それだけで不自然とは言えません。ただし、担当者が替わっている、何年も手が入っていない、途中で別の会社が手を入れた、といった場合は、元の会社でも調査が要ります。

別の会社は、今の作りを知らないところから始めるので、調査が必ず要ります。別の会社の見積が高く見える理由が調査の分だけ、ということもあります。金額差を見るときは、この条件の違いを外して比べてください。

架空の2社の見積を同じ項目に書き写す（説明用・架空データ）

ここでは架空の改修を例にします。受注管理システムの請求書（PDF）に項目を2つ足し、CSVの出力に列を1つ足す改修です。A社は元の開発会社、B社は別の会社です。会社も金額もすべて説明用の架空データで、相場や当社の価格を示すものではありません。

この表の読み方

• 金額の差130万円のうち、50万円は調査の有無です。残りの差の候補は、既存機能の再確認、業務時間外の反映、切り戻しの準備、仕様書の更新です
• A社が安いとも高いとも、この表からは言えません。A社に「記載なし」の行を聞き返し、含まれているなら書き足してもらい、含まれていないなら必要かどうかを決めてから比べます
• B社の改修260万円は、調査の後に変わりうる数字です。B社に頼むなら、調査結果で金額がどう変わったら知らせてもらうか、上限の目安を出してもらえるかを聞きます
• A社の「既存仕様どおり」は、上の「現行どおり」の食い違いが起きやすい書き方です。何を基準にした仕様か（仕様書か、今の動きか）を確かめます

相見積で前提をそろえる項目と記入例

2社の見積を比べられるようにするには、見積をもらう前か、もらった後の聞き返しの時点で、同じ条件を両社に渡します。下の表は、そのまま相手に送れる形にした記入例です（記入例は上の架空の改修のもので、説明用です）。

同じ表を2社に送ると、返ってきた見積の違いが「前提の違い」なのか「作業の量や進め方の違い」なのかを分けられます。

送る前に、元の開発会社との契約にある秘密保持の条項を確かめてください。元の会社の見積書や設計書を別の会社に見せてよいかは、契約の書き方で変わります。この点は追加開発の見積もりを受け取ったらのよくある質問でも扱っています。

見積書に書かれていないと困る条件

金額の欄以外で、見積書か契約書のどちらかに書かれていてほしい条件です。IPAのモデル契約が個別の契約で決める項目としている「作業の範囲と仕様、契約の種類、役割分担、発注者が出す資料、作業環境、納めるものの明細、費用と支払い方法、検査」を、改修の見積書に当てはめています。

改修の途中で範囲が変わったとき

着手した後に範囲や仕様が変わったら、その場の口頭ではなく、変更の理由、内容、費用、日程への影響を書面で残してから進めてもらいます。IPAのモデル契約の変更の手続きに沿った確かめ方は、追加開発の見積もりを受け取ったらで詳しく扱っています。

支払い条件と取適法

2026年1月1日から、下請法が改正されて取適法（中小受託取引適正化法）になりました。対象になる取引では、発注する側は成果物を受け取った日から60日以内に支払期日を決める必要があります。

ただし、自社で使う業務システムの改修を頼む場合は、いつも対象になるわけではありません。公正取引委員会のQ&Aでは、自社で使うソフトウェアの外注が対象になるのは、その部分を自社でもふだん作っている場合で、自社で作る力がない部分の外注は対象にならない、と説明されています。発注する会社と受ける会社の資本金や従業員数の条件もあります（公正取引委員会「取適法Q&A」Q28・Q68、2026-10-18 確認）。

自社に開発の部署があり、その仕事の一部を小さな開発会社に頼むような場合は関係しうるので、支払い条件を決める前に公正取引委員会の資料で確かめてください。この記事では対象かどうかの判断はしません。

元の会社の見積が高いと感じたときの選択肢

高いと感じても、すぐに別の会社へ移るのが正解とは限りません。元の会社は今のシステムを知っているので、調査の手間が少ない分を見積に反映できる立場にあります。選択肢は次のとおりです。

別の会社に移ると決めたら、会社の選び方はシステム改修を頼む会社の選び方、元の会社からの引き継ぎで確かめることは開発会社を変えるときの引き継ぎにまとめています。

自分でAIに読ませてよい部分と、調べないと分からない部分

ChatGPTやClaudeなどの生成AIに見積書を読ませれば、見積書の書面の確認はかなり自分で進められます。

生成AIで進めやすいこと

• 見積書に、前提条件・対象外・有効期限・支払い条件の欄があるかどうかの確認
• 「回帰テスト」「ロールバック」など、見積書の用語の意味
• 上の表の質問をもとにした、開発会社への聞き返しの文面の下書き
• 2社の見積を、同じ項目の表に書き写す作業

見積書を生成AIに入れる前に、社内のルールと、開発会社との秘密保持の条項を確かめてください。

見積書だけでは分からないこと

• 仕様書、ソースコード、今の動きの三つが一致しているか
• 影響範囲の見立てが正しいか（直す箇所とつながっている処理が、見積の想定どおりか）
• 本番のデータの実際の状態（項目の空欄、過去の例外的なデータなど）
• 工数の根拠

これは生成AIの力が足りないからではなく、見積書に書かれていない情報だからです。ソースコードや仕様書を渡せば、生成AIでも影響範囲の洗い出しはかなり進められます。ただ、その前に、ソースコードを第三者や外部のサービスに渡してよいか（利用権・秘密保持）、本番の環境やデータを誰が見てよいか、調べた結果に誰が責任を持つかを決める必要があります。現状調査を有償の作業として誰かに頼むかどうかは、この責任をどこに置くかの判断でもあります。

当社に頼める範囲と費用

AI革命株式会社は、他社が作ったシステムの調査と改修に対応できます。「調査だけ」「調査と改修」のどちらでもご相談ください。言語やフレームワークを理由にお断りすることはありません。最初に、ソースコード・仕様書・環境の情報が手元にあるか、それを使う権利があるかを確かめます。

価格と進め方は、既存システムの改修の価格（100万円〜・税別）と進め方に載せています。

当社が合わない場合もあります。

• 直したい内容が小さく、100万円を下回る費用で済みそうなとき（元の会社や保守契約で頼むほうが合います）
• 保守契約の範囲で対応してもらえるとき
• 市販のパッケージやSaaSの設定変更で済むとき（製品の提供元に頼むほうが早く済みます）

なお、この記事の2社の表は説明用の架空データで、当社が見積を比べた実例ではありません。

受け取った見積書と今のシステムの状況を伺い、前提のずれと依頼範囲の候補を相談メモでお返しします。

見積の前提と改修の範囲を相談する

相談の前に手元にそろえておくもの

初回相談は無料・30分（オンライン、Google Meet）です。要件が決まっていなくても大丈夫です。次のものがあると話が早く進みます。

• 受け取った見積書（社外に見せてよいかを契約で確かめたうえで）。見せられない場合は、工程と金額の欄の構成だけでも構いません
• システムの名前、作った会社、作った時期、最後に手を入れた時期
• 直したい画面・帳票・データと、今の動き・変えたい動き
• ソースコード・仕様書・環境の情報が手元にあるか（中身はまだ送らなくて構いません）

本番のパスワード、顧客の実データ、秘密の情報は、相談の申し込みフォームに書かないでください。

相談後に、業務の棚卸し表・効果の見立て・簡易モックと、依頼範囲の候補・進め方・費用の目安をまとめた相談メモを無料でお送りします。簡易モックは画面のイメージで、動くシステムではありません。初回の30分で確定した見積は出しません。

よくある質問

見積書の有効期限が切れてしまいました。そのまま発注してよいですか

開発会社に、同じ金額と条件で受けられるかを確かめてから発注してください。期限が切れた後は、担当者の空き状況や、その間にシステムに入った変更によって、前提が変わっていることがあります。条件が同じなら、有効期限を延ばした見積書を出し直してもらい、書面をそろえておきます。

元の会社に、他の会社にも見積を頼んだと伝えるべきですか

伝えるかどうかは自社で決めて構いません。伝える場合は「同じ前提で比べたいので、この条件で見積を出してほしい」と、前提をそろえる目的で伝えると話がこじれにくくなります。改修の後も元の会社に保守を頼む予定なら、関係を保つ意味でも、比べる理由を説明しておくほうが進めやすくなります。

元の会社がソースコードを渡してくれません。別の会社に改修を頼めますか

まず、開発時の契約書で、納めるものにソースコードが入っているか、権利が誰にあるかを確かめてください。ソースコードがないと、別の会社は画面の動きなどから推し量るしかなく、調査の範囲も改修の確かさも限られます。引き継ぎで確かめることは開発会社を変えるときの引き継ぎにまとめています。

調査の費用は、改修まで頼めば改修費から差し引かれますか

会社によって扱いが違います。調査の契約を結ぶ前に、改修まで頼んだ場合に調査費をどう扱うか、調査の報告書を他の会社に渡してよいかを聞き、書面に残してください。

見積書に「一式」としか書かれていません。内訳を出してもらってよいですか

求めて構いません。社内の承認で金額の根拠を説明する必要がある、と理由を添えると伝えやすくなります。細かい工数まで出せない会社もあるので、少なくとも「どの工程が入っているか」と「入っていない作業」を出してもらうよう頼むと、比べるのに必要な情報はそろいます。

改修の途中で、もともとあった不具合が見つかりました。直す費用は誰が払いますか

今回の改修で生じた不具合か、改修の前からあった不具合かで扱いが分かれます。前からあった不具合は今回の見積に入っていないため、別に見積もられることがあります。ただし、元の開発時の契約で無償で直す期間が残っていれば、元の会社に直してもらえる場合もあります。見つかった時点で、どちらの不具合か、誰がいつ直すかを書面で決めてから進めてください。

改修の見積の前提をそろえてから決めませんか

改修の見積は、金額だけを並べても比べられません。工程と前提をそろえ、調査が要るかを決めてから比べると、着手後の追加や、思っていた範囲との食い違いを減らせます。

受け取った見積書と今のシステムの状況を伺い、前提のずれと依頼範囲の候補を相談メモでお返しします。初回相談は無料・30分（オンライン）で、要件が決まっていなくても大丈夫です。

見積の前提と改修の範囲を相談する