LASSIC Media らしくメディア

LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託

スマホアプリ発注相場とは、機能規模と工数と契約形態で決まる費用の幅である

スマホアプリ発注相場とは、企画から要件定義・設計・実装・テスト・公開・保守までの工程ごとに必要な工数を、契約形態に応じて積み上げた費用の幅を指す。総務省「令和7年版 情報通信白書」によれば、インターネット接続端末としてのスマートフォン利用率（個人、総務省「通信利用動向調査」ベース）は2024年に74.4%となり、高齢者層を含めて主流の接続端末となっている^*1。利用率の高まりはアプリ発注のニーズを継続的に下支えしているが、実際の費用は機能規模・対応OS・契約形態・運用範囲によって幅があり、相場を一律の金額で表すことは難しい。そのため本稿では、特定の金額レンジを断定するのではなく、費用の幅を生む要素と判断軸を整理する立場をとる。

発注相場が注目される背景：スマホ利用率の高まりと発注経験のばらつき

スマホアプリの発注相場が注目される背景には、利用基盤の拡大と、発注経験のばらつきの両方がある。総務省の令和7年版情報通信白書によれば、スマートフォンのインターネット接続端末としての利用率（個人）は2011年の16.2%から2024年の74.4%へと拡大しており、60代でも78.8%に達している^*1。利用基盤の拡大に伴い、ECや会員サービス・業務システムのフロントエンドとしてのアプリ需要が継続している。

一方で、企業ごとに発注経験の蓄積には差がある。IPAの「DX動向2025」では、日米独の比較で日本企業が「内向き・部分最適」から「外向き・全体最適」へ転換する必要性が指摘されており^*2、システム発注の経験そのものが組織により大きく異なる状況が示唆される。発注経験の浅い企業ほど、相場の幅と、その幅を生む要素の理解が初期検討の出発点となる。

費用を左右する5つの要素：機能・対応OS・デザイン・連携・運用

スマホアプリの発注費用は、以下の5要素の組み合わせで変動する。各要素を発注前に整理することが、見積もり比較の出発点になる。

要素1：機能スコープ — 認証・通知・決済・オフラインなど

ログイン・プッシュ通知・決済・地図・カメラ・オフライン同期など、必要な機能を列挙する。機能ごとに実装工数と検証工数が積み上がるため、最初に「必須」「あれば望ましい」「将来追加」の優先順位を分けると、見積もりの幅を抑えられる。

要素2：対応OSとアーキテクチャ — ネイティブとクロスプラットフォームの選択

iOS・Androidそれぞれにネイティブ実装するか、Flutter（Googleが開発したクロスプラットフォーム開発フレームワーク）・React Native（Metaが公開しているクロスプラットフォーム開発フレームワーク）等のクロスプラットフォームで実装するかにより、工数構成が変わる。Google Playの対象APIレベル要件などOS側の継続対応も発生するため、対応OSの数とアーキテクチャ選択は中長期費用にも影響する^*3。

要素3：デザイン・UI/UXの作り込み — テンプレートかフルカスタムか

テンプレートをベースにするか、独自のUIデザインを起こすかで、デザイン工程の工数が変わる。プロトタイピング・ユーザーテストを実施するかどうかも費用差につながる。

要素4：外部システム連携 — API連携・SDK統合の数と複雑さ

基幹システム・決済代行・認証基盤・解析ツールなど、連携する外部システムの数と複雑さが費用を左右する。連携先のAPI仕様変更が想定される場合は、保守工程まで含めた費用把握が必要になる。

要素5：公開後の運用範囲 — 障害対応・OS追従・機能追加

リリース後の運用範囲には、障害対応・問い合わせ対応・OS追従・機能追加が含まれる。Google Playの対象APIレベル要件は新規アプリと既存アプリのアップデートで毎年の追随が求められており^*3、AOSPのセキュリティ情報も月次で公開されるため^*4、保守体制の有無で総費用が変わる。

工数の見方：IPA公開情報を踏まえた発注前の工数把握

発注前の工数把握には、自社の機能要件と類似する事例の工数感を参考にする方法がある。IPAは「ソフトウェア開発分析データ集」シリーズで、プロジェクトデータに基づく定量分析を公開している^*5。アプリ単独のベンチマークではないが、規模感・工程比率・信頼性に関する考え方を理解するうえで参考になる。

工数を要件定義・設計・実装・テスト・公開審査・保守の工程ごとに分解すると、見積もりの妥当性を確認しやすい。発注先から見積もりを受け取ったときに、工数の内訳と前提条件（対応OS・機能件数・テスト範囲・保守期間）を確認することが、相場感の理解につながる。なお、特定の金額レンジを断定できる公的統計はアプリ領域では限定的なため、本稿では具体的な数値レンジの断定は避け、要素別の判断軸として整理している。

契約形態の選び方：準委任と請負を工程で使い分ける

契約形態は費用の積算方法に直接影響する。経済産業省・IPAが公開する「情報システム・モデル取引・契約書」では、企画段階は準委任契約、開発工程は請負契約とするモデルが提示されており、要件定義など上流フェーズでは準委任、開発工程では請負が推奨されている^*6。

準委任契約（業務の遂行を約束する契約）は要件が固まりきらない上流工程に向き、請負契約（仕事の完成を約束する契約）はスコープが明確になった開発工程に向く。発注時には、工程ごとに契約形態を分けるとよい。上流は準委任で柔軟性を確保し、下流は請負で成果物を明確にする組み立てが、費用見積もりのブレを抑えることにつながる。

発注時のメリット・デメリット：内製比較で押さえる両面

外部に発注する場合と、内製で開発する場合のメリット・デメリットを公平に整理する。両面を把握することで、自社にとっての判断軸が明確になる。

外部発注は「スキル確保」「OS追従の負荷分散」で優位性があり、内製は「ノウハウ蓄積」で優位性がある。アプリの位置づけ（事業の中核か周辺か）と、開発リソースの状況に応じて使い分ける。

コスト最適化の判断軸：ニアショア・スコープ管理・継続保守

判断軸1：ニアショア活用で人件費レンジを抑える

ニアショア（国内地方拠点に開発業務を委託する形態）は、首都圏拠点と比較してコストレンジを抑えやすい選択肢である。コミュニケーション・時差・品質管理の面でオフショアより負荷が小さく、ノウハウ蓄積と費用最適化の両立を狙う場合の選択肢となる。

判断軸2：スコープ管理で要件追加による費用膨張を抑える

開発開始後の要件追加は、見積もり時点では織り込まれていない工数を増やす。要件定義工程で機能の優先順位を明確化し、フェーズ分割で段階リリースすることで、費用膨張を抑えやすくなる。

判断軸3：継続保守を初期計画から織り込む

Google Playの対象APIレベル要件は、新規アプリはメジャーバージョン公開から1年、既存アプリは2年で対応が求められる^*3。そのため、リリース後の保守費用を初期計画に含めることが、トータルコストの把握につながる。

まとめ：スマホアプリ発注相場の3つの判断軸

スマホアプリ発注相場は、機能・対応OS・デザイン・連携・運用の5要素と契約形態・運用範囲の組み合わせで決まる費用の幅であり、単一の金額では表しにくい。案件ごとの条件依存が大きく、アプリ領域の費用を一律に示す公的統計が限定的なことがその理由である。費用を左右する5要素は見積もり比較の前に整理する対象であり、契約形態は経済産業省・IPAのモデル契約に沿って準委任と請負を工程で使い分ける^*6。Google Playの対象APIレベル要件など継続対応の費用は初期計画に織り込み、ニアショア活用・スコープ管理・継続保守の3軸でコストを検討する^*3。

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：総務省「令和7年版 情報通信白書 インターネット接続端末」（2025年）
2. *2　出典：独立行政法人情報処理推進機構（IPA）「DX動向2025」（2025年）
3. *3　出典：Google「Google Play アプリの対象 API レベルに関する要件」（2025年）
4. *4　出典：Android Open Source Project「Android Security and Update Bulletins」（2025年）
5. *5　出典：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集」（2022年）
6. *6　出典：独立行政法人情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年公開・2025年4月更新）

Tweet