Macを導入している企業では、故障による端末交換や新入社員への端末配付に備えて、必要な業務アプリを確実に導入できる準備が欠かせません。MDMによる自動配布を含め、社内で管理するインストーラを使う場合、そのファイルを2027年2月以降も利用できるか、確認が必要です。
Appleは2026年10月1日、旧Developer ID中間認証局「Developer ID Certification Authority（Sub-CA）」が、2027年2月1日に有効期限を迎えると告知しました。旧Sub-CAから発行されたDeveloper ID証明書で署名されたインストーラパッケージ（.pkg）では、同日以降インストールできなくなるとしています。
開発元には、新しい証明書の取得と既存の.pkgの再署名が求められます。企業のMac管理者も、配布サーバーや共有フォルダーに置いたファイルを確認し、必要なパッケージを期限後も導入できる状態にしておく必要があります。
Appleが2026年10月1日に開発者向けサイトで公開した、旧Sub-CAの有効期限終了に関する告知。
︎動作確認に加えて、再導入用ファイルの点検を
Developer IDは、Mac App Store以外で配布するソフトウェアの署名に使う証明書です。開発元や署名後の改ざんの有無を確認する仕組みを支えており、アプリ本体に署名する「Developer ID Application」と、インストーラパッケージに署名する「Developer ID Installer」があります。
Developer IDによる署名では、アプリ本体と.pkgで使う証明書が異なり、.pkgには「Developer ID Installer」を使用します（WWDC19「All About Notarization」より）。
今回期限を迎えるのは、これらの証明書を発行していた旧Sub-CAです。Appleは2022年から現行の中間認証局「G2」への移行を進めてきました。
期限後の扱いは、アプリ本体と.pkgで異なります。Appleは、署名・公証済みで安全なタイムスタンプを持つMacアプリは引き続き動作し、今回の期限終了に伴う対応は不要と案内しています。一方、旧Sub-CA由来の証明書で署名された.pkgについては、期限前にすべて再署名するよう求めており、公証済みのパッケージを除外する記述もありません。
つまり、影響を受けるのはインストーラです。期限終了後もMac上のアプリは引き続き動作しますが、同じアプリを新たにインストールする際に、保管中の.pkgが使えなくなる可能性があります。そのため、期限までに普段の動作確認に加え、導入に使用する.pkgの点検が必要となります。
点検はキッティングや障害復旧に使うパッケージから
まず洗い出したいのは、キッティングや障害復旧の手順書で指定している.pkgです。初期導入する業務アプリや自社製ツールのほか、各拠点の共有フォルダーやMDMの配布サーバーに保管しているファイルも確認します。
すべての.pkgが今回の対象になるわけではありません。実際に配布するファイルの署名証明書を調べ、旧Sub-CA由来のものを特定します。自社の証明書はAppleのガイドに沿って発行元を調べ、他社製のパッケージは開発元に確認します。
キーチェーンアクセスで「Developer ID Installer」を選択した画面。証明書の発行元は、証明書の詳細を開いて確認します。
特に注意したいのが、互換性や社内検証の都合で、特定のバージョンに固定しているソフトウェアです。開発元が最新版のインストーラを再署名して提供しても、過去の版まで同様に提供するとは限りません。旧版を使い続ける場合は、期限後も導入できるパッケージを入手できるか、早めに問い合わせておきます。
こうした問題は、新入社員向けのセットアップや、故障したMacの交換時に初めて表面化する恐れがあります。開発元への問い合わせや検証には時間がかかるため、新規導入や復旧に欠かせないパッケージから優先して対応を進めたいところです。
MDMで自動配布している場合も対応状況を確かめる
MDMで自動配布している場合も、パッケージの確認は必要です。 Apple標準のMDMコマンドや宣言型管理による.pkg配布では、端末が検証できる署名が求められます。
ただし、管理製品によって配布方法や署名の要件は異なります。例えばJamf Proは、ポリシー経由の配布では署名を必須としていません。また、内蔵の認証局が発行する証明書を使って署名する方法もあります。こうした独自証明書は、今回期限を迎えるDeveloper IDの旧Sub-CAとは分けて確認します。
注意したいのは、署名が必須でない経路でも、旧Sub-CA由来の証明書で署名された.pkgを期限後に導入できるかどうかは、別に確認する必要があることです。今回確認したAppleとJamfの資料だけでは、その挙動までは判断できません。
「MDMだから自動で対応される」「署名が任意の経路だから影響はない」と判断せず、対象の.pkg、署名に使われた証明書、導入経路を整理したうえで、製品ベンダーへの確認と必要な検証を進めます。
再署名や対応版の入手後は配布元の差し替えまで進める
対象の.pkgが見つかったら、自社で署名するものと、開発元から入手するものに分けて対応します。
自社で署名する場合は、G2から必要な証明書を取得して署名処理を切り替え、配布中の対象パッケージも再署名します。新しい証明書を取得するだけでは、作成済みの.pkgへの対応は完了しません。他社製の.pkgは、開発元に対応状況を確認し、再署名された版を入手します。
Developer ID証明書を作成する際の中間認証局の選択画面。新しい証明書は「G2 Sub-CA」を選んで取得します。「Previous Sub-CA」は、2027年2月に期限を迎える旧認証局です。
対応後のファイルは、配布サーバーや共有フォルダーなどで差し替えます。必要に応じてパッケージのハッシュ値などの関連設定も更新し、社内ポータルのリンクや復旧手順が古いファイルを参照していないかも点検します。
そのうえで、通常の導入経路でダウンロードからインストールまでを確認します。期限前のテストでは、旧Sub-CA由来の証明書で署名された.pkgもインストールできるため、動作確認だけでは対応済みかどうかを判断できません。署名に使われた証明書や、開発元の対応状況もあわせて確かめておきます。
証明書の発行元の判別や、新しい証明書の取得の詳細については、Appleのガイド を参照してください。
︎必要なときに業務環境を再構築できる状態を保つ
点検では、パッケージの用途、保管先、必要なバージョン、担当者、署名証明書、対応状況をひも付けて記録しておくと、確認漏れや差し替え漏れを減らせます。告知から期限までは約4カ月しかありません。期限直前に作業が集中しないよう、計画的に進める必要があります。
加えて、今回の対応を一過性のものにしないこともポイントです。証明書の更新手順に、配布用パッケージの署名状況の確認と、必要に応じた再署名・差し替えを組み込んでおけば、次に証明書が期限を迎えたときにも慌てずに済みます。2027年2月の期限は、日常業務では後回しになりがちな再セットアップの備えを見直し、いざというときに業務環境を確実に復旧できる運用を整える好機でもあります。
ExcelのCopilotに新機能、データの取得・整形からレポート作成まで支援
