APKとAABの違い：新しいAndroidアプリの配布形式を解説
APKとは何か（そしてなぜ15年間もAndroidの主流だったのか）
15年間、Android Package Kit、つまりAPKが唯一の選択肢でした。2008年にプラットフォームが登場して以来、Androidアプリの標準であり続けてきました。APKは実のところ、非常に特殊な内部構造を持つ単なるZIPアーカイブです。コンパイル済みのAndroidManifest.xml、DEXバイトコード（classes.dex）、resources.arscテーブル、そしてアセット、ネイティブライブラリ、その他の生リソース用のフォルダが格納されています。ウェブサイトからアプリを入手したり、Bluetoothで友達に送ったりするとき、あなたはあらゆるAndroidデバイスで実行するために必要なすべてが含まれた単一の.apkファイルを送信しているのです。 この「ワンサイズ・フィットオール」（すべてに対応する単一パッケージ）というアプローチは、APKの最大の強みであり、同時に致命的な欠点でもあります。Google Playストアから提供される単一のAPKは、64ビットARMチップを搭載したSamsung Galaxy S25 Ultraから、32ビットARMチップの安価なTecno製スマートフォン、さらにはx86プロセッサのChromebookや、考えられるすべての画面密度まで、すべてをサポートしなければなりませんでした。これを実現するために、開発者はネイティブライブラリ、翻訳された文字列、画面密度ごとの画像の全バージョンを、一つの巨大なパッケージに詰め込む必要がありました。その結果、Googleマップのようなアプリは、あなたのデバイスが必要とするのはそのうちの約40MBだけなのに、100MBものAPKを配信することになっていました。残りはただの「お荷物」で、ダウンロードされてストレージを占有するだけで、決して使われることはありませんでした。
Android App Bundle：2018年の変更点とGoogleが義務化した理由
Googleはついに、Google I/O 2018でAndroid App Bundle（AAB）を発表し、APKの肥大化問題に対処しました。そして2021年8月には、Playストアの新規アプリでAABが必須となりました。.aabという拡張子を持ち、これもZIPアーカイブではありますが、インストール可能なアプリではありません。完成したケーキではなく、レシピと材料の箱だと考えてください。AABにはコンパイル済みのコードとリソースがモジュール単位で含まれていますが、最終的な組み立てはGoogle Playのサーバーが行います。 このプロセスは「Dynamic Delivery」（動的配信）と呼ばれます。ユーザーがPlayストアで「インストール」をタップすると、Googleのサーバーはそのユーザーの特定のデバイス、つまりCPUアーキテクチャ（ABI）、画面密度、言語設定を確認します。そして、そのデバイスに本当に必要なものだけを含む、カスタマイズされた分割APK（split APK）のセットをビルドして配信します。例えば、Android 15を英語環境で実行しているPixel 9なら38MBのダウンロードで済むかもしれませんが、古いモノリシックなAPKでは95MBものサイズになっていたでしょう。 このサイズ削減は理論上のものではなく、顕著で測定可能な効果があります。Google自身の2021年のデータによると、AABに切り替えたアプリは平均で15%のサイズ削減を実現し、中には50%以上もサイズを削減したアプリもありました。異なるGPU圧縮フォーマット（ETC2、ASTC、S3TCなど）向けに設計された巨大なテクスチャアトラスを持つゲームの場合、その節約効果は天文学的なものになり、ユーザーのスマートフォンへの最終的なインストールサイズから数百メガバイトを簡単に削減できます。
AABファイルの内部構造
AABファイルをZIPユーティリティで開いてみると、それがAPKではないことがすぐにわかります。トップレベルには、バンドルの設定を定義する`BundleConfig.pb`ファイル、`BUNDLE-METADATA`ディレクトリ、そして少なくとも1つのモジュールディレクトリがあります。メインモジュールは常に`base/`と呼ばれ、その内部は`dex/`、`manifest/`、`res/`、`root/`、`lib/`といったフォルダがあり、少しAPKに似ています。しかし、決定的な違いがあります。リソースがAPKのフラットなバイナリ形式の`resources.arsc`ではなく、`resources.pb`というproto形式で保存されている点です。これが、AABを直接インストールできない主な理由です。 `base/`モジュールと並んで、`onboarding/`や`ar_features/`といった名前の他の機能モジュールが存在します。それぞれが独自のmanifestとリソースを持ち、インストール時にダウンロードするか、インストールの直後（fast-follow）にダウンロードするか、あるいは必要なときだけダウンロードするかを設定できます。このオンデマンドモデルによって、Google Earthのようなアプリは、すべてのユーザーに3D都市データの負担をかけることなく、実際にその機能が提供されている都市を見ようとしたときにだけ、Play Coreライブラリ経由でデータを取得することができるのです。 各モジュール内の`lib/`ディレクトリこそ、サイズ削減の真価が発揮される場所です。クロスプラットフォームのゲームには、`arm64-v8a`、`armeabi-v7a`、`x86_64`といったサブディレクトリが含まれ、それぞれにコンパイル済みの.soライブラリが詰まっているかもしれません。モノリシックなAPKなら、これらすべてをバンドルします。AABを使えば、Dynamic Deliveryが一致するABIのディレクトリ一つだけを送信することを保証します。ABIあたり80MBのネイティブコードを持つゲームの場合、32ビットやx86のライブラリを必要としない最新の64ビットスマートフォンでは、瞬時に160MBも節約できることになります。
APK対AAB：開発者にとって重要な項目の直接比較
では、これらの違いは開発者、QA、そしてユーザーにとって、実際には何を意味するのでしょうか？日々の業務で実際に重要となる点で比較をしてみましょう。 **配布チャネルのサポート：** Google Playは新規アプリにAABを要求します。話は単純です。しかし、AABはGoogle独自の技術です。Amazon Appstore、Samsung Galaxy Store、Huawei AppGallery、F-Droidといった代替のAndroidアプリストアは、すべて昔ながらのAPKを要求します。Google Play以外でアプリを配布する場合、依然としてAPKを扱う必要があります。これは、特にGoogle Playが利用できず、APKのみでの配布が標準となっている市場では、些細なことではありません。 **直接インストール：** AABをサイドロードすることはできません。`adb install app.aab`でインストールしようとしても、エラーが表示されるだけです。AABをローカルでテストするには、Googleの`bundletool`を使ってローカル用のAPKセットを生成するか、ビルド時に`--local-testing`フラグを使用する必要があります。技術に詳しくないステークホルダーにビルドをテストしてもらったことがある人なら誰でも、余計な手順が増えることがフラストレーションの原因になることを知っています。これは間違いなくQAのワークフローに摩擦を生じさせます。 **ビルドツール：** Android Studioでは、「Build > Generate Signed Bundle/APK > Android App Bundle」を選択するか、`./gradlew bundleRelease`タスクを実行してAABを作成します。APKは`./gradlew assembleRelease`でビルドします。ほとんどのチームは両方を使用し、内部テスト用にAPKを、最終的なPlayストアへのアップロード用にAABをビルドしています。 **ディスク上のファイルサイズ：** ここがよくある誤解のポイントです。あなたのAABファイルは、ほとんどの場合、APKよりも大きくなります。60MBのAPKが80MBのAABを生成することがあるのは、AABが*すべて*のデバイス構成用のリソースを含んでいるからです。サイズ削減の効果は、Google Playがその「魔法」をかけた後、ユーザーのデバイス上でのみ現れます。 **セキュリティモデル：** どちらのフォーマットも署名されますが、プロセスが異なります。AABでは、「Play App Signing」を使う必要があります。これは、あなたがバンドルをアップロードし、Googleが生成する最終的な分割APKに、Googleが管理する鍵で再署名することを意味します。あなたはこの鍵を登録しますが、最終的に鍵を保持するのはGoogleであり、この事実はセキュリティを重視するチームを不安にさせる要因です。APKの場合は、Googleの関与なしに、あなた自身の鍵で署名プロセス全体を管理できます。
APKとAABの相互変換：可能なことと不可能なこと
ここは、マーケティングの約束よりも正直な答えが重要になる部分です。はっきり言いましょう。既存のAPKをAABに変換し直す、などということは現実的ではありません。そして、自動でできると謳うツールは、深く疑ってかかるべきです。 問題は根本的なものです。AABには、元のソース情報、つまり画面密度や言語ごとにきちんと整理されたリソースファイル、proto形式のリソーステーブル、モジュール構造などが必要です。APKが作成される際に、それらのデータはすべてコンパイルされ、フラット化され、最適化されて失われてしまいます。APK内の`resources.arsc`ファイルはバイナリの塊であり、元の`res/drawable-hdpi/`のようなフォルダ構造は消えています。コンパイル済みのAPKからそれを再構築しようとするのは、変換ではなく、骨の折れるリバースエンジニアリングのプロセスであり、その結果はほとんどの場合不完全です。 CocoConvertは、APKからAPKへの操作のために作られています。APKの再パッケージ化、名前の変更、そして最も便利なのは、検査のためにAPKのコンテンツを抽出することです。APKをアップロードすれば、そのmanifestを取り出したり、リソーステーブルを確認したり、特定のアセットを取得したりできます。しかし、CocoConvertができないのは、APKから有効でPlayストアに対応したAABを生成することです。率直に言って、元のソースコードプロジェクトがなければ、どのツールもこれを確実に行うことはできません。 もしソースを失い、APKしか持っていないのであれば、最善の策は`apktool`のようなツールを使うことです。これはパッケージをsmaliバイトコードに逆コンパイルし、リソースの近似値を提供してくれますが、それをAABにビルドできる適切なプロジェクトに戻すには、膨大な手作業が必要です。 CocoConvertが*本当に*役立つのは、モバイルQAやセキュリティリサーチで頻繁に発生するタスクです。APKをZIPファイルに変換してコンテンツを閲覧したり、特定の画像や音声ファイルを抽出したり、さらにはフォルダ全体のAPKをバッチ処理して監査したりすることもできます。これらが、私たちが手助けできる実践的で現実的な作業です。
サイドロードの問題と、APKがなくならない理由
GoogleがAABを大々的に推進しているにもかかわらず、地味ながらもAPKがどこかへ消え去ることはありません。その耐久性は、Googleの管理外に存在するあらゆるユースケースから来ています。サイドロード、つまりPlayストア以外からAPKをインストールすることは、Androidのコア機能であり、スマートフォンの設定を少し変更するだけで有効にできます（通常は「設定 > アプリ > 特別なアプリアクセス > 不明なアプリのインストール」にありますが、パスは機種によって異なります）。 そして、サイドロードのエコシステムは巨大です。APKMirrorはPlayストアアプリの検証済みAPKをホストしており、ユーザーは段階的なロールアウトが自分に届く前にアップデートを入手したり、古いバージョンをインストールしたりできます。VMwareやMicrosoftのエンタープライズモバイルデバイス管理（MDM）ツールは、Playストアを一切経由せずに、何千もの企業デバイスにAPKをプッシュします。ゲームの改造コミュニティは、改造されたAPKで成り立っています。Playストアへのアクセスが制限されている地域の開発者にとって、APKの共有が主要な配布方法です。 これらのユーザーにとって、AABはまったく無関係です。それはGoogleの「壁に囲まれた庭」（walled garden）の中でしか生きられないフォーマットなのです。アプリがそのエコシステムの外で共有、展開、またはインストールされる必要がある瞬間、それはAPKでなければなりません。 これは新しい規制によってさらに重要性を増しています。EUのデジタル市場法（Digital Markets Act）は、AppleとGoogleの両方に代替アプリストアへの開放を強制しています。ヨーロッパでサードパーティのAndroidマーケットプレイスが勢いを増すにつれて、彼らは提出用の普遍的なフォーマットを必要とするでしょう。彼らはGoogle独自のDynamic Deliveryインフラストラクチャを利用できないため、そのフォーマットはAPKになります。皮肉なことに、これにより、Googleが自社ストアでAABを強化する一方で、世界最大級の市場の一部ではAPKの重要性が再燃する可能性があります。
あなたの状況に応じた実践的な推奨事項
では、単刀直入にいきましょう。どちらのフォーマットが正しいかは、あなたが何をしようとしているかに完全に依存します。あなたの役割に応じた、無駄のないガイドです。 **Google Playに新しいアプリを公開する場合：** 選択の余地はありません。2021年8月以降の新規アプリはAABを提出しなければなりません。Play ConsoleでPlay App Signingを設定し（「設定」>「アプリの完全性」）、Gradleの署名設定を行い、`./gradlew bundleRelease`を実行してください。ローカルでのテストは`bundletool build-apks --bundle=app.aab --output=app.apks --local-testing`に続けて`bundletool install-apks --apks=app.apks`を実行して、必ず確認してください。 **MDM経由で企業デバイスに配布する場合：** APKを使い続けてください。`./gradlew assembleRelease`でAPKをビルドします。MDMソリューションはAPKを直接デバイスにプッシュします。ここでAABを使っても何の価値ももたらさず、頭痛の種を増やすだけです。 **代替アプリストアに配布する場合：** APKをビルドしてください。例えばAmazon Appstoreには、APKアップロード用の独自の開発者ポータルと、デバイスターゲティング用の独自のロジックがあります。彼らはGoogleのシステムを使いません。 **ビルドをテストするQAエンジニアの場合：** 日々のスモークテストやリグレッションテストにはAPKを使いましょう。高速で、`adb install`で直接インストールできます。最終的なリリース前検証では、AABをビルドし、`bundletool`を使って、ユーザーが実際にPlayストアから入手するものをテストしていることを確認すべきです。 **受け取ったAPKを検査する必要がある場合：** CocoConvertにアップロードして迅速にコンテンツを抽出するか、Android Studio独自のAPK Analyzer（「Build」>「Analyze APK」）を使うこともできます。Analyzerはファイルサイズの優れた視覚的な内訳を提供し、2つの異なるビルドを比較して何が変わったかを確認するのに最適です。 最終的に、APK対AABの議論は、どちらのフォーマットが真空状態で技術的に優れているかという話ではありません。それはロジスティクス（段取り）の問題なのです。正しい選択は、あなたの配布チャネルとツールによって決まります。どちらのフォーマットも、広大に広がるAndroidエコシステムの異なる道を支えるために、存続し続けるでしょう。