アプリ運用保守の費用は、アプリの規模、対応するOSやストア、保守の水準によって、月額3万円から数百万円まで変わります。費用の内訳では、OS更新やストア審査への対応がアプリならではの項目です。
スマホアプリ開発の費用の考え方や見積もりの注意点については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
▼見積依頼前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
アプリ運用保守の費用相場の全体像
アプリ運用保守の費用は、一般的に「開発費用の15％程度（年間）」が目安です。開発費が1,000万円なら、年間の保守費用は150万円前後です。月額では12万円程度が一つの基準になります。
ただし、この金額はあくまで出発点です。アプリはWebシステムと違い、OSの定期アップデートに追従する必要があります。さらに、ストア審査基準の変更にも対応し続けるため、同規模のWebシステムより保守負荷が高くなる傾向があります。
見積を正しく読むには、まず費用の構成要素を知ることが第一歩です。
保守費用を構成する3つの分類
アプリ運用保守の費用は、維持費・管理費・運用費の3分類で見ると、内訳を読み解けます。
- 維持費：インフラを動かし続ける固定的なコスト。
- 管理費：システムを健全に保つ作業の費用。
- 運用費：ビジネスを成長させる活動の費用。
維持費には、サーバーやデータベース、ドメインの費用が含まれます。SSL証明書や、プッシュ通知配信基盤、バックエンドAPIサーバーの稼働費用も維持費です。
管理費には、障害対応やバグ修正、セキュリティパッチの適用などが含まれます。OS更新への追従も、システムを健全に保つための作業です。アプリ運用保守では、この管理費がコストの中心になります。
運用費には、機能改善や新機能の追加、データ分析が含まれます。ユーザー対応も運用費に入ります。さらに、運用費は集客やマーケティングとも連動し、KPIの向上を狙う場合は投資が大きくなります。
見積書を読むときは、3分類のそれぞれにどれだけ費用が配分されているかを確認します。特に、維持費だけが計上され、管理費が薄い見積には注意が必要です。そうした見積では、障害対応やOS更新対応が手薄になっている可能性があります。
アプリならではの費用が発生する理由
アプリの保守費用がWebシステムより高くなりやすいのは、OSとストアへの継続的な対応が必要だからです。
- OS更新：API変更や非推奨機能の廃止への対応。
- ストア対応：審査基準の変更に合わせた改修。
iOSとAndroidは、年に1回以上のメジャーアップデートを行います。これに対応しない場合、アプリがクラッシュするリスクがあり、最悪の場合はストアから配信停止になる可能性もあります。
Apple App StoreとGoogle Playは審査基準を継続的に変更しており、プライバシー関連の表示義務やトラッキングの同意取得も追加されました。
アカウント削除機能の必須化など、新しいルールへの改修も必要になります。これらは、現状を維持するための作業であり、機能追加とは性格が異なります。それでも相応の工数がかかる点は、見積で見落とされがちです。
規模別・月額の費用レンジ
アプリ運用保守の月額費用は、規模・ユーザー数・サポート水準で大きく変わります。まず、規模別の目安と、それぞれの金額に含まれる内容を具体的に見ていきます。
小・中・大規模それぞれの月額目安
規模別の月額レンジを見ると、必要な保守水準に対して予算がどの程度かを判断できます。
- 小規模：月額3万〜8万円程度。
- 中規模：月額10万〜30万円。
- 大規模：月額数十万円〜数百万円。
小規模アプリは、個人向けの単機能アプリや社内利用アプリなどです。その水準では、OS更新時の動作確認と軽微なバグ修正が含まれます。
サーバーの稼働監視も含まれますが、緊急障害への即時対応は含まれないことが多く、対応は24時間体制ではなく平日日中が基本となります。
中規模アプリは、一定のユーザー数を抱える事業アプリです。OS更新への追従やストア審査基準の変更への対応、SDK更新に加えて、定期的なセキュリティパッチの適用もこの水準に含まれます。
クラッシュ監視ツールによる異常検知と一次対応も行います。さらに、月次レポートで稼働状況や不具合の発生状況を共有する契約も増えます。
大規模アプリは、数十万ダウンロード以上で決済や個人情報を扱うアプリです。24時間365日の監視体制や、専任エンジニアのアサインが含まれます。
重大障害時は、初回応答15分以内・解決4時間以内という厳格なSLAを置きます。さらに、稼働率99.9％以上など、高い品質保証も求められます。
行政の防災アプリでは、20万台規模で安定稼働させた事例があります。その事例では、年間稼働率99.99％以上・累計停止時間1時間以内が基準でした。このように、社会インフラ級のアプリほど、保守に求められる水準とコストは跳ね上がります。
月額固定型と従量課金型の違い
保守契約の料金体系は、月額固定型と従量課金型（スポット型）に分かれます。
- 月額固定型：一定の作業範囲を定額で請け負う契約。
- 従量課金型：発生した作業時間に応じた支払い。
月額固定型は毎月の予算が読みやすく、継続的なOS更新やセキュリティ対応を任せる形です。多くの事業アプリは、この月額固定型を選びます。
従量課金型は、障害や改修が必要になったときに、その都度費用を支払う形態です。保守の発生が少ないアプリであれば、従量課金型でコストを抑えられます。ただし、緊急対応の単価は割高になりやすく、対応の優先順位も後回しになりがちです。
OS更新は必ず発生しますが、時期を読みづらい作業です。そのため、月額固定型を基本にし、大規模改修だけ別途見積とする形が現実的です。
アプリ保守特有の費用項目
アプリ運用保守の見積は、総額だけでなく内訳も確認する必要があります。特に、OS更新対応やストア対応、SDK・ライブラリ更新が含まれているかを確かめます。
これらは、一般的なシステム保守の見積テンプレートには現れにくい項目です。そのため、抜けていると後から追加費用として請求される原因になります。
OS更新対応とストア審査対応の費用
OS更新とストア審査は、発生時期と作業範囲を契約前に確かめておく項目です。
- OS更新対応：新OSへの検証と、必要な修正の作業。
- ストア審査対応：基準変更やリジェクトへの対応。
OS更新対応は、iOSとAndroidの新バージョンが公開されるたびに発生します。新OSのベータ版が出た段階から、保守を担う側が動作検証を始めます。不具合があれば修正してリリースする一連の流れが、年に複数回必要になります。
OS更新対応を月額保守に含めるか都度見積とするかで総額は大きく変わるため、契約前にOS更新対応が保守範囲に含まれるかを書面で明確にしておくべきです。
ストア審査対応とは、AppleやGoogleの基準変更に伴う改修のことです。リジェクト（審査差し戻し）への対応も、この中に含まれます。
たとえば、アカウント削除機能の必須化やプライバシー表示の更新が該当します。ストア側の都合で発生する改修は、件数も時期も読めません。
OS更新対応とストア対応を合わせると、年間で数十万円規模になることもあります。この金額を「保守費用の15％目安」に上乗せして考えると、予算のブレを小さくできます。
SDK更新・クラッシュ監視のコスト
SDK更新とクラッシュ監視は、外部連携の安定性と障害発見に関わる費用です。
- SDK・ライブラリ更新：外部機能を安全な状態に保つ作業。
- クラッシュ監視：ユーザー端末の異常を捉える作業。
アプリには、決済や分析、プッシュ通知などの外部SDKやライブラリを組み込みます。SDKやライブラリは定期的に更新され、古いものはサポート終了の対象になります。さらに、古いバージョンはセキュリティ脆弱性の対象になることもあります。
更新を放置すると、プッシュ通知が届かない障害につながります。決済が通らなくなる可能性もあります。そのため、定期更新の作業は保守費用に組み込んでおく必要があります。
ユーザー端末でアプリが落ちた際には、そのログを集めて分析します。分析によって原因を特定し、修正につなげます。
クラッシュ率は、アプリの評価やストアでの表示順位にも影響します。そのため、監視ツールの利用料と分析工数を保守費用に含めるのが一般的です。
近年は、AIによるエラーログの自動解析や障害の自動検知を組み合わせることもあります。人手で全件を追わずに、異常の兆候を早期に拾う運用も広がりつつあります。こうした仕組みを使えば、監視工数を抑えながら品質を保つ選択肢も増えています。
費用を左右する主な要因
同じアプリ運用保守でも、見積金額が数倍違うことは珍しくありません。差が生まれる主な理由は、SLA水準、対応プラットフォーム数、アプリの複雑さです。
まず、自社の要件のどこにコストがかかるのかを把握します。そうすると、見積金額の差を読み解く手がかりになります。
SLA水準と対応時間帯
費用に最も大きく影響するのが、SLA（サービスレベル合意）の水準です。
- 重大障害：初回応答15分以内・解決4時間以内。
- 通常時：応答2時間以内・解決8時間以内。
SLAには、稼働率の保証値や、障害受付から一次対応までの応答時間を定めます。加えて、復旧目標時間も数値で決めます。
一般的なIT運用アウトソーシングでは、上記のような水準が設定されることがあります。
応答時間を短くするほど、待機体制やオンコール対応の費用が上乗せされます。「平日日中のみ」と「24時間365日」では必要な人員体制が異なるため、月額費用が数倍変わることもあります。
まず、アプリ停止がビジネスに与える影響を見積もり、本当に必要な対応時間帯を見極めます。24時間対応が要るか、平日日中で足りるかを冷静に検討すると、過剰なコストを避けられます。
対応プラットフォーム数とアプリの複雑さ
対応OSと端末の数、アプリが持つ機能の複雑さで保守工数は変わります。
- 対応OS：iOSのみ、Androidのみ、両OS対応のどれかで工数が変わります。
- 開発方式：クロスプラットフォームは共通コードの保守。
- 追加端末：タブレットやウェアラブルで検証対象が増加。
両OSをネイティブで個別に開発すると、OS更新対応も2系統で発生します。その分だけ、保守コストは増えます。
決済や位置情報の機能、リアルタイム通信、外部システム連携も費用に影響します。これらを多く持つアプリは、それぞれが障害の起点になり得ます。そのため、監視、テスト、対応の工数が増えます。
機能を絞ったシンプルなアプリは保守負荷が小さく、月額費用を抑えやすいです。見積を比べる際は、機能の多さと保守費用が見合っているかを評価します。この観点で見ると、過不足のない契約に近づけます。
見積を取る際に確認すべきポイント
アプリ運用保守の見積は、総額の安さだけで判断すると後悔しかねません。安い見積には、対応範囲が狭い、緊急対応がないなどの条件が隠れていることがあります。OS更新が別料金になっている場合もあるため、条件を確認します。
保守範囲の明文化と「含む・含まない」の確認
見積では、保守に含める作業と含めない作業の線引きを確認します。
- 含む作業：OS更新・ストア・SDK対応の範囲。
- 含まない作業：機能改善などの別途見積範囲。
見積トラブルは、想定した作業が保守に含まれない認識のズレから生まれます。そのため、OS更新対応やストア審査対応、SDK更新、機能改善のそれぞれについて、保守に含まれるのか別途見積になるのかを確かめます。
そのうえで、契約書や見積書に作業範囲を明文化してもらうことが、追加費用トラブルを防ぎます。
この点は、法的な紛争にも発展しうる論点です。保守契約をめぐり、見積工数を超過した報酬をベンダーが請求した裁判があり、東京地裁の平成24年4月25日判決です。
判決では、超過分のうちユーザー側の追加指示に起因する部分だけがユーザー負担と認められました。ベンダーの請求は、一部しか認められませんでした。
当初の保守範囲と追加作業の線引きが曖昧だと、双方が損をします。だからこそ、発注側も契約時に範囲を具体的に詰めておくことが自衛になります。
複数社比較とRFPによる手戻り削減
見積を比べるには、相見積もりとRFPを組み合わせます。
- 複数社比較：最低でも2〜3社の内訳を横並びにすること。
- RFP：要件と前提を各社へ同じ条件で提示すること。
適正価格で発注するには、複数社の見積を並べて、保守費用の相場感をつかむことが欠かせません。
見積の前提や項目の粒度が違うと、単純な比較はできません。
RFP（提案依頼書）には、自社の要件を整理して記載します。保守範囲や求めるSLA、対応時間帯のほか、レポート頻度なども明記します。
各社に同じRFPを提示すれば、同じ土俵で比較できる見積が揃います。
RFPは、見積の比較以外にも効果があります。質問リストやRFPを用意して選定すると、要件の伝達ミスによる作り直しや認識違いを事前に防げるため、発注後の手戻りコストを削減できます。初期の準備工数をかける価値は十分にあります。
アプリ運用保守の進め方は、アプリ運用保守の進め方を解説した記事で詳しく扱っています。
発注や外注の具体的な手順は、アプリ運用保守の発注方法を解説した記事で解説しています。
コストを最適化する考え方
保守費用には、無駄を省く余地があります。ただし、削る場所を誤らないことが大切です。対応範囲、属人化、中長期の内製化という3つの視点から、見直し方を考えます。
対応範囲のメリハリ
社内で担う作業と外注する作業を分け、対応範囲にメリハリをつけることが第一歩です。
- 自社で行う作業：コンテンツ更新やお知らせ配信。
- 外注する作業：OS更新、障害復旧、セキュリティ対応。
専門ベンダーの工数を必要な作業に集中させれば、月額費用を抑えられます。一方で、保守を最低限まで削ると、かえって高くつくことがあります。
OSやSDKの更新を怠ったことで、脆弱性を突かれた事例もあります。サーバーが不正アクセスを受け、Webサイトの内容を改ざんされたケースです。
攻撃後の復旧や信頼回復のコストは、平時の保守費用をはるかに上回ります。だからこそ、削ってよいところと、削ってはいけないところを見極めることが欠かせません。
属人化の解消と内製化による長期コスト削減
保守コストを長期的に押し上げる隠れた要因が、属人化です。
- 属人化の解消：構成図や運用手順書で知識を共有すること。
- 段階的な内製化：外注から軽微な保守を社内へ移すこと。
特定の担当者やベンダーしか仕様や手順を知らないと、保守が不安定になります。担当者が不在になると保守が立ち行かず、引き継ぎや再調査にコストがかかります。
暗黙知の例として、特定の順番で操作しないと動かない手順や、現場判断で値を変える処理があります。どちらもドキュメントには残らない暗黙知です。
こうした暗黙知は、引き継ぎ時の致命的なトラブルの原因になります。そこで発注側は、構成図や運用手順書を整え、ナレッジ共有の仕組みを保守契約に組み込みます。この取り組みが、結果的にコストを下げます。
中長期では、社内にノウハウを蓄えて一部を内製化するロードマップも有効です。最初は外注で品質を担保しながら、ドキュメントを受け取ります。そのうえで、社内エンジニアを育成し、軽微な保守から段階的に内製へ移します。
外注と内製のバランスは、段階を踏みながら見直し続けます。これが、費用と品質を両立させる現実的な道筋です。
費用構造をさらに把握するには、アプリ運用保守でおすすめの開発会社を比較した記事も参考になります。
アプリ運用保守の完全ガイドもあわせて参考にしてください。
まとめ
アプリ運用保守は、開発費の15％／年を起点に、規模別の月額レンジで予算を考えます。小規模は月額3万〜8万円、中規模は10万〜30万円、大規模は数十万円〜数百万円が目安です。
OS更新やストア審査、SDK更新などの固有費用が、継続的に上乗せされます。そのため、これらが見積に含まれるかどうかが、追加費用トラブルを防ぐ分かれ目です。
費用を評価するには、維持費・管理費・運用費の3分類で内訳を読みます。あわせて、SLA水準や対応プラットフォーム数といった費用の変動要因も確認します。
保守範囲を明文化したうえで、複数社をRFPで比べることも大切です。対応範囲にメリハリをつけ、属人化を解消して、中長期では内製化も検討します。そうすれば、品質を保ちながらトータルコストを抑えられます。
本記事の数字と視点を手がかりに、自社アプリに過不足のない保守予算を組み立ててください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。