症状：Developer IDの証明書を更新したのに、署名対象のアプリと.pkgのどちらを再署名すべきか判断できません。
最短の対応：Developer ID G2証明書への移行前に発行元を確認し、旧Developer ID Certification Authorityの影響を受ける.pkgは期限までに差し替えて再署名します。安全なタイムスタンプ付きで公証済みの既存Macアプリは、同じ理由で一律に再署名する必要はありません。Appleは旧機関の有効期限を2027年2月1日と告知しています。Appleの告知を基準に、成果物ごとに判断してください。
Macの独立開発者：Mac App Store以外で配布するアプリの証明書が影響対象かを確認したい方。
Macソフトウェアのリリースチーム：Developer ID Installerを使う.pkgを切り替え、再署名後の導入を検収する方。
CI/CDエンジニア：ビルド環境の証明書、秘密鍵、キーチェーン参照を更新する方。
最終更新：2026年10月28日。期限と影響範囲はAppleの2026年10月1日付告知、証明書の確認方法はDeveloper ID証明書の置き換え手順に基づいています。
最初に確認するのは証明書名ではなく発行元です
Developer ID Applicationはアプリへの署名に、Developer ID Installerはインストーラーパッケージへの署名に使う証明書です。AppleのDeveloper ID証明書の説明で用途を照合し、配布物がアプリなのか.pkgなのかを先に分類してください。
証明書一覧に表示される名前や有効期限だけでは、対象となる旧証明機関から発行されたかを確定できません。Apple Developerアカウントの証明書情報と、署名に使うMacのキーチェーンにある証明書の発行元を照合します。移行時の識別には、AppleのDeveloper ID中間証明書に関する案内と置き換え手順を参照してください。
| 配布物・証明書 | 旧機関の影響が確認された場合 | 移行後の検収ポイント | 判断 |
|---|---|---|---|
| Developer ID Applicationで署名したアプリ | 安全なタイムスタンプ付きで公証済みの既存アプリは、期限到来だけを理由に一律再署名しない | 新規ビルドをG2で署名し、配布予定のアプリを検証 | 条件付きで継続 |
| Developer ID Installerで署名した.pkg | 期限までに代替証明書へ切り替えて再署名する | 署名状態を確認し、実際の配布形態で新規インストールを試す | 期限前に移行 |
| 旧機関の発行元と一致しない証明書 | 今回の告知だけを理由に急いで再署名しない | 証明書の種類・発行元・用途を記録し、通常の更新計画に従う | 個別確認 |
ここでいう「継続」は、今後の証明書更新やOS側の個別要件が不要という意味ではありません。G2証明書にもそれぞれ有効期限があるため、Appleの証明書管理手順に従って更新時期を管理します。
独立開発者向け：旧Sub-CA発行かをどう見分けるか
まずアカウント上の証明書一覧でDeveloper ID ApplicationとDeveloper ID Installerを別々に確認し、発行元情報を記録します。続けて、署名に使うMacのキーチェーンにある該当証明書を開き、発行者の情報がAppleの案内する旧機関に該当するか照合します。
証明書の表示名や期限だけを見て「旧証明書」「G2」と決めつけないでください。発行元の確認に迷う場合は、署名に使う証明書を特定してからAppleの置き換え手順と照合します。
Developer ID G2証明書と旧証明書の違いは、名前の見た目だけで判定するものではありません。Appleの中間証明書情報と証明書置き換え案内を使い、どの機関が署名した証明書かを確認してください。旧機関の証明書に該当すると判断できた場合に、対象の証明書種別に応じて代替証明書の発行・切替へ進みます。
Macソフトウェアチーム向け：アプリと.pkgを分けて移行する
Macアプリとインストーラーパッケージでは、移行判断が異なります。Appleの告知は、旧証明機関で署名された.pkgと、安全なタイムスタンプが付与され公証済みの既存Macソフトウェアを同一扱いしていません。したがって、プロジェクトの配布物を洗い出し、アプリと.pkgを別の検収対象として管理します。
| 評価項目 | Macアプリ | .pkg |
|---|---|---|
| 旧機関の期限による扱い | 安全なタイムスタンプ付きで公証済みの既存アプリは、告知を理由に一律再署名しない | 影響対象なら期限前に代替証明書で再署名する |
| 配布物の確認 | 実際に配布しているアプリ本体と署名を確認 | インストーラーの署名と配布ファイルを確認 |
| 移行後の確認 | 新しい署名と、必要に応じた公証・配布検証 | 新.pkgを署名検証し、利用者側に近い環境で導入を確認 |
Appleの案内は、旧証明機関の期限を2027年2月1日とし、影響を受ける.pkgについて期限前の証明書置き換えと再署名を求めています。期限の告知を踏まえ、以前の.pkgがその日以降も問題なく導入できると独自に保証せず、対象なら新しい証明書で作成したパッケージを検収してください。一方、既存アプリについては、告知に記載された安全なタイムスタンプと公証の条件を満たすかを確認し、条件を確認できない成果物は個別に調査します。
CI/CD担当者向け：隔離したリリースで署名経路を確かめる
macOS CIの証明書移行は、証明書ファイルを入れ替えるだけでは完了しません。ビルド機にある秘密鍵と証明書の組み合わせ、キーチェーンへの登録、署名設定がどのIDを参照しているかを一続きのリリース経路として点検します。AppleのDeveloper ID証明書の置き換え手順に沿って証明書を準備し、具体的な署名・公証操作はAppleの公証ガイドと公証ワークフローの説明で確認してください。
本番の署名ジョブを直ちに置き換えず、隔離したリリースタスクでG2証明書を使った成果物を生成します。アプリなら署名と必要な公証結果、.pkgなら署名と新規インストールまで確認してから正式なジョブへ反映します。認証情報の保管方法やコマンドは構築環境によって異なるため、ここで一律のコマンド手順を適用せず、Appleの公式文書と組織の秘密情報管理規則に照らして設定してください。
切替前に実行する確認項目
- [ ] Developer ID ApplicationとDeveloper ID Installerを分けて、アカウント上の証明書とキーチェーン内の証明書を確認した
- [ ] 各証明書の発行元を確認し、旧Developer ID Certification Authorityの対象か記録した
- [ ] アプリ、.pkg、CI内の署名設定を棚卸しし、どの成果物がどのIDを参照するか特定した
- [ ] 代替証明書と対応する秘密鍵を用意し、隔離した署名タスクで成果物を作成した
- [ ] アプリは署名・公証条件を確認し、.pkgは署名検証と新規インストールを試した
- [ ] リリース担当者が検収結果を確認してから本番CIを切り替え、失敗時の旧ジョブ復帰条件を決めた
新しい署名証明書を導入した後は、ビルドが成功したという事実だけで受け入れ完了にしないでください。実際に配布する形式で検査し、署名・公証上の問題がある場合はAppleの公証トラブルシューティングも参照します。証明書の読み込みや署名結果の判定に不一致があるときは、本番切替を止めて原因と復帰手順を確認します。
担当者を割り当て、期限前に切替判断を終える
独立開発者は証明書と配布物の確認、リリースチームはアプリ・.pkg別の試験、CI担当者はキーチェーンとジョブ設定の更新を担当します。チーム責任者は、証明書の棚卸し、代替証明書の発行、試験成果物の受け入れ、本番切替の承認者を明確にし、検収が通らない場合に切替を止める条件も共有してください。
現在の時点で発行元の確認を始め、旧機関の証明書を使った.pkgがあれば2027年2月1日より前に置き換えと再署名を完了させる計画にします。期限と影響範囲を基準にしつつ、G2証明書も有効期限に応じて更新が必要です。アプリ側は公証と安全なタイムスタンプの条件を確かめ、対象外の成果物まで一律に再署名する運用は避けてください。
まだ物理Macや検証用のmacOS環境を用意できていない場合は、ローカル機材の購入、既存のCI環境の流用、遠隔Mac環境の利用を、アクセス権限・秘密鍵の管理・検収方法の観点から比較できます。ArmMacsのサポート情報で利用条件を確認し、短期の移行検証や一時的な署名環境が必要な場合はレンタルプランを検討してください。長期にわたる常時稼働や物理接続が必要な運用では、自社管理のMacを選ぶほうが適する場合もあります。
ArmMacs Cloud Mac
署名移行後の検収に、ArmMacsの専有物理Macをご活用ください
仮想環境ではない専有物理Macで、証明書の切替後にアプリやインストーラの署名を実際の環境で確認できます。