notarytool 公証失敗の排查チェックリスト 2026

notarytool submit の実行結果で最初に保存するのは、Submission ID、提出対象、返却されたstatusです。ログを読む前に同じファイルを作り直すと、後から原因と成果物の対応を追えなくなります。

xcrun notarytool submit "<配布ファイルのパス>" \
  --keychain-profile "<Keychain Profile名>" \
  --wait \
  --output-format plist > "<提出結果の保存先>"

処理を待たずに終了する構成では、返されたSubmission IDを使ってログを取得します。

xcrun notarytool log "<Submission ID>" \
  --keychain-profile "<Keychain Profile名>" \
  "<公証ログの保存先>"

Appleの公式手順でも、提出結果だけでなくログ内の問題を確認し、成功時も警告を読む運用が案内されています。公証はApp Reviewではなく、Appleのサービスによる自動検査です。公証成功、チケット付加、Gatekeeperによる起動確認は同じ結果ではありません。
Appleの公証ワークフロー
notarytoolのカスタム運用とログ取得 (developer.apple.com)

注意: Invalid は原因名ではありません。ログのpath、message、問題の対象ファイルを保存し、外側のAppだけでなく内部オブジェクトまで確認してください。

Appleは、Developer IDで署名したソフトウェアに公証チケットを付け、Gatekeeperがオンラインまたは付加済みのチケットを確認する流れを説明しています。つまり、codesignの検証成功は署名層の合格であり、公証サービスやGatekeeperの合格を意味しません。
Developer IDの公式サポート情報 (developer.apple.com)

macOS AppやFramework、プラグイン、XPC Service、コマンドラインツールには、配布方法に合った署名 identity が必要です。Appや内部実行ファイルにはDeveloper ID Application、インストーラーパッケージにはDeveloper ID Installerを使います。Mac App Store用や開発用の証明書を流用しても、外側のAppだけでは判断できません。

codesign --verify --deep --strict --verbose=4 "<Appのパス>"
codesign -dv --verbose=4 "<Appのパス>"
security find-identity -v -p codesigning

ログに、無効なバイナリ署名、Developer IDではない証明書、署名後に変更された内容が示されていれば、再公証では直りません。秘密鍵がKeychainにない、証明書と秘密鍵の組み合わせが崩れている、セキュアタイムスタンプが付いていない場合も、提出前に署名工程へ戻ります。

Appleは、配布用のコードにはDeveloper ID証明書を使い、署名後の変更を避け、セキュアタイムスタンプを含めるよう案内しています。証明書の有効性や権限は、Apple Developerの証明書情報とKeychainの実状態で確認してください。
Resolving common notarization issues
Developer ID証明書の公式情報 (developer.apple.com)

Hardened Runtimeを有効にするだけでは十分ではありません。アプリが実際に必要とする例外だけをentitlementsへ残し、デバッグ用の権限やJIT、未署名の実行メモリを許可する設定を本番成果物へ持ち込まない構成にします。

確認するコマンドは次のように、署名前の設定ファイルと署名後の実体を分けて使います。

codesign -d --entitlements :- "<Appのパス>"
codesign -d --verbose=4 "<Appのパス>"

切り分けるポイントは3つです。

• entitlementのXML形式や値が不正になっている。
• アプリの機能に不要な例外を追加している。
• 署名後にFramework、実行ファイル、リソースを変更している。

特にcom.apple.security.get-task-allowを本番用に有効化したままにしないでください。Appleの公証要件では、Hardened Runtime、適切なentitlements、正しい形式の設定が確認対象です。
Hardened Runtimeと公証の問題解決 (developer.apple.com)

外側のAppが署名済みでも、内部のFramework、Plug-in、XPC Service、ヘルパーツール、第三者バイナリが不正なら公証は失敗します。まずログに記載されたpathを起点に、対象ファイル単体の署名を検証してください。

codesign --verify --strict --verbose=4 "<内部オブジェクトのパス>"
spctl --assess --type execute --verbose=4 "<Appのパス>"

ZIPは内部のApp署名が中心です。PKGはインストーラー署名と、内部に含めたAppや実行ファイルを分けて確認します。DMGは作成後に内容を変更していないか、イメージがstaplerで書き込み可能かを確認します。

配布形式が違っても、ログを読む、内部コードを検証する、公証後に最終配布物を評価するという基本は変わりません。DMGだけ成功した結果を、後から作ったPKGの合格証明にはしないでください。

経験則: Appを署名した後にDMGを作り直す工程があるなら、DMG作成後のファイルを提出対象として保存してください。提出後にイメージを差し替えると、付加したチケットと配布物の対応が崩れます。

Keychain Profileの認証失敗は、Appleのスキャンでコードが拒否されたこととは別です。秘密鍵ファイルのパス、Issuer ID、Key ID、権限、Keychain Profile名を確認し、スクリプトへ認証情報を直書きしない構成にします。

公証成功後は、実際に配布するDMGやPKGへstaplerを実行し、続けて検証します。

xcrun stapler validate "<配布ファイルのパス>"
xcrun stapler staple "<配布ファイルのパス>"
spctl --assess --type open --context context:primary-signature \
  --verbose=4 "<配布ファイルのパス>"

staplerが失敗したときは、対象が公証に提出したファイルと同一か、書き込み可能か、チケットがオンラインで確認できるかを分けて確認します。公証サービスが受理したことと、手元の配布物へチケットを付加できたことは別の状態です。

単発の修復で終わるなら、ローカルMacで署名と公証を完了させても構いません。ただし、公開のたびに証明書を再登録する、Keychain Profileが消える、Xcode Command Line Toolsの選択が変わる、ログが残らないという状態なら、環境の再現性が不足しています。

次の条件で判断してください。

• 1回限りの公開で、物理Macを常時使えるなら、ローカル環境で修復し、成果物とログを保存します。
• 週単位で公開し、署名鍵とKeychainを継続利用するなら、専用のMac環境へ移し、アクセス権と復元手順を固定します。
• CIから常時公証し、失敗ログを保管するなら、リモートMac上でツール選択、証明書、Keychain Profile、スクリプトを検証します。
• 物理USB機器や常時ローカル接続が必須なら、リモートMacではなく手元のMacを優先します。

リモート環境を使う場合は、秘密鍵を共有フォルダへ置かず、作業用アカウント、Keychain、ログ保存先を分離してください。CALMVPSのMacレンタル料金と利用条件を確認する場合も、価格だけでなく、継続利用、アクセス方式、作業環境の保持条件を先に見ます。必要ならリモートMacの申込み手順と、自分の公開スクリプトを照合してください。

• [ ] Submission IDと提出対象のハッシュを保存した
• [ ] notarytool logの結果を脱敏して保管した
• [ ] App、Framework、Plug-in、XPC Service、ヘルパーツールを検証した
• [ ] Developer ID ApplicationとDeveloper ID Installerを用途別に確認した
• [ ] Hardened Runtimeを有効にした
• [ ] 不要なentitlementsとデバッグ権限を削除した
• [ ] 署名後に配布物を変更していない
• [ ] DMG、PKG、ZIPのうち実際に配布する形式を提出した
• [ ] staplerで最終配布物を検証した
• [ ] Gatekeeper相当の検証を配布後のファイルで実行した
• [ ] リモートMacで証明書、Keychain、ツール選択、ログ保存を再実行した

notarytool 公証失敗を直すだけなら再送で終わる場合もあります。しかし、署名 identity、秘密鍵、Keychain、ツールチェーン、ログ保存のどれかが毎回変わるなら、次のリリースでも同じ障害が起きます。手元のMacを常時稼働できない、または公開用の環境を分離したい場合は、CALMVPSのリモートMacを一時的な作業場所ではなく、署名からGatekeeper検証までを繰り返せる公開サーバーとして評価するのが現実的です。