Electron 44 macOSのパッケージ化にはMacが必要？2026年CI構成

Windows上でmacOS用インストーラーを生成できますか。
プロジェクトの構成によっては、WindowsやLinuxからmacOS向けのファイルを生成できます。しかし、ファイルが生成されたことと、macOS利用者へ公開できる成果物になったことは別です。

Electronの配布工程には、アプリのパッケージ化、コード署名、公証、チケットの添付、最終インストール確認があります。Electronの配布工程一覧でも、これらは別の作業として扱われています。

判断対象を「ZIPやDMGが作れたか」にすると、失敗を見逃します。今回の対象は、署名済みアプリが公証を通り、チケットを添付した状態で、クリーンなユーザーアカウントへインストールできる本番成果物です。

Electron 44のインストール対象には、OSだけでなくCPUアーキテクチャも関係します。Electronのプラットフォームとアーキテクチャに関する説明を確認し、配布する対象をdarwin-arm64、darwin-x64、またはユニバーサル構成として明示します。

純粋なJavaScriptだけで構成されたアプリは、クロスプラットフォームのパッケージ化を進めやすい傾向があります。一方、Nodeの原生モジュール、補助バイナリ、システム拡張、プラットフォーム固有のリソースを含むアプリは、同じ手順で判断できません。

特に確認すべき点は、依存パッケージがmacOS向けのdarwin-arm64とdarwin-x64を提供しているかです。対応していない場合、他OSで生成したnode_modulesやビルド済みディレクトリをそのままMacへ移しても、実行時ロードで失敗する可能性があります。

リモートMacの最初の役割は、別OSで作ったディレクトリを受け取ることではありません。固定したロックファイルから新規に依存関係を解決し、対象Mac上で原生モジュールを再構築し、実行ファイルのアーキテクチャを記録することです。

Windowsで開発するElectronアプリをMac版として公開する場合の分担はどうしますか。
Windows側ではコード編集、Lint、単体テスト、共通の成果物検査を行います。Mac側では、Mac上での依存関係インストール、macOSパッケージ化、署名、公証、インストール後の起動確認を行います。

実作業では、次の情報をCIログに残します。

• Gitのコミット識別子とロックファイルのハッシュ
• darwin-arm64またはdarwin-x64の対象
• 原生モジュールの再構築結果
• パッケージ化したファイルのチェックサム
• Mac上で実行したNode、Electron、Forgeのバージョン
• 署名前後のアプリ構成

別ノードで最新ソースを再取得すると、同じジョブ番号でも異なる成果物になることがあります。WindowsまたはLinuxで作成した固定成果物とコミット情報をMacへ渡し、Mac側の再取得を避ける構成が安全です。ただし、原生依存関係はMac側で対象環境に合わせて再構築します。

macOS利用者へ配布するなら、コード署名は任意の装飾ではありません。Electron公式もmacOS配布に署名を必要な工程として説明しており、Electronのコード署名ガイドでは、署名されたアプリが改変されていないことを検証する流れが示されています。

Electron Forgeを使う場合は、ForgeのmacOS署名ガイドと、@electron/osx-signの設定定義を照合します。確認対象は証明書の種類だけではありません。entitlements、Hardened Runtime、Bundle ID、実行アカウント、Keychainの参照方法が揃っている必要があります。

Electron macOSのコード署名でMacが必要になる理由は何ですか。
署名に使う証明書の秘密鍵をmacOSのKeychainで安全に扱い、macOS向けのアプリ構造とentitlementsを検証する必要があるためです。別OSでファイルを生成できても、最終的な署名主体とKeychainを含む公開工程まで同じ条件で再現できるとは限りません。

秘密鍵をリポジトリ、通常の環境変数、共有ビルドディレクトリへ置く構成は避けます。公開専用の実行アカウント、分離したKeychain、最小限のファイル権限を設定し、証明書、Team ID、Bundle IDなどはCIの秘密情報として管理します。本文の例では、実際の値を使わず<TEAM_ID>、<BUNDLE_ID>、<CERTIFICATE_NAME>、<KEYCHAIN_PATH>と表記します。

注意：署名ジョブが成功しても、公開可能とは限りません。署名前のアプリ、署名後のアプリ、公証へ提出したファイルのチェックサムを別々に保存し、失敗時は標準出力だけでなく公証サービスの原文ログも保管します。

署名後はAppleの公証へ進みます。AppleのmacOSソフトウェア公証手順では、公証サービスへの提出と結果確認が別工程として扱われています。notarytoolまたはApple Notary APIをCIから利用する場合も、アップロード完了だけで成功と判定してはいけません。

Electron Forgeで公証を組み込む場合も、構築処理と公開処理の境界を明確にします。Forgeのビルドライフサイクルを参照し、次の状態を個別に記録します。

1. Mac上で依存関係をインストールする。
2. 対象アーキテクチャ向けにElectronアプリをパッケージ化する。
3. entitlementsを適用してコード署名する。
4. <APPLE_ACCOUNT>、<TEAM_ID>、<KEY_FILE>などの認証情報で公証へ提出する。
5. 提出識別子<SUBMISSION_ID>の結果を待つ。
6. 公証の成功後にチケットを添付する。
7. 添付済み成果物をネットワークから切り離した状態でも検証する。
8. クリーンなユーザーアカウントへインストールし、初回起動と更新を確認する。

公証の成功と、最終インストーラーの検証成功も同じではありません。DMGやZIPを作り直した場合、確認済みのアプリと配布ファイルの関係が変わります。チケット添付後にパッケージを再生成しない運用にします。

Electron ForgeでCIのnotarizationを実行する場合、何を固定しますか。
Forgeの設定、署名対象、Bundle ID、認証方式、提出ファイルのチェックサムを固定します。認証情報の値はログへ出さず、成功・失敗・待機・タイムアウトを別状態として扱います。Appleの公証ワークフロー説明に沿って、提出後の結果確認までジョブを完了させます。

すべてのタスクをMacへ送る必要はありません。WindowsまたはLinuxの汎用ノードでLint、単体テスト、静的解析、共通ビルドを済ませ、固定コミットと検証済み入力だけをMacノードへ渡します。MacノードはmacOS固有の公開工程に集中させます。

最低限の実装手順は次の通りです。

1. リポジトリをコミット識別子で固定する。
2. WindowsまたはLinuxでLintと単体テストを実行する。
3. ロックファイルと成果物のチェックサムを保存する。
4. Macでクリーンな作業領域を作り、依存関係を対象環境向けに再構築する。
5. Electron Forgeまたは採用したパッケージ化ツールでmacOS成果物を作る。
6. 専用Keychainを解錠し、署名と署名検証を行う。
7. notarytoolまたはNotary APIで提出し、結果を待つ。
8. チケットを添付し、オフライン検証を行う。
9. クリーンなユーザーアカウントでインストール、起動、自動更新を確認する。
10. 成功した成果物と直前のリリース成果物を保存する。

リリース頻度が低く、まだ署名設定を固めていない段階なら、短期のリモートMacで一度の公開工程を通す方法が合理的です。毎回のリリースで安定したMac環境と専用Keychainが必要なら、専用ノードを検討します。共有Runnerを使う場合は、他ジョブからの作業領域、Keychain、常駐プロセスの分離を確認します。

Electron macOSの公開ノードは常時稼働が必要ですか。
常時稼働そのものは必須ではありません。リリース時だけ起動する一時ノードでも、必要なツール、秘密情報、Keychain、ログ保存先を再現できれば運用できます。

ただし、再起動後にKeychain、実行アカウント、依存ツール、常駐Runnerが期待どおり復旧するかは検証が必要です。Macを購入する場合はMac miniの導入候補と比較し、物理機器の保守や長期占有が本当に必要かを確認します。短期間だけ公開経路を検証する場合は、MESHLAUNCHのMac環境を候補に含め、まず実成果物で判定します。

CIのJobが緑になっただけでは、購入・レンタル・専用ノードの判断材料として不十分です。次の項目をチェックリストとして保存します。

• [ ] クリーンな作業領域からElectron 44の成果物を再生成した
• [ ] 対象CPU向けの原生モジュールがロードできた
• [ ] 署名前後のチェックサムを記録した
• [ ] codesign相当の検証で署名状態を確認した
• [ ] <BUNDLE_ID>とentitlementsが想定値だった
• [ ] 公証の提出識別子と結果ログを保存した
• [ ] チケット添付後の成果物をオフラインで検証した
• [ ] クリーンなユーザーアカウントでインストールできた
• [ ] 初回起動、ログイン項目、必要なKeychainアクセスを確認した
• [ ] 自動更新が実際に前バージョンから動作した
• [ ] 再起動後にKeychainと実行アカウントが復旧した
• [ ] 直前の公開可能な成果物をロールバック用に保管した

判断を次の表に固定すると、環境選びが感覚論になりません。

WindowsやLinuxだけで進める構成は、開発費を抑えやすい一方、macOSの原生依存関係、Appleコード署名、Gatekeeper、更新処理を本番条件で確認できません。専用Macは再現性を保ちやすい一方、低頻度のプロジェクトでは未使用時間と資格情報の管理負担が残ります。

そのため、現在Macを持たないチームには、まず短期のリモートMac CIでElectron 44の公開経路を1回通す方法を勧めます。クリーンな作業領域から署名、公証、チケット検証、インストール、自動更新まで確認し、その後にリリース頻度と秘密鍵のリスクを基準に専用ノードへ移行するか決めます。

Windows/Linuxだけの構成では、macOS固有の署名工程を別の担当者や手作業へ逃がしやすく、再現性、ログの追跡性、更新確認のいずれかが欠けがちです。Macを購入して常時確保する方法もありますが、まだ公開経路を固める段階なら、保守対象を増やさず実機検証だけを先に行えるMESHLAUNCHのレンタルMacのほうが、判断を先送りせずに済む構成です。