アプリ運用保守の立ち上げは、現状把握、運用設計、並走確認の順に進めると、安定した定常運用につながります。OS更新や審査に追従できないと、アプリの起動不能やストア削除のリスクもあります。無理のない移行計画と納期管理は、この順序を押さえるところから始まります。
▼全体ガイドの記事
・アプリ運用保守の完全ガイド
スマホアプリ開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
アプリ運用保守の全体像と「期間」の捉え方
運用保守は毎月続きますが、実際には明確な立ち上げ（移行）期間もあります。新体制を作るときや、開発会社から別のベンダーへ引き継ぐときは、システムを把握して手順を整え、安定稼働を目指します。
契約の翌日から完璧に保守できると考えると、初動の障害対応が後手に回り、ユーザーへの影響が広がるおそれがあります。そこで期間は、立ち上げと、その後に続く定常運用の2層で捉えるのが出発点です。
運用保守と開発の違いと、アプリ特有の事情
新規開発は要件を期日までに作るプロジェクト型で、運用保守は稼働中のサービスを維持する継続型です。この性質の違いは、期間やスケジュールの組み方に影響します。
また、モバイルやWebアプリでは、一般的な業務システムとは異なる事情も期間設計に影響します。
- OS更新への適応：年次のiOS・Android更新に合わせた検証と改修が要ります。
- ストア審査：モバイルアプリは審査があり、却下時は修正と再申請が必要です。
- 技術の陳腐化：放置するとライブラリの依存関係が壊れ、改修できない技術的負債がたまります。
OS更新に伴うAPIの非推奨化や実行環境の変更に対応する保守は、「適応保守」と呼ばれます。React、Flutter、Swift、Kotlinなどは進化が速く、数年放置すると依存関係の問題で改修が困難になります。
ストア審査は数時間から数日かかる場合があります。ただし、リジェクトされると手戻りが発生します。
立ち上げ期間と定常運用期間の2層構成
アプリ運用保守の予定は、立ち上げ期間（オンボーディング）と定常運用期間に分けて設計します。
- 立ち上げ：ソースコード・インフラ構成・既存手順・障害履歴を引き継ぎ、自力で保守できる状態を目指します。
- 定常運用：月次契約で続け、期間より応答・復旧時間とリリース周期を管理します。
外部ベンダーへの委託・移行では、導入に1〜3ヶ月程度かかるのが一般的です。そのうえで、安定稼働に向けて3〜6ヶ月程度のハイパーケア（並走期間）が推奨されます。
並走中は、自社や旧ベンダーと新チームが一緒に監視・対応し、実際の障害を通じて手順書を修正します。2つの期間を分けて考えると、初期の集中的な工数と継続的な運用負荷を混同せずに見積もれます。
保守体制の立ち上げ・移行スケジュール
移行を場当たり的に進めると、引き継ぎ漏れや責任の空白が生じ、本番障害時に誰も対応できないおそれがあります。これを防ぐため、立ち上げを段階的なステップに分けて計画します。
外部の保守ベンダー（MSP=マネージド・サービス・プロバイダ）へ移行する場合を例に、現状棚卸しからハイパーケア、定例レビューまでの標準的な手順と期間を見ていきます。また、自社で保守チームを内製する場合も、基本的なステップは共通です。
ステップ1〜2：現状棚卸しと要件・SLAの定義（2〜4週間）
最初に、対象アプリの現状と運用負荷を一覧にするため、次の情報を文書にまとめます。
- システム構成：対象アプリのiOS版・Android版・Web版、バックエンドAPI、インフラを文書化します。
- 運用記録：既存の手順、過去の障害履歴、関係者の連絡網をまとめます。
- 依存関係：サードパーティSDKやライブラリのバージョンを記録します。
- 重要資産：ストアアカウント、署名証明書、プッシュ通知の証明書を確認します。
署名証明書には、iOSのプロビジョニングプロファイルやAndroidのキーストアが含まれます。特に、ストアアカウントや証明書の引き継ぎが漏れるとリリースできないため、棚卸しの段階で確実に押さえます。
委託する範囲と自社で判断する範囲を分け、どこまでを誰が受け持つかを責任分界点として決めて書き残します。役割はRACIマトリクス（実行・説明責任、相談先・報告先を整理する表）で整理し、稼働率・応答時間・復旧時間のSLAも定めます。
棚卸しとSLA定義には2〜4週間が目安です。この段階の整理の丁寧さが、後工程の手戻りを左右します。
ステップ3：運用設計と手順書（プレイブック）作成（2〜4週間）
SLAと責任分界点が決まったら、運用設計と手順書（プレイブック・Runbook）を作成します。
- 障害対応：監視アラート後の復旧手順と連絡先を定めます。
- リリース：配信手順と切り戻し計画を具体化します。
- アプリ固有の運用：ストア提出、審査却下時の対応、強制アップデートのルールを整えます。
アプリ固有の運用に含まれる強制アップデートは、旧バージョンの利用を打ち切る仕組みです。
手順書は、ハイパーケア中のインシデントを通じて磨いていく前提で、まずはたたき台を用意します。運用設計と手順書の作成には2〜4週間が目安で、棚卸しやSLA定義と一部並行して進められます。そのため、ハイパーケア前の準備は合計で1〜2ヶ月程度に収まるケースが多くあります。
ステップ4〜5：ハイパーケア（並走）と定例レビュー（3〜6ヶ月）
並走期間（ハイパーケア）は、保守体制の立ち上げで最も重要な工程です。この期間に、引き継ぎの実務と移行後の見直しを進めます。定例レビューでは、月次などの周期で、SLAの達成状況やアラートの傾向を確認します。
- 共同対応：新チームと自社担当者または旧ベンダーが監視します。
- 周期の経験：OS更新やストア審査を1サイクル以上経験します。
- 定例レビュー：移行後もSLAやアラートを振り返ります。
実際のインシデントを通じて、手順書の不足や誤りを見つけて修正します。また、年1回しか発生しないOSメジャーアップデートなど、影響の大きいイベントへの対応力も引き継ぎます。
ハイパーケアは3〜6ヶ月が目安ですが、アプリの規模や複雑さ、文書の整備状況によって変わります。知識が属人化したアプリほど、長い並走が必要です。
立ち上げの完了をゴールにせず、不要なアラートの削減や手順の自動化など、定常運用に入ってからも改善を続けます。
OS・ストア審査追従とリリース配信のスケジュール管理
定常運用では、OS追従とリリース配信の納期管理が難所になります。業務システムは社内で検証すれば配信できます。一方、モバイルアプリは、OSやストアの予定に従うことになります。
外部の予定を織り込んだリリース計画を立てられるかが、運用保守の実力を左右します。OS更新への追従、審査を見込んだ配信、リリース管理の順に、時間軸を見ていきます。
OSメジャーアップデートへの追従スケジュール
OS更新への対応は、ベータ版の検証から正式版前の改修までの流れで進みます。
- 初夏：iOS・Androidのベータ版公開を受けて検証します。
- 夏：非推奨APIや挙動変更を確認して改修します。
- 秋：正式版前に対応版を準備します。
この公開サイクルは例年繰り返されるため、秋の正式リリースから逆算して予定を組みます。
OS更新後の不具合を防ぐには、検証の段階で見つけた問題を正式版の前に直しておくことが欠かせません。検証と改修には、アプリ規模に応じて数週間から1〜2ヶ月程度のリードタイムが必要です。
OS対応は月額定額の保守には含まれず、都度見積もりのスポット改修になるのが一般的です。年1回の予算をあらかじめ確保しておかないと、対応を見送ることになり、技術的負債が積み重なる悪循環に陥ります。
ストア審査リードタイムとリリース配信
配信にかかる時間は、モバイルとWebで異なります。
- モバイル：ストア審査を経て配信します。
- 審査却下時：修正して再申請するため、予定に余裕が必要です。
- Web：社内検証後に審査なしで配信できます。
モバイルアプリは、ビルド後にApp StoreやGoogle Playの審査を通って配信されます。審査は通常数時間から数日ですが、ガイドライン違反があると却下されます。
緊急修正でも審査時間は短縮できないため、却下に備えて予定に余裕が必要です。たとえば、金曜夜に申請すると、却下時の対応が翌週へずれるので、週末配信は前提にしません。
Webアプリは審査がないため、社内検証を終えればすぐ配信でき、緊急対応のリードタイムを短くできます。この違いを踏まえて、配信予定を組みます。
深刻な不具合に備えるなら、旧版の利用を止めて更新を促す強制アップデートを組み込んでおくと、緊急時の選択肢が広がります。
リリース管理プロセスと切り戻し計画
安定した保守には、変更を本番へ配信し、その結果を追跡するリリース管理が欠かせません。
- 事前連絡：リリース予定を関係者へ伝えます。
- 切り戻し：変更に失敗したときに障害を抑えられるよう、計画を用意します。
- 配信後の監視：リリース後の状態を確認します。
CI/CD（継続的インテグレーション・継続的デリバリー）を使うと、配信の工程を整えられます。
カナリアリリースは、一部のユーザーへ先に配信する方式です。段階的ロールアウトでは、配信比率を10%、50%、100%と徐々に広げていきます。
Google Playの段階的公開機能などを使えば、問題を検知した時点で配信を止められます。
アジャイル開発のように開発周期が短い場合は、保守の側も短いサイクルで頻繁な配信に対応することになります。
管理手順が成熟すると、安心して素早くリリースできるサイクルタイムが生まれ、運用保守全体の速度と品質が高まります。
監視・SLA・障害対応体制の整備にかかる期間
監視、SLA、障害対応の体制は、運用保守の品質を支える土台です。立ち上げの間に整えておかないと、警報を見逃したり、障害の後になって監視の不備が見つかったりします。
監視項目とアラート、対応フロー、SLA/SLO指標の設計にかかる期間を見ていきます。
監視項目の設計とアラート体制の構築
APM（アプリケーションパフォーマンス監視）やRUM（リアルユーザー監視）を使い、ユーザー体験に関わる指標を継続して観測します。
- アプリの状態：クラッシュ率やANRをOS・端末別に確認します。
- バックエンド：APIのエラー率や応答時間を監視します。
- アラート：影響度に応じた通知レベルと連絡方法を決めます。
クラッシュ率は、アプリが強制終了した割合のことで、一般に0.1%未満などを目標にします。また、ANR（Application Not Responding）は、主にAndroidで処理が長引き、操作に応答しなくなる状態です。
これらはストア評価やユーザー離れに関わるため、OSや端末のバージョンごとの傾向を見ます。
API監視では、500番台の急増やレスポンスタイムも確認します。
アラートが頻発すると、重要な警告まで見落とす「オオカミ少年化」が起きます。そこで、情報共有のレベル、翌営業日の対応、深夜休日も即時に対応する緊急レベルのように、通知の重さを段階に分けます。
一時的な急増に反応しすぎないよう、5分間継続した場合に通知するなど、しきい値を調整します。また、緊急通知はメールに限らず、チャットやPagerDutyなどの電話自動コールでも届けます。
監視とアラートの設計・検証には、立ち上げ期間のうち数週間かかります。
インシデント対応フローとSLA指標の設定
障害時の対応は、自動化した一次対応と階層化した有人チームを連携させます。
- L1：手順書に沿って初期トリアージと一時復旧を行います。
- L2：ログを詳しく分析し、代替策を適用します。
- L3：コードのデバッグや構成変更で根本解決を図ります。
対応後は、発生原因・流出原因・再発防止策をポストモーテムに記録し、手順書に反映します。
対応品質を客観的に約束する指標がSLA/SLOで、稼働率や一次復旧の時間などを定めます。例として、稼働率は99.8%以上または99.9%以上、通知は30分以内、重大障害の復旧は4時間以内です。
未達のときに稼働月数に応じた減額などのペナルティがない契約は、実質的にSLAがないのと同じです。
Web・モバイルのバックエンドは、AWSなどのパブリッククラウドを使うことが多いため、クラウド事業者と保守ベンダーのSLAの境界（責任共有モデル）を明確にしておきます。
SLAは立ち上げの初期に定め、ハイパーケアを通じて現実的な水準に調整します。
期間・納期に影響する要素と費用相場
立ち上げ期間や定常運用の対応速度は、アプリの状態と契約形態によって変わります。立ち上げ期間の要因、契約形態と納期・コスト、保守費用の相場を順に見ていきます。
費用は一般的な目安です。実際には、規模・複雑さ・求めるサービス水準に応じて、複数社から見積もりを取ります。
立ち上げ期間を左右する要素
引き継ぎにかかる時間は、アプリの状態によって変わります。
- 文書：設計書やAPI仕様書、運用手順書の整備状況。
- 構成：アプリ面やバックエンド、外部連携の複雑さ。
- 技術：利用ライブラリやOSバージョンの新旧。
- 資産の引き継ぎ：ストアアカウント、証明書、APIキーの受け渡し。
知識が特定の担当者に偏っていると、コードの読解や動作検証に時間がかかり、並走期間も長引きます。また、iOS・Android・Webに加えて複数のAPIや外部サービスが加わるほど、把握すべき対象が増えます。
サポートが切れたライブラリやOSに依存していると、追加の改修やモダナイゼーション（技術刷新）が必要になる場合があります。
ストアアカウントや証明書、APIキーの受け渡しが遅れるとリリースできず、立ち上げが停滞します。事前に詰まりそうな箇所を点検し、早めに解消しておくことが、計画どおりの完了につながります。
契約形態と費用相場の目安
契約形態は作業内容に応じて選び、追加費用や応答時間も契約前に明確にします。
- 準委任契約：障害調査や応急対応など、成果物の完成を保証しない継続業務。
- 請負契約：バグ修正や機能改修など、成果物の完成が求められる作業。
- 料金方式：月額定額制または作業時間に応じた従量制。
定額の範囲を超えた作業の追加費用は、単価などの計算方法を事前に書いておかないと、トラブルのもとになります。
契約書には、受付時間、初報応答時間、暫定対応時間も定めます。初報応答は、営業時間内2時間以内などのように、具体的な時間で書きます。
中規模アプリを準委任契約の定額保守で任せる場合、障害対応やバグ調査を含めて、月額数十万円〜100万円程度が目安です。この費用は、稼働0.5〜1.0人月程度に相当します。
特に、24時間365日の監視と即時復旧を求めると、夜間休日の待機費用が発生します。その費用は、平日日中の対応と比べて2倍以上になるケースが一般的です。
年1回のOS更新対応は、スポット改修として別途、数十万〜数百万円規模の予算を確保しておくと安心です。
緊急のモバイル修正には、ストア審査が加わります。一方、Webアプリは即日配信が可能です。この納期の違いも契約時に共有し、期待値を調整します。
まとめ
ここまで、立ち上げと移行の流れを見てきました。さらに、OS追従と審査・配信、監視・SLAの進め方も確認しました。期間や費用に影響する要素も、あわせて整理しました。外部ベンダーへの移行準備は1〜2ヶ月、安定稼働までの並走は3〜6ヶ月が目安です。
OS更新は秋の正式版から逆算し、ストア審査の時間と切り戻し計画を含めて管理します。こうした管理が、納期とサービス品質の両立を支えます。
OS対応には別の予算を確保し、SLAには未達時のペナルティも定めておきます。体制づくりやベンダー移行では、文書と重要資産の引き継ぎ状況を点検したうえで、複数の保守パートナーに相談します。
▼全体ガイドの記事
・アプリ運用保守の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。