アプリの開発費用はいくら？見積内訳と予算を決める5ステップ｜1業務スタートは50万円から

「顧客管理アプリを作りたい」と3社へ相談したら、見積額が大きく違った。安い会社はどこまで含み、高い会社は何を厚く見ているのか分からない。ここで平均額だけを探しても、発注判断は楽になりません。

アプリの開発費用は、名称ではなく作る範囲と不確実性で決まります。費用を考える基本式は次の通りです。

費用を左右するのは、作る範囲（画面・データ・権限・外部連携の数）、仕様の不確実性（決まっていない部分が多いほど予備が増える）、見積に含む工程の3つです。この記事は金額表ではなく見積の内訳の読み方を扱い、市場平均は断定しません。見積を同じ条件へ揃え、自社で予算の上限と最初の開発範囲を決める方法を示します。

金額の目安：SalesDockは1業務スタート50万円〜（税別）

他社の金額は条件で大きく変わるため、一律の相場は示せません。SalesDockでは、1つの業務に絞った「1業務スタート」を50万円〜（税別）、試作の結果を受けた本実装を個別見積もりとしています。試作で動きを確かめてから本実装に進むので、作ったものが使われなかった場合に払う金額を小さく抑えられます。対応範囲と進め方はAI受託開発のページ、依頼から運用までの流れと契約の形はシステム開発を外注するときの流れと費用、手元の業務を持ち込んでの相談は無料相談で受けています。

アプリ作成の費用相場：自作・受託・SaaSの3つで目安を分ける

アプリ作成の費用は、誰が作るか（自作・受託・SaaS）でお金の出方が変わります。次の表は目安（仮）です。金額を書いているのはSalesDockの料金と、公開例を出典つきで並べたAI開発の外注費用の記事の範囲だけで、市場全体の平均や統計ではありません。

受託の公開例は、出典と確認日をAI開発の外注費用の記事に載せています。SaaSと自作は製品ごとに料金体系が違うので、この表では金額を作らず、費用の出方だけを示しました。受託で頼む場合の会社の型と契約前に聞くことは、AI受託開発とはで整理しています。

スマホアプリの開発費用が上がる要因

スマホアプリの開発費用は、業務用のWebアプリに次の作業が加わります。iPhoneとAndroidの両対応、ストアへの公開申請と審査対応、プッシュ通知、端末とOSの更新への追従です。社内で使う業務アプリなら、スマホのブラウザで開くWebアプリで足りるかを先に確かめると、ストア対応の費用を省けます。

相場を探す前に、発注方法を3つに分ける

同じ「アプリ開発」でも、既製サービスを設定する場合と、業務に合わせて個別開発する場合では、費用の中身が違います。最初から個別開発を前提にせず、次の順で代替できないかを確認します。

アプリの開発をSaaS・既製サービス、ノーコード・ローコード、個別開発のどれで進めるかを比べるときは、初期費用だけでなく、公開後に使い続けるための総費用で見ます。既製サービスでも設定・移行・教育は発生し、個別開発でも最初の範囲を絞れば段階的に試せます。

既存システムを作り直して外部へ移管する場合は、新規開発の工程に加えて、現行仕様の調査、移行対象データの整理、切り替え、旧環境の停止を見積条件に入れます。各社の見積は、要件定義・設計・実装・テスト・データ移行の内訳だけでなく、現行調査、移行後の照合、並行稼働、旧環境の停止が対象内か対象外かを揃えて比べます。

アプリの開発費用に差が出る7つの内訳

IPAのソフトウェア開発データでは、基本設計、詳細設計、製作、結合テスト、総合テストを開発5工程として扱います。一方、要件定義や移行、インフラ、運用などの扱いはプロジェクトによって異なります。見積書の「開発費」は、含む工程が会社ごとに違う場合があるため、見積を比べるときは含まれる工程を先に揃えます。

ワークフローを個別開発する場合も、一般的な開発工程ごとに見積を分けます。そのうえで、申請経路、承認段階、差し戻しや代理承認などの例外、通知、権限、既存データとの連携を同じ条件で各社へ伝えます。「承認機能一式」ではなく、工程別の内訳と対象外を揃えると、ワークフロー固有の複雑さによる費用差を説明できます。

予算を決める5ステップ

1｜目的を「機能」ではなく「変える数字」で決める

「日報アプリを作る」ではなく、「週次集計を3時間から30分へ減らす」のように置きます。成果指標がなければ、便利そうな機能が際限なく増えます。最初の指標は、作業時間、転記回数、入力漏れ、判断までの日数のどれか1つで十分です。

2｜現在の業務と例外を一枚にする

開始、入力、確認、承認、完了までを並べ、担当者と使う情報を書きます。特に費用へ効くのは「通常とは違うとき」です。値引き時だけ役員承認、契約種別ごとに帳票が違う、といった例外を後で発見すると設計と実装を戻します。

3｜画面・データ・権限・連携を数える

概算を依頼する前に、画面、主要データ、利用者の権限、外部連携を一覧にします。IPAが紹介する見積手法でも、機能数・画面数・テーブル数などの規模と、複雑度・要求される信頼性が、工数を見積もる際の要因として挙げられています。「何となく便利なアプリ」では、見積側も大きな安全幅を置くしかありません。

• 画面：一覧、詳細、登録、承認、集計
• データ：会社、担当者、案件、活動、請求
• 権限：一般、管理者、経営者、外部委託先
• 連携：メール、会計、チャット、既存基幹

4｜同じ見積依頼書で、内訳と対象外を出してもらう

各社へ同じ資料を渡し、工程別の工数、成果物、前提、対象外、追加費用になる条件を回答してもらいます。比較表の列は「総額」より先に「含まれる工程」と「含まれない作業」を置きます。

5｜変更費と公開後の費用を別枠で持つ

開発中に分かることは必ずあります。変更をゼロにするのではなく、誰が変更を承認し、納期・費用への影響をどこへ記録するかを決めます。公開後も保守、問い合わせ、アカウント管理、改善が続きます。初期開発費だけでなく、運用責任者の工数まで予算に入れます。

見積を同じ条件で比べるフォーマット

金額を人月で確認する場合も、単価だけで判断しません。たとえば「合意した単価×必要工数」で計算できますが、必要工数の前提が違えば総額は変わります。過去案件の実績とリスク要因を使う見積方法もあり、IPAのCoBRAは、組織の過去のプロジェクト実績データから見積り評価モデルを作り、工数の変動要因とそのばらつきを見積に織り込む考え方を示しています。

すでに特定のベンダーから提案書と見積書を受け取っていて、このフォーマットに当てはめても妥当かどうか判断がつかない場合は、第三者に見てもらう道があります。頼める先の種類と、見せる資料、見てもらう点はシステムやAIの導入提案を受けたら、セカンドオピニオンはどこに頼める？にまとめています。

予算超過が起きやすい3つの境目

要望が要件へ変わる前

「できれば欲しい」と「初回公開に必須」が混ざると、見積の途中で範囲が膨らみます。必須、後続、対象外の3区分にし、初回公開後に測る指標まで決めます。

既存データを移すとき

件数だけでなく、重複、欠損、表記揺れ、過去データの保持範囲が工数へ効きます。移行元ごとに件数と品質を確認し、誰が修正し、誰が照合するかを見積条件へ入れます。

公開から運用へ渡すとき

利用者登録、問い合わせ、障害時の判断、マニュアル更新が未定だと、公開後に担当者へ負荷が集中します。開発完了と業務で使える状態を分け、運用開始までの作業を予算に含めます。

公開後に測る5つの数字

• 見積差：計画工数と実績工数の差
• 変更要求数：合意後に追加・変更した件数
• 受入不具合数：業務側の確認で見つかった問題
• 成果までの日数：着手から現場利用までの日数
• 運用工数：問い合わせ、手直し、集計に使う時間

初回から完璧な予算を当てるより、実績を次の見積へ戻す方が精度は上がります。数値を残せば、2回目以降は自社の業務に合った基準を持てます。

来週やること

1. 対象業務を1つに絞り、短くしたい時間を決める
2. 通常フローと例外を付箋または表で書く
3. 画面・データ・権限・連携を数える
4. 既存見積に7つの内訳が含まれるか印を付ける
5. 不足項目を同じ質問文で各社へ確認する

これだけで、価格だけの比較から、業務と成果物の比較へ移れます。

まとめ

アプリの開発費用は、アプリの名前だけでは決まりません。要件定義、設計、実装、テスト、移行、運用準備のどこまでを含むか、未決事項と例外がどれだけあるかで変わります。目的を数字で決め、業務を一巡させ、見積条件を揃える。この順番なら、発注判断を一人の勘から会社の基準へ移せます。