追加の要望に「概算見積もり」が届いた。金額が妥当か判断する5つの見方と確認の進め方

2026年11月1日

稼働中のシステムに「この機能を足したい」と伝えたところ、数日後に「概算で◯◯万円程度です」という見積もりが届いた。高いのか安いのか、そもそも何の金額なのかが分からず、返事ができずに止まっている。追加改修の見積もりを受け取った担当者から、とてもよく聞く悩みです。

「追加の要望を伝えたら概算見積もりが出たが、金額が妥当か判断できない」

先に結論をお伝えします。金額の高い・安いは、金額だけを見ても判断できません。判断できるのは「何を作る前提の金額か」「どこまでが含まれ、何が含まれないか」「金額がどう変わりうるか」を確かめたあとです。この記事では、追加改修の概算見積もり（＝詳しく調べる前の、おおまかな金額の見立て）を受け取ったときの5つの見方と、開発会社に確認するときの進め方を解説します。

概算見積もりは「確定金額」ではない

まず、概算見積もりの性格を押さえましょう。概算は、要望を聞いた段階で、既存のシステムの中身を詳しく調べる前に出す「おおまかな見立て」であることが一般的です。

開発会社の側にも事情があります。追加改修では、既存のプログラムのどこに手を入れる必要があるかを調べないと、正確な作業量が分かりません。そのため、調査前の概算には幅を持たせたり、前提条件を付けたりします。これは不誠実というより、情報が足りない段階での自然な出し方です。

つまり、概算を受け取った時点で「この金額で決まり」でも「ぼったくり」でもありません。次の段階（調査・確定見積もり）に進むかどうかを判断する材料、と考えるのが適切です。

追加改修が「思ったより高い」と感じやすい理由

新規開発と比べて、追加改修は金額の感覚がずれやすい作業です。開発会社側の事情として、一般的に次のような点があります。

既存部分を読み解く時間がかかる：すでにあるプログラムの構造を調べないと、安全に手を入れられません。
既存機能への影響を確かめる必要がある：新しい部分だけでなく、これまで動いていた機能が壊れていないかも確認します。この確認作業（回帰テスト）が、見た目の変更量に比べて大きくなることがあります。
画面上は小さな変更でも、裏側の変更は大きいことがある：たとえば「項目を1つ足す」だけでも、データの保存場所、画面、帳票、他システムとの連携まで影響する場合があります。

発注者から見える「ボタン1つ」と、開発側が確かめる範囲は一致しません。この差を埋める質問が、このあとの5つの見方です。

概算見積もりの金額を判断する5つの見方

見方1：「何を作る前提か」が要望と合っているか

最初に見るのは金額ではなく、見積書に書かれた作業内容です。自分が伝えた要望と、見積もりが前提にしている内容がずれていないかを確かめます。

伝えたのは「一覧画面に絞り込みを足したい」なのに、「検索機能の全面改修」として見積もられていないか
逆に、自分が期待していた範囲（例：スマホ表示への対応）が前提に入っていないか

要望の伝え方が曖昧だと、開発会社は安全側（大きめ）に解釈して見積もることがあります。金額が想像より大きいときは、まず前提の食い違いを疑ってみてください。

見方2：作業の内訳（工程ごとの項目）が分かれているか

「追加改修一式」だけの見積もりでは、妥当性を判断できません。一般的には、次のような工程に分けて示してもらえると比べやすくなります。

工程	内容
調査・設計	既存の仕組みを調べ、変更の方針を決める
開発（実装）	プログラムを書く・直す
テスト	追加部分と、既存の機能が壊れていないか（回帰テスト）を確かめる
リリース	本番環境に反映する
管理・調整	打ち合わせ、進捗管理、ドキュメント更新

概算の段階では、細かい人日（＝1人が1日働く作業量）までは出せないこともあります。それでも、工程ごとの大まかな比重は聞けるはずです。特に、追加改修では「テスト」の比重が大きくなりやすいことを知っておくと、金額の見方が変わります。

見方3：金額の根拠（人日×単価）が説明できるか

多くの見積もりは「作業量（人日や人月）×単価」で組み立てられています。金額そのものが妥当かを判断するより、次のことを聞くほうが現実的です。

どのくらいの作業量（人日）を見込んでいるか
担当者の役割ごとの単価の考え方（設計者・開発者など）が、これまでの契約と大きく違わないか

過去に同じ開発会社から見積もりを受け取っている場合は、単価が変わっていないかを比べるのが有効です。変わっているなら理由を尋ねてよい点です。なお、単価の水準は会社の規模や役割で幅があり、ここで相場の数字を断定することはしません。

見方4：前提条件と「含まれないもの」が書かれているか

概算見積もりで最も見落とされやすいのが、前提条件の欄です。たとえば次のような書き方があります。

「既存システムの構造に大きな問題がない場合」
「仕様の詳細は別途打ち合わせで確定する場合」
「データ移行・本番での確認作業は含まない」

こうした前提が崩れると金額が変わる、という意味です。「金額が変わる条件」を先に聞いておくことが、あとからの食い違いを防ぎます。前提条件は、確定見積もりの段階でどう扱われるのかまで確認しましょう。

見方5：確定までの進め方（調査の有無・上限・期限）が示されているか

概算から確定金額に進むために、調査や設計の工程が必要なことがあります。そのとき確認したいのは次の点です。

調査・設計だけを先に小さく依頼できるか（その費用はいくらか）
確定見積もりはいつ出るか
概算から確定で、金額が変わる幅の目安はどのくらいか
作業を始める前に、発注者の承認を取る手順になっているか

経済産業省の「情報システム・モデル取引・契約書」は、システム開発の取引で、仕様の変更や追加が生じたときに、その費用や納期の扱いを事前の手続きに沿って決めていく考え方を示しています。

📰 出典：経済産業省「情報システム・モデル取引・契約書」

ご自身の契約書に、変更や追加が生じたときの手続き（変更管理）が書かれているかを確認してください。書かれていれば、その手順に沿って進めるのが基本です。契約の読み方など個別の判断は、弁護士や専門家に確認してください。

追加費用になるかどうか自体の見分け方は、次の記事で解説しています。

あわせて読みたい

受け入れ確認で足りない操作が見つかった。追加費用はかかる？無料で直してもらえる？判断の5つの手がかり受け入れ確認で足りない操作が見つかったとき、追加費用になるか無料で直るかの分かれ目を解説。契約書や設計書で確かめる5つの手がかり、チェックリスト、開発会社への質問例つき。

開発会社に聞く前にやっておく準備

質問する前に、自分の側で次の3つを整理しておくと、会話が早くなります。

要望の目的を一文で書く：「何ができるようになれば成功か」を書きます。機能名だけでなく目的が分かると、開発会社がより小さな方法を提案できることがあります。
必須とあれば嬉しいを分ける：金額が合わないとき、後者を削る相談ができます。
予算の目安と期限を決めておく：予算の幅を伝えると、その範囲で実現する方法を考えてもらいやすくなります。

やりがちな失敗

金額だけを見て即答する：「高い」と感じて断る、あるいは「そんなものか」と承認するのは、どちらも前提が確認できていない状態の判断です。
メールの一文で追加を頼む：曖昧な依頼は、大きめの見積もりにつながりやすくなります。
概算のまま作業が始まる：概算の承認が、確定金額の承認と受け取られないよう、書面（メールなど記録に残る形）で「概算であること」と「確定の手順」を確認します。
他社に相見積もりを取ろうとして、既存システムの情報を渡さない：追加改修は既存の仕組みを知らないと正確に見積もれません。渡せる資料の範囲は、契約と秘密保持の取り決めを確認してから決めます。