LASSIC Media らしくメディア

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

モバイルアプリ パフォーマンス改善を外注するとは — 定義と対象範囲

モバイルアプリのパフォーマンス改善外注とは、iOS・Androidアプリの起動時間・フレームレート・メモリ使用量・クラッシュ率といった動作品質を、専門のIT企業に委託して計測・分析・品質向上を図る取り組みである。Googleが公開するAndroid Vitalsでは、クラッシュ率1.09%・ANR（アプリ応答不可）率0.47%を「悪い動作の閾値」として定めており^*1、この水準を超えるとGoogle Playでのアプリ表示に影響が生じる。

Apple・Googleが定める4つの主要パフォーマンス指標

パフォーマンス改善の対象となる指標は、プラットフォームごとに公式定義がある。Androidでは、Google PlayのAndroid Vitalsが以下の4指標を核心バイタルとして公開している^*1。

• クラッシュ率：日次アクティブユーザーのうちクラッシュを経験する割合。全体閾値は1.09%
• ANR（Application Not Responding）率：アプリが無応答になる割合。全体閾値は0.47%
• スローレンダリング：1フレームの描画に16ms（60fps相当）を超える状態。700ms以上は「フローズンフレーム」と定義される^*2
• アプリ起動時間：コールドスタート・ウォームスタート・ホットスタートの3分類で計測される

iOSでは、Apple開発者向けのXcode Organizerが起動時間・ハング率・メモリ使用量・ディスク書き込み量・スクロールヒッチ率の7カテゴリを提供している^*3。ハングとは、アプリが250ms以上ユーザー操作に応答しない状態を指す^*4。これらの指標を事前に把握しておくことが、外注スコープを明確にする前提となる。

「外注で改善できる課題」と「内製で解決すべき課題」の線引き

外注が有効なのは、専門ツールによる計測・分析・最適化実装が必要な領域である。一方、UI/UXの仕様変更や機能の追加削除は、業務知識を持つ内製チームが主導すべき判断であり、外注のみで完結させることは困難である。

起動遅延・クラッシュ・描画ジャンク — 外注で解決できる3つの問題

パフォーマンス劣化の原因は複合的であり、計測ツールを使わない目視確認では根本原因を特定できない。外注先に依頼する主要な3領域を整理する。

起動時間の遅延（コールドスタート）— 外注で有効なアプローチ

Androidのコールドスタート（アプリプロセスをゼロから新規生成する起動）は、ウォームスタート・ホットスタートより処理負荷が高く、ユーザーが最初に感じる速度印象に直結する。Googleは、起動時間の短縮に向けたベストプラクティスとして「Baseline Profiles」の実装を最優先の施策として公開しており、コード実行速度を初回起動から30%向上させる効果が報告されている^*5。

iOSでは、Xcode OrganizerのLaunch Timeメトリクスを通じて、実機デバイスにおける起動時間データを集計・分析できる^*3。起動時間の遅延原因は「起動時に実行しているライブラリ初期化の量」「ネットワーク通信の有無」「画像リソースの読み込みタイミング」など複数にまたがる。これらの計測と改善実装には、Instruments（iOS）やMacrobenchmark（Android）などのプロファイリングツールを習熟したエンジニアが必要である。

ANRとクラッシュ — Google Playでアプリ評価を下げる2大要因

AndroidのANR（Application Not Responding、アプリ応答不可）とは、UIスレッドが5秒以上ブロックされ、ユーザー操作を受け付けなくなる状態である。Googleが定めるAndroid Vitalsの基準では、ANR率が全体で0.47%を超えるとアプリの品質評価に影響し、クラッシュ率は1.09%が同様の閾値となっている^*1。これらの指標が基準を超えるアプリはGoogle Playストアでの表示に影響が出る可能性がある。

ANRの主な原因はUIスレッド上でのネットワーク通信・ファイル入出力・重い計算処理の実行である。修正にはAndroid Studio Profiler（CPU・メモリ・ネットワークの分析）やPerfetto（システムレベルのトレース取得）を用いたボトルネック特定が必要であり、これらのツールを使いこなすには実務経験が不可欠だ。

スローレンダリング — 16ms/60fps基準を超えるジャンク

Androidにおけるスローレンダリングとは、アプリがフレームを16ms（60fps）以内に生成・表示できない状況を指す^*2。1msでも超過するとフレーム全体がドロップされ、ユーザーには画面のカクつき（ジャンク）として知覚される。700ms以上かかるフレームは「フローズンフレーム」と定義され、アプリが応答不可のように見える。

高リフレッシュレート端末（90fps・120fps）では許容時間がさらに短縮される。90fps端末では11ms、120fps端末では8msが基準となる。スローレンダリングの原因はRecyclerViewの非効率な更新処理・ネストしたレイアウト・UIスレッド上でのビットマップ操作など多岐にわたり、Systrace・Android CPU Profilerによる詳細分析が改善の前提となる^*2。

内製で対応できない理由 — 専門スキルと工数の壁

パフォーマンス改善を内製で完結させる場合、開発チームには通常の機能開発スキルに加え、プロファイリングツールの習熟・OS仕様への深い理解・継続的な計測インフラの構築が必要となる。これらを社内で整備するには技術習得コストと工数が発生し、既存の開発・運用業務と並行して対応することは容易でない。

iOS：Instruments・Xcode Organizerの活用スキル

Appleが提供するInstruments（インストゥルメンツ）は、iOSアプリのCPU・メモリ・エネルギー・ネットワーク・ディスクI/Oなどをリアルタイムで計測できるプロファイリングツールである。Xcode Organizerでは、App Storeを通じて配信された実ユーザーデバイスのパフォーマンスデータ（起動時間・ハング率・スクロールヒッチ率等）を集計・分析できる^*3。

これらのツールを使いこなすには、Swiftの深い知識・Appleのメモリ管理モデル（ARCの動作原理）・Runloop処理への理解が前提として求められる。また、2025年のWWDC25（Apple Developer Conference）では、Apple Silicon向けに新たなハードウェア支援型の最適化ツールが追加されており^*3、iOS対応の技術は継続的にアップデートされている。

Android：Macrobenchmark・Perfetto・Android Profilerの活用スキル

Androidのパフォーマンス改善には、以下の3ツールが中心的な役割を担う^*1。

• Macrobenchmark：起動時間やスクロール時のジャンクを実機で定量計測するライブラリ
• Perfetto：システムレベルのトレースを取得し、CPU・メモリ・スレッド動作を詳細分析するツール
• Android Studio Profiler：CPU・メモリ・バッテリー・ネットワーク使用量をリアルタイムで把握する統合プロファイラ

Baseline Profilesの実装にはKotlin/Javaの知識に加え、DEXレイアウト最適化・R8アプリオプティマイザー（未使用コードの除去・コード書き換えによるランタイム最適化）の理解が必要である。R8は単に不要コードを削除するだけでなく、コードを書き換えてランタイム性能を向上させる機能を持つ^*1。

内製対応のリスクと工数

パフォーマンス改善を内製のみで進める場合、次のリスクが生じる。プロファイリングの誤読による誤った改善（計測ツールを正しく使わないと、改善したように見えて本番環境では逆効果になるケースがある）。OSのメジャーアップデートによるAPIの廃止・変更への対応遅れ（iOSは年次、Androidも年次でAPIが変更される）。改善後の計測インフラが整備されなければ、リグレッション（改善後の品質劣化）の早期検出ができない。

これらに対応するには、継続的な技術キャッチアップが求められる。機能開発との並行対応が困難な場合、専門ベンダーへの外注が合理的な判断となる。

外注先の選定基準 — 実績・測定ツール・契約形態の3軸

パフォーマンス改善の外注先を選定する際は、機能開発の委託先選定と異なる視点が必要である。以下の3軸で候補ベンダーを評価することで、依頼後のトラブルを事前に防げる。

実績・技術スタック確認で見るべきポイント

パフォーマンス改善の実績確認では、「機能開発の納品実績」ではなく「計測・分析・改善の実績」を具体的に確認することが大切だ。確認すべき項目は次の通りである。

• 使用したプロファイリングツール（Instruments・Macrobenchmark等）の具体的な経験の有無
• 改善前後の計測数値を提示できるかどうか（数値ベースでの成果管理の有無）
• iOS・Android双方に対応できるか、どちらかに特化しているか
• 既存コードの解析から改善実装まで一貫対応できるか

請負か準委任か — 改善フェーズに合う契約形態

パフォーマンス改善の外注では、契約形態の選択がプロジェクト管理のしやすさに大きく関わる。

原因が特定されていない段階では準委任で調査を依頼し、改善項目が固まった後に請負へ移行する方法が、スコープを合意しやすくリスクを抑える進め方となる。

元請（プライムベンダー）に依頼するメリット

複数の下請け企業に分散して開発が行われている環境では、パフォーマンス改善の依頼先がプロジェクト全体の調整ができない立場の企業だと、改善実装が他社の担当領域と競合するリスクがある。元請（プライムベンダー）として開発全体の管理を担うIT企業に依頼することで、複数のベンダー間の調整コストを外注先が担い、発注企業の管理負荷を抑えられる。

外注の進め方 — 現状測定から改善完了まで5ステップ

パフォーマンス改善外注を効果的に進めるには、発注前の数値把握と段階的な進め方が不可欠である。以下のステップで進めることで、スコープの曖昧さによるトラブルを防げる。

ステップ1: 現状計測と課題の数値化

外注依頼前に、自社で取得できる範囲で現状を数値化する。AndroidではPlay Console内のAndroid Vitalsで、クラッシュ率・ANR率・スローレンダリング率・起動時間の現在値を確認できる^*1。iOSではApp Store ConnectのXcode Organizerデータを確認する^*3。これらのデータを外注先に提示することで、提案の精度と費用見積もりの正確性が高まる。

ステップ2: 改善スコープの定義（ROI試算）

「すべてを一度に対処する」ではなく、ユーザーへの影響度・改善工数・ビジネスへの貢献度を考慮してスコープを絞ることが大切だ。優先度が高いのは、Google PlayやApp Storeの評価に直接影響するクラッシュ率・ANR率・起動時間である。次に、ユーザー滞在時間や継続率に影響するスローレンダリングを対象とする判断が合理的である。

ステップ3: ベンダー選定とRFP作成

依頼仕様書（RFP）には、現状の数値・使用しているOSバージョン・ライブラリ・CI/CD環境・コードリポジトリのアクセス条件・希望する改善目標値・納期を記載する。複数社に同一のRFPを提示することで、提案内容と費用の比較が可能になる。

ステップ4: 改善実装とレビュー

改善実装は、計測→変更→再計測のサイクルで進める。各改善施策の前後でMacrobenchmark（Android）またはInstruments（iOS）による計測を行い、効果を数値で確認する。実装単位でPull Requestレビューを行う体制を確保することで、既存機能へのリグレッションを防ぐ。

ステップ5: 本番リリース後のモニタリング体制

改善後の効果は本番環境で継続監視しなければ維持されない。Android VitalsとXcode Organizerによる定期的な指標確認に加え、Firebase Crashlyticsなどのクラッシュレポートツールを用いたリアルタイム監視体制を外注先と合意した上で整備することが大切だ。OSのメジャーバージョンアップ（iOS・Androidともに年次）に合わせた定期的な再計測も計画に加えることが大切だ。

まとめ — パフォーマンス改善外注の3つの判断軸

本稿では、モバイルアプリのパフォーマンス改善を外注で進める方法として、指標の定義・外注可能な課題の範囲・専門スキルの必要性・ベンダー選定の3軸・5ステップの進め方を整理した。要点を3つに集約すると次の通りである。

第一に、Apple・Google公式が定めるパフォーマンス指標（ANR率0.47%・クラッシュ率1.09%・スローレンダリング16ms基準）を外注前に確認し、現状値との乖離をスコープの根拠にすることで、ベンダーへの依頼精度が高まる。第二に、Instruments・Macrobenchmark・Perfettoなどの専門ツールへの習熟が社内にない場合、外注先への依頼が改善の確実性を高める。第三に、ベンダー選定では実績の数値提示・適切な契約形態の判断・元請対応の可否の3軸で評価することが、後工程のトラブルを防ぐ基準となる。

よくある質問

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

1. *1　出典：Google「Android Vitals」（2025年）
2. *2　出典：Google「Slow rendering | App quality | Android Developers」（2025年）
3. *3　出典：Apple「Performance and metrics | Apple Developer Documentation」（2025年）
4. *4　出典：Apple「Improving app responsiveness | Apple Developer Documentation」（2025年）
5. *5　出典：Google「Best practices for app optimization | Android Developers」（2025年）

Tweet