CIではアップロード成功なのに、公証の状態が失敗になり、配布判定が止まっている。
【判断】適しています：Apple notarization CI失敗は、すぐに再署名や全工程を再実行せず、提出状態とAppleの公証ログから失敗段階を特定します。署名・権限、制品形式、提出経路、チケットのステープルを分けて修正してください。アップロード成功だけをリリース許可の根拠にする運用には適していません。
macOSアプリを外部配布するリリース担当者は、公証ステップの設計と障害対応に活用できます。
Developer ID証明書や秘密鍵、CI認証情報を管理するIT・セキュリティ担当者は、責任範囲を整理できます。
企業Mac CIの技術責任者は、遠隔ビルド環境の受入条件とリリース証跡の確認に役立てられます。
00Apple notarization CI失敗を工程ごとに切り分ける
「提出できた」「Appleの処理が終わった」「公証で受理された」「チケットをステープルした」「配布前の検証に通った」は、それぞれ別の状態です。CIのアップロード工程が終了コード0で終わっても、それだけでは公証の受理や最終制品の配布可否を確認したことになりません。
Appleの公証フローでは、制品の提出後に提出IDを使って状態を確認し、必要に応じてログを調べます。まずAppleの公証プロセスの説明に沿って、CIがどの段階まで完了したかを確かめます。
| CIで確認できた状態 | 意味すること | 次に確認するもの |
|---|---|---|
| アップロード処理が完了 | 制品が提出経路に送られた状態です | 提出IDが記録されているか、Apple側の現在状態 |
In Progress |
公証処理が進行中です | 同じ提出IDの状態。受理と扱わず、結果を待ってから判定 |
Accepted |
公証が受理された状態です | 配布形式に応じたステープルと、最終ファイルの検証 |
Invalid |
制品が受理されなかった状態です | 提出IDに対応する公証ログと指摘された制品箇所 |
状態名と提出ID・ログの確認方法は、Notary APIの提出状態とログに関する説明を参照してください。状態が受理以外なら、CIの「アップロード成功」表示を根拠に次の公開工程へ進めず、まず公証サービスの応答を保存します。
最初に記録する項目
- [ ] CIのジョブIDと失敗したタスクを記録する
- [ ] 公証に渡した最終制品のファイル名とハッシュを記録する
- [ ] 提出IDと取得した状態応答を保存する
- [ ] 提出IDに対応する公証ログを保存する
- [ ] 署名検証、ステープル、最終検証の各出力を別々に保管する
提出IDがない場合は、CIが提出リクエストの応答を破棄していないか、ジョブ間で引き継げているかを調べます。状態が未完了なのか、処理結果が不受理なのか、ログ取得だけに失敗しているのかを分けずにリトライすると、原因の特定が難しくなります。
01署名エラーと提出用認証の取り違えを解消する
Developer IDによるコード署名は、配布するアプリや構成要素の署名に関わります。一方、公証を提出するための認証情報は、CIがAppleの提出サービスにアクセスするためのものです。証明書の選択ミス、署名の不整合、提出用認証情報や権限の問題は、同じ「公証失敗」と表示されても確認先が異なります。
まず公証ログの具体的な指摘と、CIが実行した署名検証の出力を突き合わせてください。Appleのコード署名サービスの説明を基準に、署名対象と署名の整合性を確認します。提出時の認証エラーが示されている場合は、Developer ID証明書を変更する前に、CIサービスアカウントが使う認証設定とアクセス権を確認します。
| 症状・証拠 | 優先して調べる領域 | 先に行う対応 |
|---|---|---|
| ログが署名の不整合や未署名の要素を示す | 最終制品の署名と構成 | 対象要素を特定し、署名後の制品を再検証 |
| 提出処理が認証やアクセス権で失敗する | CIサービスアカウントと提出認証 | 使用する認証設定、権限、Keychainへのアクセスを確認 |
| 公証が受理されず、ログに制品の問題が記載される | 制品形式や署名対象 | 指摘された最終配布物を修正して再作成 |
| 受理済みだが配布後の検証で止まる | ステープル処理または最終ファイル | 配布形式に合う処理と、処理後ファイルの検証を確認 |
Appleはよくある公証問題の解決方法を公開しています。証明書の問題と決めつけてMacノードを交換したり、反対にノード問題を否定したりするのではなく、ログに表れた失敗内容から切り分けるのが先です。
秘密鍵や提出用認証情報のアクセス範囲を広げて復旧させると、原因を隠したままCIの権限だけが過剰になるおそれがあります。変更前後のアカウント、Keychain、ジョブを記録し、原因に必要な範囲だけを修正してください。
02制品の封装と署名を最終配布物で確認する
ビルド途中のアプリが署名検証に通っていても、その後にパッケージ化やファイルの差し替えを行ったなら、確認対象は変わっています。公証に提出するものと、利用者へ配布するものが一致しているかを確かめ、提出前の最終ファイルについて署名と形式を確認します。
AppleのMacソフトウェアのパッケージ化と配布に関する資料と公証ログを照合し、ログが指摘する署名対象、封装、Entitlementsを確認してください。特定のEntitlementsが一律に原因だと決めず、実際のログと対象アプリの構成に基づいて調査します。
Mac CI排障では、署名検証に使ったパスが中間生成物のままではないか、署名後に制品を変更していないか、提出ファイルとリリース用ファイルが同一かを記録すると、再提出の要否を判断しやすくなります。Appleの公証はApp Storeの審査とは別の工程であり、どちらかの結果をもう一方の承認とみなしてはいけません。
03受理後のステープルと配布検証を分離する
公証がAcceptedになっても、チケットのステープルや配布用ファイルの検証まで済んだとは限りません。Appleの資料にあるstaplerの使い方を配布形式に合わせ、実行した場合はステープル後の最終ファイルを検証します。受理結果、ステープル結果、最終検証の出力は、それぞれ別の証跡として保存してください。
「受理済みの提出IDがあるか」「配布形式に対してステープルを行う設計か」「利用者へ渡す最終ファイルを検証したか」を順に確認します。CIでは公証の受理だけでジョブを成功扱いにせず、リリース対象と一致するファイルの検証結果を公開判定に結び付けます。
修正方法を決める条件
- 公証ログが署名やEntitlementsの問題を示す場合は、該当箇所を直して最終制品を作り直します。署名と封装を再確認してから、必要な提出を行います。
- 提出状態が未完了の場合は、既存の提出IDを使って状態確認を続けます。状態が不明なまま同じ制品を再提出しないでください。
- ログに提出認証や権限の失敗が示される場合は、CIアカウント、認証設定、Keychainへのアクセス、ネットワーク経路を確認します。制品の再署名から始める必要はありません。
- 公証が受理され、ステープルまたは最終検証だけが失敗した場合は、受理済み制品と配布ファイルの一致、対象形式、処理後の検証結果を調べます。
- 状態確認や提出に関する障害が複数の制品で同時に発生する場合は、Apple Developerのシステム状況も確認し、制品の問題とサービス側の状態を分けます。
04公証の疑問をCIの受入条件に組み込む
ここまでの切り分けを、担当者の記憶だけに頼らないリリース判定へ落とし込みます。公証ログが説明する問題と、CIアカウント・Keychain・ネットワーク出口の問題を分けて記録すれば、再署名、再提出、環境調査のどれが必要かをレビューできます。
- [ ] 最終配布物に対する署名検証結果を保存した
- [ ] 提出IDと公証サービスからの状態応答を保存した
- [ ] 公証ログを提出IDにひも付けた
- [ ] ステープルを行った場合、その結果を保存した
- [ ] 配布する最終ファイルの検証結果を保存した
- [ ] 提出認証情報の利用主体とCIサービスアカウントを記録した
- [ ] 認証・Keychain・ネットワークの問題と、制品自体の問題を切り分けた
FAQ：notarytoolの提出後に失敗が見えた場合
notarytoolの提出成功だけでは、公証の受理は確定しません。提出IDで現在状態を取得し、対応するログを確認してください。ログがまだない場合は、処理未完了、提出IDの引き継ぎ漏れ、ログ取得失敗を区別し、状態を確認してから再試行を判断します。
FAQ：公証ログから署名問題をどう見分けるか
ログが署名不整合や未署名要素を具体的に示すなら、最終配布物の署名と構成を調べます。認証エラーは提出用の権限や設定が原因となる場合があり、署名証明書の問題とは分けて確認します。エラー説明と対象ファイルをAppleの公式資料に照らしてください。
FAQ：公証の受理後にステープルと検証は必要か
受理とステープルは別の工程です。配布形式と配布方法に合わせてステープルを行うか判断し、実行した場合は処理後のファイルを検証します。受理結果だけで完了扱いにせず、利用者へ渡すファイルの検証出力もリリース記録に残します。
FAQ：公証失敗時に再署名、再提出、制品修正のどれを選ぶか
公証ログが制品の署名や封装を指摘するなら、その制品を修正して再作成します。提出状態が未完了なら、既存の提出IDで状態を確かめます。提出認証の問題ならCIアカウントや権限を調査します。原因が判明する前に、全工程の再実行を標準対応にしないでください。
05Mac CIの公開判定に証跡を残す
公開を許可する条件は、「アップロード済み」ではなく、署名確認、提出ID、受理状態、公証ログ、必要なステープル、最終ファイル検証、認証情報の利用記録がそろっていることです。Apple側の状態確認が必要ならサービス状況を調べ、CIアカウントやKeychainの問題なら実行環境を調査し、ログが制品を指しているなら制品を修正します。
既存のMacで運用する場合は、CIアカウントやKeychainの権限差、ノード保守、認証情報の管理を自社で継続する必要があります。Macを自社購入すれば物理環境を管理できますが、短期の検証や変動するビルド需要にも固定資産と保守が伴います。遠隔Macのレンタルは、環境を自社保有せず一時的な検証先を用意したい場合の比較対象になりますが、安定した高負荷運用や物理接続が必要な場合は、自社保有を含めて評価してください。
NUKCLOUDのサービス概要を確認する場合も、ノードが稼働していることだけで公証の受入を判断せず、実際の署名・公証・最終制品検証で要件を満たすかを確かめるのが適切です。チームのMac環境の選択肢はNUKCLOUDの案内から確認できます。