LASSIC Media らしくメディア

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

サードパーティSDKとは — アプリ開発における役割と増える理由

サードパーティSDK（Software Development Kit）とは、アプリ開発者が自前では実装しにくい機能——分析・広告・ログ収集・決済・地図・プッシュ通知など——を外部ベンダーが提供するライブラリとして組み込める開発キットです。iOS・Android開発では、機能追加のたびに適切なSDKを選んで導入するのが一般的な進め方になっています。

SDKが増える主な理由は3点あります。第一に、機能追加のたびに「専用SDKを入れれば早い」という判断が積み重なること。第二に、過去に導入したSDKが現在は使われていないのに削除されずに残ること。第三に、担当者の交代でSDKの導入経緯が引き継がれず、棚卸しの機会が失われることです。

こうした事情から、リリース後に時間が経過したアプリほど、実際には使われていないSDKが複数残った状態になりやすいという実態があります。

SDK肥大化が生む4つの問題：サイズ・性能・プライバシー・審査負担

サードパーティSDKの増加は、アプリに4つの問題をもたらします。それぞれの問題を具体的に整理します。

アプリサイズとメソッド数の増大

SDKを追加するたびにアプリのバイナリサイズは大きくなります。Androidではメソッド数が増えることでDexファイルの上限（Multidex制約）に達するケースもあります。アプリサイズが大きくなるほどストアからのダウンロード完了率が下がる傾向があり、特にモバイル回線での初回インストール時に影響が出ます。

Androidでは配布形式としてAAB（Android App Bundle）^*2が推奨されており、端末ごとに必要なリソースだけを配信することでダウンロードサイズを絞る工夫が可能です。ただしAABを使ってもSDK自体のコードは削減されないため、不要なSDKの除去が根本的な対処になります。

起動時間と実行性能の劣化

SDKの多くはアプリ起動時に初期化処理を実行します。初期化するSDKが増えるほど、ユーザーが最初の画面を目にするまでの時間が長くなります。バックグラウンド処理を持つSDKは、実行中のCPU・メモリ使用量にも影響します。性能の問題は直接的にユーザーの離脱率や評価に響きます。

プライバシーリスク：データ収集の不透明さ

サードパーティSDKはベンダー側のサーバーにデータを送信するものが少なくありません。どのSDKが何のデータをどの頻度で収集しているかを把握していないと、ユーザーへのプライバシー開示が不十分になります。SDKベンダーのプライバシーポリシーが変更された場合、アプリ開発者が気づかないうちにデータ収集の範囲が変わることもあります。

ストア審査対応の負担増

AppleはiOS 17以降、プライバシーに関わるSDKを含むアプリにPrivacy Manifest（プライバシーマニフェスト）^*1の提出を求めています。利用するAPIや収集データの種類・目的を申告する仕組みで、申告漏れがあると審査で差し戻されます。Google PlayのData safetyセクションも同様に、収集・共有するデータの種類を開発者が申告する制度になっています。SDKが多いほど申告内容の把握と更新に手間がかかり、審査対応の負担が増します。

SDK棚卸しの5ステップ：一覧化から継続監視まで

SDK棚卸しは一度で終わる作業ではなく、定期的に回すプロセスとして設計することが大切です。以下の5ステップを順に進めます。

ステップ1：使用中SDKの一覧化

まずアプリに組み込まれているSDKをすべてリストアップします。iOSであればPodfileやPackage.swift、AndroidであればbuildSrc/build.gradleの依存関係定義が出発点になります。直接依存に加えて、SDKが内包する間接依存（推移的依存）も含めて把握することが大切です。ライセンス管理ツール（OSS Review Toolkitなど）を活用すると一覧化の精度が上がります。

ステップ2：各SDKの用途・収集データ・更新状況の確認

一覧化したSDKそれぞれについて、①何のために導入したか、②どのようなデータを収集・送信するか、③最後に更新されたのはいつかを確認します。SDKベンダーの公式ドキュメントやPrivacy Policyを参照し、収集データをスプレッドシートなどで整理します。更新が長期間止まっているSDKは、脆弱性が放置されているリスクがあります。

ステップ3：重複・不要SDKの特定

用途が重複しているSDKが複数存在する場合は統合の候補になります。例えば分析ツールが2種類入っていて実際に使っているのは1種類だけ、というケースは実務上よく見られます。また機能追加の際に導入したSDKが、その後の仕様変更でまったく呼び出されていないケースも確認します。

ステップ4：削除・代替の実施

不要と判断したSDKを削除し、代替が必要な場合は軽量なSDKや自前実装に切り替えます。削除後は後述する回帰テストを経てリリースします。この工程はアプリのコードへの変更を伴うため、十分なテスト期間を確保することが欠かせません。

ステップ5：継続的な監視の仕組みを整える

棚卸しは一度実施したら終わりではありません。新しい機能追加のたびにSDKが増えやすいため、四半期ごとや機能リリースのタイミングで定期的に棚卸しを回す運用を設計します。SDKベンダーのリリースノートやプライバシーポリシーの変更を追跡する仕組みも合わせて整えます。

削除・代替の判断基準：用途・収集データ・更新頻度で優先度をつける

すべてのSDKを一度に削除・代替するのは現実的ではありません。優先度をつけるための判断基準を整理します。

削除を優先すべきSDKの特徴

次のいずれかに該当するSDKは削除の優先度が高いといえます。

• コードベースで呼び出し箇所が存在しない（デッドコード状態）
• 同等の機能を提供するSDKが別途存在し重複している
• 更新が1年以上止まっており、OSの新バージョンへの対応が不明
• SDK導入時の担当者がすでに不在で、導入目的が不明なまま残っている

代替を検討すべきSDKの特徴

機能としては必要だが現在のSDKに課題がある場合は、代替を検討します。主な検討トリガーは次の通りです。

• 収集データの範囲が広く、Privacy Manifestへの申告が煩雑になっている
• SDKのサイズが大きく、軽量な代替選択肢がすでに存在する
• 同等の機能をOSが標準APIとして提供するようになった

自前実装が有効なケース

シンプルな機能であれば、SDKに頼らず自前で実装する選択肢もあります。例えばイベント送信の仕組みが数十行で実装できる場合、SDKを入れるよりも収集データの範囲を自社でコントロールしやすくなります。ただし自前実装は保守コストを伴うため、機能の複雑さと保守体制を踏まえて判断することが大切です。

iOS Privacy ManifestとGoogle Play Data safetyへの対応

2024年以降、iOSとAndroidのストア審査ではプライバシーに関連するデータ収集の申告が求められるようになっています。SDK棚卸しはこれらの対応とも直結します。

iOS Privacy Manifest（プライバシーマニフェスト）

AppleはiOS 17より、プライバシーに影響するAPIを使用するアプリに対してPrivacy Manifest（プライバシーマニフェストファイル）^*1の提出を義務化しました。このファイルには、アプリが使用するAPIの種類と使用目的のカテゴリを申告します。サードパーティSDKが対象APIを呼び出している場合、SDKのベンダーが提供するPrivacy Manifestと自社のアプリ全体のPrivacy Manifestの両方が必要です。

SDK棚卸しを行い、どのSDKがどのAPIを使っているかを把握しておくことで、Privacy Manifestの申告内容を正確に作成できます。棚卸しが不十分なまま申告すると申告漏れが発生し、審査で差し戻されるリスクがあります。

Google Play Data safetyセクション

Google Playでは、アプリがユーザーから収集・共有するデータの種類をData safetyセクションとして開示することが求められています。サードパーティSDKが収集するデータもアプリ開発者が申告する必要があります。SDK棚卸しで収集データを把握していないと、申告内容の正確性を担保できません。SDKベンダーがData safetyの申告に必要な情報を公開しているかどうかも、SDK選定の基準のひとつになります。

外注でSDK棚卸しを進める進め方と発注時の確認事項

SDK棚卸しはコードベースの解析・依存関係の調査・プライバシーポリシーの確認など、専門知識を要する作業です。社内のモバイルエンジニアリソースが不足している場合や、プライバシー開示対応を含めて一括で依頼したい場合は外注という選択肢があります。

外注前に準備しておくこと

外注を始める前に、発注側で以下の情報を整理しておくと見積もりの精度が上がり、作業範囲の認識ずれを防げます。

• 対象アプリのプラットフォーム（iOS / Android / 両方）とバージョン
• 現状把握しているSDKの数と大まかな種別（分析・広告・ログ・決済など）
• Privacy ManifestやData safetyへの対応が審査対応の期限として設定されているか
• 削除後の回帰テストをどこまで外注先に任せるか

発注時に確認すべきこと

外注先に確認すべきポイントは主に3点です。第一に、iOS・Androidのモバイルアプリ開発の実績があり、依存関係解析やプライバシー開示対応の経験があるか。第二に、SDK削除後の回帰テストが納品物のスコープに含まれているか。第三に、棚卸し結果をドキュメントとして納品してもらえるか（将来の運用引き継ぎのため）です。

内製と外注の比較：スキル要件・工数・リスクの違い

SDK棚卸しを内製で進めるか外注するかは、自社のモバイルエンジニアの経験・チームのリソース状況・プライバシー対応の期限によって判断が変わります。以下の比較表を参考にしてください。

内製を選ぶ場合でも、Privacy Manifestの申告内容の確認だけを専門知識を持つ外部パートナーに依頼するという進め方が、品質とコストのバランスを取りやすい場合があります。

注意点：機能影響の確認と回帰テストの設計

SDK棚卸しはアプリのコードに直接変更を加える作業です。削除したSDKが予期しない箇所で使われていた場合、機能が正常に動作しなくなるリスクがあります。特に以下の点に注意が必要です。

削除前の呼び出し箇所の全数確認

SDKを削除する前に、コードベース内の呼び出し箇所をすべて特定します。直接のメソッド呼び出しだけでなく、設定ファイル・初期化処理・アナリティクスのイベント送信部分なども確認対象です。特定が不十分なまま削除するとビルドエラーや実行時クラッシュにつながります。

回帰テストのスコープ設計

SDK削除後は回帰テストを実施します。テストのスコープは「削除したSDKと直接・間接に関係する機能」を中心に設計します。また削除前後でアプリサイズや起動時間を計測し、変化を記録しておくと今後の比較に役立ちます。

テスト対象の端末・OSバージョンは、ユーザーのセッションデータを参照して実際の利用状況に合わせて選定することが大切です。古いOSバージョンでのみ発生する挙動の変化を見落とさないよう、対象範囲を広めに設定します。

ストア申請前のプライバシー申告内容の再確認

SDK削除後は、iOS Privacy ManifestとGoogle Play Data safetyの申告内容もあわせて更新します。削除したSDKが申告していたデータ収集項目を、更新後のアプリでは申告不要になる場合があります。申告内容が実際の収集データと一致しているかを確認してからストア申請を行うことで、審査での差し戻しリスクを抑えられます。

まとめ：SDK棚卸しを成功させる3つの判断軸

本稿ではサードパーティSDKが増える背景からはじまり、SDK肥大化が生む問題・棚卸しの手順・削除の判断基準・プライバシー開示対応・外注の進め方・回帰テストの注意点までを整理しました。要点を3つに集約します。

第一に、SDK棚卸しは「使用中SDKの一覧化→用途・収集データの確認→削除・代替→回帰テスト→継続監視」の5ステップで進めることです。一覧化を省略して削除に踏み込むと、意図しない機能影響が発生するリスクが高まります。

第二に、iOS Privacy ManifestとGoogle Play Data safetyへの正確な申告は、SDK棚卸しの副産物として得られるという視点です。収集データを把握するプロセスが整うと、審査対応の負担も体系的に減らせます。

第三に、外注を活用する場合はスコープ・期待値・回帰テストの条件を要件定義段階で合意しておくことが、手戻りのない進め方の土台になります。社内リソースと対応期限を照らし合わせて、内製・外注のどちらが実情に合うかを判断してください。

よくある質問

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

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

1. *1　出典：Apple「Privacy manifest files — Apple Developer Documentation」
2. *2　出典：Android Developers「Android App Bundle — Android Developers」

Tweet