😤 1タブで2000MB消費の地獄
タスクマネージャーを開いて、Chromeのプロセス一覧を見たことがある人なら分かる。YouTubeを1タブ開いているだけで、気づけば2000MB近くを消費している。さらに何も表示されていない新規タブを開くだけで100〜200MBが上乗せされ、拡張機能が1つ動けばまたそこに数十〜数百MBが加算される。
「ブラウザを閉じたらパソコンが速くなった」という体験は決して気のせいじゃない。現代のブラウザはOSの上で動くもう一つのOSと化していて、JavaScriptエンジン・レンダリングエンジン・ネットワークスタック・GPUプロセス・サービスワーカーが同時に走り続けている。ブラウジングという行為がそのままシステムリソースの全方位圧迫になっている。
Chromeのメモリ消費の内訳（YouTubeを1タブ開いた状態）
| プロセス種別 | 消費メモリの目安 |
|---|---|
| ブラウザメインプロセス | 200〜400MB |
| レンダラー（タブ本体） | 500〜1200MB（JS・DOM・画像） |
| GPUプロセス | 100〜300MB |
| ネットワーク・サービスプロセス | 50〜150MB |
| 拡張機能（1つあたり） | 30〜200MB |
さとまたちゃんが感じた「なんかPCが重い」という感覚の正体はこれ。タブを10枚開けば平気で8〜12GBを食い潰す。メモリ16GBのマシンでChromeだけに半分以上を渡してしまうのは、どう考えても設計の問題だ。
🏗️ なぜブラウザはここまで重くなったのか
1990年代のブラウザは今と比べると驚くほどシンプルだった。HTMLを解析してテキストと画像を並べるだけのツールで、メモリ消費は数十MB程度だった。それが2026年現在、ギガバイト単位のメモリを要求するソフトウェアになった。この変化には明確な理由がある。
マルチプロセスアーキテクチャ
2008年9月、Googleはマルチプロセスアーキテクチャを採用したChromeを発表した。設計者はAdam Barthら。この設計の核心は「タブ・拡張機能・GPU・ネットワークを全て独立したOSプロセスとして分離する」というものだ。
それ以前のブラウザは1つのプロセスで全てを処理していたため、1つのタブがクラッシュするとブラウザ全体が落ちた。マルチプロセスにすることで安定性とセキュリティを劇的に向上させたが、代償として各プロセスが独自のメモリ空間を持つようになり、合計消費量が増大した。
V8 JITコンパイラとJavaScriptヒープ
ChromeのV8エンジンはJavaScriptをJIT（Just-In-Time）コンパイルによって最適化済みのマシンコードに変換する。このコンパイル済みコードはメモリ上に保持され続ける。JavaScriptヒープは1つのレンダラープロセスあたり最大1.4〜2GBまで拡張されうる。現代のWebアプリ（特にSPA）はJavaScriptを大量に走らせるため、このヒープがほぼ上限まで使われることも珍しくない。
V8エンジンの進化史
サイト分離（Site Isolation）
2019年に標準化されたSite Isolationは、異なるオリジン（ドメイン）のコンテンツを絶対に同一プロセスに入れないという設計だ。Meltdown・Spectreというハードウェア脆弱性への対応として導入された。セキュリティ的には正しいが、サブフレームやiframeが多いページでは追加プロセスが大量に生成され、さらにメモリを消費する。
積極的キャッシュ戦略
「戻るボタンを押したら瞬時に前のページが表示される」という体験を実現するために、ChromeはDOMツリー・画像デコード済みデータ・スクロール位置などをRAMにそのまま保持し続ける。これはBack-Forward Cacheと呼ばれる機能で、ユーザー体験を優先した結果としてメモリ消費が増大している。
🌳 ブラウザエンジンの系譜
現代のブラウザエンジンは、1990年代後半から始まる複雑な分岐と統合の歴史を持っている。今動いているChromiumのBlinkも、Safariを動かすWebKitも、起点をたどると意外なところに行き着く。
MicrosoftはEdgeをChromiumベースに刷新。Trident・EdgeHtmlは歴史の彼方へ。
唯一Blink/WebKit系から完全独立して生き残るエンジン。Rustで書かれたServoを実験的に取り込み中。
KHMLの開発は2023年終了。しかしその子孫Blinkが世界のブラウザシェアの7割以上を占める。
2026年時点で生き残るエンジンは3系統のみ
- 🔵 Blink — Chrome・Edge・Opera・Vivaldi・Brave・Electron（世界シェア7割超）
- 🍎 WebKit — Safari・iOS上の全ブラウザ（Appleの規制によりiOSはWebKitのみ）
- 🦊 Gecko — Firefox（唯一の独立系）
⚙️ Chromiumとは何か
Chromiumは、GoogleがChromeブラウザのベースとして開発しているオープンソースのブラウザプロジェクトだ。2008年9月2日、ChromeのリリースとまったくDの日にオープンソース化された。当初の構成はWebKit（レンダリング）＋V8（JavaScript）＋ブラウザUI全体という組み合わせだった。
2013年の転換点として、GoogleはWebKitからBlinkをフォークした。理由はシンプルで「マルチプロセス設計に関わる大きな変更を、WebKitの共同管理者（Apple等）の合意なしには進められなくなったから」だ。以降ChromiumはBlinkを独自に進化させ、Appleも同様にWebKitを独自に発展させている。
Chromiumの目的
- ✅ Webをプラットフォームとして成立させる
- ✅ Google自身のWebサービスの最高実行環境を作る
- ✅ オープンソース化でエコシステムを育てる
- ✅ 他ブラウザベンダーが採用できる共通基盤を提供
ChromeとChromiumの違い
- 🔵 Chrome = Chromium + Googleサービス統合 + Widevine（DRM）+ 自動更新
- ⚪ Chromium = コアのみ。DRMなし・Googleアカウント統合なし
- 📦 EdgeやBraveはChromiumベースで独自機能を追加したもの
ChromiumのソースコードはGitで管理されており、誰でもクローンできる。ただし全体のサイズは数十GBに達し、ビルドには高スペックなマシンと数時間の時間が必要だ。だからこそ、「Chromiumを直接改造する」のではなく、Chromiumのバイナリをそのまま使いながらJavaScriptレイヤーだけをカスタマイズするElectronという選択肢が生まれた。
⚡ Electronとは何か
Electronは、Node.jsとChromiumを組み合わせてデスクトップアプリを作るためのフレームワークだ。歴史を知ると、なぜこれが生まれたかがよく分かる。
Electronの誕生史
内部構造
Electronアプリはメインプロセス（Node.js）とレンダラープロセス（Chromium/Blink）の2層構造で動く。メインプロセスがウィンドウ管理・ファイルシステムアクセス・システムAPI等を担当し、レンダラープロセスがHTMLとJavaScriptでUIを描画する。各ElectronアプリはChromium・V8・Node.jsのバイナリを全て同梱するため、圧縮後でも80〜100MBのサイズになる。
有名なElectronアプリ
| アプリ名 | カテゴリ | メモリ消費目安 |
|---|---|---|
| VSCode | コードエディタ | 200〜600MB |
| Slack | チャット | 1〜4GB（重い） |
| Discord | ゲーマー向けチャット | 1〜4GB（2024年に4GBメモリリーク報告） |
| Claude Desktop | AIアシスタント | 130〜400MB |
| ChatGPT Desktop | AIアシスタント | 200〜500MB |
| Notion | メモ・ドキュメント | 300〜800MB |
| Obsidian | ノート | 130〜350MB（比較的軽量） |
| GitHub Desktop | Gitクライアント | 200〜400MB |
| Spotify | 音楽ストリーミング | 250〜700MB |
見て分かる通り、Electronアプリは軽いものでも130〜250MB、SlackやDiscordのような重量級は1〜4GBに達する。「Electronは重い」という批判は正しいが、それでも「クロスプラットフォームデスクトップアプリをWebの知識だけで作れる」という圧倒的なメリットがあるから、大量のアプリが選び続けている。
🪟 Minブラウザとは何か
MinはElectronベースで作られたオープンソースのミニマリストブラウザだ。作者はGitHubユーザーPalmerAL。「最も必要な機能だけを、シンプルに」という設計思想で作られており、ChromeやFirefoxとは対極に位置する。最初の外部報告記事は2016年7月（OMG! Ubuntuでv1.6.0が確認）で、2026年3月時点でv1.35.4が最新版。総リリース数88以上、月1〜1.5回ペースで活発に開発が続いている。
内部アーキテクチャ
Minは内部でElectronの「BrowserView」を採用している。古いwebviewタグではなくBrowserViewを選んだ理由は明確で、BrowserViewの方が独立プロセスとしてより安定して動作するからだ。各タブは独立したBrowserViewインスタンスとして生成され、サンドボックス化されている。これにより1つのタブがクラッシュしてもブラウザ全体に影響が及びにくい設計になっている。
Minの主な機能
- 🛡️ 組み込みAdBlocker（広告ブロック標準搭載）
- 🎯 フォーカスモード（他のタブを非表示）
- 📖 リーダーモード（記事を読みやすく整形）
- 📁 タスク（タブグループ機能）
- 🔍 スマート検索バー + ファジー検索
- 📝 ユーザースクリプト対応（v1.8.0〜）
- 🌙 ダークモード強制適用
Minの設計思想
- 🪶 UIは極限までシンプルに（アドレスバー+タブのみ）
- 🔒 プライバシーファースト（DuckDuckGoデフォルト）
- 🚫 不要な機能は入れない
- ⚡ Electronのレイヤーで動くため、Chromium自体は改造しない
- 🌍 クロスプラットフォーム（Windows・Mac・Linux）
MinのコードベースはJavaScript（Node.js）とHTMLで書かれており、Chromiumのソースを1行も触っていない。Electronが提供するAPIを通じてウィンドウ・タブ・ネットワークを制御している。これがさとまたちゃんにとって重要で、「フォーク可能」かつ「Chromiumビルドの知識が不要」という点がMinを選ぶ最大の理由になる。
⚖️ ChromeとMinの違い
ChromeとMinを「ブラウザ」として並べて比較すると、用途や対象ユーザーが全く異なることが見えてくる。どちらが優れているかではなく、何をしたいかによって選択が変わる。
| 項目 | Chrome | Min |
|---|---|---|
| 拡張機能 | Chrome Web Store対応（数万本） | 非対応（ユーザースクリプトのみ） |
| DRM（Widevine） | ✅ 標準対応（Netflix等OK） | ❌ 標準版は非対応（Netflix不可） |
| YouTube再生 | ✅ 問題なし | ✅ 問題なし（HTML5動画） |
| UI | フルUI（ツールバー・ブックマーク・設定等） | 最小限（アドレスバー+タブのみ） |
| アカウント同期 | Googleアカウント対応 | なし |
| デフォルト検索エンジン | DuckDuckGo（プライバシー重視） | |
| AdBlocker | なし（拡張機能で追加） | ✅ 標準搭載 |
| トラッカーブロック | なし（デフォルト） | ✅ 標準搭載 |
| メモリ消費（1タブ） | 500〜2000MB+ | 200〜500MB（軽量） |
| フォーク・改造 | Chromiumビルド知識が必要 | JS/CSSだけで可能 |
🎬 DRM問題について
Min標準版はWidevine DRMを搭載していないため、Netflixや一部のAmazonプライムビデオでエラーが出る。ただしYouTubeはHTML5動画（非DRM）で動くため問題なく再生できる。DRMが必要なコンテンツを見たい場合はコミュニティフォーク（min-ng等）を使う方法がある。
🛠️ コミュニティのカスタマイズ事例
Minはオープンソースなので、世界中の開発者が独自改良版を作って公開している。その中でも特に注目すべきフォークと取り組みを紹介する。
min-ng（Alex313031）
最も有名なMinのフォークの一つ。Alex313031が管理しており、以下の2点が最大の特徴だ。
- 🪟 Windows 7対応ビルド — 現在公式サポートが終了したWindows 7でもMinが動くよう改良したビルドを提供
- 🎬 Widevine（DRM）組み込み — 標準版では見られないNetflixやAmazonプライムビデオも視聴可能。DRM問題を解決した事実上の「完全版」
公式マルチウィンドウサポート（PR#2237）
Minの作者PalmerAL自身が「マルチウィンドウサポート」をプルリクエスト#2237として実装・マージした。コミュニティのニーズが本体にフィードバックされた好例で、Minはシングルウィンドウという制約を超えた。
その他のフォーク群
GitHubには複数のMinフォークが存在し、それぞれ独自機能の追加・特定OS向け改良・UIのカスタマイズ等を行っている。フォークの活発さはMinのコードベースが触りやすく、改造しやすい設計になっていることを示している。さとまたちゃんが「自分用ブラウザを作りたい」と思ったときに、このコミュニティの蓄積がそのまま参考になる。
特にmin-ngのDRM対応は重要なポイントで、「Minフォークではストリーミングが見られない」という問題が実際にコミュニティによって解決済みであることが分かる。さとまたちゃんのフォークでも同様のアプローチを取ることができる。
🔱 フォークして何をカスタマイズするか
Minをフォークしてさとまたちゃんだけのブラウザを作るとしたら、何を変えて何は変えないか。Chromiumに手を入れずにElectronのJavaScript層だけで実現できる範囲を整理する。
✅ JS/CSSだけで変えられること
⚠️ 追加調査・設定変更が必要なこと
- 🎬 Widevine DRM対応 — min-ngの実装を参考に組み込む必要がある
- 🔌 拡張機能の一部対応 — Electronのセッション設定でChrome拡張を限定的に使える場合もある
- 🔄 自動アップデート機能 — electron-updaterの設定が必要
❌ JSレイヤーだけでは無理なこと（Chromium改造が必要）
- 🚫 V8エンジンの挙動変更（JIT最適化の無効化等）
- 🚫 レンダリングエンジン（Blink）レベルのカスタマイズ
- 🚫 Chromiumのメモリアロケータ変更
さとまたちゃんの戦略は明確だ。Chromiumには手を入れない。Electronが提供するAPIとMinのJavaScriptコードだけを改造して、自分が毎日使いたいと思えるUIとUXを実装する。それだけで十分すぎるほどカスタマイズできる。
📍 ロードマップ
実際にMinをフォークして自分用ブラウザを作る場合の段階的なロードマップを整理する。一気に全部やろうとせず、まず動くものを作ってから徐々に機能を足す方針で進める。
現時点での進捗
Phase 1の「何をカスタマイズするか」の設計と調査が完了した状態。コードを書く前にアーキテクチャとコミュニティの先行事例を把握できた。
🎯 さとまたちゃんの結論
長い調査になったが、最終的な結論はシンプルだ。
さとまたちゃんの選択
- ✅Minをフォークする — Chromiumのビルドは不要。JS層だけで十分カスタマイズできる。
- ✅YouTube再生は最初から動く — HTML5動画はDRM不要。メインの用途は問題なし。
- ✅DRMはmin-ngを参考に後から対応 — 最初から完璧を目指さない。動くものを作ってから追加する。
- ✅コミュニティの先行事例が豊富 — 自分で0から考えなくていい。min-ngをはじめ参考になるフォークが多数存在する。
ブラウザが重い理由の整理（頭の中を整理するため）
- 🔵 マルチプロセス設計 → セキュリティのための必要悪。Minも同じ構造。
- 🔵 V8 JIT → JavaScript高速化のためのメモリトレードオフ。変えられない。
- 🔵 積極的キャッシュ → 快適な体験のための選択。バックグラウンドタブのサスペンドで対処できる。
- 🟢 UIと余分な機能 → ここが削れる。Minはすでにシンプル、さらにシンプルにできる。
ブラウザの重さの本質はChromiumとV8の設計にあり、そこは変えられない。でもChrome 2000MBの消費は、UIの複雑さ・拡張機能・Googleサービスの統合・積極的すぎるキャッシュ戦略が積み重なった結果でもある。Minはそのレイヤーを削ることで軽くなっている。さとまたちゃんはさらにその上で、自分の使い方に最適化したブラウザを作る。
ChromeもElectronも、もともとはWebをプラットフォームにしようというGoogleとGitHubの意志から生まれた。その副産物として、今さとまたちゃんが「自分のブラウザを作れる」環境が整っている。技術の歴史を知ると、何を使えばいいかがはっきり見えてくる。
次のステップ: MinリポジトリをフォークしてPhase 1を開始する