モバイルアプリの署名と配布
審査落ちや配布トラブルの大半は署名の仕組み誤解が原因。証明書・プロビジョニング・鍵管理の原理を押さえれば、リリース作業の迷いが消える。
- 1.iOSは証明書・プロビジョニングプロファイル・entitlementsの三点セットで「誰が・どの端末に・何の権限で」インストールできるかを検証する。
- 2.Androidはアプリ全体をアプリ署名鍵で署名し、Play App Signingを使えばアップロード鍵の漏洩・紛失リスクをGoogle側の鍵と分離できる。
- 3.コード署名が保証するのは作者の同一性と配布後の非改ざんのみで、コードの安全性そのものは保証しない。TestFlightやInternal Testingは審査前の実機検証チャネルとして役割が異なる。
コード署名が保証するものは何か
コード署名の役割は限定的です。保証するのは「秘密鍵の所有者が確かにこのバイナリを作った（真正性）」と「署名後に1バイトも変更されていない（完全性）」の2点だけで、コードの中身が安全かどうかは一切保証しません。マルウェアでも正規の鍵で署名されていれば検証は通ります。OSやストアは、この署名を土台に「誰の責任か」を追跡可能にし、改ざんされたバイナリの実行を拒否する仕組みを組み立てています。iOSとAndroidはこの原理を採用しつつ、信頼の起点と鍵の持ち方が対照的です。
iOS：証明書・プロビジョニング・entitlementsの三点セット
iOSの実機実行は、3つの要素が揃って初めて成立します。
| 要素 | 内容 | 検証する対象 |
|---|---|---|
| 証明書（Certificate） | Appleが署名した公開鍵証明書。秘密鍵は開発者のキーチェーンにのみ存在 | 「誰が」ビルドに署名したか（開発者・組織の身元） |
| プロビジョニングプロファイル | 証明書・App ID・端末UDIDリスト・entitlementsを束ねAppleが署名したファイル | 「どの端末に」「どのアプリを」インストールしてよいか |
| entitlements | Keychain共有・Push通知・App Groupsなど、アプリに許可する権限の宣言 | 「何の権限を」OSに要求できるか |
証明書はApple自身が署名するCA階層の末端であり、開発者は自分でCSR（証明書署名要求）を作りApple Developer Portalに送って発行を受けます。つまり鍵ペアの秘密鍵部分は開発者のマシンから外に出ません。プロビジョニングプロファイルはこの証明書と、対象デバイスのUDID一覧（開発配布時）、Bundle ID、entitlementsをひとまとめにしてAppleが署名したマニフェストです。インストール時にiOSは、実行ファイルの署名がプロファイル内の証明書と一致するか、端末のUDIDがリストにあるか（開発・Ad Hoc配布時）、entitlementsがプロファイルの許可範囲を超えていないかを検証します。どれか一つでも不整合ならインストールも起動も拒否されます。
証明書だけでは「誰が作ったか」しか分からず、任意の端末に無制限にインストールできてしまいます。プロビジョニングプロファイルが端末とアプリの組を限定し、entitlementsが権限を宣言的に制限することで、Appleは審査を経ないビルドの拡散範囲と権限を狭く縛れます。App Store配布では端末UDIDの制限は外れますが、証明書とentitlementsの検証は変わらず行われます。
Xcodeの自動署名（Automatic Signing）はこの3要素の生成・更新をAPI経由で肩代わりしているだけで、内部の検証ロジック自体は変わりません。CI環境では証明書の秘密鍵（.p12）とプロファイルを安全に持ち込む必要があり、ここが漏洩すると第三者が同じApp IDで署名したバイナリを作れてしまうため、鍵の保管はiOS配布パイプラインで最も慎重を要する部分です。
Androidの署名モデルとPlay App Signing
Androidの署名モデルはiOSより単純です。APK（またはAAB）全体をアプリ署名鍵（app signing key）で署名し、OSはインストール時に同じパッケージ名の更新は必ず同じ鍵で署名されているかだけを検証します。証明書はAppleのような外部CAの発行を必要とせず、開発者が自己署名で作った鍵をそのまま使えます。信頼の起点が「初回インストール時に見た鍵と同じかどうか」という継続性検証である点が、身元をCA階層で保証するiOSと本質的に異なります。
この単純さは裏を返せば、アプリ署名鍵を紛失するとそのパッケージ名で二度と更新を配布できなくなるという重いリスクを伴います。従来は開発者自身がこの鍵を生涯にわたり管理する必要がありました。
Play App Signingでは、開発者が管理するのは「アップロード鍵（upload key）」のみで、Google Playが実際に配布するAPKに署名する「アプリ署名鍵」はGoogle側のインフラで安全に保管されます。開発者はアップロード鍵で署名したAABをPlay Consoleに送り、Googleはアップロード鍵の署名を検証したうえで、自身が保持するアプリ署名鍵で再署名して配布します。アップロード鍵が漏洩・紛失してもGoogleに再発行を申請でき、ユーザー端末に届く署名の同一性は保たれます。
AAB（Android App Bundle）形式が前提となるのもこの仕組みと関係します。Google側が最終署名を担うことで、端末や言語ごとに最適化したAPKを動的に生成・署名して配信する余地が生まれ、単一のAPKを固定配布していた旧方式より柔軟な最適化が可能になっています。
配布チャネル：審査前の実機検証
配布チャネルは、コード署名とは別の関心事である「誰にどの段階でビルドを届けるか」を扱います。
| チャネル | プラットフォーム | 位置づけ |
|---|---|---|
| TestFlight | iOS | App Store審査とは別枠の簡易審査を通過したビルドを、内部（最大100名）・外部（最大1万名）のテスターに配布 |
| Internal Testing | Android | 審査なしで即座に反映される少人数向けトラック。Closed/Open Testingを経て段階的に対象を広げるのが一般的 |
| 本番配布 | 両OS | 正式審査を経てストア掲載。iOSは全ビルド審査必須、Androidも近年ポリシー審査が強化されている |
TestFlightの内部テスターは組織のApp Store Connectに紐づくメンバーで、審査を経ずに即配布できます。外部テスターへの配布にはApple側の簡易審査（本番より緩いが完全に免除ではない）が挟まります。Androidの各種テストトラックは審査そのものよりリリース管理の段階分けが主目的で、Internal Testingは登録済みメールアドレスへ数分で配布可能です。いずれの仕組みも、コード署名によって「このビルドは確かにこの開発者が作った改ざんのないものだ」という前提を担保したうえで、「誰の目に触れさせるか」という配布範囲を別レイヤーで制御しています。署名が真正性のレイヤー、配布チャネルがガバナンスのレイヤーだと整理すると、リリース工程全体の見通しが良くなります。
iOSの三点セットは「証明書＝身元」「プロビジョニング＝端末とアプリの組の許可」「entitlements＝権限」の役割分担で覚えます。Androidは「同一パッケージ名は同一鍵」という継続性検証が核であり、Play App Signingはアップロード鍵とアプリ署名鍵を分離してGoogleが後者を保管する仕組みだと説明できるようにしておきます。コード署名が保証するのは真正性と完全性であり、脆弱性の有無やコードの安全性を保証しない、という限界も定番の論点です。
まとめ
モバイルの署名基盤は、iOSが証明書・プロビジョニングプロファイル・entitlementsの3要素を組み合わせて「誰が・どの端末に・何の権限で」を厳密に検証するのに対し、Androidはパッケージ名と署名鍵の継続的な一致という単純なモデルを採用し、Play App Signingで鍵管理のリスクをGoogle側に分散させています。どちらの方式も、コード署名が保証するのは作者の同一性と非改ざんであって安全性そのものではない、という原則は共通です。その上に積まれるTestFlightやInternal Testingといった配布チャネルは、審査前の実機検証という別の関心事を扱うレイヤーであり、署名の信頼モデルと混同せず切り分けて理解することが、リリース事故を避ける近道になります。基盤となる暗号署名や証明書の一般原理は /security/ の話題とも接続しています。
モバイル開発 Article
モバイルアプリの署名と配布を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
iOS
比較で見る軸
難易度: advanced / カテゴリ: モバイル開発 / タグ数: 6
導入後に効く点
Androidはアプリ全体をアプリ署名鍵で署名し、Play App Signingを使えばアップロード鍵の漏洩・紛失リスクをGoogle側の鍵と分離できる。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- モバイル開発
- タグ数
- 6
判断チェックリスト
- 自社の用途が「iOS / Android」に近いか確認する。
- 強みである「iOSは証明書・プロビジョニングプロファイル・entitlementsの三点セットで「誰が・どの端末に・何の権限で」インストールできるかを検証する。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。