スマホアプリは、公開した時点で完成するものではありません。iOSとAndroidは定期的に大きな更新を行い、そのたびにアプリの動作確認や修正が必要になります。アプリストアの規約や審査の基準も見直され、開発に使っているツールや部品も更新され続けます。何もせずに放置したアプリは、いずれ新しい端末で正しく動かなくなったり、ストアで更新を受け付けてもらえなくなったりします。つまり、アプリの保守は「何か起きたら直す」ものではなく、「動き続けるために毎年必要になる」ものです。
この記事は、すでにアプリを運用している事業者や、これからアプリを開発するにあたって保守費用を見込みたい事業責任者・企画担当者に向けて書いています。アプリの保守で何が発生するのか、OSアップデート対応の中身、保守費用の構成と見込み方、保守契約で決めるべきこと、費用を抑える工夫を順に説明します。
結論を先に言えば、アプリの保守費用は「OSと規約の変化への追従」「不具合の修正と問い合わせ対応」「外部サービスと部品の更新」「インフラの運用」の四つで構成されます。これらを開発の段階から計画に入れ、作り方の工夫で保守の手間を減らしておくことが、長く使えるアプリにするための最も確実な方法です。
アプリに保守が欠かせない理由
Webサイトや社内システムにも保守は必要ですが、スマホアプリには特有の事情があります。
OSの更新が利用者側で進む
社内システムであれば、サーバーの環境を自社で管理し、更新のタイミングもある程度選べます。しかしスマホアプリは、利用者の端末の上で動くため、利用者がOSを更新すれば、アプリはその新しい環境で動かなければなりません。利用者に「OSを更新しないでください」とお願いすることはできないのです。
ストアの規約と要件が変わる
アプリストアは、セキュリティやプライバシーの強化のために、規約や技術的な要件を定期的に見直しています。一定の時期以降は、新しい開発環境で作られたアプリでなければ更新を受け付けない、といった要件が設けられることもあります。これに対応しないと、不具合の修正すら公開できなくなるおそれがあります。
部品と外部サービスが変わる
アプリは、ログイン、通知、決済、分析などの機能を、外部の部品やサービスを組み合わせて作ることが多くなっています。これらの部品やサービスも更新され、古い版の提供が終わったり、仕様が変わったりします。
端末の種類が増え続ける
新しい端末が発売されるたびに、画面の大きさや形、性能が変わります。新しい端末で表示が崩れていないか、操作に問題がないかを確認する必要があります。
OSアップデート対応で発生する作業
OSの大きな更新は、多くの場合年に一度程度行われ、その間にも小さな更新が繰り返されます。大きな更新に対応する際の作業は、おおむね次の流れになります。
- 事前の情報収集：OSの提供元が公開する新しいOSの情報や、開発者向けの試験版をもとに、変更点とアプリへの影響を確認します。
- 試験版での動作確認：新しいOSの試験版を入れた端末で、アプリの主要な操作を確認します。
- 影響のある箇所の修正：表示の崩れ、動かなくなった機能、許可の求め方の変更などに対応します。
- 開発環境と部品の更新：開発ツール、クロスプラットフォームの技術、各種の部品を、新しいOSに対応した版に更新します。
- 回帰テスト：修正によって他の機能に影響が出ていないかを確認します。
- ストアへの申請と公開：修正した版を申請し、審査を経て公開します。
- 公開後の監視：新しいOSでの不具合の報告や、異常終了の発生状況を確認します。
すべての更新で大きな修正が必要になるわけではありません。影響がほとんどない年もあれば、許可の仕組みやバックグラウンドの動作の変更によって、まとまった修正が必要になる年もあります。そのため、保守の計画では、毎年一定の確認作業を見込みつつ、大きな修正が必要になる年に備えた余裕を持たせておくことが大切です。
大きな更新の合間に行われる小さな更新でも、セキュリティの修正に伴って特定の機能の動きが変わることがあります。利用者からの問い合わせや、異常終了の発生状況を日ごろから監視しておけば、小さな更新による影響にも早く気づけます。異常終了の状況を集める仕組みは、開発の段階で組み込んでおくと、保守の質が大きく変わります。
保守費用の構成
アプリの保守費用は、次の四つに分けて考えると整理しやすくなります。
| 分類 | 主な内容 | 発生の仕方 |
|---|---|---|
| OS・規約への追従 | OS更新の確認と修正、ストアの要件への対応、開発環境の更新 | 定期的に発生、年によって大小がある |
| 不具合修正・問い合わせ対応 | 不具合の調査と修正、利用者からの問い合わせへの技術的な回答 | 不定期に発生 |
| 部品・外部サービスの更新 | 部品の版の更新、外部サービスの仕様変更への対応 | 定期的・不定期の両方 |
| インフラの運用 | サーバー、データベース、通知の配信基盤などの監視と運用 | 継続的に発生 |
これに加えて、機能の追加や改善を行う場合は、保守とは別の「改修」として費用がかかります。保守費用と改修費用を混ぜて考えると、毎月の費用が何に使われているのかが分からなくなるため、分けて管理することをおすすめします。
また、開発会社への保守費用とは別に、ストアの開発者アカウントの費用、クラウドの利用料、外部サービスの利用料など、アプリを動かし続けるための費用もかかります。費用の全体像を把握するときは、これらも含めて見込んでおきましょう。
保守費用の見込み方
具体的な金額はアプリの規模や作り方によって大きく変わるため、ここでは見込み方の考え方を説明します。
工数で考える
保守費用も、開発費用と同じく「作業量 × 単価」で考えるのが基本です。年間でどのくらいの作業が発生するかを、次のように分けて見積もります。
- OS更新への対応：両OSの大きな更新ごとに、確認と修正にかかる作業量
- 部品の更新：使っている部品の数と、更新の頻度
- 不具合修正：過去の実績や、アプリの複雑さから見込む作業量
- 待機と監視：問い合わせに対応できる体制を維持するための作業量
作り方による違い
保守の作業量は、アプリの作り方によって大きく変わります。
- 対応するOSの数と作り方：両OSをネイティブで別々に作っている場合、OS更新への対応も二系統分必要です。クロスプラットフォームであれば共通部分は一度で済みますが、技術そのものの更新への対応が加わります。詳しくは ネイティブとクロスプラットフォームの選び方 を参照してください。
- 端末機能への依存度：カメラ、位置情報、バックグラウンド動作、外部機器との通信などを深く使うほど、OS更新の影響を受けやすくなります。
- 部品の数：外部の部品を多く使うほど、更新の手間と、部品の提供終了のリスクが増えます。
- テストの自動化：主要な操作を自動で確認する仕組みがあれば、OS更新のたびの確認作業を減らせます。
開発時の見積もりと一緒に確認する
保守費用は、開発の見積もりを取る段階で、あわせて目安を確認しておくべきです。開発費用だけで開発会社を選ぶと、保守の段階で想定以上の費用がかかることがあります。数年間の総額で比較すると、判断を誤りにくくなります。費用の全体像は スマホアプリ開発の費用は何で決まるか でも整理しています。
保守契約で決めておくべきこと
アプリの保守を外部に依頼する場合、契約の内容を明確にしておかないと、「それは保守の範囲外です」という行き違いが起きます。次の項目を確認しておきましょう。
- 対応の範囲：OS更新への対応、ストアの要件への対応、部品の更新、不具合の修正のどこまでが含まれるか
- 対応の時間と速さ：問い合わせの受付時間、重大な不具合のときの対応開始までの目安
- 作業量の上限：月ごとの作業時間の上限と、超えた場合の扱い
- OS更新の対応方針：新しいOSの試験版の段階から確認するのか、正式版の公開後に対応するのか
- 対応するOSと端末の範囲：どの版以降のOSを対象にするか、古いOSへの対応をいつ終えるか
- 申請作業：ストアへの申請と、審査で指摘を受けたときの対応が含まれるか
- 報告の方法：毎月どのような作業を行ったかを、どのような形で報告するか
なかでも「OS更新の対応方針」は、保守の質を大きく左右します。正式版の公開後に対応を始める方針だと、利用者がOSを更新してから修正版を公開するまでの間、不具合が出たままになる可能性があります。試験版の段階から確認を始める方針にすれば、正式版の公開と同時か、その直後に修正版を出せる見込みが高まります。その分の作業量は増えるため、アプリの重要度と照らして方針を決めましょう。
保守契約全般の考え方は システム保守契約に含めるべき内容 で詳しく説明しています。
古いOSへの対応をいつ終えるか
保守の手間を左右する見落としやすい論点が、古いOSへの対応をいつ終えるかです。対応するOSの版が広いほど、確認の手間が増え、新しい機能を使いにくくなります。一方で、対応を早く終えすぎると、古い端末を使っている利用者がアプリを使えなくなります。
判断の際には、次の点を考慮します。
- 利用者の端末とOSの分布（アプリの分析ツールで確認できる）
- OSの提供元によるセキュリティ更新の提供状況
- 使っている部品や技術が対応するOSの範囲
- 古いOSに対応し続けるための作業量
対応を終える場合は、事前にアプリ内のお知らせなどで利用者に告知し、移行の期間を設けるのが望ましい進め方です。業務用のアプリで会社が端末を支給している場合は、端末の入れ替えの計画とあわせて検討しましょう。
アプリを続けるかどうかを見直す
保守の負担が重くなってきたときは、アプリそのものを続けるべきかを見直す機会でもあります。利用者の多くがWebでも同じことをしている、通知以外にアプリならではの機能がほとんど使われていない、といった状況であれば、アプリを終了してWebやメッセージングサービスに集約するという選択肢もあります。反対に、アプリの利用が事業の中心になっているなら、保守を「費用」ではなく「事業を支える投資」として位置づけ、計画的に予算を確保するべきです。
いずれの場合も、判断の材料になるのは利用状況のデータです。機能ごとの利用頻度、OSと端末の分布、問い合わせの内容を定期的に確認しておけば、保守の範囲を決めるときにも、アプリの今後を考えるときにも役立ちます。
保守費用を抑えるための工夫
保守費用を抑えるには、開発の段階からの工夫と、運用の段階での工夫の両方が有効です。
開発の段階での工夫
- 機能を目的に必要なものに絞る：使われない機能も、OS更新のたびに確認と修正の対象になります。機能が少ないほど保守は軽くなります。
- 部品の選び方に気をつける：利用が広がっていて、更新が続いている部品を選び、依存する部品の数を必要最小限にします。
- 画面の表示をサーバー側で調整できるようにする：お知らせや一部の表示内容をサーバー側から変更できるようにしておけば、小さな変更のたびにアプリを更新・申請する必要がなくなります。
- 主要な操作のテストを自動化する：OS更新や部品の更新のたびの確認作業を減らせます。
運用の段階での工夫
- 更新をため込まない：部品やOSへの対応を何年も先送りすると、一度にまとめて対応する作業が膨らみます。小さく、定期的に更新する方が、結果的に負担は小さくなります。部品の更新方針の立て方は ライブラリ更新の方針 で扱っています。
- 利用状況を見て機能を整理する：ほとんど使われていない機能は、廃止することで保守の対象を減らせます。
- 保守の作業内容を定期的に見直す：毎月の報告を確認し、作業量と費用が見合っているかを点検します。作業内容が毎月ほとんど変わらないのに費用だけが続いている場合は、範囲や体制を見直す余地があります。
具体例：小売チェーンの会員アプリの保守計画
架空の一般例として、数年前に会員アプリを公開した小売チェーンを考えます。公開後、保守契約は「不具合があれば対応する」という簡単な内容で、OS更新への対応は都度見積もりでした。
ある年、新しいOSの公開後に、会員証の表示が一部の端末で崩れるという問い合わせが店舗に相次ぎました。調べてみると、開発環境や部品の更新も長く行われておらず、修正するにはまず開発環境を新しくする必要がありました。結果として、通常の修正よりも大きな作業が必要になり、修正版の公開までに時間がかかりました。
この経験から、このチェーンは保守の方針を見直しました。新しいOSの試験版が出た段階で動作を確認すること、部品の更新を定期的に行うこと、対応するOSの範囲を毎年見直すことを保守契約に明記し、毎月の作業報告を受けるようにしました。また、利用が少なかった機能をいくつか廃止し、保守の対象を減らしました。毎年の保守費用は以前より見通しやすくなり、急な対応で慌てることも減りました。
保守計画のチェックリスト
- 保守費用を、OS・規約への追従、不具合対応、部品の更新、インフラの運用に分けて見込んだか
- 保守と改修（機能追加）の費用を分けて管理しているか
- ストアのアカウント費用や外部サービスの利用料も含めて把握しているか
- 新しいOSの試験版の段階で確認する体制があるか
- 使っている部品の一覧と、それぞれの更新状況を把握しているか
- 対応するOSの範囲と、古いOSへの対応を終える基準を決めたか
- 保守契約で、対応の範囲・時間・作業量の上限・申請作業を明確にしたか
- 毎月の作業報告を受け、内容を確認しているか
- 使われていない機能を定期的に見直しているか
よくある失敗とその避け方
失敗1：保守費用を予算に入れていない 開発費だけを予算化し、保守費用を見込んでいないと、OS更新への対応が必要になったときに予算が確保できません。開発の判断と同時に、数年分の保守費用を見込んでおきましょう。
失敗2：更新を先送りし続ける 「今は動いているから」と部品や開発環境の更新を先送りすると、ある時点で一気に大きな作業が必要になります。小さな更新を定期的に行う方が、結果的に費用もリスクも小さくなります。
失敗3：保守の範囲があいまい 保守契約の範囲があいまいだと、OS更新への対応が保守に含まれるのか、別料金なのかで揉めることがあります。契約の段階で具体的に確認しておきましょう。
失敗4：作った会社以外では保守できない状態になっている ソースコードや設計資料、ストアのアカウントの情報が開発会社の手元にしかないと、保守の会社を変えたくても変えられません。納品物と権利を契約の段階で確認しておきましょう。
よくある質問
Q. 保守契約を結ばずに、必要なときだけ依頼することはできますか？
可能ですが、必要になったときに開発会社がすぐに対応できるとは限りません。また、OS更新への備えなど、定期的な確認が行われないため、問題が起きてからの対応になりがちです。利用者が多いアプリや、事業の中心になっているアプリでは、継続的な保守契約を結ぶことをおすすめします。
Q. 保守会社を変えることはできますか？
ソースコード、設計資料、ストアのアカウントや外部サービスの管理情報がそろっていれば可能です。引き継ぎの期間を設け、現在の保守会社から必要な情報を受け取る計画を立てましょう。手順は 保守会社を乗り換える手順 で詳しく説明しています。
Q. 審査の基準の変更にはどう備えればよいですか？
ストアの規約の変更情報を定期的に確認し、影響がある場合は早めに対応を計画することが基本です。保守契約の中に、規約の変更の確認と対応を含めておくと安心です。審査で指摘されやすい論点は アプリストア審査で落ちる原因 で整理しています。
Otsumuに相談できること
機能が少なく、利用者も限られていて、開発会社との保守契約の内容が明確になっているのであれば、この記事のチェックリストで保守の状況を点検し、毎月の報告を確認していくだけで十分なことも多いでしょう。社内に技術の分かる担当者がいれば、部品やOSへの対応状況を自社で把握することもできます。
一方で、保守の範囲や費用が適切か判断できない、更新が長く行われていない、保守会社とのやり取りがうまくいっていない、保守の手間を減らすために作り方から見直したい、といった状況では、現状の把握と計画の立て直しに外部の視点が役立ちます。
Otsumuでは、既存のアプリの状況を確認したうえで、保守計画の整理、更新の遅れの解消、保守しやすい作りへの改善まで支援しています。構想から開発、運用、改善まで一気通貫で関わるため、保守だけでなく、利用状況に合わせた機能の見直しもあわせて検討できます。詳しくは システム保守・運用 と スマホアプリ開発 のページをご覧ください。
いまの保守の状況を一度見てほしい、という相談も歓迎しています。30分の無料相談 でお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01