システム開発の費用相場｜種類別・規模別に発注予算を考える

システム開発の費用相場を調べても金額の幅が広く、発注予算を決めにくいことがあります。相場表だけでは決まりません。必要な機能、利用者と権限、外部サービスとの連携、データ移行、求める品質、公開後の運用まで条件をそろえて、初めて小規模開発の見積もりを比較できます。

最初に決めるのは、予算内で必ず実現する業務と、後の段階へ回せる機能の境界です。相場表から金額を選ぶ作業を先行させると、必要な範囲と数字の根拠が離れてしまいます。MVP、業務システム、既存システム改修、AI機能の組み込みでは、どこに境界を置けばよいのでしょうか。境界が予算を決めます。

AI機能を組み込む案件では、通常の開発費とは別に、データ準備、評価、ガードレール、人手確認、監視・運用を見積もります。AIシステム開発費の内訳で追加費用と再見積もり条件を整理しています。

2026年7月時点で、公的機関による、あらゆる小規模システムに共通の金額相場は確認できません。IPAの「ソフトウェア開発分析データ集」が扱うのは、実プロジェクトの規模、工期、工数、生産性、信頼性などを比較するためのデータです。案件固有の見積書に代わる定価表ではないため、相場は予算の仮説として使い、発注条件をそろえた見積もりで確かめます。

システム開発の費用相場が一つに決まらない理由

開発費の中心は、要件を整理し、設計し、実装し、レビューとテストを行うための工数です。画面数が少なく見えても、複数の権限、既存データの取り込み、外部API連携、監査ログ、障害時の復旧要件が加われば、設計と検証の範囲は広がります。対象業務と利用者を絞り、既存のクラウドサービスを適切に利用できる案件なら、新規に作る範囲を抑えられます。

見積もりに含まれる主な範囲は次のとおりです。

• 企画・要件定義：解決する業務、利用者、機能要件、性能やセキュリティなどの非機能要件を定める
• 設計・実装：画面、データ、権限、連携方式を設計し、プログラムを作る
• レビュー・テスト：仕様との一致、操作、連携、性能、障害時の挙動を確認する
• 移行・公開：既存データの整形と投入、環境構築、公開手順を整える
• 運用・保守：監視、問い合わせ、障害対応、クラウドや外部サービスの利用料を扱う

このうち何が見積もりの対象外かを確認しないまま総額だけを比べると、安く見える案に移行や運用が含まれていないことがあります。IPAも、分析データ集の開発工数は基本設計、詳細設計、製作、結合テスト、総合テストという開発5工程を中心にしており、要件定義以前や公開後の作業を含まないと説明しています。先に「工程の範囲」をそろえます。

種類別に見る、発注予算の考え方

MVPは検証したい仮説を一つに絞る

MVPは、事業上の仮説を確かめるための必要最小限の製品です。完成品に予定する機能を一律に縮小する考え方ではありません。初回から管理機能、細かな権限、全ての通知、例外処理まで盛り込むと、検証前に費用が膨らみます。

誰のどの行動が変われば次の投資を判断できるのかを決め、その判断に不要な機能を後へ回します。個人情報の保護やアクセス制御など、初回から必要な品質要件は残します。検証目的を保ったまま、機能範囲を小さくするのがMVPの予算設計です。

業務システムは例外処理と権限を先に数える

申請、顧客管理、案件管理などの業務システムは、通常の処理だけを見ると単純に見えます。例外は少なくありません。差し戻し、取消し、重複、担当変更、承認者の不在があり、利用者の役割ごとに閲覧・登録・承認の権限が異なれば、その分だけ設計とテストも増えます。

発注前に、現在の業務フロー、扱うデータ、利用者の役割、月や年度の締め処理を整理します。機能一覧だけでなく、業務が始まって終わるまでを示すと、見積もりの前提がそろいやすくなります。

既存システム改修は調査費を切り離さない

既存システムの改修費には、変更する画面や機能に加えて事前調査が含まれます。調査も開発の一部です。現在のコード、データベース、外部連携、実行環境を調べ、変更によって既存機能が壊れないことを確かめる必要があり、仕様書やテストが不足していれば、影響範囲の特定により多くの工数が要ります。

見積もり依頼時には、ソースコード、設計資料、環境情報、既知の不具合、利用中の外部サービスを開示できる範囲で提示します。資料が不足している場合は、改修一式をすぐ固定するより、調査・診断と実装を段階に分けたほうが予算の根拠を確認しやすくなります。

AI機能の組み込みは実装費と利用費を分ける

要約、検索、分類、文章生成などのAI機能では、画面やAPIの実装に加え、入力データの整備、出力の評価、誤った出力への対処、権限管理、ログ、外部AIサービスの利用料を考えます。実装費だけではありません。動く試作を業務へ移す段階では、出力の扱い方や監視を含む運用設計も必要です。

AIはコード作成などの実装作業を速める手段になります。何を作るかを決める要件定義、設計の妥当性、レビュー、テストには人が責任を持ちます。初期予算では対象業務と評価基準を限定し、運用予算では利用量に応じた料金、監視、モデルや仕様の変更への対応を分けて確認します。

規模別の予算は機能数より複雑さで分ける

小規模、中規模という呼び方にも共通の物差しはありません。発注時には、曖昧な規模名を次の条件へ置き換えます。

表の右側に当てはまる条件が一つなら、ほかの条件との組み合わせを見て規模を判断します。画面数だけでは測れません。複数の条件が重なるほど、実装量に加えて関係者間の調整、設計、テストが増えるからです。

見積書で費用の妥当性を確認する

デジタル庁の「デジタル・ガバメント推進標準ガイドライン」は政府情報システム向けの共通ルールですが、民間の小規模発注にも参考になる観点があります。2026年7月15日更新の現行ページでは、DS-120の各種テンプレートに要件定義書と調達仕様書の標準テンプレートが収録されています。政府向けの記載項目から案件に関係する部分を選べば、発注条件を文書でそろえる際の手掛かりになります。

見積書と提案書では、少なくとも次を確認します。

• 成果物と対象機能：何が完成し、何が対象外か
• 工程と体制：要件定義、設計、実装、レビュー、テスト、公開を誰が担うか
• 前提条件：発注者が用意する資料、確認期限、外部サービス、対応環境
• 変更の扱い：要件追加や前提変更が起きたときの再見積もり方法
• 公開後の費用：保守、監視、クラウド、外部API、ライセンスの負担
• 権利と引き継ぎ：ソースコード、設計資料、アカウント、データをどう受け渡すか

項目が明確なら、会社ごとの総額が違う理由を質問できます。「開発一式」では比べられません。複数社へ依頼する場合は同じ要件資料と回答期限を渡し、含まれる作業と品質、除外事項、不確実な点を各社に明記してもらいます。

契約方式の名称だけでは、作業範囲や責任分担を判断できません。要件が固まった部分と、調査しながら決める部分を分け、成果物、検収条件、役割、変更手続きを契約書や個別の発注書で確認します。契約の法的な判断が必要な場合は、個別事情を示して専門家へ相談してください。

予算超過を避ける発注の順番

まず、システム化する目的を売上、作業時間、ミスの削減など確認可能な状態で置きます。次に、現行業務、利用者、必要なデータ、例外処理を整理し、「初回に必須」「後で追加」「作らない」の三つへ分けます。

そのうえで、概算相談、要件の具体化、正式見積もりと段階を踏みます。IPAの「ユーザのための要件定義ガイド」も、初期は情報が少なく見積もりのリスクが高い一方、要件が具体化するにつれて精度が上がるため、時点ごとの再見積もりが必要だと示しています。最初の概算を変更不能な約束にせず、どの判断時点で予算を更新するかを合意しておきます。

cotomuの小規模受託開発が対象とするのは、MVP、業務システム、既存システム改修、AI機能の組み込みです。相談時には、予算だけでなく、解決したい業務、初回に必要な範囲、希望時期、既存資料の有無を共有すると、検討すべき条件を整理できます。

相場表より、同じ範囲で比べられる予算をつくる

システム開発の費用相場は、発注予算の上限や優先順位を考える入口です。小規模という呼び方が同じでも、MVPの検証範囲、業務の例外、既存資産の状態、AI出力の評価と運用によって必要な作業は変わります。

冒頭の問いへの答えは明確です。種類を選んだ後に、機能、権限、連携、移行、品質、運用の境界を決めてください。初回必須の業務を一つに絞り、対象外と再見積もりの時点までそろえた見積書を比べる。それが、相場の幅に振り回されず、小規模なシステム開発の発注予算を判断する方法です。

参考資料

• IPA「ソフトウェア開発分析データ集2022」（2026年7月24日確認）
• IPA「ユーザのための要件定義ガイド 第2版」（2026年7月24日確認）
• デジタル庁「デジタル社会推進標準ガイドライン」（2026年7月24日確認）

執筆・編集：株式会社adding編集部

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る