Electronアプリのパッケージングと配布

Electronアプリを実際のユーザーに届けるには、4段階のパイプラインが必要です。アプリをプラットフォームネイティブなインストーラーにパッケージングし、OSから信頼されるよう署名・公証を行い、ユーザーがアクセスできるチャネルを通じて配布し、常に最新の状態を保つための自動更新を組み込む、という流れです。このパイプラインを担うツールの選定が最初の意思決定となりますが、2026年時点では2択に絞られます。Electron ForgeかElectron Builderかです。本ガイドでは、コピー＆ペーストで使える設定例、2023年と2024年に変更されたコード署名のルール、そして3つのプラットフォームを並列ビルドするGitHub Actionsのマトリックス設定を含む完全な手順を解説します。単一のマシンですべてをクロスビルドすることはできないため、CIの活用は不可欠です。

2026年におけるElectron Forge vs electron-builder

公式サポートを受けられるオールインワンのパイプラインを求めるならElectron Forgeを、成熟した組み込み自動更新機能と幅広いコミュニティサポートを求めるならelectron-builderを選択してください。どちらもmacOS・Windows・Linux向けの署名済み・自動更新対応インストーラーを生成できます。両者の違いはサポートモデルと設計思想にあり、機能面での差異ではありません。

Electron ForgeはElectronプロジェクト公認のツールです。Electronアプリのパッケージングと配布のためのオールインワンツールであり、多数の単機能パッケージを統合して、コード署名・インストーラー生成・アーティファクト公開まで含んだ完全なビルドパイプラインをすぐに利用できる形で提供します。Forgeは旧来の@electron/packagerと@electron/osx-signをMakersおよびPublishersシステムに統合しています。重要な点として、Electron Forgeを使用しない場合、その他のサードパーティツールはElectronコミュニティのメンバーによってメンテナンスされており、Electronプロジェクトからの公式サポートは提供されません。

electron-builderはそのコミュニティ製の代替ツールであり、カウンター次第で週間インストール数が200〜300万件に達する、より多くダウンロードされているツールです。2026年6月時点での最新安定版は26.15.3であり、月に数回新バージョンがリリースされるため、バージョンを固定した上でリリースサイクルごとに確認することをお勧めします。次のメジャーバージョンであるv27は2026年6月時点でアルファ版（27.0.0-alpha系）です。このバージョンではElectron BuilderがネイティブのESモジュールに移行し、最低動作環境がNode.js 22.12に引き上げられ、長期間非推奨とされていたAPIが削除されます。採用前にNodeのバージョンと設定の見直しが必要ですが、現時点での安定版チャネルは引き続き26.x系です。多くのチームがelectron-builderを選ぶ理由は、統合された自動更新機能にあります。electron-builderは依存関係を1つ追加するだけで済む完全なソリューションであり、必要な要件を内部で管理し、Electronメンテナーが使用する自動更新機能などを独自実装に置き換えています。

本記事では設定例にelectron-builderを使用します。その宣言的なpackage.jsonブロックが各プラットフォームターゲットに明確に対応しており、付属のelectron-updaterがセルフホスト型自動更新のデファクトスタンダードとなっているためです。公式ルートを好む場合は、同じ概念をForgeにも適用できます。

Tauriについて

Tauri 2.xは、バンドルサイズ約100MBが許容できない場合に有力な軽量代替となります。フルChromiumランタイムをバンドルする代わりに、OSのネイティブWebViewを通じてUIを描画するため、劇的に小さなバイナリを生成できます（桁違いの差であり、正確な数値ではありません）。ただし、トレードオフも現実として存在します。マシン間でのElectronのレンダリング一貫性と広大なnpmおよびネイティブモジュールのエコシステムを手放すことになり、ユーザーのOS間でWebViewのバージョン差異を受け入れる必要があります。Tauriはセキュリティを重視する小規模なユーティリティに適した選択肢であり、UIの忠実性とエコシステムの深さがディスク容量より重要な場合はElectronが優位です。

electron-builderによるプラットフォーム別パッケージング

electron-builderはpackage.json内の単一のbuildブロックからネイティブインストーラーを生成します。トップレベルの設定と、必要なターゲットを指定するプラットフォームごとのmac・win・linuxキーを定義します。マルチプラットフォーム対応の最小構成は次のとおりです。

{
  "build": {
    "appId": "com.example.myapp",
    "productName": "MyApp",
    "directories": { "output": "dist" },
    "files": ["dist-app/**/*", "package.json"],
    "mac": {
      "category": "public.app-category.productivity",
      "target": ["dmg", "zip"],
      "hardenedRuntime": true,
      "notarize": true
    },
    "win": {
      "target": ["nsis"]
    },
    "linux": {
      "target": ["AppImage", "deb", "rpm"],
      "category": "Utility"
    },
    "publish": [{ "provider": "github" }]
  }
}

各ターゲットは実際のインストーラー形式に対応しています。

electron-builderのターゲット設定でよく引っかかるポイントが2つあります。macOSのzipターゲットは自動更新を使用する場合に省略できません。macOS向けのzipターゲットはSquirrel.Macに必須であり、これがないとlatest-mac.ymlが生成されず、autoUpdaterエラーが発生します。なお、macOSのデフォルトターゲットはdmg+zipであるため、通常は明示的に指定する必要はありません。自動更新を機能させるには、macOSアプリケーションへの署名が必須であり、サポートされているデフォルトターゲットはDMG（macOS）、AppImage/DEB/Pacman/RPM（Linux）、NSIS（Windows）です。ビルドはnpx electron-builder --mac --win --linuxで実行できますが、署名済みインストーラーを完全にビルドできるのは対象プラットフォーム上（または対象プラットフォーム向けの環境）に限られます。これがCIを活用する理由です。

セキュリティの基本前提として、本記事ではアプリがElectronの推奨セキュリティ設定——contextIsolationを有効化しnodeIntegrationを無効化したpreloadスクリプト——で動作していることを前提としています。この設定を逆にしたままリリースしないでください。パッケージングは安全でないレンダラーの問題を解決しません。

コード署名と公証：依存関係の連鎖

macOSリリースで最も多くの問題を引き起こすルールを明示します。署名されていないmacOSアプリは、更新の存在をユーザーに通知することはできますが、サイレントインストールはできません。 コード署名は公証の前提条件であり、公証はmacOSの自動更新が機能するための前提条件です。macOSで自動更新を動作させるにはアプリケーションへの署名が必須です。これはSquirrel.Macの要件です。署名を省略すると、その後の連鎖全体が機能しなくなります。

macOS：署名してから公証

Apple Developer ID証明書が必要であり、取得にはメンバーシップへの加入が必要です。Apple Developer Programの年会費は99米ドルで、登録時に現地通貨での表示がある地域もあります。公証はメンバーシップに含まれており、Apple Developer Programのメンバーであれば追加費用なしでMacアプリを公証できます。公証（Appleによる自動マルウェアスキャン）は、macOS 10.15 Catalina以降、Mac App Store外で配布されるDeveloper ID署名アプリに対して必須となっています。

electron-builderでは、macブロックにhardenedRuntime: trueとnotarize: trueを設定し（上記参照）、ビルド時に環境変数で認証情報を提供します。リポジトリに認証情報を含めないでください。

# macOS署名証明書（base64エンコードされた.p12ファイル）とそのパスワード
export CSC_LINK="$(base64 -i developer-id.p12)"
export CSC_KEY_PASSWORD="••••••"
# 公証用認証情報（App Store Connect APIまたはApple IDのアプリ固有パスワード）
export APPLE_ID="you@example.com"
export APPLE_APP_SPECIFIC_PASSWORD="abcd-efgh-ijkl-mnop"
export APPLE_TEAM_ID="XXXXXXXXXX"

Windows：2024年のSmartScreenの変更

古いガイドの多くが見落としているこの変更点から、Windows向けの判断を始めてください。EV証明書はSmartScreenをバイパスしなくなりました。以前はExtended Validation証明書で署名することでSmartScreenのレピュテーションをデフォルトで獲得できましたが、その動作はもはや存在しません。SmartScreen警告を回避するためだけにEV証明書に高い費用を払う理由はなくなりました。EV署名済みインストーラーは、より安価なOrganization Validated（OV）証明書と同様にダウンロードレピュテーションを積み上げていく必要があります。

もう1つの変更点は、秘密鍵の保管場所に関するものです。2023年6月1日以降、コード署名の秘密鍵は認定されたハードウェアに保管することが義務付けられています。これが、USBトークン型OV証明書がヘッドレスCIで機能しない理由です。TauriのWindows署名ドキュメントも同じ境界を示しており、標準ガイドは2023年6月1日以前に取得したOV証明書にのみ適用され、それ以降に取得した証明書については発行機関のハードウェアトークンプロセスに従うよう案内しています。

2026年における最もクリーンなデフォルト選択は、トークンを完全に不要にします。Azure Artifact Signing（旧Trusted Signing）は、Azureに統合されたフルマネージドのエンドツーエンドコード署名サービスです。USBトークン不要でクラウドから署名でき、CI/CDパイプラインでネイティブに動作し、Microsoftが管理するHSMに秘密鍵を保管します。以下の優先順位で判断してください。

1. Azure Artifact Signingを第一候補に。 CIネイティブで低コストです（Microsoftは小規模プロジェクト向けに月額約10ドル程度の従量課金プランを提供しています）。ただし、利用可能な地域は米国・カナダ・EU・英国の組織に限定されており、個人開発者は現時点で米国とカナダのみが対象です。
2. これらの地域外の場合は、DigiCert・Sectigo・GlobalSignなどが提供するOV証明書を選択してください。SmartScreenに対するOV証明書の効果は、Azure Artifact Signingと実質的に同等です。
3. 既存のEV証明書は有効期限まで使い続けて構いません。 すでにEV証明書を持っている場合は引き続き有効で署名に使用できますが、SmartScreen警告の回避だけを目的に新たにEV証明書を購入することは正当化されません。

署名あり vs 署名なし

署名なしビルドは、回避手順に慣れた開発者向けには許容されます。技術的な知識のないユーザー向け、およびmacOSで自動更新を行うアプリには、署名は必須です。

electron-updaterによる自動更新

electron-updater（electron-builderの付属ツール）は、最小限のコードでクロスプラットフォームのセルフホスト型自動更新を実現します。GitHub Releases・Amazon S3・DigitalOcean Spaces・Keygen・汎用HTTP(S)サーバーをすぐに利用でき、わずか2行のコードで動作します。一般的な使用例は次のとおりです。

const { autoUpdater } = require("electron-updater");

app.whenReady().then(() => {
  createWindow();
  autoUpdater.checkForUpdatesAndNotify();
});

autoUpdater.checkForUpdatesAndNotify()を呼び出すだけで動作します。setFeedURLを呼び出す必要はありません。electron-builderはビルド時に内部的にapp-update.ymlファイルを自動生成するためです。リリースのホスト先はビルド設定のpublishブロックで指定します。{ "provider": "github" }を指定すると、タグのプッシュがCIをトリガーし、アーティファクトがGitHub Releaseにアップロードされ、アップデーターが自動的に検出します。macOSでは、ビルドが署名・公証されていない限り、この1行は意味をなしません。前のセクションで説明した連鎖と同じです。Linuxには汎用の自動更新メカニズムがなく、AppImageの更新はelectron-updaterで対応できますが、deb/rpmユーザーはパッケージマネージャーを通じて更新します。

配布チャネル

収益と信頼をどの程度自社で維持したいかと、ユーザーへのリーチに基づいてチャネルを選択してください。

• 自社ウェブサイト。 完全なコントロールが可能で、署名の有無を問わず、手数料なし。GitHub ReleasesまたはS3を通じてelectron-updaterと直接連携できます。
• GitHub Releases。 無料のホスティング、バージョン履歴、自動更新統合の最も手軽な方法です。
• Mac App Store。 発見性は向上しますが、サンドボックス化とレビューが必要で、Appleの標準手数料30%が発生します。年間収益100万米ドル未満の開発者はApp Store Small Business Programにより15%に軽減されます。
• Microsoft Store。 SmartScreen対策だけでも十分な価値があります。MSIXパッケージをMicrosoft Storeで公開すると、Microsoftがパッケージを自動的に再署名するため、ユーザーにSmartScreen警告が表示されず、証明書の購入や更新も不要です。
• Homebrew Cask。 casksリポジトリへのプルリクエストを通じたmacOS向けの無料・開発者フレンドリーな配布方法で、brew installで技術系ユーザーにリーチするのに最適です。

実用的な補足として、ElectronのレンダラーはChromiumウィンドウであるため、ブラウザのセッションリプレイ計測ツールはパッケージ化されたデスクトップビルドでも変更なく動作します。これは、開発中のelectron .では再現せず、パッケージング後や自動更新後のユーザー環境でのみ現れるUIの不具合——ネイティブメニューやトレイの操作フロー、ファイルダイアログの動作、署名済みビルドのCSPの差異など——を観察するための数少ない実用的な手段の1つです。

GitHub Actionsによる3プラットフォームの並列CIビルド

すべてをローカルでクロスビルドすることはできません。DMGの公証にはmacOSのツールが必要であり、署名済みWindowsインストーラーにはWindowsのツールが必要なため、単一のマシンで3プラットフォームすべての署名済みビルドを生成することは不可能です。2026年における現実的なアプローチは、macos-latest・windows-latest・ubuntu-latestを並列実行するGitHub Actionsのマトリックスを構成し、署名用のシークレットを暗号化された環境変数として注入することです。タグのプッシュ時にビルドと公開を行う完全なrelease.ymlは次のとおりです。

name: Release
on:
  push:
    tags: ["v*"]

jobs:
  release:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, windows-latest, ubuntu-latest]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - name: Build, sign, and publish
        run: npx electron-builder --publish always
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # macOS署名＋公証（macos-latestのみで読み込まれる）
          CSC_LINK: ${{ secrets.MAC_CSC_LINK }}
          CSC_KEY_PASSWORD: ${{ secrets.MAC_CSC_KEY_PASSWORD }}
          APPLE_ID: ${{ secrets.APPLE_ID }}
          APPLE_APP_SPECIFIC_PASSWORD: ${{ secrets.APPLE_APP_PASSWORD }}
          APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
          # Windows：Azure Artifact Signingの認証情報（windows-latestのみで読み込まれる）
          AZURE_TENANT_ID: ${{ secrets.AZURE_TENANT_ID }}
          AZURE_CLIENT_ID: ${{ secrets.AZURE_CLIENT_ID }}
          AZURE_CLIENT_SECRET: ${{ secrets.AZURE_CLIENT_SECRET }}

各ランナーは自プラットフォームのターゲットのみをビルドし、electron-builderはそのランナーの環境に存在する認証情報を使用して署名を行います。--publish alwaysは全アーティファクトとlatest*.yml更新メタデータを単一のGitHub Releaseにアップロードします。すべてのシークレットはリポジトリまたは環境のシークレットに保管し、ワークフローファイルには記載しないでください。Azure Artifact SigningはGitHub ActionsおよびAzure DevOpsと通常の環境変数を通じて連携するため、Windowsジョブにはセルフホストランナーもトークンも不要です。

Electronアプリのリリースは、魔法のコマンド1つで完結するものではなく、連鎖を正しく守ることが本質です。署名することで公証が可能になり、公証することでmacOSの自動更新が機能し、単一のマシンでは3プラットフォームすべてをビルドできないためCIマトリックスで実行する——この流れを守ってください。buildブロックを設定し、electron-updaterを追加し、release.ymlをコミットすれば、次回のgit tag v1.0.0 && git push --tagsで全プラットフォーム向けの署名済み・自動更新対応インストーラーが一度に生成されます。

よくある質問

macOS・Windows・Linuxの署名済みインストーラーを1台のマシンでビルドできますか？

できません。DMGの公証にはmacOSのツールが必要であり、署名済みWindowsインストーラーにはWindowsのツールが必要なため、単一のマシンで3プラットフォームすべての署名済みビルドを生成することは不可能です。現在使用しているプラットフォーム向けのビルドは可能であり、electron-builderは一部のクロスターゲティングをサポートしていますが、署名と公証はプラットフォームに依存します。2026年における現実的なアプローチは、macos-latest・windows-latest・ubuntu-latestを並列実行するGitHub Actionsのマトリックスを構成し、各ランナーが自プラットフォームのターゲットのみをビルド・署名する方法です。

コード署名証明書なしでMicrosoft StoreはSmartScreen警告を回避できますか？

はい。MSIXパッケージをMicrosoft Storeで公開すると、MicrosoftがパッケージをMicrosoftが管理するHSMに保管されたキーで自動的に再署名するため、ユーザーにSmartScreen警告が表示されず、証明書の購入や更新も不要です。これにより、証明書のコストとレピュテーション構築の両方を完全に回避できます。トレードオフは、ストアへの申請・審査が必要なこと、および自社サイトから直接NSISやMSIインストーラーを配布するのではなく、MSIXとしてパッケージングする必要があることです。

macOSアプリが更新を通知するのに自動インストールされないのはなぜですか？

ほぼ確実にビルドが署名されていないことが原因です。macOSでは、Squirrel.Macの要件により、自動更新を機能させるにはアプリケーションへの署名が必須です。署名されていないアプリは新しいバージョンの存在を検出してユーザーに通知することはできますが、バイナリをサイレントに置き換えることはできません。解決策は完全な連鎖を実行することです。Apple Developer ID証明書を取得し、アプリに署名し、公証を行ってください。コード署名は公証の前提条件であり、公証はmacOSのサイレント自動更新が機能するための前提条件です。

Windows上のSmartScreen警告を回避するためにEV証明書を購入する価値はありますか？

ありません。EV証明書は以前、初回ダウンロード時にSmartScreenを完全にバイパスしていましたが、Microsoftは2024年にその即時レピュテーション付与の動作を廃止しました。現在、EV署名済みインストーラーはより安価なOrganization Validated証明書と同様にダウンロードレピュテーションを積み上げる必要があるため、SmartScreen回避だけを目的にEVの割増料金を支払う正当性はありません。2026年における多くのチームにとって、より優れたデフォルト選択はAzure Artifact Signingです。USBトークン不要でクラウドから署名でき、対象地域外の場合はOV証明書が代替となります。