9月2日、Latent Spaceが「PRs NOT Welcome: How Top AI Open Source Projects Are Managing Thousands of Contributors」と題した記事を公開した。この記事では、主要なAIネイティブOSSプロジェクトがコミュニティからのPull Requestを拒否し、独自のAIエージェントによる「ソフトウェアファクトリー」でコントリビューション管理を置き換えつつある実態について詳しく紹介されている。

PRは「もう要らない」——OSSの貢献モデルが静かに変わりつつある

GitHubが2008年に開設され、Pull Request（PR）という形でのOSS貢献が広く普及してから約18年。OSSへの貢献といえば「PRを送る」のが当たり前だったが、その前提が崩れ始めている。

※なお「Pull Requestの発明」についての補足をしておく。PRという概念自体はGit文化に以前から存在していたが、GitHub上でのプルリクエストとして広く普及したのはGitHub開設（2008年）以降のことであり、本稿では「GitHubでの普及から約18年」という意味合いで用いている。

Astroのサブプロジェクトとして開発されたエージェントフレームワークFlue（詳細は後述）や、ホワイトボードツールのtldraw（GitHub Stars: 5万）といったAIネイティブなOSSプロジェクトが、外部コントリビューターからのPRを原則として受け付けない方針に転換した。理由の一つは、送られてくるPRの多くがAI生成であること。そしてもう一つは、メンテナー自身のエージェントに任せた方が早く、質も高いという判断だ。

ただし、これらのプロジェクトはIssueやDiscussionによるコミュニティの関与を引き続き歓迎しており、「コントリビューションを完全に閉鎖した」わけではない。正確には「コードを送る形式のコントリビューションを制限し、議論を起点とするモデルに転換した」と理解するのが適切だ。

Vercelの「ソフトウェアファクトリー」——PRとIssueのバックログを一掃

この変化を象徴するのが、Vercelが公開した「Building a software factory for AI SDK」だ。

VercelのAI SDKは週2,000万回以上のnpmダウンロードを誇る大規模OSSだが、2025年6月末時点でオープンIssueが1,000件超、PRが約800件という積み上がったバックログを抱えていた。そこでVercelが導入したのが、複数のエージェントを組み合わせた「ソフトウェアファクトリー」だ。

システムは役割別の複数エージェントで構成されている。

• バグ再現エージェント：報告されたバグを実際に再現する
• 修正適用エージェント：修正を実装する
• レビューエージェント：修正内容を検査する

最終的に人間がマージを承認するが、それ以前の工程はほぼエージェントが完結させる。アーキテクチャとしては、カスタムUI・WebアプリAPI・実行スペース・サンドボックスがGitHubと同期し、アクションを自動トリガーする構成だ。エージェントが実行する環境はサンドボックスに隔離されており、外部から送られてきた任意のコードをそのままホスト環境で動かすリスクを避ける設計になっている点も注目に値する。

VercelエンジニアのLars Grammelはこう説明している。

「特定のエージェント設定が過去に一定カテゴリのバグ修正で高い成功率を示してきたなら、そのエージェント設定に対して信頼が生まれる。OSSプロジェクトにとっては、コミュニティを無条件に信頼するよりも、自分たちのエージェントを持つことを検討する価値がある。レビューにかかる時間を実際に削減できる。」

導入からわずか4週間で、このソフトウェアファクトリーはマージされるPRの25〜35%を生成し、Issueの70〜80%をクローズするまでになったとVercelは報告している。

Astroの転換——「10年以上OSSに関わってきて、こんな経験は初めてだ」

GitHubスター6万2,000を持つWebフレームワークAstroも同様のアプローチを採用した。

作者のFred Schottによれば、5年間にわたって「Issueが処理できる速度を上回るペースで積み上がり続ける」状態が続いていた。しかしエージェントによるトリアージ（優先度付け）・再現・修正提案の自動化を導入した結果、状況は一変した。

「OSSに10年以上関わってきて、こんな経験は初めてだ。Issueを毎週必ず優先度付けして処理できるものとして扱えるようになった。以前はひたすらバックログを削り続けるだけだった。」— Fred Schott

Astroのシステムでは、ボットが修正案を提案し、ユーザーがその修正を確認してからメンテナーが確認するフローになっている。メンテナーが見る前に、すでにユーザーの検証が済んでいる状態だ。この「ユーザー検証済み→メンテナー承認」というフローは、外部PRのレビューコストを削減しつつ、修正の信頼性をボットだけに委ねない設計として機能している。

「PRを閉じる」という選択——FlueとtldrawのアプローチFlue

このAstroの取り組みが直接の契機となり、Schottは新しいエージェントフレームワークFlueを開発した。FlueはAstroのサブプロジェクトとしてwithastro organization配下で開発されているが、Astro本体とは独立したツールであり、他のOSSプロジェクトが導入することも想定した汎用的な設計になっている。

Flueでは、外部からのPRはすべて自動的にクローズされ、IssueまたはDiscussionに変換される。バグ報告と修正提案はIssueへ、機能要望はDiscussionへ。コードを書いて送るのではなく、まず議論する、という設計だ。つまりコントリビューションの入口がPRからIssue・Discussionに一本化され、その先のコード生成はエージェントが担う構造になっている。

Flueのコントリビューターガイドには「Drive-by AI slop PRs（使い捨てのAI生成PRスパム）」を防ぐためと明記されている。

tldrawも1月に同様の方針を発表し、5ヶ月後に改めて方針を確認した。作者のSteve Ruizは「コーディングの仕方の変化（より多くの議論、より多くのエージェント）、公開コントリビューションの社会的慣行の変化、コードセキュリティを取り巻く環境の変化への対応として下した意思決定」と説明している。

HashiCorpの共同創業者でGhosttyの作者としても知られるMitchell Hashimotoは、さらに踏み込んで「大規模OSSプロジェクトはコントリビューションを完全にクローズする方向に向かう」との見方を示している。Ruizもこれに同意し、「Issueの内容が十分に仕様化されており、エージェントがコードを書けるなら、人間にコントリビューションしてもらう意味は薄れる」と応じた。

コミュニティの育成はどうなるか

ただし、この流れには未解決の問題がある。従来のOSSにおいてPRレビューは、コードの品質担保だけでなく、次世代メンテナーを発掘・育成する場でもあった。エージェントがその役割を担い始めると、コミュニティメンバーが深く関与する経路が失われかねない。コードレビューを通じてプロジェクトの設計思想やコーディング規約を学び、段階的に信頼を積み上げてメンテナーになる——という従来の経路が、PRを閉じることで事実上消滅するリスクがある。

Schott自身もこのリスクを認めている。

「プロジェクトを絞り込み続ければ、ある時点で自分たちが休暇に入ったとき何が起きるか。この問題は完全には解決されていない。」

FlueもtldrawもPRは閉じるがIssueとDiscussionは開いたままにしている点は、一つの回答かもしれない。PRを送る前に議論する文化に戻すことで、メンバーが互いに知り合い、信頼関係を築き、将来のメンテナー候補として自分を示す場が生まれる、という考え方だ。

tldrawのRuizがブログで述べたように、「コミュニティの貢献が依然として重要な場所——バグ報告、議論、視点の提供、ケア——に限定する方が良い」という方向性がここには見える。OSSの「開かれた貢献」という理念を守りながら、AIが生み出す大量の低品質PRという新しい問題にどう対処するか。その答えはまだ模索の途中にある。

詳細はPRs NOT Welcome: How Top AI Open Source Projects Are Managing Thousands of Contributorsを参照していただきたい。