Web システム開発の費用と期間の相場｜規模別早見表と見積の読み方

Web システムの費用と期間は、見積の前提をそろえて読む

「Web システムを作りたいが、いくらかかるのか見当がつかない」「複数社から見積を取ったら 300 万円と 2,000 万円で桁が違った」「開発期間 6 ヶ月と言われたが、業務で使えるのはいつなのか」。Web システムの新規開発やリプレイスを検討する発注担当者や情報システム担当が、最初に突き当たるのはこの 3 つの疑問です。

比較サイトで「平均 200 万円」「50 万〜500 万円」といった相場を見てから見積を受け取ると、金額の差に戸惑うかもしれません。

この記事では、規模別の費用と期間の早見表を最初に示し、金額の決まり方 (人月単価と見積の内訳)、金額を左右する要因、期間の決まり方と実質納期、AI 駆動開発で縮む工程を順に扱います。数字はいずれも社内で予算を組むための目安です。依頼先の選び方や契約の進め方といった発注の総論は Web システム開発を依頼するなら に、見積書の読み方や交渉はシステム開発全般を扱う システム開発の見積もり (見積書サンプルとチェックリスト) にまとめています。

結論: 費用と期間の早見表

Web システムの費用は、機能数・外部連携の数・データモデルの複雑さで帯が決まります。金額はいずれも税抜です。期間は、これまでの一般的な進め方 (AI 駆動開発を前提にしない場合) で要件定義から納品までにかかる目安で、着手待ちと発注側の受入テストは含みません。

規模	費用 (税抜)	期間	該当する例	判別の目安
小規模	300 万〜800 万円	2〜4 ヶ月	社内の単一業務ツール、Excel 業務の Web 化、SaaS MVP	主要機能 1〜2 個・外部連携 1〜2 本・5〜10 テーブル
中規模 (1 領域)	800 万〜1,500 万円	3〜6 ヶ月	受発注・顧客管理・在庫管理などの業務 1 領域	主要機能 3〜5 個・外部連携 3〜5 本・10〜20 テーブル
中規模 (複数領域)	1,500 万〜2,500 万円	6〜9 ヶ月	複数の業務領域をまたぐシステム、複数拠点で使う業務 Web	主要機能 6〜10 個・20〜40 テーブル・外部連携 5〜10 本・承認や状態遷移のある業務フロー
大規模	2,500 万円以上	9 ヶ月以上	全社基幹に近いシステム、大規模な BtoC サービス	10 本以上の外部連携・24 時間の稼働要件・監査対応

小規模・中規模・大規模の区切りは、システム開発の見積もり (見積書サンプルとチェックリスト) の「種類別の費用相場」の表にある Web システムの行と同じです。中規模は幅が広いため、この記事では業務の領域数で 2 行に分けています。

見積に書かれた「開発期間」は業務で使い始められるまでの期間と一致しないため、着手待ちや受入テストを足した実質納期の読み方を、後半の「期間の目安と、期間が決まる仕組み」で扱います。

Web システムの費用相場

規模別の目安と該当例

小規模 (300 万〜800 万円) は、勤怠・社内ポータル・簡易 CRM のような社内向けの単一機能ツールが典型です。データモデルは 5〜10 テーブル程度で、外部連携は Slack や Google Workspace への通知くらい。画面はフォームと一覧が中心で、認証は SSO で外部サービスに任せる構成が多くなります。SaaS の MVP もこの帯に入ります。公開事例では、AI 駆動開発で 3 週間で作った HR テック SaaS の MVP が 400 万〜600 万円 (税抜) です (SaaS MVP を 3 週間で本番投入した事例)。MVP の費用の詳細は SaaS の MVP 開発の費用と期間 にまとめています。

中規模・1 領域 (800 万〜1,500 万円) は、業務システム化の中心になる帯です。受発注・顧客管理・在庫管理といった業務の 1 領域を扱い、10〜20 テーブルのデータモデルと、会計・EC・決済などとの 3〜5 本の外部連携を含みます。

中規模・複数領域 (1,500 万〜2,500 万円) は、複数の業務領域をまたぐ Web システムです。20〜40 テーブル、5〜10 本の外部連携を持ち、承認や状態遷移が絡む業務フローを含む構成が典型です。中堅企業の基幹周りや、複数拠点で使う業務システムがここに入ります。

大規模 (2,500 万円以上) は、全社基幹に近い規模です。24 時間の稼働要件、10 本以上の外部連携、監査対応、複数拠点といった要素が重なります。この規模では既存システムの置き換えを伴うことが多く、レガシー刷新の費用と期間 や システムリプレイスの進め方完全ガイド の内容も関係してきます。

種類別の傾向

同じ規模の帯でも、Web システムの種類によって費用がかさむ場所が違います。自社の案件がどれに近いかを先に決めておくと、見積のどこを重点的に見ればよいかが分かります。

種類	例	費用がかさむ場所
社内業務 Web	在庫管理、勤怠、案件管理、承認フロー	紙運用や業務の例外を吸収する要件定義と業務ロジック
BtoB SaaS	プロジェクト管理ツール、業務特化型 SaaS	マルチテナント設計・課金・権限を最初から作ること
BtoC Web サービス	会員制メディア、マッチング、予約サービス	アクセス集中への対策、UI / UX とパフォーマンス
管理画面付き Web	LP と管理 CMS、EC の管理画面、コンテンツ配信	公開側と管理側の二重構造

とくに BtoB SaaS は、マルチテナントと課金を後から入れると作り直しが大きくなるため、最初の版から費用の下限が高くなりがちです。

比較サイトの相場と見積の桁が違う理由

検索上位の相場記事では、コーポレートサイト・予約サイト・マッチングサイト・EC などを数十万〜500 万円程度で紹介していることが多く、この記事の早見表とは桁が違って見えます。これは、どちらかが誤っているというより、対象にしている「Web システム」が違うためです。

比較サイトの数字の多くは、テンプレートや CMS、既製のパッケージで大部分を満たせる「サイト型」を前提にしています。一方、業務で使う Web システムでは、次の要素が加わるたびに工数が積み上がります。

• 管理画面 (検索・CSV 出力・監査ログなど、運用担当者向けの画面)
• 多段階の権限 (テナント管理者・部門管理者・一般・閲覧のみの 4 段階など)
• 会計・販売管理・SFA などの社内外システムとの連携
• 紙や Excel で回していた業務の例外処理

受け取った見積が比較サイトの相場より高いときは、これらの要素が見積に含まれているかを確かめてください。含まれているなら、金額の差はそのまま工数の差です。逆にこれらが必要なのに安い見積が出ているなら、見積の範囲から漏れている可能性があります。

金額の決まり方: 人月単価 × 工数 + 諸経費

人月単価の目安

Web システムの開発費は、ほとんどが人件費です。基本の計算式は「人月単価 × 工数 (人月) + 諸経費」で、1 人が 1 ヶ月働く量を 1 人月と数えます。人月単価は担当者の役割と経験で変わり、目安は次のとおりです。

役割	人月単価の目安
ジュニアエンジニア (実務 2〜3 年)	60〜80 万円
中堅エンジニア (実務 4〜7 年)	80〜120 万円
シニア / テックリード	120〜180 万円
PM / PL	100〜160 万円
UI / UX デザイナー	80〜130 万円

同じ工数でも、誰が何人月入るかで総額は変わります。

見積の内訳 6 ブロックと比率の目安

見積書の項目名は会社ごとに違いますが、次の 6 ブロックに当てはめると構造が見えます。比率は総額に占める目安です。

ブロック	主な作業	総額に占める比率の目安
要件定義	ヒアリング、業務整理、機能一覧化	10〜20%
設計	画面設計、DB 設計、API 設計、インフラ設計	15〜25%
実装	フロントエンド・バックエンド・管理画面の開発	35〜50%
テスト	単体・結合・受入テスト、不具合の修正	10〜20%
インフラ	サーバー構築、CI / CD、監視、初期セットアップ	5〜10%
デザイン	情報設計、UI デザイン、デザインシステムの構築	5〜15%

見積を比べるとき、実装の金額だけを並べて安いほうを選ぶと失敗しやすくなります。要件定義とテストが薄い見積は、実装の後に追加費用が出やすいためです。まず、要件定義とテストで総額の 20〜40% 程度が確保されているかを確かめてください。

「一式 500 万円」のように内訳のない見積は、着手後に追加費用が積み上がっても、どこが増えたのかを議論できません。「要件定義 80 / 設計 120 / 実装 130 / テスト 80 / インフラ 40 / デザイン 50 万円」のように工程ごとに分かれていれば、ブロックごとの妥当性を発注側でも確かめられます。

試算例 (仮定の要件): 50 名で使う案件管理システム

小規模帯の典型例として、50 名程度の社内チームが使う案件管理システムを試算します。機能は案件の登録・検索・ステータス管理、担当者の割り当て、管理者と一般の 2 段階の権限、Slack 通知、CSV 出力です。実在の案件ではなく、要件を仮定した試算です。

ブロック	目安
要件定義	80 万円
設計	120 万円
実装	340 万円
テスト	80 万円
インフラ	40 万円
デザイン	40 万円
合計	約 700 万円

期間は約 4 ヶ月を見込みます。要件定義とテストの合計は 160 万円で、総額の約 23% です。

見積を左右する 7 要因

見積を読むときは、金額の絶対値より、金額を左右する 7 要因に分けて見るほうが判断を誤りにくくなります。

1. 機能数と業務ロジックの複雑さ。画面数より、業務ロジックが分岐する条件の数が費用を押し上げます。単純な登録・一覧の画面と、承認フローや状態遷移のある業務では、同じ画面数でも工数は 2〜3 倍が目安です。管理画面の工数は公開側の 30〜80% が目安で、検索・CSV 出力・監査ログを積むほど比率が上がります。
2. データモデルの複雑さ。テーブル数に加えて、履歴管理の要件や、複数の企業が同じシステムを使うマルチテナントかどうかで工数が変わります。
3. 外部連携の数と難易度。会計・販売管理、決済、SFA / CRM、SSO、通知などの連携は、1 本ごとに 30〜150 万円程度の工数が目安です。連携先の仕様が公開されていない、テスト環境がない、といった条件では工数が増えます。
4. セキュリティと権限。認証・認可、監査ログ、暗号化、脆弱性診断、業界の基準への準拠の有無で費用が変わります。権限が多段階になると、ほぼすべての画面と API に権限判定が入り、テストの工数も大きく増えます。
5. 稼働率と運用体制。稼働率 99% と 99.9% の違いや、24 時間対応か営業時間内の対応かで、インフラ構成と運用体制の費用が変わります。
6. デザインとフロントエンドの作り込み。既存のデザインシステムを使うか専用デザインを起こすか、スマートフォン対応をどこまで行うかで費用が変わります。多言語・多通貨への対応は、後から追加すると最初から入れるより高くつきます。
7. 運用引き継ぎとドキュメントの範囲。運用マニュアル、API ドキュメント、開発者向けの引き継ぎ資料をどこまで納品物に含めるかで費用が変わります。

複数社の見積を比べるときは、7 要因のそれぞれで、どこまでを見積の範囲に含めているかをそろえます。金額だけで「A 社が安い」と判断すると、あとから「セキュリティ要件は別途」「運用マニュアルは別料金」と追加費用が重なることがあります。

FIXIT

複数社の見積、金額の差が大きすぎて、どれを信じていいか分からないんだけど。

金額の差より、前提条件の差を見るのがおすすめですよ。見積ごとに、含まれる範囲が違うんです。

Hinata

追加費用が出る条件と検収基準、この 2 つをそろえて比べると、実際の総額が見えてきますよ。

FIXIT

「安すぎる見積」ってどう見分けるの？

Hinata

追加費用が出る条件を聞いてみてください。答えを濁すなら、あとで費用が増えやすいですよ。

期間の目安と、期間が決まる仕組み

工期は工数に比例して伸びない

IPA (情報処理推進機構) の 「ソフトウェア開発データ白書 2018-2019」の紹介資料 は、白書のデータから「工期は工数の 3 乗根に比例する傾向が見られる」と述べています。3 乗根で計算すると、工数が 8 倍でも工期はおよそ 2 倍にとどまります。

裏返すと、規模が大きい案件ほど、月あたりに投入する人数を増やして工期を収めています。同じ作業量のまま期間だけを大きく縮めようとすると、人数を増やすことになり、調整やレビューの手間も増えます。人を倍にすれば期間が半分になる、という計算は成り立ちません。

見積の「開発期間」と実質納期は違う

見積の期間を読むとき、開発期間だけを見ると、業務で使えるようになる時期を見誤ります。実質納期は、次の 5 つの期間の合計です。

1. 着手待ち期間。契約から作業開始までの期間で、開発会社の体制次第で 1 週間〜1 ヶ月かかることがあります。
2. 要件定義・設計期間。実装の前段で、中規模なら 1〜2 ヶ月、大規模なら 2〜4 ヶ月が目安です。
3. 実装期間。見積で「開発期間」として示される中心の期間です。
4. 受入テスト期間。発注側が本番相当の環境で確かめる期間で、中規模なら 2〜4 週間、大規模なら 1〜2 ヶ月が目安です。
5. 運用引き継ぎ期間。ドキュメントの受け渡しや運用手順の確認にあたる期間で、1〜2 週間が目安です。

たとえば中規模の案件で、見積の「開発期間 4 ヶ月」が実装だけを指している場合、上の目安を足すと、着手待ち 1〜4 週間、要件定義・設計 1〜2 ヶ月、受入テスト 2〜4 週間、引き継ぎ 1〜2 週間が加わります。合計は 8〜18 週間で、実質納期は約 6〜8 ヶ月になります。見積の「開発期間」に要件定義や受入テストが含まれているかは会社によって違うため、どの期間を指しているかを必ず確かめてください。

リリース日から逆算して発注時期を決める

業務で使い始めたい日が決まっているなら、実質納期から逆算して、いつまでに発注すべきかを決めます。

1. 業務で使い始めたい日を決める
2. そこから運用引き継ぎと受入テストの期間を引き、開発側の作業が終わっているべき日を出す
3. さらに実装期間と要件定義・設計期間を引き、作業開始日を出す
4. 着手待ち期間を引き、契約日を出す
5. 相見積と社内の稟議にかかる期間を引き、見積を依頼すべき日を出す

最後の見積依頼と稟議の期間は会社ごとに大きく違うため、自社の過去の稟議にかかった期間を当てはめてください。逆算した日付が過ぎているなら、初期スコープを絞る、段階発注にする、といった進め方の見直しが必要です。

AI 駆動開発で縮む工程・縮まない工程

縮む工程

AI 駆動開発で期間が縮むのは、主に次の 3 つの工程です。

• 仕様のすり合わせ。AI が質問リストや画面遷移図、データモデルの草案を作り、それを使って要件レビューを進めます。公開事例の SaaS MVP では、通常 1 週間かかる仕様すり合わせが 2 日で終わりました。
• 足場づくり。アプリの骨組み、認証、データベースのスキーマ、API といった定型部分を AI に並行して作らせます。同じ事例では、この足場づくりを 4 日で終えています。
• 実装。テストを先に書き、AI に実装させ、人がレビューする分担で進めます。進め方は AI 駆動 TDD で解説しています。

縮まない工程

一方で、AI を使っても縮みにくい工程があります。

• 発注側の受入テスト。業務担当者が時間を取れるかで決まります。
• 外部連携先との調整。連携先の対応スケジュールに左右されます。
• 何を作るかの判断と、要件・コードのレビュー。人が責任を持つ工程です。
• 本番データで見つかる想定外への対応。業務の理解が要ります。
• 運用の引き継ぎ。期間を詰めすぎて運用ドキュメントが薄くなると、引き継ぎ後に再依頼が発生します。

要件レビュー・画面確認・デプロイ承認といった発注側の作業も、AI では肩代わりできません。

公開事例の数字

FIXIT が公開している 2 つの事例では、期間が次のように変わりました。

事例	通常の見込み期間	実績の期間	費用の目安 (税抜)
SaaS MVP の新規開発	2〜3 ヶ月	3 週間	400 万〜600 万円
基幹システムのリプレイス	8 ヶ月	4 ヶ月	1,800 万〜2,400 万円

どちらも AI 駆動開発での費用です。基幹リプレイスは、この記事の区分では中規模 (複数領域) に当たります。どちらの事例でも期間は半分以下になりました。ただし短い期間に作業が集中するため、発注側も同じペースで要件レビューや画面確認に時間を割く必要があります。規模別の事例と内訳は AI 駆動開発の費用と期間の事例まとめ に並べています。

「AI を使うなら安くなるはず」と見積を大きく値切ると、縮まない工程に使う時間が削られ、品質が下がります。見積を比べるときは、AI 駆動開発を前提にした見積と従来の進め方の見積を混ぜず、どの工程が縮んでいるかを確かめてください。

安すぎ・盛りすぎ見積を見分ける 5 つの質問

複数社の見積を比べるとき、次の 5 つを質問すると、見積の妥当性を判断しやすくなります。

1. どの機能が初期スコープに含まれ、どの機能が後から追加する扱いか。この線引きが曖昧な見積は、契約後に「それは範囲外」と言われるおそれがあります。
2. 追加費用が発生する条件は何か。要件変更・機能追加・打ち合わせ回数の超過などで、金額がどう決まるかを事前に確かめます。
3. 検収基準は何か。「動く」なのか「テストがすべて通る」なのか「業務で使える」なのか。基準が曖昧だと、納品後に揉めます。
4. 既存システムや連携先の実データで動作を確かめるか。開発環境で動くところまでの見積だと、本番データで出る想定外への対応が別途になることがあります。
5. 納品後の初期サポートはどこまで含まれるか。1 週間か、1 ヶ月か、3 ヶ月かで、運用開始後にかかる費用が変わります。

質問に「あとで詰めましょう」と答えを濁す見積は、契約後に想定外の費用が出やすくなります。

安すぎる見積の典型は、初期スコープを絞りきったうえで、あとから必要になる要素をすべて追加費用の扱いにするものです。契約時は安く見えても、リリースまでに追加が重なり、発注担当が社内で追加予算の稟議を通すことになります。盛りすぎた見積の典型は、考えうる要素をすべて初期スコープに入れ、予備費も厚く乗せるものです。安全ではありますが、実際には使わない機能にも費用を払うことになります。

費用と期間を抑える進め方

費用や期間を抑える方法は、値引きの交渉より、発注の進め方に多くあります。

1. 段階発注にする。要件がまだ動きそう、社内で本当に使われるか確信が持てない、予算を一度に確保しにくい、といった案件では、要件定義だけを先に切り出して発注し、その結果を見て次の予算を決めます。
2. 初期スコープに優先順位をつける。最初のリリースで必ず要る機能と、あとから足せばよい機能を分けます。優先順位があれば、開発側は予算に合わせた初期スコープを提案できます。
3. 発注側の確認体制を先に決める。要件レビュー、画面確認、受入テストを誰がいつ行うかを決めておくと、確認待ちで期間が延びるのを防げます。
4. 内製で持つ範囲を決める。運用や軽微な改修を自社で持つなら、その分の引き継ぎを見積に含めてもらいます。開発会社に残す保守と追加開発の費用の内訳は、システム保守費用の相場と根拠 で扱っています。
5. 既製品で満たせる部分を切り出す。認証・決済・CMS など、既存のサービスやフレームワークで満たせる部分が多いほど、独自に作る範囲が減り、フルスクラッチの 4〜7 割程度の費用が目安です。ただし独自の要件が多いと、既製品の制約を回避する実装で逆に高くつくことがあります。

発注前のチェックリスト

費用と期間の両面で、発注前に確かめておきたい項目を並べます。

• 自社の案件が、早見表のどの規模の帯と、どの種類に近いかを把握しているか
• 見積が 6 ブロックに分かれていて、要件定義とテストで総額の 20〜40% があるか
• 7 要因の範囲と、追加費用の発生条件・検収基準をそろえて比べているか
• AI 駆動開発を前提にした見積と、従来の進め方の見積を混ぜて比べていないか
• 実質納期 (着手待ち + 要件定義・設計 + 実装 + 受入テスト + 運用引き継ぎ) で計画し、リリース希望日から見積を依頼すべき日を逆算しているか
• 段階発注にするかと、契約途中の機能追加の扱い (請負か準委任か) を契約時点で決めているか
• 軽微な改修や追加開発まで含めた保守の予算として、年間で開発費の 15〜20% 程度を見込み、クラウドの利用料などの月額費用は別に見ているか

Web システム開発のご相談

FIXIT は AI 駆動開発のクリエイティブスタジオとして、Web システムのプロダクト開発を、要件が固まりきっていない段階から支援しています。見積では、この記事で扱った 6 ブロックの内訳と、実質納期に含まれる期間を分けてお示しし、AI で縮む工程と縮まない工程がどこかを発注側と共有したうえで進めます。

自社の案件がどの帯に入るかをまず確かめたい場合は、条件を選ぶだけで概算と工程ごとの内訳を出せる システム開発の費用シミュレーター を登録なしで使えます。概算を見たうえで、段階発注の組み方や発注時期の逆算を相談したい場合は お問い合わせ からご連絡ください。

サービスの内容は AI 駆動開発 で紹介しています。SaaS の MVP なら SaaS MVP 開発、既存システムの置き換えなら システム刷新・リプレイス もあわせてご覧ください。