GitHub ReleasesでElectronアプリを配布する実例
個人開発のElectronアプリ配布は無料でできる、ただし設計に工夫が必要
あなたが個人開発で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 の構成で十分に商用利用に耐える品質を実現できます。配布基盤に悩んでいる開発者は、まずこの構成から始めるのが最速ルートです。