LASSIC Media らしくメディア
アプリリリース後の保守を外注する方法｜契約形態とSLA設計を解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- リリース後の保守には5種類の対応が必要であり、いずれかの欠落がアプリ停止やストア削除につながります。
- 保守契約は「月額固定」「従量課金」「SLAベース」の3形態に整理でき、自社の稼働要件に合った選択が費用対効果を左右します。
- 開発元への継続委託と別会社への移管はそれぞれ異なるリスクがあり、移管時の引き継ぎ内容の確認が後のトラブルを防ぎます。
目次
リリース後の保守外注とは何か — 5種類の対応範囲
アプリリリース後の保守外注とは、公開済みアプリの品質・セキュリティ品質・動作継続性を維持するために必要な継続的作業を、外部の専門企業に委託する取り組みです。
リリース直後は目に見える不具合対応が中心ですが、時間の経過とともにOSバージョンアップへの追従やストア要件の変更対応など、開発とは異なる種類の作業が継続的に発生します。これらを自社エンジニアだけで対応し続けるのは、工数・専門知識の両面で負担が大きくなります。
保守外注の対象となる作業は大きく5種類に整理できます。
第一にOS追従対応です。iOSやAndroidはほぼ毎年メジャーバージョンがリリースされ、アプリ側もAPIの変更に合わせた修正が求められます。
第二に障害対応です。クラッシュや機能停止を検知し、原因特定から修正・リリースまでを迅速に行います。
第三にセキュリティ更新です。使用しているライブラリの脆弱性パッチを適時適用します。
第四にストア要件変更対応です。App StoreとGoogle Playはポリシーを定期的に更新し、対応しないとアプリが配信停止になるリスクがあります。
第五に軽微な改善です。UI文言の修正や小規模な機能追加など、プロジェクト型の大型開発には至らない継続的な改善作業が含まれます。
OS追従・ストア要件対応を怠るとアプリは停止する
保守対応の中でもOS追従とストア要件対応は、期日が明確に設けられており、対応しないと新規ユーザーへの配信が制限または停止される点で特に重要です。
Google Playは2025年8月31日以降、新規アプリおよびアップデートにAndroid 15（APIレベル35）以上をターゲットにすることを義務付けています*1。これより古いAPIレベルを設定したアプリは、新しいAndroid OSを実行するデバイスの新規ユーザーに表示されなくなります。
Apple App Storeも同様に、2026年4月28日以降にApp Store ConnectへアップロードするアプリはすべてXcode 26以上でビルドし、iOS 26 SDKを使用することが要件とされています*2。年次でSDK要件が更新されるため、毎年対応コストが発生します。
セキュリティ面でも継続的な対応が必要です。IPA（情報処理推進機構）の集計によると、2024年の脆弱性関連情報の届出件数は年間632件（ソフトウェア製品296件・ウェブサイト336件）にのぼり*3、依存ライブラリを更新しなければアプリが既知の攻撃手法にさらされ続けます。
ストア要件対応の遅延は収益や評価に直結するリスクがあります。担当エンジニアの退職や異動などで社内対応が困難になった場合、外注先を確保しておくことがリスクヘッジになります。
保守契約の3形態：月額固定・従量課金・SLAベース
アプリ保守の外注契約は主に3つの形態に分類できます。自社のアプリ規模・稼働重要度・予算計画に合った形態を選ぶことが費用対効果の鍵です。
| 契約形態 | 概要 | 向いているケース | 留意点 |
|---|---|---|---|
| 月額固定型 | 月額一定額で定められた保守スコープを対応する。 | OS追従・ライブラリ更新など定常作業が明確な場合。 予算を平準化したい場合。 |
スコープ外の作業は別途費用が発生する。 作業量が少ない月も固定費がかかる。 |
| 従量課金型 | 対応した工数・チケット数に応じて費用が発生する。 | 軽微な改善・スポット対応が多い場合。 保守頻度が月により変動する場合。 |
作業量が増えると費用が青天井になるリスクがある。 月次費用の予測が難しい。 |
| SLAベース型 | 障害対応時間・可用性目標などのSLA（サービスレベル合意）を定め、未達時にペナルティを設ける。 | 24時間稼働や高可用性が求められる業務アプリ・BtoBアプリ。 | SLA水準が高いほど費用が上がる。 SLAの定義（対応開始時間か復旧完了時間か）の明確化が必要。 |
実務では、月額固定型をベースにSLA条項を追加する「ハイブリッド型」の契約も見られます。定常的な月額固定範囲を明確にしつつ、障害対応の応答目標をSLAで担保する設計です。
いずれの形態でも、契約前にスコープの明文化（何が保守の対象で何が対象外か）を行うことが後のトラブルを防ぐ前提条件です。
SLA設計の実務ポイント — 障害対応時間と可用性目標
SLA（Service Level Agreement）とは、サービスの品質基準と対応義務を発注者と受注者の間で合意した文書です。アプリ保守においてSLAを設ける場合、主に以下の3つの指標を設定します。
まず応答時間（Response Time）です。障害報告を受けてから最初の対応（状況確認・連絡）を開始するまでの時間です。「営業時間内30分以内」「24時間365日対応の場合は1時間以内」のように定めます。
次に復旧目標時間（RTO：Recovery Time Objective）です。障害発生から通常稼働に戻るまでの目標時間です。RTOが短いほど高い体制コストが必要になります。
さらに可用性目標（稼働率）です。年間稼働率として「99.9%」（年間約8.7時間の停止許容）や「99.5%」（年間約43.8時間許容）などで設定します。稼働率が高いほど冗長化・監視コストが増加します。
SLA設計で見落とされやすいのが対象範囲と除外事項の定義です。「計画メンテナンス時間はダウンタイムに含めない」「ストアの審査遅延は対象外」など、受注者側の責任範囲を明確にしておかないと、ペナルティの解釈をめぐるトラブルに発展します。
SLA未達時のペナルティ（サービスクレジットの返還など）の定め方も重要です。ペナルティが厳しすぎると対応可能な外注先が限られ、緩すぎると実効性がなくなります。ペナルティよりも再発防止プロセス（ポストモーテム実施義務など）を組み合わせる設計が実務上は機能しやすいです。
費用相場の考え方 — 開発費の10〜20%目安の根拠と注意点
アプリ保守の外注費用について、「開発費の10〜20%程度を年間保守費用として見込む」という考え方が実務上よく使われます。ただしこれは一次資料に基づく公的統計ではなく、市場における参考値として広く流通している目安です。
この考え方の背景には、保守作業の中心であるOS追従・ライブラリ更新・軽微な修正が、開発当初のコードベース規模に比例して工数が変動するという実務的な経験則があります。アプリの機能が複雑で依存ライブラリが多いほど、年間の保守工数も増加する傾向があります。
費用に影響する主な変数は以下の通りです。
- 対応プラットフォーム数：iOS単独かAndroid併用か（クロスプラットフォームか）
- 監視体制：営業時間内対応か24時間365日か
- SLA水準：応答時間・可用性目標の設定値
- 使用ライブラリの数と更新頻度
- バックエンドの保守が含まれるか（アプリ単体かサーバーも含むか）
OS追従対応は単に「ビルドして動作確認する」だけでなく、APIの変更内容を把握し、実装を修正し、テストを実施してストアにサブミットするまで一連の作業が必要です。iOSとAndroidの両プラットフォームに対応する場合は工数がほぼ2倍になります。
実際の見積もりを取る際は、「保守範囲の明細（スコープ表）」と「SLA水準」を具体的に提示した上で複数社から見積もりを取ることが費用妥当性を判断する上で大切です。
開発元継続委託 vs 別会社移管 — 選定の判断軸
保守外注先の選択肢は大きく「開発元（既存のベンダー）に継続委託する」と「別の保守専門会社に移管する」の2パターンに分かれます。どちらが適切かは一概には言えず、現状のベンダー関係・ソースコードの権利・保守品質への評価によって異なります。
| 観点 | 開発元への継続委託 | 別会社への移管 |
|---|---|---|
| コード理解 | アーキテクチャや設計意図を熟知しており立ち上がりコストが低い。 | コード読解・引き継ぎに初期工数が必要。 引き継ぎドキュメントの質が重要。 |
| 交渉力 | 依存度が高くなりやすく、費用値上げや対応優先度で交渉力が弱まる可能性がある。 | 競争原理が働き、費用・品質の両面で選択肢を持てる。 |
| 移行リスク | 低い。 | 引き継ぎの失敗により障害対応が遅延するリスクがある。 ソースコードの権利関係を事前に整理する必要がある。 |
| 向いている状況 | 開発元との関係が良好で保守品質に満足している場合。 | 保守費用が市場相場より高い場合、または保守品質に課題がある場合。 |
開発元への継続委託には「知識継続性」というメリットがある一方、いわゆるベンダーロックイン（特定ベンダーへの過度な依存）のリスクも生じます。特にソースコードが開発会社に帰属する契約になっている場合、移管が実質不可能になるケースがあります。
別会社への移管を検討する際は、現在の開発元がソースコードとドキュメントを適切に引き渡せる状態にあるかの確認が最初の論点です。移管先の選定では、同一技術スタック（使用言語・フレームワーク）での実績と、移管時の引き継ぎ支援サービスの有無を確認することが大切です。
移管時の引き継ぎで確認すべき5つの成果物
保守の委託先を変更（移管）する際に引き継ぎが不十分だと、新しい保守会社が障害発生時に迅速に対応できず、復旧に長時間かかるリスクがあります。移管前に以下の5つの成果物の整備状況を確認することが実務上の重要な事前確認です。
①ソースコードリポジトリ：Gitなどのバージョン管理システムで管理されたコードと、全コミット履歴の一式です。受注者側に権利がある場合は契約上の権利移転が必要です。
②システム設計書・アーキテクチャドキュメント：アプリの設計思想・画面設計・データフロー・外部API連携先の一覧です。これが欠けると新しい保守担当者がコードを理解するのに多大な時間を要します。
③環境構築手順書（開発・ステージング・本番）：ビルド手順・環境変数の設定値・デプロイフローを文書化したものです。特にCI/CD（継続的インテグレーション・デリバリー）パイプラインの設定が含まれているかを確認します。
④テスト仕様書・テストコード：既知の動作仕様と、それを検証するテストケースです。テストコードが整備されていると、OS追従後の動作確認を効率化できます。
⑤アカウント・認証情報リスト：App Store Connect・Google Play Console・Firebase・外部API等のアカウント情報の一覧と権限移転です。これが未整理のまま移管すると、ストアへのサブミット自体ができなくなります。
移管作業には相応の工数がかかります。開発元が引き継ぎに協力的でない場合、移管コストが想定を大きく上回ることがあります。保守委託先変更を視野に入れる段階で、現開発元との契約書に引き継ぎ義務が明記されているかを確認しておくことが大切です。
まとめ：保守外注を成功させる3つの判断軸
本稿ではアプリリリース後の継続保守外注について、保守の5種類の対応範囲・契約形態・SLA設計・費用の考え方・外注先選定・移管時の引き継ぎを整理しました。要点を3つに集約すると次の通りです。
第一に、OS追従とストア要件対応は対応期日が存在する義務的な保守です。Google Playは2025年8月31日以降にAPI 35への対応を求め*1、Apple App Storeも年次でSDK要件を更新します*2。これらの対応を計画に組み込んだ保守契約が必要です。
第二に、契約形態は月額固定・従量課金・SLAベースの3形態があり、アプリの稼働重要度と予算計画に合わせて選択します。24時間稼働が求められる業務アプリにはSLA条項の追加が重要です。SLAの定義は「対応開始」か「復旧完了」かを明確にしないと後でトラブルになります。
第三に、移管時の引き継ぎ5成果物（ソースコード・設計書・環境構築手順・テスト・アカウント情報）の整備状態が移管成否を左右します。現開発元との契約に引き継ぎ義務を明記しておくことが移管リスクを下げます。
よくある質問
アプリ保守を外注する際、最低限必要な契約期間はどのくらいですか？
一般的には6か月〜1年単位の契約が多く見られます。OS追従対応はiOS・Androidともに年1回のメジャーリリースへの対応が必要なため、少なくとも12か月単位で契約するとOS更新サイクルを安定してカバーできます。短期契約は担当チームの引き継ぎコストが割高になるため、中期以上での設計が実務上は合理的です。
SLAの「応答時間」と「復旧時間」はどう使い分ければよいですか？
「応答時間（Response Time）」は障害報告を受けてから調査・連絡を開始するまでの目標時間で、「復旧時間（RTO）」は障害が解消されるまでの目標時間です。応答時間は比較的短く設定しやすい一方、復旧時間は原因の深刻さによって大きく変動します。SLA契約ではこの2指標を分けて定めることで、対応状況の評価が明確になります。
開発元以外の会社にアプリ保守を移管する際の注意点は何ですか？
最初に確認すべきはソースコードの権利帰属です。契約上、コードが開発会社に帰属している場合は権利移転の交渉が必要になります。また、設計書・環境構築手順・テスト仕様・アカウント情報の5成果物が引き渡し可能な状態かを移管前に確認することが大切です。引き継ぎが不十分だと、移管直後の障害対応に遅延が生じるリスクがあります。
iOSとAndroidの両方を保守外注する場合、費用はどう変わりますか？
OS追従対応の工数はプラットフォームごとに発生するため、iOS単独と比べてiOS＋Android対応では保守工数が増加します。特にクロスプラットフォームフレームワーク（React NativeやFlutterなど）の場合は、フレームワーク側の対応状況にも依存するため、単純に2倍とはなりませんが、依存ライブラリの管理コストが加わります。見積もり時にプラットフォームごとの内訳を明示してもらうことで費用の妥当性を確認しやすくなります。
保守外注の範囲として「軽微な改善」はどこまで含めるのが適切ですか？
「軽微な改善」の範囲はスコープ合意が最も曖昧になりやすい領域です。一般的には「1チケットあたりの対応工数が〇時間以内」「テキスト変更・レイアウト微調整・既存機能の表示条件変更」などを軽微と定義し、それを超える作業は別途見積もりとする設計がトラブルを防ぎます。月額固定型の保守契約では、このスコープ境界を契約書の別紙（スコープ表）として明記しておくことが大切です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Google「Google Play のターゲット API レベルの要件」（2025年）
- *2 出典：Apple「Upcoming Requirements for App Store Submissions」（2026年）
- *3 出典：IPA（情報処理推進機構）「ソフトウェア等の脆弱性関連情報に関する届出状況（2024年第4四半期）」（2025年）
