Linux中心のCIにmacOSアプリの署名、公証、配布工程を追加する開発者向けの記事です。公証サービスへの提出だけを汎用ノードで行う場合と、ビルドからチケット装着、最終検証までをMacで完結させる場合を工程別に分け、遠隔Mac CIを含む現実的な構成判断と検収手順を示します。
Linux中心のCIにmacOSアプリの署名、公証、配布工程を追加する開発者向けの記事です。公証サービスへの提出だけを汎用ノードで行う場合と、ビルドからチケット装着、最終検証までをMacで完結させる場合を工程別に分け、遠隔Mac CIを含む現実的な構成判断と検収手順を示します。
macOS App 公証にはMacが必要かという判断は、提出と照会だけなら必須ではありません。ただし、ビルド、Developer ID署名、チケット装着、最終検証まで含むなら、実際のMacをCIに残す構成が安全です。Linuxなどの汎用CIで編成し、遠隔MacでmacOS固有の配布工程を閉じる方法が、多くのチームにとって現実的です。
この内容は、Linux中心のCIにmacOSアプリの公開工程を追加するプラットフォームエンジニア向けです。自動署名と公証を無人化したい開発者、長期稼働するMacと必要時だけ起動するMacを比較している技術責任者にも適しています。
macOSの配布工程では、次の処理を別々の段階として扱います。
AppleはXcode、notarytool、Notary APIを公証サービスとの接点として案内しています。特にNotary APIは、notarytoolを使わずにソフトウェアの提出や状態照会を行うためのインターフェースです。Appleの公証ワークフローとNotary APIの概要を確認すると、サービスとの通信と、ローカルの署名・検証処理が別の責務であることが分かります。
つまり、Linuxから提出できる可能性があることは、LinuxだけでmacOSアプリのリリースが完了することを意味しません。提出前の製品が正しく署名され、提出後に配布形式へ適切な処理を施されているかまで確認する必要があります。
最初に、CIの入力を「ソースコード」と「提出可能な製品」に分けます。すでに署名済み、または署名前の再現可能なアーカイブがある場合は、Linux側で製品の保管、ハッシュ確認、ジョブ制御を担当できます。一方、Xcodeプロジェクトのビルド、Apple固有のツールチェーン、Mac向けのインストーラー生成を含む場合は、Macノードをビルド工程に置くのが自然です。
AppleのMacソフトウェアの配布用パッケージング資料に沿って、提出対象を明確にします。検収時は「ビルドが成功した」ではなく、同じソース、同じ依存関係、同じ設定から、再実行可能な署名前の製品を生成できることを証拠にします。
製品準備段階の失敗条件は、次のように定義できます。
この境界を曖昧にすると、Linuxで提出だけ成功した後、どのファイルを配布すべきか分からなくなります。
公証はDeveloper ID署名の代替ではありません。署名前に、アプリ本体、フレームワーク、ヘルパー、プラグインなどの埋め込みコードが確定している必要があります。署名後に内部ファイルを変更すると、署名状態や公証対象との整合性を失う可能性があります。
AppleのMac向け配布署名の説明を基準に、CIでは次の証拠を残します。
専用の遠隔Macを使う構成では、署名用の実行アカウントと、通常の管理アカウントを分けやすくなります。共有Macノードでは、前ジョブの一時ファイル、ログインセッション、キーチェーンのロック状態が次のジョブへ影響しないかを確認してください。
外部の署名工程を組み合わせる設計もありますが、認証情報の受け渡し、製品の改変防止、失敗時の再実行経路が増えます。署名をMacから切り離すことだけを目的にすると、監査可能性と復旧性を失う場合があります。
注意：証明書名、Team ID、秘密鍵、提出識別子、ファイルパスは、CIログへそのまま出さず、すべてプレースホルダーと秘密変数で管理します。公証が成功しても、認証情報の取り扱いが安全になるわけではありません。
Macノード上で署名済み製品を提出し、同じ実行環境で状態確認とログ取得まで行うなら、notarytoolを優先的に評価できます。Appleのnotarytoolに関する公証ワークフロー資料を参照し、認証情報の保存場所、待機処理、失敗時のログ保存をCIの仕様に落とし込みます。
一方、Linuxなどの制御ノードから提出と照会だけを実行したい場合は、Notary APIを候補にできます。Submit SoftwareのAPI仕様を確認し、製品のアップロード、提出識別子の保存、状態照会をジョブの状態機械として設計します。失敗時は、同じ製品を再生成するのか、保存済み製品を再提出するのかを明確に分けます。
Notary APIを使う場合でも、次の処理は別途残ります。
提出ログは成功・失敗の文字列だけで判断せず、Appleが提供する公証ログ取得のAPI仕様に沿って保存します。ログ取得に失敗した場合の再試行、提出識別子の紐付け、ジョブの手動再開も先に決めておくべきです。
公証サービスが成功を返した後も、最終配布ファイルが完成したとは限りません。配布形式によって、チケット装着などの追加処理と、ローカル検証の手順が変わるためです。
ここでは、提出対象の一時アーカイブではなく、実際に顧客へ渡すZIP、インストーラー、ディスクイメージなどを検収対象にします。公証済みの製品と、最終的に公開する製品が同じハッシュであるか、後工程で内容が変わっていないかを確認してください。
遠隔Mac CIでは、次の順番で実行すると責務が追いやすくなります。
Macノードが再起動した場合に、GUIログイン、キーチェーンのロック解除、SSH接続、CIエージェントの再登録がすべて正常に戻るとは限りません。再起動後に同じ製品を検証できるか、ジョブを途中から再開できるか、管理者が手動で引き継げるかを試運転で確認します。
本番採用の前に、汎用CIノードと遠隔Macを接続した一回のエンドツーエンド試運転を行います。確認対象は、製品転送、秘密情報の分離、提出状態の待機、ログ保存、ジョブ再試行、Mac再起動後の復旧、手動介入の入口です。
次のチェック項目を上から確認してください。
判定は次の条件分岐にします。
このチェックで「提出だけ」に該当する場合でも、Notary APIの採用をそのまま本番決定にしません。認証、状態管理、ログ保存、再試行、制品の改変防止まで確認できた場合に限り、汎用ノード中心の構成へ進めます。
採点の考え方として、提出だけを見れば汎用CI中心の構成が有利です。署名から配布検証までの一貫性、障害時の再現性、秘密情報の境界まで含めると、遠隔Macを残す混合CIの方が評価しやすくなります。
提出済み製品のアップロードと状態照会だけなら、Notary APIをLinux側の制御ノードから呼び出す構成を検討できます。ただし、署名やMac固有のパッケージングをLinuxで代替できるとは限らないため、公開前の最終検証をMac側へ残します。
Mac上のジョブに提出処理をまとめたい場合はnotarytoolが扱いやすく、Linux側で複数のMacノードを制御したい場合はNotary APIが候補になります。後者では認証、状態管理、ログ保存、再試行を自社のCI設計へ組み込む必要があります。
Xcodeによるビルド、Developer ID署名、Appleのコマンドラインツールを使う検証、配布形式に応じたチケット装着が、Macノードへ置く代表的な処理です。公証サービスの成功通知だけでは、配布物の検証完了とはみなしません。
汎用CIを編成担当にし、遠隔Macでは実行アカウント、キーチェーン、秘密変数、成果物保存先を分離します。再起動後のエージェント復旧と署名検証を試し、提出識別子とログを保存できてから無人運用へ移行します。
macOS App 公証にはMacが必要かという問いへの答えは、工程の切り方で変わります。Apple Notary APIによる提出と照会だけなら、Linuxを含む汎用CIから評価できます。しかし、ビルド、Developer ID署名、チケット装着、最終検証までを安定して完了させるには、実際のMacを遠隔Mac CIとして残す判断が堅実です。
Linuxのみの構成は、Mac固有のツールチェーン、署名環境、再起動後の検証を別の場所へ押し出しやすく、障害時に製品の再現経路も追いにくくなります。手元のMacだけで運用すると、常時稼働、共有、担当者不在時の復旧に制約が出ます。そこで、まずは隔離した遠隔Macへ実際の製品を流し、署名から最終検証までを確認してから、長期レンタルか必要時だけの利用かを決める方法が現実的です。
開発用Macを購入せずにCI用の実機環境を用意する場合は、VNCMacのMacレンタル案内で利用形態を確認できます。日本拠点からの接続条件を比較する場合は、日本向けMacクラウドの案内も参照し、まずは本番製品ではなく検証用製品で一連の復旧手順まで試してください。
提出ファイルを用意済みで、サービスへの送信と結果照会だけを行うなら、Notary APIをLinux側のオーケストレーターから利用する構成を評価できます。ただし、ビルド、Developer ID署名、チケット装着、Mac上の最終検証まで含める場合は、実際のMacノードを残す必要があります。
すでに署名済みMacノードがあり、Appleのコマンドラインツールで提出、状態確認、ログ取得をまとめたい場合はnotarytoolが扱いやすい選択です。Linuxなどの制御ノードから提出と照会を分離したい場合はNotary APIを検討しますが、認証情報、再試行、ログ保存を自前で設計します。
Xcodeプロジェクトのビルド、Appleの署名ツールを使うDeveloper ID署名、配布形式に応じたチケット装着、そして最終ファイルのローカル検証が代表例です。公証サービスが成功を返したことだけでは、配布物全体の準備が終わったとは判断しません。
汎用CIから制御し、遠隔Macでは制限した実行アカウント、分離したキーチェーン、短時間だけ利用する認証情報、再起動後の復旧確認を組み合わせます。成果物、提出識別子、ログを保存し、失敗時に同じ制品を再提出できる設計にしてから常用へ移行します。