Web システム 受託開発の費用と納期の実数値｜規模別レンジと見積の読み方

「Web システムを新しく作りたいが、いくらかかるか分からない」「複数社から見積を取ったが、300 万と 2,000 万で桁が違い、どれが妥当か判断できない」「納期 6 ヶ月と提示されたが、実際にいつから使えるかが読めない」。Web システムの新規開発やリプレイスを検討する情シス・発注担当から、この 3 つの相談を毎月のように受けます。本記事は、Web システム受託開発の費用と納期の実数値を、規模別レンジと見積の読み方から、AI 駆動開発のクリエイティブスタジオが実例ベースで整理した実務ガイドです。

結論: 費用は 4 段階のレンジで、納期は「実質」を分解して読む

先に結論を書きます。Web システムの費用は、機能数と外部連携数で 4 段階のレンジに分かれます。300 万〜、800 万〜、1,500 万〜、3,000 万〜、というレンジが標準で、それぞれ想定される規模と、レンジの中で価格が上下する要因が異なります。納期のほうは、開発期間そのものよりも「着手待ち期間」「受入テスト期間」「運用引き継ぎ期間」を含めた実質納期で読まないと、契約後に「まだ使えない」という状況が発生します。

本記事では、まず 4 段階のレンジと判別軸を提示し、そのうえで見積を左右する 7 要因、安すぎ・盛りすぎ見積を見分ける質問集、AI 駆動開発で期間が半分になる仕組み、実質納期の分解と、順を追って掘り下げます。「Web システム開発を依頼するなら」の要件整理と進め方の総論は Web システム開発を依頼するなら にまとめているので、あわせて参照してください。本記事は「費用と納期」に絞って深堀りします。

Web システムの規模別費用レンジと判別軸

Web システムの費用は、機能数・外部連携数・データモデルの複雑さで大きく変わります。実案件で見えているレンジは、おおむね次の 4 段階に分かれます。

規模	費用レンジ (税抜)	期間	想定される規模
小規模	300 万〜800 万円	2〜4 ヶ月	単一機能・外部連携 1〜2 本・データモデル小
中規模	800 万〜1,500 万円	3〜6 ヶ月	主要機能 3〜5 個・外部連携 3〜5 本・データモデル中
中大規模	1,500 万〜3,000 万円	6〜9 ヶ月	主要機能 5〜10 個・外部連携多数・複雑な業務フロー
大規模	3,000 万円以上	9 ヶ月以上	主要機能 10 個以上・全社基幹・24 時間 SLA・多数連携

小規模 (300 万〜800 万円) は、社内向けの単一機能ツール (勤怠、社内ポータル、簡易 CRM) が典型例です。データモデルは 5 〜 10 テーブル程度、外部連携は Slack や Google Workspace への通知程度、UI はフォームとリストが中心。認証は SSO で外部サービスに任せる構成が多いです。

中規模 (800 万〜1,500 万円) は、業務システム化の中核レンジです。受発注、顧客管理、在庫管理、といった業務の 1 〜 2 領域をカバーし、10 〜 20 テーブルのデータモデル、3 〜 5 本の外部連携 (会計、EC、決済) を含みます。SaaS MVP もこのレンジに入ります。詳しくは SaaS の MVP 開発の費用と期間 に整理しています。

中大規模 (1,500 万〜3,000 万円) は、複数の業務領域を横断する Web システムです。20 〜 40 テーブル、5 〜 10 本の外部連携、複雑な業務フローで承認や状態遷移が絡む構成が典型例です。中堅企業の基幹周りや、複数拠点で使う業務システムがこのレンジに入ります。

大規模 (3,000 万円以上) は、全社基幹に近い規模で、24 時間 SLA、10 以上の外部連携、監査対応、複数拠点、といった要素が組み合わさります。ここまで来ると、リプレイスの選択肢を並べて検討するフェーズで、レガシー刷新の費用と期間 や システムリプレイスの進め方完全ガイド の内容が関係してきます。

同じレンジ内でも、費用は上下します。次の節で扱う 7 要因のうち、どれが上振れするかを見積時点で確認しておくと、後からの追加費用を予測できます。

見積を左右する 7 要因

Web システムの見積を読むときに、金額の絶対値よりも、金額を左右する 7 要因を分解して見るほうが判断が正確になります。実案件で費用と期間に効いてくる 7 要因は次のとおりです。

1. 機能数と業務ロジックの複雑さ。画面数ではなく、業務ロジックが分岐する条件の数が費用に効きます。「単純な CRUD」と「承認フローと状態遷移のある業務」では、同じ画面数でも工数が 2 〜 3 倍違います。
2. データモデルの複雑さ。テーブル数だけでなく、正規化の程度、履歴管理の要件、複数テナントかどうか、といった要素で工数が変わります。
3. 外部連携の数と難易度。連携本数、認証方式、レート制限、エラー時のリトライ設計、といった観点で費用が積み上がります。連携先の仕様が公開されていない、テスト環境がない、といった状況では追加工数がかかります。
4. セキュリティ要件。認証・認可、監査ログ、暗号化、脆弱性対策、PCI DSS や SOC2 などのコンプライアンス要件の有無で、費用が大きく変わります。
5. SLA と可用性。99% と 99.9%、24 時間対応か営業時間対応か、といった要件でインフラ構成と運用体制の費用が変わります。
6. デザインとフロントエンドの作り込み。既存デザインシステムを使うか、専用デザインを起こすか、モバイル対応の範囲、といった要素で費用が変わります。
7. 運用引き継ぎとドキュメントの範囲。運用マニュアル、API ドキュメント、開発者向けオンボーディング資料の作成、といった納品物の範囲で費用が変わります。

複数社から見積を取るときは、これら 7 要因のそれぞれで、どこまでを見積範囲に含めているかを揃えて比較します。金額だけを見て「A 社は安い」と判断すると、後から「セキュリティ要件は別途」「運用マニュアルは別料金」といった追加費用で総額が上がるケースが多いです。

FIXIT

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

金額の差より、前提条件の差を見るのがおすすめですよ。同じ 800 万円でも、含まれる範囲が違うんです。

Hinata

セキュリティ、運用引き継ぎ、追加費用の発生条件、この 3 つを揃えて比較すると、実質のコストが見えてきます。

FIXIT

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

Hinata

追加費用の発生条件と検収基準を質問すると、大体分かります。

安すぎ・盛りすぎ見積を見分ける質問集

複数社の見積を並べて比較するとき、次の 5 つの質問をぶつけると、見積の妥当性を判断できます。

1. どの機能が「初期スコープ内」で、どの機能が「後から追加」の扱いか。この線引きが曖昧な見積は、契約後に「これは範囲外」と言われるリスクがあります。
2. 追加費用が発生する条件は何か。「要件変更」「機能追加」「調整会議の回数超過」といった条件で、単価がどう決まるかを事前に確認します。
3. 検収基準は何か。「動く」なのか「テストが全て通る」なのか「ユーザーが業務で使える」なのか。検収基準が曖昧だと、納品後に「動かない」で揉めます。
4. 既存システムや外部連携先のデータで動作確認をしているか。「開発環境では動く」で終わっている見積は、本番データでの想定外に対応する費用が別途発生する可能性があります。
5. 納品後の初期サポート期間はどこまで含まれるか。1 週間、1 ヶ月、3 ヶ月、といった期間の違いで、実質の総所有コストが変わります。

これらの質問に「あとで詰めましょう」で答えを濁す見積は、契約後に想定外の費用が発生する確率が高いです。逆に、質問すべてに具体的な答えを持って返してくる会社は、過去の案件で同じ論点を経験しており、見積の精度も高いことが多いです。

「安すぎる見積」の典型は、初期スコープを絞りきったうえで、後から必要になる要素を全て「追加費用」の扱いにするパターンです。契約時は安く見えても、リリース時点で当初の 1.5 〜 2 倍の総額になるケースが多く、発注担当が社内で追加予算の稟議を通す負担を負います。

「盛りすぎ見積」の典型は、全ての可能な要素を初期スコープに含めて、リスクバッファも厚めに乗せるパターンです。安全ではありますが、実際には使わない機能や、後から要らないと分かる要素も費用に乗ってしまい、投資対効果が落ちます。

AI 駆動開発で期間が半分になる仕組み

AI 駆動開発を取り入れた Web システム開発では、従来開発と比べて期間がおおむね 1/2 〜 2/3 に圧縮されるケースが増えています。期間短縮の内訳は次のとおりです。

• 要件整理と設計。要件を Claude Code で構造化し、UML やデータモデルの草案を AI に作らせることで、要件定義フェーズが 30 〜 50% 短縮されます。
• 実装。テスト先行で AI に実装させる進め方 (AI 駆動 TDD) で、実装工数が 40 〜 60% 短縮されます。特にフォームとリスト中心の CRUD 実装は AI が最も得意な領域です。
• インフラ構築。認証・課金・監視・ロギングといった必須インフラを、AI に IaC (Infrastructure as Code) で書かせることで、インフラ立ち上げが 1 〜 2 週間から 2 〜 3 日に短縮されます。

一方で、AI で短縮しにくい工程もあります。

• 受入テスト。ユーザーによる受入テストの期間は、業務担当者の稼働に依存するため、AI で短縮できません。
• 外部連携の調整。連携先の相手側の対応スケジュールに依存するため、AI で短縮できません。
• 本番データでの想定外への対応。実データを扱う段階で発見される想定外の対応は、業務理解が要るため、人間が握る領域です。

このため、AI 駆動開発で「期間が半分」になる部分と、そうでない部分を分けて見積を読むことが重要です。「全工程が半分」ではなく、「実装工程が半分」と理解すると、実質納期の判断がしやすくなります。

FIXIT が支援した実案件では、従来開発で 6 ヶ月見込みだった中規模 Web システムを、AI 駆動で 3 〜 4 ヶ月に圧縮したケースがあります。この期間短縮は、開発工程の圧縮に加え、要件と受入テストのイテレーションを 1 週間サイクルで回せる体制の効果でもあります。

納期は「実質」で読む

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

1. 着手待ち期間。契約から実装開始までの期間。開発会社の他案件との兼ね合いで、1 週間から 1 ヶ月かかることがあります。
2. 要件定義・設計期間。実装の前段の期間。中規模で 2 〜 4 週間、大規模で 1 〜 2 ヶ月です。
3. 実装期間。見積で提示されている「開発期間」の中心。ここが AI 駆動で圧縮できる領域です。
4. 受入テスト期間。発注側で本番相当のテストを行う期間。中規模で 2 〜 4 週間、大規模で 1 〜 2 ヶ月です。
5. 運用引き継ぎ期間。ドキュメント引き渡し、運用マニュアルの作成、開発者オンボーディングの期間。1 〜 2 週間が標準的です。

「開発期間 4 ヶ月」の見積は、実質納期で見ると 5.5 〜 7 ヶ月になるのが標準的です。実質納期で計画を立てないと、リリース予定日から逆算して発注のタイミングが遅れ、予定日に間に合わなくなります。

発注時に押さえておくべきチェックリスト

Web システム受託開発の発注時に、費用と納期の両面で確認しておくべき論点を整理します。

• 見積の規模区分 (小規模・中規模・中大規模・大規模) が、実際の要件と一致しているか
• 見積を左右する 7 要因のそれぞれで、どこまでを見積範囲に含めているかを揃えて比較しているか
• 追加費用の発生条件と検収基準が具体的に定義されているか
• AI 駆動開発の前提で見積を取り、従来開発の見積と混在させていないか
• 実質納期 (着手待ち + 要件定義 + 実装 + 受入テスト + 運用引き継ぎ) で計画を立てているか
• 段階発注 (ディスカバリー → MVP → 拡張) の選択肢を検討しているか
• 契約途中の機能追加への対応 (請負か準委任か) を契約時点で握っているか

これらを満たしたうえで、AI 駆動開発を取り入れると期間が 1/2 〜 2/3 に圧縮できる領域があるので、従来開発の見積と AI 駆動開発の見積を並べて比較する進め方が、費用対効果を最大化する現実解です。

Web システム 受託開発のご相談

Web システム受託開発の見積の読み方、AI 駆動開発を取り入れた場合の実質納期、段階発注の設計、といった具体的な相談は、要件が固まっていない段階でも承っています。まずは AI 駆動開発サービスの内容 をご覧いただき、お問い合わせ からお気軽にご相談ください。SaaS MVP の規模なら SaaS MVP 開発サービス、既存システムからのリプレイスなら システム刷新・リプレイスのサービス の情報も参考になります。