LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

アプリサイズが大きいと何が問題か — DL離脱・ストレージ・更新負荷

アプリサイズの削減外注とは、モバイルアプリのダウンロードサイズや端末上のインストールサイズを圧縮する作業を、専門のIT企業に委託する取り組みを指します。アプリの新機能追加や資産の蓄積に伴ってサイズが肥大化しやすく、開発・事業担当がこれを放置するとユーザー体験と事業指標の両面に影響が出ます。

ダウンロード離脱とインストール率の低下

アプリのダウンロードサイズが大きいと、モバイル回線のユーザーがWi-Fi接続を待つか、ダウンロードそのものをあきらめる判断につながります。Androidの公式ガイドでは、アプリサイズの増加がインストール率の低下に直結する旨を指摘しており、サイズ削減を継続的な品質改善のひとつと位置づけています^*1。

特に新興市場や格安スマートフォンを使うユーザー層では、端末ストレージの余裕が少ないケースがあります。インストール後のストレージ不足は、ユーザーが他のアプリとの兼ね合いで削除対象として判断する要因になります。

更新負荷とエンゲージメント低下

アプリサイズが大きいほど、定期アップデートのダウンロード量も増えます。アップデートのたびに通信量が多いアプリは、ユーザーが自動更新をオフにする動機となり、古いバージョンを使い続けるユーザーが増えます。

古いバージョンへの対応コストが増えると、開発チームの維持負荷も上がります。セキュリティパッチや機能修正を速やかに全ユーザーへ届けるためにも、アプリサイズの管理は開発運用の観点からも重要です。

Androidのサイズ削減手法 — App Bundle・Play Feature Delivery・R8/ProGuard・リソース最適化

Androidのサイズ削減は、Googleが提供する公式の仕組みと開発時の最適化手法を組み合わせて進めます。Android Developersの公式ガイドでは、App Bundle（AAB）の利用を筆頭に、複数の削減手法を体系的に解説しています^*1。

App Bundle（AAB）— デバイス別に最適化したAPKを配信

App Bundle（Android App Bundle、拡張子.aab）は、Google Playへの公開形式のひとつです。従来の単一APKとは異なり、コンパイル済みコードとすべてのリソースを含むバンドルをGoogleにアップロードすると、Google Playが各ユーザーのデバイス構成（CPU命令セット・画面密度・言語）に最適化したAPKを生成して配信します^*2。

ユーザーは自分のデバイスに必要なコードとリソースだけをダウンロードするため、全構成を詰め込んだ単一APKよりもダウンロードサイズを抑えられます。Googleは2021年8月以降、新規アプリにはApp Bundleでの公開を必須としており^*2、既存アプリも移行が推奨されています。

なお、App Bundleの圧縮ダウンロードサイズには200MBの上限があります^*1。これを超えるアプリはPlay Feature DeliveryまたはPlay Asset Deliveryの利用が必要です。

Play Feature Delivery — 機能のオンデマンド・条件配信

Play Feature Delivery（プレイ フィーチャー デリバリー）は、App Bundleの高度な機能として、アプリの特定機能をインストール時ではなく必要なタイミングでダウンロードできる仕組みです^*3。

配信方式には「インストール時（必須モジュール）」「オンデマンド（ユーザーが要求した時）」「条件付き（デバイス要件に合致する場合のみ）」「インスタント（アプリ未インストールで体験可能）」の4種類があります^*3。使用頻度が低い機能や特定ユーザー層だけが使う機能をオンデマンドモジュールに分離することで、初回インストールサイズを削減できます。

R8/ProGuard — コードの縮小・難読化

R8（Android Studioが標準で使用するコンパイラ）とProGuardは、リリースビルド時にコードの縮小・難読化・最適化を行うツールです^*1。使用されていないクラスやメソッドをビルド時に除去し、コードサイズを圧縮します。また、シンボル名を短縮することでさらに小さくできます。

Gradleビルドスクリプトで `minifyEnabled true` と `shrinkResources true` を設定するだけで有効化できます。ただし、R8によるコード除去がアプリの動作に影響する場合があるため、ProGuardルールの適切な設定と動作確認が必要です。この設定の調整は、ビルドシステムの知識と検証工数を要するため、外注時の重要なスコープのひとつになります。

リソース最適化 — 未使用削除・WebP変換・密度別配信

アプリサイズ肥大化の原因として、使われていない画像・レイアウト・文字列リソースが蓄積されているケースがあります。`shrinkResources`によって未使用リソースはビルド時に自動削除できます^*1。

画像はJPEGやPNGをWebP形式に変換することで、品質を維持しながらファイルサイズを抑えられます^*1。また、App Bundleのデバイス別APK配信を使うと、画面密度に対応した解像度の画像のみが各デバイスに配信されるため、全密度の画像を一括で持つ必要がなくなります。アイコンや単純なグラフィックはVectorDrawable（ベクター形式）に置き換えることでも削減効果が期待できます。

iOSのサイズ削減手法 — App Thinning（App Slicing・On-Demand Resources）

iOSでは、Appleが提供するApp Thinning（アップ シニング）という仕組みによってアプリのサイズを最適化できます。App Thinningは、App Slicing（アップ スライシング）とOn-Demand Resources（オンデマンドリソース）の2つの要素で構成されています^*4。

App Slicing — デバイス別に必要なリソースのみを配信

App Slicingは、App Store ConnectにアップロードされたアプリをAppleが自動的にデバイス別のバリアントに分割し、各ユーザーの端末に必要なアーキテクチャとリソースだけを配信する仕組みです^*4。

例えば、Retina HDディスプレイを持つ端末には高解像度の画像リソースのみが配信され、低解像度の端末向けリソースは含まれません。開発者側が特別な実装をしなくてもApp Store経由での配信で自動的に有効になります。ただし、Asset Catalog（Xcodeのアセットカタログ）を適切に構成していることが前提です。

On-Demand Resources — 必要なタイミングでリソースを追加DL

On-Demand Resources（ODR）は、アプリの一部リソースをApp Storeのサーバーに保存しておき、ユーザーが必要とするタイミングで追加ダウンロードする仕組みです^*4。ゲームの後半ステージのデータや、特定の条件でしか使わないサウンド・画像などをODRに分離することで、初回インストール時のダウンロードサイズを抑えられます。

利用頻度が低いリソースや、特定のシナリオでのみ表示されるコンテンツを持つアプリ（ゲーム・学習アプリ・コンテンツ配信アプリ等）でとくに効果的です。実装にはNSBundleResourceRequestを使ったコードの変更と、Xcodeでのリソースタグ設定が必要です。

削減を外注で進める流れ — 計測→要因分析→手法適用→検証

アプリサイズ削減を外注で進めるには、まず現状を数値で把握するところから始めます。外注先が適切なスコープと手法を設計するために、計測データが前提となります。以下は実務上の標準的な進め方です。

ステップ1：現状計測 — APK Analyzer・App Store Connectで数値を把握

Androidでは、Android Studioに組み込まれているAPK Analyzerを使ってAPKまたはAABの内訳を確認できます^*1。コード・リソース・アセット・ライブラリ別のサイズが可視化されるため、どのカテゴリが全体サイズを押し上げているかを特定できます。

iOSでは、App Store Connectのアップロード後にビルドの圧縮サイズとダウンロードサイズが表示されます^*4。Xcodeのビルドレポートでもバイナリサイズの内訳を確認できます。計測結果をまとめた資料を外注先に渡すことで、見積もり精度と作業効率が高まります。

ステップ2：要因分析 — 膨張箇所の特定と優先順位づけ

計測データをもとに、サイズ膨張の主要因を特定します。よくある要因には、未圧縮のまま同梱された画像群、不要なサードパーティライブラリの依存関係、削除されずに残った旧バージョンのリソース、R8/ProGuardが無効のままのリリースビルドなどがあります。

要因分析の精度は、アプリのアーキテクチャとビルド設定の理解に依存します。特に依存ライブラリの精査はアプリ固有の知識が必要なため、外注先にリポジトリアクセスと技術背景の説明を提供することが分析の質に直結します。

ステップ3：手法適用 — App Bundle移行・R8有効化・リソース整理

要因に応じた削減手法を適用します。AndroidでApp Bundleをまだ使っていない場合は移行が第一優先です。R8/ProGuardが未設定ならビルド設定への追加と動作確認を並行して進めます。

リソース整理では、lintツールによる未使用リソースの洗い出しと、画像のWebP変換を組み合わせます。iOSでApp Thinningを活用する場合は、Asset Catalogの構成確認とODR対象リソースの選定・実装が必要です。

手法適用には既存コードへの変更が伴うため、テスト工数を含めたスケジュール設計が欠かせません。内製でR8設定を変更したところ特定機能が動作しなくなった、という事例は実務上よく見られます。適切なProGuardルールを整備できるエンジニアが社内にいない場合、この工程ごと外注するのが合理的です。

ステップ4：検証・再計測 — 効果確認と継続監視

手法適用後にAPK AnalyzerやApp Store Connectで再計測し、削減前との数値比較を確認します。削減量だけでなく、アプリの動作に問題が出ていないかの回帰テストも必要です。

継続的なサイズ管理には、CI/CDパイプラインにサイズチェックを組み込む方法が有効です。リリースごとにサイズが一定量を超えた場合に警告を出す仕組みを整備しておくと、肥大化の再発を防ぎやすくなります。

外注の使いどころ — 分析・実装・継続最適化の委託判断軸

アプリサイズ削減のどの工程を外注するかは、社内リソースと課題の深刻度によって変わります。以下は実務上の委託判断の目安です。

計測基盤がない場合 — 計測・分析から委託する

「ダウンロードサイズが大きいとは聞いているが、どこに問題があるか分からない」という状況では、計測・分析工程ごと外注するパターンが有効です。外注先がAPK Analyzerや App Store Connectの数値を読み解いて要因整理をしてくれるため、社内の技術調査コストを省けます。

この工程を委託するには、アプリのビルド環境へのアクセス提供と、技術スタック（言語・フレームワーク・CI環境）の説明が必要です。NDAや秘密保持契約を事前に締結し、コードアクセスの範囲を明確にしてから進めましょう。

実装スキルが不足している場合 — R8設定・ODR実装を委託する

Play Feature DeliveryやOn-Demand Resourcesの導入は、アプリのアーキテクチャを変更する作業です。モジュール分割の設計経験や、iOS・AndroidのSDKに関する深い知識が必要で、経験の少ない開発者が試行錯誤すると手戻りが発生しやすい領域です。

具体的なスキルとして、AndroidではGradleマルチモジュール構成・Play Core Library・AABビルドの知識、iOSではNSBundleResourceRequest・Asset Catalogの構成・XCTestによる動作確認が求められます。これらを内製で習得する期間を取るより、実績のある外注先に委託してスケジュールを確定させる判断は合理的です。

継続最適化が必要な場合 — ラボ型での継続支援

アプリへの機能追加が続く限り、サイズ管理は一度やれば終わりではありません。リリースサイクルに合わせてサイズ監視と最適化を継続したい場合は、単発の請負よりも継続的な支援体制のほうが管理しやすくなります。

ラボ型（準委任）での委託では、社内エンジニアと外注先が協業しながらサイズ管理を継続できます。LASSICは元請（プライムベンダー）としてモバイルアプリの開発・運用保守を受託しており、継続的な品質管理体制を構築したい企業のご相談にも対応しています。

まとめ — アプリサイズ削減を外注で成果につなげる3つの判断軸

本稿では、アプリのダウンロードサイズ増大がインストール率・更新率・ストレージ占有に与える影響と、AndroidのApp Bundle・Play Feature Delivery・R8/ProGuard・リソース最適化、iOSのApp Thinning（App Slicing・On-Demand Resources）という公式の削減手法を整理しました。

外注で成果につなげる判断軸を3点に集約すると次の通りです。第一に、計測データなしで外注しても要件が定まらないため、APK AnalyzerやApp Store Connectで現状を数値化してから依頼するのが起点です。第二に、R8/ProGuardの設定ミスやPlay Feature Deliveryのモジュール設計誤りは動作不具合に直結するため、実装スキルが社内にない工程は経験のある外注先に委ねるのが合理的です。第三に、機能追加が続くアプリではサイズ管理は継続作業であり、一度だけの対応ではなくリリースサイクルに組み込んだ監視体制の構築まで視野に入れると効果が持続します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Android Developers「Reduce your app size — Android Developers」（Google）
2. *2　出典：Android Developers「Android App Bundles — Android Developers」（Google）
3. *3　出典：Android Developers「Play Feature Delivery overview — Android Developers」（Google）
4. *4　出典：Apple「Reducing your app’s size — Apple Developer Documentation」（Apple Developer）

Tweet