「Invalid」なのに同じZIPを再送信している、または「Accepted」なのに利用者のMacで開けない。macOS App 公証失敗では、まずnotarytoolの状態とログで認証、署名、封装、票据のどこが止まったかを確定し、最終配布物を修正してください。Accepted後もstaple、Gatekeeper、開発用キャッシュのないMacでのインストール確認が必要です。
この手順は、Developer IDでMac App Store以外にアプリを配布する独立開発者、リモートMacやCIでnotarytoolとstaplerを動かす担当者向けです。プラグイン、補助ツール、DMG、PKGを含む小規模チームにも適しています。
失敗直後の時間線：再送信より先に現場を固定する
最初に、Build、Archive、Export、Sign、Package、Submit、Accepted、Staple、Gatekeeperを同じ「公証」として扱わないでください。例えば、Archiveは成功していても、Export後に別の署名が入り、DMG作成時にアプリが変更されていれば、Submitしたファイルは検査前のものと異なります。
0分：状態と証拠を保存する
次の情報を、リリース番号や社内の実行IDと関連付けて保存します。
- notarytoolの実行結果と提出ID
infoで取得した最終状態、コマンドの標準出力、標準エラー- SubmitしたZIP、DMG、PKGのファイルハッシュ
- 実際に選択されたXcodeのパス
- Apple ID、Team ID、証明書名、Bundle ID、ホスト名、認証情報は伏せ字にしたログ
notarytoolの提出、情報取得、ログ取得を含む標準的な流れは、Appleの公証ワークフロー資料で確認できます。資格情報を変更したり証明書を削除したりする前に、現在の成果物とログを別の場所へ退避してください。失敗原因を失ったうえ、元の環境へ戻せなくなるためです。
| 表示・段階 | まず確認する対象 | 次に進む条件 |
|---|---|---|
| 認証失敗・提出未完了 | 資格情報、Team ID、提出コマンド | 認証方式を直し、同一ファイルを盲目的に再送しない |
| 処理中 | 提出ID、サービス状態、ログ取得可否 | 長時間化を個別事例として扱い、公式の稼働情報も確認する |
| Invalid | notarytoolログの最初の有効なエラー | 指定パスの内側のコードを修正する |
| Accepted | チケット取得、stapler、最終ファイル | Gatekeeperと別環境で配布物を検証する |
| Accepted後に起動拒否 | stapling結果、配布ファイルの同一性 | 利用者が取得する実ファイルを再検査する |
第一段階：署名済みAppではなく最終配布物を検査する
「署名済みなのに公証できない」場合、Xcodeプロジェクトや元の.appだけを見てはいけません。実際にSubmitしたZIP、DMG、PKGを展開し、その中のアプリとすべてのネストされたコードを確認します。Appleの公証前のmacOSソフトウェア確認手順も、配布物を基準にした検査を前提にしています。
確認する項目は、Developer ID Applicationによる署名、Hardened Runtime、安全なタイムスタンプ、entitlementsです。さらに、次の内部要素を一つずつ追います。
- Framework、動的ライブラリ、プラグイン
- ヘルパーアプリ、ログイン項目、補助ツール
- PKGがインストールする実行可能ファイル
- DMG内に同梱したアプリと追加ファイル
署名後にBundleへファイルを追加したり、埋め込みFrameworkを置き換えたりすると、直前の署名確認は無効になります。codesignの検査が元のAppで成功しても、後から作ったDMGやPKGが同じバイナリを含むとは限りません。
| 配布形式 | 公証前の確認 | 公開前の確認 |
|---|---|---|
| ZIP | 展開後の.appと内部コードを検査 | ZIPを再生成し、提出したファイルと公開ファイルの同一性を確認 |
| DMG | DMG内の.app、ボリューム構成、署名状態を確認 | DMGをマウントしてstapleとGatekeeperを確認 |
| PKG | インストールスクリプトと配置される実行可能ファイルを確認 | インストール後のAppを別環境で起動する |
PKGやDMGの作成工程で何が署名対象になるかは、Macソフトウェアの配布用パッケージ資料に沿って確認します。
macOS Appが署名済みでも公証に失敗する場合、何を疑うべきですか。
最初に、署名そのものではなく、ネストされたコードの署名、不要なget-task-allow、entitlementsの形式、安全なタイムスタンプ、証明書の種類を調べます。元のAppではなく、Submit直前のZIP、DMG、PKGを展開して確認するのが境界線です。
第二段階：notarytoolのログを最初の有効なエラーまで読む
Invalidという結果だけでは修正箇所は分かりません。提出IDを使って情報とログを取得し、ログ内で具体的なパスを指している最初の有効なエラーを探します。後続のエラーは、内側の実行ファイルが正しく認識されなかった結果として発生している場合があるためです。
notarytoolがInvalidを返した後、具体的なエラーをどう確認しますか。
まず提出IDを保存し、同じ提出IDに対する詳細情報とログを取得します。ログで指定されたBundle、Framework、プラグイン、実行ファイルのパスを配布物内で照合し、署名状態、entitlements、タイムスタンプを再確認してください。Appleの一般的な公証問題の解決資料を基準にし、Invalidという文字列だけから原因を推測しないことが重要です。
典型的な読み方は次のとおりです。
- 署名無効：ログのパスにある内側のコードを先に検査します。
- 安全なタイムスタンプ不足：署名時のオプションと証明書の有効性を確認します。
get-task-allow：配布用署名に開発用の権限が残っていないか確認します。- entitlements形式エラー：XMLやキーの構造だけでなく、対象の署名と一致しているか確認します。
- 証明書タイプの誤り：Mac App Store用とDeveloper IDによる直接配布用を混同していないか確認します。
- ネストされたコンポーネントの欠落：アプリ本体だけでなく、内部のFrameworkや補助ツールを列挙します。
Appleは公証ツールの移行について、altoolからnotarytoolへの変更と現行ワークフローをTN3147で案内しています。記事執筆時点の公式資料では、altoolは公証サービスに受け付けられず、notarytoolを使う構成が前提です。Xcodeや認証方式を更新する場合も、固定済みの自動化環境へ一度に反映せず、退避した設定で差分を確認します。
第三段階：内側から外側へ再署名し、容器を作り直す
修正が必要なら、いきなり再帰的な署名で全体を上書きしないでください。まず最も内側の実行可能ファイル、Framework、プラグイン、補助ツールを直し、次にApp本体、最後にDMGやPKGなど外側の容器を作り直します。
この順序を崩すと、外側のAppだけが新しい署名になり、内部コードの不整合を隠したまま再提出することになります。PKGが追加の実行可能コンテンツを配置する場合は、Appleのパッケージ作成と公証の公式手順に照らし、インストール後の実体まで確認してください。複数の配布物を作る工程では、どのファイルを提出したかを記録し、別の容器を公証済みだと誤認しないようにします。
分岐で決める再処理方法
- ログが内部Frameworkやプラグインを指す場合：そのコンポーネントを修正してからAppを再署名し、容器を再生成します。
- ログがentitlementsや証明書を指す場合：資格を削る前に、現在の署名設定を保存し、配布用と開発用の差分を確認します。
- Submit前にファイルを変更した場合：同じ提出を再利用せず、最終成果物のハッシュを取り直して新しい提出として扱います。
- 原因が認証だけの場合：署名済み成果物を作り直す前に、認証情報の出所とTeam IDを修正します。
- ローカルでは成功し、リモートMacだけ失敗する場合：Xcodeの選択、キーチェーンの権限、環境変数、作業ディレクトリ、GUIセッションの有無を比較します。
Accepted後の時間線：票据を貼り、利用者の条件で開く
notarytoolがAcceptedになった後もstaplerは必要ですか。
必要です。Acceptedは公証サービス側の判定であり、公開用ファイルにチケットが付与されたことや、利用者のMacで起動できることまで保証する表示ではありません。配布形式に応じてstaplerを実行し、結果を検証してからGatekeeperで評価します。
その後、開発用キャッシュや既存のオンライン判定に頼らず、別のMacへ実際に配布するZIP、DMG、PKGを渡します。ネットワークを制限した状態も含め、展開、インストール、初回起動、必要な権限要求まで確認すると、「公証したファイル」と「公開したファイル」の取り違えを見つけやすくなります。
この確認では、次の証拠を残します。
- Acceptedになった提出ID。
- stapleの実行結果とvalidateの結果。
- Gatekeeper評価の出力。
- 実際にダウンロードしたファイルのハッシュ。
- 開発者ツールや過去のチケットを持たないMacでの起動結果。
第一週のマイルストーン：リモートMacの自動公証を再現可能にする
ローカルでは公証できるのに、リモートMacの自動公証だけ失敗する場合はどうしますか。
まず成果物を変更せず、同じ入力をローカルとリモートMacで比較します。xcode-selectまたはDEVELOPER_DIRを固定し、資格情報の保管場所、実行ユーザー、キーチェーンのロック状態、GUIセッション、作業ディレクトリ、ログインシェルを記録してください。
リモートMacでは、SSHセッションとグラフィカルセッションでキーチェーンや環境変数の見え方が変わることがあります。したがって、SSHで提出できたかだけでなく、断線後の再接続、ホスト再起動後の再実行、途中で停止したタスクの再開を確認します。リモートMacの常時運用を検討する場合は、まずDeveloper IDの秘密鍵移行と受け入れ確認を済ませ、権限を広くしたまま自動化を固定しないでください。
自動化には、提出IDと成果物ハッシュの対応、ログの保存先、待機、タイムアウト、再試行、手動停止の条件を組み込みます。再試行は、認証失敗や成果物不整合を隠すための無制限ループにしません。リモートMacを公開リリース用に使う前に、無人コード署名の切り分け手順とDMG・PKG自動公開の構成を確認し、非正式版でBuildからGatekeeperまでを通します。
現在の開発用Macだけで運用すると、電源オフ、スリープ、容量不足、秘密鍵の未同期、ログの散逸が同時に起きやすくなります。共有CIだけに寄せる場合も、GUIセッションや特定のXcode環境を再現できず、原因調査のたびに実行条件が変わることがあります。Developer IDの秘密鍵、固定したXcodeツールチェーン、長期ログを安定して保管できないなら、故障原因を切り分けた後の署名・公証・Gatekeeper確認を、権限分離した常駐のリモートMacへ移す方が管理しやすいです。まずはVMSPINのリモートMac利用方法を確認し、正式版ではなく検証版で一連の公開工程を試してください。