トップ AI オープンソースプロジェクトが PR 受付を停止する理由

GitHub がプルリクエスト（Pull Request）を発明して以来、約 18 年にわたりデフォルトで開放されてきました。しかし現在、トップクラスの AI ネイティブなオープンソースプロジェクトの一部では、より良い方法を見出したため、PR の受け付けを停止し始めています。

Flue や tldraw といったこれらのプロジェクトは、外部からのコントリビューターによる PR を受け付けていません。その理由の一つとして、提出されるコードの多くが AI によって生成されていることが挙げられます。代わりに、メンテナーたちは自社のエージェントを活用して PR の作成と管理を行っています。

また、多くのプロジェクトでコミュニティからの貢献を管理するための「ソフトウェアファクトリー」の導入が進んでいます。典型的な運用では、「チーム」として機能する複数のエージェントが、PR のトリアージ（選別）を行い、バグの場合は問題の再現を試み、修正や新機能の実装を行います。その後、レビューを経て最終的に人間がマージを行うという流れです。

Vercel が構築した AI SDK 向けのソフトウェアファクトリー

Vercel は最近、「AI SDK のためのソフトウェアファクトリーの構築」と題する記事を公開しました。同記事では、週に 2,000 万回以上の npm ダウンロードを誇るオープンソースプロジェクト「AI SDK」において、PR とイシューのバックログ管理のためにエージェントを導入した事例が紹介されています。このプロジェクトは、6 月末には「1,000 件を超えるオープンなイシューと約 800 のプルリクエスト」という膨大な数の課題を抱えていました。

Vercel はこれらの課題を解決するために、AI エージェントを活用するソフトウェアファクトリーを構築しました。

Vercel のシステムには複数のエージェントが存在し、それぞれが異なるタスクに特化しています。例えば、バグの再現を担当するエージェント、修正を適用するエージェント、そしてその修正を検証するエージェントなどが用意されています。

図：Vercel 提供（コメント：Latent Space）

Vercel がこのソフトウェアファクトリーを構築した主な理由の一つは、コミュニティメンバーが運用するエージェントよりも、自社のエージェントに作業を任せることに高い信頼を置いているからです。

「非常に特定のタスクに特化したエージェントがあり、そのプロンプトを最適化している場合、過去の履歴から特定カテゴリのバグ修正において極めて高い成功率を示すことが分かれば、その特定の構成に対して信頼が生まれます」と Vercel のエンジニア、ラルス・グラムメル氏は YouTube 動画で説明しています。

「オープンソースプロジェクトにおいては、コミュニティに依存するのではなく、自社のエージェントと設定を整備することを検討する価値があります。そうすることで、レビューにかかる時間を大幅に短縮できるからです」と彼は付け加えています。

図：AI SDK プロジェクトにおけるソフトウェアファクトリーのワークフロー例

グラムメル氏は、同システムのデプロイメントアーキテクチャも紹介しました。「UI があり、Web アプリがあり、基盤となる API があり、実行環境があり、サンドボックスもあります」と述べています。これらは GitHub と同期され、自動的に他のアクションがトリガーされます。ここで言及された UI は、カスタム作成されたものです。

Vercel のソフトウェアファクトリーのデプロイメントアーキテクチャ。図は Lars Grammel 氏によるものです。

このソフトウェアファクトリーを導入してからわずか 4 週間後、Vercel は「現在、マージされる PR の 25〜35% を自動生成しており、クローズされる課題の 70〜80% も処理している」と主張しています。

Astro の自動トリアージシステム

GitHub で 62,000 スターを獲得している Web フレームワーク「Astro」も、創設者の Fred Schott 氏が提唱する「ソフトウェアファクトリー」の概念を採用しました。

「過去 5 年間、私たちが対応できる速度よりも課題が流入し続ける状態でした」と Schott 氏は Latent Space に語っています。

しかし今、エージェントがトリアージ作業を担うことで、再びコントロールを取り戻しました。

「ここ半年で状況は劇的に変わりました」と彼は言います。「自動化によってこれらの課題を解決できるようになりました。トリアージや再現性の確認、そしてボットが提案する修正をユーザー自身が検証してもらうまでを処理し、私たちが目を通す前にそのプロセスを完了させるのです。」

Astro のファクトリーボットが実際に動作している様子

この取り組みの結果、オープンな課題（issues）の数は大幅に減少しただけでなく、Astro チームがコミュニティからの要望に対応する仕組みそのものが根本から変わりました。

「オープンソースに関わって 10 年以上になりますが、これほど劇的な変化を見たことはありません」と Schott は語ります。「毎週、何があっても優先順位をつける対象として課題を扱う。常に整理し続けるバックログとして扱うのではなく、そうして管理できるのは初めてです」

さらに、Astro の「自動トリアージ（自動仕分け）」システムは、Schott が新しいエージェントフレームワーク「Flue」の構築へと直接つながりました。

Flue は PR を受け付けないが、議論にはオープン

Schott は Flue において、PR に対するより過激なアプローチを試みています。Flue のコントリビューターガイドには、「私たちは物事のあり方を再考しようとしている」と明記されており、その目的の一つは「ドライブバイ AI スロップ PR（安易に提出された AI 生成の低品質なプルリクエスト）」を防ぐことにあります。

Schott が説明するところでは、Flue プロジェクトにおける外部からのすべてのプルリクエストは自動的にクローズされ、課題やディスカッションに変換されます。バグ報告や修正提案は課題として扱われ、機能追加のリクエストはディスカッションの形式に移行します。

Flue のコントリビューターガイドによると、現在ではエージェントが PR（プルリクエスト）の処理のほとんどを担えるようになっています。

「PR を提出しても、怒ったりはしません。むしろ、それを ISSUE やディスカッションとして扱い、そこから適切な貢献者を募る方法を模索します」

これは、外部からの依頼をマテイナーがレビューすべき作業として扱うのではなく、見込み顧客（リード）として捉えるような考え方です。コントリビューターガイドでは、チームの専門知識と「入手可能な最新 SOTA[State-of-the-Art] LLM」を組み合わせて活用し、次に何を優先して取り組むべきかを判断すると説明されています。

ISSUE やディスカッションで方針が決定されると、エージェントは「調査、設計、実装、そして初期レビュー」のために投入されます。

もしコードを書いているのがエージェントなら、外部からの PR は無意味になります

Flue と同様に、「ソース利用可能」とされる React 描画ツール tldraw（スター数約 50,000）も、外部からの PR を自動的にクローズする方針を採用しています。

プロジェクト作成者の Steve Ruiz 氏は今年 1 月にこの方針を発表し、5 ヶ月後に改めてその重要性を強調しました。彼はこれを「コーディング手法の変化（より多くの議論とエージェントの活用）、公開貢献に関する社会的慣行の変容、そしてコードセキュリティを取り巻く環境の変化」に対する明確な判断であると述べています。

Superlogical の共同創設者であり、Ghostty の生みの親である HashiCorp 元共同創設者のミッチェル・ハシモト氏は、さらに一歩先を行く考えを示しています。「将来は、大規模なオープンソースプロジェクトが貢献を完全に閉ざすようになる」と彼は考えています。

ルイス氏はこれに対し、「課題が十分に明確に定義されており、コードがエージェントによって書けるのであれば、人がコードを投稿する意義は薄れる」と応えています。

しかし、コミュニティはどうなるのでしょうか？

従来、オープンソースの世界では、プルリクエストのレビューは単にコードをチェックするためだけでなく、貢献者を教育し、将来のマaintainer として評価するために実施されてきました。AI SDK や Astro のようなプロジェクトがエージェントを活用してコードレビューや実装の多くを担うようになった場合、より積極的に参加したいコミュニティメンバーの立場はどうなるのでしょうか？

ショット氏はこれをリスクとして認識しています。

「それでもなお、『プロジェクトを狭めていくと、いつかあなたと私が休暇に行ってしまう——その時どうなるのか？』という穴が開いたままです。これはすべての問題を解決するものではありません」

しかし、PR の受け入れは拒否しつつも、新しい課題や議論の投稿は受け入れている Flue や tldraw という事実が、一つの解決策を示唆しているのかもしれません。つまり、お互いにコミュニケーションを深めることで、コミュニティメンバー同士がより深く理解し合い、信頼関係を築くことができるのです。これは同僚から学ぶ手段であると同時に、自分がマaintainer にふさわしい人材であることを証明する道にもなり得ます。

tldraw のイシュー（上図）が、プルリクエスト（下図）として取り込まれる例

コードに関しては、メンテナーが外部からの貢献を受け入れるよりも AI を活用する方が効率的だと判断される場合、tldraw の創設者であるスティーブ・ルイスが指摘するように、「コミュニティの貢献は、まだ価値がある領域——バグ報告、議論、多様な視点、そしてケア——に限定すべきだ」という考え方もあります。