スマホアプリの保守費用は、一般に初期開発費の年10〜20%程度が一つの目安です。標準的な業務・会員アプリなら月額10万〜50万円程度ですが、対応時間やサーバー構成により月5万円程度から100万円超まで変動します。見積時は対象範囲、受付時間、復旧目標、追加料金を明文化してください。
本記事でいう保守(=不具合修正やOS更新によって正常な状態を保つ業務)と運用(=監視、問い合わせ、コンテンツ更新など、サービスを日常的に動かす業務)は別の作業です。料金だけでなく、この両方のどこまでを委託するかが、適切な保守会社を選ぶうえで重要になります。
アプリ保守費用の相場と必要な期間
アプリ保守の予算は、月額料金だけでなく、クラウド利用料、外部サービス利用料、突発的な改修費、引き継ぎ費を分けて考える必要があります。月額が安く見えても、実作業がほとんど別料金なら、年間総額は高くなる可能性があります。
規模別の月額費用目安
以下は、スマホアプリの保守を開発会社へ外注する場合の一般的な目安です。実際の金額は、利用者数、機能数、決済や個人情報の有無、受付時間、サーバー側システムの構成によって変わります。
| 保守レベル | 月額費用の目安 | 想定されるアプリ | 主な対応内容 |
|---|---|---|---|
| 最小構成 | 5万〜15万円程度 | 更新頻度が低い情報提供アプリ、小規模な社内アプリ | 平日日中の問い合わせ、軽微な調査、定期更新の相談 |
| 標準構成 | 15万〜50万円程度 | 会員、予約、店舗、営業支援などの一般的なアプリ | 障害調査、OS対応、ストア更新、サーバー監視、月次報告 |
| 高可用性構成 | 50万〜150万円以上 | 決済、医療、金融、大規模会員サービスなど | 夜間・休日の連絡体制、迅速な障害対応、セキュリティ対応、詳細な監視 |
| スポット対応 | 1人日5万〜15万円程度 | 定期契約を結ばず、必要時だけ依頼するアプリ | 調査、軽微な修正、ストア更新などを都度見積もり |
高可用性とは、システムが止まりにくく、障害が起きても早期に復旧できる性質です。24時間365日の監視や深夜の復旧作業まで求めると、複数人で待機する体制が必要になるため、費用は大きく上がります。
一方、利用者が少なく、数時間の停止が事業に大きな影響を与えないアプリであれば、平日日中のみの対応に限定して費用を抑えられます。すべてのアプリに高度な監視体制が必要なわけではありません。
月額料金とは別に発生しやすい費用
保守見積もりでは、次の費用が月額に含まれているかを確認してください。
- クラウドサーバーやデータベースの利用料:月数千円〜数十万円以上
- エラー監視、アクセス解析、メール配信などの外部サービス利用料
- Apple・Googleの開発者アカウントに関する費用
- 大規模な機能追加や画面改修:1件数十万〜数百万円以上
- セキュリティ診断:数十万〜数百万円程度
- 他社から引き継ぐ場合の現状調査:30万〜200万円程度
- ストア審査で追加対応が求められた場合の修正費
- 利用者からの問い合わせを受けるカスタマーサポート費
初期開発費の年10〜20%という考え方は、予算の概算には便利です。ただし、初期開発費が低くても、決済や個人情報を扱い、短時間での復旧が必要なら、保守費用は高くなります。反対に、初期開発費が高くても、公開後の更新が少ないアプリは低く抑えられることがあります。
引き継ぎに必要な期間
新しい開発会社へ保守を移管する場合、準備から運用開始までは一般に1〜2か月程度が目安です。資料や権限が不足している場合は、2〜3か月以上かかることもあります。
| 工程 | 期間の目安 | 実施内容 |
|---|---|---|
| 資料・権限の確認 | 1〜2週間 | ソースコード、仕様書、契約、アカウントを確認 |
| 技術調査 | 2〜4週間 | アプリ、サーバー、外部連携、既知の不具合を調査 |
| 運用設計 | 1〜3週間 | 連絡方法、障害レベル、対応時間、報告方法を決定 |
| 並行運用 | 1〜4週間 | 旧会社と新会社が共同で問い合わせや更新に対応 |
公開日と同時に旧会社との契約を終了すると、移管中に障害が発生したときの担当が不明確になります。可能であれば、少なくとも数週間は新旧2社の契約期間を重ねるほうが安全です。
保守運用で委託する範囲と優先順位
スマホアプリの保守は、アプリ本体だけでは完結しません。発注時には「アプリ」「サーバー」「ストア」「外部サービス」「利用者対応」の5領域に分けると、作業の抜け漏れを防ぎやすくなります。
アプリ本体とOSへの対応
iOSやAndroidは定期的に更新されます。公開時に正常だったアプリでも、新しいOSや端末で表示崩れ、通知不良、ログイン失敗などが発生する可能性があります。
アプリ本体の保守には、主に次の作業があります。
- iOS・Androidの新しいバージョンでの動作確認
- 画面崩れ、フリーズ、クラッシュ(=アプリの異常終了)の修正
- SDK(=外部機能を組み込むための開発部品)の更新
- 古い端末やOSをサポート対象から外す判断
- アプリ署名に使う証明書や鍵の管理
- 不具合修正版のビルドとストアへの提出
OSの大型更新が公開されてから調査を始めるのではなく、事前に提供されるテスト版で主要機能を確認する運用が理想です。ただし、すべての機能を毎回検証すると費用が増えるため、ログイン、決済、予約、通知など、事業上重要な機能から優先順位を付けます。
サーバーと外部連携の保守
ログイン、会員情報、予約、決済、チャットなどを備えたアプリは、バックエンド(=データ保存や業務処理を担うサーバー側の仕組み)と通信しています。アプリ画面だけを保守しても、サーバー障害や容量不足には対応できません。
確認すべき作業は次のとおりです。
- サーバー、データベース、通信状況の監視
- データのバックアップと復元テスト
- セキュリティ更新と脆弱性への対応
- アクセス増加に応じた容量・性能の見直し
- API(=アプリと外部システムをつなぐ接続口)の監視
- 決済、地図、SNSログイン、メール配信など外部サービスの仕様変更対応
- 障害時の原因調査とデータ復旧
特に注意したいのが、外部サービスの仕様変更です。アプリ自体を変更していなくても、決済会社やSNSの接続方式が変わると、一部機能が利用できなくなることがあります。利用中の外部サービス一覧と契約者を保守会社へ共有しておきましょう。
ストアとアカウントの管理
App StoreやGoogle Playでは、アプリの更新だけでなく、説明文、画像、プライバシー情報、対象年齢などの管理も必要です。審査基準や提出要件が変更された場合は、追加の申告やアプリ修正を求められることがあります。
ストア管理で決めておく項目は以下のとおりです。
- 開発者アカウントの契約名義と管理者
- 更新版を提出できる担当者
- 審査で却下された場合の修正担当と費用
- ストアから届く警告や規約変更通知の確認担当
- 説明文、スクリーンショット、プライバシー表示の更新担当
- 公開停止や緊急アップデートを判断する責任者
アカウントは、原則として発注企業自身の名義で保有することをおすすめします。開発会社名義にすると、契約終了時にアプリを移管できなかったり、手続きに時間がかかったりする可能性があるためです。審査や公開作業を個別に依頼したい場合は、アプリ申請代行の費用相場|外注手順と注意点も参考にしてください。
発注前に決める優先順位
すべての障害を同じ速さで直す必要はありません。影響度に応じてレベルを分けると、必要以上に高額な体制を避けられます。
| 障害レベル | 例 | 対応方針の例 |
|---|---|---|
| 緊急 | 全利用者がログインできない、決済できない、情報漏えいの疑い | 夜間・休日を含めて連絡し、最優先で調査 |
| 高 | 一部利用者が主要機能を使えない | 当日または翌営業日までに調査開始 |
| 中 | 特定端末の表示崩れ、回避手段がある不具合 | 数営業日以内に原因と修正方針を報告 |
| 低 | 文言の誤り、軽微な操作性の改善 | 定期アップデートにまとめて対応 |
ここでいう「調査開始」と「復旧完了」は異なります。発注のご相談を受ける立場でも、「1時間以内に対応」と書かれているため1時間で直ると思っていた、という認識違いは少なくありません。契約では、連絡を受け付ける時間、一次回答までの時間、調査開始までの時間、目標復旧時間を分けてください。
契約形態と保守見積もりの確認ポイント
保守契約は、月額固定、作業時間に応じた契約、スポット契約を使い分けます。料金の安さだけでなく、突発的な障害が契約内で対応されるかを比較することが重要です。
契約形態の違い
| 契約形態 | 向いているケース | メリット | 注意点 |
|---|---|---|---|
| 月額固定 | 毎月の監視や問い合わせが発生する | 予算を立てやすく、連絡先を固定できる | 含まれる作業時間と超過単価の確認が必要 |
| 準委任契約 | 改善内容や作業量が毎月変わる | 優先順位を変えながら柔軟に進められる | 成果物の完成自体を保証する契約ではない |
| スポット契約 | 更新が少なく、停止影響も小さい | 固定費を抑えられる | 緊急時に担当者を確保できるとは限らない |
| 請負契約 | OS対応など作業範囲が明確 | 完成条件と金額を決めやすい | 想定外の調査や仕様変更は追加費用になりやすい |
準委任契約とは、決めた業務を専門家として遂行する契約です。特定機能の完成を約束する請負契約とは異なるため、毎月確保される時間、担当者、報告内容を確認します。
実務では、監視や問い合わせ窓口を月額固定にし、機能追加や大きなOS対応を別途見積もりにする組み合わせが一般的です。責任範囲を明確にしやすく、保守会社も必要な体制を準備できます。
見積書で確認する項目
保守見積もりを受け取ったら、次の項目を確認してください。
- 対象となるiOS・Androidアプリの名称とバージョン
- サーバー、管理画面、API、外部サービスが対象に含まれるか
- 月額内に含まれる作業時間と、未使用時間の繰り越し可否
- 超過時の時間単価または人日単価
- 平日、夜間、休日それぞれの受付時間
- 障害レベルごとの一次回答時間と調査開始時間
- OS・SDK更新、ストア提出、審査対応が含まれるか
- クラウド利用料や監視ツール利用料が含まれるか
- 機能追加と不具合修正をどのように区別するか
- 保証期間内の不具合と保守契約の関係
- 月次報告、定例会、改善提案の有無
- 契約終了時に返却される資料、データ、アカウント
「軽微な修正を含む」という表現だけでは不十分です。画面の文言変更は含まれるが、ストアへの再申請は別料金という場合もあります。具体例を2〜3件示し、それぞれ契約内か追加料金かを質問すると比較しやすくなります。
SLAで決めるべきこと
SLA(Service Level Agreement、=提供するサービス水準の合意)には、実現可能な目標を設定します。代表的な項目は次のとおりです。
- 問い合わせの受付時間
- 障害を検知してから通知するまでの時間
- 連絡を受けてから一次回答するまでの時間
- 障害レベルごとの調査開始目標
- バックアップの取得頻度と保存期間
- 月次の稼働状況や障害件数の報告方法
- SLAを満たせなかった場合の報告・改善手順
アプリストアの審査期間は、開発会社が完全に管理できません。そのため「申請から必ず24時間以内に公開」といった条件ではなく、「修正版を何営業日以内に提出するか」を合意するほうが現実的です。
保守外注の進め方と会社の選び方
保守外注を成功させるポイントは、見積もりを依頼する前に、資産とアカウントを棚卸しすることです。資料が不足したままでは、開発会社もリスクを見込んだ高めの見積もりを出すか、調査後に大幅な追加費用を提示せざるを得ません。
発注前の準備チェックリスト
次の情報を可能な範囲で用意してください。すべてそろっていなくても相談できますが、不足しているものは最初に申告することが重要です。
- App Store・Google Playの公開URL
- ソースコードとリポジトリ(=ソースコードの変更履歴を保存する場所)
- 画面・機能一覧、設計書、API仕様書
- アプリを生成するためのビルド手順
- クラウド、データベース、ドメインの契約情報
- Apple・Googleの開発者アカウント
- 証明書、秘密鍵、外部サービスの接続情報
- エラー監視、アクセス解析、通知配信の管理画面
- 現在発生している不具合と問い合わせ履歴
- 過去のリリース履歴と審査で指摘された内容
- 現行の開発・保守会社との契約書
- 個人情報保護方針、利用規約、社内のセキュリティ基準
パスワードや秘密鍵を、見積もり段階でそのままメール送付するのは避けてください。まずは資産の有無と管理者を一覧化し、契約後に安全な共有手段を決めます。
発注から運用開始までの7ステップ
-
事業への影響を整理する
アプリが1時間停止した場合の売上、顧客対応、社内業務への影響を確認します。 -
保守対象を棚卸しする
アプリ本体だけでなく、サーバー、管理画面、ストア、外部サービスも一覧化します。 -
希望する対応水準を決める
平日のみか夜間も必要か、一次回答と復旧の目標時間を決めます。 -
候補会社へ現状調査を依頼する
他社開発のアプリでは、正式見積もりの前に有償調査を行うことがあります。これは不要な費用ではなく、保守可能性とリスクを判断する工程です。 -
見積もりと契約条件を比較する
月額だけでなく、対象範囲、超過単価、担当体制、解約・移管条件を比較します。 -
引き継ぎとテストを行う
新会社がアプリを生成し、テスト環境へ接続し、ストア提出まで実施できるか確認します。 -
月次で状況を見直す
障害、問い合わせ、作業時間、クラウド費用を確認し、不要な作業や将来の改修候補を整理します。
資料の不足や現在の保守範囲がわからない場合は、最初から固定額の年間契約を結ぶより、現状調査を経て契約範囲を確定する方法が適しています。開発のご相談はこちらから、アプリとサーバーを含めた保守体制についてご相談いただけます。
保守会社を見極める質問
保守会社には、実績件数だけでなく、実際の対応方法を質問してください。
- iOSとAndroidの両方を担当できる技術者がいるか
- アプリだけでなく、サーバーやAPIも調査できるか
- 担当者が休暇・退職した場合の代替体制があるか
- 夜間や休日の連絡は誰がどの方法で受けるか
- 重大障害を想定した連絡訓練や復旧テストを行えるか
- 他社開発アプリの引き継ぎ経験があるか
- 作業履歴、設計変更、アカウント情報をどこに記録するか
- 契約終了時に別会社へ移管できる状態を維持するか
- 不具合修正だけでなく、利用状況に基づく改善提案ができるか
たとえば「金曜日の夜に全利用者がログインできなくなった場合、誰が何分以内に確認し、発注者へ何を報告するか」と具体的に質問します。明確な手順を説明できる会社は、体制や責任分担を設計している可能性が高いと判断できます。
価格以外の提案力、品質管理、契約条件を含めた比較方法は、システム開発会社の選び方|発注前の比較ポイントでも詳しく解説しています。
よくある失敗と回避策
失敗1:月額料金だけで選ぶ
月額5万円でも、調査、修正、ストア提出がすべて別料金なら、障害のたびに追加費用が発生します。代表的な作業例を提示し、契約内・契約外を確認してください。
失敗2:応答時間を復旧時間だと誤解する
「1時間以内に応答」は、受付連絡を返す意味かもしれません。一次回答、調査開始、暫定復旧、恒久修正を分けて合意します。
失敗3:アカウントを開発会社名義のままにする
ストア、クラウド、ドメイン、外部サービスは、できる限り発注企業名義で契約します。開発会社には必要な権限だけを付与します。
失敗4:担当者一人に情報が集中する
担当者しかアプリを公開できない状態は、休職や退職時のリスクになります。手順書、権限一覧、障害履歴を共有し、複数人が対応できる体制を確認してください。
失敗5:修正を先送りし続ける
古いSDKや未更新のライブラリが積み重なると、将来まとめて対応する際の費用と不確実性が増えます。このような将来の改修負担を技術的負債と呼びます。四半期または半年ごとに更新候補を棚卸ししてください。
失敗6:解約時の引き継ぎを契約していない
契約終了時に、資料作成や別会社への説明が有償になることは珍しくありません。返却物、引き継ぎ期間、作業単価、アカウント削除まで契約時に決めておきます。
まとめ
- スマホアプリの保守費用は、標準的な構成で月額10万〜50万円程度が一般的な目安です
- 更新が少ない小規模アプリは月5万〜15万円程度、高い可用性や夜間対応が必要なら月50万〜150万円以上になることがあります
- 月額料金とは別に、クラウド利用料、外部サービス利用料、大規模改修費、引き継ぎ調査費を見込みます
- 保守対象はアプリ本体だけでなく、サーバー、API、ストア、アカウント、外部サービスまで確認します
- 見積書では、受付時間、一次回答時間、調査開始時間、超過単価、契約外作業を明確にします
- 他社へ移管する場合は、ソースコード、ビルド手順、設計資料、各種アカウントを棚卸しします
- 開発会社を選ぶ際は、障害時の具体的な対応手順、複数人の体制、サーバーを含む対応力を確認します
- ストアやクラウドのアカウントは、原則として発注企業が保有すると将来の移管が容易です
アプリ保守は、公開後に不具合が起きてから探すのではなく、開発中に対象範囲と予算を決めておくことが重要です。事業への影響に合った対応水準を設定すれば、必要以上に高額な体制を避けながら、継続的にサービスを提供できます。
よくある質問
スマホアプリの保守費用は月額いくらですか?
一般的な目安は月額10万〜50万円程度です。更新頻度が低い小規模アプリは5万〜15万円程度、高い可用性や夜間対応が必要なアプリは50万〜150万円以上になることがあります。クラウド利用料や大規模改修費が含まれるかも確認してください。
公開後すぐに保守契約は必要ですか?
原則として公開時点から必要です。公開直後は端末・OS固有の不具合や問い合わせが発生しやすく、証明書、ストア情報、監視、障害連絡先を空白にできません。利用者が少ない場合は、対応時間を限定した小規模プランにする方法があります。
開発会社とは別の会社へ保守を依頼できますか?
可能です。ただし、ソースコード、設計資料、ビルド手順、ストア・クラウドの権限がそろっていることが前提です。移管前に現状調査を行い、未解決不具合と技術的負債、保証対象外の範囲を双方で合意してください。
ソースコードや仕様書がないアプリも引き継げますか?
引き継げる場合はありますが、通常より調査費と期間が必要です。ソースコードが取得できない場合は、既存アプリの継続保守が難しく、再開発が必要になることもあります。まず契約、アカウント、リポジトリ、サーバーの保有者を確認してください。