期限:Appleは旧Developer ID Certification Authority(Sub-CA)が2027年2月1日に期限を迎えると告知しています。Appleの期限告知 対応:まずCIで使う証明書のIssuerを調べ、旧Sub-CA発行ならG2証明書へ切り替え、隔離したMac CIで署名と公証を検収してください。

この記事は、Developer ID ApplicationまたはDeveloper ID Installerを使ってmacOSアプリを配布する開発者、CI・DevOps担当者向けです。 Mac CIの実行環境やキーチェーンを管理している場合は、実行アカウントでの証明書利用可否も確認してください。 リリース担当者は、アプリとインストーラーパッケージで再署名の要否が異なる点を確認できます。

最終更新:2026年11月7日。期限と成果物の扱いはAppleの告知、証明書の切り替え手順はAppleのDeveloper ID証明書交換ガイドで確認しました。

期限公告を受けた影響範囲

旧Sub-CAの期限が来るからといって、配布済みのすべてのMacアプリを一律に再署名するわけではありません。Appleの説明では、旧証明書で署名されたインストーラーパッケージと、すでに安全なタイムスタンプ付きで公証済みのMacアプリを分けて扱います。

<
成果物旧Sub-CA期限に伴う扱い検収時の判断
Developer ID Installerで署名した.pkg影響を受ける旧証明書で署名したパッケージは、2027年2月1日より前に再署名します。[Appleの期限告知](https://developer.apple.com/news/?id=w4atic4c)新しいDeveloper ID Installer署名を検証し、配布対象を置き換えます
安全なタイムスタンプがあり、公証済みのMacアプリこの期限だけを理由に再署名する必要はありません。[AppleのDeveloper ID案内](https://developer.apple.com/developer-id/)署名、公証、タイムスタンプの証跡を確認します
旧Sub-CA以外の証明書を使う成果物期限日だけでは影響を確定できません証明書のIssuerと用途を実物で照合します
**判断の要点:**日付は棚卸しのきっかけにとどめ、対象かどうかは証明書のIssuerで確定します。アプリのバイナリを変更した場合は、今回の期限とは別に、変更後の署名・公証が必要です。

CIの証明書がどのSub-CA発行かを確かめる

Certificates, Identifiers & Profilesで証明書を確認し、Mac CIのビルド設定、署名スクリプト、キーチェーン設定と突き合わせます。証明書の有効期限だけで判断せず、Issuerを確認してください。期限が近い証明書でも旧Sub-CA発行とは限らず、逆に期限表示だけではチェーンを特定できません。

<
確認方法分かること判定上の注意
開発者アカウントで証明書の詳細を確認証明書の種類、Issuer、有効期間CIが実際に使う証明書か、署名設定と照合します
キーチェーンから証明書を書き出してIssuerを確認実行ノードに取り込まれた証明書の発行元複数の証明書がある場合は、対象の証明書を選んで確認します
署名済み成果物の証明書チェーンを確認成果物に使われた署名IDとチェーンCI設定だけでなく、生成物側の証跡も残します
証明書の書き出し後は、macOSに含まれるopensslでIssuer、Subject、有効期間を確認できます。署名済みアプリではcodesign -dv --verbose=4 App.appも使えますが、出力を見ているだけでCIの実行アカウントが新しい証明書を使えると判断してはいけません。Appleの[コード署名確認手順](https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html)も参照し、証明書の実体と成果物を照合してください。

1. 証明書と署名設定の棚卸し

影響範囲を絞るため、Developer ID ApplicationとDeveloper ID Installerを別々に記録します。前者はMacアプリの署名、後者はインストーラーパッケージの署名用です。片方の証明書をもう片方の用途に流用せず、ビルドジョブごとに使用箇所を追跡してください。Appleの証明書作成説明で用途を確認できます。

棚卸し表には、証明書名、種類、Issuer、使用するCIジョブ、キーチェーン、実行アカウント、署名対象、配布先を記録します。ローカル端末にある証明書と、CIでインポートされる証明書が異なるケースもあるため、リポジトリの設定値だけでなく、実行環境に投入される資格情報までたどります。

2. G2証明書と秘密鍵の引き継ぎ

旧Sub-CA発行と確認できた証明書は、Appleの手順に沿ってG2 Sub-CAの証明書へ置き換えます。Developer ID ApplicationとDeveloper ID Installerの両方が必要なチームは、それぞれの用途で証明書を用意し、署名設定が正しい方を参照していることを確認してください。

証明書の作成担当者と、秘密鍵をCIへ登録する担当者を明確にします。証明書ファイルだけでは署名できないため、秘密鍵との対応、キーチェーンへの取り込み、CIの資格情報更新、旧証明書を参照する変数やスクリプトの修正までを変更記録に含めます。Appleの証明書交換ガイドに沿って更新し、古いXcodeを含む構成では、使用するXcodeの制限や対応条件をAppleの現行説明で個別に確認してください。

注意:証明書を作っただけではローテーション完了ではありません。CIの実行アカウントが対応する秘密鍵を利用できることと、署名コマンドがG2証明書を選択していることを、実際のジョブで確かめてください。

3. 隔離したMac CIで署名・公証を試走

本番ブランチや配布先に影響しない隔離ジョブで、正式なCIと同じ実行アカウント、署名設定、キーチェーンの読み込み方法を使って検証します。開発者の対話セッションで手動署名が通っても、CIの非対話実行で鍵へのアクセスに失敗する場合があるため、手動実行だけで合格にしないでください。

検収では、次の証拠を分けて保存します。

  1. CIが選択した証明書の種類とIssuer。
  2. アプリまたはパッケージの署名検証結果。
  3. 公証サービスへの提出結果と、審査結果の取得内容。
  4. 公証後の配布物が期待した成果物と一致すること。
Appleの[コマンドライン公証ワークフロー](https://developer.apple.com/documentation/security/customizing-the-notarization-workflow)を使う場合も、提出コマンドの終了だけを公証完了の証拠にせず、結果を取得して記録します。[公証済みソフトウェアの配布説明](https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution)を参照し、署名と公証を別々の検収項目として扱ってください。

専用のMac検証環境が手元にない場合は、MACGPUのMac環境案内でリモートMacの利用方法を確認し、検証用の分離方法や資格情報の扱いはチームのセキュリティ要件に合わせて設計してください。証明書保管や鍵管理の機能が確認できていない状態で、サービス側がそれらを代行すると見なすのは避けます。

4. 成果物別の検収と段階展開

.appはcodesign --verify --deep --strict --verbose=2 App.appで署名を検証し、必要に応じてspctlでシステムの評価結果を確認します。これらは同じ確認ではありません。署名の整合性、公証の結果、タイムスタンプの有無を別々に記録し、既存アプリがAppleの条件を満たしているなら、旧Sub-CAの期限だけを理由に再署名対象へ加えないでください。

.pkgは新しいDeveloper ID Installer証明書で署名し、pkgutil --check-signature product.pkgで署名情報を確認します。CIが生成したパッケージを検収対象にし、旧証明書で署名したリリース済みパッケージの一覧も照合します。受け入れたパッケージは配布元を差し替え、古いファイルがダウンロード経路に残っていないかをリリース手順で確認します。

リリース前には、隔離ジョブで合格した署名設定を本番Mac CIへ段階的に反映します。各ノードでIssuerと証明書用途を再確認し、切り戻し先、実行ログ、署名検証、公証結果を記録してください。期限前に全配布経路の更新を終えられない場合は、旧証明書を参照するジョブを止め、承認済みの新証明書を使うリリース経路へ切り替えます。

運用上の注意:証明書を更新した後も、開発者アカウントでIssuerと有効期間を定期的に確認します。G2証明書もAppleの案内に従って将来の更新対象として管理し、失効や期限の検知をリリース前の確認項目に含めます。

5. 公開前の環境選択と期限再確認

ローカルMacだけで運用する方法は、実機や周辺機器を直接扱いやすい一方、CI担当者の端末に依存し、常時稼働やチーム共用の管理が難しくなることがあります。Linux CIは一般的なビルドには使えても、macOS専用の署名・公証工程をそのまま実行できません。自前のMac miniサーバーは継続運用に向きますが、ハードウェアの調達、保守、障害時の復旧をチームで担う必要があります。

一時的な証明書切り替えやリリース前の検収なら、リモートMacを試験環境として使う方法もあります。常時高負荷で長期間運用する場合や、物理インターフェースへの接続が必要な場合は、自社管理のMacを用意する方が適することもあります。必要な期間や運用責任を比較するため、MACGPUのMacレンタル案内も選択肢の確認に利用できます。

公開前にはAppleの証明書交換案内と期限告知をもう一度確認し、Issuer、証明書用途、アプリのタイムスタンプと公証状態、.pkgの再署名状況を照合してください。手元にMacがなく、隔離した署名・公証検収だけを行いたい場合は、MACGPUのリモートMacを短期の検証環境として検討できます。鍵の取り扱いやCIへの組み込み方は、利用前に自社の要件と環境の条件を確認して決めてください。