iOS開発証明書の移行：2026年の新Mac検収リスト

証明書を新しいMacへ読み込んだのに、Xcodeが「秘密鍵がありません」と表示されます。

最短の解決策は、.cer だけでなく秘密鍵を含む署名IDを移行することです。秘密鍵が残っていなければ、新Macで証明書を再作成し、Provisioning Profile、App ID、権限を同期してください。旧Macは、実際のArchive、署名検証、App Store Connectへのアップロードが終わるまで停止しません。

この手順は、旧MacからリモートMacへビルド環境を移す独立開発者、常駐のiOS打ち上げ環境を管理する小規模チーム、旧Macの故障で署名資産の復旧可否を判断したい人向けです。fastlaneの導入方法ではなく、署名環境を安全に切り替えて発行を止めないための検収手順に絞ります。

証明書ファイルと署名IDを比較する

Appleのコード署名では、証明書に含まれる公開鍵と、Macのキーチェーンに保存された秘密鍵が組み合わさって署名IDになります。したがって、証明書ファイルだけをコピーしても、新しいMacで署名できるとは限りません。Appleは、証明書と対応する秘密鍵の組み合わせがコード署名に必要だと説明しています。詳しくはAppleのコード署名証明書に関する技術ノートを確認してください。

なぜ証明書を読み込んでもXcodeが秘密鍵を要求するのでしょうか。
.cer は証明書だけであり、旧Macのログインキーチェーンにある秘密鍵を含みません。Keychain Accessで証明書の横に秘密鍵が表示されない場合、署名IDは完成していない状態です。AppleのKeychainに保存される署名IDの説明でも、証明書と秘密鍵の対応関係が示されています。

第一段階：旧Macを残したまま移行範囲を確定する

旧Macがまだ起動するなら、先にプロジェクトと署名資産を棚卸しします。Team ID、Bundle ID、ターゲット名、Capabilities、使用する証明書の種類、Provisioning Profile、App Store Connectのアップロード方式を記録してください。

Xcodeの自動署名、手動署名、CI用のコマンドライン設定は別物です。自動署名ではXcodeが現在のApp IDや権限に応じたプロファイルを取得しますが、手動署名ではプロファイル名や証明書を明示的に指定します。CIではさらに、ビルドユーザー、キーチェーンのロック解除、APIキー、環境変数まで確認対象になります。

ここでの合格条件は「ビルドが通る」ではありません。最終的には、実際のRelease Archiveが作成でき、署名が検証でき、App Store Connectで受理・処理されることを成功基準にします。

第二段階：秘密鍵を含む形で安全に書き出す

旧MacのKeychain Accessを開き、「自分の証明書」からApple Distributionなどの対象証明書を確認します。証明書を展開したとき、対応する秘密鍵が表示されることが第一条件です。

秘密鍵が確認できたら、証明書単体ではなく、パスワードで保護されたアイデンティティ形式で書き出します。書き出したファイル、保護用パスワード、Apple Accountの認証情報を同じ場所へ置かないでください。秘密鍵やパスワードをGitリポジトリ、チャット、CIログへ保存する運用も避けます。

Appleの証明書の概要と保護に関する案内では、配布用証明書と認証情報を機密資産として扱うことが求められています。チームで移行する場合は、誰が書き出し、誰が新Macへインポートし、誰が削除を承認したかを記録してください。

旧Macが起動しない場合でも、同じ署名を復元できますか。
秘密鍵のバックアップが残っていれば復元できる可能性があります。しかし公開証明書だけから秘密鍵を逆算することはできません。バックアップがない場合は、権限を確認したうえで新しい証明書を作成し、関連するProvisioning Profileを更新するルートへ切り替えます。

第三段階：再作成と失効を混同しない

旧Macが使えず、秘密鍵も回収できない場合は、新MacでCSRを作成して新しい署名証明書を発行します。ただし、古い証明書を先に失効させる必要はありません。Appleの案内では、証明書を失効させると、その証明書を含むProvisioning Profileも無効になります。失効は、漏えいが疑われる場合や管理上の明確な理由がある場合に限定してください。

新しい証明書を発行した後は、App IDのCapabilitiesとプロジェクトのentitlementsを比較します。App IDはProvisioning Profileの中でアプリを識別し、Capabilitiesは利用可能なサービスの許可リストとして働きます。Bundle IDの入力違い、Push NotificationsやSign in with Appleなどの設定漏れは、証明書が正しくても署名エラーの原因になります。確認にはApp IDとCapabilitiesの公式説明を使います。

App Store Connect APIキーやAPNsキーは、コード署名証明書とは別の資産です。特に.p8形式の秘密鍵は、ダウンロード後に再取得できない場合があるため、保管場所とローテーション担当者を別に決めます。Appleのサービス用秘密鍵の作成手順でも、キーを安全に保存するよう案内されています。

第四段階：新Macで署名関係を復元する

新Macには、まず対象のキーチェーンへ署名IDをインポートします。Keychain Accessで証明書と秘密鍵が同時に表示されることを確認し、Xcodeのアカウント画面では正しいチームへログインします。

続いて、Signing & CapabilitiesのTeam、Bundle Identifier、Provisioning Profile、証明書指定を確認します。自動署名を使う場合でも、Xcodeが意図したApp IDとCapabilitiesを参照しているかを確認してください。手動署名では、古いプロファイルがキャッシュされていないかも確認します。AppleのProvisioning Profileの編集・再生成手順では、証明書の変更、Capabilitiesの変更、期限切れなどが再生成の理由として示されています。

リモートMacを無人ビルドに使う場合は、ビルドユーザーでキーチェーンが利用できるか、再起動後も依存関係が復元されるかを確認します。自動化のために秘密鍵の保護を外したり、資格情報を平文で配置したりするのは避けてください。

第五段階：Archiveからアップロードまで段階的に検収する

最初の確認は、実際のプロジェクトを使ったクリーンなRelease Archiveです。シミュレーター向けのビルドやDebugビルドだけでは、配布用署名の移行完了を判断できません。

検収は次の順に分けます。

1. 依存関係を復元し、指定したRelease Schemeでビルドします。
2. ProductからArchiveを実行します。
3. Organizerで使用された証明書、Team ID、Provisioning Profile、entitlementsを確認します。
4. Archiveの署名検証とExportを実行します。
5. XcodeまたはTransporterでApp Store Connectへアップロードします。
6. App Store Connect側でビルドが受理され、処理後に表示されることを確認します。
7. 同じ手順をターミナルやCIの実行ユーザーでも再現します。

コンパイル成功、Archive成功、Export成功、署名検証成功、アップロード成功は別々の状態です。AppleのXcodeによる配布手順でも、Archiveの作成後にValidate Appやアップロードを行う流れが示されています。アップロードはローカルにIPAができた時点では完了していません。App Store Connectで処理されるまで確認してください。

注意：ログは完全削除せず、チームID、Bundle ID、プロファイル名などの必要な手掛かりを残したまま、秘密鍵、トークン、パスワード、個人情報だけをマスキングして保存します。

新しいMacが正常に署名とアップロードを行えるか、どう確認すればよいですか。
実案件のArchiveを作成し、署名対象、entitlements、Export結果を確認したうえで、App Store Connectへアップロードします。その後、再起動した環境で無人ビルドをもう一度実行します。人がログインした一回だけ成功する状態は、常駐打ち上げ環境として未検収です。

条件分岐で決める新旧環境の切り替え時期

次の条件で判断すると、早すぎる旧Macの停止を防げます。

• 旧Macで秘密鍵を確認でき、保護済みの署名IDを書き出せるなら、新Macへ移行して実案件で検証します。
• 秘密鍵がないが、チーム権限があり証明書を再作成できるなら、新証明書とProfileを発行して置き換えます。
• 証明書を失効させる必要がないなら、旧環境を残したまま新環境を並行稼働させます。
• ArchiveとExportだけ成功し、App Store Connectの処理確認が終わっていないなら、旧Macを下ろしません。
• App Store Connectのアップロード権限やAPIキーが不明なら、署名移行とは別に認証資産を棚卸しします。
• 再起動後の無人ビルドが失敗するなら、旧Macへ戻し、キーチェーン解錠と実行ユーザーの設定を修正します。

新しいMacの運用方式まで見直す場合は、MacDateのmacOSレンタル案内で短期利用と継続利用の違いを確認できます。物理Macに近い隔離性が必要なら、ベアメタルと仮想macOSの比較も判断材料になります。

最後に旧Macを下ろすための検収スコア

移行完了の判定は、次の5項目を各2点で採点します。

• 秘密鍵を含む署名IDを安全に移行できた：2点
• App ID、Capabilities、Provisioning Profileが一致した：2点
• 実案件のRelease Archiveと署名検証に成功した：2点
• App Store Connectでビルドの受理・処理を確認した：2点
• 再起動後の無人ビルドを再現できた：2点

10点なら旧Macの廃止を進められます。8点以下なら、署名、認証、キーチェーン、アップロードのどこで止まっているかを特定し、旧環境を保留してください。特にアップロード未確認のまま旧Macを消去する判断は避けます。

旧Macを自前で維持する方法は、電源、ストレージ、macOS更新、バックアップ、遠隔アクセス、故障時の交換まで管理対象が増えます。新しいMacを購入する方法も、移行が終わった後に使わない期間まで固定費を負担することになります。旧環境が近く停止する一方、まだ本番発行を検証できていないなら、短期間だけMacDateのリモートMacを使って移行と実リリースを通し、Archive、署名、アップロードを繰り返せる状態か確認するのが現実的です。

必要な期間だけ環境を確保したい場合は、MacDateの日本語サービス案内から利用条件を確認してください。長期の安定した高負荷ビルドや物理デバイス接続が常に必要なら、自前のMacを残す方が適しています。逆に、旧Macの停止前に移行を検証したい、発行頻度に合わせて打ち上げ環境を保ちたいという場合は、短期レンタルから始めると撤退条件も決めやすくなります。