2026年10月4日更新：期限前に旧Sub-CAを確認し、検証後に切り替えます

2027年2月1日に旧Developer ID Certification Authority（Sub-CA）が期限を迎えるため、まずDeveloper ID ApplicationとDeveloper ID Installerの発行元を確認し、影響する証明書にはG2の代替証明書を用意してください。隔離したMac CIでアプリとpkgを別々に検証し、合格したジョブから段階的に切り替えます。Appleは、旧Sub-CAが発行した証明書の期限後の扱いと、既存アプリ・pkgへの影響を公式告知で説明しています。

対象となる方 - macOSアプリやインストーラーパッケージの署名・公開を担うエンジニアリング責任者。 - 企業のMac CIやリリース基盤を管理するIT・プラットフォーム担当者。 - Apple Developerチームの証明書と秘密鍵を管理するアカウント担当者。

データ確認日：2026年10月4日。Appleの告知と証明書の置き換え手順を参照しています。公開前には最新の案内を再確認してください。

まず、CIノードと署名対象を棚卸しします

影響確認は証明書名や有効期限だけで済ませず、Mac CI上で実際に使う署名ID、証明書の発行元、秘密鍵の保管場所、成果物をひも付けます。Apple Developerアカウントの証明書情報と、各CIノードのキーチェーンにある証明書を照合してください。

  • [ ] CIノードごとに、署名に使うキーチェーンと実行アカウントを記録する。
  • [ ] アプリ署名用のDeveloper ID Applicationと、インストーラーパッケージ用のDeveloper ID Installerを区別する。
  • [ ] アプリ、pkg、配布先、署名ジョブ、担当チームを一覧にする。
  • [ ] 証明書の発行元と中間証明書をApple Developerアカウントおよび証明書情報で確かめる。
  • [ ] 秘密鍵の保管場所、アクセス権限、更新責任者を記録する。

Developer IDはmacOSアプリの配布に使う証明書であり、Apple Distributionとは用途が異なります。証明書の種類を取り違えないよう、Appleの証明書タイプの概要も参照します。

次に、旧Sub-CAの影響を成果物ごとに判定します

旧Sub-CAの発行証明書を使ったpkgは、2027年2月1日以降にインストールできなくなるとAppleが案内しています。一方、旧証明書で署名され、安全なタイムスタンプを含み、公証済みの既存macOSソフトウェアは引き続き動作します。これらの条件と日付はAppleの告知で確認できます。

つまり、すでに公開したアプリを一律に再署名するのではなく、次回更新とpkgのインストール経路を優先して調べます。将来の更新には新しい証明書が必要で、安全なタイムスタンプを含める必要があります。アプリの署名・公証と、pkgの署名・インストール確認は、別々の受け入れ項目として扱ってください。

旧Sub-CA由来の証明書はどう見分けますか？

証明書名や失効日から推測せず、証明書の発行元（issuer）とSub-CAの情報をAppleの手順に照らして確認します。Developer ID証明書の置き換え案内にある識別方法を使い、該当する証明書のシリアル番号や保管場所も棚卸し表に残してください。

Developer ID Applicationはアプリ本体の署名に、Developer ID Installerはインストーラーパッケージの署名に使われます。片方の確認結果をもう片方に流用せず、証明書タイプごとに発行元と署名ジョブを照合します。

署名済みpkgと公証済みアプリはどう扱いますか？

期限後にインストールできなくなる対象としてAppleが明示しているのは、影響を受けるDeveloper ID Installer証明書で署名されたpkgです。公開済みpkgが今後もインストール可能だと仮定せず、利用者が取得する場所、インストール時期、再配布の有無を確認し、新証明書で作成したpkgの配布計画を用意します。

安全なタイムスタンプ付きで公証済みの既存アプリは引き続き動作します。ただし、将来の更新を同じ証明書で署名し続けられるという意味ではありません。公証の前提条件はAppleのmacOSソフトウェア公証ガイドで確認し、提出に失敗した場合は公証でよくある問題の説明も参照します。

代替証明書を準備し、秘密鍵の扱いを固定します

影響が確認できた証明書について、Apple Developerアカウントから対象用途に合う代替証明書を申請します。Application用とInstaller用を必要に応じて分け、証明書チェーンで選ぶ中間証明書がG2 Sub-CAであることを、申請時点のApple公式手順で確認してください。

秘密鍵はCI設定に無制限に複製せず、チームの資格情報管理ルールに沿って生成・保管・アクセス制御を行います。申請できる担当者の役割、利用するツールの前提条件、証明書数の上限は変更される場合があるため、作業前に置き換え手順を再確認します。現在のApple Developerアカウントで確認できない条件は、過去の運用記録だけで決めず、公式画面と案内を根拠にします。

隔離したMac CIでアプリとpkgを別々に検証します

本番キーチェーンや公開ジョブに先行して新証明書を追加し、隔離ノードまたは本番へ影響しない検証ジョブで署名から配布まで通します。手元の管理者アカウントで署名できても、CIサービスアカウントから同じ秘密鍵にアクセスできるとは限りません。実際の実行アカウントで確かめ、ログに証明書の識別情報を残します。

  • [ ] アプリの署名が、意図したDeveloper ID Applicationと新しい証明書チェーンで行われる。
  • [ ] 公証の提出と結果確認が成功し、安全なタイムスタンプを含む配布成果物を検査できる。
  • [ ] pkgが意図したDeveloper ID Installerで署名され、検証用Macでインストールできる。
  • [ ] CIサービスアカウントが必要な秘密鍵だけを参照できる。
  • [ ] 失敗ログ、使用証明書、成果物の識別情報を後から追跡できる。

単発の成功だけで本番許可を出さず、定期実行や対象リポジトリごとの署名設定も確認します。署名・公証の失敗が出た場合は、原因が証明書、秘密鍵へのアクセス、公証の提出条件のどこにあるか切り分け、修正後に同じ検証を再実行します。

合格条件を決めてから、本番ジョブを段階的に切り替えます

置き換え前の証明書をすぐ削除すると、未発見のジョブや切り戻し調査に必要な情報まで失うおそれがあります。まず対象ジョブ、責任者、切り替え単位を確定し、旧証明書がどこで参照されているかを確認したうえで、アプリとpkgのジョブを段階的に新証明書へ移します。

切り替え後に旧証明書を使って再署名する前提の回退計画は避けてください。問題が出た場合は、影響する公開を停止し、新証明書での署名・公証・インストール検証をやり直すなど、証明書の利用可否に依存しない手順を用意します。

切り替え判断 - 発行元が旧Sub-CAではないと確認できた場合は、その証明書を今回の置き換え対象から外し、通常の更新管理を続けます。 - 旧Sub-CA発行と確認できた場合は、G2の代替証明書を隔離環境で検証してから、本番ジョブを段階的に切り替えます。 - 発行元を確認できない場合は、本番変更を保留し、Appleの案内とアカウント上の証明書情報を照合します。 - アプリまたはpkgの検証が未完了の場合は、当該成果物の公開を許可せず、検証ログが揃ってから再判定します。

Mac CIノードの追加や分離が必要な場合は、社内ノードの増設、物理Macの購入、リモートMacの利用を運用条件で比較します。物理購入は初期調達や保守の手配が必要で、既存ノードの共用は権限境界や変更時の影響範囲を確認しなければなりません。短期間だけ隔離環境が必要なチームには、週・月・四半期単位で利用できるRUVCLOUDのリモートMacが選択肢になりますが、長期の常時高負荷運用や物理接続が必要な用途では、自社保有環境との比較が必要です。利用条件を調べる場合は料金案内を確認し、環境の利用を検討する際はRUVCLOUDの申し込みページで提示される内容を基準にしてください。

最後に、リリース許可の証拠をまとめます

公開を許可する前に、証明書の発行元とタイプ、アプリ・pkgそれぞれの署名結果、公証結果、CIサービスアカウントの権限、切り替え履歴、回退条件を一つの記録にまとめます。旧証明書の使用箇所が未確認、実行アカウントでの検証が未完了、または配布成果物の証拠が不足している場合は、対象ジョブのリリースを保留します。

社内のMac CIを変更すると、調達・保守の調整や共有ノードの権限整理が残ることがあります。反対に、レンタル環境でも秘密鍵の保管責任やアクセス設計はチーム側で確認が必要です。証明書移行のために一時的な隔離環境や追加ノードが必要で、物理Macの調達を避けたい場合は、RUVCLOUDのリモートMacを検証候補に加え、実際の署名ジョブとセキュリティ要件を満たすか確認してから選定してください。