# システム開発の費用相場と見積もりの内訳：高い・安いの正体と、妥当性の見抜き方 > システム開発の費用相場（人月単価・開発タイプ別レンジ）と、見積もりの内訳・妥当性の見抜き方を、発注者の視点で解説。なぜ同じ要件で見積もりが数倍違うのか、安い見積もりに潜む『抜け』、運用・保守費の考え方、一人×生成AIで費用構造がどう変わるかまで、実プロジェクトの知見から体系化します。 - 公開日: 2026-06-25 - 著者: 友田 陽大 - タグ: 受託開発, システム開発, 発注, コスト最適化, 見積もり, B2B SaaS - URL: https://tomodahinata.com/blog/system-development-cost-estimate-market-rate-guide ## 要点 - システム開発費は『人月単価 × 人数 × 期間』で決まり、原価の約8割は人件費。だから見積もりの差は本質的に『工数の差』 - 相場の目安はSaaS導入~10万円、カスタマイズ50~300万円、スクラッチ300万円~数千万円。ただし非機能要件で大きく変動する - 安い見積もりは、性能・セキュリティ・テスト・運用・保守といった『非機能要件』が抜けていることが多い - 見積もりの妥当性は金額の大小ではなく『内訳の粒度』と『前提・除外事項の明記』で見抜く - 一人×生成AIは中間マージンと調整コストを削るが、安さの根拠は検証ゲートで品質を担保していることにある --- 結論から述べます。**システム開発の見積もりが「高い／安い」の正体は、ほぼ工数（人月）です。** 開発費は「人月単価 × 投入人数 × 期間」で決まり、その原価の約8割は人件費だからです。そして、同じ要件で見積もりが数倍違うとき、その差のほとんどは**「非機能要件（性能・セキュリティ・運用・保守）を見積もりに含めているかどうか」**にあります。安い見積もりが本当に安いのか、それとも「あとで効いてくる費用」が隠れているだけなのか——本記事は、発注者がそれを自分で見抜けるようになるための実務ガイドです。 > この記事は[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)の費用編です。発注全体の意思決定はそちらを参照してください。 --- ## 1. 費用の正体：すべては「人月」に還元される 日本のシステム開発費は、ほぼ例外なく**人月（にんげつ）**で計算されます。 ```text 開発費 ≒ 人月単価 × 投入人数 × 開発期間（月） ``` 「3人のエンジニアが、単価100万円で、4ヶ月」なら、ざっくり 3 × 100万 × 4 = 1,200万円。これが見積もりの骨格です。そして、ここがいちばん大事なのですが——**開発費の原価の約8割は人件費**です。サーバー代やライセンス代ではなく、人の時間にお金を払っているのです。 このことから、3つの実務的な帰結が出ます。 1. **「安くしてほしい」は、本質的には「工数を減らしてほしい」**——機能を削るか、品質を削るか、のどちらかになる。 2. **見積もりの差は、単価の差か、想定工数の差**——同じ要件で倍違うなら、どちらかの前提が違う。 3. **「人を増やせば早く終わる」は誤り**——人を増やすほど調整コストが増える（ブルックスの法則）。これは小さく速いチームが有利な理由でもあります。 ### 人月単価の目安 | 役割・水準 | 人月単価の目安 | |---|---| | 初級〜中堅エンジニア | 60〜100万円 | | 上級・テックリード級 | 100〜160万円 | | 大手SIer・コンサル（多重下請け構造を含む） | 150万円以上 | 大手SIerが高いのは、技術力だけの問題ではありません。**多重下請け構造**により、実際に手を動かすエンジニアの単価に、各層のマージンが乗るためです。発注者が払う150万円のうち、最下層の開発者に届くのは半分以下、ということも珍しくありません。 --- ## 2. 開発タイプ別・費用レンジの目安 「で、結局いくらかかるのか」に答えます。あくまで一般的な相場で、要件次第で大きく変動しますが、判断の出発点として使ってください。 | 開発タイプ | 費用レンジの目安 | 期間の目安 | 例 | |---|---|---|---| | **SaaS導入・設定** | 〜10万円程度 | 即日〜数週間 | 会計・勤怠・CRMなど既製ツールの導入・初期設定 | | **カスタマイズ・小規模開発** | 50〜300万円 | 1〜3ヶ月 | 既製品の拡張、社内向けの小規模業務アプリ、LP・コーポレートサイト＋簡易機能 | | **中規模の業務システム** | 300〜1,000万円 | 3〜6ヶ月 | 受発注・在庫・予約などの業務システム、MVP | | **大規模・スクラッチ（B2B SaaS等）** | 1,000万円〜数千万円 | 6ヶ月〜 | 業界特化のB2B SaaS、決済を含むマルチテナント基盤 | 私が手がけた木材流通のB2B SaaS（経済産業大臣賞を受賞）は最後のカテゴリで、**221本のAPIエンドポイント、17のTerraformモジュール、12のLambda、4ラウンドのセキュリティ監査**——という規模感です。この「何が含まれているか」を知らずに金額だけ比較すると、判断を誤ります。次の章がその核心です。 --- ## 3. 安い見積もりに潜む「抜け」——非機能要件という落とし穴 発注者が最も損をするパターンは、**「安かったから選んだら、運用で破綻した」**です。なぜこれが起きるのか。安い見積もりは、たいてい次の**非機能要件**が抜けているからです。 非機能要件とは、「画面を作る」「ボタンを押すと保存される」といった**機能要件**ではなく、システムが本番で生き延びるための「品質」に関する要件です。 | 抜けがちな項目 | 抜けると何が起きるか | |---|---| | **性能（パフォーマンス）** | 利用者が増えると遅くて使えない。後から作り直し | | **セキュリティ** | 情報漏洩・不正アクセス。賠償と信用失墜 | | **可用性・回復性（DR）** | 障害で止まる、データが消える。復旧できない | | **監視・可観測性** | 障害に気づけない。原因がわからない | | **テスト・品質保証** | リリースのたびにバグ。改修が怖くて触れない | | **運用・保守** | 作って終わり。トラブル対応も改修も追加費用 | これらは「あれば良い」オプションではなく、**本番運用の前提**です。たとえば決済を含むシステムで「冪等性（リトライしても二重課金しない仕組み）」が見積もりに入っていなければ、それは「いつか二重課金事故を起こすシステム」を安く買っている、ということです。 > **見積もりの読み方の鉄則**: 2社の見積もりが「機能は同じなのに金額が倍違う」とき、安い方が優れているのではなく、**高い方に非機能要件が含まれている**可能性を最初に疑ってください。同じ土俵で比較するには、両社に「性能・セキュリティ・テスト・監視・運用・保守を含むか」を明示的に確認します。 ### 運用・保守費という「見えないランニングコスト」 見落とされがちですが、システムは作って終わりではありません。本番リリース後の**運用・保守費は、一般に初期開発費の年15%前後**が目安です。1,000万円で作ったシステムなら、年150万円前後の保守を想定しておく。これを織り込まずに「初期費用が安い」だけで選ぶと、総保有コスト（TCO）で逆転します。 --- ## 4. 見積もりの妥当性を見抜く5つのチェック 金額の大小ではなく、**見積書の「構造」**を見ます。妥当な見積もりは、次の5点を満たしています。 ### チェックリスト - [ ] **内訳の粒度が適切か**——「開発一式 800万円」のような丸めた見積もりは危険信号。要件・工程ごとに工数（人日／人月）が分解されているか。 - [ ] **前提条件と除外事項が明記されているか**——「〜は別途」「〜は含まない」が書かれているか。曖昧な見積もりは、後から追加費用の温床になる。 - [ ] **非機能要件が項目化されているか**——性能・セキュリティ・テスト・運用が独立した項目として存在するか。 - [ ] **要件定義・設計の工程が含まれているか**——いきなり実装から始まる見積もりは、要件の曖昧さを発注者に押し付けている。 - [ ] **保守・運用の条件が示されているか**——リリース後の対応範囲・費用・SLAが書かれているか。 ### 「不確実性」をどう握るか——固定価格 vs 準委任 要件が固まりきっていない段階で**固定価格（請負）**を握ると、開発側はリスクを織り込んで高めに見積もるか、安く受けて後で揉めるかのどちらかになります。要件が流動的なら、**準委任（時間・工数ベース）**で小さく始め、要件が固まった部分から請負に切り替える——というハイブリッドが、双方にとって健全です。「すべて固定価格で安く」は、たいてい幻想です。 --- ## 5. 一人 × 生成AI は、費用構造をどう変えるか 近年、私のような**一人（少人数）× 生成AI**の開発スタイルが、費用面で現実的な選択肢になっています。なぜ安くできるのか——その根拠を正直に説明します。 | 安くなる理由 | 内容 | |---|---| | **中間マージンがない** | 多重下請け構造の各層マージンが乗らない。発注額がそのまま開発に向かう | | **調整コストが小さい** | 会社間・チーム間の調整工数がゼロ。意思決定者と直接対話して要件を高速に回せる | | **生成AIによる実装の高速化** | コードを書く速度が上がり、同じ工数でより多くを実装できる | | **一気通貫** | 要件定義からインフラ・運用まで一人で担い、引き継ぎロスがない | ただし——ここが最も重要です——**「安い」は「品質を削った」と同義であってはなりません**。生成AIは実装を速くしますが、その出力を**そのまま信用しない検証ゲート**（型安全な境界検証・自動テスト・静的解析・セキュリティ監査）を通して初めて本番品質になります。 私の場合、木材流通DXでは**全221エンドポイントの認証欠落0件**を第三者ペネトレーションテストで実証し、決済基盤では**本番稼働中の二重課金0件**を冪等性という構造で担保しています。「速くて安いが、検証で固めているから安全」——これが、一人×生成AIの見積もりが信頼に足るかどうかの分かれ目です。逆に、検証ゲートを説明できない「安いだけ」の相手は、別の意味で高くつきます。 --- ## よくある質問（FAQ） ### Q. システム開発の費用相場はいくらですか？ 開発タイプによります。SaaS導入は〜10万円程度、既製品のカスタマイズや小規模アプリは50〜300万円、中規模の業務システムは300〜1,000万円、決済を含むB2B SaaSのスクラッチ開発は1,000万円〜数千万円が目安です。費用は「人月単価 × 人数 × 期間」で決まり、原価の約8割が人件費なので、本質的には工数の問題です。 ### Q. なぜ同じ要件なのに、会社によって見積もりが数倍違うのですか？ 主因は2つです。(1) 単価の差——大手SIerは多重下請け構造のマージンが乗るため高くなります。(2) 想定工数・前提の差——非機能要件（性能・セキュリティ・テスト・運用）を含むかどうかで大きく変わります。安い見積もりは、これらが抜けている可能性を疑ってください。 ### Q. 安い見積もりを選んで大丈夫ですか？ 金額だけで判断しないでください。安さの理由が「中間マージンや調整コストの削減」なら健全ですが、「非機能要件や品質保証を削った」結果なら、運用で破綻し総コストで逆転します。見積もりの内訳・前提・除外事項を確認し、同じ土俵で比較することが重要です。 ### Q. 運用・保守費はどれくらい見ておくべきですか？ 一般的な目安は、初期開発費の年15%前後です。1,000万円で作ったシステムなら年150万円前後。これを織り込まずに初期費用だけで判断すると、総保有コスト（TCO）で高くつきます。見積もり段階で保守の範囲・費用・対応条件を確認してください。 ### Q. 要件がまだ固まっていません。それでも見積もりは取れますか？ 概算は取れますが、固定価格で握るのは危険です。要件が流動的な段階は準委任（工数ベース）で小さく始め、固まった部分から請負に切り替えるハイブリッドが健全です。要件定義そのものを最初の工程として見積もりに含める会社を選んでください。 --- ## まとめ：金額ではなく「構造」を見る システム開発の費用で損をしないために、押さえるべきは次の通りです。 1. **費用は「人月単価 × 人数 × 期間」で決まり、原価の8割は人件費**——見積もりの差は工数の差。 2. **相場の目安はSaaS導入~10万円、カスタマイズ50~300万円、スクラッチ300万円~数千万円**——非機能要件で大きく変動。 3. **安い見積もりは非機能要件（性能・セキュリティ・テスト・運用・保守）が抜けがち**——同じ土俵で比較する。 4. **妥当性は金額ではなく「内訳の粒度」と「前提・除外事項の明記」で見抜く**。 5. **一人×生成AIの安さは中間マージン削減が根拠で、品質は検証ゲートで担保する**——「安いだけ」とは別物。 見積もりの妥当性に不安がある、あるいは「この金額は適正か」を第三者の視点で確認したい——そうしたご相談も歓迎します。要件の棚卸しから、何にいくらかかるのかの構造化まで、発注者の側に立って整理します。