Electronとは？Web技術でデスクトップアプリを作る仕組みと始め方【v44で実測】

Electron（エレクトロン）とは、HTML・CSS・JavaScriptで書いた画面を、Windows・macOS・Linuxで動くデスクトップアプリにするオープンソースのフレームワークです。英単語のelectronは物理の「電子」を指しますが、開発の文脈ではこのソフトウェアを指します。この記事では、2026年10月21日時点の最新安定版 Electron 44.9.2 を手元のMacで動かし、Hello Worldの起動、配布用パッケージのサイズ、メモリ使用量を実測した結果をもとに、仕組みと始め方、採用を決める条件を整理します。

まとめ：Electronの要点

• ElectronはChromium（画面の描画）とNode.js（OS機能）を1つに同梱したランタイムで、1つのコードから3つのOS向けアプリを作れます。VS Code・Slack・Discord・Figma・Notionなどが採用しています。
• 2026年10月21日時点の最新安定版は44.9.2（Chromium 152・Node.js 24.22.0）。新しいメジャー版は8週ごとに出て、サポートされるのは最新の3系列だけです。
• 始めるならElectron Forge 8の雛形（npx create-electron-app@latest my-app --template vite --typescript）が最短です。Electron 42以降は npm install の時点でバイナリを取得せず、初回起動時に取得します。
• Hello WorldでもmacOS向けの.appは294MB、zipで134MB、起動中のメモリは4プロセス合計で約230〜245MBでした。アプリ本体のコード（app.asar）は11.5KBで、重さのほぼ全部がランタイムです。
• 安全面の既定値は、contextIsolation・sandboxが有効、nodeIntegrationが無効です。画面とOS操作の受け渡しはpreloadとIPCに限り、送信元を検証します。
• 配布サイズとメモリを最優先するならTauri、Web技術だけで全OS同じ描画を得たいならElectronを選びます。

Electronの仕組み：ChromiumとNode.jsを同梱するデスクトップアプリ基盤

Electronアプリは、ブラウザの描画エンジンであるChromiumと、JavaScriptの実行環境であるNode.jsを丸ごと抱えて配布されます。画面はWebページとして描き、任意のファイルの読み書きや外部プロセスの起動など、ブラウザのサンドボックスでは制限される処理はNode.js側で行います。OSごとにSwiftやC#で別々に書く必要がなく、Web開発の知識だけで3つのOS向けのアプリを出せるのが最大の利点です。公式サイトはElectron is an open-source project under the OpenJS Foundationと記しており、ライセンスはMITです。

メインプロセスとレンダラープロセスの役割分担

Electronアプリは役割の違う2種類のプロセスで動きます。メインプロセスはアプリの入口で、Node.jsのAPIを使ってウィンドウの生成やメニュー、ファイル操作を担当します。レンダラープロセスはウィンドウごとに起動し、Chromiumで画面を描きます。両者はIPC（プロセス間通信）でやり取りし、その仲介役が後述のpreloadスクリプトです。画面のコードはレンダラー、OSに触れるコードはメイン、と分けるのが基本設計です。実測時のプロセス構成は、Browser（メイン）・GPU・Utility・Tab（レンダラー）の4つでした。

読み方と名前の由来：Atom Shellからの改名

読み方は「エレクトロン」です。元はGitHubがテキストエディタAtomのために作った土台で、当初はAtom Shellという名前でした。最初のコミットは2013年3月13日で、2015年4月23日に公式ブログがAtom Shell is now called Electronと改名を告知しています。2019年にOpenJS Foundationへ参加し、現在はGitHubの一製品ではなく財団配下のプロジェクトです。なお検索結果には同じ綴りの美容機器ブランド「ELECTRON」も出ますが、本記事のElectronとは無関係です。

Electron製アプリの例と見分け方

公式サイトが挙げる採用アプリ

Electronの公式トップページは、採用例として1Password、Asana、Claude、Discord、Dropbox、Figma、GitHub Desktop、MongoDB Compass、Notion、Obsidian、Postman、Signal、Slack、Trello、Twitch、VS Codeなどを並べています。日本語の音声合成ソフトVOICEVOXも、GitHubのpackage.jsonでElectron 42.1.0を指定しています。大規模な商用アプリで使われ続けていることは、Web技術のデスクトップアプリが実用水準にある根拠になります。ただし自社の要件に合うかは、後述する配布サイズとメモリ、8週ごとの更新に追従できる運用体制で判断します。

手元のアプリがElectron製か確かめる手順

macOSでは、アプリの中に Electron Framework.framework が入っていればElectron製です。次のコマンドで、/Applications内のElectron製アプリと、それが使っているElectronの版を一覧にできます。

for a in /Applications/*.app; do
  f="$a/Contents/Frameworks/Electron Framework.framework/Resources/Info.plist"
  [ -f "$f" ] && echo "$(basename "$a")  app=$(defaults read "$a/Contents/Info.plist" CFBundleShortVersionString)  electron=$(defaults read "$f" CFBundleVersion)"
done

2026年10月21日に手元のMacで実行した結果の一部です（各アプリはその時点でインストールされていた版の値です）。

この表は手元にインストールされていた版の観察で、各社が現在配布している版とは限りません。それでも、インストール済みのアプリが使うElectronの系列には大きな開きがあり、アプリの更新を止めると、組み込まれたElectronもサポート外の系列のまま残ることが分かります。Windowsでは、インストール先の resources フォルダに app.asar があれば、ほぼElectron製と判断できます。

2026年10月時点の最新バージョンとサポート期間

Electronは8週ごとに新しいメジャー版を出し、各版は4週間のalpha、4週間のbetaを経て安定版になります。公式のリリース方針は「The latest three stable major versions are supported」で、長期サポート（LTS）版はありません。2026年10月21日時点の状況を、公式のリリース一覧とリリーススケジュールから整理しました。

44.9.2は2026年10月20日に公開され、Node.js 24.22.0とV8 15.2を同梱しています。45の安定版が出た時点で42はサポート対象から外れるため、42で配布しているアプリは44以降への更新を計画してください。版は短い周期で変わるので、導入時はElectron Releasesで最新を確認します。版ごとの新機能や更新時の注意はElectronのUIをWeb技術で作る実践ガイドで扱っています。

Electronの始め方：Hello Worldを動かす

Node.jsの必要バージョン

electron 44.9.2 のpackage.jsonは "node": ">= 22.12.0" を要求します。雛形ツールのElectron Forge 8はリリースノートで「Node.js 22.17 or newer」と明記しているため、Node.js 22.17以上、できれば現行のLTS系を入れておけば両方を満たします。Node.jsの版の選び方はNode.js 26の新機能と破壊的変更・LTS移行日にまとめています。

Electron Forge 8による雛形の生成

実務の出発点は公式の雛形ツールElectron Forgeです。2026年9月29日公開のForge 8で、テンプレートは「バンドラーごとに1つ」に整理され、TypeScriptは --typescript の指定に変わりました。Vite＋TypeScriptの構成は次の1行で作れます。

npx create-electron-app@latest my-app --template vite --typescript
cd my-app
npm start

手元では45秒で依存関係のインストールまで終わり、forge.config.mts・vite.main.config.mts・vite.preload.config.mts・vite.renderer.config.mts と、src 配下に main.ts・preload.ts・renderer.ts が生成されました。package.jsonのスクリプトは start・package・make・release・lint・typecheck です。Forge 7の publish は release に改名され、旧名は非推奨の別名として残っています。リンターとフォーマッターにはESLint・Prettierではなく、Rust製のoxlintとoxfmtが入ります（Oxcの構成と使い方を参照）。

Electronの最小構成と手動セットアップ

仕組みを理解するには、Forgeを使わず手で書くのが早道です。まずプロジェクトを作ってElectronを入れます。

mkdir hello-electron && cd hello-electron
npm init -y
npm install --save-dev [email protected]

Electron 42で、npm install時のpostinstallスクリプトによるバイナリ取得が廃止されました。公式の破壊的変更の一覧は、理由をnpmを狙ったサプライチェーン攻撃への対策と説明しています。そのため上のコマンドは数秒で終わり、初回の npx electron . で「Downloading Electron binary…」と表示され、macOS x64版で128.2MBのzipを取得します（実測で初回起動まで約29秒、2回目以降は即時）。CIで事前に取得したいときは npx install-electron --no を使います。npm install --ignore-scripts でも動くようになったのは、この変更の利点です。

ここでは本記事の実測と同じ44.9.2に固定しています。新しく採用するときは、その時点でサポート中の最新版を指定してください。ファイルは package.json・main.js・preload.js・index.html・renderer.js の5つです。package.jsonは、npm installが書き込んだ devDependencies を残したまま、main と scripts を次のように書き換えます。

{
  "name": "hello-electron",
  "version": "1.0.0",
  "main": "main.js",
  "scripts": {
    "start": "electron ."
  },
  "devDependencies": {
    "electron": "44.9.2"
  }
}

メインプロセス（main.js）でウィンドウを作ります。

const { app, BrowserWindow } = require('electron')
const path = require('node:path')

function createWindow () {
  const win = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js')
    }
  })
  win.loadFile('index.html')
}

app.whenReady().then(() => {
  createWindow()
  app.on('activate', () => {
    if (BrowserWindow.getAllWindows().length === 0) createWindow()
  })
})

app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') app.quit()
})

preload.jsで、画面に渡す値だけを公開します。

const { contextBridge } = require('electron')

contextBridge.exposeInMainWorld('versions', {
  node: () => process.versions.node,
  chrome: () => process.versions.chrome,
  electron: () => process.versions.electron
})

index.htmlにはContent-Security-Policyを置き、スクリプトは別ファイルのrenderer.jsから読み込みます。script-src 'self' の下ではHTMLに直接書いたscriptは実行されないため、インラインに書かないのが正しい形です。

<!DOCTYPE html>
<html lang="ja">
  <head>
    <meta charset="UTF-8">
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'">
    <title>Hello Electron</title>
  </head>
  <body>
    <h1>Hello World!</h1>
    <p id="v"></p>
    <script src="renderer.js"></script>
  </body>
</html>

// renderer.js
document.getElementById('v').textContent =
  `Node ${window.versions.node()} / Electron ${window.versions.electron()}`

npm start で「Hello World!」と「Node 24.22.0 / Electron 44.9.2」が表示されたウィンドウが開けば成功です。この画面で typeof require を評価すると undefined で、レンダラーからNode.jsのAPIには触れない状態になっています。コードを書かずにAPIを試したいときは、公式の実験用アプリElectron Fiddleも使えます。

配布用パッケージのサイズとメモリの実測

上のHello Worldを@electron/packager 20.3.0でmacOS（x64）向けの.appにし、Forge 8の雛形も npm run make でzipにして測りました。メモリは app.getAppMetrics() の値を起動5秒後に4回取得しています。

アプリ本体のコードを収めたapp.asarはHello Worldで9KB、Forge雛形でも11.5KBしかなく、配布物の大きさはほぼ全部がChromiumとNode.jsのランタイムです。つまり自分のコードを削っても配布サイズはほとんど減りません。GitHubの44.9.2リリースに置かれたランタイム単体のzipも、Windows x64が151.1MB、macOS x64が128.2MB、Linux x64が117.4MBあります。メモリはmacOSの app.getAppMetrics() が返すworking setの合計で、Browser約101MB・Tab約60MB・GPU約46MB・Utility約24MBの内訳でした（Intel Core i9-9880H・macOS 26.6.2）。ウィンドウを1つ増やすごとにレンダラーのプロセスが1つ増えるため、画面を複数開くアプリほど差が開きます。

Mac App Store以外でmacOS向けに配布するにはコード署名とAppleの公証が必要で、その手順はElectron製Macアプリのコード署名とApple公証で実測しています。WindowsでMSIX形式にする場合はwinapp CLIの導入とMSIX化の手順が参考になります。

WindowsのNSISインストーラやLinuxのAppImageを作り、electron-updaterで自動更新まで配る設定はelectron-builderの使い方とelectron-updaterの自動更新で解説しています。

セキュリティの既定値と追加で守る設定

既定で有効になっている3つの保護

ElectronのレンダラーはWebページなので、XSSが起きるとNode.jsの権限まで奪われるおそれがあります。そこで現在の既定値は、レンダラーからNode.jsを切り離す側に倒れています。nodeIntegrationの無効化はElectron 5、contextIsolationの有効化は12、sandboxの既定化は20で入りました。上のHello Worldで getLastWebPreferences() を読むと、contextIsolation=true、nodeIntegration=false、sandbox=trueでした。古い記事のコードにある nodeIntegration: true や contextIsolation: false を写さないことが、最初の防御になります。

IPCの送信元と引数の検証

公式のセキュリティチェックリストは20項目あり、その17番目が「Validate the sender of all IPC messages」です。画面に公開する操作を絞ったうえで、メイン側で送信元と引数を確かめます。

// preload.js：画面に渡すのは「メモを保存する」操作だけ
const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('api', {
  saveNote: (text) => ipcRenderer.invoke('save-note', text)
})

// main.js：送信元と値を確かめてから保存する
const { app, ipcMain } = require('electron')
const path = require('node:path')
const fs = require('node:fs/promises')
const { pathToFileURL } = require('node:url')

// 受け付けるのは同梱した index.html を表示しているメインフレームだけ
const allowedUrl = pathToFileURL(path.join(__dirname, 'index.html')).href

ipcMain.handle('save-note', async (event, text) => {
  const frame = event.senderFrame
  if (!frame || frame !== event.sender.mainFrame || frame.url !== allowedUrl) {
    throw new Error('不正な送信元です')
  }
  if (typeof text !== 'string' || text.length > 10000) throw new Error('不正な値です')
  const file = path.join(app.getPath('userData'), 'note.txt')
  await fs.writeFile(file, text, 'utf8')
  return file
})

この組み合わせを44.9.2で動かすと、window.api.saveNote('メモの本文') はユーザーデータ領域のnote.txtへ保存され、saveNote(123) は「不正な値です」、同じフォルダの別のHTMLを開いて呼んだ場合は「不正な送信元です」で拒否されました。プロトコルが file: かどうかだけを見る判定では、この別のHTMLを通してしまいます。画面側からは window.require も window.process も undefined で、触れるのは公開した1関数だけです。なおElectron 29以降は ipcRenderer を丸ごとexposeInMainWorldで渡しても、受け取った側は空のオブジェクトになり、invoke は使えません（44.9.2でも確認）。チャンネル名を引数で受け取って何でも中継する汎用関数を作ると同じ穴が開くため、公開するのは用途を限った関数だけにします。

Forge雛形のfuses設定と機能制限

Forge 8の雛形は、配布時にElectronの機能スイッチ（fuses）を切り替える設定を最初から含んでいます。生成された forge.config.mts では、ElectronをNode.jsとして起動する RunAsNode、環境変数 NODE_OPTIONS と --inspect 系引数の受け付けを無効にし、Cookieの暗号化、ASARの整合性検証、ASARからだけアプリを読む設定を有効にしています。配布物を改ざんして任意のコードを動かす経路を塞ぐための設定です。ただし公式のfusesの解説のとおり、RunAsNodeを無効にすると child_process.fork でNode.jsとして子プロセスを起動する処理が動かなくなります。手で構成する場合は、アプリが使う機能と照らし合わせてから同じ値に揃えます。

ElectronとReact・Vue・Next.jsの連携

レンダラーの中身はChromiumなので、ReactやVueで作った画面をそのまま載せられます。Forge 8のViteテンプレートに、通常のWeb開発と同じ手順でReactを追加すれば動きます。Viteの基本はVite + Reactの環境構築手順、型の付け方はTypeScriptの型・型推論・型注釈の書き分けが参考になります。

Next.jsはサーバーで動く前提の機能（Server ActionsやAPIルート、画像最適化）がElectronの中ではそのまま使えないため、静的書き出しにしてレンダラーで読み込む構成が現実的です。Next.js 16の最新バージョンとリリース履歴で版の状況を確認してから選んでください。画面の作り込み方はElectronのUI構築ガイドでReact・Vue別に解説しています。

Electronを選ぶ条件と選ばない条件

比較の相手は主に、OSのWebViewを使うTauriと、独自エンジンで描くFlutterです。

Electronを選ぶのは、Web版と画面のコードを共有したい、全OSで描画を揃えたい、OS機能側もJavaScriptで書きたい場合です。全OSで同じ版のChromiumを使うので、OSごとにブラウザエンジンが違うことによるCSSやJavaScriptの差は出ません。フォントやウィンドウ枠などOS側の違いは残るため、OSごとの表示確認は省けません。逆に、配布サイズが数十MBに収まることが要件にある、常駐型でメモリを抑えたい、スマートフォン版も同じコードで出したい場合はElectronを選ぶべきではありません。Hello Worldでも294MBあり、設計では削れない部分だからです。

Tauriは2024年10月2日の2.0でiOS・Androidに対応しました。Electronとの実測比較はTauriとは？Electronとの違い・将来性にあります。モバイルを含めたクロスプラットフォーム開発を検討している場合は、一創のFlutter / React Native開発でもご相談を承っています。PHPの資産を生かしたい場合は、内部でElectronを使うNativePHPという選択肢もあります。

「Electronはオワコンか」という問いには、主要アプリの採用が続き、8週ごとの更新も止まっていない以上、オワコンではないと答えられます。将来性の根拠と、乗り換えを考えるべきケースはElectronのUI実践ガイドの将来性の章で詳しく扱っています。

よくある質問

Electronはオワコンですか？

オワコンではありません。主要アプリの採用が続き、2026年も8週ごとに新しいメジャー版が出ています。配布サイズとメモリを最優先する新規開発ではTauriが有力な候補です。

electronの意味は「電子」ですか？

英単語としてのelectronは物理の電子です。ソフトウェアのElectronは、2015年4月にAtom Shellから改名したデスクトップアプリ用フレームワークの名前で、読み方は「エレクトロン」です。

Electronで作ったアプリは商用利用できますか？

できます。ElectronはMITライセンスです。配布物には同梱するChromiumなどのライセンス文書（LICENSES.chromium.html、44.9.2で約20MB）が含まれるので、削除せずに配布してください。

Electronアプリが重いのはなぜですか？

ChromiumとNode.jsをアプリごとに同梱するためで、Hello Worldでも.appは294MBでした。ウィンドウ数を抑える、画面を必要になってから読み込むといった対策で増え方は抑えられますが、ランタイム分は減らせません。

ElectronでReactは使えますか？

使えます。Forge 8のViteテンプレートにReactを追加する構成が手早く、OSに触れる処理はpreloadとIPC経由でメインプロセスに任せます。

ElectronでiOSやAndroidのアプリは作れますか？

作れません。ElectronはWindows・macOS・Linux向けです。同じ技術でモバイルも出したい場合は、Tauri 2.0以降やFlutterを検討します。

関連記事

• ElectronのUIをWeb技術で作る実践ガイド｜React・Vue連携から最新v43・軽量化・将来性まで
• Tauriとは？読み方・Electronとの違い・将来性を実測で解説【v2.12／3.0 alpha】
• Electron製Macアプリのコード署名とApple公証｜notarytoolとentitlements設定の実測手順
• Vite + Reactの環境構築手順｜Viteとは・Vite 8.3の変更点とTypeScript 7対応
• Node.js 26の新機能と破壊的変更・LTS移行日｜24からの移行手順【26.11.1対応】