Webサービス・スマホアプリ開発の費用相場・料金体系

Webサービスやスマホアプリの開発費は、相場だけを見ても判断しにくいテーマです。似たように見える案件でも、Webのみなのか、アプリを1OSで出すのか、両OS対応なのか、管理画面や外部連携まで含むのかで、費用構造が大きく変わります。さらに、見積書の総額だけでは、何が含まれ、何が後から追加費用になりやすいのかが見えません。

この記事では、Webサービス・スマホアプリ開発の費用を、相場の一覧としてではなく、自社案件に当てはめて判断するための材料として整理します。読後には、自社案件の予算帯を仮置きし、初年度総額を見積もり、契約形態を仮決めし、同じ条件で複数社へ見積もり依頼するところまで進めやすくなります。

相場だけでなく、契約形態、初年度総額、見積比較までを一連の判断として整理すると、自社案件に当てはめやすくなります。

01Section費用相場を見る前に押さえる前提

まず押さえたいのは、開発費は機能数だけで決まらないという点です。画面数、権限の数、外部連携、運用責任、対応OS、納期条件が変わると、同じような見た目の案件でも見積もりは大きく変わります。

まず分けるべき4つの開発パターン

まず開発対象を4つに分けると、どこで工数が増えやすいかを整理しやすくなります。

予算感を仮置きするときは、最初に次の4つへ分けると整理しやすくなります。

• Webのみ
• スマホアプリ1OS
• スマホアプリ両OS
• Web＋アプリ＋管理画面/API

この分け方が必要なのは、開発対象ごとに工数の増え方が違うためです。Webは管理画面や業務フロー、既存システム連携で膨らみやすく、アプリはOS差分、ストア公開、端末検証、OSアップデート追従が増分になりやすい傾向があります。規模情報を見積もり判断の材料として扱う考え方は、IPAのCoBRA見積り支援でも確認できます。

小規模・中規模・本格開発の見分け方

厳密な標準ではありませんが、社内で予算帯を仮置きするなら次の見方が実務的です。

• MVP・小規模: 5〜15画面、権限1〜2種、連携0〜1本、管理画面はなし〜簡易、期間は1〜3か月程度
• 中規模: 15〜40画面、権限2〜4種、連携1〜3本、管理画面あり、期間は3〜6か月程度
• 本格開発: 40画面以上、権限4種以上、連携3本以上、高機能な管理画面あり、6か月超も視野

この区分は、画面数や連携数、非機能要件が工数に影響するという公開情報を、予算仮置きしやすくしたものです。正式な金額は、要件定義の深さや責任範囲によって変わります。

相場をそのまま当てはめにくい理由

公開されている相場情報は便利ですが、同じ条件で横並び比較できるわけではありません。たとえば、要件定義を含むか、管理画面をどこまで作るか、ストア申請や保守開始準備を含むかで総額の見え方は変わります。したがって、相場は予算の仮置きに使い、正式判断は同じ依頼条件での個別見積もりで行うのが安全です。

02SectionWebサービス・スマホアプリ開発の費用相場

ここでは、初期開発費の概算目安を4分類で整理します。金額そのものより、何が含まれやすく、何が別建てになりやすいかを合わせて読むことが重要です。

SunのWeb開発費用の公開相場では、小規模Webアプリ100万〜500万円、中規模業務システム500万〜1,000万円、EC・予約系では1,000万円前後の目安が示されています。アプリ側は、LASSICのiOSアプリ開発費用の解説で1OSの目安が整理されており、モバイルアプリ開発費用の解説では両OSで工数が増えやすい考え方が確認できます。

開発対象別の概算レンジ

レンジの使い方

この表は、まず自社案件をどの帯に置くかを判断するための目安です。たとえば、会員管理と管理画面があり、外部連携が2本、Webのみで進めるなら、中規模業務システムの帯から見始めるのが自然です。一方で、まずはアプリ1OSで検証したいなら、1OSの小規模〜中規模レンジを起点にし、あとで両OS化したときの追加工数を見ます。

高くても妥当になりやすい条件は、次のようなものです。

• 複数の外部連携がある
• 権限分岐や承認フローが多い
• セキュリティや監査ログの要件が厳しい
• 両OS対応が前提になる
• 短納期で並行作業が必要になる

税別・税込の表記は各社で異なるため、社内比較では表記条件をそろえて読むのが前提です。

03Section料金体系と契約形態の選び方

同じ開発でも、請負、準委任、保守契約では見積書の読み方が変わります。大事なのは、どの契約が安いかではなく、要件の固まり方と変更頻度に合っているかです。

内容未確定の段階でプロジェクト全体を一括請負にするのが適切でないケースがあることは、IPAの外部委託の整理でも示されています。また、経済産業省のモデル契約書では、請負と準委任で責任の持ち方が異なる前提が整理されています。

請負・準委任・保守契約の違い

契約形態の判断フロー

契約形態は安さではなく、要件の固まり方と変更頻度に合わせて選ぶと比較しやすくなります。

迷ったときは、次の順で切り分けると判断しやすくなります。

1. 1要件、成果物、検収条件を先に固められるか

• 固められるなら、請負を主軸にしやすい案件です。
• 固めにくいなら、次へ進みます。

1. 1仕様変更や優先順位の入れ替えが起こりやすいか

• 起こりやすいなら、準委任を主軸にしたほうが運用しやすくなります。
• ある程度は動くが、実装単位で区切れるなら、次へ進みます。

1. 1上流と実装を分けて考えられるか

• 分けられるなら、上流は準委任、仕様が固まった機能群は請負に分ける形が現実的です。

1. 1リリース後に監視、障害一次対応、軽微改修が必要か

• 必要なら、開発契約とは別に保守契約を確認します。

実務では、上流は準委任、区切れた実装は請負、運用は保守契約という分け方が比較しやすいケースが少なくありません。

追加費用が出やすい境目

追加費用が発生しやすいのは、契約形態そのものより、境界が曖昧なときです。とくに次の5点は契約前に明文化しておくと、後の認識差を減らせます。

• どこまでが成果物か
• 検収完了の条件は何か
• 仕様変更をどこから追加扱いにするか
• テスト範囲をどこまで含むか
• 保守開始後に何が別費用へ移るか

04Section見積もりの内訳と妥当性の見方

見積もり比較で重要なのは、総額の高低より、同じ条件で並べられているかです。安く見えても、テストや保守準備が抜けていれば、後から総額が増えることがあります。

Sunの見積内訳の解説には、PM 10〜15％、設計10〜25％、デザイン約5％、開発50〜60％程度という公開例があります。ただし、各社で計上位置が異なるため、比率をそのまま比較するより、何がどこに入っているかをそろえて読むほうが実務的です。検収条件の明確化は、経済産業省のモデル契約書でも重要な論点として扱われています。

まず見るべき内訳項目

最初に見るのは、要件定義、設計、UI・デザイン、実装、テスト、PM、インフラ、申請・公開、保守開始準備の切り方です。すべてが細かく分かれている必要はありませんが、少なくとも要件定義・設計・開発・テスト・PMの境界は見えたほうが比較しやすくなります。

赤信号になりやすい見積もり

• 一式 表記が多く、工程の境界が見えない
• テスト範囲と不具合修正の扱いが書かれていない
• 検収条件が曖昧で、どこで完了なのか分からない
• 管理画面、外部連携、データ移行の有無が不明
• 仕様変更時の追加費用条件が書かれていない

比較時にそろえる条件

見積書を受け取ったら、総額だけでなく、テスト範囲、検収条件、管理画面の想定、外部連携の範囲、保守の境界を同じ粒度で確認してください。この粒度までそろうと、安さの理由と高さの理由を説明しやすくなります。

05Section初年度総額で考える費用

初期開発費だけで稟議すると、リリース後に予算不足が起きやすくなります。初年度は、開発会社への支払いだけでなく、ストア、クラウド、外部SaaS、社内運用工数まで含めて見たほうが安全です。

4つの費目区分で整理する

開発会社費用と外部サービス費の分け方

アプリを含む場合は、ストア関連費用が別建てです。たとえば、Apple Developer Programは99米ドル/年、Google Play Consoleは25米ドルの一回払いです。売上連動の手数料や課金条件は案件によって影響度が異なるため、必要な場合はAppleのSmall Business ProgramやGoogle Playのサービス手数料で最新条件を確認してください。

クラウド費は初期費用ではなく、利用量で動く費用として見るのが基本です。AWS EC2のオンデマンド料金は長期契約なしの従量課金で、Firebase BlazeもCloud Billing連携を前提とした従量課金プランです。利用者数、アクセス量、通知数、保存データ量によって、初年度総額への効き方が変わります。

初年度総額の簡易試算

初期開発費だけでなく、月額費用や従量課金、改修予備費まで分けて置くと、稟議で説明しやすくなります。

初年度総額は、初期費用だけでなく継続費用と変動費を分けて置くと説明しやすくなります。

初年度総額 = 初期費用 + 月額固定費×12 + 想定従量課金 + スポット改修予備費 + 社内工数

試算は3パターンに分けると使いやすくなります。

• 低位ケース: 想定利用量の50％程度で従量課金を置き、改修予備費も最小限にする
• 基準ケース: 月次想定利用量どおりで置き、軽微改修を数回見込む
• 上位ケース: 利用量を1.5〜2倍で置き、機能追加やOS追従も初年度に入る前提で見る

このとき、支払先も分けておくと稟議で説明しやすくなります。

• 開発会社: 初期費用、月額保守、スポット改修
• 外部サービス: ストア、クラウド、SaaS、API
• 社内: 受入テスト、素材準備、定例参加、問い合わせ対応

06Section費用を抑えるときの考え方

費用を抑える方法はありますが、単純な値引きではなく、何を初回から作るか、どこまでを将来へ回すかの設計が中心になります。短期の初期費削減と、中長期の再実装コストは分けて考える必要があります。

効果が出やすい5つの方法

効果が出やすいのは、値引きよりもスコープ設計で調整する方法です。

• MVP化: 初回リリースで必要な機能に絞る方法です。新規事業や仮説検証には有効ですが、後から基盤ごと作り直す設計だと総額が戻ります。
• 対象OSの絞り込み: ユーザーの端末が偏っているなら効果が出やすい方法です。ただし、後から別OSを追加する際に設計とテストの再コストが発生します。
• 既存サービス活用: 会員管理、予約、フォーム、CRM連携など共通要件が多い案件では初期費を抑えやすくなります。一方で、月額費やカスタマイズ制約は残ります。
• 段階開発: 一度に全部出さず、優先順位順に分割する方法です。初期キャッシュアウトは抑えやすい一方、分割しすぎるとPMとテストの再コストが増えます。
• 発注前整理: 目的、機能、連携、非機能要件を先にそろえる方法です。準備工数は増えますが、再見積もりや手戻りを減らしやすくなります。

削りにくい項目

反対に、削ると失敗しやすい論点もあります。

• 要件定義の最低限整理
• 重要な外部連携
• 性能やバックアップなどの非機能要件
• 検収に必要なテスト
• 障害時の運用ルール

非機能要求を上流で整理する重要性は、IPAの非機能要求グレードでも整理されています。初期費用だけを下げようとして、ここを曖昧にすると、後からの追加費用が大きくなりやすくなります。

07Section見積もり依頼前に整理しておくこと

見積もりの精度は、依頼前の整理で大きく変わります。最初から全部を固める必要はありませんが、最低限の条件をそろえておくと、各社の前提ブレを減らせます。

依頼前に目的や課題、代替案、意思決定理由を整理する考え方は、IPAのビジネス分析ガイドが参考になります。要件定義で起きやすい問題は、IPAの要件定義ガイドでも整理されています。

概算見積もりに最低限必要な情報

各社比較をしやすくするには、依頼条件の前提をそろえて伝えることが重要です。

精度を上げる追加情報

未確定でも共有すべき論点

見積もり依頼は、1ページ程度でも構いません。大切なのは、同じ依頼メモを各社へ送ることです。条件がそろえば、総額だけでなく、内訳、前提、追加費用条件の違いを読みやすくなります。

08Section社内で次に進める4ステップ

ここまでの内容を、実際の判断順に並べると次の4ステップになります。読み終えたら、この順で社内メモを作ると判断が進みやすくなります。

要件整理や見積比較の前提づくりを進めたい方へ

予算帯の仮置き、依頼条件の整理、見積もり比較の観点整理から相談できます。要件が固まり切る前に、何をそろえて各社へ依頼すべきか確認したい場合に向いています。

プロダクト企画・要件定義支援0社掲載

対応会社を見る