Electronはオワコンか？採用状況・将来性とUIの作り方【Electron 45で実測】

Electronは「重い」「Tauriに置き換わる」と言われ続けていますが、2026年もオワコンではありません。2026年10月21日にElectron 45.0.0が公開され、VS CodeやDiscordは2026年に入ってもElectronの版を上げています。一方で、Microsoft Teamsのように離れた大型アプリもあります。この記事では、公式のリリース記録、主要アプリの採用と離脱、npmのダウンロード数、Electron 45で測ったメモリとIPCの数値から将来性を判断し、後半ではReactやVueでElectronのUIを作る手順と、43〜45でUIのコードに効く変更点を説明します。

まとめ：Electronの将来性とUI開発の要点

• オワコンではありません。2026年1月1日〜10月26日に安定版が178件公開され、メジャー版は40〜45の6つが出ました。8週ごとに新しいメジャー版が出て、最新3系列がサポートされます。
• VS Codeは2026年10月26日時点でElectron 43.8.3を指定し、Discordは2026年9月にElectron 42へ更新しました。反対に新しいTeamsはEdge WebView2へ移り、Microsoftは「最大2倍の速さ、メモリ50%減」と公表しています。
• npmのダウンロード数はElectronも伸びていますが、Tauriの伸びの方が速く、差は2024年10〜12月の9.4倍から2026年7〜9月の3.0倍まで縮みました。ダウンロード数は利用者数ではありませんが、少なくともElectronの取得回数が減っている兆しはありません。
• Electron 45で小さなHTMLを表示して測ると、1ウィンドウのアプリで合計約245MB、ウィンドウを1枚増やすごとに約60MB増えました。WebContentsViewも1枚ごとに画面用のプロセスが1本増えます。この条件では、画面の数がメモリの増え方を大きく左右しました。
• UIはレンダラープロセスで動くWebページなので、素のHTMLでもReact・Vueでも作れます。OSの機能はpreloadとIPCを通して呼び、Electron 44以降はレンダラーからclipboardモジュールを使えず、45ではsandboxのpreloadから Buffer や require('events') が消えています。

以下、将来性の根拠、重さの実測、UIの作り方、版ごとの変更点の順に説明します。

Electronはオワコンか：2026年の開発・採用状況から見た将来性

オワコンかどうかは、開発が続いているか、主要なアプリが使い続けているか、新しく選ばれているかの3つで判断できます。どれも公開データで確かめられます。

8週ごとのメジャー更新と最新3系列のサポート

Electronは公式のリリース方針で、メジャー版を8週間ごとに出し、直近の安定版3系列をサポートすると定めています。LTS（長期サポート版）はありません。公式のリリース一覧を数えると、2026年1月1日〜10月26日に公開された安定版は178件で、メジャー版は1月15日の40.0.0から10月21日の45.0.0まで6つ出ています。開発が止まった兆しはありません。

サポート終了日は公式スケジュールの予定日（†付きの暫定値）で、公開日は公式リリース一覧の表示日です。スケジュール上の安定版の予定日は、45が10月20日、43が6月29日と1日前になっています。

サポートは約半年で切れるので、Electronで作ったアプリは年に数回、版を上げる作業が前提になります。ここを運用で回せない組織には向きません。最新版の確認方法と始め方はElectronとは？Web技術でデスクトップアプリを作る仕組みと始め方にまとめています。

使い続けるアプリと離れたアプリ：VS Code・Discord・1PasswordとTeams

主要アプリの公開情報を見ると、使い続けているアプリと離れたアプリの両方があります。

• Visual Studio Code：公式リポジトリの.npmrcが、2026年10月26日時点で runtime="electron"、target="43.8.3" を指定しています。
• Discord：2026年9月8日のパッチノートで「デスクトップアプリのElectronを42へ更新した」と書いています。
• 1Password：2021年8月12日の公式ブログで、Mac版をSwiftUIで作る作業を止め、サポート対象のすべてのmacOSをElectron版でカバーする判断を説明しています。ネイティブからElectronへ寄せた例です。
• Microsoft Teams：新しいTeamsはElectronからEdge WebView2へ移りました。Microsoftは2023年3月27日の発表で「最大2倍の速さ、メモリ使用量50%減」と書いています。ただし同じ公式ブログが、ElectronもWebView2も同じChromiumを土台にしていると明記しています。Web技術を捨てたのではなく、Chromiumを同梱する方式からOSの共有ランタイムを使う方式へ移った例です。

WebView2はMicrosoft以外の開発者も使えるWindows向けの部品で、ランタイムの配布方法も公開されています。ただしmacOSやLinuxでは使えないため、3つのOSで同じ描画を保ちたいアプリには別の手段が要ります。VS CodeやDiscordはElectronのまま版を上げています。

npmダウンロード数で見るElectronとTauriの差

新しく選ばれているかを直接測る公開データはありませんが、関連パッケージの取得回数はnpmのダウンロード数APIで確かめられます。開発時に入れるパッケージ同士として、electron と Tauriのコマンドラインツール @tauri-apps/cli を四半期ごとに比べました（2026年10月26日取得）。

Electronの取得回数は2年で約7.9倍に増えており、衰退を示す数字ではありません。同じ期間にTauriは約25倍で、取得回数の差は縮んでいます。これは開発者の手元やCIでの取得回数の比較で、採用されたアプリの数や比較検討の件数を示すものではありません。GitHubのスター数は、2026年10月26日にGitHub APIで取得した値でElectronが約12.4万、Tauriが約11.2万でした。

「Electronは重い」の実測：Electron 45のメモリ使用量

「重い」と言われる理由は、アプリごとにChromiumとNode.jsを同梱することにあります。配布物の大きさはHello Worldでも.appで294MBあり、その内訳はElectronの仕組みと始め方の記事で測っています。ここでは、UIの作り方で変わる起動中のメモリを測りました。

ウィンドウ数・WebContentsView数ごとのメモリ

Electron 45.0.0で、同じ小さなHTMLを読み込むウィンドウの数を変え、全画面の読み込みが終わってから6秒後の app.getAppMetrics() のworkingSetSize（KB）を全プロセス分足し、1,024で割ってMBにしました（Intel Core i9-9880H・macOS 26.6.2、2026年10月26日）。

ウィンドウ3枚の1回は画面用のプロセスが2本しか起動していなかったため集計から外しました。ウィンドウ5枚の1回（361MB）は、画面用だけでなくメインやGPUのプロセスも同時に2〜4割小さく出ました。原因は特定していませんが、全プロセスがそろって縮んでいるため、画面の数による差とは分けて扱います。それ以外の回で比べると、ウィンドウを1枚から5枚にして約240MB増え、1枚あたり約60MBでした。土台のプロセス（メイン・GPU・ネットワーク等のユーティリティ）は合わせて約185〜195MBで、画面の数にほぼ比例して増えるのは画面用（レンダラー）のプロセスです。1枚のウィンドウの中に WebContentsView を重ねても、ビュー1枚ごとに画面用のプロセスが1本増えました。WebContentsViewはタブUIを作る部品ですが、今回の条件では、ビューを開きっぱなしにするとウィンドウを増やすのに近いメモリを使いました。実際のアプリでは、画面の中身や読み込むデータの量でも1本あたりの値は変わります。

この値はプロセスごとの値の単純な合計で、共有メモリを重ねて数えるため、アクティビティモニタの表示とは一致しません。

重さを抑えるUI設計：画面数の抑制とIPCのまとめ送り

測定で分かったのは、画面を1つ増やすたびにプロセスが1本増えることです。そこから考えられるUI設計上の対策を挙げます（対策ごとの効果の比較は測っていません）。

• 設定画面やダイアログを別ウィンドウにしない：同じウィンドウ内でReactやVueのルーティングで切り替えれば、画面用プロセスは1本のままです。
• タブは閉じたら破棄する：WebContentsViewは removeChildView() で外すだけでなく、使わなくなったら webContents.close() で閉じます。
• IPCはまとめて送る：1ウィンドウで ipcRenderer.invoke() を1,000回続けて往復させると、6回の測定で0.25〜0.75秒、1回あたりの平均で0.25〜0.75msでした。単発の呼び出しは気にしなくてよい速さですが、スクロールやドラッグの1イベントごとに何十回も呼ぶ設計にすると、1フレーム（約16.7ms）の予算に響きます。表示用のデータは配列でまとめて渡します。

配布サイズはランタイムを同梱する限り大きくは減りません。100MB単位で減らしたいなら、Electronの中での工夫ではなくTauriなど別の方式を選ぶ判断になります。

ElectronのUIの仕組み：メイン・レンダラー・preloadの役割

ElectronのUIは、Chromiumが描くWebページです。アプリは役割の違う3つの層で動きます。

Electron 20以降はレンダラーがsandbox（OSの隔離）で動くのが既定で、contextIsolation も有効、nodeIntegration は無効です。画面のJavaScriptから直接ファイルを読めないのは不具合ではなく、外部のWebページを表示しても端末を乗っ取られないための設計です。UIからOSの機能を使うときは、preloadで関数を1つずつ公開し、IPCでメインプロセスに処理を頼みます。

ElectronでUIを作る手順

Electron Forge 8によるVite＋TypeScript雛形の作成

公式のビルドツールElectron Forgeの雛形から始めると、開発サーバーとパッケージ作成まで揃います。2026年9月29日に出たcreate-electron-app 8.0.1では、TypeScript付きのVite構成を次のように指定します。版を固定しておくと、この手順と同じ結果になります。

npx [email protected] my-app --template vite --typescript
cd my-app
npm start

Forge 7までの --template=vite-typescript という書き方は8.0で廃止されました。古い記事の手順をそのまま打つと失敗します。必要なNode.jsの版や生成されるファイルの中身はElectronの始め方の記事で実測しています。

素のHTMLによる最小UIとファイル選択の実装

雛形を使わずに仕組みを確かめるなら、次の4ファイルで動きます。npm i -D electron のあと、package.json の "main" を "main.js" にし、npx electron . で起動します。npm init -y が作る既定値は "index.js" なので、書き換えないと何も表示されずに止まります。

// main.js（メインプロセス）
const { app, BrowserWindow, ipcMain, dialog } = require('electron');
const path = require('node:path');

ipcMain.handle('open-file', async (event) => {
  if (event.senderFrame !== event.sender.mainFrame) return null; // iframeからの呼び出しは拒否
  const r = await dialog.showOpenDialog({ properties: ['openFile'] });
  return r.canceled ? null : r.filePaths[0];
});

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();
  // macOSはウィンドウを閉じてもアプリが残るので、Dockから開き直したときに作り直す
  app.on('activate', () => {
    if (BrowserWindow.getAllWindows().length === 0) createWindow();
  });
});

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

// preload.js（画面に渡す関数だけを公開する）
const { contextBridge, ipcRenderer } = require('electron');
contextBridge.exposeInMainWorld('api', {
  openFile: () => ipcRenderer.invoke('open-file'),
});

<!-- index.html（UI） -->
<!doctype html>
<html>
<head>
  <meta charset="utf-8">
  <meta http-equiv="Content-Security-Policy" content="default-src 'self'">
  <title>Electron UI</title>
</head>
<body>
  <button id="open">ファイルを選ぶ</button>
  <p id="path"></p>
  <script src="./renderer.js"></script>
</body>
</html>

// renderer.js（画面のJavaScript）
document.getElementById('open').addEventListener('click', async () => {
  const p = await window.api.openFile();
  document.getElementById('path').textContent = p ?? '選択されませんでした';
});

preloadで ipcRenderer そのものを渡さず、openFile という目的の関数だけを渡すのが要点です。ipcRenderer を丸ごと渡すと、画面のスクリプトから任意のチャンネルを呼べてしまいます。Electron 43以降、defaultPath を省いたファイルダイアログは毎回ダウンロードフォルダで開くので、前回のフォルダを覚えさせたい場合はアプリ側で保持して渡します。

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

レンダラーはふつうのWebページなので、ReactもVueもSvelteもブラウザ向けと同じ書き方で動きます。Forgeの雛形ならViteの設定に @vitejs/plugin-react や @vitejs/plugin-vue を足すだけです。Vite＋Reactの構成はVite + Reactの環境構築手順、ReactとVueのどちらを選ぶかはReactとVue 3の違いの比較を参照してください。VueでMaterial Designの部品を揃えたいならVuetifyの使い方が使えます。

フレームワークを選ぶうえでElectron固有の注意は2つです。1つは、コンポーネントの中から fs などのNode.jsモジュールを直接importしないことです。レンダラーでは動かず、preload経由の関数に置き換える必要があります。もう1つは、Next.jsのサーバー側の機能を前提にしないことです。この記事の構成では画面を loadFile() でローカルファイルとして読み込むので、静的に書き出せるフロントエンドを選びます。

メインプロセスで作るメニュー・トレイ・通知

アプリのメニューバー、タスクトレイ（macOSのメニューバーアイコン）、OSの通知は、HTMLではなくメインプロセスのAPIで作ります。次のコードは、main.jsと同じフォルダにトレイ用の画像 icon.png（16×16ピクセル程度）を置いてから追加します。

// main.js に追加
const { Menu, Tray, Notification, nativeImage } = require('electron');
let tray; // 関数の外で参照を持たないと、ガベージコレクションでトレイが消える

app.whenReady().then(() => {
  Menu.setApplicationMenu(Menu.buildFromTemplate([
    { role: 'fileMenu' },
    { role: 'editMenu' },
    { label: '表示', submenu: [{ role: 'reload' }, { role: 'toggleDevTools' }] },
  ]));

  tray = new Tray(nativeImage.createFromPath(path.join(__dirname, 'icon.png')));
  tray.setToolTip('My App');
  tray.setContextMenu(Menu.buildFromTemplate([{ label: '終了', role: 'quit' }]));

  new Notification({ title: '準備完了', body: '同期が終わりました' }).show();
});

role を指定すると、コピー・貼り付けや終了などの標準の動きと、OSごとのショートカットキーがそのまま付きます。macOSの通知はElectron 42からUNNotificationの仕組みに変わり、コード署名していないアプリでは通知が表示されず、Notification に failed イベントが出ます。Macで配布する前の署名と公証の手順はElectron製Macアプリのビルド・コード署名・Apple公証で扱っています。

作ったアプリをWindowsやLinuxへ配り、配布後も自動で更新させる手順はelectron-builderの使い方とelectron-updaterの自動更新で扱っています。

Electron 43〜45でUIのコードに効く変更点

サポートが約半年で切れるため、版を上げるたびに破壊的変更の一覧を確認します。UIを作るコードに関係するものを抜き出しました。

Electron 45のsandbox preloadで使えなくなったもの

Electron 45では、sandboxで動くpreload（20以降の既定）から Buffer、setImmediate、clearImmediate と、require('events')・require('timers')・require('url') が消えました。45.0.0のpreloadで1行ずつ評価した結果は次のとおりです（記録は2026年10月26日）。require('events') は例外になるので、続けて試すときは try で囲みます。

typeof Buffer                 // "undefined"
typeof setImmediate           // "undefined"
require('events')             // Error: module not found: events
typeof require('electron').clipboard  // "undefined"（44で削除済み）
typeof TextEncoder            // "function"
typeof navigator.clipboard    // "object"

preloadでバイト列を扱っていた Buffer は Uint8Array と TextEncoder／TextDecoder、setImmediate は setTimeout か queueMicrotask、EventEmitter は EventTarget に置き換えます。ipcRenderer.on() などのイベントのメソッドはそのまま使えます。sandbox: false にすれば元の環境に戻りますが、UIの都合で隔離を外すのは勧めません。

Electron 44で変わったクリップボードの扱い

Electron 44からは、レンダラーで require('electron').clipboard が使えません。画面からのコピー・貼り付けはWeb標準の navigator.clipboard で書きます。それで足りない処理は、メインプロセスでclipboardモジュールを使い、preloadではその処理を呼ぶ関数だけを公開します。あわせてメインプロセス側のclipboardモジュールもW3CのClipboard APIに合わせて作り直され、clipboard.read() は ClipboardItem の配列を返すPromiseに、clipboard.write() は ClipboardItem の配列を受け取る形に変わりました。44へ上げるときは await を足すだけでなく、読み書きするデータの形も書き換えます。対象のメソッドは破壊的変更の一覧で確認してください。

Electron 45で追加されたUI関連の機能

Electron 45の公式発表によると、sandboxのレンダラーの起動処理が減り、macOSでの起動が速くなり、メニューの構築と表示も速くなりました。macOSでは app.configureWebAuthn() に platformPasskeys: true を渡すと、iCloudキーチェーンなどのパスキー画面を呼び出せます。アプリが用意したAIモデルをChromiumのPrompt APIにつなぐ機能も実験的に入りましたが、モデルは同梱されないので自分で用意します。

Electronを選ぶ条件と選ばない条件：Tauri・Flutter・WebView2との比較

オワコンかどうかより実務で大事なのは、自分のアプリにElectronが合うかです。主な候補を並べます。

Electronを選ぶべき条件は、Webアプリの画面やnpmの資産をそのまま使いたい、Windows・macOS・Linuxで同じ見た目にしたい、チームがJavaScriptとTypeScriptしか書かない、の3つが揃う場合です。描画エンジンを同梱するので、OSのWebViewの版の違いで表示が崩れる問題が起きません。

選ぶべきでない条件は、低スペックのPCで常駐させるユーティリティ、配布サイズに制限がある社内配布、半年ごとの版上げを担当できる人がいない体制です。この場合はTauriが第一候補で、Windowsだけの業務アプリならWinUI 3やWPF、モバイルも同じコードで出すならFlutterや.NET MAUIを比べます。Electronでの開発や、ほかの方式も含めたクロスプラットフォームのアプリ開発を相談したい場合は、Flutter / React Native開発の支援も行っています。

よくある質問

Electronはオワコンですか？

オワコンではありません。2026年も8週ごとにメジャー版が出ており、VS CodeやDiscordが版を上げ続けています。npmでの取得回数はTauriの方が速く伸びており、2026年7〜9月の差は3.0倍でした。

Electronのデメリットは何ですか？

配布サイズとメモリが大きいこと、サポートが約半年で切れるため版上げが続くことの2つです。Electron 45で小さなHTMLを表示して測ると、ウィンドウ1枚で約245MB、1枚増やすごとに約60MB増えました。

Electronは今後どうなりますか？

公式スケジュールでは、Electron 45のサポートは2027年4月27日まで続く予定（暫定）で、その間も8週ごとに新しい版が出る予定です。12月は公開を休むため、次の46は2027年1月の予定です。

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

作れます。レンダラーはふつうのWebページなので、Forge 8のVite雛形にReactやVueのプラグインを足して開発します。ファイル操作などはコンポーネントから直接せず、preloadとIPCを通します。

ElectronとTauriの違いは何ですか？

ElectronはChromiumを同梱し、TauriはOSのWebViewを使います。そのためTauriは配布サイズとメモリが小さく、ElectronはOSによる表示の差がほぼありません。バックエンドの言語もElectronはJavaScript、TauriはRustです。

関連記事

• Electronとは？Web技術でデスクトップアプリを作る仕組みと始め方【v44で実測】
• Tauriとは？読み方・Electronとの違い・将来性を実測で解説【v2.12／3.0 alpha】
• Electron製Macアプリのビルド・コード署名・Apple公証｜Electron 45とnotarytoolで実測した手順
• Vite + Reactの環境構築手順｜Viteとは・Vite 8.3の変更点とTypeScript 7対応
• ReactとVue 3の違いを比較｜どっちを選ぶべきか【React 19.3・Vue 3.5対応】