macOS 27 Mac App公証前の確認方法：2026年チェックリスト

macOS 27はApple silicon搭載MacのみをサポートするとAppleが案内しています。この環境でMac Appを直接配布する場合は、Developer ID署名、公証結果、最終成果物からの起動を別々に確認してください。Mac App Store経由のアプリには、同じ公証手順を機械的に当てはめません。まず隔離したビルド環境で検収し、合格した手順だけを正式公開に使います。AppleのmacOS 27リリース情報で、対応環境も確認してください。

直接配布するMac Appの署名・公証・配布ファイルを公開前に確認したい独立開発者向けです。
DMGとPKGの検収を分けたい小規模チームや、遠隔Macを継続的な公開環境に使えるか判断したい開発者にも役立ちます。

最終更新：2026年11月6日。確認資料：Apple Developerの公証ガイド、notarytool関連文書、macOS 27リリース情報。

配布経路ごとに異なる検収対象

最初に決めるのは、公証をするかどうかだけではありません。ユーザーに渡すものがアプリ本体、DMG、PKG、またはMac App Store経由のどれかを特定し、その配布物を検収の単位にします。

Appleは、macOSソフトウェアの直接配布に関する公証手順を案内しています。提出物の種類や署名の条件は、Appleの公証ガイドとMacソフトウェアのパッケージング資料を配布形式に合わせて確認してください。

直接配布では、Developer ID署名に加えてHardened Runtimeなどの要件をAppleの案内に照らして確認します。Hardened Runtimeの説明を参照し、必要なエンタイトルメントがある場合は、理由と設定をプロジェクト記録に残してください。署名そのものの状態はAppleのコード署名サービス資料で確認できます。

DMGでは、内部のアプリだけが公証済みでも、ユーザーが取得するイメージ全体の検収が済んだとは限りません。PKGも同様に、インストーラーの結果と、インストール後に配置されたアプリの署名状態を混同しないことが重要です。Mac App Storeの配布は、Appleのアプリ配布に関する説明に沿ってストア提出経路を検収し、直接配布向けのDeveloper ID公証フローとは分けます。

判定を分ける条件

以下の条件で検収経路を選びます。判定欄はAppleの認証区分ではなく、公開作業の抜けを見つけるためのプロジェクト内の評価です。

• 直接配布し、Developer IDで署名する場合は、署名・Hardened Runtime・公証結果・ユーザーに渡すファイルからの起動をすべて確認します。一つでも証跡がなければ、正式公開には進まず隔離環境で再確認します。
• DMGを配布する場合は、アプリ単体の検収で止めず、配布用DMGを開いて中のアプリを起動します。DMGを作り直した場合は、新しいイメージを検収対象に戻します。
• PKGを配布する場合は、インストーラーの署名と公証、インストール後のアプリの署名状態を分けて記録します。アプリ単体の確認をPKG全体の合格に置き換えません。
• Mac App Storeで配布する場合は、直接配布用の公証手順からいったん離れ、ストア提出物と公開後の配信経路を確認します。
• 対象環境がmacOS 27の場合は、Appleが示すApple silicon対応の境界を確認し、OS互換性と公証の合否を別の判定項目にします。

公証サービスの受理は、アプリがすべての対象Macで起動する証明ではありません。提出結果、最終成果物の同一性、対象環境での起動記録をそろえて、公開可否を判断してください。

よくある確認事項

macOS 27向けの公開前検収で、署名以外に何を見るべきですか。
アプリの署名だけで終えず、提出物の公証結果とユーザーが取得する最終ファイルを照合します。macOS 27の対応環境で実際に起動し、起動時の表示や主要な初期動作を記録してください。Appleのサポート範囲とプロジェクト独自の対応範囲も分けて残します。

Developer IDで署名した後、公証が完了したことをどう確認しますか。
notarytoolで提出した対象、サービスから返された状態、関連ログを保存し、提出したファイル名やハッシュなどで最終成果物と照合します。チケットを付与・検証できる対象では、その処理結果も記録します。公証のワークフローはAppleのカスタマイズ資料を確認してください。

DMGとPKGの検収を同じ手順にできますか。
共通の記録様式は使えますが、検収対象は分けます。DMGはイメージをマウントした後のアプリ起動まで確認し、PKGはパッケージ自体とインストール後のアプリを別々に確認します。作成し直した配布ファイルは、以前の結果を流用せず再検収します。

Mac App StoreのアプリもDeveloper IDで公証しますか。
ストア配布には、直接配布向けのDeveloper ID公証手順をそのまま適用しません。ストアの提出物、審査・公開の状態、ストアから取得したアプリの動作を確認します。配布経路を途中で変更した場合は、変更後の経路に対応した検収記録を作ります。

遠隔Macで署名・公証の検収を完結できますか。
必要なmacOS環境と開発ツールにアクセスでき、認証情報を適切に保護できるなら、遠隔Mac上でビルドから公証結果の確認まで進められます。ただし、macOS 27の対象環境で起動確認できることが別途必要です。作業ログ、提出物、最終配布ファイルを同じリリース記録にまとめます。

遠隔Macで証跡をそろえる手順

公開前の流れは、次の順にすると提出対象と配布物の取り違えを見つけやすくなります。

• 作業環境を分けます。 正式公開に使う資格情報や既存の配布物をそのまま流用せず、隔離したビルド環境を用意します。対象OS、Xcodeのバージョン、ビルド設定、対象アーキテクチャを記録します。Xcodeのアーカイブ手順はAppleのアーカイブ工程資料を参照してください。
• 配布経路と提出物を固定します。 アプリ直接配布、DMG、PKG、Mac App Storeのどれかを選び、何を提出し何をユーザーに渡すか明記します。公開後にファイルを作り直したら、以前の検収結果を引き継がない運用にします。
• 署名設定を確認します。 Developer IDの署名状態、Hardened Runtime、必要なエンタイトルメントを確認します。証明書やプロファイルの扱いは、担当者と保管場所を含めて記録し、秘密情報をログへ出さないようにします。
• notarytoolの結果を保存します。 提出した対象とサービスの結果を照合し、ログもリリース記録にひも付けます。受理結果だけをスクリーンショットで残すのではなく、後から対象と状態を特定できる情報を保管します。
• 配布ファイルを使って起動します。 DMGならマウントしたイメージから、PKGならインストール後のアプリから確認します。直接配布では実際に渡すアプリを使用します。起動した環境と結果を記録し、ビルド時のテストとは区別します。
• 記録を照合して公開します。 署名情報、公証結果、成果物の識別情報、起動確認を一つのリリース単位にまとめます。Appleの資料が更新された場合は、現行の手順と差がないか再確認します。

遠隔Macでも、この作業を同じ環境で繰り返せるなら、公証を含む公開手順の再現性を保ちやすくなります。OrbVPSの利用を検討する場合は、先に遠隔Macの利用案内で接続方法や利用条件を確認し、必要なツールと資格情報の管理方法が合うか判断してください。

公開環境を固定する選択

手元のMacだけで公開を続ける方法は、追加費用を避けやすい一方、担当者の端末状態にビルド設定や証明書が依存しやすく、空き容量やOS更新、作業時間の調整も必要です。共有のCI環境では実行条件や資格情報の設計が別途必要になり、最終成果物を使った起動確認まで自動化できるとは限りません。

一時的な検収や、チームで繰り返す公開作業のために固定したmacOS環境が必要なら、Macを購入する前にOrbVPSのMacレンタルを比較対象にできます。長期間の高負荷運用や物理ポートへの接続が必須なら、レンタルより実機購入が適する場合もあります。公開頻度、資格情報の管理、対象環境での起動確認を照らし合わせ、必要な期間だけ利用するかを決めてください。

よくある質問