モバイルアプリのメンテナンス・セキュリティ・リリース運用：ローンチ後の安定稼働

本ガイドは、モバイルアプリをリリース済みで、その後の運用を担うCTO・エンジニアリングリード・プロダクトオーナーを対象としています。扱うテーマは、パッチサイクル・OS／SDKサポート・アプリストアリリース運用です。ディスカバリーから初回ローンチまではモバイルプロダクト開発ガイド、ビルド方針の選択はネイティブ vs クロスプラットフォーム開発、サーバーサイドアーキテクチャはモバイルアプリのバックエンド・API・オフライン同期をご参照ください。本ページは、初回リリース後から始まる運用レイヤーを対象としています。

目次

• アプリのリリース後に変わること、そして誰が担うのか
• リリース前にすべての変更を分類する
• 段階的ストアロールアウトの実際の手順
• 古いOSまたはSDKバージョンのサポートをいつ終了すべきか
• リリース間のセキュリティメンテナンス
• モバイルメンテナンスとリリース運用におけるAIの活用
• 実績として存在するもの・存在しないもの
• 代替案：誰がメンテナンス・セキュリティ・リリース運用を担うか
• 本ガイドの制限事項
• よくある質問
• 次のステップ

アプリのリリース後に変わること、そして誰が担うのか

Webサイトはデプロイした瞬間に変わりますが、モバイルアプリはそうではありません。ユーザーは自分のスケジュールでアップデートし、2つのストアはアプリの下でルールを変え続けているからです。AppleとGoogleはレビューガイドラインと最低ターゲットAPIレベルを定期的なサイクルで改定し、サードパーティSDK（プッシュ通知・サインイン・決済・アナリティクス）はそれぞれ独自のセキュリティアドバイザリーを公開します。また、一定数のユーザーは1年前のアプリバージョンを使い続けています。通常、3つの役割がオーナーシップを分担します。エンジニアリングリードまたはリリースリードが各変更を分類してリリースし、セキュリティオーナーがSDKと依存関係のアドバイザリーを追跡し、プロダクトオーナーが機能を次のサイクルに回すかどうかを判断します。各役割に担当者を明確に設定しなければ、パッチは後回しになり、アプリストアへの対応は計画的ではなく事後対応になってしまいます。

リリース前にすべての変更を分類する

すべてのリリースが同じ承認フローや同じロールアウト速度を必要とするわけではありません。変更を最初に3種類のいずれかに分類することで、残りの運用モデルがリリースごとの議論ではなく、機械的に動くようになります。

メンテナンスリリースも完全な段階的スケジュールに従います。バグ修正でも独自のクラッシュを引き起こす可能性があるため、「新機能なし」は「リスクなし」とは同義ではありません。セキュリティパッチは、スケジュールをスキップできる唯一のケースですが、それは待機することでアクティブなエクスプロイトを放置することになる場合に限られます。

古いOSまたはSDKバージョンのサポートをいつ終了すべきか

サポート終了の基準は、固定した年数ではなく、各プラットフォーム固有のポリシーサイクルに連動させてください。Google Playは年次サイクルで必要なターゲットAPIレベルを引き上げており、これに遅れたアプリへのアップデート配信を停止します。AppleのApp Store審査ガイドラインも同様のリズムで改定されます。プラットフォームバージョンのサポートを終了するのは、継続サポートが必要なセキュリティ機能をブロックする場合、ストアポリシーの更新により継続サポートが不可能になった場合、またはそのインストールシェアがチームが事前に合意した閾値を下回った場合です。その際は、効力発生後ではなく事前にアプリ内でサポート終了を告知してください。同じ規律がバンドルされたSDKにも適用されます。セキュリティアドバイザリーを受け続けているSDKはパッチ対象であり、自動アップグレードの候補ではありません。テストされていないSDKのバージョン変更は、それ自体が独自の段階的ロールアウトを必要とするメンテナンスリリースだからです。

リリース間のセキュリティメンテナンス

稼働中アプリのセキュリティ作業はリリース内の一ステップではなく、継続的な活動です。アプリに同梱されているすべてのSDKと依存関係のアドバイザリーを監視し、高深刻度の発見は次の定例リリースではなく合意したウィンドウ内でパッチを適用し、緊急の依存関係の更新でも通常のリリースと同じリトライおよびロールバックテストを省略しないことを意味します。Netbase JSCはこれを自社のビルド成果物に適用しています。具体的には、セキュアコードレビューとバージョン管理・転送中のTLSと保存時のAES・ロールベースのアクセス制御・管理ダッシュボードへのMFA・脆弱性スキャンとペネトレーションテスト・ディザスタリカバリーを実施しており、NDA・DPA・SLAについてはご要望に応じて対応します。Netbase JSCは自社の情報セキュリティおよび運用プラクティスについてISO 27001認証とSOC 2 Type II認証を取得していますが、いずれもクライアントのアプリやホスティングには適用されず、証明書番号・監査機関・適用範囲は公開していません。

実績として存在するもの・存在しないもの

Netbase JSCは、稼働中アプリのパッチおよびリリースサーフェスを構成するコンポーネントを、ビルドフェーズのエンゲージメントにおいて構築・リリースしてきました。

• RB Marketplace モバイルアプリ。 注文・価格アラートのためのFirebase Cloud Messagingプッシュ通知、Google／Facebook／Appleサインイン、セキュアなWebViewを通じた決済を、キックオフからQA・ハンドオーバーまで6フェーズ・45画面以上で提供しました。
• Dey Page。 Firebase プッシュ通知・ディープリンク・アプリ内ブラウザによる決済を備えたiOS／Android向けReact Nativeアプリを、12週間のWebおよびモバイル計画の一部として提供しました。
• ドバイを拠点とするロイヤルティ・リワードプラットフォーム（NDAにより非公開）。 クライアントアプリ向けのモバイルSDK UIコンポーネントを、プラットフォーム独自のWebhookおよびスケジュール同期インテグレーションとともに提供しました。

存在しないもの。これらはビルドフェーズおよびデリバリーの実績であり、継続的なメンテナンス・セキュリティパッチ・リリースサイクルのエンゲージメントではありません。初回デリバリー後のいかなるアプリについても、パッチ対応時間・リリースサイクル・稼働率・クラッシュフリー率・インシデント数を示すNetbase JSCの公開実績は存在しません。上記のリリース種別マトリクス・ロールアウトステップ・サポートウィンドウルールは、ストアドキュメントとデリバリー実践から導かれたものであり、特定のメンテナンス契約の計測値ではありません。

代替案：誰がメンテナンス・セキュリティ・リリース運用を担うか

Netbase JSCのチームは3名から30名で構成され、ビジネスアナリスト・プロジェクトマネージャー・ソリューションアーキテクト・開発者・QAを組み合わせています。通常、ディスカバリーから1〜2週間以内に開始し、週次レビュー・KPIダッシュボード・専任アカウントマネージャーがデリバリーを通じてサポートします。カスタム開発で作成されたIPはクライアントに帰属し、ほとんどのNetbase JSCプロジェクトはディスカバリー後に請負契約で進行しますが、継続的なメンテナンスキャパシティに適した場合はマイルストーンベース・月次リテイナー・KPI連動の契約形態も提供しています。このオファーはモバイルアプリ開発にあり、再利用可能な認証・プッシュ通知・オフラインコンポーネント向けのモバイルプロダクトアクセラレーターによって支援されています。

本ガイドの制限事項

• アプリストアの審査ポリシー・ターゲットAPI要件・フェーズド／段階的ロールアウトの仕組みは、各プラットフォーム固有のスケジュールで変更されます。上記の基準を適用する前に、AppleおよびGoogleの公式ドキュメントで現在のルールをご確認ください。
• Netbase JSCのいかなるエンゲージメントについても、パッチ対応時間・リリースサイクル・稼働率・クラッシュフリー率・インシデント数は主張していません。実際のプログラムの数値は、そのアプリ・SDK・ユーザーベースに依存します。
• OWASP MASVSおよび引用されたAppleとGoogleのドキュメントは、それらが定義するものの参照として挙げられており、Netbase JSCまたはクライアントのアプリがそれらに対して評価されたという主張ではありません。

次のステップ

現在のアプリ構成をお伝えいただければ、ソリューションレビューを予約してメンテナンス・セキュリティ・リリース運用モデルのスコープを設定します。または、モバイルプロダクトアクセラレーターソリューションもご覧ください。

関連サービスとソリューション