LASSIC Media らしくメディア

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

モバイルアプリ パフォーマンス改善の外注とは — 計測から改善完了までの全体像

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

Apple・Googleが公式定義する6つのパフォーマンス指標

改善対象となる指標は、プラットフォームごとに公式定義があります。AndroidではGoogle PlayのAndroid Vitalsが4つの核心バイタルを公開しており^*1、iOSではXcode OrganizerとMetricKitが対応する指標を提供しています^*3。

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

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

ボトルネック特定に使う無料プロファイリングツール — Android・iOS・クロスプラットフォーム別

パフォーマンス改善を外注する際、事前に自社でどこまで計測できるかを把握しておくと、外注先へのRFP（依頼書）の精度が高まります。主要なプロファイリングツールをプラットフォーム別に整理します。

Android — Android Studio Profiler・Firebase Performance Monitoring・Android Vitals

Androidのパフォーマンス計測には3つのツールが中心的な役割を担います^*1。

• Android Studio Profiler：CPU・メモリ・バッテリー・ネットワーク使用量をリアルタイムで把握できる統合プロファイラ。開発環境での詳細分析に使います。
• Firebase Performance Monitoring：本番環境の実ユーザーデバイスからHTTP応答時間・画面描画トレース・カスタムトレースを収集できます。無料枠で利用可能です。
• Android Vitals（Play Console）：クラッシュ率・ANR率・スローレンダリング率・起動時間を実ユーザーデータで集計します。

Macrobenchmarkは起動時間やスクロールジャンクを実機で定量計測するライブラリで、Baseline Profiles（後述）の効果測定にも活用されます。Perfettoはシステムレベルのトレースを取得し、CPU・メモリ・スレッド動作を詳細分析できます。

iOS — Instruments・MetricKit・Xcode Organizer

Appleが提供するInstruments（インストゥルメンツ）は、iOSアプリのCPU・メモリ・エネルギー・ネットワーク・ディスクI/Oをリアルタイムで計測できるプロファイリングツールです^*3。

MetricKit（メトリックキット）はiOS 13以降で利用できるAPIで、実ユーザーデバイスのCPU時間・起動時間・ハング率・クラッシュダイアグノスティクスを取得できます^*4。Xcode Organizerは、App Storeを通じて配信された実機のパフォーマンスデータ（起動時間・ハング率・スクロールヒッチ率等）を集計・比較できます。これらのデータを外注先に渡すことで、調査フェーズの工数を削減できます。

クロスプラットフォーム — Flutter DevTools・React Native Flipper

Flutter（フラッター）アプリにはFlutter DevToolsが付属しており、Widget Rebuild Stats（ウィジェットの再描画回数）・CPU Flame Chart・メモリ使用量を確認できます。React Native（リアクトネイティブ）ではFlipperというデバッグツールが標準サポートされており、ネットワーク・レイアウト・クラッシュログを統合的に把握できます。

6領域の主な改善施策 — 起動速度から電池消費まで

パフォーマンス劣化の原因は複合的であり、各領域に対応した施策が存在します。外注先に依頼する際は、計測で特定したボトルネック領域に対応した施策実績を確認することが大切です。

起動速度 — Baseline Profileと初期化処理の遅延ロード

Androidのコールドスタート（アプリプロセスをゼロから新規生成する起動）は、ウォームスタートより処理負荷が高く、ユーザーの第一印象に直結します。Googleが推奨するBaseline Profilesは、初回起動から特定コードをAOT（事前コンパイル）でコンパイルすることで起動時間短縮を期待できる施策です^*5。

遅延ロード（Lazy Initialization）も有効で、起動時に必須でないライブラリの初期化を後回しにします。iOSではXcode OrganizerのLaunch Timeメトリクスで原因を特定し、dylib（動的ライブラリ）の削減・画像リソースの読み込みタイミング調整などを行います。

描画/スクロール — Jankフレーム削減とCompose Recomposition最適化

Androidにおけるスローレンダリングとは、アプリが1フレームを16ms（60fps基準）以内に生成・表示できない状況を指します^*2。ユーザーには画面のカクつき（ジャンク）として知覚されます。

Jetpack Compose（ジェットパックコンポーズ）を使用しているアプリでは、Recomposition（再描画）の回数過多がジャンクの原因になります。Android Studio Profilerのレイアウトインスペクタで不要な再描画を特定し、rememberやstabilityアノテーションで最適化します。iOSではCore Animation Hitches計測とInstrumentsのTime Profilerで描画ボトルネックを特定します。

メモリ — OOMクラッシュ防止とHeapリーク除去

OOM（Out Of Memory）クラッシュは、アプリが利用できるメモリ上限を超えた際に発生します。Androidでは低メモリデバイス（RAM 2GB以下）での発生頻度が高く、Firebase Crashlyticsで分類できます。ヒープ分析（Heap Dump解析）でオブジェクトの生存状況を確認し、Context参照やリスナー登録解除漏れによるメモリリークを特定して修正します。

通信 — APIレイテンシ削減とオフラインキャッシュ

HTTP通信の遅延はユーザー体感速度に直接影響します。Firebase Performance MonitoringのHTTPリクエストトレースでAPIごとの応答時間を計測し、遅いエンドポイントを特定します。改善施策としては、レスポンスキャッシュ（OkHttp・URLSession）の導入・不要なAPI呼び出しの統合・GraphQLによるover-fetchingの解消などがあります。

電池消費 — バックグラウンドCPU制限とWakeLock最適化

バックグラウンドでのCPU使用率過多や不要なWakeLock（デバイスのスリープ抑止）はバッテリー消耗の原因です。AndroidではAndroid Studioのバッテリープロファイラで電力消費を確認し、JobScheduler・WorkManagerによるバックグラウンドタスクの最適化を行います。iOSではXcode OrganizerのEnergy Logsで高消費箇所を特定し、BGTaskSchedulerを活用します。

クラッシュ・ANR — UIスレッドブロック除去とFirebase Crashlytics活用

AndroidのANR（Application Not Responding）は、UIスレッドが5秒以上ブロックされる状態です。原因の多くはUIスレッド上でのネットワーク通信・ファイルI/O・重い計算処理の実行です。Perfetto（システムレベルトレース取得ツール）でスレッドのブロック箇所を特定し、コルーチン（Kotlin Coroutines）やRxJavaを使った非同期処理に移行します。

Firebase Crashlyticsは、iOSとAndroid双方のクラッシュレポートをリアルタイムで収集・分類できます。スタックトレースと発生率を組み合わせて優先対応順を決定し、修正後の改善効果も同ツールで確認できます。

外注先に求めるスキルセットと費用の市場参考値

パフォーマンス改善の外注先を選定する際は、機能開発の委託先選定と異なる確認軸が必要です。計測・分析・最適化実装のそれぞれに対応できるスキルを持つ企業かどうかを、具体的な経験で確認します。

プロファイリング解析・改善提案（コンサルティング型）

まず「どこに問題があるか」の調査分析を先行して依頼する形態です。使用ツールの具体的な経験（Macrobenchmark・Instruments等）と、改善前後の計測値を提示した納品実績の有無を確認します。調査フェーズでは改善スコープが事前定義できないため、準委任契約（業務遂行を委託する契約形態）が適しています。

起動・描画最適化（実装型）

改善施策が決まった後の実装フェーズは、成果物（改善済みコードのPull Request・Before/Afterの計測レポート）を定義した請負契約での委託が進めやすくなります。下記は外注費用の市場参考値です。費用は委託規模・エンジニア単価・スコープによって変動し、下記は参考値であり一次資料ではありません。

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

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

LASSICのIT事業部は、iOS・Androidアプリの開発・保守を元請（プライムベンダー）として受託しており、パフォーマンス改善フェーズの計測・分析・実装を一貫して担う体制を整えています。

外注の進め方 — 計測・RFP・実装・KPI測定の5ステップ

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

ステップ1: 現状KPIの数値化（プラットフォーム公式ツールで取得）

外注依頼前に、自社で取得できる範囲で現状を数値化します。AndroidではPlay Console内のAndroid Vitalsで、クラッシュ率・ANR率・スローレンダリング率・起動時間の現在値を確認できます^*1。iOSではApp Store ConnectのXcode Organizerデータで同様の指標を把握できます^*3。

これらのデータを外注先に提示することで、提案の精度と費用見積もりの正確性が高まります。数値がない状態でのRFPは「どこを対処すべきかわからない」となり、見積もりが大きくぶれます。

ステップ2: 改善スコープと優先度の決定（影響×工数のROI試算）

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

ステップ3: RFP作成 — 外注先への依頼書に書く5項目

依頼仕様書（RFP）には以下の5項目を記載します。複数社に同一のRFPを提示することで、提案内容と費用の比較が可能になります。

1. 現状の計測値と目標KPI（例：ANR率0.47%以下・起動時間3秒以内）
2. 対象OS・バージョン・デバイスレンジ（例：Android 11以上、iOS 16以上）
3. コードベースの状態（技術的負債の程度・テストカバレッジ・CI/CD環境の有無）
4. 成果物の定義（改善レポート・コードレビュー・Pull Requestの納品形式）
5. 効果測定期間と受け入れ基準（本番リリース後X週間で指標がY以下になること）

ステップ4: 改善実装とレビュー（計測→変更→再計測サイクル）

改善実装は、計測→変更→再計測のサイクルで進めます。各改善施策の前後でMacrobenchmark（Android）またはInstruments（iOS）による計測を行い、効果を数値で確認します。

実装単位でPull Requestレビューする体制を確保することで、既存機能へのリグレッション（改善後の品質劣化）を防ぎます。リグレッションが発生すると改善した指標が再び悪化するため、自動化テストと組み合わせた継続計測が理想的です。

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

改善後の効果は本番環境で継続監視しなければ維持できません。Android Vitals・Xcode Organizerによる定期的な指標確認に加え、Firebase Crashlyticsなどのクラッシュレポートツールを用いたリアルタイム監視体制を外注先と合意して整備します。

OSのメジャーバージョンアップ（iOS・Androidともに年次）に合わせた定期的な再計測も計画に含めることが大切です。新OSリリース後2〜3ヶ月以内に再計測を行い、パフォーマンスのリグレッションがないことを確認します。

効果測定KPIの設計 — 改善後に継続追跡すべき指標

パフォーマンス改善の効果は「体感が良くなった」では管理できません。外注先との合意にもとづきKPIを設計し、改善前後と改善後の継続追跡を定量化します。

ストア評価と直結するKPI（ANR率・クラッシュ率・起動時間）

Google PlayのAndroid Vitalsは、ANR率・クラッシュ率・スローレンダリング率・起動時間をダッシュボードで表示し、同カテゴリのアプリとの比較も提供しています^*1。これらはストア評価・表示に影響する指標であり、優先的に追跡します。

iOSではApp Store Connect経由でXcode Organizerのデータを定期確認します^*3。MetricKitを実装すると、実ユーザーデバイスからのCPU時間・起動時間・ハング率をアプリ内で自動収集できます。

ユーザー体感を補完するKPI（継続率・離脱率・セッション時間）

技術指標だけでは「改善がユーザー行動に与えた影響」が見えにくいことがあります。Firebase Analytics（またはApps Flyer等の計測SDK）でセッション時間・画面遷移の離脱率・翌日継続率を計測し、パフォーマンス改善前後の変化を確認します。

App Storeのレーティング（星評価）の推移も参考指標になります。クラッシュ頻度が高い時期のレビューには「落ちる」「重い」という否定的コメントが増えやすく、対処後に評価が上向く傾向があります。

改善後の定期レポートを外注成果物に含める

外注契約の成果物として、改善前後の指標比較レポートと改善後の定期モニタリングレポート（月次・四半期）を含めることを契約時に合意します。レポート形式と頻度を明示することで、改善効果の可視化と継続改善の議論材料を確保できます。

改善後に指標が目標に達しなかった場合の対応方針（追加改善の工数・費用）も事前に合意しておくことで、プロジェクト完了後のトラブルを防げます。

まとめ — 計測・施策・KPIの3軸で外注を成果につなげる

本稿では、モバイルアプリのパフォーマンス改善を外注で進める方法として、指標の定義・プロファイリングツール・6領域の改善施策・外注先のスキルと費用感・5ステップの進め方・KPI設計を整理しました。要点を3つに集約すると次の通りです。

第一に、Google/Apple公式が定めるパフォーマンス指標（ANR率0.47%・クラッシュ率1.09%・スローレンダリング16ms基準）を外注前にAndroid Vitals・Xcode Organizerで確認し、現状値との乖離をスコープの根拠にすると、外注先への依頼精度が高まります。

第二に、プロファイリングツール（Instruments・Macrobenchmark・Perfetto・Flutter DevTools等）への習熟が社内にない場合は、調査フェーズを準委任契約で外注することで改善の確実性を高められます。

第三に、改善効果はANR率・クラッシュ率・起動時間をKPIとして設計し、継続追跡することで投資対効果を可視化できます。OSの年次アップデートに合わせた定期再計測も計画に含めることが長期的な品質維持につながります。

よくある質問

パフォーマンス改善の外注費用はどのくらいが目安ですか？

外注費用は改善対象（iOS・Android・両対応）・計測と改善の範囲・エンジニアの稼働規模によって異なります。調査・計測フェーズと改善実装フェーズを分けて見積もりを取ることが費用を正確に把握する方法です。本記事の費用参考値（市場参考・一次資料なし）では、プロファイリング調査が30万〜80万円程度、複合最適化で150万〜400万円程度が目安です。スコープが広い場合は準委任契約での月額見積もりが一般的です。

改善完了までどれくらいの期間がかかりますか？

改善期間は課題の複雑さとスコープによって異なります。クラッシュ原因が特定済みで修正実装のみであれば短期間で完了することもあります。パフォーマンス全体の計測・原因特定・複数箇所の改善・検証を含む場合は、数週間から数ヶ月規模のプロジェクトになります。依頼前にAndroid Vitalsまたは Xcode Organizerで現状の数値を整理し、改善対象を絞ることで期間と費用を見通しやすくなります^*1。

起動時間の改善だけを部分的に依頼できますか？

起動時間の改善のみを対象とした部分的な委託は可能です。ただし、起動時間の遅延はアプリ全体の初期化処理と密接に関わるため、外注先は既存コードベース全体を調査した上で改善箇所を特定する必要があります。Googleが推奨するBaseline Profilesの実装は既存コードへの影響が比較的限定的な改善施策として位置づけられており、スコープを絞りやすいと言われています^*5。

外注後の運用保守は別途契約が必要ですか？

改善実装後の継続監視・OSアップデート対応・リグレッション検出は、改善実装とは別のフェーズとして扱われることが多いです。Android・iOSともに年次でOSメジャーアップデートがあり、その都度パフォーマンスへの影響を再確認する必要があります。運用保守まで一括して依頼するか、改善フェーズ完了後に別途契約するかは、プロジェクト開始前に外注先と合意しておくことが大切です。

ソースコードを外注先に渡すセキュリティリスクはどう対処すればよいですか？

ソースコードの開示を伴う外注では、NDA（秘密保持契約）の締結と、アクセス権限を最小限に絞ったリポジトリ管理が基本的な対処法です。元請（プライムベンダー）として責任を持つ企業に依頼することで、下請けへのコード開示範囲の管理も委託先が担う体制を構築できます。コードの問題箇所のみを共有する方法で対応できるケースもあるため、初回相談時にアクセス範囲を明確にすることをお勧めします。

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

---

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

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年）