Skip to content
Published on

ブラウザエンジン 2026 — Chromium・Gecko・WebKit・Servo・LadyBird、ウェブを実際にレンダリングしているのは誰か

Authors

プロローグ — 3つのエンジンがウェブを描く

いまあなたが見ているこの画面の裏側には レンダリングエンジン がある。HTMLをパースしてDOMツリーを作り、CSSをマッチさせてスタイルツリーを作り、両者を合わせてボックスツリー・レイヤーツリー・ペイントツリーへと降ろし、最後にGPUにテクスチャを投げ込む — 数十万行規模のC++コード。私たちは毎日これを使っているが、ほとんど目にすることはない。

2026年5月時点でデスクトップ・モバイル・タブレットを合算すると、世界のウェブのレンダリングは 3つのエンジン がほぼすべてを担っている。

  • Blink (Chromium系) — 約81%。Chrome、Edge、Brave、Arc、Opera、Vivaldi、Samsung Internet、そしてElectronで束ねられたほぼすべてのデスクトップアプリ。
  • WebKit (Apple) — 約14%。Safari、そして — 少なくともEU圏外では — iOS上のすべてのブラウザ(Chrome iOS、Firefox iOS、Edge iOSを含む。App Store ポリシーでWebKit強制)。
  • Gecko (Mozilla) — 約3%。Firefoxとその派生。本当の意味で非Chromium・非Appleで残る最後のメジャーエンジン。

これで終わりだ。3つで99%を取り、残りの1%は Pale Moon の Goanna、Ekioh の GPU エンジン Flow、そして — 最も興味深い — ゼロから書き直している2つの野心作 Servo(Mozilla の Rust エンジン)と LadyBird(Andreas Kling の独立 C++ エンジン)が分け合う。

この記事ではその3つのエンジンと、その先で復活を試みている2つのインディーエンジンの 2026 年の現在地を整理する。そして問う。

私たちは本当に1つのエンジンが80%超のウェブを支える状況に耐えられるのか? 3つのエンジンは多様性の最低ラインなのか? そして — Servo と LadyBird は本当にプロダクションに到達できるのか?


1章 · なぜ3つのエンジンに収束したか — 30年の圧縮史

ウェブエンジンの歴史は短くも濃い。圧縮するとこうなる。

1.1 1993–2003: Mosaic、Netscape、IE、KHTML

  • Mosaic (1993) — 初のグラフィカルWebブラウザ。NCSAで始まり Netscape へ分岐。
  • Netscape Navigator (1994) — Mosaic 出身者が作った商用ブラウザ。エンジンは独自。1998 年にオープンソース化され、Mozilla プロジェクトが始まり、そこから Gecko が生まれた。
  • Internet Explorer (1995–) — Microsoft が Mosaic をライセンス、Trident エンジンを開発。1990 年代末には 90% 超のシェアで事実上ウェブを定義した。
  • KHTML (1998) — KDE プロジェクトの Konqueror ブラウザエンジン。軽量で綺麗な C++ コードベース。2003 年に Apple がフォークして WebKit を作る。

1.2 2003–2013: WebKit が現れ、Chrome がすべてを変える

  • WebKit (2003) — Apple が KHTML をフォーク。Safari 1.0 と共にリリース。
  • Chrome (2008) — Google が WebKit をフォークし、独自の V8 JavaScript エンジンと組み合わせる。マルチプロセスアーキテクチャで安定性が一段上がる。
  • Blink (2013) — Google が WebKit から分岐して独自エンジンを立ち上げる。同じ年に Opera も Presto エンジンを捨てて Blink に移行。

1.3 2013–2020: 単一化の加速

  • Microsoft Edge (2015) — IE 引退、独自の EdgeHTML エンジン。シェアは戻らず。
  • Edge → Chromium (2020) — Microsoft が EdgeHTML を捨て Chromium ベースで再出発。この時点でデスクトップ向けエンジンは事実上3つに圧縮された。
  • Servo (2012–2020) — Mozilla が Rust で始めた次世代エンジン。2020 年の Mozilla 大規模解雇時に外部へ移管され、しばらく休眠。

1.4 2020–2026: 復活と亀裂

  • Servo (2023) — Linux Foundation Europe (LFE) に移管され、活発な開発が再開。2026 年には組み込みデモと独自のブラウザシェルを披露。
  • LadyBird (2022–) — Andreas Kling(元 Apple WebKit エンジニア、SerenityOS 創設者)が SerenityOS ブラウザを独立プロジェクトとして分離。2024 年に非営利の LadyBird Browser Initiative を設立し、GitHub・Shopify 創業者(特に Chris Wanstrath、Tobi Lutke)らから数百万ドル規模の資金を確保。初のアルファ版リリース目標は 2026 年 7 月 (Linux/macOS)。Windows・Android は後回し。
  • iOS WebKit 強制解除 (2024 EU DMA) — EU 限定で iOS 上での非 WebKit エンジンを許可。Chrome iOS の Blink ベース版が試験的に投入される。実利用は緩やかだが、柱の一つが揺らぎ始めた事件。
  • DOJ vs Google 判決 (2024 年 8 月) — 米国連邦裁判所が、Google が検索市場で違法に独占を維持していると判決。2025 年の救済段階で DOJ は Chrome の分離 を勧告。2026 年は控訴が進行中。もし強制されれば、ウェブエンジンの地形が再び揺らぐ。

この章の要点: 3つのエンジンは「安定状態」ではなく、累積した合併の残滓だ。1990 年代には 4 〜 5 つあり、2010 年代半ばに圧縮され、2020 年代半ばから — 小さくとも — 再び分岐が始まっている。


2章 · エンジン別の精密解剖

所有者: Google (BSD 系オープンソース、ただし事実上は単一企業が方向性を決定)

JS エンジン: V8

レンダーパイプライン: Blink → cc (コンポジタ) → Viz (GPU プロセス) → Skia / Dawn

採用ブラウザ:

  • Chrome (Google)
  • Edge (Microsoft、2020 年に移行)
  • Brave (プライバシー重視)
  • Arc / Arc Search (The Browser Company)
  • Opera (2013 年に移行)
  • Vivaldi
  • Samsung Internet
  • Yandex Browser
  • Naver Whale
  • その他数十のマイナーフォーク
  • Electron ベースのデスクトップアプリすべて (VS Code、Slack、Discord、Notion、Figma デスクトップなど)
  • Tauri の一部オプション (デフォルトは OS WebView だが、Bundled Chromium オプションもある)

強み:

  • 最も早い標準採用。Container Queries、View Transitions、Anchor Positioning などの最新機能を最初に出荷。
  • 開発者ツールが業界標準。
  • WebGPU、WebRTC、メディアコーデック対応が最も広範。

弱み:

  • 単一企業が事実上の標準を定義する構造。「Blink がサポートすれば標準」のような圧力。
  • メモリ使用量が大きい。タブ1つあたり数百 MB。
  • Manifest V3 のような拡張 API 変更ではプライバシー / 広告ブロックの観点で論争。

ガバナンス: 形式上はオープンソースだが、コミットのほぼ 100% が Google 社員。Microsoft が Edge 採用以降に一部寄与(特に Windows・アクセシビリティ)。Igalia (スペインのコンサル) が外部コントリビューターとして大きな割合を占める — Container Queries、MathML など。

2.2 WebKit — Apple の庭園

所有者: Apple (LGPL / BSD 混合)

JS エンジン: JavaScriptCore (JSC)

レンダーパイプライン: WebCore → WebKit2 (マルチプロセス) → Metal / CoreAnimation

採用ブラウザ / プラットフォーム:

  • Safari (macOS、iOS、iPadOS、visionOS)
  • iOS 上のほぼすべてのブラウザ — App Store ポリシーで WebKit 強制 (Chrome iOS、Firefox iOS、Edge iOS、Brave iOS は全て WebKit ラッパー)
  • 2024 年 EU DMA 以降、EU 限定で iOS の非 WebKit 許可、実際の適用は段階的
  • macOS の SwiftUI WebView、AppKit WKWebView
  • PlayStation 5 のシステムブラウザ
  • Amazon Kindle、BlackBerry、Tizen などの一部組み込み

強み:

  • macOS / iOS で GPU・メディア統合が優秀 (Metal バックエンド)。
  • 省電力 — ノート PC・モバイルのバッテリー最適化。
  • プライバシー保護 — Intelligent Tracking Prevention (ITP) で先行。

弱み:

  • 多くの機能で標準採用が遅い。WebGPU・WebRTC・OffscreenCanvas・Service Worker などで Blink / Gecko より 1 〜 2 年遅れた。
  • iOS の WebKit 強制は — 少なくとも EU 圏外では — ユーザーにエンジン選択権を与えていない。
  • 開発者ツールが Blink・Gecko に比べ弱い。

ガバナンス: Apple 社員がほぼすべてのコミット。Igalia が WPE WebKit という組み込み派生を維持。Sony が PlayStation ブラウザ関連で一部寄与。

2.3 Gecko — 最後の非 Chromium の旗

所有者: Mozilla Foundation / Mozilla Corporation (MPL 2.0)

JS エンジン: SpiderMonkey

レンダーパイプライン: Gecko → WebRender (Rust ベースの GPU コンポジタ) → Direct3D / Metal / OpenGL

採用ブラウザ:

  • Firefox (デスクトップ、Android)
  • Firefox ESR (長期サポート)
  • LibreWolf (プライバシー強化フォーク)
  • Waterfox (古い拡張互換)
  • Tor Browser (Firefox ESR ベース)

強み:

  • 最も強いプライバシー保護。トラッキング遮断・フィンガープリンティング対策がデフォルト。
  • WebRender — Rust で書き直された GPU コンポジタ。合成段階で効率的。
  • 標準委員会で — 小さくとも — バランス重として機能。

弱み:

  • 人員と資源が小さい。Mozilla は 2020 年・2024 年に大規模解雇を経て、2026 年現在のフルタイムエンジンエンジニアは高い1桁台 / 低い2桁台と推定される。
  • 標準採用が Blink より 6 〜 12 か月遅れることが多い。WebGPU は 2025 年後半にようやく安定化。
  • モバイルシェアが非常に小さい(Android で1桁前半、iOS は WebKit ラッパーのため実質ゼロ)。

ガバナンス: Mozilla 単一企業主導。外部寄与はあるが小さい。2024 年以降、Mozilla が広告・AI へ事業多角化を試みる中で、「エンジンへの投資が減っているのではないか」という議論 — 通称 「Mozilla のミッションドリフト」 論争 — が大きくなっている。

2.4 Servo — Rust による未来の書き直し

所有者: 現在は Linux Foundation Europe (LFE) 傘下プロジェクト (2023 年移管)

JS エンジン: SpiderMonkey (Gecko から借用)

レンダーパイプライン: Rust フルスタック。並列レイアウト・並列ペイント — マルチコア活用が設計の中核。

歴史:

  • 2012 年に Mozilla Research でスタート。Rust 言語自体が Servo のために進化した側面がある。
  • Servo の一部コンポーネント(スタイルシステム、WebRender)は Gecko へ統合され、Firefox に使用されている。
  • 2020 年の Mozilla 解雇でほぼ休眠。
  • 2023 年に LFE が運営を引き継ぎ、Igalia・Huawei・ボランティアが寄与する形で活発な開発が再開。

2026 年の現状:

  • Linux / macOS 上でシンプルなページ・CSS・JS はレンダリング可能。
  • 独自のミニブラウザシェルがデモ可能。
  • 組み込みユースケースに注力 — 自動車インフォテインメント、キオスク、家電 UI など。
  • Tauri の実験的バックエンドオプションとして検討中。

プロダクション到達距離: デスクトップ一般ユーザー向けのブラウザに到達するには — まだ遠い。サイト互換性の作業が膨大。

2.5 LadyBird — 最も興味深いインディー

所有者: LadyBird Browser Initiative (501(c)(3) 非営利、2024 年設立)

JS エンジン: LibJS (独自)

言語: C++23 (元々は SerenityOS の LibWeb コンポーネント)

歴史:

  • 2019 年に Andreas Kling が SerenityOS の付属コンポーネントとして開始。
  • 2022 年に独立プロジェクトとして分岐。
  • 2024 年に LadyBird Browser Initiative 非営利を設立。初期資金は GitHub・Shopify 創業者(特に Chris Wanstrath、Tobi Lutke)、その後の支援者から数百万ドル規模。
  • フルタイムエンジニアは 10 人前後。

2026 年の現状:

  • 初のアルファ版リリース目標は 2026 年 7 月 — Linux / macOS。
  • Web Platform Tests の通過率が急速に上昇中 (2024 年中盤の約 80% → 2026 年初頭で一部領域 90%+)。
  • HTTPS、HTML5、CSS の大半、JavaScript ES2022 レベル、一部 Web API。マルチプロセスアーキテクチャ — タブごとに ProcessIsolation。
  • WebGPU・WebRTC・メディアコーデックは未対応または初期段階。

哲学:

  • 独立性優先 — 広告収益・VC・検索取引は受けない。寄付と支援のみで運営。
  • 底からの再構築 — 既存エンジンのフォークではない。100% 新規コード。
  • 標準準拠 — ユーザートラッキングなし。サイト互換性が優先。

プロダクション到達距離: アルファ版は「技術的可能性の証明」。一般ユーザーの日常利用は、楽観的に見ても 2028 年以降。しかし 30 年ぶりに 新しいメジャーエンジン が登場しつつあるという事実そのものに大きな意味がある。

2.6 Flow — 商用インディー

所有者: Ekioh (英国ケンブリッジ拠点)

言語: C++、独自の GPU 加速ライブラリ

用途: 組み込み・キオスク・セットトップボックス・車載インフォテインメントなど — 一般消費者向けブラウザではない。

特徴:

  • すべてを GPU で合成 — CPU 負荷を最小化。
  • マルチスレッドレイアウト。
  • 標準採用は選択的 — クライアント要件に合わせる。

なぜ興味深いか: 「独立して主要サイトの一部をレンダリング可能」な 2 つ目のインディーエンジンであるという点。LadyBird と並んで、インディーエンジンが可能であるという生きた証拠。

2.7 Goanna — 保守主義の旗

所有者: Moonchild Productions (Pale Moon 開発元)

起源: 2015 年に Gecko から分岐。XUL 拡張など、Firefox が捨てた機能を維持したい意図。

用途: Pale Moon、Basilisk ブラウザ。

現実: シェアは 0.1% 未満。標準採用が非常に遅い。モダンサイトの相当数が動作しない。しかし、最後の本当の意味での「ユーザーコントロール」を追求する小さなコミュニティが維持している。


3章 · 機能カバレッジマトリクス

エンジンごとの機能対応を一目で見る。O = 安定対応、~ = 部分 / フラグ、X = 未対応、- = 適用外

機能Chromium / BlinkWebKit (Safari 26)Gecko (Firefox 130)Servo (2026 nightly)LadyBird (Alpha)
HTML5 コアOOOOO
CSS Grid / FlexboxOOOOO
Container QueriesO (2022)O (2023)O (2023)~~
View Transitions APIO (2023)~ (2026 Safari 26 部分)~ (2026 Firefox 130 nightly)XX
Anchor PositioningO (2024)~~XX
CSS NestingOOO~O
WebGPUO (2023)O (2026 Safari 26)O (2025 Firefox 121)XX
WebGL 2OOO~~
WebRTCOOOXX
OffscreenCanvasOO (2024 Safari 17)O~X
Web ComponentsOOO~~
Worker での ES ModulesOOO~~
WebAssembly SIMDOOO~~
WebAssembly ThreadsOOOXX
Web CodecsO~ (2026 一部)OXX
Web StreamsOOO~~
Service WorkerOOOXX
WebAuthn / PasskeysOOOXX
Web Share Level 2OO (iOS)~XX
File System Access APIOXXXX

Web Platform Tests 通過率 (おおよそ、2026 年第1四半期時点 — 発表数値参照):

エンジンWPT 通過率
Blink (Chromium)約 98%
WebKit約 96%
Gecko約 96%
Servo約 78%
LadyBird約 88% (選択領域)

LadyBird の WPT 通過率がこれだけ速く上がっていることは、小さなチームが 6 年で作ったエンジンとしては印象的だ。


4章 · どのサイトがどこで壊れるか — 実戦互換性

標準の表は綺麗だが、現実はそうではない。実際にどのサイトがどのエンジンで壊れるか — 2026 年 5 月時点で整理すると。

4.1 Safari / WebKit でよく壊れるパターン

  • <input type="date"> インタラクションの差異 — iOS Safari はネイティブピッカーを強制、デスクトップ Safari は非標準 UI。
  • 強い PWA 制約 — Add to Home Screen はできるが、Service Worker キャッシュ容量・プッシュ通知で制約。2024 年の EU 政策変化以降も痕跡が残る。
  • IndexedDB トランザクションタイミング差 — Safari の IDB は他エンジンより微妙なロック競合を頻発する。
  • WebRTC ICE candidate 交渉が稀に — 特にモバイル — 非対称 NAT でより頻繁に失敗。
  • メディアコーデック — VP9・AV1 はデスクトップでは対応するがモバイルで限定的。H.264・HEVC が優遇。
  • File System Access API 非対応 — デスクトップアプリ級のファイルワークフローは不可。

4.2 Firefox / Gecko でよく壊れるパターン

  • 一部の広告 / トラッキング遮断が — 意図的に — サイト自体を壊す。サイトがトラッカー依存だと真っ白な画面。
  • WebGPU・OffscreenCanvas は安定化したが、Blink より 6 〜 12 か月遅れた。その期間のサイトが時々壊れる。
  • モバイル Firefox (Android) のシェアが小さく、サイトがほとんどテストしていない。しばしば Chromium 専用 CSS が処理されない。
  • DRM コンテンツは — Widevine を別モジュールでロード — 一部環境で無効化。

4.3 Chromium でも壊れる

これはよく忘れられる。「Chrome なら無条件動く」は嘘だ。

  • Manifest V3 以降の拡張 API 変更で一部の拡張が — 特にコンテンツブロック・高度な自動化 — 機能低下。
  • Origin Trials のみで有効化された機能にコードが依存すると、トライアル満了後に突然壊れる。
  • ChromeOS・Android WebView・Electron の間に微妙な挙動の差。
  • Edge・Brave・Opera などの派生ブラウザが広告・追跡遮断を挟み込んだ結果サイトが壊れる。

4.4 互換性テストマトリクス (現実版)

小さなチームが合理的にテストできる最小マトリクスを定めるなら。

優先度エンジン / プラットフォーム理由
P0Chrome デスクトップ約 50% のトラフィック
P0Safari iOSモバイルの 25 〜 35%
P1Chrome Androidモバイルの 50%+
P1Safari macOSデスクトップ 15%
P2Firefox デスクトップ3% だが互換性カナリアの役割
P3Edge デスクトップChrome とほぼ同等、企業環境限定
P3Samsung Internet韓国・中東モバイルシェア
P4Firefox Android余裕があるときのみ

Servo・LadyBird は 2026 年時点で一般サイトの互換性テスト対象ではない。それはエンジン側がサイトに合わせる段階で、サイトがエンジンに合わせる段階ではない。


5章 · 政治 — DOJ、DMA、そして Mozilla のミッションドリフト

5.1 DOJ vs Google — Chrome 分割は実現するか?

2024 年 8 月、米国連邦裁判所は Google が検索市場で — シャーマン法第 2 条に違反して — 独占を維持していると判決した。2025 年の救済段階で DOJ は次を勧告した:

  1. Chrome の売却 — Google が Chrome ブラウザ事業を分離して売却。
  2. 検索取引禁止 — Apple との — 年間 200 億ドル規模の — デフォルト検索取引を禁止。
  3. データ共有 — 検索インデックス・ランキングシグナルの一部を、一定条件で競合に共有。

Google は控訴し、2026 年 5 月時点で控訴裁判所段階で進行中。最終結果は早くても 2027 年と予想される。

もし Chrome 売却が強制されたら:

  • Chromium オープンソースガバナンスが揺らぐ。Google が運営費を出していた部分を、新しい所有者がどう扱うのか。
  • V8・Blink の発展速度は短期的に遅くなる可能性。
  • Microsoft Edge はすでに Chromium ベースのため影響は小さい。事実上の標準の影響力が一部 Microsoft 側へ移る可能性。
  • 多様性には逆説的に良い信号。単一主体の支配が緩む。

5.2 EU DMA — iOS WebKit 強制の終焉?

2024 年 3 月、EU の Digital Markets Act (DMA) が発効し、Apple は EU 限定で iOS 上での非 WebKit エンジンブラウザを許可しなければならなくなった。

2026 年の現状:

  • Chrome iOS の Blink ベース版が EU ユーザーに段階的に配信中。ただしメインアプリではなく別 SKU として配信され、ユーザーが自発的に選ぶ必要がある。
  • Firefox iOS の Gecko ベース版は 2025 年に試験運用、2026 年に EU で正式配信。
  • Apple は DMA 規定をできる限り厳しく解釈。WebKit スタート画面、JIT コンパイラ制約、データセキュリティモデルの違いなどで、非 WebKit エンジンの初期使用体験を意図的に荒く保っているという批判。
  • EU 圏外 (米国・アジア・日本など) は変化なし。米議会の類似法案は停滞中。

これは少なくとも EU 内ではエンジン多様性の小さな勝利。しかし実際のユーザーシェア変化は 2026 年時点で意味のある数字には到達していない。

5.3 Mozilla のミッションドリフト論争

Mozilla は事実上、非 Google・非 Apple のエンジンを維持する唯一のメジャー機関だ。しかし 2020 年代に入って次のパターンが繰り返され、批判が大きくなっている。

  • 2020 年解雇 — Servo チームを含む大規模削減。
  • 2022 年以降 AI・広告・プライバシーツールへの新事業強調 — Mozilla.ai 設立、AI 広告サービス Anonym を 2024 年に買収。
  • 2024 年追加解雇 (約 60 人) — 標準委員会参加の一部縮小。
  • 2026 年現在のフルタイム Gecko エンジンエンジニア — 2010 年代中盤の数百人から、高い1桁 / 低い2桁台にまで縮小したと推定。

支持側の立場: 「収入源を多角化する必要がある。Google 検索取引依存を減らさないと存続できない。」Mozilla の収入の 80%+ は Google とのデフォルト検索取引から来ている。この取引が DOJ 判決で禁止されかねない状況で、多角化は生存条件。

批判側の立場: 「エンジン投資がマイナスなのに AI に投資する余力があるのか? 『インターネットがすべての人のための公共財』をミッションとする団体が広告会社を買収するのは正しいのか?」

これは単純な是非ではなく、資源配分の難しい問いだ。しかし明確なのは: Gecko エンジンは一つの企業に依存し過ぎている


6章 · なぜ多様性が重要か — 単調な景観のリスク

「Chromium で十分」 — よくある反論だ。標準採用は速く、開発ツールは良く、オープンソース。本当に他のエンジンが必要なのか?

答え: 必要だ。理由をいくつか。

6.1 一企業が標準を定義したら、それは標準ではない

W3C・WHATWG 標準の策定で Blink が事実上の拒否権を持つ。Blink が実装していない機能は、実質的に標準ではないのと同じ。逆に Blink が始めれば、他のエンジンが追随する圧力がかかる。

これは IE 時代の繰り返しだ。1990 年代末に IE が 90% シェアだったとき、Microsoft が ActiveX・VBScript・HTC のような事実上標準ではない自社技術を標準のように押し出した。結果として、ウェブ全体が IE に縛られ、他のブラウザは壊れた。

いま Blink は — 意図的にそうしているわけではないが — 構造的にその位置にいる。良し悪しを超えて、それは危険だ。

6.2 広告・トラッキングモデルの単一化

Manifest V3 には合法的な理由がある。しかし結果的に広告ブロック拡張の機能を一部低下させた。これは Google の主要収益源が広告である事実と衝突せざるを得ない。

Gecko はシェアが小さくとも別の信号を発する。uBlock Origin が Firefox では Manifest V3 ではないより強力な API で動作する。それが信頼性の面での多様性の価値だ。

6.3 セキュリティの単一障害点

CVE 一つが Blink にあれば、Chrome・Edge・Brave・Arc・Electron アプリ全部に影響する。2022 年 Chromium の V8 0-day が発見されたとき、パッチ適用前に事実上デスクトップのほぼ全てのユーザーが露出した。

エンジン多様性はセキュリティの面で、まさに自然生態系の種の多様性と同じだ。一つの病原体に全員が同時に倒れない。

6.4 イノベーションは競争から

WebKit が Service Worker を遅れて受け入れたとき、Blink と Gecko が速く実装し、結局 Apple も追随した。Gecko の WebRender が合成効率を新しいレベルへと押し上げ、Blink が一部を取り入れた。競争がなければ、誰もが停滞する。


7章 · Servo と LadyBird がプロダクションに到達するために

それでは — 本当に — 新しいエンジンがメジャーになり得るのか? 二つのインディーエンジンを正直に評価しよう。

7.1 Servo

残っている作業:

  • サイト互換性 — 実際のウェブの 99% を処理するには無数のエッジケース。WPT 通過率が 78% から 95% へ — 最後の 17% が最も難しい。
  • DOM・CSS・JS の表面積をフルカバー。一部 API (WebRTC、WebAuthn、Service Worker など) 未実装。
  • 開発者ツール。
  • 拡張システム — または意図的に作らないという決断。
  • 資金。LFE 傘下にあるが、フルタイムエンジニアは一桁。

機会:

  • 組み込み優先戦略 — 自動車・キオスク・家電は一般ブラウザより サイト互換性要件が緩い。
  • Rust エコシステムの他のコンポーネントとの結合 — Tauri、他の組み込みフレームワーク。

現実的なタイムライン: デスクトップ一般ブラウザ = 5+年。組み込み一部採用 = 2027 〜 2028。

7.2 LadyBird

残っている作業:

  • アルファ版をリリース (2026 年 7 月目標)。その後サイト互換性・性能・安定性をすべて速やかに引き上げる必要。
  • WebGPU・WebRTC・メディアコーデック — インディーチームが直接作るには膨大な作業量。ライブラリ再利用戦略 — Skia・FFmpeg など — を検討中。
  • Windows・Android への移植。iOS は政策上難しい。
  • 資金の持続性。2024 年のシード資金で数年は運営できるが、その後は?

機会:

  • 真の意味での独立。広告・検索取引・VC 圧力なし。純粋にユーザー体験基準で決定。
  • 30 年ぶりの真の意味での新エンジンという象徴性・広報効果。
  • LadyBird コードベースが意図的にクリーン。寄与の参入障壁が低い。

現実的なタイムライン: アルファ = 2026 年 7 月。ベータ(一般使用可能、既知の制限あり) = 2027 〜 2028。一般ユーザーの日常利用 = 2028 〜 2030。

7.3 たとえ二つとも失敗しても

たとえ二つともメジャーシェアに到達しなくても意味は大きい。理由。

  • 標準委員会に新しい声 — インディーエンジン一つがいるという事実だけで議論はより慎重になる。
  • Chromium への圧力 — Chrome が単調な景観の唯一の選択肢ではないという社会的認識。
  • 次世代のための学校 — Servo の Rust・LadyBird の C++23 で新しいエンジニアが育つ。
  • 組み込み・特殊環境の代替 — 車載・キオスク・組み込みではライセンス・制御権の面でインディーエンジンが魅力的。

8章 · 実務者 — 何をすべきか

この記事を読むあなたがウェブ開発者なら、何を違う形でやるべきか。

8.1 マルチエンジンテストを CI に組み込む

GitHub Actions などの CI で Playwright が Chromium・WebKit・Firefox をすべて自動実行する。無料だ。言い訳がない。

# .github/workflows/test.yml (例 — コードブロック内のみ)
name: cross-browser-tests
on: [push, pull_request]
jobs:
  test:
    strategy:
      matrix:
        browser: [chromium, webkit, firefox]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install ${{ matrix.browser }} --with-deps
      - run: npx playwright test --project=${{ matrix.browser }}

8.2 機能利用は Baseline 基準で

web.dev/baseline または caniuse — どの機能が三つのエンジンすべてで安定採用されたかを確認。

Baseline 2024+ に入った機能は安全に使う。Baseline 未満はポリフィル / プログレッシブエンハンスメント、または使用保留。

8.3 Origin Trials は慎重に

Chromium の Origin Trials は、コードを新機能に依存させる。トライアル満了でその機能を使っていた全サイトが突然壊れる。可能なら使わない、もしくはポリフィル必須。

8.4 シェアの小さなエンジンも無視しない

Firefox が 3% だからと無視すると、一部のユーザーが一部の機能を使えなくなる。小さな労力で大きな差。

8.5 標準が優先

ベンダープレフィックス (-webkit--moz-) を使うときは標準版も必ず併記。サイトが特定エンジンに縛られるパターンを避ける。


エピローグ — 30 年ぶりの分岐点

ウェブエンジンの歴史を圧縮して見ると、分岐点はまれにしか来ない。1994 年 Netscape、2003 年 WebKit、2008 年 Chrome、2013 年 Blink — そして 2026 年に何らかの形で次のページが開かれつつある。

LadyBird のアルファ、Servo の復活、DOJ の Chrome 売却勧告、EU DMA の iOS エンジン強制解除、Mozilla のミッションドリフト — どれ一つとして即座に結果を生むわけではない。しかし累積すれば、2030 年代のウェブは 2020 年代とは違うように描かれ得る。

チェックリスト

  • 私たちのサイトは Chrome・Safari・Firefox で回帰なく動作するか?
  • Playwright または同等のツールで三つのエンジンの CI 自動テストを運用しているか?
  • Baseline 未満の機能はポリフィルまたはプログレッシブエンハンスメントで包んでいるか?
  • ベンダープレフィックスの隣に標準版を併記しているか?
  • Origin Trials にコードが依存していないか?
  • サイトの核機能が JavaScript なしでも動作するか?

アンチパターン

  • 「Chrome でのみテストする」 — 他のエンジンで知らぬ間に壊れている可能性。
  • 「user-agent で分岐処理」 — ほぼ常に未来で壊れる。
  • 「Service Worker があると仮定」 — Safari / iOS の微妙な差を無視。
  • 「うちのユーザー統計上 Firefox は小さいので無視」 — Firefox は互換性カナリア。
  • 「Manifest V3 拡張が Manifest V2 と同じ」 — 嘘。

次回予告

次回は、これらのエンジンを埋め込んでデスクトップアプリを作る — Electron・Tauri・WebView 比較を深く掘る予定。Chromium を丸ごとバンドルするか (Electron)、OS WebView を借りるか (Tauri)、新しい道を行くか (WebView2 / WKWebView 直接) — そしてそれぞれのセキュリティ・メモリ・バンドルサイズトレードオフ。


参考 / References