RAM 価格は高騰しているが、人気のある Windows 11 アプリは Electron や Web コンポーネントのせいでより多くの RAM を使用している

2025-12-07 517 words 3 minutes

Contents

<本文>

Windows 11 の最も人気のあるアプリの一部は RAM を大量に使用するため、PC のパフォーマンスに影響を与える可能性があり、RAM の価格が高騰しているという事実が問題をさらに悪化させています。この問題は、開発者が Windows 上のネイティブアプリではなく Web アプリを好む傾向にあることが原因です。

ごく最近、Windows Insight は、Discord、Teams、新しい WhatsApp などの RAM を大量に消費するアプリが、バックグラウンドであってもどのように発生するかを報告しました。ここでの共通点は、これらのアプリは通信中心のアプリであり、ご想像のとおり、使用していないときでも有効にしておく必要があるということです。

ただし、私たちのテストでは、ネイティブバージョンのアプリ (古い WhatsApp など) が大量の RAM を消費していないことが証明されました。これらは、ユーザーがどのドメインに属しているかに関係なく、Windows で最もよく使用されるアプリの一部です。

では、なぜこれらのアプリにはネイティブバージョンがないのでしょうか?これらの企業にとって、最も人気のあるデスクトップオペレーティングシステムのネイティブバージョンと最適化されたバージョンを構築することはそれほど難しいのでしょうか?

Windows 11 における最悪の RAM 犯罪者

PC やラップトップのハードウェアアップグレードは非常に高価になるため、RAM の使用量について話すのにこれほど適切な時期はありません。そしてMicronが消費者向けRAM事業から撤退することで状況はさらに悪化している。

Windows 11 は発売時に RAM 要件が高いとしてすでに批判されていましたが、2025 年には、Windows の主要な通信アプリが無料リソースのように RAM を大量に消費するため、事態はさらに悪化しています。

Discord は常に約 1GB を使用しており、RAM は喜んで 4GB に急増します

ゲーマーやオンラインコミュニティの間で有名な Discord は、同社がすでに RAM の問題を認めているため、最も攻撃されやすいです。 Windows クライアントは Electron 上に構築されています。つまり、Chromium ブラウザインスタンスとデスクトップアプリとして Node.js を実行していることになります。各サーバー、チャネル、および開くすべての追加機能により、内部ブラウザにさらに多くのタブが追加されます。

Discordは、通常の使用量はRAM 1 GB未満であるが、実際の状況では4 GBに達する可能性があるとユーザーに伝え、同社はその時点で、今や悪名高い「メモリが4 GBを超えた場合の自動再起動」実験のテストを開始した。

アプリが少なくとも 1 時間開いていて、30 分間アイドル状態で、通話中でない場合、Discord は 24 時間に 1 回、メモリを取り戻すために自動的に自動的に再起動します。

同社は再稼働は誠意あるものだと説明している。ただし、これは根本的な問題に対する応急処置であると考えています。いずれにせよ、Discord の開発者は本物のメモリリークの修正に忙しくしており、高パーセンタイルのメモリ使用量が約 5% 削減されたと主張しています。

そうは言っても、Electron はあらゆるアプリの完全なブラウザスタックであるため、PC はチャット UI をレンダリングするためだけに、レンダリングエンジン、JavaScript ランタイム、セキュリティサンドボックスの料金を支払うことになります。

ここでの良いニュースは、Discord が問題を解決したいと考えているということですが、悪いニュースは、この業界に 10 年間いるにもかかわらず、同社が必ずしも利益を上げているわけではないということです。したがって、同社がネイティブアプリに投資することはあまり期待できません。同社にはネイティブ macOS アプリケーションもありません。

WhatsApp は高速なネイティブアプリから低速な Web ラッパーに変わりました

WhatsApp for Windows は、以前は良かったので、別の種類の悲劇です。古い UWP および WinUI ベースのクライアントは軽量で軽快で、Windows 11 上で快適に使用できました。数百のチャットやアクティブなグループが存在する日常的な頻繁な使用でも、通常はアイドル状態で 100 MB 未満にとどまり、長い会話を高速でスクロールした場合でも約 250 MB にとどまりました。

その後、Meta は、Chromium ベースのコンテナに web.whatsapp.com をロードするだけの WebView2 ラッパーとして構築された新しいバージョンを出荷しました。私たちのテストでは、新しいアプリはログインする前からすでに約 300 MB の RAM を搭載しています。チャットが同期してスクロールを開始すると、簡単に 1.2 GB にまで跳ね上がり、CPU 使用率は以前よりもはるかに高くなります。

パフォーマンスの問題は RAM に限定されません。 UI ははるかに低いフレームレートで実行されているように感じられ、チャットの切り替えには目に見える遅延があり、まともなハードウェアでも常に重い感覚が残ります。ウィンドウを閉じても、実際にはアプリは終了しません。これはトレイに最小化され、RAM のチャンクがバックグラウンドで予約された状態に保たれるため、Service Worker 経由で通知を受信できますが、これはネイティブアプリには必要ありませんでした。

これらはすべて「開発の簡素化」と Web コードベースの再利用という名目で行われましたが、ユーザーにとっては直接的なダウングレードです。 macOS では、Meta は引き続きネイティブ WhatsApp アプリを提供します。はるかに多くのユーザーがいるプラットフォームである Windows では、現時点でできるのはブラウザウィンドウだけです。これは Meta 側の単なる怠惰であり、会社としてもそれをする余裕がないわけではありません。

チーム;マイクロソフトも気にしない

次に、Electron から WebView2 に移行した Microsoft Teams があります。これは机上の進歩のように聞こえるかもしれません。しかし、実際には、どう見ても Web アプリです。チームはアイドル時に通常約 1GB RAM を使用します。

Microsoftはアプリを書き直すのではなく再構築することで問題を認めた。 2026 年初めから、Teams には、メインの ms-teams.exe プロセスとは別に呼び出し機能を処理する ms-teams_modulehost.exe と呼ばれる新しいプロセスが導入されます。

これは、通常の容疑者がバックグラウンドで存在し、すべてが依然として WebView2 上で実行されているという事実に変わりはありません。

特に Microsoft の企業顧客が文字通り毎日のコミュニケーションに Teams に依存している状況については、私たちには何と言ってよいのかわかりません。

現時点では、他の開発者がネイティブ Windows アプリを作成するかどうか、あるいは Meta のように既存のネイティブアプリを Web アプリに移行するかどうかを Microsoft が気にすることは期待していません。

真実は、最近の Web ブラウザーは膨大な量の RAM を使用しており、その上に構築されたアプリは RAM を消費するだけです。通信アプリは文字通り常にオンにする必要があるため、最も最悪です。

最近の Windows アプリはなぜこれほど多くの RAM を使用するのでしょうか

現在、Microsoft Store にある新しい Windows アプリのほとんどは、実際には Windows アプリではなく、ブラウザーエンジンです。 DiscordではElectronを使用しています。 WhatsApp と Teams は WebView2 を使用します。小規模なアプリの多くは PWA を使用します。ただし、これらはすべて、アプリ内に完全な Chromium ランタイムを埋め込むという特徴を共有しています。

すべての Electron アプリには、独自の JavaScript エンジン、GPU レンダラー、ネットワークスタック、オーディオパイプライン、およびサンドボックス化されたサブプロセスがあります。最新のブラウザーのセキュリティ標準により、小さな UI 要素でも別のプロセスが生成される可能性があります。各チャット、サーバー、チャネル、通話ビュー、または設定パネルは、実際には個別のサンドボックス化された世界です。したがって、機能が並行して実行されると、メモリ使用量は水平方向に増加します。

Teams と WhatsApp で使用されるフレームワークである WebView2 は、独自の Chromium コピーを開くことを回避しますが、設計は似ています。 Windows 上の新しい WhatsApp は単純なチャットのリストだと思うかもしれません。実際には、これは小型のブラウザタブであり、Chrome のすべての層が内部で実行されています。

PWA は、Windows 上の Reddit アプリと同様に、Chromium のマルチプロセスアーキテクチャとバックグラウンドサービスワーカーに依存しているため、同様に動作します。

技術的には、WebView2 は Electron よりも優れています

すべての Electron アプリはフルブラウザのように開くため、サイズと RAM の使用量が増加しますが、Windows、macOS、Linux にわたるクロスプラットフォームの動作は一貫しています。 WebView2 アプリは、Windows 上の既存の Microsoft Edge (Chromium) インストールを使用して、ネイティブアプリ内で Web コンテンツをレンダリングします。したがって、独自のブラウザを開かないため、オーバーヘッドとフットプリントが削減されます。もちろん、Windows に関連付けられており、Edge ランタイムが必要なため、移植性には多少の制限があります。

いずれにせよ、これらのアーキテクチャが偶然非効率になったわけではありません。開発者はこれを認識しており、エクスプロイトやセキュリティ問題を防ぐために存在します。

最新のブラウザは、悪意のあるページがユーザーが表示しているものと対話するのを防ぐためにプロセス分離を実装しています。メモリプールをサンドボックス間で分割します。これらは、ロジックとストレージから離れた場所でレンダリングを続けます。この余分なリソースの使用は、セキュリティのために支払わなければならない代償です。したがって、デスクトップアプリの基盤としてブラウザエンジンを選択した場合、過剰な RAM の使用は避けられません。

これらすべてに加えて、最新の JavaScript フレームワークが RAM の相当なシェアを占めます。大規模なバンドル、重い差分アルゴリズム、仮想 DOM レイヤー、クライアント側のステートマシンはすべて、すでに高いブラウザーの RAM 使用量の上に積み重なっています。基本的に、適切に最適化された Web ラッパーアプリであっても、ベースラインのメモリ使用量は高くなります。

メモリリークはどこにでもあります

メモリリークは、JavaScript 参照が適切に解放されない場合、またはイベントリスナーが時間の経過とともに蓄積される場合に発生します。フレームワークがアイドル状態のオブジェクトを内部キャッシュに保持しておくことがよくあります。また、ブラウザプロセスが長時間実行セッション内のメモリの解放に失敗した場合にも発生します。

メモリリークが始まると、Discord で発生したような数ギガバイトのスパイクに成長します。これは Electron、Chromium Embedded Framework (CEF)、および WebView2 アプリに共通であり、複雑な JS スタックのデバッグツールはネイティブデバッガーほど成熟していません。

不快な真実は、企業が RAM の使用状況を監視していることを私たちが知っていることであり、彼らができることはメモリの問題の小さな部分を修正する可能性のあるパッチをプッシュすることだけです。しかし、スタック全体が抽象化の背後に隠れすぎています。

Chromium が低レベルで何をしているのかを見ることはできません。レンダラーにメモリをより積極的に解放させることはできません。マルチプロセスモデルを書き換えることはできません。フレームワークのメモリ使用量をどの程度最適化できるかには、避けられない制限があります。

企業がネイティブアプリではなく Web アプリを出荷し続ける理由

これらすべての問題があるため、そもそもなぜ企業が Web アプリを開発するのか疑問に思うかもしれません。彼らはユーザーがスムーズな UI を利用できることを重視していませんか?

単純な答えはコストです。単一の JavaScript コードベースは、技術的にはほとんど変更を加えずに Windows、macOS、Linux 上で実行できます。 JavaScript 開発者を雇用するのは、C++ 開発者よりもはるかに簡単です。

新入社員のオンボーディングが迅速化され、開発サイクルが短縮されます。また、チームはプラットフォーム間で機能を同時に出荷できるようになります。ほとんどの企業はアプリをより早く出荷するというプレッシャーにさらされており、現時点ではネイティブアプリの開発は現実的な解決策ではありません。

企業はブランドの一貫性についても議論しますが、正直言って無意味です。この考えは、企業が自社の UI をどのデバイスでも同一に見えるようにしたいということです。 Web ラッパーはそれを行うことができます。しかし、OS プラットフォームが異なれば、外観も異なります。Windows の場合はそうではありません。これについてはまた別の機会にお話しします。より良い例として、Apple の液体ガラスのデザインを考えてみましょう。 OS 全体はこのデザインになっていますが、ブランドのアプリの見た目がまったく異なると、エクスペリエンスが損なわれてしまいます。

最も情けないのは、企業が Windows ネイティブアプリを優先事項として見なくなったことです。 UWP WhatsApp がほぼ正常に機能していたにもかかわらず、Meta が UWP WhatsApp を廃止するのをすでに見てきました。 Messenger は Microsoft Store から完全に姿を消しました。 Facebook と Instagram は Web ラッパーになりました。

Microsoft でさえ模範を示すことはありません。Teams はまだ WebView2 アプリであり、全額現金取引で 262 億で買収した LinkedIn は単なる Web ラッパーだからです。

非常に面白いのは、Windows 11 の通知パネルの次の予定表ビューでは、ネイティブの XAML/WinUI ではなく WebView2 が使用されていることです。これは、Microsoft が Web ラッパーとして作成した OS の文字通りの一部です。操作するときにさらに多くの RAM を使用します。他のメタや他の会社を責めることに意味はあるのでしょうか？

Apple は、より最適化されたネイティブアプリカタログを活用しています

Apple ユーザーは、低品質のアプリに対してはるかに寛容ではありません。彼らは高速でスムーズなネイティブエクスペリエンスを求めています。このプレッシャーにより、開発者はたとえ高価であっても、ネイティブ macOS アプリに投資せざるを得なくなります。 macOS でネイティブアプリを作成するのが難しいことは言うまでもありません。

驚くべきことに、Windows ネイティブアプリの開発は macOS アプリよりも簡単です。それは、Microsoft が .NET、WPF、UWP/WinUI などの成熟したフレームワークを備えた統合エコシステムを提供しているためです。これらはすべて Visual Studio と緊密に統合されており、広範な下位互換性もあります。

macOS の開発では、Xcode を介して Cocoa および Swift/Objective-C API を操作する必要があります。Xcode には、より厳格なサンドボックス、署名、および App Store 配布ルールがあります。 Windows 開発者は、ゲートキーピングの制約がはるかに少なく、より広範な言語サポートにアクセスできます。予想通り、macOS 開発者は、Apple の厳格なエコシステムとプラットフォーム固有の API の使用により、より急な学習曲線に対処する必要があります。

しかし、Windows ユーザーは Web ベースのデスクトップソフトウェアに慣れており、開発者もそれを認識しています。アプリが動作する限り、たとえ動作が遅くても、反発は軽度である傾向があります。したがって、企業はそれに応じて投資を減らすことになります。

それはすべて、Apple が低価格 PC を出荷しない最初の理由によるものです。現在、同社の顧客のほとんどは購買力が高く、会社全体が高級ブランドとみなされているため、今後の低価格MacBookはPCメーカーにとって深刻な頭痛の種となる可能性がある。

したがって、ブラウザベースのモデルがより安価で、どこにでも出荷でき、ユーザーもそれほど不満を言わない場合、最適化と RAM 使用量の削減のためだけに Windows 用のネイティブコードを書くように企業とその開発者を説得することは非現実的になります。

RAM の価格は上昇しており、これは変わらない

これらすべてのタイミングはこれ以上に悪いものはありません。 RAM の価格は多くの場合、ほぼ 2 倍になっていますが、これは主に一般消費者への供給削減、DDR5 の積極的な価格設定サイクルによって引き起こされており、その中で最大のものは AI データセンターによって生み出された圧倒的な需要です。メモリメーカーは現在、こうした利益率の高いエンタープライズ向けチップを優先している。

Windows アプリの現在の状態を解決する魔法のような修正はありません。開発者にとっては何のメリットもないと思われるため、ここで果たすべき最大の役割はマイクロソフトです。同社は、開発者をネイティブツールに再び誘導し、WinUI を改良してより魅力的なものにし、Windows の長年の問題を修正することでコアシステムの品質が依然として重要であることを示すことができます。

Windows がブラウザーベースのアプリを基盤とした世界に導入される予定である場合、プラットフォームはまず模範を示し、ユーザーと開発者の両方に作業のためのより良い基盤を提供する必要があります。

ホーム

ニュースレター

WL ニュースレター

WLニュースレターです！

最新の Windows、IT、AI アップデートを常に入手してください。 50,000 人以上の加入者から信頼されています。

名前

電子メール

無料で参加

*️⃣ 出典リンク:

コンシューマー向けRAMビジネス、メモリが4 GBを超えると自動再起動、正確には利益が得られるわけではない、WebView2ラッパーとして構築された新しいバージョンは問題を認めたと説明、 Windows 11 通知パネルの今後の予定表ビューは WebView2 を使用し、今後の予算の MacBook、ホーム、