2026.04.07 プラットフォーム

ElectronのUIをWeb技術で作る実践ガイド｜React・Vue連携から最新v43・軽量化・将来性まで

ElectronはHTML・CSS・JavaScriptで書いたUIを、そのままWindows・macOS・Linuxで動くデスクトップアプリにするフレームワークだ。VS CodeやSlackの土台であり、フロントエンドの知識だけで画面を作れる一方、「重い」「オワコン」という指摘も根強い。この記事は、Electronで実際にUIを組む流れ——レンダラーの画面構築、React・Vueの組み込み、ネイティブUI、preloadとIPC——を最小コードで示したうえで、最新のElectron 43時点のバージョン方針、軽量化、Tauri・Flutterとの使い分け、採用判断までを一次情報でまとめる。

まとめ：ElectronでUIを作るときの要点（先に結論）

  • ElectronのUIはレンダラープロセスが描くWebページ。素のHTML/CSSでもReact・Vueでも同じように作れる。
  • 最新はElectron 43.1.1（2026年7月14日／Chromium 150・Node.js 24）。LTSは無く、常に最新3系だけをサポートし8週ごとに新メジャーが出る。
  • レンダラーとOS機能はpreload＋contextBridge＋ipcRenderer.invokeでつなぐ。nodeIntegration無効・contextIsolation有効が既定であり、崩してはいけない。
  • 「重い」の実体はChromium同梱ゆえの数十〜150MB級の配布サイズと常駐メモリ。ASAR化・不要モジュール削減・ウィンドウ再利用で緩和できるがゼロにはならない。
  • 「オワコン」は誤り。VS Code・Slack・Discordは継続採用。省メモリ最優先ならTauri、Web資産と開発速度優先ならElectronと割り切る。

ElectronがUIを描く仕組み：3つのプロセスとWeb技術の土台

Electronは、UIを描くChromiumと、OS機能を扱うNode.jsを1つの実行ファイルに同梱する。だからブラウザ向けに書いたHTML・CSS・JavaScriptがそのまま画面になり、同時にファイル読み書きやプロセス起動といったブラウザでは禁じられた操作もできる。Webの画面表現とデスクトップのOS権限を両取りする土台と捉えればよい。Electronの成り立ちや基本機能そのものを基礎から押さえたいならElectronとは？入門解説を先に読むと早い。本記事はその先の「UIをどう作り、どう運用するか」に絞る。

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

Electronアプリは役割の違う3種類のプロセスで動く。メインプロセス（main.js）がアプリの入口で、ウィンドウ生成・メニュー・自動更新などOSに関わる制御を持つ。レンダラープロセスは各ウィンドウの中身、つまりUIを描くWebページそのもので、ここにReactやVueのアプリが載る。両者の橋渡しがpreloadスクリプトで、レンダラーに渡してよいAPIだけを選んで公開する。「レンダラープロセス」で検索して迷いやすいのはこの3層の境界だが、UIコードはレンダラー、OS操作はメイン、その仲介がpreloadと覚えれば設計を誤らない。

Chromium×Node.js統合が生む利点と制約

1つのコードベースで3OSに配布できるため、Web開発チームがそのままデスクトップ開発へ移れる。反面、各アプリがChromiumを丸ごと抱えるため配布サイズと常駐メモリが大きくなり、Chromiumの更新に追従して8週ごとにメジャーが上がる保守コストも発生する。この二面性が、後述の軽量化とフレームワーク選定の判断軸になる。ランタイムのNode.js側のバージョン方針はNode.js 26の新機能とLTSスケジュールも参照してほしい。

ElectronのUI構築：レンダラーの画面の作り方

「electron ui」で最初に決めるのは、レンダラーの画面を何で書くかだ。Electronはブラウザと同じDOMを持つので、選択肢は素のHTMLから各種フレームワークまで幅広い。ここでは最小のUIから、フレームワーク組み込み、ネイティブUI、OS機能との接続までを順に示す。

素のHTML/CSSから始める最小UI

レンダラーは1枚のHTMLでよい。ボタンとテキストだけの画面ならこれで動く。

<!doctype html>
<html lang="ja">
  <head>
    <meta charset="utf-8" />
    <meta http-equiv="Content-Security-Policy" content="default-src 'self'" />
    <title>My App</title>
  </head>
  <body>
    <h1>Hello Electron</h1>
    <button id="save">保存</button>
    <p id="result"></p>
    <script src="renderer.js"></script>
  </body>
</html>

メインプロセスはこのHTMLをウィンドウに読み込むだけだ。webPreferencesでpreloadを指定し、contextIsolationとnodeIntegrationは既定値のまま（有効/無効を反転しない）にしておく。

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

function createWindow() {
  const win = new BrowserWindow({
    width: 1000,
    height: 700,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      contextIsolation: true,   // 既定でtrue。無効化しない
      nodeIntegration: false    // 既定でfalse。有効化しない
    }
  })
  win.loadFile('index.html')
}

// レンダラーからの保存要求を受けてファイルへ書き込む
ipcMain.handle('note:save', async (event, text) => {
  const fs = require('node:fs/promises')
  const file = path.join(app.getPath('userData'), 'note.txt')
  await fs.writeFile(file, text, 'utf-8')
  return file  // 保存先パスを返す
})

app.whenReady().then(createWindow)

React・Vue・Svelteを組み込むときの選び方

レンダラーは通常のWebページなので、React・Vue・Svelteをそのまま載せられる。実運用ではビルドツール込みのテンプレートを使うのが早く、Electron ForgeにはViteテンプレートが用意されている。フレームワーク選定はデスクトップ特有の事情よりチームの既存資産で決めてよい。ReactとVueで迷うならReactとVue3の違いの比較が判断材料になる。UIコンポーネント（「electron ui 框架」で探されるボタン・表・ダイアログ部品）はWeb向けライブラリをそのまま使え、Vue系ならVuetify（Vue 3対応）、React系ならMUIなどが定番だ。特別な「Electron専用UIライブラリ」を探す必要はない。

メニュー・トレイ・通知などネイティブUIの追加

Webの画面だけでは出せないOSネイティブのUIは、メインプロセスのAPIで組む。アプリメニュー（Menu）、常駐トレイ（Tray）、ファイル選択（dialog）、OS通知（Notification）が代表格で、これらを足すと「Webページの延長」から「デスクトップアプリ」らしさが出る。

const { Menu, Tray, dialog, Notification } = require('electron')

// アプリケーションメニュー（OSネイティブのメニューバー）
const menu = Menu.buildFromTemplate([
  { label: 'ファイル', submenu: [{ role: 'quit', label: '終了' }] }
])
Menu.setApplicationMenu(menu)

// 常駐トレイアイコン・ネイティブ通知・ダイアログ
const tray = new Tray('icon.png')
new Notification({ title: '完了', body: '保存しました' }).show()
dialog.showOpenDialog({ properties: ['openFile'] })

preloadとIPCによる安全なOS機能の呼び出し

レンダラー（UI）から保存や外部プロセス起動などOS機能を使うには、preloadでcontextBridgeを介してAPIを公開し、ipcRenderer.invokeでメインに問い合わせる。レンダラーに直接Node.jsを触らせない（nodeIntegrationを有効にしない）のが安全設計の核で、これが崩れると読み込んだWebコンテンツからOS権限が奪われる。preload側はこう書く。

const { contextBridge, ipcRenderer } = require('electron')

// レンダラーの window.api として、許可したメソッドだけを露出する
contextBridge.exposeInMainWorld('api', {
  saveNote: (text) => ipcRenderer.invoke('note:save', text)
})

レンダラー（UI）側は公開されたwindow.apiだけを呼ぶ。Node.jsのモジュール名は一切出てこない。

// レンダラー側はNode.jsに触れず、preloadが渡したwindow.apiだけを使う
document.getElementById('save').addEventListener('click', async () => {
  const path = await window.api.saveNote('メモ本文')
  document.getElementById('result').textContent = '保存先: ' + path
})

非同期の要求と応答はipcRenderer.invokeとipcMain.handleの対で扱う（先のmain.jsのnote:saveハンドラが応答側）。この一方通行の境界を保つことが、Electron特有のセキュリティ事故を防ぐ最短路だ。

最小プロジェクトの作成からインストーラ出力まで

「electron アプリ 例」や「webアプリ デスクトップアプリ化」で必要になるのは、雛形生成から配布用インストーラ出力までの一本道だ。公式のElectron Forgeがこの全工程を1つのツールで賄う。

Electron Forgeでの雛形生成

# Electron Forge公式の雛形を生成（Node.js 22.12以上が前提）
npx create-electron-app@latest my-app
cd my-app
npm start        # 開発起動

# Vite + React テンプレートで作る場合
npx create-electron-app@latest my-app --template=vite

生成されたmy-appには、先に示したmain.js・preload.js・index.htmlに相当する最小構成と、パッケージング設定が最初から入っている。既存のWebアプリをデスクトップ化する場合も、レンダラー側にその画面を載せ替えるだけで動き出す。

各OS向けインストーラを1コマンドで出力

配布物の生成もForgeが担う。実行したOS向けのインストーラ（Windowsの.exe、macOSの.dmg、Linuxの.debなど）が生成される。

# 現在のOS向けインストーラ（.exe / .dmg / .deb 等）を出力
npm run make

本番配布ではmacOS・Windowsともコード署名と公証が実質必須で、未署名だと起動時に警告が出る。あわせてレンダラーにはContent-Security-Policyを設定し、外部からのスクリプト読み込みを塞いでおく。

// レンダラーのHTMLに設定（外部読み込みを禁止しXSSの被害を抑える）
<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'self'">

最新バージョンとサポート方針：Electron 43・LTSの有無

「electron 41」「electron lts」といった版クエリの答えを一次情報でまとめる。最新安定版はElectron 43.1.1（2026年7月14日リリース、Chromium 150・Node.js 24）。ElectronはLTS（長期サポート）を提供しない。代わりに最新3メジャーだけをローリングでサポートし、各メジャーはおよそ8週で最古の1本がサポートから外れる。したがって「どの版を選ぶか」ではなく「サポート内の最新へ追従し続ける」のが正しい運用だ。

メジャー Chromium Node.js サポート終了
Electron 43（最新） 150 24 2027-01-05
Electron 42 148 24 2026-10-20
Electron 41 146 24 2026-08-25

Electron 41は2026年8月25日にサポートが切れる。バージョンはChromiumのリリースに連動して決まるため、日付は前後しうる。最新値は公式のリリーススケジュールで確認してほしい。

「重い」を軽くする：サイズとメモリの最適化

「electron 重い」「electron メモリ使用量」の実体は、各アプリがChromiumを同梱する構造にある。最小構成でも配布物は数十MBに達し、常駐メモリもタブ相当のプロセスぶん積み上がる。ゼロにはできないが、次の手で体感は変えられる。

  • ASARアーカイブ化と不要なnode_modulesの刈り込みで配布サイズを圧縮する（Forgeの既定でASARは有効）。
  • ウィンドウとプロセスを増やしすぎない。複数ウィンドウはそのぶんレンダラープロセスが増えメモリを食う。使い回せる画面は1ウィンドウ内で切り替える。
  • 起動時処理を遅延させる。重い初期化はウィンドウ表示後に回し、体感の起動速度を上げる。
  • それでも足りないなら、後述のTauriのようにOS標準WebViewを使う設計へ土台ごと替える判断になる。

Tauri・Flutter Desktopとの比較で分かる適用範囲

「electron flutter」「tauri webgl」で比較検討している読者向けに、UIの作り方が近い3者を並べる。ElectronとTauriはどちらもUIをWeb技術で書く点が同じで、決定的な違いは描画エンジンをアプリが同梱するか（Electron）OS標準WebViewを使うか（Tauri）にある。

観点 Electron Tauri Flutter Desktop
UI記述 HTML/CSS/JS（Web） HTML/CSS/JS（Web） Dart＋独自ウィジェット
描画エンジン Chromium同梱 OS標準WebView Skia/Impeller同梱
バックエンド言語 Node.js Rust Dart
配布サイズの目安 数十〜150MB級 数MB〜十数MB 十数MB〜
学習コスト 低（Web資産流用） 中（Rust） 中（Dart/独自UI）
実績 VS Code/Slack/Discord 比較的新しい モバイル発

TauriはバックエンドがRustで、システムのWebViewを使うぶん配布サイズは数MB級まで小さくなるが、Rustの学習と各OSのWebView差異への対応が要る。詳細はTauriとElectronの違い・将来性にまとめた。Flutter Desktopは描画エンジンを同梱してUIの見た目をOS間で完全に揃えるが、UIはWebではなくDartの独自ウィジェットで、Web資産は流用できない。Node.jsのネイティブモジュールに依存する、あるいは既存のWebフロントをそのまま移植したいプロジェクトではElectronが最も素直な選択になる。

Electronは「オワコン」か：将来性と採用・移行の判断

「electron オワコン」「electron 将来性」に正面から答える。結論としてオワコンではない。2026年時点でもVS Code・Slack（数千万規模のユーザーが日常利用）・DiscordはElectronで動き続けている。話題になった移行事例はMicrosoft Teamsで、2023年にElectronからEdge WebView2へ移り、インストーラは約134MiBから約12MiBへ、メモリは概ね半減、起動は約2倍速になった。ただしWebView2はWindows前提の技術であり、クロスプラットフォームを捨てられるTeamsだから成立した最適化だ。3OS配布を維持するプロダクトには同じ移行はそのまま当てはまらない。

採用判断は単純化できる。「省メモリ・小容量が最優先」ならTauri、「Web資産の流用と開発速度が最優先」ならElectron。逆にElectronを選ぶべきでない場面もはっきりしている——常駐メモリを厳しく絞りたい軽量ユーティリティ、配布サイズが採用可否を左右する組み込み用途、Windowsだけに閉じてよい社内ツール。これらは最初からTauriやWebView2、あるいはネイティブを選ぶほうが後悔が少ない。既存のElectronアプリについては、ユーザー体験がメモリで頭打ちになっていないなら移行コストに見合わないことが多く、慌てて乗り換える必要はない。

よくある質問

ElectronでUIを作るのに最低限おさえる仕組みは？

UIはレンダラープロセスが描くWebページ、OS機能はメインプロセスのNode.jsが担い、両者をpreloadがつなぐ——この3層だけ押さえれば画面は作れます。Electronそのものの定義や成り立ちはElectronとは？入門解説にまとめています。

Electronの最新バージョンは？LTSはありますか？

最新はElectron 43.1.1（2026年7月14日、Chromium 150・Node.js 24）です。ElectronにLTSはなく、常に最新3メジャー（43・42・41）だけがサポート対象で、8週ごとに新メジャーが出ます。運用ではサポート内の最新へ追従し続けるのが基本です。

ElectronのUIはReactやVueで作れますか？

作れます。レンダラーは通常のWebページなので、React・Vue・Svelteをそのまま載せられます。UI部品もWeb向けライブラリ（React系のMUI、Vue系のVuetifyなど）を流用でき、Electron専用のUIフレームワークは不要です。ビルド込みならElectron ForgeのViteテンプレートが手早いです。

Electronは「重い」「オワコン」と聞きますが実際は？

「重い」はChromiumを同梱する構造上の事実で、配布サイズ数十〜150MB級・常駐メモリの大きさが実体です。ASAR化やウィンドウ数の抑制で緩和できます。「オワコン」は誤りで、VS Code・Slack・Discordは継続採用中です。WebView2へ移行したのはWindows専用でよいTeamsなど一部に限られます。

ElectronとTauri・Flutterはどう使い分けますか？

省メモリ・小容量を最優先しRustを扱えるならTauri、Web資産の流用と開発速度を優先するならElectron、UIの見た目をOS間で完全統一したくWebに依存しないならFlutter Desktopが向きます。Node.jsのネイティブモジュールに依存する場合はElectronが最も素直です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る