なぜSlackは重いのか？本当の原因と解決策

一言で言うと

SlackはElectronアプリケーションであるため重くなります。ElectronはフルChromiumウェブブラウザとNode.jsランタイムをデスクトップアプリにまるごとバンドルします。Slackを起動するとき、コンピュータは実質的にブラウザを立ち上げ、その中で複雑なウェブアプリケーションを読み込み、Slackが起動し続ける間ずっとそれをメモリ上に保持し続けます。このアーキテクチャ上の選択が、一通もメッセージを送っていない状態でも1GB超のRAMを消費する理由です。

これは一時的な障害でも、Slackのサーバー側の問題でもありません。公式クライアントをデスクトップで動かす際の、構造的なコストです。

Electronがあなたのマシンに与える影響

Electronアプリケーションのオーバーヘッドは、いくつかの側面に分けて考えられます。

メモリ使用量。 Chromiumのレンダラープロセスは、アプリケーションのロジックが走る前から相当なベースラインコストを持っています。Slackはその上に、チャンネル・スレッド・検索・通話・アプリ連携といったワークスペースUI全体を重ねます。結果として、複数タブを開いたフルブラウザを一日中起動し続けるのに匹敵するメモリフットプリントになります。

アイドル時のCPU。 ElectronアプリはDOMのポーリング、バックグラウンドJavaScriptタイマーの実行、操作していない間のUI再レンダリングを常時行うことが多く、少なくとも1コアを断続的に占有し続けます。これがラップトップのファン回転やバッテリー消費につながります。

起動時間。 Slackの起動にはChromiumインスタンスの初期化、JavaScriptバンドルの読み込み、認証、ワークスペースの描画が必要です。ミドルレンジのマシンでは数秒かかることも珍しくなく、同等の処理を行うネイティブアプリと比べると体感差は明らかです。

これはSlackだけの問題ではありません。多くの人気デスクトップアプリが同じアーキテクチャと同じトレードオフを抱えています。コミュニケーションツールはバックグラウンドで一日中動き続けるという点で特に影響が大きく、わずかなアイドルオーバーヘッドが積み重なって、作業効率とバッテリー寿命への実質的なコストになります。

Slackに障害が起きているのか、それとも常にこんなに重いのか

Electronを疑う前に、実際のサービス障害を除外しておく価値はあります。Slackはstatus.slack.comでリアルタイムのステータスページを公開しています。メッセージ送信の失敗、ファイルのアップロード不能、通知の不着といった症状が出ているなら、プラットフォーム側のインシデントが原因かもしれません。それは一時的なものであり、自然に解消します。

一方、Slackが全体的に重い――アイコンをクリックしてから表示されるまで時間がかかる、システムファンが回り出す、アクティビティモニタやタスクマネージャで高いメモリ使用量が見える――という場合は、Electronのベースラインコストであり一時的な障害ではありません。Slackを再起動すればメモリが解放されてキャッシュがクリアされる分、一時的に軽くなることはありますが、セッションが続くにつれてオーバーヘッドは戻ってきます。

ネイティブクライアントがどう状況を変えるか

コンパイル型システム言語でOSのレンダリングプリミティブを直接使って書かれたネイティブデスクトップクライアントは、ブラウザをバンドルしません。OSがより小さなバイナリを読み込んですぐに処理を開始できるため、起動が速くなります。バックグラウンドでJavaScriptのイベントループが走らないため、アイドル時のCPU使用率はほぼゼロに近くなります。表示に実際に必要なデータだけをメモリに確保するため、メモリフットプリントはElectronの何分の一かに収まります。

これがmsgaの存在理由です。msga（Make Slack Great Again）はC++とQt6で書かれた無料のオープンソースSlackクライアントです。Telegram Desktopと同じフレームワークを採用しており、ブラウザでラップすることなくSlackのAPIにネイティブに接続します。

現時点のmsgaに期待できること

msgaは活発に開発が進んでいるプロジェクトであり、その点について正直に述べています。チャンネルやダイレクトメッセージでのメッセージ読み書きといったコアなメッセージング機能は動作します。Electronのリソースコストなしに日常のコミュニケーションをカバーするクライアントを目指しています。

一部の高度な機能（特定のワークフロー自動化、アプリ内通話、一部のサードパーティ連携など）はまだロードマップ上にあります。これらに強く依存するワークフローをお持ちの場合は、完全に移行する前にプロジェクトのGitHubページで現在の実装状況を確認されることをお勧めします。多くのユーザーは、日常業務の大半をmsgaで対応しつつ、未対応のエッジケースにだけブラウザ版Slackを使うという運用が現実的だと感じています。

まとめ：実践的な結論

Slackが今日重く感じられる理由は、去年重かった理由と同じです。コミュニケーションアプリをブラウザの中で動かすことには、作業時間のあらゆる瞬間に積み重なるコストがあります。実際のサービス障害は確認する価値がありますが、重さが構造的なものであれば、どれだけ待っても再起動しても根本的には解消しません。

その構造的な問題を解決するのが、この用途のために設計されたネイティブクライアントです。msgaはLinux、macOS、Windowsで無料で利用でき、ソースコードはGPL-3.0のもとで公開されています。公式クライアントのメモリ・CPU負荷が日常業務に影響しているなら、一度試してみる価値があります。