アプリをリリースした後、「運用保守をどこかに発注したいが、何をどう依頼すればよいのか分からない」と悩む企業は少なくありません。アプリの運用保守は、iOS・AndroidのOS更新への追従、ストア審査への対応、クラッシュ監視、緊急アップデートのリリースなど、Webシステムにはない固有の論点が多く、発注時の取り決めが曖昧だと「OS更新は契約に含まれていなかった」「ストア審査のリジェクト対応で想定外の追加費用が発生した」といったトラブルにつながります。
本記事では、アプリ運用保守を外注・委託する際の具体的な発注方法を、保守範囲の明文化・SLA（サービス品質保証）の設定・リリース権限の引き継ぎという3つの観点から解説します。実在の裁判例やSLAの数値基準、属人化による引き継ぎ失敗の実例も交えながら、発注前に準備すべきドキュメントから契約締結時のチェックリストまで、依頼先選定で後悔しないための判断材料をまとめました。アプリの安定運用を外部パートナーに任せたい担当者の方は、ぜひ最後までご覧ください。
アプリ運用保守を発注・外注する前に押さえる全体像
アプリ運用保守の発注を成功させるには、まず「運用」と「保守」が指す業務の違いを理解し、自社が外注したい範囲を明確にすることが出発点になります。漠然と「保守をお願いしたい」と依頼してしまうと、依頼先との認識がずれ、後から追加費用や対応遅延の火種になります。ここでは発注前に整理すべき基礎知識を解説します。
「運用」と「保守」で外注範囲が変わる
アプリ運用保守の発注で最初につまずきやすいのが、「運用」と「保守」を一括りに考えてしまう点です。運用とは、サーバーやアプリの稼働監視、バックアップ取得、ユーザー問い合わせへの一次対応といった、日常的に発生するオペレーション業務を指します。一方の保守とは、障害発生時の復旧、OSアップデートへの追従、セキュリティパッチの適用、不具合の修正といった、システムを正常な状態に保つための技術的な対応を指します。
この2つは性質が異なるため、外注時の契約範囲も変わります。たとえば「運用だけを外注し、機能改修を伴う保守は自社や開発元に依頼する」という切り分け方もあれば、「運用も保守も一括で委託する」という選び方もあります。アプリの場合、OS更新やストア審査対応といった保守領域の専門性が高いため、どこまでを依頼先に任せるかを発注前に決めておくことが、見積もりの精度と費用の妥当性を左右します。
アプリ固有の保守論点を発注書に盛り込む
アプリ運用保守がWebシステムの保守と決定的に異なるのは、AppleとGoogleという外部プラットフォームの都合に常に追従しなければならない点です。iOSやAndroidは毎年メジャーアップデートを行い、古いAPIが非推奨になったり、新しいプライバシー要件が課されたりします。これに追従しなければ、ある日突然アプリが起動しなくなったり、ストアから審査を通せなくなったりするリスクがあります。
そのため発注時には、「OSのメジャーアップデート対応は保守範囲に含むか」「App Store・Google Playの審査ガイドライン変更への対応は誰が行うか」「審査でリジェクト（却下）された際の再申請対応は契約内か」といったアプリ固有の項目を、発注書や仕様書に明記する必要があります。これらを曖昧にしたまま発注すると、いざOS更新の時期に「それは別途見積もりです」と言われ、対応が後手に回る事態を招きます。
発注の第一歩：保守範囲を明文化する
アプリ運用保守を外注する際に最も多いトラブルが、「保守込みのはずだった作業に追加費用を請求された」という認識のずれです。これを防ぐ唯一の方法は、保守範囲を契約前に文書で明確に定義することにあります。どこまでが月額保守費の範囲内で、どこからが別途見積もりになるのか、その境界線を発注側が主導して引いておく必要があります。
OS更新・ストア対応を含むかを線引きする
アプリ保守で特に境界が曖昧になりやすいのが、OSアップデート対応とストア審査対応です。たとえば「軽微な不具合修正は保守範囲内」と定めても、新OSへの対応はAPIの大幅な書き換えを伴うことがあり、これを軽微な修正と捉えるか、別途の改修案件と捉えるかで費用が大きく変わります。発注書には「年1回のメジャーOSアップデート対応までを月額保守に含む」「SDKやライブラリのバージョン更新は四半期ごとに実施」など、頻度と範囲を数値で明記すると認識のずれを防げます。
この境界の重要性を示すのが、保守契約をめぐる東京地裁の判決（平成24年4月25日）です。この裁判ではベンダーが見積もり工数を超過した分の報酬を請求しましたが、裁判所は「超過の原因がユーザー側の追加指示に起因する場合のみ」ユーザー負担とし、請求の一部しか認めませんでした。つまり、作業範囲や追加対応の条件を契約時に明確にしていなければ、追加費用の請求自体が認められないこともあるということです。発注側にとっても受注側にとっても、範囲の明文化は紛争を避ける防波堤になります。
「対象外」と「別途見積もり」を区別する
保守範囲を文書化する際は、「保守に含む作業」だけでなく「保守の対象外とする作業」も同時に列挙することが大切です。たとえば新機能の追加開発、デザインの大幅変更、他システムとの新規連携などは、通常の保守とは別の開発案件として扱うのが一般的です。これらを「対象外」と明記したうえで、必要になった場合は別途見積もりで対応するという流れを契約に盛り込んでおきます。
発注時に役立つ整理の切り口は次の通りです。
・月額保守に含む作業（障害復旧、稼働監視、軽微な不具合修正、定例のOS追従）
・別途見積もりとなる作業（新機能追加、大規模リニューアル、新規外部連携）
・緊急対応の扱い（深夜・休日の障害対応の有無と追加料金の有無）
この3つの線引きを発注書に明記しておくことで、月々の保守費の妥当性が判断しやすくなり、依頼先との信頼関係も構築しやすくなります。
SLAを設定して障害対応の品質を担保する
保守範囲を決めたら、次に重要になるのがSLA（Service Level Agreement／サービス品質保証）の設定です。SLAとは、障害発生時にどれだけの速さで対応するか、どの程度の稼働率を保証するかといった品質水準を、数値で取り決める合意のことです。アプリは障害が起きるとストアのレビューに直接低評価が書き込まれ、ダウンロード数や売上に即座に響くため、対応スピードの明文化は発注時の必須項目になります。
応答時間と復旧時間を数値で合意する
SLAで定める代表的な指標は、障害受付から一次対応までの応答時間、障害の復旧目標時間、そしてシステムの稼働率です。IT運用アウトソーシングにおける一般的な目安としては、重大な障害で「初回応答15分以内・解決4時間以内」、通常レベルの障害で「応答2時間以内・解決8時間以内」といった水準が用いられます。この基準を発注時に提示し、依頼先が現実的に対応できるかを確認しておくと、契約後の期待値のずれを防げます。
稼働率の水準も重要です。たとえば三重県の防災アプリでは、システム停止は年1回以内・累計停止時間1時間以内、年間稼働率「99.99%以上」という厳格な基準が設けられた事例があります。ここまで高い水準は一般的なアプリには過剰なこともありますが、自社アプリが止まったときの事業インパクトに応じて、目指すべき稼働率を発注前に決めておくことが、適切なSLAと費用の落としどころを見つける鍵になります。
準委任契約と請負契約の使い分け
アプリ運用保守を外注する際の契約形態は、業務の遂行そのものを目的とする「準委任契約」が一般的です。保守運用は「成果物を完成させる」というより「定められた品質で業務を継続的に提供する」性質が強いため、特定の完成物の納品を約束する「請負契約」よりも準委任が適しています。準委任では、SLAで定めた応答・復旧の水準を満たすことが品質の基準になります。
ただし、バグ修正や機能改修が保守に含まれる場合は注意が必要です。改修作業は成果物を伴うため、その部分だけ請負として切り出すか、準委任の範囲内で扱うかを契約時に明確にしておかないと、責任の所在が曖昧になります。発注側としては、「日常の運用保守は準委任」「一定規模以上の改修は別途請負」というように、作業の性質に応じて契約形態を使い分ける視点を持っておくと安心です。
リリース権限とアカウントの引き継ぎを設計する
アプリ運用保守の外注で見落とされがちなのが、ストアへのリリース権限とアカウントの管理です。アプリはApp Store ConnectやGoogle Play Consoleを通じてしか公開・更新できないため、これらのアカウントを誰が保有し、誰がリリース操作を行うのかを発注時に設計しておかないと、依頼先を変更したくても変更できない、いわゆるロックインの状態に陥ります。
ストアアカウントは自社名義で保有する
外注する際の鉄則は、App Store ConnectとGoogle Playの開発者アカウントを自社名義で取得・保有することです。ベンダー名義のアカウントでアプリを公開してしまうと、契約終了時にアプリそのものの権利や公開状態が依頼先に握られ、移行が極めて困難になります。自社でアカウントを保有し、依頼先には作業に必要な権限だけを付与する形にしておけば、依頼先を変更してもアプリの公開を継続できます。
同様に、署名証明書やキーストア（アプリの正当性を証明する鍵）、各種APIキー、ソースコードのリポジトリといった重要資産も、自社管理を原則とすべきです。これらを依頼先だけが握っている状態は、特定担当者しか仕様を知らない属人化と同じ構造のリスクを生みます。発注時の契約条項に「ストアアカウント・署名鍵・ソースコードは発注者に帰属する」と明記しておくことが、将来の自由度を守ります。
属人化を避ける引き継ぎドキュメントを求める
保守を外注すると、依頼先の特定エンジニアだけがアプリの内部仕様やリリース手順を把握する属人化が起こりがちです。この状態は、担当者の退職や引き抜き、依頼先の変更時に深刻なトラブルを招きます。実際、システム保守の現場では「特定の順番で再起動しないと立ち上がらない」「月初だけ特別な処理を実行する必要がある」といった、ドキュメントに残らない暗黙知が引き継ぎ時の致命的な障害になった例が報告されています。
これを防ぐには、発注時の契約に「保守作業の手順書・構成図・リリース手順の文書化と定期更新」を義務として盛り込むことが有効です。アプリの場合、ビルド環境の構成、リリースフロー、証明書の更新手順、外部サービスの連携設定など、引き継ぎに必要な情報を網羅したドキュメントを依頼先に整備してもらいます。月次レポートで作業内容を可視化してもらう仕組みも、属人化の抑止に役立ちます。
発注前に準備すべきドキュメントと依頼先の選び方
発注の成否は、依頼前の準備で大きく決まります。何をどこまで保守してほしいのかを整理したドキュメントを用意してから複数社に見積もりを依頼すれば、各社の提案を同じ土俵で比較でき、価格と品質の妥当性を見極めやすくなります。ここでは準備すべき資料と、依頼先選定の基準を解説します。
RFPと現状資料を整えて手戻りを防ぐ
発注前に準備したいのが、RFP（提案依頼書）と現状のアプリに関する資料です。RFPには、保守を依頼したい範囲、求めるSLA水準、対応してほしい体制（24時間か平日日中か）、契約形態の希望などを盛り込みます。あわせて、アプリの技術構成（使用言語・フレームワーク・外部サービス）、現在のクラッシュ率やユーザー数、過去の障害履歴といった現状資料を共有すると、依頼先が正確な見積もりを出せます。
的確なRFPと質問リストを用意してベンダーを選定すると、開発後の手戻りコストを約40%削減できるという見方もあります。曖昧なまま「とりあえず保守をお願いしたい」と依頼すると、認識のずれから見積もりの精度が下がり、契約後に追加費用や対応漏れが多発します。準備に手間をかけることが、結果的に総コストを下げる近道になります。
価格だけで選ばず実績と提案力で見極める
依頼先を選ぶ際、最も避けたいのが価格の安さだけで判断することです。安さを優先して選んだ結果、いざ障害が起きたときに復旧が大幅に遅れ、その間の機会損失が保守費の差額をはるかに上回るケースは珍しくありません。確認すべきは、モバイルアプリの保守実績、OS更新やストア審査への対応経験、24時間365日の障害対応体制の有無、そして単なる作業代行ではなくビジネス視点での改善提案ができるかどうかです。
もう一つ重視したいのが、契約終了時の引き継ぎ支援への姿勢です。発注前の段階で「将来ベンダーを変更する場合、データやソースコード、ストアアカウントの引き継ぎにどう協力してくれるか」を確認しておくと、健全な力関係を保てます。実績を確認する際は、自社アプリと近いジャンル・規模の対応経験があるか、過去の障害対応のスピード感はどうだったかを具体的に質問し、提案の中身で各社を比較することが重要です。
アプリ運用保守の費用相場や、進め方の全体像、依頼先の比較については、以下の関連記事もあわせてご覧ください。
・アプリ運用保守の進め方を解説した記事
・アプリ運用保守の費用相場を解説した記事
・アプリ運用保守のおすすめ会社を比較した記事
・アプリ運用保守の完全ガイド
契約締結前のチェックリストとトラブル回避
依頼先が決まったら、契約締結の前に条件を最終確認します。ここで詰めが甘いと、後から「言った・言わない」のトラブルや、依頼先変更時の引き継ぎ拒否といった問題が起こります。発注側が主導してチェックリストを用意し、抜け漏れなく合意することが、長期的に安定した保守関係を築く土台になります。
契約前に確認すべき必須項目
契約締結前に確認すべき主な項目は次の通りです。
・保守範囲（含む作業／対象外の作業／別途見積もりの作業）の明文化
・SLA（応答時間・復旧時間・稼働率）とその未達時の扱い
・OS更新・ストア審査対応の範囲と頻度
・ストアアカウント・署名鍵・ソースコードの帰属
・途中解約のルールと違約金の有無
・契約終了時のデータ引き渡し・引き継ぎ支援の義務
・障害時の責任範囲と免責の条件
これらを一つずつ確認し、口頭ではなく契約書や仕様書に文書として残すことが、トラブル回避の基本になります。
特に、契約終了時のデータ引き渡しと引き継ぎ支援は、契約時にこそ取り決めておくべき項目です。関係が良好なうちに「ベンダー変更時には構成図・IPアドレス・設定情報を受領できる」「並行稼働期間を設けて責任分界点を明確にする」といった条件を合意しておくと、いざ変更が必要になったときにスムーズに移行できます。
セキュリティと責任分界を明確にする
アプリは個人情報やログイン情報、場合によっては決済情報を扱うため、セキュリティ対応の責任範囲を発注時に明確にしておく必要があります。脆弱性が放置されると、不正アクセスやデータ改ざんの被害につながります。実際に、Webサイトの保守を怠ってサーバーがハッキングされ、企業サイトの内容が無関係なものに書き換えられた事例も報告されています。OSやライブラリのセキュリティパッチを誰がいつ適用するのか、その責任を契約で明確にしておくことが重要です。
複数のベンダーやクラウドサービスが関わる場合は、責任分界点の取り決めがさらに重要になります。障害が起きた際に「ネットワークは新ベンダー」「サーバーは旧ベンダー」「アプリ側は社内」と各社が責任を転嫁し合い、復旧が大幅に遅延した事例もあります。発注時に「どの領域は誰が一次対応するか」を文書で定めておけば、障害発生時に迅速に切り分けられ、無用な遅延を避けられます。近年はAIによるエラーログの自動解析や障害の自動検知も保守の現場に取り入れられつつあり、対応スピードを高める手段として依頼先の活用方針を確認しておくとよいでしょう。
まとめ
アプリ運用保守を発注・外注する際は、まず「運用」と「保守」の範囲を切り分け、OS更新やストア審査対応といったアプリ固有の論点まで含めて保守範囲を文書化することが出発点になります。そのうえで、応答時間・復旧時間・稼働率といったSLAを数値で合意し、準委任と請負を作業の性質に応じて使い分けることで、品質と責任の所在を明確にできます。
さらに、ストアアカウントや署名鍵、ソースコードを自社名義で保有し、属人化を防ぐ引き継ぎドキュメントの整備を契約に盛り込むことが、将来の自由度を守る鍵となります。発注前にRFPと現状資料を整え、価格だけでなく実績と提案力、引き継ぎ支援の姿勢で依頼先を見極め、契約締結前にチェックリストで条件を確認すれば、追加費用や対応遅延、ベンダーロックインといったトラブルを未然に防げます。本記事で紹介した観点を踏まえ、自社アプリに最適な保守パートナーとの長期的な関係を築いていただければ幸いです。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。