LASSIC Media らしくメディア

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

アプリのコード署名・証明書管理とは何か

アプリのコード署名・証明書管理とは、iOSアプリの配布に必要な証明書・App ID・Provisioning Profileと、Androidアプリの署名に使うアップロード鍵・アプリ署名鍵を、有効期限や利用範囲を踏まえて継続的に管理・運用する業務を指します。証明書はApple Developer公式の「Certificates, Identifiers & Profiles」で発行・失効管理され^*1、AndroidはGoogle Play Console公式ヘルプが定めるPlay App Signingの仕組みでアプリ署名鍵をGoogleが保管します^*2。

iOSとAndroidでは仕組みが大きく異なります。iOSは証明書とProvisioning Profileという2つの要素をApple Developerで管理し、期限が切れると再発行が必要です^*1。Androidは開発者が保有するアップロード鍵と、Googleが保管するアプリ署名鍵を分離するPlay App Signingが標準の仕組みになっています^*2。

この記事では両OSの仕組みを一次情報に基づいて整理し、証明書・鍵の管理を外部パートナーに委ねる際の判断軸を解説します。開発チームの体制構築を検討している方に向けた内容です。

iOSの署名体系 — 証明書・App ID・Provisioning Profile

iOSアプリの署名には、証明書・App ID・Provisioning Profileという3つの要素が連動します。Apple公式の「Certificates, Identifiers & Profiles」で管理され、それぞれ役割が明確に分かれています^*1。

証明書には開発用と配布用の2系統があります。開発用のApple Development証明書は開発者個人が保有し、端末上での動作確認に使います。配布用のApple Distribution証明書はチーム単位で保有し、App Store提出や社内配布の署名に使う点が公式ヘルプで説明されています^*1。証明書の発行にはAccount HolderまたはAdminロールが必要で、失効（Revoke）もこの2ロールに限定されます^*3。

App ID（バンドルID）はアプリを一意に識別する文字列で、Provisioning Profileはこの App IDと証明書、必要に応じて登録済み端末を紐付ける許可証の役割を持ちます^*4。Apple公式の説明では、Provisioning Profileはアプリが特定のApp Serviceを使用できることを承認し、開発者本人であることを保証する仕組みとされています^*4。App Store配布用のProfileには単一のDistribution証明書が含まれる仕様です^*5。

APNs（Apple Push Notification service）を使う場合は、プッシュ通知専用の証明書または認証キーを別途発行する必要があります。この証明書が失効すると、プッシュ通知の送信自体ができなくなる点にも注意が必要です^*3。

Androidの署名体系 — アップロード鍵とPlay App Signing

Androidアプリの署名を理解する起点は、Google Play Console公式ヘルプが定めるPlay App Signingです。これは、Googleが保護されたインフラ上でアプリの署名鍵を管理するサービスとされています^*2。

Play App Signingでは、開発者が保有する「アップロード鍵（upload key）」と、Googleが保有・管理する「アプリ署名鍵（app signing key）」の2つを分離します。開発者はアップロード鍵でAAB（Android App Bundle）に署名してPlay Consoleに提出し、Googleがアップロード証明書で本人確認をした上で、実際に端末へ配布されるAPKにはアプリ署名鍵で再署名する仕組みです^*2。

鍵はkeystore（拡張子.jksや.keystore）という形式のファイルに保管されます。keystoreは証明書と秘密鍵を格納するリポジトリであり、Android Developers公式ガイドは保護された場所での保管を求めています^*6。アップロード鍵を紛失または侵害した場合でも、アカウント所有者がPlay Consoleのヘルプフォームからアップロード鍵のリセットを申請すれば、アプリ署名鍵には影響を与えずに新しい鍵へ切り替えられます^*2。

新規にアプリを公開する場合、Google Playの要件では鍵の有効期限を2033年10月22日以降に設定する必要があり、25年以上の有効期間が推奨されています^*2。iOSの証明書が1年ごとに更新を要するのとは対照的に、Androidの鍵は長期利用を前提とした設計です。

iOSとAndroidの署名管理を比較する

両OSの署名管理は目的が共通する一方、鍵・証明書のライフサイクルや管理主体が異なります。外注・内製を検討する際は、この違いを踏まえて体制を設計する必要があります。

この比較から分かる通り、iOSは証明書とProfileの組み合わせを人手で追跡し続ける必要があり、Androidは鍵の分離構造によって一定のリスク低減が図られています。ただしAndroidでもアップロード鍵自体の管理が疎かになれば、リセット申請の手続きに時間を要する点は変わりません^*2。

証明書失効・鍵紛失が招く配信停止リスク

iOSの配布用証明書が期限切れになると、新しいバージョンをApp Storeにアップロードできなくなります^*3。社内配布用の証明書が失効した場合は、その証明書で署名済みのアプリ自体が端末で起動できなくなるため、既存ユーザーへの影響がより直接的です^*3。

証明書を意図的に失効（Revoke）した場合の影響も見逃せません。Apple公式ヘルプは、失効した証明書を含むProvisioning Profileはすべて無効になると明記しています^*3。開発者が退職時に個人所有の証明書を削除した結果、同じProfileを使っていた他のビルドが連鎖的に無効化される事態も起こり得ます。

Androidでは、Play App Signingを利用していればアプリ署名鍵はGoogleが管理するため、アップロード鍵を紛失しても配信自体が止まるわけではありません^*2。一方でPlay App Signingを使わず自前のkeystoreだけで署名している場合、keystoreの紛失は既存アプリの更新提出そのものができなくなるリスクに直結します^*6。keystoreの管理者が退職し、保管場所やパスフレーズが引き継がれていないケースは実務上のリスクとして想定しておく必要があります。

APNsの証明書やキーが失効すると、プッシュ通知の配信が止まります^*3。会員向けアプリやEC系アプリでは通知が売上機会に直結するため、証明書の期限は事業影響として捉える必要があります。

チーム間の鍵共有で起きやすい問題

複数人・複数チームでアプリを開発する場合、証明書や鍵をどう共有するかが運用課題になります。iOSでは開発用証明書は個人単位（1人あたりiOS用2枚・Mac用2枚が上限）で発行され、配布用証明書はチーム単位で1種類ずつという制約があります^*3。この制約を理解せずに個々のメンバーが独自に証明書を発行すると、上限に達して新規発行ができなくなる事態が起こり得ます。

Androidのkeystoreはファイル自体をやり取りする必要があるため、メールやチャットでの受け渡しが常態化すると流出のリスクが高まります。パスフレーズも含めて保護された経路で共有し、アクセスできる担当者を限定する運用が欠かせません。

属人化も大きな問題です。証明書やkeystoreの管理を特定の担当者のPCやアカウントに依存させると、担当者の異動・退職時に更新作業が滞ります。この状態を放置すると、次回リリース時に証明書の所在が分からず、緊急でApple・Googleに問い合わせる事態にもつながりかねません。

CI/CDでの署名自動化とmatchの考え方

アプリのビルド・配布を自動化するCI/CD環境では、証明書やProvisioning Profileをビルドサーバー側でも参照できる状態にする必要があります。ここで広く使われているのが、fastlaneが提供するmatchというツールです。

fastlane公式ドキュメントによると、matchは証明書とProvisioning Profileを生成し、GitリポジトリやGoogle Cloud、Amazon S3といった外部ストレージに保存する仕組みです^*7。チームメンバーは同じ署名情報を参照できるため、各自がApple Developerポータルに直接アクセスして証明書を発行し直す必要がなくなります^*7。公式ドキュメントでは、この方式によって新しいメンバーのオンボーディングや新しいMacのセットアップが容易になるとされています^*8。ファイルはOpenSSLで暗号化された状態で保存される点も特徴です^*7。

CI環境でmatchを使う場合、公式はreadonlyモードでの実行を推奨しています^*7。これは、CIサーバーが誤って新しい証明書を発行し、既存の証明書を失効させてしまう事故を防ぐためです。証明書の発行・失効という強い権限操作は人が判断し、CI/CDのビルド工程は既存の署名情報を「読み取るだけ」に限定する設計が事故防止に役立ちます。

Androidの場合はCI/CD上でkeystoreファイルと署名用パスワードを環境変数やシークレットストアで管理し、ビルド時に注入する運用が一般的です。keystoreそのものをリポジトリに平文でコミットしないという基本を徹底する必要があります。

外注と内製の判断軸

証明書・鍵の管理を内製で行うには、Apple Developer Program・Google Play Consoleの権限体系の理解に加えて、証明書の発行・失効操作、Provisioning Profileの再生成、CI/CDとの連携設定という複数領域の知識が必要です。少人数の開発チームがリリース作業と兼務で対応する場合、証明書の期限管理が後回しになりやすい点は実務上の課題です。

専門パートナーに委託する場合との違いは、期限監視の体制にあります。内製では担当者の記憶やスプレッドシートでの手動管理に頼りがちですが、外部の運用チームに委ねれば、複数プロジェクトの証明書・鍵の期限を一元的に管理する仕組みを整えやすくなります。証明書の失効やアップロード鍵の紛失といった不測の事態への対応手順も、委託先が過去の運用実績に基づいて用意していることが判断材料になります。

外注を検討する際は、Apple Developer・Google Play Consoleへのアクセス権限をどう分離するか、証明書やkeystoreの保管場所をどこに置くかという契約上の取り決めも欠かせません。委託範囲を「鍵の生成・保管まで」とするか「CI/CD組み込みまで」とするかによって、必要なスキルセットと体制が変わってきます。

LASSICでは元請（プライムベンダー）としてシステムの保守・運用を受託しており、証明書・鍵のライフサイクル管理を含めた運用設計の相談に対応する体制を整えています。開発チームがリリース業務に集中できるよう、署名まわりの運用を切り出して任せたいという要望にも応じています。

まとめ：コード署名・証明書管理を外注で継続運用するために

本稿では、iOSの証明書・App ID・Provisioning Profileの仕組みと、Androidのアップロード鍵・アプリ署名鍵によるPlay App Signingの仕組みを整理しました。要点を3つに集約すると次の通りです。第一に、iOSは証明書が1年で失効するため継続的な更新管理が必須であり、第二に、Androidはアップロード鍵とアプリ署名鍵の分離によって鍵紛失時のリスクを抑える設計になっています。第三に、CI/CDでの署名自動化にはmatchのような仕組みを使いつつ、証明書の発行・失効という強い操作は人が判断する体制が欠かせません。これらの運用を属人化させずに継続するには、外注も含めた体制の見直しが有効な選択肢になります。

よくある質問

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

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

1. *1　出典：Apple Developer「Certificates overview」
2. *2　出典：Google Play Console ヘルプ「Use Play App Signing」
3. *3　出典：Apple Developer「Revoke a certificate」
4. *4　出典：Apple Developer Documentation「TN3125: Inside Code Signing: Provisioning Profiles」
5. *5　出典：Apple Developer「Create an App Store provisioning profile」
6. *6　出典：Android Developers「Sign your app」
7. *7　出典：fastlane docs「match」
8. *8　出典：fastlane docs「Getting Started with codesigning」

Tweet