LASSIC Media らしくメディア
Androidの16KB移行、ネイティブ対応を外注で解決
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Android 16KBページサイズ対応は、Google Playの新規・更新アプリに適用される要件です。
- 対象になるのはネイティブコード（.so/NDK/JNI）やサードパーティSDKを含むアプリです。
- 再ビルド・検証には専門知識と工数がかかるため、外注の判断軸を整理します。
目次
Android 16KBページサイズ対応とは何か
Android 16KBページサイズ対応とは、Androidアプリのネイティブコード（.soファイル等）を、従来の4KB単位ではなく16KB単位のメモリページに整列させて動作可能にする対応を指します*1。Android Developers公式ドキュメントによると、AGP（Android Gradle Plugin）8.5.1以上・NDK r28以上を使えば既定で16KB対応になり、古いバージョンではリンカーフラグの追加や再ビルドが必要になります*1。
Androidの16KBページサイズ対応とは、CPUがメモリを管理する最小単位（ページサイズ）が16KBのデバイス上でも、ネイティブコードを含むアプリが正常に動作するようにする技術対応です。従来Androidは4KBページサイズを前提に設計されてきましたが、メモリ容量の大きい端末が増えるにつれ、より大きなページサイズを採用するデバイスが登場しています*1。ページサイズが変わると、4KB単位を前提にビルドされたネイティブライブラリの一部が正しく読み込めなくなる可能性があります。
NDK（Native Development Kit、Android用C/C++開発キット）やJNI（Java Native Interface、JavaとC/C++を橋渡しする仕組み）を使ったアプリは、この整列（アライメント）を満たすように再ビルド・再検証する必要があります。Java/Kotlinのみで実装されたアプリは対象外ですが、依存しているSDKにネイティブライブラリが含まれる場合は間接的に影響を受けます*1。
2025年11月開始のGoogle Play要件と対象時期
Android Developers Blogによると、Google Playは2025年11月1日以降に提出される新規アプリおよび既存アプリの更新について、Android 15（APIレベル35）以上をターゲットとする場合に16KBページサイズ対応を要件化しています*2。対象はネイティブコードを含むアプリに限られ、要件を満たさない場合は審査・配信の段階で影響が生じる可能性があります。
この適用範囲や猶予の扱いについては、Google Play Console側の告知やポリシーに沿って随時更新される可能性があります。したがって、自社アプリの対象可否や最新の適用条件は、Play Console内の告知および開発者向け公式ドキュメントで都度確認することが欠かせません*1。期日の解釈を誤ると審査通過後の対応が後手に回るため、社内のリリース計画に組み込む際は保守的な前倒しスケジュールを検討する必要があります。
対応の要否は、アプリがネイティブコードを直接持つか、依存ライブラリ経由で間接的に持つかで変わります。次の章で対象範囲を具体的に整理します。
.so・NDK・JNI・サードパーティSDK — 対応が必要な3領域
16KBページサイズ対応の要否は、アプリ内のネイティブ資産の所在によって3つの領域に分けて検討すると判断しやすくなります。
自社で開発した.soライブラリ
C/C++で書いた処理をNDK経由でビルドし、JNIでKotlin/Javaから呼び出している場合は、自社ビルド環境の更新が起点になります。AGP 8.5.1以上・NDK r28以上を使えば既定で16KB整列に対応しますが、古いバージョンで運用している場合はリンカーフラグ（-Wl,-z,max-page-size=16384等）の追加が必要です*1。
サードパーティ製ネイティブライブラリ
広告SDK・分析SDK・決済SDK・画像処理ライブラリなど、外部提供のライブラリに.soファイルが含まれるケースです。この領域は自社のビルド設定だけでは解決できず、SDK提供元が16KB対応版を配布しているかどうかに左右されます。対応版が未提供の場合、SDKの差し替えや提供元への問い合わせが必要になります。
ハードコードされたページサイズ前提のコード
C/C++のソースコード内で「PAGE_SIZE」や「4096」を直接書いている箇所は、実行時のページサイズと食い違う原因になります。Android Developers公式ドキュメントは、こうした値をgetpagesizeやsysconf(_SC_PAGESIZE)による動的取得に置き換えるよう推奨しています*1。
3領域とも、対応の有無を確認する第一歩はAPK Analyzer等によるネイティブライブラリの棚卸しです。次章で確認方法とリスクを具体的に見ていきます。
未対応で生じるリスクと確認方法
16KBページサイズ未対応のまま放置すると、審査提出時の指摘対応に追われるだけでなく、16KBページサイズを採用したデバイス上でアプリがクラッシュしたり、想定通りに起動しなかったりする恐れがあります。ネイティブ処理が多いアプリほど影響範囲の特定に時間がかかり、リリーススケジュールへの影響が大きくなりやすい点に注意が必要です。
確認方法として、Android Studioの「Build > Analyze APK」でlibフォルダ内の.soファイルを開き、Alignment列の警告有無をチェックする方法があります*1。加えて、check_elf_alignment.shスクリプトでAPK全体を一括検証する方法や、llvm-objdumpでELFセグメントのアライメント値を直接確認する方法も公式ドキュメントで案内されています*1。
実機検証には、Android 15 QPR1以降を搭載する一部のPixel端末で「Boot with 16KB page size」を有効化する方法や、SDK Managerから取得できる16KB対応の実験的システムイメージをエミュレータに導入する方法があります*1。自社の対応要否・対応範囲・検証環境の構築を一つずつ潰していく作業は、ネイティブ開発の知見がない体制では負荷が大きくなりがちです。
再ビルドから申請までの実務フロー
対応範囲を特定した後は、ビルド環境の更新・再ビルド・検証・Google Play申請という流れで進めます。まずAGPとNDKのバージョンを最新化し、既定の16KB対応を有効にできるかを確認します*1。古いツールチェーンから移行する場合は、依存ライブラリの互換性検証もあわせて必要になります。
次に、サードパーティSDKごとに16KB対応版の提供状況を洗い出します。対応版がある場合はバージョンアップ、ない場合は代替SDKの検討や提供元への確認が発生します。すべてのネイティブ資産が整列済みになったら、APK Analyzerやzipalignコマンドで最終確認を行い*1、実機・エミュレータの16KB環境でクラッシュや異常動作がないかをテストします。
この一連の作業を誤ると、Google Playの審査で差し戻しを受けたり、対応済みと誤認したまま16KB環境でのみ発生する不具合を見落としたりするリスクがあります。ビルド設定の変更・SDK差し替え・実機検証には、NDK/JNIの知識に加えてAndroidのビルドシステム全般の理解が求められます。
内製と外注の分岐点 — 必要スキルと工数
16KBページサイズ対応を内製で行う場合、NDK/JNIによるネイティブ開発の経験、AGPのビルド設定知識、ELFバイナリのアライメント検証スキル、そして依存SDKの棚卸しと調整を行う体制が必要になります。ネイティブコードを自社で書いていないアプリであっても、依存SDKの対応状況調査やビルド環境の更新作業自体は避けられません。
社内にAndroidネイティブ開発の担当者が不在、または他の開発案件と兼務で手が回らない場合は、対応の優先順位が下がり、申請直前に慌てて着手する事態になりかねません。外部の専門パートナーに委託する場合は、ネイティブライブラリの棚卸し・再ビルド・実機検証・申請対応までを一括して依頼できるかが選定のポイントになります。
内製と外注を比較すると、内製は既存の開発体制をそのまま活用できる一方、NDK/JNI経験者の確保がボトルネックになりやすい傾向があります。外注は専門知識を持つ体制に短期間で対応を任せられる一方、アプリの仕様理解やコミュニケーションコストが発生します。自社アプリのネイティブ依存度と社内のリソース状況を踏まえて判断することが欠かせません。
| 比較軸 | 内製で対応する場合 | 外注で対応する場合 |
|---|---|---|
| 必要な専門知識 | NDK/JNI・ビルド設定・ELF検証の知識が必要です。 | 委託先が専門知識を持つ体制であることの確認が必要です。 |
| 対応スピード | 担当者のアサイン状況に左右されます。 | 専門体制のため着手までの調整期間を短縮しやすいです。 |
| リスク管理 | 見落とし箇所を自社で洗い出す必要があります。 | 棚卸しから検証まで一括で依頼できる場合があります。 |
まとめ：16KBページサイズ対応で押さえる3つの判断軸
本稿ではAndroidの16KBページサイズ対応について、Google Playの適用要件・対象範囲・実務フローを整理しました。要点は3つに集約できます。第一に、対応対象になるのはネイティブコード（.so/NDK/JNI）やサードパーティSDKを含むアプリであり、Java/Kotlinのみのアプリは対象外です。第二に、適用時期や猶予の扱いは変更される可能性があるため、Play Consoleと公式ドキュメントでの継続的な確認が欠かせません。第三に、再ビルドから実機検証までの作業には専門知識と工数が必要であり、社内リソースとの兼ね合いで外注の選択肢を検討する価値があります。
よくある質問
自社アプリがネイティブコードを含むかどうか、どう確認すればよいですか。
Android Studioの「Build > Analyze APK」でAPKを開き、libフォルダ内に.soファイルが存在するかを確認する方法があります*1。.soファイルが見当たらない場合は、依存しているSDKの提供元にネイティブライブラリの有無を確認することをおすすめします。
Java/Kotlinのみのアプリでも対応が必要になりますか。
Android Developers公式ドキュメントによれば、ネイティブコードを含まないJava/Kotlinのみのアプリは16KBページサイズ対応の対象外とされています*1。ただし依存SDKにネイティブライブラリが含まれる場合は間接的に影響を受けるため、依存関係の確認が必要です。
対応にかかる期間はどれくらいを見込めばよいですか。
ネイティブライブラリの数・依存SDKの対応状況・検証環境の構築状況によって必要な期間は変わります。公表された標準的な所要期間の統計はないため、自社アプリの棚卸し結果をもとに個別に見積もる必要があります*1。
外注する場合、どのような範囲を依頼できますか。
ネイティブライブラリの棚卸し、ビルド環境（AGP/NDK）の更新、サードパーティSDKの対応状況調査、実機・エミュレータでの検証、Google Play申請対応までを一括で依頼できるケースがあります。委託先の対応範囲は契約時に個別確認が必要です。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Android Developers「Support 16 KB page sizes」（https://developer.android.com/guide/practices/page-sizes）
- *2 出典：Android Developers Blog「Prepare your apps for Google Play’s 16 KB page size compatibility requirement」（2025年）（https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html）
