Ladybird:非Chromiumブラウザプロジェクトの探求
Ladybirdは、Chromium・WebKit・Geckoのいずれの系譜にも属さず、ゼロから構築されたウェブブラウザエンジンです。Andreas KlingとChris Wanstrathが設立した501(c)(3)非営利団体、Ladybird Browser Initiativeによって開発されています。過去10年以上で初めて、フロントエンド開発者が注目に値するレベルの標準準拠度に達した、真に新しい独立ブラウザエンジンです。本記事では、「Ladybird」がHacker NewsやXでトレンドになった後に開発者が実際に抱く3つの疑問に答えます。すなわち、「これは本物か」「2026年のアルファ版は意味があるか」「自分がリリースするウェブに何か変化をもたらすか」という問いです。端的に言えば、答えはそれぞれ「はい」「おそらく」「まだ」ですが、注目すべきはその軌跡です。
重要なポイント
- Ladybirdは501(c)(3)非営利団体であるLadybird Browser Initiativeのもと、Andreas Kling氏が代表を務め、既存エンジンのフォークではなくゼロから構築されている。
- 現在のウェブはBlink・WebKit・Geckoの3つのエンジンで動いており、真に新しい独立エンジンが普及した最後の例は、Operaが2013年にBlinkへ移行する以前にさかのぼる。
- 2026年4月のニュースレター時点で、LadybirdはWeb Platform Testのサブテスト2,067,263件のパスと、インポートされたtest262 JavaScript準拠サブテストにおける97.8%のパス率を報告している。
- 2026年2月、チームはLibJSフロントエンドパイプライン(レキサー、パーサー、AST、スコープコレクター、バイトコードジェネレーター)のRust再実装をデフォルト有効化した状態でランディングした。
- 2026年にLinuxおよびmacOS向けのパブリックアルファを予定しているが、Ladybirdはプレアルファソフトウェアであり、日常的なブラウジングには適していない。
Ladybirdとは何か、誰が開発しているのか
Ladybirdは、Blink・WebKit・Geckoのいずれともコードを共有しない独立したブラウザエンジンであり、登録済みの501(c)(3)非営利団体であるLadybird Browser Initiativeによって運営されています。プロジェクトの組織ページによると、現在のリーダーシップはAndreas Kling氏(代表)、Tim Flynn氏(事務局長)、Mike Shaver氏(会計)で構成されています。このプロジェクトはKling氏の趣味のオペレーティングシステムであるSerenityOS内のHTMLビューアとして始まり、その後スタンドアロンのクロスプラットフォームブラウザとして独立しました。
このガバナンス構造は、機能リストよりも「本物かどうか」を示す強力なシグナルです。Ladybirdは広告収入やデバイス販売ではなく、スポンサーシップと寄付によって資金調達されています。GitHubの共同創業者であるChris Wanstrath氏がInitiativeを共同設立し、彼の家族が100万ドルを寄付することをawesomekling.github.ioで発表しました。ladybird.orgに掲載されているスポンサーリスト(2026年4月取得)には、プラチナスポンサーとしてFUTO・Shopify・Cloudflare、ゴールドスポンサーとしてHuman Rights Foundation・Proton・Guillermo Rauch氏・Ohne Maklerなどが名を連ねています。プロジェクトの成長に伴いスポンサーティアは変化するため、最新情報はサイトで直接確認してください。
懐疑的な方にとって最も重要な点はここです。具体的な法人名、役員名、企業スポンサー名、そして検証可能な資金提供の誓約があります。Ladybirdは週末のプロトタイプではありません。
新しいブラウザエンジンが稀な理由
Discover how at OpenReplay.com.
ウェブはGoogleのBlink・AppleのWebKit・MozillaのGeckoという3つのエンジンで動いており、真に新しいエンジンが登場することは稀です。参入コストが非常に大きいためです。新しい独立エンジンが意味のある普及を遂げた最後の例は、OperaがPrestoを搭載していた時代にさかのぼります。それは2013年にOperaがChromiumベースのブラウザに移行したことで終わりを告げ、MicrosoftのEdgeHTMLからの移行は2020年のChromiumベースEdgeの安定版リリースで完結しました。現在、ウェブはこれら3つのレンダリングエンジンに大きく依存しており、StatCounterによるとBlinkがブラウザ使用率の大部分を占めています。
新しいエンジンの構築が極めて困難な理由は、数万件の互換性テストをパスし、HTML・CSS・JavaScript・グラフィックス・セキュリティ・アクセシビリティ・パフォーマンスをウェブスケールで正確に処理しなければならないからです。その基準となるのが、クロスベンダーの準拠プロジェクトであるWeb Platform Tests(WPT)スイートです。WPTには数百万の個別サブテストが含まれており、実際のサイトが依存する動作(既存エンジンが数十年にわたって出荷してきた非公式の挙動を含む)を正確に再現することが、独立エンジンを歴史的に困難にしてきた作業です。そうした挙動に依存するサイトを壊してしまう厳格な標準実装は、商業的に唯一重要なテスト、すなわち「既存のウェブを正しくレンダリングすること」に失敗します。
これがLadybirdを注目に値するものにしている背景です。Ladybirdは機能で競争しているのではありません。過去10年の統合によってほぼ乗り越えがたくなった準拠性のハードルをクリアしようとしているのです。
Ladybirdのアーキテクチャの内側
Ladybirdのマルチプロセスアーキテクチャは、レンダリング・画像デコード・ネットワークリクエストをプロセス間通信で連携する独立したサンドボックスプロセスに分離しています。プロジェクトのドキュメントとソースレイアウトによると、エンジンはメインUIプロセスと複数のヘルパープロセスに分かれています。WebContentがレンダリングとスクリプト実行を担当し、ImageDecoderが画像をデコードし、RequestServerがネットワークリクエストを処理します。各ウェブコンテンツプロセスはサンドボックス化されています。
この分離の目的は、プロセス境界による封じ込めです。歴史的にメモリ破壊バグの一般的な原因であった信頼できない画像データのデコードは、レンダリングプロセスから隔離されたImageDecoderで行われます。ネットワーク処理はページコンテンツから隔離されたRequestServerに存在します。このプロセス分離自体が検証可能な設計上の主張であり、その境界こそがLadybirdのセキュリティモデルが存在する場所です。これは過去15年間にメインストリームのブラウザが採用したマルチプロセス設計をモデルにしています。
レンダリングとスクリプト処理の作業は、プラットフォームの各レイヤーを担当する一連のライブラリに分割されています。
| ライブラリ | 役割 |
|---|---|
| LibWeb | HTML/CSSのパース、レイアウト、レンダリング |
| LibJS | JavaScript:レキサー、パーサー、AST、バイトコード生成、インタープリター |
| LibWasm | WebAssemblyのパースと実行 |
| LibGfx | 2Dグラフィックスプリミティブと画像フォーマット |
LibJSは特筆に値します。なぜなら、V8やJavaScriptCoreのような既存のJavaScriptエンジンの薄いラッパーではなく、独自のレキサー・パーサー・AST・バイトコードジェネレーター・バイトコードインタープリターを備えた完全な実装だからです。この詳細が次のセクションで重要になります。なぜなら、そのパイプラインのフロントエンドこそが、プロジェクトの最も重要な最近のエンジニアリング作業がランディングした場所だからです。
言語戦略:C++コア、Rust移行進行中
LadybirdのコアはモダンなC++で書かれていますが、チームはパフォーマンスとセキュリティに敏感なコンポーネントをRustに移行し始めています。2026年2月、プロジェクトはLibJSフロントエンドパイプライン(レキサー・パーサー・AST・スコープコレクター・バイトコードジェネレーターを含む)のRust再実装をデフォルト有効化した状態でランディングしました。これは2026年2月のニュースレターで報告されており、プロジェクトにおける最新かつ最も技術的に重要な進展であり、以前の報道では触れられていません。
その動機は、ブラウザエンジンにおけるRust採用の標準的なものです。信頼できない入力をパースするコードパスにおけるメモリ安全性であり、脆弱性の一クラス全体を削減するためです。JavaScriptパーサーはページロードのたびに任意の攻撃者制御のテキストを取り込むため、言語レベルでのメモリ安全性の保証が特に有効なコンポーネントです。また、明確に定義されたインターオペラビリティ境界により、RustフロントエンドがC++インタープリターにバイトコードを渡すことができ、全面的な書き直しなしに段階的な移行が可能です。
これはプロジェクトにとってC++以外の最初の実験ではありませんでした。Ladybirdはかつてコードベースの一部にSwiftを試み、後にすべてのSwiftコードを削除してからRustに移行することを決定しました。「Swiftを試している」から「Rustフロントエンドパイプラインをデフォルトでリリース」への転換は、エンジニアリングの成熟を示すマーカーです。プロジェクトは今や、C++を永続的な前提として扱うのではなく、意図的に言語の決定を行い、また覆すことができています。
標準準拠:Ladybirdの現状
2026年4月時点で、Ladybirdは2026年4月のニュースレターによると、Web Platform Testのサブテスト2,067,263件のパス(前期の2,003,537件から増加)と、インポートされたtest262 JavaScript準拠サブテスト53,207件中52,045件における97.8%のパス率を報告しています。これらの数値は、Ladybirdがデモではなく本格的なエンジンであることを示す最も明確な証拠です。
ただし、これらの数値を正確に理解するためのいくつかの注意点があります。WPTサブテスト数は絶対値であり、スイート全体に対するパーセンテージではありません。他のエンジンとの総合的なWPTパス率のランキングを確認するには、取得日を明記した上でwpt.fyiを直接参照してください。スイートのサイズとブラウザごとの結果は継続的に変化するためです。test262の数値は、スイート全体ではなくインポートされたサブテストに限定されています。Ladybirdはサブセットをインポートし、それに対してレポートしています。これらの注意点を踏まえても、全体像としては、JavaScriptの実装が実行する準拠テストの大多数をパスし、ウェブプラットフォームの実装が数百万件のWPTサブテストをクリアしているということです。これは、エンジンが実際のウェブをある程度レンダリングできるしきい値をはるかに超えています。
ロードマップと正直な注意点
公式サイトによると、Ladybirdのホームページでは2026年にLinuxおよびmacOS向けのパブリックアルファを目標としています。ベータ版と安定版のリリース日はそれぞれ2027年と2028年として二次的な報道で流通していますが、現時点ではladybird.orgから検証できないため、確約ではなく目安として扱うべきです。プレアルファのタイムラインはずれ込むものであり、ブラウザエンジンの準拠作業は本質的に終わりのないものです。そのため、2026年のアルファ以降の日付は約束ではなく目標として理解してください。
プラットフォームサポートは完成したブラウザよりも狭いですが、「Linuxのみ」よりは広い範囲をカバーしています。アルファ版はLinuxとmacOSを対象としており、Windowsサポートは活発に開発中です。現在Windowsを使用している開発者がエンジンを試したい場合は、WSL2ベースのビルドワークフローがすでに存在します。本稿執筆時点での実用的な状態は、ビルドして実行できるものの、日常的なブラウジングには準備が整っていないソフトウェアです。機能の欠如や粗削りな部分が予想されます。
Ladybirdがフロントエンド開発者にとって重要な理由
4つ目の独立したブラウザエンジンがフロントエンド開発者にとって重要なのは、新しいシェアを獲得するブラウザとしてではなく、準拠性への圧力ポイントとしてです。WPTを厳格にパスし、実際のサイトが壊れた場合に仕様の問題を提起するプロジェクトは、2〜3エンジンの寡占状態では生まれない説明責任を生み出します。その価値は市場シェアではなく、構造的なものです。
Ladybirdの非営利構造には守るべき広告収入もなく、守るべきデバイスエコシステムもないため、W3C仕様から商業的な目的のために逸脱する構造的なインセンティブを持たない唯一のエンドユーザー向けフルブラウザを目指すエンジンです。元々Mozillaから生まれ、現在はLinux FoundationのもとにあるServoも非商業的な姿勢を共有していますが、現在はフルブラウザ製品ではなく組み込み可能なエンジンとして開発されています。この違いは具体的に理解できます。FLoCはGoogleのPrivacy Sandboxの提案であり後にTopicsに置き換えられたこと、Intelligent Tracking PreventionはAppleのプラットフォーム優先事項を反映したWebKitの機能であることを思い出してください。どちらも親組織の商業的文脈を反映しており、そのような文脈を持たないエンジンはその圧力を完全に排除します。
エンジン固有のレンダリングやスクリプト処理の挙動の違い(CSSレイアウトのエッジケース、仕様の境界でのJavaScriptの動作の違い)は、単一のエンジンに対するローカルテストではなく、多様なブラウザ環境での本番トラフィックで表面化するバグのクラスです。クロスブラウザの問題のセッションリプレイは、開発者自身のマシンでは再現しなかった障害を頻繁に明らかにします。同じ準拠スイートをパスする独立した実装が増えることで、そうした挙動の違いが潜む余地が狭まります。
Ladybirdをフォローして試す方法
Ladybirdはプレアルファソフトウェアであり、LinuxとmacOSでビルドして実行できます。追跡するための信頼できる方法は、プロジェクト自身のチャンネルです。二次的な報道は数週間で古くなります。ladybird.org/newsフィードは、準拠性の数値・アーキテクチャの変更・マイルストーンの更新を含む定期的なニュースレターを公開しており、本記事のすべてのステータス情報の一次ソースです。ソースはGitHubのLadybirdBrowser/ladybirdリポジトリにあります。
ビルドして実行するには、サードパーティのガイドではなく公式ドキュメントの最新のビルド手順に従ってください。これほど速く進むプロジェクトでは、依存関係のリストとビルドコマンドが頻繁に変わります。クローンして依存関係をインストールした後、プロジェクトのビルドと実行のエントリポイントはMetaスクリプトです。
git clone https://github.com/LadybirdBrowser/ladybird.git
cd ladybird
./Meta/ladybird.py run
./Meta/ladybird.py runの形式は、古いチュートリアルに見られるladybird.shコマンドに取って代わっています。公式ドキュメント以外で見つけた特定の依存関係バージョンは疑ってかかってください。開始前に現在のツールチェーン要件についてビルド手順を確認してください。
Ladybirdは、本物の、適切に管理された、ゼロから構築されたブラウザエンジンであり、本格的な準拠性のハードルをクリアしています。今日のChrome代替としては実用的ではありませんが、過去10年以上でウェブが目にした中で最も信頼できるエンジンの多様性への試みです。具体的な次のアクションは、ladybird.org/newsをブックマークして、各ニュースレターの準拠性の数値を確認することです。それらの数値の軌跡は、単一のスナップショットよりも、これが自分のリリースするウェブに変化をもたらすかどうかについて多くを語ってくれるでしょう。
よくある質問
LinuxとmacOSでLadybirdをビルドして実行することはできますが、信頼性の高いクロスブラウザテストにはまだ適していないプレアルファソフトウェアです。機能が欠けており動作も粗削りなため、パスまたは失敗の結果は本番環境での準備状況をほとんど示しません。現時点では、自分のサイトをテストするよりも、各ニュースレターでプロジェクトのWPTサブテスト数を追跡する方が有益です。自分のサイトのテストが意味を持つのは、2026年のパブリックアルファがリリースされてからです。
いいえ。LadybirdはChromium・WebKit・Geckoのいずれともコードを共有せず、ゼロから書かれています。レンダリングライブラリLibWeb・JavaScriptエンジンLibJS・WebAssemblyエンジンLibWasm・グラフィックスライブラリLibGfxはすべて、V8や既存エンジンのラッパーではなくオリジナルの実装です。プロジェクトはSerenityOS内のHTMLビューアとして始まり、その後スタンドアロンのクロスプラットフォームブラウザになりました。既存エンジンからアーキテクチャ上のインスピレーションを得てはいますが、そのソースコードは再利用していません。
2026年4月のニュースレターで報告された2,067,263という数値は、Web Platform Testのパスしたサブテストの絶対数であり、スイート全体に対するパーセンテージではありません。テストが追加されるにつれてスイートの総サイズは継続的に変化するため、分母なしに絶対数をランキングに変換することはできません。Blink・WebKit・Geckoとの総合的なパス率の比較については、wpt.fyi を直接確認し、取得日を記録してください。結果は日々変化するためです。
Rustへの移行は、信頼できない入力をパースするコードパスを対象としており、メモリ安全性の保証により脆弱性の一クラスを防ぎます。2026年2月のニュースレターでは、LibJSフロントエンドパイプライン(レキサー・パーサー・AST・スコープコレクター・バイトコードジェネレーター)がRustで再実装され、デフォルトで有効化されたことが報告されています。JavaScriptパーサーはページロードのたびに攻撃者制御のテキストを取り込むためです。明確に定義されたインターオペラビリティ境界により、RustフロントエンドがC++インタープリターにバイトコードを渡すことができ、全面的な書き直しなしに段階的な移行が可能です。
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.