Ladybirdは、Chromium・WebKit・Geckoのいずれからも派生せず、Web標準への準拠を掲げてゼロから書き起こされている独立ブラウザエンジンOSSです。2024年7月には米国の501(c)(3)非営利団体「Ladybird Browser Initiative」として法人化され、2026年のAlpha(Linux/macOS)を目標に開発が続けられています(公式サイト ladybird.org)。
一方で、Ladybirdは公式README上でも「pre-alpha段階であり、開発者向けの用途にのみ適する」と明示されているプロジェクトです(GitHub README)。ChromiumやFirefoxの代替として業務で常用できる段階には至っておらず、Web標準への準拠度も向上を続けている段階にあります。
そのため、Ladybirdについて検索するエンジニアの関心は、「明日使うツール」というよりも「これから起こりうるブラウザエンジン地殻変動を、技術動向としてどこまで追うか」の意思決定にあると考えられます。Chromiumの一強状態が続く中で、非営利・OSS・完全独立という3条件をすべて満たすエンジンはLadybirdだけであり、その位置づけを整理する価値は小さくありません。
本記事では、公開されているGitHubリポジトリ、公式サイト、公式ドキュメント、および複数の二次情報を突き合わせながら、Ladybirdの現在地とロードマップ、非営利ガバナンスの構造、2026年に進行しているC++からRustへの大規模ポーティング、Servo・Flowなど類似ブラウザエンジンとの棲み分け、そして「業務プロジェクトから見たウォッチ観点」までを整理します。動作検証やインストール手順の紹介は本記事の範囲外とし、あくまでドキュメントベースで「追う価値があるか」を判断できる材料の提示に絞ります。
Ladybirdとは何か
Ladybirdは、GitHubリポジトリ LadybirdBrowser/ladybird で開発されている独立ブラウザエンジンOSSです。プロジェクトのミッションは「Chromium・WebKit・Geckoのいずれのエンジンからも派生せず、Web標準に準拠したエンジンをゼロから書き起こす」ことにあります。
プロジェクト概要と基本スペック
対象リポジトリのメタデータは以下のとおりです(本記事執筆時点のgh api /repos/LadybirdBrowser/ladybird取得値に基づきます)。
項目 | 値 |
|---|---|
リポジトリ | LadybirdBrowser/ladybird |
説明 | Truly independent web browser |
主要言語 | C++(Rust化が進行中) |
ライセンス | BSD-2-Clause |
スター数 | 65,779 |
フォーク数 | 3,133 |
archived | false |
fork | false |
disabled | false |
可視性 | public |
最終push | 2026-08-21T20:37:02Z |
archived・fork・disabledのいずれもfalseであり、公開されたオリジナルリポジトリとして活発に更新されていることが確認できます。ライセンスはBSD-2-Clauseで、README冒頭には「Ladybird is a truly independent web browser, using a novel engine based on web standards.」との自己定義が置かれています(GitHub README)。
同じREADMEの上部にはIMPORTANTブロックとして「Ladybird is in a pre-alpha state, and only suitable for use by developers.」との但し書きも明示されており、一般利用向けではないことが繰り返し強調されています。この位置づけは、以降で解説するロードマップやRust化のスケジュールとも整合します。
「独立ブラウザエンジン」という位置づけ
現在アクティブな独立ブラウザエンジンは、ざっくり整理すると次の6種類です。
- Gecko(Firefox)
- WebKit(Safari)
- Blink(Chromium/Chrome/Edge)
- Servo(Rustベース、Linux Foundation傘下)
- Flow(Ekioh社の商用プロプライエタリ、組込機器向け)
- Ladybird(非営利OSS、フルブラウザ志向)
このうち「非営利」「OSS」「ゼロから書き起こし」「フルブラウザを志向」の4条件をすべて満たすのは、現時点でLadybirdのみとされています(Ladybird & Independent Browser Engines – Frontend Masters)。GeckoやWebKit、Blinkがいずれも大企業の事業戦略と密接に結びついているのに対し、Ladybirdは「利益相反から距離を取ったブラウザエンジン」という独自のポジションを狙っています。
SerenityOSからの独立経緯
Ladybirdの起源は、Andreas Klingが個人開発する趣味OSプロジェクトSerenityOSの中に組み込まれていたHTMLビューワーにあります。当初はSerenityOS上でのみ動くツールでしたが、Web標準実装の完成度が高まるにつれ、独立したクロスプラットフォームブラウザとして分離される形でLadybirdプロジェクトとして再構成されました。この経緯は、後述するコアライブラリの多くがLib*という命名規則でSerenityOS由来の資産を受け継いでいることにも表れています。
アーキテクチャとエンジン構成
Ladybirdは、モダンブラウザで一般化しているマルチプロセスアーキテクチャを採用しています。実装レベルではSerenityOS由来のコアライブラリ群を土台としつつ、ブラウザに固有な機能(DOM/レンダリング/JavaScript)はLibWeb・LibJSといった専用ライブラリに切り出されています。
マルチプロセスアーキテクチャの狙い
Ladybirdは概ね次のようなプロセス構成を取ります。
- Main UIプロセス
- WebContentレンダラー(タブごとにサンドボックス化)
- ImageDecoderプロセス
- RequestServerプロセス
Webコンテンツのレンダリングを独立プロセスに分離することで、レンダラーで発生した不具合や脆弱性の影響範囲をタブ単位に閉じ込める設計は、Chromium・Firefox・WebKitと同じ発想です。画像デコードやHTTPリクエスト処理といったパースリスクの高い処理を別プロセスに追い出す構成もまた、モダンブラウザで一般化している選択と言えます。この構成情報は、READMEのアーキテクチャ節に記載されています(GitHub README)。
LibWeb / LibJS などのコアライブラリ群
Ladybirdは、多数のLib*ライブラリを組み合わせて構築されています。主なものを整理すると次のとおりです。
ライブラリ | 用途 |
|---|---|
LibWeb | Webレンダリングエンジン(DOM/CSS/レイアウト) |
LibJS | JavaScriptエンジン |
LibWasm | WebAssembly実装 |
LibCrypto / LibTLS | 暗号処理・TLS |
LibHTTP | HTTP/1.1クライアント |
LibGfx | 2Dグラフィックス・画像デコード |
LibUnicode | Unicode/ロケール処理 |
LibMedia | 音声・動画再生 |
LibCore | イベントループ・OS抽象化 |
LibIPC | プロセス間通信 |
これらのライブラリの多くはSerenityOSから継承されており、Ladybirdはブラウザ固有の機能追加とWeb標準準拠の詰めに集中できる設計です。近年ではLibJSのフロントエンドがRustへ書き換えられるなど、コアライブラリ内部の実装言語も段階的に置き換わっています(詳細はのちほど扱います)。
対応OSとビルド要件
対応OSと主なビルド要件は、BuildInstructionsLadybird.md にまとめられています。要点だけ抜粋すると次のとおりです。
- 対応OS: Linux/macOS/Windows(WSL2経由)/その他*nix
- コンパイラ: GCC 14以上/Clang 21以上/Xcode 15以上(C++23対応必須)
- ビルドシステム: CMake 3.30以上
- UIフレームワーク: Qt 6.9以上
- Rustツールチェーン(rustup経由)
- Python 3.7以上、nasm、ninja、autoconf、automake、libtool、pkg-config、ccacheなど
Windowsのネイティブビルドはあくまで実験的な位置づけで、MinGW/MSYS2は非対応です。「開発者向けpre-alpha」という前提を踏まえると、コンパイラ・ツールチェーンの要件が比較的新しめに設定されている点も、実運用ブラウザというより「最新の標準に寄せていく研究開発プロジェクト」に近い性格を示していると読めます。
なお、本記事はドキュメントベースの解説を目的としており、実際のビルドや起動確認は行っていません。手元で動かす際の詳細は、必ず上記の公式ビルドドキュメントを参照してください。
非営利ガバナンスと資金源
Ladybirdの独自性は、コードや設計だけでなく、それを開発する組織構造にも及びます。2024年7月1日、Ladybirdは米国の501(c)(3)非営利公益法人「Ladybird Browser Initiative」として設立され、企業の広告事業や商業戦略から距離を取った運営体制が敷かれました。
501(c)(3)非営利化の背景
Ladybird Browser Initiativeの発足は、公式サイトの Ladybird Browser Initiative 発足発表 に詳細が記されています。発表では、主要ブラウザエンジンの大半が実質的にGoogleの広告事業に依存している現状への問題意識と、それに対して「Web標準に忠実で、利益相反から自由なブラウザ」を提供したいというミッションが示されています。
発起メンバーは、SerenityOSおよびLadybirdの創始者Andreas Kling、そしてGitHubの共同創業者Chris Wanstrathです。Chris WanstrathはInitiativeのSecretary & Treasurerを務め、一家からのUSD 1 millionの初期寄付も行われました。加えて、Shopifyから初回スポンサーとしてUSD 100,000が拠出された点も併記されています。
主要スポンサーと利益相反回避のガバナンス
スポンサー構成については、Platinum級にFUTO、Shopify、Cloudflareが名を連ねています。CloudflareのスポンサーシップはメディアでLadybird支援の一例として紹介されました(Cloudflareスポンサーシップの解説記事 - Linuxiac)。Shopifyのケースも、Klingのブログ上で歓迎メッセージとして共有されています(Welcoming Shopify as a Ladybird Sponsor - Andreas Kling)。
ここで重要なのは、公式発表内で「スポンサーは技術ロードマップや製品方向性への発言権を持たない」と明記されている点です。営利企業のスポンサーを受け入れつつも、開発方針への介入は行わせないという線引きが、非営利ガバナンスの中核に据えられています。
ランウェイと持続可能性の考え方
公式発表では、常時18ヶ月分程度のランウェイ(運転資金)を維持する方針も示されています。OSSプロジェクトの多くが「開発者個人の善意」と「単発の寄付」で綱渡り的に運営されがちなのに対し、Ladybirdは組織体としての持続可能性を明示的にゴールに据えている点が特徴的です。
技術動向として追うエンジニアの視点から見ると、この「資金源とガバナンスの独立性」は、「単発の技術デモで終わらず、長期にわたって開発が続く見立てが立つプロジェクトか」を判定する材料になります。スポンサー企業の顔ぶれと寄付の枠組みは、いずれも公式サイトから追跡できます。
開発状況とロードマップ
「今使えるのか」「いつ使えるようになるのか」は、初見エンジニアが最も気にするポイントです。ここでは公式サイトと関連メディアで示されているロードマップと、標準準拠状況・現時点の制約を整理します。
Alpha/Beta/Stableの各マイルストーン
現在公表されているマイルストーンは次のとおりです。
フェーズ | 予定時期 | 対象 |
|---|---|---|
Alpha | 2026年 | Linux/macOS向け、開発者・アーリーアダプター |
Beta | 2027年 | 同上、より広いテスターへ拡大 |
Stable | 2028年 | 一般ユーザー向け |
Windowsサポート | デスクトップ完成後 | ネイティブサポート |
モバイル | デスクトップ成熟後 | 未定 |
このスケジュールは公式サイト ladybird.org のロードマップと、Servoとの比較解説記事 Servo vs Ladybird - LibreNews の両方で確認できます。Windowsとモバイルはデスクトップ実装の後回しであり、業務クライアント向けの動作検証環境として「まずWindowsで」というシナリオはしばらく成立しません。
直近の実装トピックとしては、公式ニュースレター This Month in Ladybird - October 2025 において、プライベートブラウジングモード、フルユーザープロファイル、WebAudioなどの機能追加が段階的に進んでいることが報告されています。Alphaに向けて、日常的なブラウザ利用を支える基本機能が順次揃えられている局面です。
Web標準準拠度の現在地(WPT 88%・90%閾値突破)
Web標準準拠度については、Web Platform Tests(WPT)のパス率が指標としてよく参照されます。LibreNewsの比較記事によると、LadybirdのWPTパス率は約88%、絶対値では約206万件がパスしていると紹介されています(Servo vs Ladybird - LibreNews)。Acid3テストは満点であり、基礎的なCSS・DOM実装が正確に動くことが確認されている状態です(Ladybird Browser Nears Alpha - byteiota)。
さらに2025年10月には、Andreas Klingが公式ニュースレター This Month in Ladybird - October 2025 上で、Appleがサードパーティエンジンに要求する基準として知られる「90%閾値」を突破したことを公表しました。iOS上での代替エンジンとして参照されうる水準に到達した点は、単なるWPT数値の推移以上に象徴的な意味を持つマイルストーンと言えます。
一方で、Chromium系ブラウザのWPTパス率はさらに高い水準にあり、Ladybirdはあくまで「主要エンジンとの差を詰めつつある段階」に位置します。日々のWeb体験を任せるにはまだ隔たりがあり、この定量指標の推移こそが、Ladybirdをウォッチする際の主要な判断軸のひとつになります。
現時点の制約(Windowsネイティブ未対応・ブラウザ拡張機能未対応)
技術動向として追う際に押さえておきたい現時点の制約は次のとおりです。
- ネイティブWindows対応はデスクトップ完成後にずれ込み、当面はWSL2経由の実験ビルドが中心
- 拡張機能(Chrome/Firefox拡張)はサポート対象外
- pre-alpha段階のため、任意のサイトの再現テストや業務用のクロスブラウザ検証には利用できない
これらの制約は、READMEの「pre-alpha」注記およびBuildInstructionsLadybird.md、および前掲のメディア記事から読み取れます。ロードマップと現在地のギャップを踏まえると、「Chromeの代替」ではなく「Web標準実装のリファレンス」としての価値をどう見積もるかが、Ladybirdを追う際の実質的な論点になります。
2026年のRust化とAI活用による大規模ポーティング
Ladybirdをめぐる2026年最大のニュースは、C++からRustへの本格的な移行と、それをAI支援で高速化した実績です。この移行は単なる言語切り替えではなく、「大規模C++コードベースのRust化」というテーマにおける実装事例としても注目されています。
Rust移行のタイムライン
2026年に入ってからのRust化の流れは、複数のメディア記事で追うことができます。
- 2026年2月: LibJSのフロントエンドパイプライン(lexer/parser/AST/scope collector/bytecode generator)を約25,000行のRustコードで再実装し、既定で有効化。実装期間は約2週間で、Anthropic製のClaude CodeやOpenAI製のCodex等のAI支援ツールと人間レビューを組み合わせて進められたと報じられています(Ladybird Browser Just Ported C++ Code to Rust in 2 Weeks Th…)。
- 2026年4月: Rustがコードベース全体で必須依存に格上げ。
- 2026年7月: セレクタマッチング、計算済みスタイル、カスケード、アニメーション、
calc()評価、レイアウトツリー構築、全レイアウトフォーマッティングコンテキストがC++からRustへ移行(Ladybird Browser Goes Full Rust: UA Spoofing Chrome 2026 - …、Ladybird Browser Nears Alpha - byteiota)。
repo-meta上の主要言語がC++と表示されている一方で、実装の中枢部分はスタイル計算・レイアウト・JSフロントエンドを中心にRustへ組み替えが進んでいる状態と読めます。
AI支援ポーティングの進め方と品質担保
前掲のIt's FOSSの記事および関連速報によると、LadybirdチームはAIコーディング支援ツールを「機械的な変換工程」に用いつつ、既存の大規模テストスイート(52,898件のテストと12,461件のリグレッションテストが言及されています)で回帰を捕捉し、加えて人間のレビュアーが最終判断を行う体制で移植を進めたとされています。約25,000行のLibJSフロントエンドを2週間で書き換えられた背景には、この「AI支援 × テスト網 × 人間レビュー」の三点セットがあります。
ここで注目しておきたいのは、AI支援を単独で使うのではなく、既存のテスト網と人間レビューを前提としたパイプラインに組み込んでいる点です。プロダクションコードのAI移植を検討している開発チームにとって、この構成は品質を担保しながらAI活用を進める一つの参考パターンとして解釈できます。
「AI移植の実務ヒント」としての含意
Ladybirdの事例そのものを自社プロジェクトに直接持ち込めるわけではありませんが、以下のような論点はAI活用の議論に持ち帰りやすい材料と言えます。
- 大規模移植の対象は、テストで振る舞いを固定できる範囲に絞る(LibJSフロントエンド=入出力が明確な部分から着手)
- AIによるコード生成は、既存のリグレッションテストとレビュアーの間に挟むことで、単体のAI出力への依存度を下げる
- 完全移行までのステップを段階分割し、「既定で有効化」までを一区切りにする
具体的な数字(25,000行/2週間/テスト件数)はいずれも報道ベースの情報であり、公式リポジトリ上のリリースノートやコミット履歴で裏取りする余地は残ります。技術ブログとして扱う際にも、二次情報からの引用である旨を明示したうえで参照するのが妥当な扱いになります。
Servo・Flowなど類似ブラウザエンジンとの違い
「独立ブラウザエンジン」という文脈でLadybirdと並置されやすいのが、Rust製のServoと、英Ekioh社の商用プロプライエタリエンジンFlowです。ここでは3者の違いを整理し、Ladybirdを追う際の位置づけを明確にします。
Servoとの違い(フルブラウザ vs エンジン単体)
Servoは、2012年にMozillaの研究プロジェクトとして始まり、現在はLinux Foundation傘下で開発が続けられているRust製のブラウザエンジンです。特徴は、メモリ安全性・並行処理・GPUアクセラレーションを重視し、埋め込み用途を意識している点にあります。
一方でLadybirdは、エンドユーザー向けのフルブラウザ(UIを含むアプリケーション)を目指しており、そもそもの対象範囲が異なります。標準準拠度の比較としては、LadybirdのWPTパス率が約88%、Servoが約76%と紹介されており(Servo vs Ladybird - LibreNews、および関連するHacker Newsスレッド)、Ladybirdの標準準拠が一歩先行している格好です。Acid3スコアも、Ladybirdが満点、Servoが83/100と差があります。
開発言語の観点でも、Servoは当初からRustオリジンであるのに対し、Ladybirdは前述のとおりC++で始まり2026年に入ってRust化が本格化しているという時間軸の違いがあります。「Rustブラウザ」というくくりで一緒くたに語られがちですが、Servoは「Rustネイティブなエンジン単体」、Ladybirdは「Rust化しつつあるフルブラウザ」と整理すると混同を避けやすくなります。
Flowとの違い(OSS vs 商用組込特化)
Flow(Ekioh Flow)は、英国Ekioh社が開発する独立ブラウザエンジンで、WPTパス率は約88%と、Ladybirdと拮抗する水準まで到達しています。主用途は組込機器・スマートTV向けであり、汎用デスクトップブラウザを狙うLadybirdとは対象領域が明確に異なります(Ladybird & Independent Browser Engines – Frontend Masters)。
ライセンス面でも、Flowは商用プロプライエタリ、LadybirdはBSD-2-Clauseのオープンソースと対極的です。「独立ブラウザエンジンの選択肢」という括りでは同じ棚に並びますが、Flowを検討する場面(組込機器向けのライセンス契約が前提)と、Ladybirdを検討する場面(Web標準実装のリファレンスとしての参照や、OSSコミュニティの動向ウォッチ)は交わりにくいと考えられます。
独立ブラウザエンジン6種の位置関係マップ
前述の6種を、開発体制と主用途、および参考としてのWPTパス率の軸で並べ直すと次のような整理になります。
エンジン | 開発体制 | 主用途 | ライセンス | WPTパス率(参考) |
|---|---|---|---|---|
Gecko | Mozilla | Firefox(デスクトップ/モバイル) | MPL | 高水準(主要商用エンジン) |
WebKit | Apple主導 | Safari/iOS WebView | LGPL / BSD | 高水準(主要商用エンジン) |
Blink | Google主導 | Chromium/Chrome/Edge | BSD等 | 約97%(Chrome) |
Servo | Linux Foundation傘下 | 埋め込み向けエンジン | MPL | 約76% |
Flow | Ekioh社(商用) | 組込機器・スマートTV | プロプライエタリ | 約88% |
Ladybird | 501(c)(3)非営利OSS | 汎用デスクトップブラウザ | BSD-2-Clause | 約88%(Apple 90%閾値突破) |
「非営利 × OSS × ゼロから書き起こし × フルブラウザ」の4条件をすべて満たすのはLadybirdだけです。この位置づけは、単に「新しいブラウザ候補」と見るよりも、「Chromium一強の状況に対するOSSからの対抗軸」として捉えたほうが実態に近いと考えられます。
業務プロジェクトから見たLadybirdウォッチの意味
ここまでの整理を踏まえ、業務プロジェクトの視点から「今Ladybirdをどう扱うか」「どんな観点でウォッチすると価値があるか」を短く整理します。
今業務で採用すべきかの現時点判断
pre-alpha段階かつ主要商用エンジンとのWPTパス率の差が残る現状では、Ladybirdを次のような用途に採用することは現実的ではありません。
- 業務クライアントに配布する既定ブラウザ
- Webアプリのクロスブラウザ検証環境(Chrome/Firefox/Safariの代替)
- 顧客向けアプリケーションに組み込むWebView
一方で、次のような使い方は「観察・学習」のレベルで検討し得ます。
- Web標準の実装リファレンスとしてソースコードを参照する
- ブラウザエンジンの内部構造(マルチプロセス・LibWeb/LibJS)を学ぶ教材として読む
- 大規模C++からRustへの移植事例として、コミット履歴と関連ブログを追う
ウォッチする場合の具体的なチェックポイント
技術動向として追う場合、次のような観点をチェックしておくと、他プロジェクトへの示唆が得やすくなります。
- Rust化の進行率と対象範囲(スタイル・レイアウト・JS・ネットワーキング)
- Web Platform Testsのパス率推移(現在約88%からの伸び)
- Alpha/Betaリリース時の対応OS・機能セット
- スポンサー構成の変化(新規参入・脱退・寄付規模)
- コミュニティのアクティビティ(GitHub上のIssue・PR動向)
これらは、いずれもGitHubリポジトリと公式サイトのladybird.org、および月次で更新される公式ニュースレターを継続的に眺めていれば追跡できる指標です。
2026〜2028の注目イベント
現時点で公表されているロードマップから、次の3イベントは特に注目に値します。
- 2026年: Alpha(Linux/macOS)リリース
- 2027年: Beta移行と対応機能の拡大
- 2028年: Stableリリースと一般ユーザー向けアナウンス
Alphaリリースが計画通りに達成できるか、Alpha時点でのWPTパス率がどこまで伸びているかは、その後のBeta/Stableの現実味を判断する最初のマイルストーンになります。「今業務では採用しないが、Alphaリリースが出たら再評価する」という判断は、多くのチームにとって妥当な落としどころと言えるでしょう。
まとめ
Ladybirdは、Chromium・WebKit・Geckoのいずれからも派生せず、501(c)(3)非営利団体Ladybird Browser Initiativeが開発する独立ブラウザエンジンOSSです。ライセンスはBSD-2-Clause、リポジトリはarchived=false / fork=falseのオリジナルで、pre-alpha段階ながら活発に更新が続いています。
要点を最後にまとめておきます。
- 独立性: Chromium/WebKit/Geckoに依存しない、ゼロから書き起こしのエンジン
- ガバナンス: 501(c)(3)非営利公益法人、スポンサーはロードマップに介入しない設計、常時18ヶ月ランウェイを目標
- Rust化: 2026年2月のLibJSフロントエンドを皮切りに、4月のRust必須化、7月のスタイル・レイアウトのRust化へと進行
- ロードマップ: 2026年Alpha(Linux/macOS)/2027年Beta/2028年Stable、Windows・モバイルはデスクトップ完成後
- 標準準拠: WPTパス率 約88%(絶対値 約206万件)、Acid3満点、2025年10月にApple基準の90%閾値突破
- 類似エンジンとの棲み分け: Servo(Rustネイティブなエンジン単体、WPT約76%)/Flow(商用組込特化、WPT約88%)とは目的も対象も異なる
初見のエンジニアにとってのLadybirdは、「今日から業務で使うブラウザ」ではなく、「Chromium一強状態に対する非営利OSSからの対抗軸」として、Alphaリリースまでの数年を継続的にウォッチする対象と位置づけるのが妥当と考えられます。判断材料としては、GitHubリポジトリ、公式サイトのladybird.org、月次公開のThis Month in Ladybird、そしてビルド要件と実装状況を示すBuildInstructionsLadybird.mdを定期的に参照するのが出発点になります。
関連情報:Webフロントエンド/ブラウザ関連の開発相談
自社サービスのブラウザ対応方針の整理、Web標準対応の実装レビュー、あるいはOSS技術を採用した開発体制の検討をご検討中の方は、お問い合わせフォームからご相談ください。技術選定の段階からご一緒することが可能です。



