Ladybirdの件、Hacker Newsで流れてきたとき「あーついにか」と思いながら原文読んだ。
LadybirdはBlink・WebKit・Geckoのコードを一切使わず、ゼロからブラウザエンジンを書くプロジェクトだ。Linuxとmacos向けの初回アルファ版を2026年内に出す予定で、普通に追いかけてたリポジトリだった。その開発チームが「今後は外部からのpublic PRは受け付けない」と発表した。方針転換時点で開かれているPRも全部閉じる、メールやIssueでパッチを送る抜け道も作らない、という結構ハードな決断だ。
創設者のAndreas Kling氏の説明がわかりやすかった。「数千行のコードを手で書くには相応の時間と知識が必要だった。それが貢献者の真剣さの代替指標になっていた。でもAIツールで見た目に本格的な変更を短時間で作れるようになった今、作業量はもう信頼の証明にならない」という話だ。
自分もレビューする立場として、これはリアルに刺さった。うちのチームは7人で、最近外部のコントリビューターと仕事することも増えてきた。Godotでも同じことが起きているらしく、AI生成と思われるPRが増えてコード本文だけでなく説明文まで明らかにAI生成で、コードベースの理解が浅いまま投げてくる事例がHacker Newsのコメント欄に上がっていた。「感謝されない」と反発するケースもあるとのこと。これ、想像するだけでかなりしんどい。
ブラウザエンジンは特にセキュリティ的にクリティカルで、巧妙に隠れた脆弱性が1個混入するだけで攻撃者に悪用される。Ladybirdが「責任の所在」を最優先にしたのは、そのコンテキストでは合理的な判断だと思う。
個人開発で公開してるライブラリは今のところスター数が少ないから外部PRはほぼこない。でもこれが数百スターになったとき、AI生成のPRが飛んでくる可能性は普通にある。今から方針を決めておいた方がいい気がしてきた。
tldrawも2026年1月に同じ理由で外部コントリビューターからのPRを一時クローズした。「不完全な説明」「コードベースへの理解不足」「投稿後のフォローアップ不足」が理由として挙げられていて、これはAIツールが生成したコードを理解しないままそのまま送ってくるパターンと完全に一致する。
自分がレビュアーとしてAI生成PRを受け取ったとき、何をチェックするかを整理しておこうと思った。
全部当てはまるPRは、コードの中身が良くても一回立ち止まって投稿者に質問を投げるようにしている。返答の質でだいたいわかる。
Ladybirdの判断で面白いのは「AIを使うな」という話ではない点だ。メンテナー自身はClaude CodeなどのAIツールを引き続き使うと明言している。問題は「外から届いた大量のコードを限られた時間でレビューするコスト」であって、「責任を持つメンテナーがAIで書いたコードを入れる」のは全く別の話という整理だ。
これ、チームのPRレビューポリシーにもそのまま使える考え方だと思う。AIで書いたコードを出すなではなく、そのコードに責任を持てる人間が出すかどうか、という基準に変えていく方向が現実的だ。
個人のOSSリポジトリにCONTRIBUTING.mdを追加する予定がずっとあったが、今回の件でやる気が出た。「AIツールで生成したコードを含む場合は、そのコードを自分で理解・説明できる状態にしてからPRを出すこと」という一文を入れるつもりだ。Ladybirdが全閉鎖という強い方針を取ったのに対して、自分はまず「説明責任」のラインだけ引く、という感じで。
コードの塊が持つ意味は2年前と変わった、というHacker Newsのコメントが一番しっくりきた。レビューの前提条件を更新しないといつまでも同じところでハマり続ける。
LadybirdはBlink・WebKit・Geckoのコードを一切使わず、ゼロからブラウザエンジンを書くプロジェクトだ。Linuxとmacos向けの初回アルファ版を2026年内に出す予定で、普通に追いかけてたリポジトリだった。その開発チームが「今後は外部からのpublic PRは受け付けない」と発表した。方針転換時点で開かれているPRも全部閉じる、メールやIssueでパッチを送る抜け道も作らない、という結構ハードな決断だ。
なぜそうなったか、という話
創設者のAndreas Kling氏の説明がわかりやすかった。「数千行のコードを手で書くには相応の時間と知識が必要だった。それが貢献者の真剣さの代替指標になっていた。でもAIツールで見た目に本格的な変更を短時間で作れるようになった今、作業量はもう信頼の証明にならない」という話だ。
自分もレビューする立場として、これはリアルに刺さった。うちのチームは7人で、最近外部のコントリビューターと仕事することも増えてきた。Godotでも同じことが起きているらしく、AI生成と思われるPRが増えてコード本文だけでなく説明文まで明らかにAI生成で、コードベースの理解が浅いまま投げてくる事例がHacker Newsのコメント欄に上がっていた。「感謝されない」と反発するケースもあるとのこと。これ、想像するだけでかなりしんどい。
ブラウザエンジンは特にセキュリティ的にクリティカルで、巧妙に隠れた脆弱性が1個混入するだけで攻撃者に悪用される。Ladybirdが「責任の所在」を最優先にしたのは、そのコンテキストでは合理的な判断だと思う。
自分のOSSとチームのコードレビューに置き換えてみた
個人開発で公開してるライブラリは今のところスター数が少ないから外部PRはほぼこない。でもこれが数百スターになったとき、AI生成のPRが飛んでくる可能性は普通にある。今から方針を決めておいた方がいい気がしてきた。
tldrawも2026年1月に同じ理由で外部コントリビューターからのPRを一時クローズした。「不完全な説明」「コードベースへの理解不足」「投稿後のフォローアップ不足」が理由として挙げられていて、これはAIツールが生成したコードを理解しないままそのまま送ってくるパターンと完全に一致する。
自分がレビュアーとしてAI生成PRを受け取ったとき、何をチェックするかを整理しておこうと思った。
- コミットメッセージとPR説明文のトーンが明らかに人間っぽくない
- 変更範囲が「ちょうどよすぎる」単一機能に限定されている
- 既存の命名規則やアーキテクチャの癖を無視した書き方になっている
- 投稿後に一切コメントへの反応がない
全部当てはまるPRは、コードの中身が良くても一回立ち止まって投稿者に質問を投げるようにしている。返答の質でだいたいわかる。
Ladybirdの判断で面白いのは「AIを使うな」という話ではない点だ。メンテナー自身はClaude CodeなどのAIツールを引き続き使うと明言している。問題は「外から届いた大量のコードを限られた時間でレビューするコスト」であって、「責任を持つメンテナーがAIで書いたコードを入れる」のは全く別の話という整理だ。
これ、チームのPRレビューポリシーにもそのまま使える考え方だと思う。AIで書いたコードを出すなではなく、そのコードに責任を持てる人間が出すかどうか、という基準に変えていく方向が現実的だ。
次に自分がやること
個人のOSSリポジトリにCONTRIBUTING.mdを追加する予定がずっとあったが、今回の件でやる気が出た。「AIツールで生成したコードを含む場合は、そのコードを自分で理解・説明できる状態にしてからPRを出すこと」という一文を入れるつもりだ。Ladybirdが全閉鎖という強い方針を取ったのに対して、自分はまず「説明責任」のラインだけ引く、という感じで。
コードの塊が持つ意味は2年前と変わった、というHacker Newsのコメントが一番しっくりきた。レビューの前提条件を更新しないといつまでも同じところでハマり続ける。