This article was translated from 英語 by GPT-5 Thinking.
少数のテックジャイアントが支配する世界で、ゼロから新しいウェブブラウザーを作ることは、神々に挑むのに等しい行為だ。
それでもなお、まさにそれをやっているのが Ladybird ブラウザー・プロジェクトである。既存技術に新しい皮を被せるのではなく、独立した本物のウェブブラウザーを目指し、新しいエンジン（LibWeb）と自作の JavaScript インタープリター（LibJS）を中核に据えている。
そこで本稿では、そもそも「ブラウザーエンジン」とは何なのか、そしてなぜ仙女が撒いた花びらのように数多く存在しないのかを語ろう。さらに、もし Chrome が買収されたら何が起きるのか。
もちろん私は Safari と Firefox の愛好家で、Chrome はあくまで議論の題材にすぎない。
心臓部#
多くのユーザーにとって、ブラウザーは画面上のアイコン—広大なインターネットへの門—にすぎない。
だがこの門の背後で働く中核部品は「ブラウザーエンジン」と呼ばれる複雑なソフトウェアだ。いくつかの比喩で理解してみよう。
それはブラウザーの心臓であり、休むことなくデータを送り出すポンプだ。同時に偉大な翻訳者でもある。ウェブサイトの生のコード—人間にとってそのままでは読みにくい HTML、CSS、JavaScript のテキスト—を、その場で翻訳し、私たちの画面に表示されるインタラクティブで豊かなページへと変換していく。
「ブラウザーエンジン」「レイアウトエンジン」「レンダリングエンジン」という用語はしばしば同義で使われる。
これらはいずれもブラウザーの中核部分を指し、主な責務はウェブページのコードを解釈し、ページ上のあらゆる要素の位置とスタイル（すなわち「レイアウト」）を計算し、それらを画面に描画することだ。
ブラウザーの構造をより明確に理解するため、エンジンを他の2つの部分と区別する必要がある。第1はユーザーインターフェース（UI）。アドレスバー、進む／戻るボタン、タブなど、私たちが直接目にする部分である。
第2は JavaScript エンジン。これはウェブページ内の JavaScript コードを実行し、ページに動的なインタラクティブ性を与えるための独立したコンポーネントだ。
ブラウザーエンジンはこれらすべてを調停し、JavaScript エンジンと緊密に連携して、静的な文書を生きたアプリケーションへと変える。
歴史#
現代のインターネットを見渡すと、ほぼすべてのウェブ体験は3大家族のブラウザーエンジンによって駆動されている。
それぞれが技術進化と市場競争の産物であり、固有の進化の道筋を体現している。
- Blink：2013年に WebKit からフォークし、Google 主導で開発。現在世界で最も高いシェアを持ち、Chrome、Microsoft Edge、Opera、Brave、Vivaldi など多くのブラウザーを支えている。
- WebKit：Apple 主導で開発。さらに古い KHTML エンジンに起源を持つ。Safari の中核であり、Blink が誕生するまでは Chrome のエンジンでもあった。
- Gecko：Mozilla 財団によって開発。Firefox の中核。Blink／WebKit 圏外では、現在も有意なシェアと影響力を保つ唯一の独立エンジンである。
また、過去の参加者として Microsoft の Trident（Internet Explorer）や EdgeHTML（旧 Edge）も忘れてはならない。
（Blink エンジンは Chromium オープンソース・プロジェクトの一部である）
奇跡#
URL を入力する#
すべては単純な行為から始まる。アドレスバーに URL を入力して Enter を押す。
この命令を受けると、ブラウザー内蔵のネットワーク機構が直ちに動き出す。
大まかには次の段階に分けられる。
- DNS ルックアップ：そのウェブアドレスに対応するサーバーの所在を知る必要がある。ブラウザーは「ドメインネームシステム（DNS）」に問い合わせ、人間に読みやすいドメイン名（例：www.baidu.com）を、サーバーが理解できる ↗ IP アドレス（例：220.181.7.203）へと引き当てる。いわばインターネットの電話帳だ。
- 接続確立：IP アドレスを取得したら、ブラウザーは TCP プロトコルで対象サーバーとの信頼できる接続を確立する。
- リクエスト送信：接続が確立すると、ブラウザーはユーザーに代わってサーバーへ HTTP リクエストを送り、URL に対応するウェブページの内容を要求する。
DOM と CSSOM#
サーバーはリクエストを受け取ると、通常は HTML ファイルからなる応答データを返す。
ここでレンダリングエンジンがパースを開始する。
まずエンジンは HTML コードを逐次読み取り、コンピューターが理解できる木構造の論理体—DOM（Document Object Model）—に変換する。
これは、建築家の設計図を、各部屋・壁・扉・窓とその関係を含む構造化されたリストへと写し取るようなものだ。
次に、HTML のパースと並行して、ブラウザーは HTML で参照された CSS ファイルも取得・解析する。スタイル規則（色、フォントサイズ、レイアウト方式など）を木構造に変換し、CSSOM（CSS Object Model） を構築する。
レンダーツリー#
続いてエンジンは DOM ツリーと CSSOM ツリーを結合し、新たなツリーである レンダーツリー を生成する。
これはページの最終的な視覚表現のための総合設計図だ。賢いことに、画面に表示する必要がある要素だけを含む。
例えば CSS で display: none が指定された要素はレンダーツリーに現れない。ツリーの各ノードは最終的なスタイル情報を保持している。
すべての要素を所定の場所へ#
レンダーツリーが構築されると、工程は極めて重要な段階、レイアウト（リフロー） に入る。
ここではレンダーツリー上の各ノードについて、画面上での幾何情報—サイズと位置—が精密に計算される。
ページ全体の幅からボタンの高さ、1 行のテキストの折り返し位置に至るまで、空間的な関係がピクセル単位の精度で決まっていく。
ペインティング#
すべての要素の位置とサイズが定まると、いよいよ ペインティング が始まる。
エンジンはレンダーツリーを走査し、OS のグラフィックス API（UI バックエンド）を呼び出して、テキスト、画像、背景色、枠線などの各要素を、対応する画面のピクセルへと描いていく。
この一連の処理は段階的に進行する点は重要だ。より良い体験のため、ブラウザーは HTML・CSS・画像のすべてがダウンロード完了するのを待たず、できる限り早期に描画を開始する。
そのため、まず内容が表示され、その後スタイルが読み込まれて一瞬ちらつく（Flash of Unstyled Content）ことがある。
インタラクティビティ#
初期描画が済むと、独立した JavaScript エンジン（例えば Chromium の V8）が輝き始める。
ページに埋め込まれた JavaScript コードを実行し、静的なページに生命を吹き込むのだ。
ボタンを押した後のポップアップ、滑らかなスクロールアニメーション、ページをリロードせずに新しい内容を読み込む（AJAX）といった動きは、いずれも JavaScript のおかげである。
ここで性能最適化の要諦が見えてくる。レイアウトやペインティング、JavaScript の実行といった処理の多くは通常、同じメインスレッドで行われる。
もし JavaScript の一部が長時間を要すればメインスレッドをブロックし、スクロールやクリックなどのユーザー操作への応答を妨げてしまう。画面上の内容が完全に読み込まれていても、ページが固まったりカクついたりして見えるのはそのためだ。
だからこそ、ブラウザー開発者は性能最適化に絶えず巨額の労力を注ぎ込んでいる。
Google 対 米国#
せっかく Chrome の話題になったので、独禁法の問題にも触れておこう。要するに、連邦地裁の Amit Mehta 判事は 2024 年 8 月、Google が一般検索サービスと検索広告市場における独占を違法に維持したと判断した。
例えば 2021 年だけでも、Google は自社検索を各種プラットフォームのデフォルトにするために 263 億ドルという途方もない額を支払っていた。
この評決を受け、司法省（DOJ）は独占の解体を狙う救済措置を提案し、その中心で最も衝撃的なのが Google の Chrome ブラウザー事業の強制的な分離・売却 だ。
圧倒的なシェアを持つブラウザーとして、Chrome は Google が検索独占を維持するための重要ツールである。数十億のユーザーに到達する最重要の配信チャネルであるだけでなく、巨大なデータ収集端末でもあり、検索分野での堀をさらに固めている。
（注：DOJ の分離命令は Google Chrome を対象としている）
公共事業#
では、旗艦製品であるブラウザーを売却させられた後、Google は Chromium への巨額投資を続ける動機を持てるのか？
答えは「イエス」だ。というのも、Google の中核的な事業利益はオープンウェブの健全性と切っても切り離せないからである。
Google の主要収益源—検索広告、YouTube、Google Cloud—はいずれも、高速・安定・安全で、絶えず革新を続けるウェブプラットフォームに依存している。
ウェブが停滞したり分断されたりすれば、コンテンツやサービスのマネタイズ能力に直撃する。
したがって、Chromium への資金提供は単なるブラウザー製品支援ではなく、数兆ドル規模のエコシステムの基盤インフラを維持する行為なのだ。
同時に、Google はウェブ標準を主導し続けられる。高度な広告技術、リッチメディア、複雑なウェブアプリに有利な方向へ、ウェブプラットフォームの進化を導けるからだ。
もちろんもう一つの狙いは、Apple（WebKit エンジン）など競合にウェブ標準の方向性を支配され、自社の中核サービスが将来のウェブ環境で不利になる事態を避けることにある。
ゆえに、Chromium は Google にとって単なる一製品の依存物ではなく、戦略的な堀そのものと見なせる。
DOJ の救済策は検索独占を固めるために使われた「製品としての Chrome」を解体しようとしている。しかし Google のビジネスモデル自体はオープンウェブ全体の健全性に依拠している。
このプラットフォームを形作る主力は Chromium の Blink エンジンだ。だから Chrome という製品を失っても、Chromium への投資を通じてウェブ進化に影響を与えたいという Google の動機は残る。
それはもはや分離された製品のためではなく、核心的収益源をプラットフォームレベルのリスク（例：Apple 主導の進化、マネタイズ不能なまでの断片化）から守るための戦略投資だ。
Chromium への資金投入は、Google が自らの帝国の土台を保つために負担せざるを得ない「公共事業費」なのである。
では、Chrome を分離すれば独占は本当に解消されるのだろうか？
メンテナンスコスト#
Chrome およびその基盤である Chromium を維持することは、巨大なエンジニアリング作業であり、コストと複雑さは一つの OS を開発するのに匹敵する。
ここではいったん Chromium の開発論点を脇に置き（Ladybird の話で改めて触れる）、まず Chrome のセキュリティについて語ろう。
セキュリティ確保は迅速な対応に依存する。Chrome は約 4～6 週間ごとにフルのブラウザー更新を出し、重要なセキュリティ修正を含む小規模更新は 2～3 週間ごとにリリースする。
ほぼすべての更新がセキュリティパッチを含み、すべて同等に重要と見なすべきだ。この高頻度の更新サイクルには大規模で専門的なセキュリティ／リリースエンジニアリングのチームが必要となる。
言い換えれば、買い手候補として名前が挙がる OpenAI や Perplexity のような企業は、数百億ドル規模の評価額を持ちながら、自らの中核 AI 事業のために巨額のキャッシュを燃やしている。
これらの企業のコア・コンピタンスは大規模言語モデルであって、何十億というエンドポイントを抱えるクライアントアプリのグローバルなセキュリティ基盤を運用することではない。
したがって、セキュリティという負担そのものが巨大で見えにくい参入障壁になる。買収者は莫大なユーザーベースだけでなく、ネットワーク上の「永続的な戦争」も相続するのだ。
このことは、適格な買い手の母集団を著しく狭め、そもそも分離案の実現可能性に疑義を投げかける。
（Chromium は Google が Chrome に注ぎ込むあらゆるセキュリティ報奨と投資の間接的受益者である）
さらに DOJ の目的は「反競争的行為から市場を解放し、競争を回復する」ことにある。裁判所が認定した害悪は、Google が支配的資産（Chrome）を用いて別の支配的資産（検索）を保護した点だ。
しかし、Chrome を OpenAI のような潤沢な資金力を持つ主体に売却しても、根本的な独禁の問題は解けず、次の技術パラダイムへ単に移送されるだけかもしれない。
OpenAI による Chrome 買収は、Google のモデルを寸分違わず再現する恐れがある。すなわち、市場支配的資産（Chrome）を梃子に、台頭しつつある、より重要になり得る AI エージェント／AI 主導の情報取得市場における覇権を固めることだ。
ここに独占のパラドックスがある。ある独占を解くための救済が、次の独占の種を同時にまく。規制当局は昨日の問題を解きながら、明日の問題を生んでいるのかもしれない。
なぜなら、Chrome 級の市場力を得た競合は誰であれ、自社の AI サービスをインターネットへのデフォルトの入口に設定しやすいからだ。これは Google を分割する本来の趣旨に反し、実質的な独占問題の解決にもならない。
財団という選択肢#
企業売却の種々の欠点を前に、より建設的な代替案が見えてくる。Chromium を中立の非営利財団のガバナンス下に置くというものだ。
このアプローチは、ウェブ基盤として不可欠な Chromium の健全かつ中立的な発展を将来にわたり確保する最善の道として広く考えられている。
運営は Linux Foundation や Apache Software Foundation といった成功例をなぞることができる。
ガバナンスは、Chromium エコシステムに依存する主要ステークホルダー—Google、Microsoft、Opera など—の間で共有する。
運営資金はエコシステムに依存する会員企業のコンソーシアムが共同で拠出する。このモデルは財政的負担を分散し、単一企業が過度な影響力を行使することを効果的に防ぐ。
以上は時事への簡単な論評にすぎない。本稿の主目的は Ladybird の紹介にある。
Ladybird#
Ladybird の出自は SerenityOS プロジェクトにさかのぼる。これはゼロから構築されたホビー志向のデスクトップ OS だ。
当初 Ladybird はそのシステム内の単純な HTML ビューアにすぎなかった。この歴史は後の発展に決定的で、既存のフレームワークに頼らず、仕様の実装から積み上げるという「第一原理」文化を築いた。
転機は、創設者の Andreas Kling が SerenityOS の日常的なメンテナンスから身を引き、Ladybird の開発に全力投球する決断を下したことだ。SerenityOS からフォークし、独立したクロスプラットフォーム・プロジェクトになった。
プロジェクトの長期的独立性とミッション重視の姿勢を確実にするため、チームは米国で非営利法人 Ladybird Browser Initiative を正式に設立した。
この組織形態は、営利ではなく公益を目的とする性格を法的に確立する。
透明性#
Ladybird の開発哲学は、厳格な「ウェブ標準第一」である。開発チームは W3C や WHATWG といった標準化団体が公開する仕様文書に直接基づき、機能を一から実装していく。
これは、事実上ブラウザー実装が標準を定義してしまう現在の市場主導モデルとは対照的だ。
プロジェクトは完全な透明性を重視する。すべての開発活動は GitHub 上で公開され、コミュニティの主要なコミュニケーションは誰でも参加できる Discord サーバーで行われ、コード貢献を歓迎している。
さらに、ユーザーのプライバシーを中核に据える。内蔵の広告ブロック機能をロードマップに含め、あらゆる形のユーザートラッキングやデータのマネタイズ手法を明確に拒否している。
経済モデル#
Ladybird は、個人と企業からの無条件の寄付とスポンサーシップのみによって資金調達される。このモデルは主流ブラウザーとは本質的に異なる。
今日の多くのブラウザー（オープンソースの Firefox を含む）は、デフォルト検索エンジン契約から主要収入を得ている（前述のとおり）。
寄付のみの非営利モデルは単なる資金調達の代替ではない。技術的・倫理的独立性の構造的な保証である。
Firefox のような主流ブラウザーの主たる収入源は検索エンジンからのパートナー料だ。これは強力な金銭的インセンティブを生み、意思決定において検索事業者の目標を考慮せざるを得なくさせる。
その目標には広告事業を支えるデータ収集がしばしば含まれ、ユーザープライバシー保護という本来の趣旨と衝突し得る。
Ladybird は、定款と公開コミットメントによって、この収益流を制度的に断っている。組織レベルでこの潜在的利益相反を排除することで、（より強力なプライバシー保護の実装やデフォルトでのトラッカー遮断など）技術的決定が、金銭的パートナーを喜ばせる必要に左右されることは決してない。
したがって、この経済モデルこそが、ユーザー中心主義を実現する堅固な土台なのである。
機能面#
さて現実に戻ろう。Ladybird は実際に使い物になるのか？
プレアルファ#
現在 Ladybird は依然としてプレアルファ段階にあり、一般ユーザーの日常利用には適さない。
体験したいユーザーは自分でソースコードからビルドする必要がある。愛好家にとって難しくはないが、一般には高いハードルだ。
とはいえ、プロジェクトは活発で迅速な開発ペースを維持している。チームは月次の進捗動画などの形式で最新の成果をコミュニティに共有している。
そこでは、マージされた Pull Request の件数、新規コントリビューター数、合格した Web Platform Tests（WPT）の数といった主要指標が示され、健全な開発軌道を物語っている。
互換性#
ブラウザーエンジンの標準準拠度を測る権威的ベンチマーク WPT において、Ladybird は目覚ましい進歩を遂げている。2025年3月時点でのテスト合格率は第4位で、成熟した3大エンジン—Chrome、Safari、Firefox—に次ぐ位置につけた。ゼロから作られた新エンジンとしては特筆すべき成果だ。
JS パフォーマンス#
自作の JavaScript エンジン LibJS も標準準拠の観点で優秀だ。WPT の結果では、LibJS は Firefox の SpiderMonkey に次ぐ 第2位の仕様準拠 を示している。
アーキテクチャ#
Ladybird の技術的中核は、完全自作のエンジン部品 LibWeb と LibJS にある。
LibWeb は HTML パース、DOM 構築、CSS レンダリングといったウェブコンテンツの表示に関するあらゆる処理を担う。
LibJS はウェブページ内の JavaScript コードを実行する完全な ECMAScript エンジンである。
プロジェクトは当初、SerenityOS の技術スタックを色濃く継承し、全面的に C++ で書かれていた。
独立後は、コードの安全性と堅牢性を高める目的で、Swift のようなメモリ安全な言語を第2開発言語として導入する評価と計画を積極的に進めている。
さらに、コード量の面では、Ladybird の C++ コードは約 42.5 万行であるのに対し、Chromium は 3200 万行超に達する（いくつかのプラットフォームを欠くとはいえ、非常にスリムだ）。
この軽量なアーキテクチャには多くの利点がある。
第一に、保守コストと複雑さを大幅に低減する。
第二に、小さなコードベースは新規貢献者がシステム全体の仕組みを理解しやすく、参入障壁を下げる。
最後に、この「ハックしやすさ」は実験と革新を促し、新機能の迅速な反復と実装に好適な環境を作る。
Blink や Gecko のようなブラウザーエンジンは、数十年の開発で数百万行規模に膨れ上がり、旧来標準の互換やアーキテクチャ進化への追随といった歴史的複雑性を不可避に抱えている。
対照的に、Ladybird は 2020年代生まれであり、（マルチプロセス分離やメモリ安全といった）現代的なソフトウェア工学の原則に基づいて最初から設計でき、巨大で根深いレガシーを大規模リファクタリングする必要がない。
著しく小さいコードベースは一人の開発者でも全体を把握しやすく、少数のコア開発者への過度な依存を減らし、より全体最適なアーキテクチャ判断を促す。
つまり、新しいウェブ標準の実装やアーキテクチャ変更において、巨大なレガシーに縛られる既存エンジンよりも、Ladybird のほうが素早く動ける可能性がある。
マルチプロセス#
Ladybird は現代的なマルチプロセス・アーキテクチャを採用し、これがセキュリティ設計の中心となっている。メインの UI プロセスを、サンドボックス化された複数の WebContent レンダリングプロセスから厳格に分離し、各タブが独立したレンダリングプロセスで動作する。
さらに、画像デコードやネットワークリクエストのようなセンシティブな処理も別プロセスで扱う。
この設計は重要なセキュリティ上の優位性と見なされている。機能モジュールを分離したプロセスに分配することで、悪意あるコンテンツ処理中にレンダリングプロセスがクラッシュしたり侵害されたりしても、その影響は当該プロセスのサンドボックス内に封じ込められる。メイン UI プロセスや OS 全体を守り、攻撃面を大幅に減らすのだ。
課題#
主流ブラウザーに対する実行可能な代替となるには、Ladybird の最優先技術課題は**機能同等性（パリティ）**の達成だ。
これは途方もない仕事で、膨大かつ拡張し続ける Web API 群の実装のみならず、多様なウェブサイトでのピクセル単位の一致、拡張機能や高度なメディアコーデックのサポートといった複雑な機能も含まれる。
プロジェクトは現在「まず動くものを作る（make it work）」段階にあり、今後「良くする（make it good）」「高速にする（make it fast）」段階へ移行しなければならない。
これはレンダリングパイプラインと JavaScript 実行の徹底的な最適化を要し、資源集約的で長期的な投資が不可欠だ。
セキュリティ面では、既存のアーキテクチャ的サンドボックスに加え、継続的なハードニングが必要である。現代ブラウザーのセキュリティ維持コストは極めて高い。Google のような企業はバグバウンティに毎年数百万ドルを投じ、Pwn2Own のようなトップレベルのハッキング競技では主流ブラウザーへのゼロデイ攻撃が頻繁に実演される。
ユーザーの信頼を得るには、Ladybird も同等に強固なセキュリティ対応・防御体制を築く必要がある。
非技術的な最大の障害は、ブラウザーそのものを作ることではなく、ウェブエコシステムに存在する Chromium の自己強化フィードバックループ を乗り越えることだ。
Chromium の支配的地位ゆえに、圧倒的多数のウェブ開発者は Chrome での動作確認を最優先にする。その結果、ウェブは Blink の特定実装（既知のバグや非標準動作を含む）に実質最適化されてしまっている。
新しいブラウザーである Ladybird が標準に忠実な実装をしたとき、むしろ Chromium 固有の癖に依存するサイトで表示崩れが起きることがある。
Ladybird の挙動がより仕様に準拠していても、ユーザー視点ではサイトが「壊れている」ように見える。
この現象が「新参ブラウザーはバグだらけ」という印象を与え、開発者・ユーザー双方の Chromium 志向をさらに強化してしまう。
したがって Ladybird は標準準拠であるのみならず、Chromium 中心のウェブに合わせるための互換性確保にも多大な工数を割く必要があるかもしれない。
戦士#
私たちはこれまで、ドラゴンを倒す英雄譚を数多く聞いてきた。Ladybird の登場は、Chromium というドラゴンの影が覆う王国で、なお剣を抜くことを厭わない戦士のようだ。その勇気を称えつつ、勝算の薄さに不安も覚える。
無意識に問う。「この戦士はいずれ新たなドラゴンになるのか？」
だが、そもそも問いが間違っているのかもしれない。
Google と米司法省のせめぎ合い、そして Chrome の新たな所有者が誰になるかという議論は、究極的には誰が鉄の玉座に座るかの話である。
独禁の剣が一人の王を打ち倒しても、玉座が残る限り、それを欲する者は常に現れる。
Chrome をある巨人から別の巨人へと手渡すのは、王冠の受け渡しにすぎず、私たちが王の支配下で生きるという事実は何も変わらない。
ここに「戦士がドラゴンを討つ」というナラティブを超える、Ladybird の真の意義がある。
Ladybird は新たな王になろうとしているのではない。使者として、耳をつんざくメッセージを運んでいるのだ。
世界は王を必要としない。
Ladybird の価値は、短期的に Chrome を代替できるか否かにあるのではない。その存在そのものが、現在のウェブの姿が唯一最適な解ではないことへの強力な反証なのだ。
ゼロから書かれる一行一行のコードは、未来へ通じる道が一つではないことを証明する。オープンに立ち返り、コミュニティが共に築き、データではなくユーザーを第一に据える道があり得るのだ。
それは、私たち一人ひとりの選択をこれまで以上に重要なものにする。
ブラウザーを選ぶとき、私たちは単に道具を選んでいるのではない。望む未来に一票を投じているのだ。
効率的で善意あるが唯一の君主が統治する中央集権の帝国を選ぶのか。それとも、やや混沌としている（本当にそんなに混沌だろうか？ 例：Mastodon と X）かもしれないが、しなやかさと自由に満ちた都市国家の多様な同盟を選ぶのか。
独禁の究極目標は、おそらく、玉座を奪い合う企業を増やすことではない。玉座のない世界を創る権利と可能性を、常に私たちが持ち続けることを保障することだ。
そして Ladybird のようなプロジェクトこそが、その可能性を守る火種である。