レディバードブラウザがRustを採用

2026年2月23日原文(ladybird.org)

概要

LadybirdはC++の代替として Rust の導入を決定最初のターゲットは LibJS （JavaScriptエンジン）の移植移植作業は 人間主導＋AIツール で短期間に完了移植後も 性能・互換性に一切の劣化なし 今後も C++とRustの共存体制 で段階的に移行予定

LadybirdのC++からRustへの移行決定

C++に代わるメモリ安全な言語 を長期間模索
Swift はC++との相互運用やApple以外のプラットフォーム対応で断念
Rust はシステムプログラミング向けのエコシステムが成熟
貢献者の多くがRust経験者 であることも後押し
FirefoxやChromiumもRust導入を進めており 業界の流れ に合致

Rust選定の理由と課題

2024年時点では C++流OOPとの相性の悪さ からRustを一度却下
Webプラットフォームのオブジェクトモデルは 1990年代的OOP が色濃く、Rustの所有権モデルと自然に合わない
しかし 安全性・エコシステムの成熟 を重視し、現実的な選択としてRustを再評価
保守性・安全性の向上 を最優先

LibJS（JavaScriptエンジン）のRust移植

最初のターゲットはLibJS （LadybirdのJavaScriptエンジン）
字句解析器・構文解析器・AST・バイトコード生成器 など独立性が高くテストカバレッジも十分
移植には Claude CodeやCodex などAIツールを活用
- 人間が 移植範囲や順序・Rustコードの設計 を決定
- 数百回の小さなプロンプトでAIを誘導しながら作業
移植後は 複数のAIモデルでコードレビュー を実施し品質確保

移植結果と検証

Rust版・C++版でバイト単位まで完全一致の出力 を達成
約 25,000行 のRustコードへの移植が 2週間で完了
- 手作業なら数ヶ月かかる規模
ASTやバイトコードの完全一致 を確認
テストスイート（test262, Ladybird回帰テスト）でリグレッションゼロ
JSベンチマークでも性能劣化なし
C++/Rust両パイプライン同時実行でWebブラウジング検証 も実施
コードは 「C++から翻訳された」雰囲気 を強く残す設計
- 互換性重視のため C++のレジスタ割当パターン等を模倣
- 正確性と互換性が最優先
- 将来的には Rustらしいリファクタリング も予定

今後の方針と開発体制

Rust移植はプロジェクトの主軸ではない
- エンジン開発は 引き続きC++が中心
- Rust移植は 長期的なサイドプロジェクト として進行
C++とRustの共存体制 を維持
- 明確な 相互運用境界 を設けて新旧コードが共存
- どの部分をどの順序で移植するかはコアチームが管理
移植作業は必ずコアチームと調整 し、無駄な作業を防止
Ladybirdの将来を見据えた最善の選択 との自信

まとめ

安全性・保守性・業界動向 を重視しRust導入を決断
移植作業はAIと人間の協働で効率化
C++との互換性維持を最優先
段階的な移行とチーム内調整の徹底
Ladybirdの未来を見据えた現実的な舵取り

Hackerたちの意見

面白いことに、編集されたタイトルには「AIの助けを借りて」が抜けてるね。

└

LLMを使ったコードベースの移行は、彼らにとってはかなり良いユースケースかもしれないね。面白いことに、著者はハンズオンのアプローチを提唱してる。「AIの助けを借りて」を追加すると、ほぼ必ず「開発者はAIを取り入れなきゃダメ！」と「社会は雑なもので壊されてる！」という議論に devolve しちゃうから、そんなことが起きない限り、編集されたタイトルについて文句は言わないよ。

└

たぶん、これはクラシックなHackerNewsのタイトル短縮アルゴリズムが働いてるだけだね。

└

新しいコードについては、逆の方向に進むべきだと思う。「AIなしで完了」とかね。ソフトウェア開発に携わっている古いおじさんとして、たくさんの友達がシニア開発者として働いてる。彼ら全員、俺を含めてAIを使ってるよ。俺もどんどんAIを使うようになってる。例えば、「クラスA、B、Cをこういう名前で作って、これを状態遷移図として使って流れを理解して、モジュールXYZで宣言された特定のヘルパーを使って」って感じで。コードをテストして、最適でないパターンや好ましくないパターンを見直して、変更をお願いする。数回の反復の後、コードは通常輝くようになる。最終結果は、念のためにいくつかのLLMと照らし合わせて確認するよ。

結果がイディオマティックなRustじゃないのは分かってるし、C++のパイプラインを引退することに慣れたら、もっとシンプルにできることがたくさんあるよ。そのクリーンアップは時間が経てば来るだろうね。間違ってたら教えてほしいんだけど、これらの2つの言語は知らないからさ。他の言語と同じように、イディオマティックなやり方でやると全然違うことになるかも。ここでの「クリーンアップ」はかなりの重労働を意味してるのかな？それとも、もう一度ゼロから完全に書き直すことを意味するのかな？開発を何年も続けたスタートアップが言語を切り替えるのは、普通は大きな赤信号だよね。「Xで書き直してる」っていう投稿は、いつも「閉鎖します」っていう前触れだったし。でも、彼らに幸運を祈るよ！

└

これは、Joel on Softwareが昔のブログ投稿で話してた有名な罠だね。書き直しをすると、基本的に他のすべてを止めてしまうことになる。古い方で機能開発を続けている間に、別の「タイガーチーム」が書き直しをしていると、実質的にこの2つのチームは競争状態になって、ポートは決して追いつかない可能性が高いよ。（相対速度によるけど）もしかしたら、彼らはこのLLM支援ツールを一気にやってしまって、その後あまり時間をかけずに続けられると思ってるのかもね。

└

開発を何年も続けたスタートアップが言語を切り替えるのは、普通は大きな赤信号だよね。スタートアップは、ここでは良い比較対象じゃないよ。彼らはソフトウェアプロジェクトとは違ったコードとの関係を持ってる。Linuxは何度も全スタックを書き直してきたし、PHPエンジンも少なくとも2回は完全に書き直されてる。musl libcは基本的にゼロから全コンポーネントを書き直して、後で統合されたんだ。

└

まさにその通り！しばらくはFirefoxを使い続けることにするよ…

└

この場合の緩和要因は、C++とRustの両方がマルチパラダイム言語であることだね。ほとんどのC++のパターンをRustで合理的に表現できるけど、最初からRustを書くときとはちょっと違うかもしれないね。

└

何週間もかけて（おそらく）動いているコードをポーティングするのはちょっと変だよね。

翻訳にはClaude CodeとCodexを使ったよ。これは人間が指示したもので、自動生成ではない。何を移植するか、どの順番でやるか、Rustのコードがどうあるべきかを決めたんだ。数百の小さなプロンプトを使って、エージェントを必要な方向に誘導した。初期の翻訳の後、いくつかのモデルにコードのミスや悪いパターンを分析させるために、複数回の対立的レビューを行った。 > 最初からの要件は、両方のパイプラインからの出力がバイト単位で同一であることだった。結果は約25,000行のRustで、全体の移植には約2週間かかった。この作業を手作業でやってたら、数ヶ月かかってたと思う。Rustのパーサーが生成したASTはC++のものと完全に同一で、Rustコンパイラーが生成したバイトコードもC++コンパイラーの出力と同じだって確認済み。全体でリグレッションはゼロだよ。これが正しいやり方だね。コーディングアシスタントは、特に既存のテストがあるときに、一つの言語から別の言語への移植が得意なんだ。

└

これが、嫌なことを言う人たちが何を言おうとも、私たちがClaudeを使う方法だよ。「ただ作る」ってわけじゃなくて、設計して、レビューして、洗練させて、テストして、作るんだ。

Hacker Newsで議論の続きを見る

ハクソク