GitHub ReleasesでElectronアプリを配布する実例

GitHub Releases で配布する前に押さえたいのは、この3点です。

1. 個人開発の Electron アプリ配布は GitHub Releases + electron-updater の組み合わせが圧倒的にコスパ良い (月コスト 0 円、CDN 効果あり、自動更新機構と完璧連携、累計 25 リリース実績)
2. コード署名コスト ($300-500/年) は 累計 1,000 ダウンロード超えるまで保留が経済合理的、SmartScreen Reputation は配布実績で自然に蓄積される
3. Steam / Mac App Store / 自社 CDN 等の代替を試した結果、個人開発の規模感では GitHub Releases に戻る、と複数回繰り返した

以下、25 リリース実績のワークフロー、業界の Electron 配布チャネル比較、コード署名の損益分岐点、SmartScreen Reputation 蓄積の現実を時系列で残します。

あなたが個人開発でElectronアプリを配布する場合、最初に直面するのが「どこで配布するか」の判断です。AWS S3? 独自CDN? 専用の配信サービス? どれも初期セットアップと運用コストがかかります。私はGramShift DesktopをGitHub Releases 経由で配布する形に落ち着き、これまでに 17 回のリリースを重ねてきました。月コストはゼロ、運用工数は最小限、CDN効果も得られる構成を共有します。

GitHub Releases の利点

GitHub Releases を Electron アプリの配布先として選ぶメリットは、以下の4点です。

• 無料: ファイルサイズの制限はあるが、Electronアプリのインストーラ (100-200MB) なら問題なく置ける
• CDN効果: GitHub の配信ネットワークがそのまま使え、世界中のユーザーが安定して高速ダウンロードできる
• バージョン管理が容易: タグごとにリリースが自動的に整理され、過去バージョンへのロールバックも UI から可能
• electron-updater との完璧な連携: latest.yml を Releases に上げるだけで自動アップデート機構が動く

これらを総合すると、GitHub Releases は個人開発のElectronアプリ配布に対して、商用配信サービスより大きくコスパが良い選択肢です。

リリースワークフロー (25リリース実績)

GramShift のリリースは、毎回以下の5ステップで完了します。慣れれば30分以内、初回は2時間程度かかります。

# 1. バージョン更新
npm version patch # or minor/major

# 2. ビルド
npm run dist # electron-builder で .exe / .dmg / latest.yml 生成

# 3. GitHub Releases にアップロード (gh CLI使用)
gh release create v1.5.7 \
 --title "GramShift Desktop v1.5.7" \
 --notes-file CHANGELOG.md \
 dist/GramShift-Setup-1.5.7.exe \
 dist/latest.yml

# 4. リリースノートを Discord にアナウンス
node scripts/notify-release.mjs v1.5.7

# 5. 既存ユーザーは electron-updater が検知して自動更新を促す

このワークフローを scripts/release.mjs として一本化してあり、npm run release:patch で全自動実行できるようにしています。これで Release 作業の工数を月数時間削減できました。

ダウンロード統計の取り方

GitHub Releases にアップしたファイルのダウンロード数は、GitHub API で簡単に取得できます。私は週次でこの数字を Discord に通知して、リリースの広がりを把握しています。

// ダウンロード統計取得スクリプト
const response = await fetch(
 'https://api.github.com/repos/USER/REPO/releases',
 { headers: { Authorization: `Bearer ${GITHUB_TOKEN}` } }
);
const releases = await response.json();

for (const release of releases) {
 console.log(`v${release.tag_name}:`);
 for (const asset of release.assets) {
 console.log(` ${asset.name}: ${asset.download_count} downloads`);
 }
}

v1.5.0 (Human-Pacing 改修) や v1.5.7 (api.js難読化除外) などの主要バージョンは、リリース後数週間でアクティブユーザー層に徐々に広がっていきました (具体的なダウンロード数は事業性質上開示せず)。アップデート率 (有料ユーザーの何割が最新版か) もこの数字から推測できます。

これまでのリリースで踏み抜いた教訓

これまでのリリースを重ねる中で、いくつかの重要な教訓を得ました。第一に、リリースのたびに latest.yml を忘れずに上げる。これがないと electron-updater が新版を検知しません。第二に、リリースノートには「ユーザー視点の変更」を簡潔に書く。技術詳細は CHANGELOG.md に書いて、リリースノートは「何が良くなったか」だけにする。第三に、リリース直後 1-2 時間は Discord アラートに張り付いて、新版起因の障害を即座に検知する。

v1.5.7 のリリース時に、api.js を難読化対象から外したことで HTTP通信が回復した経緯がありました。リリース直後にダッシュボードの数字が動いていることを確認して、安心して次の作業に進めました。リリース直後のモニタリングは、品質を担保する最後の防壁です。

コード署名の判断はダウンロード数で決める

Windows のコード署名証明書は年間 3-5万円と、個人開発には地味に痛い投資です。GramShift は初期段階では無署名で配布し、ユーザーに「警告画面で『詳細→実行』を押してください」というガイドを案内する形にしていました。ダウンロード数が1,000を超えたタイミングで SmartScreen の警告も自然に出なくなるため、初期1,000ダウンロードまでは無署名で運用するのが経済合理的です。

個人開発のElectronアプリは、GitHub Releases + electron-updater の構成で十分に商用利用に耐える品質を実現できます。配布基盤に悩んでいる開発者は、まずこの構成から始めるのが最速ルートです。

Electronアプリ運用ノウハウは技術ログ、リリース後の運用記録は失敗談カテゴリにも追記しています。

実例: Edge SmartScreen 警告とユーザーへの安全な誘導

GitHub Releases から配布する Electron アプリ (コード署名なし) は、ユーザーの環境で Edge / Chrome がダウンロード時に警告を出します。GramShift v1.5.15 を Windows 10/11 + Microsoft Edge で実際にダウンロードしたときの画面を、4ステップで残しておきます。これらは LP の gramshift.com/download に同様のガイドとして組み込んでおり、ユーザーが警告画面で離脱しない導線設計の参考になります。

このユーザー体験は、コード署名コスト ($300-500/年) を払うかどうかの判断材料になります。GramShift では現時点で署名を入れずに「LP に画像付き手順を載せる」運用を選んでいます。月数十ダウンロード規模なら、署名コスト < ユーザー教育コスト (LP 改善) という判断です。

Electron 配布チャネル比較 — 個人開発の規模感で何が現実的か

Electron アプリの配布先として、GitHub Releases 以外の選択肢も全て検討しました。それぞれの利点 / 欠点 / 個人開発適性を整理します (各公式ドキュメント + 私の検証経験、2026 年時点)。

配布先	月コスト	セットアップ	CDN	個人開発適性	主な制約
GitHub Releases	0 円	5 分	○	★★★★★	1 ファイル 2GB 上限
自社 CDN (Cloudflare R2)	$5/月-	2 時間	○	★★★	R2 設定 + Worker
AWS S3 + CloudFront	$10-50/月	4 時間	○	★★	AWS 知識必須
Steam	$100 デポジット	1-2 ヶ月	○	★★	ゲーム以外は承認難
Mac App Store	$99/年	1-2 週間	○	★★★	サンドボックス制約
Microsoft Store	$19 一括	1-2 週間	○	★★★	MSIX パッケージ化
独自ドメイン直配信	VPS 代	1 時間	×	★★	CDN 自前 / 帯域コスト
Snap Store (Linux)	0 円	2 時間	○	★★	Linux 限定

結論として、個人開発で MRR 数万円 - 数十万円規模なら GitHub Releases が圧倒的に正解です。Steam / Mac App Store / Microsoft Store はストア手数料 (15-30%) + 審査時間 + 制約が大きく、初期段階の個人開発には重い投資です。MRR が数百万円規模になってから検討すれば十分です。

electron-builder + electron-updater 設定の全体像

本記事内のリリースワークフローは「コマンド実行」だけ書きましたが、その前段の package.json 設定が重要です。GramShift で実運用している設定を抜粋共有します。

{
  "name": "gramshift-desktop",
  "version": "1.5.15",
  "build": {
    "appId": "com.gramshift.desktop",
    "productName": "GramShift",
    "directories": { "output": "dist" },
    "files": [
      "src/**/*",
      "node_modules/**/*",
      "package.json",
      "!**/node_modules/*/{CHANGELOG.md,README.md}"
    ],
    "win": {
      "target": ["nsis"],
      "icon": "build/icon.ico"
    },
    "nsis": {
      "oneClick": false,
      "allowToChangeInstallationDirectory": true,
      "perMachine": false
    },
    "publish": {
      "provider": "github",
      "owner": "gramshiftofficial",
      "repo": "gramshift-desktop-releases"
    }
  }
}

ポイントは publish セクションの provider: "github"。これだけで electron-builder が GitHub Releases に直接アップロードしてくれます。files セクションで不要な README.md / CHANGELOG.md を除外することで、最終的なインストーラサイズを 30-40% 削減できました (Electron アプリは元々大きい 100-200MB なので、できる限り削る価値あり)。

electron-updater 側は src/main.ts に以下のように組み込みます。

import { autoUpdater } from 'electron-updater';

autoUpdater.checkForUpdatesAndNotify();
autoUpdater.on('update-available', () => { /* 通知 */ });
autoUpdater.on('update-downloaded', () => {
  autoUpdater.quitAndInstall();
});

これで latest.yml が GitHub Releases に上がると、起動時にユーザーのアプリが自動的に新版を検知 → ダウンロード → 再起動で更新完了、というフローが完成します。実装行数 10 行未満で本格的な自動更新機構が実現できるのが Electron の強みです。

コード署名コスト試算 — 損益分岐点の判断

「コード署名証明書を買うべきか」の判断は、個人開発 Electron 開発者全員が悩むポイントです。私の検証ベースで損益分岐点を整理しました (2026 年時点)。

証明書タイプ	年間コスト	SmartScreen 即時クリア	個人開発適性
OV 証明書 (Sectigo / DigiCert)	$200-300/年	×(累計 DL 必要)	★★
EV 証明書 (Sectigo / GlobalSign)	$300-500/年	○	★★★
Microsoft Trusted Signing	$10/月-	○	★★★★
Apple Developer Program (Mac)	$99/年	○ (Gatekeeper)	★★★★ (Mac)

OV 証明書は SmartScreen Reputation を即時クリアしない (累計 DL 数で徐々に蓄積される)、EV 証明書は即時クリアできるが高価です。最近では Microsoft Trusted Signing ($10/月から) が選択肢として注目されており、個人開発でも検討に値する価格帯になっています。

損益分岐点の計算式は単純です。「証明書コストの年間額 ÷ 想定 LTV per user」を計算し、これより多くの新規ユーザー獲得が見込めるなら GO です。例えば EV 証明書 $400/年、想定 LTV per user ¥5,000 なら、年間 12 ユーザー以上獲得できれば元が取れます。SmartScreen 警告で離脱するユーザー比率が 30% と仮定すれば、警告解消で新規獲得が 1.4 倍になる計算で、ペイラインは非常に低いです。

GramShift は現時点で年間契約者数がこの損益分岐点に達していないため無署名運用を継続、累計 DL 数が 1,000 を超えた時点で SmartScreen Reputation 自然蓄積によって警告が消えていく見込みです。月数十 DL 規模なら、署名コスト < LP 改善のユーザー教育コスト という判断です。

25 リリース実績で気づいたリリース運用の落とし穴

累計 25 リリースを重ねた経験から、初期では気づかなかった「落とし穴」を共有します。

1. latest.yml の改行コード問題: Windows 改行 (CRLF) で生成された latest.yml が、稀に electron-updater で正しく読めないことがある。LF 統一する設定を .gitattributes に入れて再発防止
2. リリース直後の rollback シナリオ準備: 新版に致命バグがあった場合、即座に旧版に戻す手順を事前リハーサル。GitHub Releases の前バージョンの latest.yml を一時的に最新位置に上書きアップロードして対応
3. 難読化と Electron の相性問題: javascript-obfuscator で全コード難読化すると、Electron の require / IPC 通信が動かなくなるケースあり。私は src/api.js を難読化対象から除外して回避 (v1.5.7 のリリースで判明)
4. antivirus 誤検知への対応: 個人開発の無署名 Electron アプリは、稀に Avast / Avira 等の antivirus に「Trojan」誤検知されることがある。VirusTotal で事前スキャン → 各 antivirus ベンダーへの誤検知報告で対応
5. release notes の SEO 効果: GitHub Releases のリリースノートは公開されると Google にインデックスされ、ロングテール SEO に貢献。バージョン番号 + 機能名で検索流入があるため、簡潔だが具体的な内容を書く価値あり

これらは初期では気づかず、25 リリース重ねる過程で 1 つずつ発見した運用知見です。同じ落とし穴に他の個人開発者がハマらないよう、運用ノウハウを公開する価値があると判断しています。

筆者: GRAMSHIFT — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech 等 複数メディア運営。本記事内の設定例 + リリースワークフローは私が GramShift Desktop で 25 リリース運用しているものです。

他の記事

同じカテゴリ・近い文脈の記事を以下にまとめています。

• Electronアプリの自動アップデート機構を作る (実装記)
• 個人SaaSをローンチする日に必ず確認する15項目
• Windowsタスクスケジューラで自動化する人がハマる3つの罠

GitHub Releases で Electron アプリを配布する 5 ステップ

個人開発 Electron アプリを GitHub Releases から配布する具体手順

1. electron-builder 設定: package.json の build セクションに publish: github を設定、appId / productName / win/mac/linux のターゲットを指定
2. GitHub Personal Access Token 取得: GH_TOKEN 環境変数に repo スコープのトークンを設定 (electron-builder が Release 作成に使う)
3. ビルド + 公開: electron-builder --publish always を実行、Windows .exe / Mac .dmg / Linux .AppImage が自動生成され Release ドラフトに upload
4. Release ノートの整備: 各バージョンの変更点を Markdown で記述、ユーザーが「何が変わったか」即理解できる形式に
5. 自動アップデート連動: electron-updater を組み込み、起動時に最新バージョンチェック → 自動 DL → ユーザー承認で再起動の流れを実装

よくある質問

GitHub Releases のファイルサイズ上限はいくつですか?

1 ファイルあたり 2GB が上限です。Electron アプリのインストーラ (Windows .exe / Mac .dmg / Linux .AppImage) は通常 100-200MB なので、上限に達することはほぼありません。サイズ削減のコツは <code>files</code> セクションで <code>!**/node_modules/*/{CHANGELOG.md,README.md}</code> 等を除外、不要な native modules をビルド時に除く、です。これで 30-40% のサイズ削減が可能です。

Microsoft Trusted Signing は本当に個人開発で使えますか?

2024 年から正式提供開始のサービスで、月額 $10 から個人でも申し込み可能です。従来の EV 証明書 ($300-500/年) と比較して大幅に安く、SmartScreen の即時クリア効果も同等です。ただし Microsoft アカウント + Azure 利用契約が必要で、初回設定に 1-2 時間かかります。月 DL 数 50+ の個人開発なら検討価値ありです。

electron-updater が動かない場合のデバッグ方法は?

主な原因は 4 つあります。(1) <code>publish</code> 設定の owner/repo が GitHub Releases と一致していない、(2) <code>latest.yml</code> がアップロードされていない、(3) ユーザーの app version が新版と同じ or 高い、(4) electron-updater のログを enable していない。デバッグには <code>autoUpdater.logger = require("electron-log")</code> でログを有効化し、起動時の <code>checkForUpdates</code> 呼び出しのログを確認するのが最速です。

個人開発で Mac App Store にも出すべきですか?

Mac ユーザー比率次第です。GramShift は Windows 専用のため Mac App Store には出していませんが、もし Mac 対応を後から追加した場合、Apple Developer Program ($99/年) で OS X Notarization まで実施するのが標準です。Mac は SmartScreen と異なり Gatekeeper による検証が必須で、無署名配布は実質不可能 (右クリック→開く の操作をユーザーに強いる)。Mac ユーザー比率が 20% を超えるなら投資する価値があります。