Webアプリとスマホアプリはどっちが稼げる？収益モデル・手数料・実務での選び方

「Webアプリとスマホアプリ、結局どっちが稼げるの？」という話は、かなりよく出ます。

ただ、ここは単純に「スマホアプリの方が課金しやすい」「Webアプリの方が手数料が安い」とだけ見ると、だいたい判断を外します。稼げるかどうかは、配布経路、課金のしやすさ、手数料、開発費、継続利用のされ方、サポート負荷まで含めて見た方がいいです。

先に要点

低コストで検証して早く売上を作りたいなら、まず Webアプリが向いています。
毎日開く、通知を使う、端末機能を深く使う、ブランド体験を強く出すならスマホアプリが強いです。
デジタルコンテンツやサブスクをアプリ内で売る場合は、アプリ内課金のルールと手数料を必ず見ます。
最初から両方作るより、Webで売れる形を検証してからアプリ化する方が失敗しにくいです。

この記事でいうWebアプリとスマホアプリ

まず言葉をそろえます。

この記事でいう Webアプリは、ブラウザから使うアプリです。
予約システム、SaaS、会員サイト、業務システム、EC、管理画面、学習サービスなどが分かりやすい例です。

スマホアプリは、App Store や Google Play からインストールして使うアプリです。
Swift、Kotlin、Flutter、React Native などで作るネイティブアプリや、ネイティブ寄りのクロスプラットフォームアプリを含めて考えます。

その中間に PWA があります。
MDN では、PWA は Web 技術で作りながら、端末にインストールされたアプリのような体験を提供できるものとして説明されています。
つまり、Webだけどアプリっぽく使える選択肢です。

ここで大事なのは、技術分類そのものよりも、どこでユーザーと接点を持ち、どこでお金を受け取るか です。
同じ機能でも、Webで売るのか、アプリストアで売るのかで、利益率も運用もかなり変わります。

結論: 稼げるかは「売り方」で変わる

かなりざっくり言うと、次のように考えると外しにくいです。

観点	Webアプリが向く	スマホアプリが向く
初期検証	早く作って試しやすい	ストア申請や審査があり重くなりやすい
課金	自社決済・請求書・銀行振込などを組みやすい	アプリ内課金ルールの影響を受けやすい
集客	SEO、広告、SNS、法人営業と相性がよい	ストア検索、ランキング、レビュー、通知と相性がよい
継続利用	業務利用や管理画面に強い	毎日使う習慣化、通知、端末機能に強い
利益率	決済手数料を抑えやすい	ストア手数料や審査対応が入る
体験品質	ブラウザ制約を受ける	カメラ、位置情報、通知、オフラインなどを作り込みやすい

つまり、売る相手が企業や業務利用ならWebアプリが強く、毎日開く個人向けサービスならスマホアプリが強くなりやすい です。

ただし、これは絶対ではありません。
個人向けでもWebの方が売りやすいサービスはありますし、法人向けでも現場作業アプリのようにスマホアプリが強いケースもあります。

Webアプリが稼ぎやすい場面

Webアプリが強いのは、まず販売までの距離が短いことです。

URLを共有すれば使えます。
広告からLPへ流し、無料登録、トライアル、決済、利用開始までをWeb上で完結させやすいです。
法人向けなら、問い合わせ、見積もり、契約、請求書払いにもつなげやすいです。

特に次のようなサービスはWebアプリと相性がよいです。

業務管理システム
SaaS
予約・問い合わせ・見積もりサービス
ECや会員サイト
管理画面が中心のサービス
BtoB向けツール
PCで作業する時間が長いサービス

Webアプリの収益化で強いのは、価格設計の自由度 です。
月額、年額、従量課金、初期費用、保守費、導入支援費、請求書払い、法人プランなどを組み合わせやすいです。

たとえば中小企業向けの業務システムなら、月額3,000円の個人向けアプリを大量に売るより、月額3万円から10万円の法人契約を少数積み上げる方が現実的なこともあります。
この場合、スマホアプリのダウンロード数より、商談、導入支援、継続率の方が大事になります。

Webアプリの弱点

もちろんWebアプリにも弱点はあります。

まず、スマホのホーム画面に自然に居座る力は、スマホアプリより弱いです。
通知、オフライン、カメラ、位置情報、バックグラウンド処理なども、できることは増えていますが、ネイティブアプリほど自由ではありません。

また、個人向けサービスでは「アプリストアにあるから安心」「ランキングで見つけた」「レビューを見て入れた」という導線を取りにくいです。
SEOや広告、SNS、紹介、法人営業など、別の集客設計が必要になります。

スマホアプリが稼ぎやすい場面

スマホアプリが強いのは、端末に入り込みやすいことです。

ホーム画面にアイコンがあり、通知を送れて、カメラや位置情報、プッシュ通知、端末内の体験と組み合わせやすい。
この強さはWebだけではなかなか出せません。

特に次のようなサービスはスマホアプリと相性がよいです。

毎日使う習慣化アプリ
学習、健康、家計簿、タスク管理
SNS、コミュニティ、マッチング
写真、動画、音声など端末機能を使うアプリ
通知が価値になるサービス
店舗会員証、ポイント、予約確認
現場作業、点検、配送、訪問記録

スマホアプリは、うまくハマると継続率が高くなります。
通知で戻ってきてもらえる、ホーム画面からすぐ開ける、操作が気持ちいい、という体験が収益につながります。

ゲーム、学習、健康、サブスク、コンテンツ配信のように、アプリ内で何度も利用してもらうモデルでは特に強いです。

スマホアプリの弱点

一方で、スマホアプリは公開までの手間が重いです。

Apple Developer Program は公式に年額 99 USD と案内されています。
Google Play Console も公式ヘルプで 25 USD の一回限りの登録費が案内されています。
金額自体よりも、審査、ストア掲載情報、スクリーンショット、プライバシー表示、SDK管理、OS更新対応、レビュー対応が継続的に発生する点が重いです。

さらに、デジタルコンテンツやアプリ機能をアプリ内で販売する場合、Apple の App Review Guidelines や Google Play の Payments policy を確認する必要があります。
Google Play では、Google Play で配布するアプリがアプリ内機能やデジタルコンテンツへの支払いを受ける場合、原則として Google Play の課金システムを使う必要があると説明されています。
Apple も App Store Review Guidelines で、デジタル機能やコンテンツの購入、サブスクリプションなどについて App Store のルールを定めています。

つまり、スマホアプリは「売れたら強い」反面、売る前から守るルールと運用コストが増えやすい です。

手数料で見るとどう違うか

収益性を見るなら、売上ではなく粗利で見た方がいいです。

たとえば月額1,000円のサービスでも、Web決済、App Store、Google Play、広告収益、法人請求では、残るお金が変わります。

収益経路	主なコスト・注意点
Webのクレジットカード決済	決済代行会社の手数料、チャージバック、請求管理
App Store のアプリ内課金	Apple Developer Program、審査、ストア手数料、アプリ内課金ルール
Google Play のアプリ内課金	Play Console登録、Google Play Billing、サービス手数料、Payments policy
広告収益	PV、継続利用、広告単価、表示体験の悪化
法人契約	営業、契約、請求書、導入支援、サポート

Apple は、Apple Developer Program の説明で、デジタル商品・サービスの App Store 販売に対する手数料を通常 30%、Small Business Program などでは 15% と案内しています。
Google Play も公式ヘルプで、15%サービスフィー枠では最初の年間100万USDまで15%、それを超える部分は30%、サブスクリプションは15%などと説明しています。

この数字だけ見ると「手数料があるスマホアプリは損」と思うかもしれません。
ただし、ストア決済には、ユーザーが支払いに慣れている、解約管理がしやすい、購入導線が端末に統合されている、という強さもあります。

逆にWeb決済は手数料を抑えやすいですが、ユーザーにカード情報を入れてもらう、請求や領収書を整える、解約導線を作る、問い合わせに対応する、といった実装と運用が必要です。

手数料だけで勝ち負けを決めるのではなく、その手数料を払ってでも購入率や継続率が上がるのか を見るべきです。

開発費で見るとどちらが重いか

初期開発だけを見ると、多くの場合はWebアプリの方が始めやすいです。

理由はシンプルで、ブラウザで動くものを1つ作れば、PCでもスマホでもまず使えるからです。
レスポンシブ対応やスマホ操作の調整は必要ですが、iOS版、Android版、Web版を別々に作るよりは軽く始められます。

一方、スマホアプリは次のような作業が増えます。

iOSとAndroidのビルド環境
ストア申請
スクリーンショットやストア説明文
プライバシー情報の提出
Push通知やアプリ内課金の実装
OSバージョンアップ対応
SDK更新
審査リジェクト対応

Flutter や React Native を使えば共通化できますが、それでも「アプリとして出すための運用」は消えません。
むしろ、Web、iOS、Androidの3面を見ることになり、チームが小さいと負担が増えやすいです。

実務の判断

最初の検証では、Webアプリで十分なことが多いです。
売れるか分からない段階でスマホアプリまで作ると、開発費が先に膨らみます。

逆に、以下の条件が見えているならスマホアプリを早めに検討してよいです。

通知が売上や継続率に直結する
カメラ、位置情報、Bluetooth、端末内データを使う
毎日開いてもらう必要がある
オフライン利用が重要
店舗や現場でスマホ操作が中心になる

集客で見るとかなり違う

Webアプリとスマホアプリでは、集客の考え方も違います。

Webアプリは、検索、広告、SNS、YouTube、記事、比較ページ、法人営業などから直接流入させやすいです。
LPを作って、問い合わせや無料登録へ誘導し、改善を回せます。
SEOと相性がよいテーマなら、長期的に集客コストを下げられる可能性もあります。

スマホアプリは、App Store や Google Play の検索、ランキング、レビュー、広告、紹介が重要になります。
インストールまで進めば強いですが、ストアページで離脱されることもあります。

ここでよくある失敗は、アプリを作れば勝手に見つけてもらえると思うことです。
今はアプリストアも競争が激しいので、ストア掲載文、スクリーンショット、レビュー、初回体験、継続率まで含めて作り込む必要があります。

Webでもアプリでも、作っただけでは売れません。
ただ、改善の回しやすさでいうと、Webの方が早いことが多いです。
文言、価格、導線、LP、フォーム、決済画面をすぐ変えられるからです。

広告収益ならどちらが向いているか

広告収益だけで見るなら、どちらが有利とも言い切れません。

Webなら、記事、検索流入、比較コンテンツ、ツールページなどでPVを集め、広告やアフィリエイトにつなげやすいです。
このサイトのような技術記事サイトは、基本的にはWeb向きです。

スマホアプリなら、起動回数が多いアプリ、ゲーム、ニュース、天気、ユーティリティなどで広告を出しやすいです。
ただし、広告を入れすぎると体験が悪くなり、レビューや継続率が落ちます。

広告モデルで大事なのは、単に表示回数を増やすことではなく、ユーザーが嫌にならない位置に広告を置けるか です。
特にアプリはレビューに悪影響が出やすいので、収益化を急ぎすぎると長期的に損をします。

サブスクならどちらが向いているか

サブスクは、Webでもスマホアプリでも成立します。

ただし、向いているサービスが違います。

Webサブスクに向いているのは、次のようなものです。

業務ツール
SaaS
管理画面付きサービス
法人向けプラン
請求書払いが必要なサービス
PC作業が中心のサービス

スマホアプリのサブスクに向いているのは、次のようなものです。

学習アプリ
健康・運動アプリ
習慣化アプリ
写真・動画・音声系
個人向けユーティリティ
毎日使うコンテンツサービス

スマホアプリの方が、ユーザーの生活に入り込みやすいので継続課金に向く場面はあります。
一方で、アプリ内課金のルールと手数料があるため、単価や利益率の設計は慎重に見る必要があります。

法人向けなら、Webで契約してアプリは補助的に提供する形もかなり現実的です。
たとえば、管理者はWeb管理画面、現場担当者はスマホアプリ、請求はWeb契約、という構成です。

PWAという中間案

いきなりスマホアプリを作る前に、PWA を検討する価値があります。

PWAは、Webアプリをホーム画面に追加できたり、オフライン対応や通知などを一部使えたりする仕組みです。
ネイティブアプリほど何でもできるわけではありませんが、Webの身軽さを残しながら、アプリっぽい体験に近づけられます。

特に次のような場合はPWAが合います。

まずWebでサービスを検証したい
ストア審査を避けたい
PCとスマホの両方で使わせたい
端末機能をそこまで深く使わない
小さなチームで運用したい

ただし、PWAにも限界があります。
端末機能、通知、ブラウザごとの差、ユーザーへのインストール誘導などは注意が必要です。

「Webで十分か、PWAで足りるか、それともネイティブアプリが必要か」を順に見ると、無駄な開発を避けやすくなります。

実務でのおすすめ順

個人的には、よほど明確な理由がない限り、最初は次の順で考えるのが堅いです。

まずWebで売れるか試す
スマホ利用が多ければPWAやスマホ最適化を強める
通知や端末機能が売上に効くと分かったらスマホアプリ化する
アプリ化後もWebのLP、SEO、問い合わせ導線は残す

いきなりスマホアプリから入ると、作るものが多くなります。
Webサイト、LP、管理画面、API、iOSアプリ、Androidアプリ、ストアページ、審査対応、課金、通知、分析。
これを小さなチームで同時に回すのはかなり大変です。

逆に、Webで「誰が、何に、いくら払うか」が見えているなら、スマホアプリ化は投資判断として考えやすくなります。
アプリはアイデアの証明ではなく、売れ始めたサービスを伸ばすための手段 と見る方が失敗しにくいです。

収益モデル別の向き不向き

買い切りアプリ

買い切りアプリは、スマホアプリでもWebでも難易度が上がっています。
継続収益がないため、常に新規ユーザーを取り続ける必要があるからです。

ただし、ニッチな業務ツールや専門家向けツールなら成立することがあります。
その場合でも、アップデート費用とサポート費用をどう回収するかを先に考えるべきです。

月額サブスク

月額サブスクは、Webでもスマホアプリでも強いです。
ただし、価値が継続しないとすぐ解約されます。

Webなら法人契約や複数ユーザー課金と相性がよく、スマホアプリなら習慣化やパーソナル用途と相性がよいです。

受託・導入支援

Webアプリは、受託開発や導入支援と組み合わせやすいです。
小規模企業向けに「月額システム + 初期設定 + 保守」という形にすると、単純なアプリ販売より収益が安定することがあります。

スマホアプリでも受託はありますが、iOS/Android両対応やストア申請、保守が入るため、見積もりは重くなりがちです。

「稼げる」の判断で見たいチェックリスト

最後に、作る前に見たいチェックリストを置いておきます。

質問	Web寄り	スマホアプリ寄り
ユーザーはPCで作業する？	はい	いいえ
毎日スマホで開く必要がある？	いいえ	はい
通知が価値になる？	弱い	強い
カメラや位置情報を深く使う？	弱い	強い
法人契約や請求書払いが多い？	強い	弱い
SEOや比較記事で集客できる？	強い	弱い
ストア検索で探されるテーマ？	弱い	強い
初期検証を安く速くしたい？	強い	弱い
アプリ内課金ルールを避けたい？	強い	弱い

この表でWeb寄りが多いなら、まずWebアプリで始めるのが自然です。
スマホアプリ寄りが多いなら、最初からアプリを見据えて設計してもよいです。

まとめ

Webアプリとスマホアプリのどちらが稼げるかは、アプリの種類だけでは決まりません。

Webアプリは、低コストで始めやすく、SEO、広告、法人営業、請求書払い、SaaS化と相性がよいです。
スマホアプリは、端末に入り込みやすく、通知、習慣化、アプリ内課金、ストア流入、端末機能を使うサービスで強くなります。

実務では、最初から「スマホアプリを作れば稼げる」と考えるより、まずWebで需要と課金を確認し、必要に応じてPWAやネイティブアプリに広げる方が堅いです。

一番大事なのは、どちらを作るかではなく、

誰が払うのか
何に払うのか
どの頻度で使うのか
手数料や運用費を引いて利益が残るのか
集客をどう続けるのか

を先に決めることです。

Webアプリは「早く試して売る」ことに強く、スマホアプリは「習慣化して伸ばす」ことに強い。
この違いで見ると、だいぶ判断しやすくなります。

参考リンク

Apple Developer: Membership Details
Apple Developer: App Store Small Business Program
Apple Developer: App Review Guidelines
Google Play Console Help: Service fees
Google Play Console Help: Payments
Google Play Console Help: Get started with Play Console
MDN: Progressive web apps

Webアプリとスマホアプリはどっちが稼げる？収益モデル・手数料・実務での選び方を解説