ブラウザのマルチプロセス・サンドボックスアーキテクチャ

なぜブラウザは複数プロセスなのか

ブラウザは「信頼できない他人のコード」を常時実行する、特殊なアプリケーションです。任意のサイトの HTML・CSS・JavaScript・WebAssembly を解釈・実行し、しかもそれらは攻撃者が書いたものかもしれません。レンダリングエンジン（Blink）や JavaScript エンジン（V8）はC++で書かれた巨大なコードであり、メモリ安全性のバグはゼロにできません。そこで Chrome は**「いずれ攻略される」前提**で設計されています。鍵は2つです。

• 権限分離（privilege separation）：信頼できないコードを動かす部分（レンダラ）から、強い権限（ファイル・ネットワーク・デバイス）を取り上げる。
• 障害分離（fault isolation）：1つの部品の異常を、その部品の中に封じ込め、ブラウザ全体やほかのサイトへ波及させない。

この2つを満たすために、Chrome は1つの巨大プロセスではなく、役割の違う複数のOSプロセスに分割されています。プロセスはOSが提供する最も強い隔離境界——別々の仮想アドレス空間と権限——だからです。

プロセスの役割分担

Chrome の代表的なプロセスは次の通りです。タスクマネージャ（Chrome の Shift+Esc）で実際の内訳を確認できます。

中核はブラウザプロセスとレンダラプロセスの非対称性です。ブラウザプロセスはユーザーの代理として強い権限を持ちますが、サイトのコードを直接は実行しません。レンダラプロセスはサイトのコードを実行しますが、強い権限を持ちません。両者はプロセス間通信（IPC）、Chrome では Mojo と呼ばれるメッセージ機構でやり取りします。レンダラが「このファイルを読みたい」「この URL を取得したい」と思っても、自分ではできず、ブラウザプロセスへ IPC で依頼するしかありません。ブラウザプロセスは依頼を検証してから実行する、いわばリファレンスモニタとして働きます。

Site Isolation：サイトごとに別プロセス

初期の Chrome はタブ単位でプロセスを分けていましたが、1つのタブが iframe で複数サイトを埋め込むと、別サイトのコンテンツが同じレンダラプロセスに同居してしまいます。同一プロセス内に同居すると、メモリ上に別サイトのデータが載りうる——これが後述する Spectre の文脈で致命的になります。

Site Isolation は、ページ本体と各 iframe をそれぞれの所属サイトのレンダラプロセスへ分ける仕組みです。a.com のページが b.com の iframe を含むと、b.com の iframe は別プロセス（アウトオブプロセス iframe、OOPIF）でレンダリングされます。これにより、あるサイトのコードが触れるメモリにはそのサイトのデータしか存在しない状態を、OSのアドレス空間分離によって物理的に保証します。

さらにネットワーク応答の段階でも防御します。レンダラが b.com のデータを必要としない場面で b.com の機微な応答（例えば JSON や HTML）を受け取ろうとした場合、ブラウザプロセス側でそのバイト列をレンダラのメモリに渡さないようにします。これが CORB（Cross-Origin Read Blocking）、現在の後継が ORB（Opaque Response Blocking） です。クロスオリジンで正当に読めるのは画像・スクリプト・スタイルなど限られた型だけなので、機微なデータ型はそもそもレンダラへ載せない、という発想です。クロスオリジンの読み取り可否のルールは CORS と地続きの世界です。

サンドボックス：レンダラから権限を奪う

レンダラプロセスは「いつか攻略されるコード」を実行する場所なので、最初から無力化しておきます。これがサンドボックスです。具体的には、OSのセキュリティ機構を使って、レンダラプロセスに対し以下を禁じます。

• 任意のファイルの読み書き（ファイルシステムへの直接アクセスを遮断）
• 任意の宛先へのネットワーク接続（ネットワークサービス経由のみ）
• 画面への直接描画やデバイス操作
• 新しいプロセスの起動や、ほかのプロセスへの干渉

実装はOSごとに異なります。Windows ではジョブオブジェクト・制限付きトークン・別デスクトップ・AppContainer などを組み合わせ、Linux では namespace と seccomp-bpf（許可するシステムコールをホワイトリスト化）、macOS では Seatbelt ベースのサンドボックスプロファイルを使います。

レンダラがやりたいこと          実際の経路
------------------------------  --------------------------------
fetch("https://...")        →   IPC → ブラウザ（ネットワークサービス）が代行
ローカル画像を表示          →   IPC → ブラウザがファイルを開いて中身を渡す
canvas / WebGL を描画       →   IPC → GPU プロセスがコマンドを実行
Cookie を読む               →   IPC → ブラウザが同一オリジンポリシーを検証して返す

ポイントは、禁止された操作はすべて IPC でブラウザプロセスに肩代わりしてもらう点です。そしてブラウザプロセスは依頼ごとに正当性（オリジン、権限、サイズなど）を検証します。攻撃者がレンダラ内で任意コード実行（RCE）に成功しても、できるのは「サンドボックス内でできること」だけ。端末を本当に支配するには、さらにサンドボックス脱出（sandbox escape）——OSカーネルの脆弱性や IPC の検証漏れの悪用——という二段目の壁を越えねばなりません。重大な攻撃は通常「レンダラ RCE + サンドボックス脱出」の**連鎖（チェーン）**として組み立てられます。

Spectre とサイトレベル分離の必然性

なぜ「同一プロセスにさえいなければ安全」と言い切るのか。背景に Spectre（2018） があります。Spectre は CPU の投機的実行を悪用するサイドチャネル攻撃で、本来アクセスできないメモリの内容を、キャッシュのタイミング差として間接的に読み出すものです。

決定的なのは、Spectre がソフトウェアのメモリ保護を越えて、同一アドレス空間内のデータを読めてしまう点です。つまり、別サイトのデータが同じレンダラプロセスのメモリに載っていれば、JavaScript からそれを盗み見る現実的な手段が存在します。配列の境界チェックや言語レベルのサンドボックス（V8 のヒープ分離など）は、投機実行の前では完全な壁になりません。

ここから導かれる設計判断が明快です。「同一プロセスのメモリに、別サイトの機微なデータを最初から置かない」。これこそが Site Isolation と CORB/ORB を既定で全面有効化した根拠です。緩和策（投機の抑制、SharedArrayBuffer の制限、高精度タイマーの粒度低下など）も併用されますが、それらは補助線にすぎません。本丸の防御はプロセス境界によるデータの物理的分離である、という割り切りが Chrome のアーキテクチャを貫いています。

トレードオフと運用

プロセス分割はタダではありません。各プロセスは独自のメモリ常駐（V8 のヒープ、Blink のオブジェクト等）を持つため、サイトが増えるほどメモリ使用量が増加します。これが「Chrome はメモリを食う」と言われる主因の1つで、Site Isolation の全面有効化はこのコストと引き換えに安全性を取った判断です。Chrome はメモリ逼迫時にプロセスをまとめる（同一サイトを共有させる）などの調整も行います。

実務的には、この設計は開発者の前提も変えます。クロスオリジンの埋め込みは別プロセスで動くため、SharedArrayBuffer のような強力な機能は COOP/COEP によるクロスオリジン分離をページが宣言しないと使えません。マルチスレッド WASM や正確なメモリ計測を使いたいなら、これらのヘッダ設定が前提になります。タブ間で重い JS を動かしてもUIが固まりにくいのは、レンダラとブラウザUIが別プロセスだからで、JS 実行モデルの詳細は イベントループ詳説 を、データ保存の分離は Web ストレージ を併読すると、どこで何が隔離されるかの地図が完成します。描画側の続きは ブラウザのレンダリング へ。

まとめ