オープンソースブラウザ「Ladybird」が外部コード受け入れを停止、AI時代の開発体制へ転換

独立系ブラウザ「Ladybird」の開発チームが、今後は外部からの公開プルリクエストを受け付けず、コード変更をプロジェクトのメンテナーだけが導入する方針に切り替えると発表しました。

Changing How We Develop Ladybird - Ladybird
https://ladybird.org/posts/changing-how-we-develop-ladybird/

Ladybirdは既存ブラウザの派生版ではなく、新しいブラウザエンジンをゼロから作ることを掲げるオープンソースのプロジェクトです。Google Chromeで使われるBlink、Safariで使われるWebKit、Firefoxで使われるGeckoといった既存エンジンのコードを使わず、ウェブ標準に基づく独立したエンジンを作ることを目指しています。記事作成時点ではLinuxとmacOS向けの初回アルファ版を2026年内に公開する計画です。

オープンソースソフトウェアでは、外部の開発者が不具合を見つけて修正案をプルリクエストとして送り、メンテナーが内容を確認して取り込む流れが広く使われています。例えば、画面表示のずれを直す小さな修正や、対応していなかったウェブ標準の一部を実装する変更などを外部の協力者が送ることで、プロジェクトは少しずつ改善されます。Ladybirdも長年にわたり外部からの貢献を受けてきたとのこと。

しかし、AIコーディングツールの普及により「大きなパッチを送ってきた」という事実だけでは、かつてほど投稿者の努力や善意を判断できなくなったとLadybirdの創設者であるアンドレアス・クリング氏は説明しています。手作業で数千行のコードを書くには相応の時間と知識が必要でしたが、AIを使えば見た目には本格的な変更を短時間で作成できます。LadybirdチームはAIツールを毎日使っていると明言しており、問題視しているのはAIそのものではなく「コードがどのように作られたか分かりにくくなった状況で、誰が責任を負うのか」という点です。

エンジニアが集うニュース共有サイト「Hacker News」のコメント欄でも、別の大規模オープンソースプロジェクト「Godot」でAI生成のプルリクエストが増えているという体験談が投稿されています。コード本文だけでなく説明文までAI生成と思われるプルリクエストが送られ、プロジェクトの方針に反するためメンテナーが注意すると、一部の投稿者が「せっかく貢献したのに感謝されない」と反発することもあるとのこと。

AI生成コードをめぐって外部からのプルリクエストを制限する動きは、Ladybirdだけに限られません。2026年1月には、ウェブベースのドローツール「tldraw」も、AIツールだけで生成されたコードを含むプルリクエストが増え、不完全な説明やコードベースへの理解不足、投稿後のフォローアップ不足につながっているとして、外部コントリビューターからのプルリクエストを一時的に閉じる方針を明らかにしています。

AIのせいでオープンソースの「tldraw」が外部コントリビューターからのプルリクエストをクローズ - GIGAZINE

開発は動くコードを取り込めば終わりではありません。新しいコードが既存の設計に合っているか、将来のリファクタリングに耐えられるか、ほかの機能と正しく連携するか、数年後に別の開発者が読んで理解できるかまで確認する必要があります。特にLadybirdはブラウザというインターネット全体から信頼できない入力を受け取るソフトウェアであり、巧妙に隠された脆弱(ぜいじゃく)性が1つ混入するだけでも攻撃者に悪用される可能性があります。

クリング氏は、オープンソースの世界では長年、作業そのものを通じて信頼が積み上がってきたと説明しています。小さな修正を送り、レビューに応じ、責任を持って変更を保守し、時間をかけてプロジェクトに関わり続けることで、メンテナーと外部協力者の間に信頼関係が生まれるという考え方です。しかし、AIによって「真面目な貢献に見える作業」を安く速く作れるようになったことで、作業量は信頼の代替指標にはならなくなりました。

そのためLadybirdでは今後、公開プルリクエストを受け付けず、コードベースに入る変更はプロジェクトのメンテナーだけが導入することになります。方針転換時点で開かれている公開プルリクエストもすべて閉じる方針とのこと。また、メール、Issue、コメント、フォークなどを使ってパッチを送る別経路も設けない方針で、外部からコードを送って上流に入れてもらう仕組み全体を閉じるというかなり踏み込んだ変更となっています。

一方で、Ladybirdがオープンソースではなくなるわけではありません。ソースコードは今後もオープンソースライセンスの下で公開され、外部の協力も引き続き重要だとされています。受け付けられる協力の形として「分かりやすいバグ報告」「不具合を最小限の手順で再現できる形にしたリダクション」「ウェブサイトの動作テスト」「ウェブ標準に関する議論」「設計についての議論」「セキュリティ報告」「技術的なフィードバック」などが挙げられています。コードそのものを送るのではなく、メンテナーが責任を持ってコード化できる材料を外部から提供する形というわけです。

Hacker Newsでは「バグを見つけて修正方法まで分かっているにもかかわらず具体的なパッチを伝えられないなら、メンテナーが同じ修正作業をやり直すことになる」として、「修正案を受け取る選択肢まで閉じるのは非効率だ」という指摘も出ています。また、「AIによってオープンソースプロジェクトが新しいメンテナーを見つけたり育てたりする機会を失うのは残念だ」という声もあります。

元Chrome開発者を名乗るユーザーは、Chromium、Gecko、WebKitの方が少なくとも外部コードの受け入れという面ではLadybirdより開かれて見えると述べ、大規模ブラウザベンダーが外部貢献を支えるために投じているリソースも評価されるべきだとコメントしました。

さらにオープンソースの文化について、誰でも自由に変更案を持ち寄る雑多な市場のような「バザール(市場)」型の開発から、限られた人が内部で設計と実装を進める「カテドラル(大聖堂)」型の開発へ戻るように見えるという指摘も行われています。

一方で、多くのプルリクエストがAIで書かれているなら、メンテナー自身がClaude CodeなどのAIツールを使えばよいとして、「コードの塊」が持つ意味は2年前とは完全に変わったと理解を示すコメントも投稿されています。

Ladybirdを応援しているというユーザーからは「プルリクエストを閉じることでコードだけでなく、アイデアや多くの人の目による確認といった目に見えにくい貢献まで失われるのではないか」という不安も寄せられました。

Ladybirdのメンテナーたちは今後もAIを使用するとのこと。つまり新方針はAI利用を避けるためのものではなく、外部から届いた大量のコードを限られた時間で見極めるよりも、コードを取り込む責任を負うメンテナーが変更を導入する体制へ切り替えるためのものというわけです。

Ladybirdは「実際のユーザーにブラウザを届ける準備を進めており、開発プロセスも責任に見合ったものにする必要がある」と述べています。初のアルファ版に向けてコードの入口を狭くする決定は、開発速度よりも責任の所在を優先する段階に入ったことを示しているとのことです。