Apple Developer証明書の期限切れにどう対処する？2026年iOSリリースの修復

Apple Developer Programの会員資格は1年ごとの更新です（Apple公式の会員更新案内）。そのため、期限切れを見つけたら、会員資格、証明書、Provisioning Profileを別々に確認し、失効対象に合った資産を更新してから、実際にビルドするMacでArchiveをやり直してください。

症状：証明書を更新したのに、署名またはアップロードに失敗する。
最短対応：エラー文だけで原因を決めず、証明書の状態、Profileとの組み合わせ、実行中のMacを順に照合します。

この手順は、更新版を公開する直前に署名エラーが出た独立開発者向けです。
小規模チームで証明書を更新し、Profileやビルド環境へ反映したい担当者にも役立ちます。
ローカルでは成功するのにリモートMacの自動ビルドが失敗する場合も、実行先を追って原因を絞れます。

Apple Developer証明書の期限切れと撤回は、まず対象を分ける

「署名に失敗しました」という表示だけでは、証明書の期限切れとは断定できません。Appleの証明書一覧で種類と状態を確認し、開発者アカウントの会員状態、ビルドログ、Xcodeの署名設定を別々に照らし合わせます。Appleの証明書一覧と用途では証明書の種類を確認できます。

期限切れと撤回も同じ扱いにはできません。期限切れは証明書の有効期間が終わった状態で、撤回は有効期間中でも証明書が取り消された状態です。Appleの証明書に関する権限と撤回の説明も確認し、原因が会員資格やチーム権限なら、証明書を次々に作り直さないでください。

Apple Development証明書とApple Distribution証明書では、期限切れの影響は同じですか？
同じではありません。開発証明書は開発時の署名に、配布証明書は配布用ビルドの署名に使われます。まず失敗したビルドの用途と選択中の署名IDを確認し、別用途の証明書を入れ替えて解決しようとしないことが重要です。

開発用と配布用では、公開済みアプリへの影響が異なる

App Store向けの配布証明書が期限切れでも、それだけで公開済みアプリが直ちに無効になると考える必要はありません。影響を判断するときは、公開済みアプリの状態と、これからアップロードする新しいビルドを分けて確認してください。Appleの証明書の種類と用途を参照し、配布用の署名に利用できる有効な証明書があるかを調べます。

配布証明書が期限切れでも、App Storeの更新版をアップロードできますか？
期限切れの証明書を使って新しい配布用ビルドに署名することはできませんが、期限切れだけを理由に公開済みアプリまで停止したと決めつけないでください。新しい更新版を出すには、有効な配布証明書を選び、必要に応じて対応するProfileを更新して、新しいArchiveを作成します。

証明書を切り替える前に、チームで誰が証明書を作成・管理できるかも確かめます。Appleのチーム署名証明書の共有方法に照らして、証明書の所有チームやアカウント権限を確認してください。会員資格に問題がある場合は、会員更新の手順を先に確認します。証明書の撤回や再作成を繰り返すより、該当する管理者やAppleのサポートへ確認する方がよいケースがあります。

証明書を更新しても署名できないなら、Profileと秘密鍵を照合する

新しい証明書がアカウントに表示されていても、署名を実行するMacに必要な秘密鍵があるとは限りません。署名には証明書だけでなく対応する秘密鍵が必要です。キーチェーンで署名IDが揃っているか、実行アカウントから秘密鍵を使えるかを確認します。

次にProvisioning Profileの期限、App ID、署名対象の証明書、必要な能力を照合します。Profileに古い証明書だけが含まれている場合、新しい証明書に切り替えても署名に使えないことがあります。AppleのProfileの編集・ダウンロード・削除手順に沿って、手動管理のProfileを更新または再生成してください。

iOS分配証明書を更新したあと、Provisioning Profileも作り直す必要がありますか？
必ずしも毎回作り直すとは限りません。現在のProfileが有効で、新しい証明書やApp ID、必要な能力と整合しているかを先に確認してください。Profileに旧証明書しか登録されていない、期限が切れている、必要な能力が含まれていない場合は、AppleのProfile更新に関する案内を確認し、該当するProfileを更新または再生成します。

Xcodeの自動署名を使う構成と、アカウントから手動で取得したProfileを使う構成では、確認箇所が異なります。自動署名なら対象のTeamと署名設定、手動管理なら実際に参照しているProfileのファイルと内容を確かめます。Xcodeの設定画面に新しい証明書が見えることだけで、ビルドに使われるProfileまで更新済みとは判断しないでください。

証明書を撤回して作り直す前に、ビルドログが示す失敗対象を特定してください。会員状態、権限、Appleのサービス側に問題がある場合、署名資産の再作成では原因が解消しません。

リモートMacの署名失敗は、実際の実行先で判定する

ローカルMacで署名できても、CIや自動化の実行先に秘密鍵や更新済みProfileがなければ、リモートMacでは失敗します。ビルドを開始したワークフロー名だけで判断せず、ログに記録された実行ホスト、Xcode、実行ユーザー、署名設定を確認してください。

証明書を更新したのに、リモートMacではなぜ署名に失敗するのでしょうか？
ローカル環境だけに新しい証明書やProfileが存在し、実際のビルド環境へ反映されていない可能性があります。fastlane matchを使っている場合は、公式ドキュメントを参照し、ビルド時に取得した署名資産と実行環境を確認します。ここでは同期の再初期化ではなく、同期結果が対象のMacと実行アカウントから利用できるかを調べます。

問題の切り分けは、次の条件で進めます。

• 失敗ログが会員資格やチーム権限を示している場合は、証明書を再発行せず、アカウント状態の確認へ戻ります。
• 署名IDに対応する秘密鍵が実行先にない場合は、秘密鍵を含む正しい署名IDを安全に配置し、同じ実行アカウントから利用できるかを確認します。
• Profileが期限切れ、または新しい証明書やApp IDと不一致なら、対象のProfileを更新して実行先が参照するファイルを切り替えます。
• ローカルとリモートでXcodeの署名設定が異なる場合は、リモート側のTeam、署名ID、Profile指定を修正してから再実行します。
• 状態が有効でもArchiveに失敗し、ログがアカウント権限やApple側の問題を示す場合は、撤回や再作成を止めて原因を確認します。

この分岐で、直す対象を「証明書」「Profile」「実行環境」「アカウント」に絞れます。ローカルのキーチェーンを更新しただけで、リモートMacの同期も完了したと見なさないでください。

Archiveで修復を確定し、Macの運用方法を選ぶ

修正後は、公開時と同じ配布方式でArchiveまたは書き出しを実行し、ビルド成果物の署名ID、Profile、App ID、必要な能力が意図したものと一致するかを確認します。その後、アップロード工程の結果まで追跡してください。Archiveだけが成功しても、署名対象やアップロード先の確認が済んだことにはなりません。

公開用の署名を安定して扱うには、秘密鍵の保管とアクセス権限も運用に含めます。チームで共有する署名資産についてはAppleの証明書共有ガイドを確認し、誰が更新し、どのビルド環境へ反映したかを記録してください。

手元のMacだけに依存すると、空き容量や常時稼働の確保、複数メンバーでの利用が負担になることがあります。一方、一般的なCI環境では、署名用の鍵やmacOS上の設定を自分の要件どおり管理しにくい場合があります。公開前の一時的な検証や、必要な期間だけ使う署名環境なら、実機購入や保守に代えてMacDateのリモートMacを利用する選択肢があります。長期にわたる高負荷運用や物理インターフェースが必要な用途は、自前のMacが適する場合もあります。運用形態を比較するならベアメタルと仮想化の違い、費用面を確認するならMac miniの料金ガイドも参考になります。

証明書とProfileの状態をローカルで確認できたら、次は実際のリモート環境でArchiveと署名を検収してください。公開作業の期間だけmacOS環境が必要な場合は、MacDateの利用方法を確認し、必要な期間やビルド頻度に合うかを判断できます。