Appleの公式資料では、配布用の署名にはクラウド管理証明書とローカルで管理する証明書という2つの管理経路が示されています。Cloud-managed certificatesの仕様を確認すると、選択の要点は「クラウドかローカルか」だけではありません。誰がArchiveを作り、どのMacで秘密鍵を使い、失敗時にどこへ戻せるかです。

症状 → 最速の解決策

  • Xcode Organizerで手動アップロードする個人開発者 → まずクラウド管理証明書を試します。
  • xcodebuild、fastlane、CI Runnerで無人実行する場合 → 管理下のローカルApple Distribution署名を用意します。
  • 手動公開と自動化を両方使う小規模チーム → 二重構成にし、アカウント、Keychain、公開権限を分離します。

この記事は、Xcode OrganizerでTestFlightへ手動アップロードしたい個人開発者、リモートMacで無人署名を維持する自動化担当者、複数人でiOS打包環境を共有するチーム向けです。証明書の種類だけで判断せず、実際のArchive、IPA、アップロード結果まで確認したい場合に読んでください。

まず公開担当者ごとの選択を決める

クラウド署名とローカル署名は同じものではありません。クラウド管理証明書、Apple Distribution証明書、公開鍵と秘密鍵、Provisioning Profile、Xcodeの自動署名は、それぞれ役割が異なります。Appleの証明書概要でも、証明書と秘密鍵を一つの設定項目として扱わないことが確認できます。

Xcode Organizerを使う個人開発者

Archive後にOrganizerからDistribute Appを選び、TestFlightまたはApp Store Connectへ送るだけなら、証明書の手動インポートを減らせるクラウド管理方式が候補になります。Apple Developer Programのチーム所属、対象AppのBundle ID、XcodeのAutomatically manage signing、App Store Connectへの権限を順に確認してください。

クラウド方式を選んでも、署名設定が無条件に解決するわけではありません。チームの選択が違う、Bundle IDが登録されていない、プロファイルの状態が合わない、といった問題は残ります。Xcodeの配布手順に沿って、実際のArchiveからアップロードまでを確認します。

xcodebuildやfastlaneを使う自動化担当者

無人ビルドでは、ログイン画面を操作する人がいません。そのため、署名証明書の秘密鍵を実行ユーザーのKeychainから読み出せること、Provisioning Profileの配置先が一致していること、署名後のIPAを検証できることが必要です。

プロジェクトで自動署名を有効にしていても、すべてのCLI公開処理がクラウド署名を直接利用できるとは限りません。判断材料は設定画面ではなく、xcodebuild archive、-exportArchive、fastlaneの実行ログと、生成された署名済み成果物です。Xcodeのビルド設定リファレンスで、署名関連の設定がどの段階に効くかを確認してください。

注意
証明書名、Team ID、Bundle ID、Keychain名、パスワード、ログの識別子は、記事やチケットに実値を貼らないでください。<TEAM_ID>、<BUNDLE_ID>、<KEYCHAIN_PATH>のような置換値を使います。

共有のリモートMacを使う小規模チーム

複数人で同じmacOSユーザーにログインすると、誰が秘密鍵を使ったのか追跡しにくくなります。さらに、Keychainのロック解除状態やAppleアカウントのログイン状態が、別の担当者へそのまま引き継がれます。

最低限、次の単位を分けてください。

  • 開発者のAppleアカウントとApp Store Connectの役割
  • macOSユーザーとログインセッション
  • 署名用Keychainと秘密鍵
  • CIサービス用ユーザーと実行ディレクトリ
  • 手動公開者と自動化担当者の承認範囲

App Store Connectの役割は一律ではありません。AppleのRole permissions一覧で、アプリ情報の閲覧、ビルド管理、提出操作を担当者ごとに確認します。アップロードできる人と、秘密鍵を扱える人を同一人物に固定する必要はありません。

クラウド署名とローカル署名を実務で分ける

クラウド管理方式の利点と制約

クラウド管理方式の利点は、複数のMacへ配布用秘密鍵を手動でコピーする作業を減らせることです。個人開発者がOrganizer中心で公開するなら、証明書の導入、バックアップ、交換作業を少なくできます。

一方で、CLIの無人実行に必要なKeychain内の秘密鍵、固定されたプロファイル、再現可能な環境が自動的に手に入るわけではありません。クラウド署名に切り替えた後は、手動Archiveだけでなく、実際の自動Exportまで実行してください。

ローカルApple Distribution署名の利点と制約

ローカル署名では、配布証明書と秘密鍵を特定のMacまたはCIユーザーで管理します。どのKeychainを使うか、いつロック解除するか、どのProfileを選ぶかを明示できるため、fastlaneやxcodebuildの実行条件を固定しやすい方式です。

反対に、秘密鍵のバックアップ、インポート、失効、更新、アクセス制御を自分で運用しなければなりません。証明書を削除・失効させる前に、現在の本番Archiveを再現できる別環境と、復旧用の安全なバックアップを確認してください。署名IDの同期に関するAppleの説明も、共有方法を決める前に確認する資料です。

一時協力者と複数Appでは漏えい範囲を先に決める

外部協力者に公開用秘密鍵を渡してしまうと、作業終了後に鍵を回収したつもりでも、複製済みのファイルまでは消せません。短期作業では、公開用署名を触らせず、必要なArchiveを専任担当者が作る運用のほうが安全な場合があります。

複数Appを一つの打包機で処理する場合も、全プロジェクトで同じ署名資産を使い回さないでください。Appごと、チームごと、または役割ごとにアクセス範囲を分けます。特定の証明書が漏えいした場合に、どのAppと公開経路まで影響するかを先に書き出します。

よくある判断をリモートMacで検証する

Xcodeの自動署名でも分配証明書を持ち込む必要はあるか

手動Organizerの範囲では、Xcodeがチーム情報や署名設定を処理できる場合があります。ただし、リモートMac上のCIユーザーが同じ状態になるとは限りません。Appleアカウントの認証状態、macOSユーザー、Keychain、Profile、実行権限が異なるためです。

まず、テスト用Bundle IDで次を確認します。

  • [ ] Xcodeで正しいチームとBundle IDを選択する
  • [ ] Archiveを作成し、署名IDをログで確認する
  • [ ] OrganizerからTestFlightへアップロードする
  • [ ] App Store Connectでビルドが処理済みになることを確認する
  • [ ] macOSユーザーを切り替え、同じ操作が意図せず実行できないことを確認する

クラウド方式を採用する場合も、手動アップロードの成功だけで本番運用と判断しないでください。再ログイン、Keychainのロック、Macの再起動後にも同じ担当者が復旧できるかを確認します。

fastlaneの無人ビルドはクラウド管理証明書だけで動くか

直接動くと決めつけないでください。fastlaneやxcodebuildは、実行時に利用できる署名ID、秘密鍵、Profile、環境変数、キーチェーン状態に依存します。クラウド管理証明書を選んだプロジェクトでも、CI側で同じ認証・署名経路が再現されるかは別途検証が必要です。

実行ログでは、署名IDが想定したApple Distributionになっているか、ProfileのBundle IDが一致するか、Export後のIPAが正しいチームで署名されているかを確認します。失敗した場合に、すぐローカル証明書を追加するのではなく、認証、Profile、Keychain、署名設定のどこで止まったかを切り分けてください。

共有のiOS打包機で秘密鍵を漏らさない方法

共有環境では、全員に管理者権限を付ける設計を避けます。macOSユーザーを分け、CIサービスには必要なディレクトリとKeychainだけを許可し、手動公開者のAppleアカウントをCIへ保存しない構成にします。

SSHやVNCで接続する担当者にも、秘密鍵ファイルを読み出せる権限を与える必要があるのかを確認します。接続できることと、署名秘密鍵をエクスポートできることは別です。リモートMacの管理では、root権限があるから安全になるのではなく、root権限を持つ人を限定し、操作履歴と復旧手順を管理できることが重要です。

最後にArchiveから復旧までを受け入れる

公開方式の選択は、1回の署名成功では終わりません。次の確認を一つの受け入れ条件として扱います。

  • [ ] 手動Archiveで署名IDとTeam IDを確認する
  • [ ] IPAをエクスポートし、Bundle IDと署名状態を検証する
  • [ ] TestFlightへのアップロード結果をApp Store Connectで確認する
  • [ ] CIユーザーから同じArchiveとExportを実行する
  • [ ] macOSユーザーのログアウト後にKeychainの扱いを確認する
  • [ ] Mac再起動後に、必要なサービスだけが復旧することを確認する
  • [ ] 署名権限を撤回した担当者が再実行できないことを確認する
  • [ ] クラウド経路が失敗した場合のローカル回退手順を文書化する

個人開発者がOrganizerで手動公開するなら、まずクラウド管理証明書で維持作業を減らします。自動化が主役なら、秘密鍵とKeychainを管理できるローカルApple Distribution署名を選びます。両方が必要なチームでは、クラウド署名とローカル署名を役割別に使い、同じAppleアカウント、macOSユーザー、Keychainを共有しない構成にします。

手元の環境が一時的な共有セッション、揮発するKeychain、再起動後に戻らないユーザー状態であれば、署名方式を変えるだけでは解決しません。自前のMacでは、購入費用に加えて常時稼働、保守、保管、遠隔復旧の負担も発生します。短期の検証や出先からのArchiveでは、物理Macを用意するより、権限分離とKeychainの永続性を確認できるMacレンタル環境のほうが扱いやすい場合があります。

まずは実際のArchive、IPA、TestFlightアップロードを一度通してください。そのうえで、手動公開とCIを分けて運用したい場合は、MACCOMEのリモートMac環境を候補に加え、接続方式、ユーザー権限、Keychainの保持、再起動後の復旧を契約前に確認してください。Macを長期保有する選択肢と比較するなら、Mac miniレンタルの選び方も、必要な運用期間と照らし合わせて検討できます。