アプリはストア公開した瞬間から、OS更新、問い合わせ、障害、データ増加、外部API変更へ対応する運用段階へ入ります。
保守は壊れた箇所を直す作業、運用は日々の監視と問い合わせ、改善は利用結果から価値を高める作業として分けると優先順位が安定します。
公開前に担当者、通知条件、復旧手順、更新頻度、改善指標を決めてください。
アプリ開発の目的に合う相談先は、外注と学習を目的別に分けた相談ガイドにまとめています。
| 活動 | 起点 | 主な成果物 |
|---|---|---|
| 定常運用 | 監視、問い合わせ、定期作業 | 日次記録、対応履歴 |
| 障害対応 | アラート、利用者報告 | 影響、復旧、再発防止 |
| 保守更新 | OS、依存関係、外部APIの変更 | 更新版、試験結果 |
| 改善 | 利用データ、調査、要望 | 仮説、優先順位、効果測定 |
| リリース管理 | 修正と機能追加 | 変更履歴、配布計画、戻し方 |
運用保守を五つの活動へ分ける
問い合わせ対応と障害対応を同じ列に置くと、緊急性の低い要望と主要機能停止が混ざります。
受付時に影響範囲、緊急度、再現性、回避策の有無を分類します。
| 活動 | 例 | 目標 |
|---|---|---|
| 監視 | エラー率、応答、重要操作の成功率 | 異常を早く検知 |
| 問い合わせ | 操作質問、アカウント確認 | 利用者を復帰 |
| 障害 | ログイン不能、データ不整合 | 影響を止め復旧 |
| 保守 | SDK、ライブラリ、証明書更新 | 継続してビルド、公開 |
| 改善 | 動線、機能、性能の変更 | 測定した課題を改善 |
運用の評価はサーバーが動いているかだけでは足りません。
ログイン、検索、登録、決済など利用者の重要操作が成功しているかを見ます。
クラウド運用の観点を整理するなら、AWS Well-Architectedの六つの柱が運用、セキュリティ、信頼性、性能、費用、持続可能性を別々に扱っています。
自社のアプリへ該当する指標と担当を選び、製品名だけを台帳へ置かないでください。
障害対応を検知から振り返りまで六段階で進める
障害時に全員がログを見始めると、利用者への案内と復旧判断が遅れます。
- 重要操作への影響と開始時刻を確認する
- 対応責任者を決め、調査、復旧、連絡を分担する
- 機能停止、前版への切り戻し、負荷制限から一時対策を選ぶ
- データ整合性を確認し、復旧後の再実行範囲を決める
- 利用者と関係者へ影響、対応状況、次回連絡を伝える
- 原因、検知、判断、再発防止を振り返り開発へ戻す
アラートは、人が直ちに行動すべき状態へ絞ります。
Google SREの実践的なアラート資料は、緊急通知を行動可能で利用者に関係する状態へ結び付ける原則を示しています。
通知ごとに確認手順、一次対策、担当者、権限、連絡先を付けます。
夜間に通知されても誰も本番へ入れない体制では、検知だけを早くしても復旧時間は縮まりません。
月間停止時間から可用性を考える計算例
次の数字は、可用性と利用者影響を結び付けるための仮定です。
30日間を43,200分として、そのうち合計60分間、主要機能が利用できなかったとします。
稼働時間は43,200－60で43,140分です。
仮の可用性は43,140÷43,200×100で約99.86％になります。
| 項目 | 計算 | 結果 |
|---|---|---|
| 月間総時間 | 30日×24時間×60分 | 43,200分 |
| 主要機能停止 | 合計 | 60分 |
| 稼働時間 | 43,200－60 | 43,140分 |
| 可用性 | 43,140÷43,200 | 約99.86％ |
同じ60分でも、深夜の低利用時間と決済集中時間では影響が違います。
割合だけで判断せず、失敗した操作数、失われたデータ、回避手段、復旧後の再処理を記録してください。
OSと依存関係の更新を小さく試す
OS、SDK、ライブラリ、証明書、外部APIには更新期限があります。
構成要素、利用版、サポート期限、更新担当、最終試験日を台帳にします。
版番号の付け方を決める際は、Semantic Versioningの互換性を基準にする考え方を参考にできます。
ストア表示版と内部API版へ同じ規則を使うとは限らないため、適用対象を明記してください。
更新は開発環境で一つずつ行い、ビルド、主要動線、データ移行、前版との互換性を確認します。
複数ライブラリとSDKを同時に上げると、不具合の原因を絞りにくくなります。
公開条件も継続して変わり得ます。
Androidでは公式の公開準備、iOSではApp Review Guidelinesを更新ごとに確認してください。
ログと問い合わせを改善仮説へ変える
ログは集める量ではなく、判断できる問いから設計します。
重要操作の開始、成功、失敗理由、所要時間、アプリ版、相関IDを記録し、秘密値や個人情報の本文は避けます。
問い合わせをそのまま機能要望へ変えず、利用者の目的、発生場面、回避方法、頻度を確認します。
説明不足、操作の複雑さ、権限、性能、業務ルールのどれが原因かを分類してください。
改善には指標と期限を付けます。
「検索を改善する」ではなく、対象利用者、変更する動線、成功率や所要時間、測定期間を決めます。
安全性の不具合は通常の改善待ちへ入れません。
NIST SSDFが扱う脆弱性対応の考え方を使い、受付、影響評価、一時対策、修正版、再発防止を別の経路で管理します。
アプリの運用保守でよくある質問
アプリの保守はどのくらい続けますか？
利用者とデータを持ち、ストアで公開する間は更新、問い合わせ、脆弱性、終了手順への責任が続きます。
終了する場合も告知、データ出力、課金停止、ストア非公開、保存データ削除を計画します。
ログは多いほど障害調査に役立ちますか？
目的のない大量ログは重要な異常を埋もれさせ、個人情報や秘密値を残す危険も増やします。
利用者の重要操作と障害対応の問いから必要項目、保存期間、閲覧権限を決めます。
OS更新のたびにアプリ更新が必要ですか？
必ず更新するとは限りませんが、利用SDK、端末機能、ストア条件への影響を確認します。
iOS公開では現在の審査ガイドラインも照合し、対応OSの実機で主要動線を再試験してください。
復旧と改善を同じ運用記録から進める
運用保守の成熟度は、障害が一度も起きないことではなく影響を早く把握し、復旧し、学びを次の版へ戻せることに表れます。
監視、問い合わせ、変更、障害を共通の版と操作へ結び付け、判断の履歴を残します。
- 運用、障害、保守、改善、リリース管理で異なる起点と成果物
- 障害対応に必要な影響確認、責任者、一時対策、復旧、連絡、振り返り
- 可用性の割合と併せて見る失敗操作、データ、回避手段、再処理
- 更新台帳へ残す構成要素、版、期限、担当、最終試験日
社内業務へ組み込むアプリなら、業務アプリ開発の要件と導入効果で運用担当者と現場の変更まで含めて設計できます。
