- Braveのメモリセーバーは「最大」設定でも効かないタブが多数ある。理由はbrave://discards/のView Reasonで確認できる
- スワップのリセットには再起動が必要。タブ整理＋再起動で57GBのスワップが完全に解消した
- Cursor拡張機能と常駐アプリも要因。3段階の対処でアプリメモリを17.5GB → 12.7GBに削減した
先日、MacBook Air M5(32GB)を使っていたらアクティビティモニタのスワップ使用量が57GBという異常な数値になっていました。物理メモリの1.8倍のスワップ。Macが悲鳴を上げている状態です。
なります。しかも「Braveのメモリセーバーはちゃんと最大設定にしてあるのに」という状態で。
結果的に2時間かけて原因を特定し、3段階で解決しました。この記事はその記録です。brave://discards/ というBrave内蔵ページの使い方が特に役立ったので、同じ問題で悩んでいる方に向けて詳しく残しておきます。
- スワップ57GB。32GBのMacで何が起きていたか
- 犯人はBrave。でもメモリセーバーは最大設定済みだった
- brave://discards/ で真相を解明した
- 第1段階：Urgent Discard + Mac再起動
- 第2段階：不要常駐アプリを削減してベースラインを下げる
- 第3段階：Cursor拡張機能の棚卸し（40 → 26個）
- Before / After：3段階の効果まとめ
- 同じ32GBでもM5 AirとM1 Maxで挙動が違う理由
- よくある質問（FAQ）
- まとめ
スワップ57GB。32GBのMacで何が起きていたか
M5 Air(32GB)でBraveブラウザのスワップが57.36GB(物理メモリの1.8倍)・圧縮6.42GB・使用済みメモリ28.65GBという異常状態に陥りました。メモリプレッシャーグラフは緑のままでも、実際は圧縮とスワップで凌いでいる詰みかけの状態。M1 Maxからの乗換からわずか1ヶ月でこの状態に到達しました(2026年5月時点)。
アクティビティモニタを開いて目に入った数値がこれです。
- 使用済みメモリ: 28.65 GB（物理32GBのほぼ限界）
- スワップ使用領域: 57.36 GB
- 圧縮: 6.42 GB
スワップとはメモリが不足したときにSSD上に作られる仮想メモリのことです。物理メモリの1.8倍のスワップが積み上がっており、Macがずっとメモリを圧縮・スワップしながら無理やり動かしている状態でした。
メモリプレッシャーグラフは緑でしたが、これは「今は余裕がある」ではなく、「圧縮とスワップで凌いでいる」という状態です。
この「同じ32GBでも挙動が違う」という点は後で詳しく説明します。
犯人はBrave。でもメモリセーバーは最大設定済みだった
アクティビティモニタ降順表示でBrave Browser Helper(Renderer)が画面を埋め尽くし、最大1.90GB含む合計16GB超を消費。アプリメモリ17.53GBのほぼ全部がBrave関連でした。Braveのメモリセーバーは既に「最大」設定済み・除外リストも空で、設定の問題ではない構造的問題です(2026年5月時点)。
アクティビティモニタをメモリ降順でソートすると、Brave Browser Helper (Renderer) が画面を埋め尽くしています。最大1.90GBのRendererが1個、1.14GB、1.01GBと並び、合計すると16GB超がBrave関連プロセスに使われていました。
アプリメモリ17.53GBのほぼ全部がBrave。犯人は明確です。
ただしBraveのメモリセーバーは既に「最大」に設定済みでした。「常にアクティブにするサイト」の除外リストも空。設定の問題ではありません。
brave://discards/ で真相を解明した
brave://discards/はBrave内蔵デバッグページで、全タブの「Auto Discardable(ユーザー側ON/OFF)」「Is Discardable(技術的破棄可否)」「Lifecycle State(loaded/frozen/discarded)」を確認できます。「最大」設定はAuto DiscardableをON化するだけで、Is Discardable✕のタブは解放されません(2026年5月時点)。
Braveには brave://discards/ というデバッグページがあります。全タブの状態を一覧で確認でき、「なぜそのタブが解放されないか」の理由まで調べられます。
Is Discardable = ✕ の衝撃とは？
ページを開いて衝撃を受けました。ほぼ全タブの「Is Discardable」が ✕（不可） です。
このページで確認できる状態は3つあります。
- Auto Discardable: ユーザー側のスイッチ（自動破棄を許可するかどうか）
- Is Discardable: Brave側の判定（技術的に破棄できる状態かどうか）
- Lifecycle State: 現在の実状態（loaded / frozen / discarded）
「最大」設定はAuto Discardableを全タブONにするだけです。Is Discardableが✕のタブは、設定に関係なく解放されません。
また、frozenは「一時停止状態」でメモリ削減効果は限定的です。本当に効くのはdiscarded（完全アンロード）状態だけです。
View Reasonで判明した「ピン留め以外の除外理由」は？
最初の仮説は「ピン留めタブが原因」でした。20個近いピン留めタブがあったので。ところがView Reasonで確認すると、ピン留め以外の要因が大量に出てきます。
Googleスプレッドシートのタブ（frozenにしかなれていないもの）のView Reasonを見ると、このような理由が表示されていました。
- Tab is updating favicon or title in the background
- The user has edited the tab's content
スプレッドシートはバックグラウンドでも定期的に保存処理が走るため、構造的にDiscardされません。
Google Driveのタブは4つの除外理由が複合していました。メモリセーバーが効かない主な除外理由はこれだけあります。
- Tab was pinned — ピン留め
- Notification permission is granted — 通知許可（Gmail / Slack等）
- Tab is updating favicon or title in the background — バックグラウンド更新（Googleサービス全般）
- Tab has form interactions — フォーム操作中
- The user has edited the tab's content — 内容を編集した
- Tab is recently visible — 最近表示したばかり
ピン留めの判断基準として「通知が来るタブ = ピン留めOK / ただ開いておきたいだけ = ブックマーク」という整理が一番現実的です。
第1段階：Urgent Discard + Mac再起動
brave://discards/上部の「Urgent discard a tab now」連打でスプレッドシート7個・Claudeタブ複数・Upstash・note等13個のタブをunloaded化。Mac再起動でスワップ57GB→0バイト・圧縮6.42GB→0バイト・使用済みメモリ28.65GB→14.43GB・アプリメモリ17.53GB→10.70GBに完全回復。macOSはSIPの関係で再起動以外にスワップを消す手段がありません(2026年5月時点)。
Urgent Discard連打で強制解放
brave://discards/ のページ上部に「Urgent discard a tab now」というボタンがあります。これを連打すると、優先度の低いタブから順番に強制的にDiscardされていきます。
スプレッドシート7個、Claudeタブ複数、Upstash、note等が次々unloaded状態に。合計13個のタブを強制破棄しました。
Mac再起動でスワップを完全リセット？
強制Discardでアプリメモリは減りますが、スワップはMac再起動でしかリセットできません。
Linuxには swapoff -a に相当するコマンドがありますが、macOSはSIP（System Integrity Protection）の関係で安全に実行できる手段がありません。再起動が唯一の現実解です。
再起動後の数値です。
| 項目 | Before | After |
|---|---|---|
| 使用済みメモリ | 28.65 GB | 14.43 GB |
| アプリメモリ | 17.53 GB | 10.70 GB |
| 圧縮 | 6.42 GB | 0 バイト |
| スワップ | 57.36 GB | 0 バイト |
| キャッシュされたファイル | 3.33 GB | 14.78 GB |
完全回復です。キャッシュされたファイルが増えているのは、空きメモリを有効活用している正常な状態なので問題ありません。
第2段階：不要常駐アプリを削減してベースラインを下げる
OneDrive削除(200〜500MB+バックグラウンド同期処理ゼロ)、iMovie削除(常駐202MB)、Apple Intelligence無効化(常駐MLモデル数GB削減・Siriも同時無効)の3対処でベースライン消費が2.5〜5GB削減できる見込みです。ログイン項目は5〜7個以内が目安で、自分は6個で適正でした(2026年5月時点)。
ブラウザを整理しただけでは、ベースラインの消費が高いままだとすぐ再発します。次は常駐アプリの棚卸しです。
対処したのは3つです。
OneDrive（削除） : Google Driveに完全移行済みで不要。削除で200〜500MB＋バックグラウンド同期処理がなくなります。
iMovie（削除） : 常駐で202MB消費していましたが、使っていませんでした。macOSの移行時に自動でインストールされていたものです。
Apple Intelligence（無効化） : macOS Tahoeから導入された機能ですが、自分は使っていません。常駐MLモデルが数GBを消費するため、使わないなら無効化が正解です。Siriも同時に無効化されます。
3つ合わせてベースライン消費が2.5〜5GB削減できる見込みです。
第3段階：Cursor拡張機能の棚卸し（40 → 26個）
Cursor Helper(Plugin):extension-hostが複数プロセス合計713MB(Cursor関連で約1.4GB)を消費していました。cursor --list-extensions --show-versionsで40個を一覧化し、重複機能5個・Python関連5個(普段使わないため)・未使用テーマ4個の計14個を削除して40→26個に整理。extension-hostは300〜400MBに削減見込みです(2026年5月時点)。
アクティビティモニタをよく見ると、Cursor Helper (Plugin): extension-hostが複数プロセスで合計713MB消費していました。Cursor関連だけで約1.4GBです。
cursor --list-extensions --show-versions で一覧化すると40個。多すぎます。
削除した内訳はこちらです。
| カテゴリ | 削除数 | 内容 |
|---|---|---|
| 重複機能 | 5個 | フォーマッター・パス補完・TODO管理等で重複していたもの |
| Python関連 | 5個 | 普段Pythonを使わないため |
| 未使用テーマ | 4個 | 使用中テーマを自動判定して不要なものを削除 |
| 合計 | 14個 | 40 → 26個 |
テーマ拡張機能の整理では、Claude Codeにsettings.jsonと各拡張のpackage.jsonを読ませて「使用中のテーマはどれか」を自動判定してもらいました。3テーマのローテーション中、拡張機能が必要なのはDracula At Nightのみと判明し、残り4個を削除。
「複数ファイルをまたぐ横断調査 → 削除候補リスト化」はClaude Codeが得意な領域です。ただし「勝手に削除しないこと、コマンド提示までで止めること」と明示するのが大事です。
extension-hostの消費は削減後に約300〜400MBになる見込みです。
Before / After：3段階の効果まとめ
3段階すべての対処後の最終状態です。
| 項目 | 問題発生時 | 第1段階後 | 最終状態 |
|---|---|---|---|
| 使用済みメモリ | 28.65 GB | 14.43 GB | 16.67 GB |
| アプリメモリ | 17.53 GB | 10.70 GB | 12.69 GB |
| 圧縮 | 6.42 GB | 0 | 480 MB |
| スワップ | 57.36 GB | 0 | 0 バイト |
BraveのタスクマネージャはShift+Escで開きます。タブ単位のメモリ確認ができます。整理後はTwitchが297MB（画質を480pに変えた効果）、Claudeタブが528MB（最重量）という状態でした。
同じ32GBでもM5 AirとM1 Maxで挙動が違う理由
M1 Max(2021〜2026年3月)とM5 Air(2026年3月〜)はどちらも32GB容量ですが、メモリ帯域が約400GB/s→約153GB/s(約4割)、ファンあり→ファンレス、macOS Sonoma→Tahoeと処理余裕度が大きく異なります。Tahoeはベースライン消費が増加傾向で、M5 Airの軽快さで無意識にタブを増やすと容量だけで判断したパターンが破綻しがちです(2026年5月時点)。
M1 Max(2021〜2026年3月)では同じタブ運用でも問題が起きなかったのに、M5 Air(2026年3月以降)で1ヶ月で破綻した理由を整理します。
M1 MaxとM5 Airの主な違いはこちらです。
| 項目 | M1 Max | M5 Air |
|---|---|---|
| メモリ帯域 | 約400 GB/s | 約153 GB/s |
| 冷却 | ファンあり | ファンレス |
| macOS | Sonoma | Tahoe |
メモリ帯域が約4割（400GB/s → 153GB/s）になったことで、圧縮・スワップ処理の余裕度が大幅に下がります。またTahoeはSonomaよりベースライン消費が増加していると感じました。
よくある質問（FAQ）
Q. MacでBraveのスワップが異常に大きい原因は何ですか?
- メモリセーバー「最大」設定でも、ピン留め以外の構造的要因(通知許可・バックグラウンド更新・フォーム操作・編集済み・最近表示)でDiscardされないタブが多いことが主因です。brave://discards/のView Reasonで個別タブの除外理由を確認できます。
Q. Braveのメモリセーバーが効かないのはなぜですか?
- 「最大」設定はAuto Discardableを全タブONにするだけで、Is Discardableが✕のタブは設定に関係なく解放されません。Googleサービス(Gmail/Drive/Calendar/Docs/Sheets)やnoteは構造上Discardされにくい代表例です。
Q. macOSでスワップを手動でクリアできますか?
- macOSはSIP(System Integrity Protection)の関係で、Linuxの
swapoff -aに相当するコマンドが安全に実行できません。スワップを完全リセットするにはMac再起動が唯一の現実解です。
Q. ピン留めタブはすべて外すべきですか?
- 通知が来るタブ(Gmail/Slack/Calendar等)はピン留めを外しても他の要因でDiscardされないため無意味です。一方、開いておきたいだけのSNSやAmazonタブはピン留め解除でDiscard対象になります。判断基準は「通知が来る=ピン留めOK・開いておきたいだけ=ブックマーク」です。
Q. 同じ32GBのMacでもM5 AirとM1 Maxで挙動が違うのはなぜですか?
- メモリ帯域がM1 Max約400GB/s→M5 Air約153GB/sと約4割に低下、ファン付き→ファンレスで圧縮・スワップ処理の余裕度が下がります。さらにmacOS Sonoma→Tahoeでベースライン消費が増加傾向のため、容量が同じでも処理余裕度に大きな差が出ます。
まとめ
M5 Air(32GB)でBraveのスワップが57GBになった原因と対処をまとめます。
第1段階（タブ整理 + 再起動） : アプリメモリ17.5GB → 10.7GB。スワップ・圧縮を完全解消。
第2段階（不要常駐アプリ削減） : OneDrive・iMovie削除、Apple Intelligence無効化でベースライン2〜5GB削減。
第3段階（Cursor拡張機能 40 → 26個） : extension-host 713MB → 300〜400MB見込み。
今回の一番の収穫は「メモリセーバー設定だけでは解決しない」という事実と、その理由を brave://discards/ のView Reason で画面として確認できることです。
同じ症状で困っている方はまずbrave://discards/を開いて、View Reasonで自分のタブが「なぜDiscardされていないか」を確認してみてください。「ピン留めが原因だろう」という直感が外れるケースがほとんどのはずです。
