アプリ運用保守の発注は、運用と保守のどこまでを外部に任せるかを切り分け、保守範囲を文書にすることから始まります。
そのうえで、SLA、契約形態、リリース権限を決め、契約前に確認します。OS更新やストア審査など、アプリ固有の論点を曖昧にすると、追加費用や対応の遅れを招きます。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
- 運用と保守の範囲、アプリ固有の論点
- SLA、障害対応、契約形態、リリース権限
- アカウント・ソースコード・引継ぎドキュメント
- RFP、依頼先選定、契約前チェックリスト
アプリ運用保守を発注・外注する前に押さえる全体像
発注では、まず「運用」と「保守」が指す業務の違いを理解し、自社が外注したい範囲を明確にします。
「保守をお願いしたい」とだけ伝えると、依頼先との認識がずれ、後から追加費用や対応の遅れを招きます。
「運用」と「保守」による外注範囲の違い
アプリ運用保守の発注で最初につまずきやすいのは、「運用」と「保守」を一括りに考えてしまう点です。運用とは、サーバーやアプリの稼働監視、バックアップ取得、ユーザー問い合わせへの一次対応など、日常的に発生するオペレーション業務を指します。
一方の保守とは、障害発生時の復旧、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、アカウント、契約終了時の引き継ぎまで多岐にわたるため、次の5点で確認します。
- 保守範囲（含む作業／対象外の作業／別途見積もりの作業）と、OS更新・ストア審査対応の範囲と頻度を文書で明確にする
- SLA（応答時間・復旧時間・稼働率）と、その未達時の扱いを決める
- ストアアカウント・署名鍵・ソースコードの帰属先を明記する
- 障害時の責任範囲と免責の条件を取り決める
- 途中解約のルール（違約金の有無を含む）と、契約終了時のデータ引き渡し・引き継ぎ支援の義務を盛り込む
発注側は、これらを一つずつ確認し、口頭ではなく契約書や仕様書に文書として残すことが、トラブル回避の基本になります。
特に、契約終了時のデータ引き渡しと引き継ぎ支援は、契約時にこそ取り決めておくべき項目です。関係が良好なうちに「ベンダー変更時には構成図・IPアドレス・設定情報を受領できる」「並行稼働期間を設けて責任分界点を明確にする」といった条件を合意しておくと、いざ変更が必要になったときにスムーズに移行できます。
セキュリティと責任分界の明確化
アプリは個人情報やログイン情報、場合によっては決済情報を扱うため、セキュリティ対応の責任範囲を発注時に明確にしておく必要があります。脆弱性が放置されると、不正アクセスやデータ改ざんの被害につながります。実際に、Webサイトの保守を怠ってサーバーがハッキングされ、企業サイトの内容が無関係なものに書き換えられた事例も報告されています。
OSやライブラリのセキュリティパッチを誰がいつ適用するのか、その責任を契約で明確にしておくことが欠かせません。複数のベンダーやクラウドサービスが関わる場合は、責任分界点の取り決めがさらに重要になります。
たとえば障害時に、「ネットワークは新ベンダー」「サーバーは旧ベンダー」「アプリ側は社内」と責任を転嫁し合い、復旧が遅れた事例もあります。発注時に「どの領域を誰が一次対応するか」を文書で定めておけば、障害時の切り分けが速まり、無用な遅延も避けられます。近年はAIによるエラーログの自動解析や障害の自動検知も保守の現場に取り入れられつつあり、依頼先の活用方針も確認しておくとよいでしょう。
まとめ
アプリ運用保守を発注・外注する際は、まず「運用」と「保守」の範囲を切り分け、OS更新やストア審査対応といったアプリ固有の論点まで含めて保守範囲を文書化することが出発点になります。
発注側は、応答時間・復旧時間・稼働率といったSLAを数値で合意し、準委任と請負を作業の性質に応じて使い分けることで、品質と責任の所在を明確にできます。
将来の自由度を守るには、ストアアカウントや署名鍵、ソースコードを自社名義で保有し、属人化を防ぐ引き継ぎドキュメントの整備を契約に盛り込むことが欠かせません。
発注前にRFPと現状資料を整え、価格だけでなく実績と提案力、引き継ぎ支援の姿勢で依頼先を見極めます。契約締結前にチェックリストで条件を確認すれば、追加費用や対応遅延、ベンダーロックインといったトラブルを未然に防げます。
本記事で紹介した観点を踏まえ、自社アプリに最適な保守パートナーとの長期的な関係を築いていただければ幸いです。
RFP作成前に、スマホアプリ開発の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。