スマホアプリ開発の費用はどう決まるか｜ネイティブ・クロスプラットフォーム・PWAで何が変わるか
自社のサービスをスマホアプリにしたいと考えて開発会社に相談すると、見積もりの金額が会社によって大きく違うことがあります。同じ依頼のはずなのに数倍の差がつく理由の多くは、開発の方式と、見積もりに含まれている範囲の違いにあります。
スマホアプリの作り方は、iPhone（iOS）とAndroidそれぞれの専用言語で作るネイティブ開発、1つのコードで両方に対応するクロスプラットフォーム開発、Webの技術でアプリのように動かすPWA（Progressive Web Apps）に大きく分かれます。方式によって、費用、期間、できることの範囲、公開後の保守のしやすさが変わります。
また、アプリの費用は開発費だけでは終わりません。アプリストアへの登録費用、審査への対応、OSのアップデートへの追随、サーバーの運用など、公開後も費用がかかり続けます。開発費だけを比べて選ぶと、数年後の総額で想定を大きく超えることがあります。
この記事では、スマホアプリの費用の内訳、3つの方式の違いと費用への影響、開発費以外にかかる費用、方式の選び方を、発注する立場から整理します。記載している料金や規約は2026年10月時点の公式情報に基づくもので、今後変わる可能性があります。
スマホアプリの費用はどう決まるか
スマホアプリの開発費は、ほかのシステム開発と同じく、作業量（人月）と単価の掛け算で決まります。単価の参考として、日本情報システム・ユーザー協会（JUAS）の「ソフトウェア・メトリクス調査2025」では、スクラッチ開発プロジェクト99件の外注コストの加重平均単価が96万円/人月と報告されています。比較的規模の大きい企業のプロジェクトが中心のデータで、実際の単価は依頼先の体制によって変わります。
見積もりの差が大きくなるのは、作業量の見立ての違いです。スマホアプリの作業量は、次のような部分に分けて考えると比較しやすくなります。
| 費用の内訳 | 内容 |
|---|---|
| 企画・要件定義 | 目的、利用者、機能の範囲、画面の流れを決める |
| デザイン | 画面のデザイン、操作の設計、アイコンやストア掲載画像の作成 |
| アプリ本体の開発 | iOS・Android向けの画面と機能の実装 |
| サーバー側の開発 | 会員情報、データの保存、管理画面、APIなど、アプリの裏側の仕組み |
| 外部連携 | 決済、ログイン（SNS連携など）、地図、プッシュ通知、既存システムとの連携 |
| テスト | 複数の機種・OSバージョンでの動作確認 |
| 公開作業 | ストアへの登録、審査への対応 |
見落とされやすいのが「サーバー側の開発」です。会員登録、ポイント、予約、チャットなど、利用者ごとのデータを扱うアプリは、アプリ本体と同じかそれ以上の作業量がサーバー側にかかることがあります。見積もりを比べるときは、アプリ本体だけの金額なのか、サーバー側と管理画面まで含んだ金額なのかを必ず確認してください。
参考：ソフトウェア・メトリクス調査2025【ガイドブック】／日本情報システム・ユーザー協会（JUAS）
ネイティブ・クロスプラットフォーム・PWAはどう違うか
3つの方式の特徴を整理すると、次のようになります。
| 方式 | 作り方 | 得意なこと | 苦手なこと |
|---|---|---|---|
| ネイティブ | iOSはSwift、AndroidはKotlinなど、それぞれの専用言語で別々に作る | 端末の機能を最大限に使える。動作が滑らかで、OSの新機能にも早く対応できる | 2つのアプリを作ることになり、開発・保守の手間が大きい |
| クロスプラットフォーム | FlutterやReact Nativeなどの仕組みで、1つのコードから両OS向けのアプリを作る | 多くの部分を共通化でき、ネイティブより開発・保守の手間を抑えやすい | 端末固有の機能やOSの新機能を使う部分は、個別の対応が必要になることがある |
| PWA | Webの技術で作り、ブラウザからホーム画面に追加して使う | ストアの審査なしで公開・更新できる。Webサイトとして検索からも入れる | 使える端末の機能に制限がある。ストアからの集客ができない |
PWAについては、以前はiPhoneでプッシュ通知が使えないことが大きな制約でしたが、iOS 16.4以降はホーム画面に追加したWebアプリでWebプッシュ通知を受け取れるようになりました。ただし、利用者がホーム画面への追加を行い、通知の許可を操作する必要があるため、ストアからインストールするアプリと同じ感覚で通知を届けられるわけではありません。
クロスプラットフォームは、iOSとAndroidの両方に対応する業務アプリや会員アプリで広く選ばれている方式です。ただし、カメラの高度な制御、Bluetooth機器との連携、バックグラウンドでの位置情報の取得など、端末の機能に深く依存する部分が多いアプリでは、結局その部分をOSごとに作ることになり、共通化の効果が薄れます。
参考：Web Push for Web Apps on iOS and iPadOS／WebKit
方式によって費用と期間はどう変わるか
同じ機能のアプリを作る場合、作業量の大小関係はおおむね「ネイティブ（2OS）＞クロスプラットフォーム＞PWA」になります。ただし、差の大きさはアプリの内容によって変わるため、一律に「何割安くなる」とは言えません。
| 方式 | アプリ本体の作業量 | 公開後の保守の手間 | 注意点 |
|---|---|---|---|
| ネイティブ | 大きい。画面と機能をOSごとに作る | 大きい。修正もOSごとに行う | iOSとAndroidのどちらか一方から始めると初期費用を抑えられる |
| クロスプラットフォーム | 中程度。共通化できる割合が高いほど小さくなる | 中程度。仕組み自体の更新への追随が必要 | 端末固有の機能が多いと、共通化の効果が小さくなる |
| PWA | 小さい。Webサイトの開発に近い | 小さい。審査なしで更新できる | 必要な端末機能が使えるか、事前の確認が必須 |
注意したいのは、方式の違いで変わるのは主に「アプリ本体」の作業量だという点です。前の章で触れたサーバー側の開発、デザイン、要件定義、外部連携の作業量は、どの方式を選んでも大きくは変わりません。サーバー側の比重が大きいアプリほど、方式の選択による総額の差は小さくなります。
期間についても同じ傾向です。アプリ本体の開発期間は方式によって変わりますが、要件定義やサーバー側の開発、ストアの審査にかかる時間は方式に関係なく必要です。見積もりで期間を比べるときは、どの工程にどれだけの期間を見込んでいるかの内訳を確認すると、無理のある計画かどうかを判断しやすくなります。
開発費以外にかかる費用
アプリは公開した後も費用がかかり続けます。主なものを整理します。
| 費用 | 内容 |
|---|---|
| Apple Developer Program | App Storeでアプリを公開するために必要。Appleの公式案内では年額99ドル（または現地通貨相当額）で、地域によって異なる場合がある |
| Google Playのデベロッパー登録 | Google Playでアプリを公開するために必要。Googleの公式ヘルプでは1回限りの登録料25ドル |
| サーバー・インフラ費 | 利用者数やデータ量に応じて毎月かかる |
| 保守・OS対応 | 毎年のOSのアップデート、ストアの規約変更、開発に使う仕組みの更新への対応 |
| 外部サービスの利用料 | 決済、プッシュ通知、地図、SMS認証などの従量課金 |
| ストアの手数料 | アプリ内で有料のデジタルコンテンツやサービスを販売する場合に発生する。料率は規約によって決まる |
会社名義でApp Storeにアプリを公開する場合、AppleのDeveloper Programには組織として登録する必要があり、D-U-N-S番号（企業を識別する番号）や組織のドメインのWebサイトなどが求められます。準備に時間がかかることがあるため、公開予定日から逆算して早めに手続きを始めておきましょう。
また、アプリは公開前にストアの審査を受ける必要があり、指摘を受けて修正し再提出することもあります。審査にかかる時間は内容や時期によって変わるため、キャンペーンの開始日などに合わせて公開したい場合は、審査と修正の期間に余裕を持たせた計画にしておくことが大切です。
ストアの手数料については、日本では2025年12月18日に「スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律」（スマホソフトウェア競争促進法）が全面施行され、AppleとGoogleがアプリストアなどの規制対象として指定されています。これに伴い、アプリの配信方法や決済手段の選択肢、手数料の条件が変わりつつあります。アプリ内で課金を予定している場合は、最新の規約を公式情報で確認してから収支を計画してください。
見積もりを依頼したら、金額とあわせて次の点を確認しておくと、後からの追加費用を防ぎやすくなります。
- サーバー側の開発と管理画面が見積もりに含まれているか
- 動作確認の対象とする機種とOSバージョンの範囲
- ストアへの登録作業と、審査で修正を求められた場合の対応が含まれているか
- デザインの修正回数や、仕様変更が発生した場合の扱い
- ソースコードや各種アカウントの権利・管理者が誰になるか
特に最後の点は見落とされがちです。ストアのアカウントやサーバーの契約が開発会社の名義になっていると、将来ほかの会社に保守を移すときにアプリの引き継ぎが難しくなります。アカウントは自社の名義で作成し、開発会社には必要な権限だけを付与する形にしておくのが安全です。
また、保守費を見積もりに含めていない開発会社もあります。OSのアップデートで動作しなくなったり、ストアの審査基準の変更に対応しなかったりすると、アプリを更新できなくなります。開発費とあわせて、公開後の保守の範囲と費用を確認しておくことが重要です。
参考：スマホソフトウェア競争促進法（スマホ法）／公正取引委員会
方式の選び方
方式を選ぶときは、「アプリで何をしたいか」と「どこから利用者に来てもらうか」の2つから考えると判断しやすくなります。
| 状況 | 向いている方式 |
|---|---|
| 社内の業務で使う、または既存の顧客にURLを案内して使ってもらう。端末の特殊な機能は使わない | PWA、またはスマホ対応のWebアプリ |
| iOSとAndroidの両方で、会員証、予約、ポイント、通知などの一般的な機能を提供したい | クロスプラットフォーム |
| カメラ・センサー・Bluetooth機器などを高度に使う、動作の滑らかさが体験の中心になる | ネイティブ |
| 利用者の大半がどちらか一方のOSに偏っている | そのOSのネイティブから始め、必要に応じてもう一方を追加 |
| ストアの検索から新規の利用者を集めたい | ネイティブまたはクロスプラットフォーム（ストアに公開できる方式） |
判断に迷う場合は、最初からアプリにせず、スマホ対応のWebアプリやPWAで利用者の反応を確かめてから、アプリ化を検討する進め方もあります。利用者が本当に繰り返し使うのか、プッシュ通知が必要なほど頻繁に接点を持つ必要があるのかが分かってから投資すれば、使われないアプリに大きな費用をかけるリスクを減らせます。
一方で、すでに利用者が多く、アプリでしか実現できない体験が事業の中心にあるなら、最初から品質を優先してネイティブやクロスプラットフォームで作る方が、作り直しの費用がかかりません。いずれの場合も、見積もりを依頼する前に「対応するOS」「使う端末の機能」「サーバー側で扱うデータ」「公開後の保守の範囲」の4点を書き出しておくと、各社の提案を同じ条件で比較できます。
まとめ
スマホアプリの費用は、作業量と単価の掛け算で決まります。見積もりの差が大きくなるのは、開発の方式と、サーバー側の開発や管理画面、保守を含むかどうかの違いによるものです。
ネイティブは端末の機能を最大限に使える代わりに2つのアプリを作る手間がかかり、クロスプラットフォームは共通化で手間を抑えやすく、PWAはストアの審査なしで公開できる代わりに使える機能とストアからの集客に制約があります。方式で変わるのは主にアプリ本体の作業量で、サーバー側の比重が大きいアプリほど方式による総額の差は小さくなります。
公開後も、ストアの登録費用、サーバー費、OSへの追随などの保守費がかかります。アプリ内課金を予定している場合は、スマホソフトウェア競争促進法の全面施行後の最新の規約を確認してください。
明日できることとして、アプリで実現したいことを「端末の機能が必要なもの」と「Webでもできるもの」に分けて書き出してみてください。Webでもできるものが大半なら、まずPWAやWebアプリで始める選択肢が見えてきますし、端末の機能が必要なものが多ければ、方式の検討と見積もりの依頼を具体的に進められます。