リモートMac CIで公証を自動化するには、どこから始めればよいですか？

まずDeveloper IDで署名した配布用成果物を作り、署名検証の結果と成果物の識別情報をビルド記録に残します。その後、CIからnotarytoolで提出し、処理結果とログを保存します。公証サービスのAcceptedだけで完了にせず、配布形式に応じたチケット処理とダウンロード後の確認までを同じリリース記録につなげてください。

notarytoolの提出結果がAcceptedなら、そのまま公開できますか？

Acceptedは提出物の処理結果であり、最終配布物の受け入れ確認を代替するものではありません。Submission IDとログを記録し、提出した成果物と公開対象のファイルが一致するか確認します。必要なチケット処理、署名の検証、実際に配布するファイルのインストールまたは起動確認を終えてから公開可否を判断してください。

公証用の認証情報をリモートMac CIで安全に扱う方法はありますか？

認証情報はリポジトリやスクリプトへの直書きを避け、CIの秘密情報管理から実行時に渡します。Keychain profileを使う場合も、秘密情報の保管とCIジョブへのアクセス制御は別々に設計し、対象ジョブや担当者の権限を必要最小限にします。値そのものを標準出力やデバッグログへ出さず、ローテーションと失効の担当も運用手順に記録してください。

公証後にチケットが処理されているかは、どう確認しますか？

まず対象の配布形式がチケット処理に対応するかAppleの現行資料で確認し、適用できる場合はstaplerで処理した後、検証コマンドの結果を保存します。チケットの有無だけでなく、署名検証、配布ファイルの同一性、取得後のインストールまたは起動も確認します。検証対象は提出時の一時ファイルではなく、実際に公開する成果物にしてください。

macOSアプリの公証をリモートMac CIにどう導入する？2026年ガイド

Appleは2023年11月1日以降、altoolおよびXcode 13以前を使った公証アップロードを受け付けていません（Appleの公証ツール移行案内）。macOSアプリ公証はリモートMac CIに組み込めますが、Developer ID署名済みの成果物を準備し、notarytoolで提出・結果確認を行い、配布形式に応じてチケットを処理したうえで、最終配布物まで検証してください。今週は隔離した公開ジョブを用意し、Acceptedだけでリリースしない制御から実装します。

この手順は、Mac App Store以外で配布する独立系macOS開発者、Archiveと書き出しを管理するビルドエンジニア、CIの認証情報や署名資産を扱うDevOps担当者向けです。
Mac App Store提出の手順や、macOSコード署名全般の設定解説は対象にしません。

公証の対象と完了条件

ここで扱うのは、Developer IDで署名し、Mac App Store以外の経路で配布するmacOSアプリです。公証はApp Reviewとは別の仕組みであり、Mac App Store向けの提出・審査・公開フローと混ぜずに管理します。AppleのmacOSソフトウェア公証の説明に沿って、提出から配布物の準備までをひと続きの工程として扱います。

リモートMac CIで追跡する対象は、署名済み成果物、提出記録、処理結果、チケット処理の有無、そして公開用ファイルです。公証サービスが提出を受理したことと、利用者に渡すファイルの検証が完了したことは同じではありません。

作業前に、Archive、書き出し後の成果物、実際に公開するパッケージを区別します。各段階でファイル名だけに頼らず、ビルド記録、ソース管理のコミット、署名検証の出力を関連付け、どの成果物が提出され公開されたのかを後から特定できるようにします。

提出前の署名と成果物準備

最初に、配布用成果物がDeveloper IDで署名されていること、Hardened Runtimeやタイムスタンプなど必要な署名条件を満たしていることを確認します。AppleのMac向け配布署名のガイドを参照し、アプリ内に埋め込まれた実行コードも含めて検証します。証明書名やプロジェクト固有の設定値は、実際の署名設定に合わせて確認し、未確認の値をコマンドに固定しないでください。

CIの署名ジョブでは、次の情報を記録します。

対象のコミットとビルドジョブの識別子
Archiveと書き出し後の成果物の保存先、およびファイルの識別情報
署名検証の結果と、失敗時に確認できるログ
公証へ渡すファイルと、公開用ファイルとの対応関係

署名の失敗を公証サービスの問題と扱うと、原因を切り分けられません。まず書き出し後のファイルが想定した署名対象か確認し、その後に公証提出へ進めます。XcodeのCI用Archiveと書き出しの工程を整える場合は、リモートMacでのXcode CI構築もあわせて確認できます。

リモートMacからnotarytoolで初回提出

ジョブを動かす前に、選択したXcodeまたはCommand Line Toolsからnotarytoolを呼び出せるか確認します。Appleはスクリプトを含む公証ワークフローを説明しているため、公証ワークフローのカスタマイズ資料を参照し、利用環境でのコマンドや認証方法を確定してからCIへ実装してください。

コマンド例では、実際のパスや秘密情報を埋めず、CI内で管理する変数に置き換えます。

xcrun notarytool submit "$DISTRIBUTION_FILE" \
  --keychain-profile "$NOTARY_PROFILE" \
  --wait

この例は提出と処理完了までの待機を一つのジョブで行う構成です。CIで待機を分離する場合は、提出時の識別子を保存し、後続ジョブでそのIDを参照できるようにします。認証パラメーターやprofileの作成方法は、Appleのカスタム公証ワークフローおよびNotary API資料で現行の説明を確認してください。

秘密情報はリポジトリ、コマンド履歴、ビルドログに書き込まず、CIの秘密情報管理から実行時に渡します。Keychain profileは認証情報を利用する仕組みであり、誰がどのジョブから使えるかというCI側の権限管理の代わりにはなりません。公開ジョブに利用権限を絞り、ログのマスキング、認証情報の更新・失効手順、障害時の担当者を合わせて決めます。

提出結果と失敗証拠の確認

提出後は、Submission ID、処理結果、対象ファイルの識別情報を同じジョブ記録に残します。処理に失敗した場合や警告が返った場合は、ログを取得してから修正箇所を判断します。Appleの公証に関する一般的な問題の解決資料に照らし、署名や権限、成果物形式、提出サービスからの応答を分けて確認します。

xcrun notarytool log "$SUBMISSION_ID" \
  --keychain-profile "$NOTARY_PROFILE"

ログに署名や実行コードの指摘があれば、該当する成果物と署名記録を確認します。ファイル形式の問題なら、CIが提出したファイルと意図した配布ファイルが一致しているかを調べます。応答が得られない場合も、単一の表示だけでリモートMacの故障やネットワーク障害と決めつけず、ジョブログ、提出ID、サービス応答などの証拠を照合してください。

公証の処理結果はリリース可否の判定材料ですが、配布物そのものの署名やダウンロード後の動作を保証する最終検査ではありません。

FAQ：提出後と認証情報の扱い

リモートMac CIの公証をどの順で自動化しますか

Developer ID署名済みの成果物を確定し、署名検証の結果と識別情報を記録してからnotarytoolで提出します。処理結果とログを保存し、配布形式に応じたチケット処理、署名の再確認、利用者が取得するファイルの動作確認までをリリースジョブに含めます。Acceptedだけを公開条件にしない設計が要点です。

認証情報とKeychain profileはどう分けて管理しますか

秘密情報はCIの秘密情報管理に置き、許可した公開ジョブの実行時だけ利用させます。Keychain profileを利用する場合も、profileの利用可能範囲とCIのアクセス権限は個別に見直します。値をログへ出さない設定、更新・失効の担当、失敗時の再実行方法も決め、秘密情報の管理を特定の担当者の記憶に依存させないようにします。

配布形式に応じたチケット処理

公証の処理結果を確認した後は、実際に配布する形式に合わせてチケット処理の要否と手順を確認します。アプリ、圧縮ファイル、ディスクイメージ、インストーラーパッケージは同じ成果物ではありません。利用形式に適用できる処理や検証コマンドは、AppleのMacソフトウェアのパッケージング資料で確かめてからパイプラインへ追加してください。

適用対象であれば、たとえば次のように処理し、結果を記録します。

xcrun stapler staple "$DISTRIBUTION_FILE"
xcrun stapler validate "$DISTRIBUTION_FILE"

コマンドが成功しても、それだけで公開ファイルの確認が終わるわけではありません。署名をcodesign --verify --strict --verbose=2で検証し、チケットの確認結果とともに保存します。そのうえで、CIから取得した最終配布ファイルを隔離した環境で展開・インストールまたは起動し、署名の有効性、チケットの状態、アプリの基本動作を別々に確認します。

リリース判定用の決定チェックリスト

各項目を確認し、該当する分岐に沿って公開方法を選びます。

[ ] 署名済み成果物から実際の公開ファイルまで、コミットとビルド記録をたどれますか。
[ ] notarytoolの処理結果とSubmission ID、必要なログを保存しましたか。
[ ] 配布形式に必要なチケット処理と、その検証結果を確認しましたか。
[ ] 実際に配布するファイルを取得し、署名とインストールまたは起動を確認しましたか。

すべてにチェックできる場合： 証拠を同じリリース記録に保存したうえで、自動公開へ進みます。

一部の確認が未完了だが、提出結果や署名に失敗がない場合： 自動公開は有効にせず、担当者が成果物と記録を照合する手動承認へ戻します。

署名不備、提出失敗、公開ファイルとの不一致、検証不能がある場合： 公開を保留し、ログと対象ファイルを確保して原因を確認してから再実行します。Acceptedだけを理由にこの分岐を飛ばしてはいけません。

実リリースによる受け入れ確認

本番へ切り替える前に、実際のリリース候補を使って、Archiveから書き出し、公証提出、結果確認、チケット処理、配布ファイル検証までを通します。記録からソースのコミット、提出記録、最終配布ファイルをたどれない場合は、ジョブの成功表示だけを根拠に公開しないでください。

失敗時に誰が再試行を判断するか、どの条件で認証情報を更新するか、前の配布物へ戻す責任者は誰かも運用記録に含めます。CIの設定変更でログや成果物の保存範囲が変わった場合は、実リリースの検証をやり直してから自動公開を有効にします。

すでに使えるMacがある場合は、まず既存環境で一連の公開ジョブを検証し、Xcode、署名資産、CIの制御要件を満たすか判断します。一方、Linux環境だけではmacOS固有の署名や公証を完結できず、手元のMacを常時稼働させる方式では保守やアクセス管理も必要です。購入が過剰で、一時的な検証や公開用の実行環境だけが不足しているなら、NodeMiniのMac環境を確認し、必要な期間だけリモートMacを使う選択肢と比較してください。恒常的な高負荷や物理接続が必須なら、自社保有のMacを含めて要件を見直すのが適切です。