Electron は 1.0 リリースから 10 年を経て、デスクトップアプリの「枯れたデファクト」として完全に成熟しました。Visual Studio Code、Slack、Discord、Notion、Figma Desktop、GitHub Desktop、1Password 8、Signal Desktop、そして OpenAI の ChatGPT for Windows や Codex Desktop、Anthropic の Claude Desktop まで、コミュニケーション、開発者ツール、生産性、AI アシスタントの主要プロダクトのほとんどが Electron で動いています。
ところがその一方で、Microsoft Teams は 2023 年 10 月に WebView2 ベースの新 Teams へ移行し、WhatsApp Desktop は UWP を経て薄い WebView ラッパーに回帰、Atom の後継 Zed は Rust ネイティブで完全に Electron を捨てました。さらに Spotify や Raycast、macOS 版 ChatGPT のように「Electron だと誤解されがちだが実は違う」アプリも少なくありません。
本記事では、公開リポジトリ、公式エンジニアリングブログ、一次インタビューを元に、2026 年 5 月時点で観測できる Electron 製有名アプリの全体像、よくある誤解の整理、各社が積み上げた最適化パターン、そして OpenAI Codex Desktop のように 2026 年に新規参入してきたケースまでを総点検します。「採用し続けている理由」と「離れていく現実」の両面を、プロダクト単位で検証していきます。
カテゴリ別 — 2026 年に動いている Electron アプリの全体像
最初に、現在も Electron で動いていることが公開情報から確認できる主要アプリをカテゴリ別に並べます。各表の備考列には、公式エンジニアリングブログ、Hacker News のコメント、公開 package.json などから読み取れる特徴を簡潔に書いています。
開発者ツール
| アプリ | 主体 | 主な特徴 |
|---|---|---|
| Visual Studio Code | Microsoft | Stack Overflow Developer Survey 2025 で開発者の 75.9% が使用するデファクト |
| Cursor | Anysphere | VS Code フォーク。2025 年 12 月時点で DAU 100 万超、ARR の YoY 成長率 9,900%（Bloomberg 報道） |
| Windsurf | Cognition AI | 旧 Codeium。VS Code フォーク |
| GitHub Desktop | GitHub | desktop/desktop の package.json で Electron 42.0.1 を確認 |
| Postman | Postman | API 開発のデファクト。CORS 制約回避が公式の採用理由 |
| Insomnia | Kong | 元作者 Gregory Schier 氏は Kong 買収後にスピンアウトし、後継の Yaak を Tauri で再構築 |
| Hyper | Vercel | Vercel 製ターミナル |
| Docker Desktop | Docker | UI 部分が Electron |
コミュニケーション
| アプリ | 主体 | 主な特徴 |
|---|---|---|
| Slack | Salesforce | 2016 年に macOS 版を Electron で再構築。2019 年に「ground up」リライト |
| Discord | Discord | Electron + C/C++ ネイティブモジュール + WebRTC。MAU 2 億超 |
| Signal Desktop | Signal Foundation | UI は Electron / React / TypeScript、暗号は libsignal-client（Rust） |
| WhatsApp Desktop | Meta | Electron → UWP（2022 年）→ WebView2 ラッパー（2025 年 12 月）と二度乗り換え |
| Mattermost Desktop | Mattermost | サーバごとに isolated process を持つ企業向け設計 |
生産性、ノート
| アプリ | 主体 | 主な特徴 |
|---|---|---|
| Notion | Notion Labs | 2025 年 12 月時点で評価額 110 億 USD、MAU 1 億超 |
| Obsidian | Obsidian | Desktop 1.12.7（2026 年 3 月）で Electron 39.8.3 |
| Joplin | Joplin | Markdown ベースの OSS、Electron 40.9.2 |
| Linear | Linear | スピード重視のプロジェクト管理 |
| Asana / Loom / Todoist / Trello / Miro | 各社 | 生産性カテゴリの Electron 常連 |
デザイン、クリエイティブ
| アプリ | 主体 | 主な特徴 |
|---|---|---|
| Figma Desktop | Figma | Electron + WebAssembly の編集エンジン。BrowserView を Electron 本体に寄贈 |
| Canva | Canva | Electron 公式の showcase に掲載 |
| balenaEtcher | balena | OS イメージ書き込み。drivelist や direct-io 系のネイティブモジュールが本質 |
| Streamlabs OBS | Streamlabs | 配信向け OBS 派生プロダクト |
AI アシスタント
| アプリ | 主体 | 主な特徴 |
|---|---|---|
| ChatGPT for Windows | OpenAI | 約 260 MiB の Electron アプリ。リリース時に Copilot（WebView2、600 KiB 未満）と比較され論争に |
| Codex Desktop | OpenAI | macOS / Windows のみ。VS Code 拡張とコード共有のため Electron を選んだと Alexander Embiricos 氏（OpenAI）が X で公言 |
| Claude Desktop | Anthropic | macOS / Windows の両方が Electron。Felix Rieseberg 氏がエンジニアリングをリード |
| Cherry Studio / Chatbox / Opencode Desktop | OSS | electron-vite + electron-builder の典型構成 |
OSS、コミュニティアプリ
WordPress Studio（Automattic/studio）、TriliumNext、WebCord、Element Desktop、Standard Notes、Bitwarden Desktop など、OSS 領域でも Electron は引き続き層が厚いです。
誤解されがちな「実は Electron じゃない」アプリ
Electron は Web 技術ベースの統一感のある UI のせいで、見た目から判別するのが難しく、本当は別技術で実装されているアプリまで「Electron 製」と思われがちです。一次情報で確認できる代表例を挙げておきます。
Spotify Desktop は CEF
Spotify Engineering のBuilding Spotify’s New Web Playerには「Before tools like Electron became a reality for building hybrid applications, Spotify started using Chromium Embedded Framework (CEF) in 2011」と明記されています。Electron が登場する前から、ネイティブ C++ シェル + Chromium Embedded Framework を独自に運用してきました。
ChatGPT for Mac はネイティブ Swift、Windows だけが Electron
OpenAI のエンジニア Javier Soto 氏が X（旧 Twitter）で「ChatGPT for Mac is a fully native macOS app. Not Electron. Not even Catalyst」と明言しています。一方で Windows 版は Windows Latest によるバイナリ解析（chrome_100_percent.pak などの Electron 特有ファイルを発見）で Electron 製であることが確認されています。同じ製品でも OS ごとに技術選定が割れている点は、デスクトップ AI の世界でも珍しい事例です。
Raycast はネイティブ macOS アプリ
Raycast は AppKit と Swift で書かれた完全ネイティブの macOS アプリで、拡張機能のみ Node.js サブプロセスで実行し、独自の React Reconciler を介して AppKit コンポーネントへレンダリングしています。Raycast 公式ブログの How Raycast API Extensions Work でも「Raycast is a fully native macOS app and we treat extensions as first-class citizens」と明言されています。
ゲームランチャー系、ストリーミング系は Electron ではない
Amazon Music、Twitch、Battle.net、Epic Games Launcher、Steam、GOG Galaxy、OBS Studio はいずれも CEF または Qt WebEngine ベースで、Electron ではありません。「ゲームランチャー系、配信系は Electron ではない」というのが整理の定石です。
Sketch は別系統
Sketch はずっとネイティブ macOS（Swift / Objective-C）路線で、Electron を採用したことはありません。
なぜ採用し続けるのか — 著名アプリの最適化パターン
「Electron は重い」という批判は何年も続いていますが、それでも採用し続ける各社は、性能上の課題を構造的に潰すノウハウを積み上げています。代表的な 3 アプリの実装上の意思決定を見ていきます。
Visual Studio Code — Piece Tree と V8 スナップショット
VS Code が「軽い Electron アプリ」として知られているのは、テキストバッファのデータ構造を Piece Tree に刷新したことが大きな転換点でした。初期実装は各行をオブジェクト化して配列で保持する典型的な「行配列」モデルで、約 1,370 万行、35 MiB のファイルで V8 メタデータが膨らみ、バッファだけで約 600 MiB を消費して容易に OOM クラッシュしていました。
開発チームは一度 C++ ネイティブモジュールへの移行を検証しましたが、JavaScript / C++ 間の境界越えと文字列コピーのコストが上回り、ランタイムは JavaScript / TypeScript に留めたうえで、赤黒木でバランス調整した Piece Tree を導入する道を選びました。元ファイルを「読み取り専用バッファ」としてメモリに置き、編集差分を「追記専用バッファ」に書き留め、ツリーノードで軽量に位置と長さを管理することで、メモリ消費量をほぼファイルの実サイズと同等まで圧縮しています。
加えて、require() の同期 I/O ボトルネックは V8 スナップショット（V8 エンジン初期状態をシリアライズしてバイナリ化）で回避し、初期入力レスポンスを優先するためにシンタックスハイライトを非同期に遅延させる「段階的初期化」も行っています。
Slack — legacy-interop と単一プロセス統合
Slack の 2019 年デスクトップ再設計は、Electron アプリの大規模リファクタリング事例として今でも参照される金字塔です。初期実装は jQuery と直接的な DOM 操作、起動時のアセット一括ロード（Eager Data Loading）に支えられており、特に複数ワークスペースに参加するユーザーでは、ワークスペース 1 つにつき独立した Web ビューと Electron プロセスを生成していたため、PC 上で大量の Chromium インスタンスが立ち上がる構造でした。
打開策として採用されたのが Slack Engineering の “When a rewrite isn’t: rebuilding Slack on the desktop” で語られる「legacy-interop」アプローチです。古い jQuery ベースのメインアプリを動かしながら、React で書き直したパーツを段階的に融合させていく方式で、「古いコードから新しいコードはエクスポート経由、新しいコードから古いコードはアダプタ経由」という厳格なインターフェースルールで新旧モジュールが混ざるのを防ぎました。
この再設計の最大の成果は、すべてのワークスペースを「単一の Electron プロセス」へ統合した点です。Redux と redux-thunk でグローバル状態を構築し、各ワークスペースを状態オブジェクトの個別「スライス」としてカプセル化しました。データ取得は Lazy Loading に切り替わり、結果として、Slack 公式が起動速度 33% 向上、メモリ消費最大 50% 削減、通話接続が 10 倍高速化、ワークスペース切り替えラグの解消を達成したと発表しています。
Discord — CSS セレクタ最適化と N-API リンク
Discord は数億人のユーザーが PC ゲームを実行しながらバックグラウンドで通話するという、Electron にとって最も過酷なユースケースを抱えています。2025 年末から 2026 年にかけて、Windows 11 上で一時的にメモリ消費が最大 4 GiB に達する問題に対する大規模な近代化を実施しました。
調査の結果、原因は Electron 本体だけでなく、Discord が利用していたサードパーティ製 systeminformation ライブラリにあることが判明しました。このライブラリは適切な低レイヤ Windows API を直接叩く代わりに、バックグラウンドで PowerShell を頻繁に生成し、Get-WmiObject Win32_logicaldisk のような重い WMI クエリを定期実行することで、CPU スパイクとメモリ蓄積を引き起こしていました。Discord はシステム情報取得経路を直接 API ベースに書き換え、9 つ以上のメモリリークシナリオを解消したうえで、30 分以上アイドルかつメモリ使用量が 4 GiB を超えた場合に一度だけ安全にセルフ再起動するセーフガードのテストを開始しています。
UI のカクつきの原因が、バックエンドのネットワークレイテンシではなく、レンダラ内の非効率な CSS セレクタによる Reflow にあったことを突き止め、CSS セレクタを最適化した形式にリファクタリングして、サーバ、チャンネル切り替え時のレンダリングレスポンスを大きく改善した話も象徴的です。さらに音声通話の根幹部はノイズ抑制、エコーキャンセル、H.264 コーデック処理を C++ ネイティブモジュールに切り出し、N-API 経由で JavaScript スレッドから独立して実行しています。Linux プラットフォームでは、Steam Deck などへの搭載に伴い、画面共有時に従来の Electron 描画パスを迂回して Gamescope や Vulkan を直接叩くことでゲームの性能低下を防いでいます。
共通パターン — 重い処理は Rust / WASM / C++ へ寄せる
これら 3 社の事例から浮かび上がるのは、「Electron 単独で全部を支えるのではなく、性能、セキュリティが効くコア部分は別言語で書く」というハイブリッド戦略です。
- VS Code: 描画と編集を Piece Tree（TypeScript）で最適化、起動は V8 スナップショット
- Slack: Electron プロセスを単一化し、状態は Redux のスライスで統合
- Discord: 音声 / 画面共有を C++ + N-API、Linux の描画は Vulkan で迂回
- Signal Desktop: 暗号と通話を
libsignal-client（Rust）と RingRTC に分離 - 1Password 8: バックエンドのほぼすべてを Rust 化し、
electron-secure-defaultsとelectron-hardenerを自社公開 - Notion: ローカルキャッシュに WebAssembly 版 SQLite を採用
- Figma: 編集エンジン本体を C++ → Emscripten 経由で WebAssembly 化
脱 Electron の代表例 — Teams、WhatsApp、Zed
Electron 離脱の事例として頻繁に語られるのが、Microsoft Teams、WhatsApp Desktop、Zed の 3 つです。Electron の最大級のスポンサーである Microsoft が Teams で離脱という判断を下した点は象徴的で、Meta の WhatsApp と Atom 後継の Zed も、それぞれ独自の動機で Electron を離れています。
Microsoft Teams は WebView2 へ全面移行
旧 Teams は Electron 製で、メモリ消費の悪評が長年続いていました。2021 年に元 CVP の Rish Tandon 氏が X で「We are moving away from Electron to Edge Webview2. Teams will continue to remain a hybrid app but now it will be powered by Microsoft Edge. Also Angular is gone. We are now 100% on reactjs」と公式表明し、2023 年 3 月の Preview を経て、2023 年 10 月 5 日に新 Teams が Windows / Mac で GA に到達しました。
公式に発表されたインパクトは大きく、インストーラサイズが 134 MiB から 12 MiB 級に縮小、メモリ使用量が概ね半減、起動が約 2 倍高速化されました。Linux 版は廃止されて PWA 化、2024 年 3 月 31 日からは旧 Teams の自動移行が始まり、新規インストール後 14 日で旧版がアンインストールされる運用に移行しています。
WhatsApp Desktop は Electron → UWP → WebView2 ラッパー
WhatsApp Desktop は 2022 年に Electron から UWP / WinUI へ移行して評価を得ましたが、わずか 3 年で再び方針転換しました。2025 年後半、Microsoft Store 版が WebView2 ベースの Chromium 薄いラッパーへ再変更され、Windows Latest の計測では UWP 版と比べてメモリ消費が大きく悪化していると報じられました。Daring Fireball は新版を「a shitty web app wrapper」と切り捨て、続けて「bloated, slow, and unsurprisingly has poor support for native Windows features」と評しており、Electron 離脱が必ずしも「ネイティブ化」を意味しないという象徴的な事例です。
Zed は Atom の遺産そのものから完全離脱
Electron の母体である Atom Shell 由来の Atom は、2022 年 12 月 15 日に GitHub が正式に EOL 化しました。後継として一部の Atom コアコントリビュータが立ち上げた Zed は、Rust + 自前 GPU UI フレームワーク GPUI で実装され、Electron を完全に捨てています。エディタ級の遅延要件を Electron の Chromium モデルでは満たせないというのが Zed チームの説明で、「Electron アプリだった有名プロダクトが Electron を完全に離れた」最も顕著な事例として頻繁に参照されます。
AI 時代はむしろ Electron 回帰
「脱 Electron」の流れがある一方で、2024 年から 2026 年にかけて大量に登場した AI デスクトップアプリは、むしろ Electron に集中しています。
ChatGPT for Windows と Claude Desktop の意思決定
ChatGPT for Windows は約 260 MiB の Electron アプリとしてリリースされ、Microsoft の Copilot（WebView2、600 KiB 未満）と比較されて技術コミュニティで論争となりました。それでも OpenAI が Electron を選んだ事実は重く、「インストールサイズより配布速度と UI 統一性が優先された」と解釈できます。
Claude Desktop はさらに踏み込んでいて、macOS と Windows の両方が Electron です。Claude Code チームの Boris Cherny 氏が Drew Breunig 氏の記事「Why is Claude an Electron App?」（2026 年 2 月 21 日）の Hacker News スレッドで「Some of the engineers working on the app worked on Electron back in the day, so preferred building non-natively. It’s also a nice way to share code so we’re guaranteed that features across web and desktop have the same look and feel. Finally, Claude is great at it. That said, engineering is all about tradeoffs and this may change in the future!」と直接コメントしています。
さらに Electron のコアメンテナで元 Slack / Notion のエンジニアだった Felix Rieseberg 氏が、現在 Anthropic でデスクトップアプリのエンジニアリングに携わっています。同氏は自身のブログ記事 Things people get wrong about Electron で、Chromium をアプリ側で制御できるレンダリングスタックとして同梱できる点、そして OS 同梱の WebView が同梱 Chromium を上回ると示す公開データが存在しない点を、Electron を選び続ける根拠として繰り返し語っています。
AI 機能（MCP サーバ統合、Claude Code / Cowork、Computer Use、Artifacts、Skills 等）が毎週のように追加される現状では、「Web と完全同期できる」「Chromium レンダリングを自分で制御できる」「Node.js エコシステム（MCP ツールホスト）を活用できる」という Electron のメリットが圧倒的で、ローンチ後の新機能反復速度が AI プロダクトの寿命を決める世界では合理的な選択肢です。
Codex Desktop は Electron、VS Code 拡張とコード共有
OpenAI の Codex は、ターミナル UI 版の Codex CLI（Rust + Ratatui ベースの TUI）とは別に、GUI 版の Codex Desktop を提供しています。CLI から codex app を実行すると、macOS では Codex.dmg を persistent.oaistatic.com から取得して /Applications/Codex.app を起動し、Windows では Microsoft Store の Codex を案内する設計で（codex-rs/cli/src/desktop_app/mac.rs と windows.rs で確認できます）、Linux 向けの GUI 版は提供されていません。
実装スタックは Electron です。OpenAI で Codex プロダクトをリードする Alexander Embiricos 氏が X で 2026 年 2 月 2 日に「we built it in Electron, sharing code the with VSCode extension, specifically so we can get to Windows quickly」と明言しており、VS Code 拡張とコードを共有して Windows 版を素早く出すために Electron を採用したことが公式コメントとして残っています。macOS の Apple Silicon 用 DMG が約 330 MiB と、ChatGPT for Windows（約 260 MiB）や Claude Desktop と同レンジに収まっている点とも整合します。「IDE / エディタ拡張とデスクトップアプリで Web 資産を再利用したい」という動機が、Anthropic の Claude Desktop と完全に重なっているのが象徴的です。
VS Code フォークが AI IDE の標準に
Cursor、Windsurf、Kiro（AWS 製）、Antigravity、Void（OSS 版）といった主要な AI IDE は、ほぼすべて VS Code フォークで Electron を継承しています。Cursor は Bloomberg 報道によれば 2025 年 12 月時点で DAU 100 万超、ARR の YoY 成長率 +9,900% と桁違いの伸びを示しており、VS Code 経済圏が「AI エディタを通じて Electron を延命している」という構図が出来上がっています。
ただし副作用もあり、Cursor 等で「悪意ある拡張機能 / MCP サーバが JavaScript を Electron コンテキストへ注入できる」というクラスの脆弱性が複数のセキュリティ研究者から報告されており、AI エージェントが直接 Node コンテキストでコードを評価する設計と Electron の権限モデルの相性は、サプライチェーンセキュリティの新しいリスクとして認識され始めています。
AFFiNE が Tauri から Electron へ回帰
AI 時代以前の事例として、AFFiNE はかつてオルタナフレームワークでデスクトップ配布を試みたあと、後に Electron へ切り替えています。コミュニティフォーラムに「Why Shift from Tauri to Electron」スレッドが残っており、プラグインエコシステム、デバッグ容易性、Chromium 一貫性が判断理由として挙げられています。Chromium をアプリ側で制御できるレンダリングスタックとして同梱できる点が、Electron の本質的価値であることをあらためて裏付ける事例です。
アーキテクチャ最適化の共通プラクティス
著名アプリの実装事例を横並びにすると、Electron で性能を維持するための共通プラクティスがはっきり浮かび上がります。
同期 require() の根絶とモダンバンドラー
Node.js の伝統的なモジュール読み込みは同期動作で、メインプロセスやレンダラプロセスの起動中に実行されると UI 描画スレッドを完全にロックします。Atom の起動速度を Google エンジニアがプロファイリングした際、起動時間の大部分が描画前の数千回の同期 require() で消費されていたことが明らかになっています。
現在の最適化では Webpack / esbuild / Vite などの高速バンドラーの導入が必須となり、モジュール群をビルド時に単一バンドルへ結合することで、実行時の同期 I/O 回数を激減させます。
ルートベースのコード分割と遅延読み込み
React の lazy() と Suspense を使ったダイナミックインポートで、特定のページ、モーダル（絵文字ピッカー、詳細設定など）を開いた瞬間にコードを読み込む構成が標準です。アイドル時のメモリ（レジデントセットサイズ）を 150 MiB 程度に抑えることが目標値になります。
メインプロセスのブロッキング防止
Electron のメインプロセスは OS イベントの中継と全ウィンドウ管理を行う「管制塔」のため、UI スレッド上で重い計算、同期ファイル I/O（fs.readFileSync 等）、同期 IPC を実行することは避けるべきです。CPU 負荷の高い処理は Worker Threads で別スレッドにオフロードするか、レンダラ側で非同期に処理する設計が標準で、古い @electron/remote は 2026 年現在は完全に非推奨です。
セキュアデフォルト
contextIsolation: true、nodeIntegration: false、CSP ヘッダ強化、preload スクリプト隔離は必須です。1Password が公開している electron-secure-defaults と electron-hardener は、デフォルトの不十分さを補強するためのリファレンス実装として参照価値が高いです。
本番ユーザー上での継続プロファイリング
Notion は Palette との取り組みで本番 JS Profiler を導入し、初期ページレンダリングで発生していた 10% の遅延の原因を特定しました。Microsoft、Dropbox、Slack も同種の手法を導入しており、「リリースしてからが本番」というスタンスで継続改善する運用が、生き残っている Electron アプリの共通項です。
選定の指針 — どんな場合に Electron を選ぶか
Electron を採用するかしないか、するならどこまで Electron 単独で支えるかをシナリオ別に整理します。
Electron を選ぶべき条件
- Web 版とコードベース、デザインを共有して出荷速度を最大化したい
- React / TypeScript の人材プールを即戦力化したい
- AI 機能の高速反復（MCP、Computer Use、Cowork 等）が想定される
- 全 OS で完全に同一の描画と挙動を保証したい
- Slack / Notion / Anthropic と同じ土俵で戦う成熟度が必要
Electron + Rust ハイブリッドを選ぶべき条件
- 既に Electron で出荷しており、メモリ / 起動が体験の KPI に直結し始めた段階
- 暗号、通話、DB など特定領域だけネイティブ性能が必要
- 1Password 8 / Signal Desktop と同じ戦略を踏襲したい
Electron を選ばないほうがよい条件
- 単一 OS（特に macOS）に特化した極限の UX を志向する
- Raycast / Sketch / Zed のような「ネイティブでなければ成立しない」プロダクト
- エディタ級の遅延要件（タイピング遅延 5 ms 未満等）が前提
留保すべき点
本記事の整理は 2026 年 5 月時点で観測可能な公開一次情報に基づきますが、いくつか留保事項があります。
- 数値はソース時点のもの: Discord MAU 2 億超（2024 年 4 月の CEO 発言）、Notion 評価額 110 億 USD（2025 年 12 月、Forbes）、Cursor DAU 100 万超（2025 年 12 月、Bloomberg）等は時点情報で、最新値は変動し得る
- **Microsoft Teams 新版の「メモリ 50% 減」**は Microsoft 内部測定値で、実機での体感は構成、テナント数に依存
- Perplexity Desktop の公式アプリの実装スタックは、公開情報からは確認できなかった
- 「Electron かどうかで AI 企業の質を判定する」論調（Drew Breunig 氏の 2026 年 2 月の記事「Why is Claude an Electron App?」など）は、Anthropic 自身が公式に「現時点の最適解」として Electron を選んでいる事実を踏まえると、「現時点の合理性」と「将来のスイッチコスト」を分離して評価すべき
まとめ
2026 年の Electron は、登場から 10 年以上が経った今も Visual Studio Code、Slack、Discord、Notion、1Password 8、Signal Desktop、ChatGPT for Windows、Codex Desktop、Claude Desktop など、数億人規模のプラットフォームの確固たる土台として活用され続けています。Web テクノロジーの圧倒的なエコシステム、Chromium レンダリングの予測可能性、Node.js を介した強力な OS 制御、そして AI 機能を週次で反復できる柔軟性。これらが採用理由の核心です。
一方で、Microsoft Teams、WhatsApp Desktop、Atom → Zed のように「離れる」流れも着実に存在します。ただし「離れる」が必ず「ネイティブ化」を意味するわけではなく、WhatsApp のように「より薄い Web ラッパー」へ向かう場合もあれば、AFFiNE のように一度離れた後 Electron に戻る逆流もある、というのが実情です。
実務的な指針としては、「Web チーム主体で速く回したいなら Electron が依然有力」、「特定領域だけネイティブ性能が必要なら 1Password / Signal 流の Electron + Rust ハイブリッド」、「単一 OS の極限 UX が要件なら Raycast / Sketch / Zed のように完全ネイティブ」という三層で考えるのが筋が通っています。
「Electron か、ネイティブか」は単純な二項対立ではなく、Slack の legacy-interop、VS Code の Piece Tree、Discord の N-API リンク、Notion の WASM SQLite といった先人たちの工夫を踏まえて、要件の濃淡で選び分けるべき設計判断です。Electron の採用事例だけを並べても、2026 年の地図はそれだけ複雑で、それだけ実用的な選択肢が揃った時代だと言えます。
以上、Electron 製有名アプリの 2026 年総点検を整理した、現場からお送りしました。