
- Vercel AI SDKはエージェントがマージPRの25〜35%を作成し、issueの70〜80%を閉鎖
- Astroは自動トリアージでissue処理を効率化し、Flueは外部PRを自動でissue化
- Flueとtldrawは外部PRを全面拒否、代わりに議論や報告での参加を促す
PR閉鎖の背景
GitHubのプルリクエスト(PR)は、18年間デフォルトで開かれた参加経路として機能してきた。しかし最近のAIネイティブなオープンソースプロジェクトの中には、外部からのPRを一切受け付けないところが出始めている。理由の一つは、外部から送られるPRの多くがAI生成で、品質のばらつきが大きいためだ。その代わりに、メンテナー自身が用意したAIエージェントを使ってPRを作成・管理する「ソフトウェアファクトリー」方式が登場している。
Vercelのソフトウェアファクトリー
Vercelは2026年、AI SDK向けに「ソフトウェアファクトリー」を構築したと発表した。AI SDKは毎週2,000万以上のnpmダウンロードがあり、6月末時点で1,000件以上のissueと約800件のPRが未処理でたまっていた。このバックログを解消するため、バグの再現、修正の適用、修正のレビューなど、役割ごとに特化した複数のエージェントを導入した。
VercelのエンジニアであるLars Grammel氏は、自社で最適化したエージェントとプロンプトの方が、コミュニティメンバーが動かすエージェントよりも信頼できると説明している。導入4週間後、マージするPRの25〜35%がエージェントによる作成で、issueの70〜80%がクローズされるようになった。
AstroとFlueの取り組み
AstroはGitHubで62,000スターを獲得しているWebフレームワークで、創設者のFred Schott氏は「ソフトウェアファクトリーの考え方を取り入れた」と話す。従来はissueが処理速度を上回って積み上がっていたが、エージェントによる自動トリアージを導入してから状況が変わった。バグの再現や修正案の検証をエージェントが行い、人間のメンテナーは最終確認に集中できるようになったという。
この経験からSchott氏は、新しいエージェントフレームワーク「Flue」を開発した。Flueは外部からのPRを自動的に閉じ、内容をissueやdiscussionに変換する方針を取る。これは「Drive-by AI slop PRs」と呼ばれる、いわゆる場当たり的なAI生成PRを防ぐ狙いがある。
tldrawの全面拒否
tldrawも同様の判断を下している。React製の描画ツールで、GitHubスター数は50,000。プロジェクト創設者のSteve Ruiz氏は1月に外部PRを自動で閉じる方針を発表し、5か月後に改めてその考えを強調した。その背景には、エージェントによる開発への移行やコードセキュリティの変化があるという。
また、HashiCorp共同創業者でGhostty作者のMitchell Hashimoto氏は「大規模オープンソースプロジェクトはいずれ貢献を完全に閉じるようになる」と予測している。Ruiz氏も「issueが十分に明確なら、エージェントがコードを書ける時代に、人間がコードをコントリビュートする意味は薄れる」と応じている。
コミュニティへの影響
ただし、この流れはコミュニティ育成というオープンソースの伝統と衝突する。従来のPRレビューは、コードの品質確認だけでなく、新規貢献者を育て、将来のメンテナーを見極める役割を担ってきた。Schott氏は、プロジェクトの維持をすべて自動化すると、メンテナーが不在のときに誰も継続できないリスクを指摘する。
一方で、FlueやtldrawのようにPRは閉じてもissueやdiscussionは受け付ける方式は、コミュニティの役割を「報告、議論、視点、ケア」といった領域に限定するという考え方だ。コードはエージェントが書き、人間は対話と意思決定に注力する形が広がる可能性がある。
| 項目 | 従来のPR方式 | ソフトウェアファクトリー方式 |
|---|---|---|
| 外部からのPRの扱い | 受け付けてレビューする | プロジェクトによっては閉じてissue化する |
| レビューの主体 | 人間のメンテナー | エージェントが一次レビューし、人間が最終マージ |
| コミュニティ育成 | コードレビューを通じて貢献者を育てる | 議論や報告など限定的な場に限定する傾向 |
For open-source projects, it's worth considering having your own agents and your own setup, and not necessarily trusting the community, because it can actually cut down your time to review.
オープンソースプロジェクトにとって、自前のエージェントと環境を持ち、必ずしもコミュニティを信頼しないことを検討する価値はあります。実際にレビュー時間を短縮できるからです。
今後の見通し
今回紹介したVercel AI SDK、Astro、Flue、tldrawの事例は、オープンソース開発の分岐点を示している。今後は、Mitchell Hashimoto氏が予測するように、大規模プロジェクトが外部からのコード貢献を完全に閉じる動きがさらに広がる可能性がある。ただし、コミュニティの維持やメンテナーの育成という課題は残っており、この方式が長期的にプロジェクトの健全性を保てるかは検証が必要だ。次に注目すべきは、ソフトウェアファクトリーを導入したプロジェクトの持続可能性や、外部貢献者の満足度に関するデータが公表されるかである。また、エージェントの品質がどのように維持・評価されるのかも判断材料になる。
日本の開発者・IT企業にとっての意味
日本のIT企業や開発者にとって、この流れはOSSへの関わり方を再考する必要があることを意味する。自社が採用しているOSSプロジェクトが外部PRを閉じる方針に転じた場合、これまでコードで貢献していた開発者は、issueやdiscussionでの参加へ切り替えを迫られる。また、自社でOSSを運営する側にとっては、AIエージェントを活用したソフトウェアファクトリーがメンテナンス負荷を減らす選択肢になる。ただし、エージェントの品質保証とコミュニティの活性化をどう両立するかが課題となる。特に、PRを閉じる方式は一部のコントリビューターの意欲を削ぐ可能性があり、参加のハードルを下げる仕組みと組み合わせることが重要だ。
気になる点
- VercelのAI SDKでエージェントが実際に作ったPRはどれくらいあるのか?
- Vercelの発表によると、ソフトウェアファクトリー導入から4週間後、マージされるPRの25〜35%がエージェントによって作成され、全issueの70〜80%がクローズされたとされる。全てのPRがエージェント製というわけではなく、人間のメンテナーがレビューしてマージしている。
- FlueやtldrawにPRを送ったらどうなるのか?
- 外部からのPRは自動的にクローズされ、内容に応じてissueやdiscussionとして作り直される。バグ報告や修正提案はissueに、機能リクエストはdiscussionに変換される。送信者に否定的な意図はなく、参加の窓口を整理するのが目的だ。
- Astroの自動トリアージでは、ユーザーは修正をどう確認するのか?
- Astroでは、ボットが修正案を提案し、ユーザーが実際にその修正を検証してからメンテナーが確認する、という流れに変わった。人間のメンテナーが最初に見る前に、ユーザー側で検証が済むという。
用語解説
- ソフトウェアファクトリー
- AIエージェントのチームがissueのトリアージから修正、レビューまでを担当し、人間は最終マージを行う開発方式。
- トリアージ
- 報告されたissueの優先度を判断し、対応が必要かどうかを分類する作業。AIエージェントで自動化される。
- ドライブバイPR
- 深い関与なしに、軽い気持ちで送られる場当たり的なPR。AI生成のコードが増えたことで問題視されている。
- プルリクエスト(PR)
- GitHub上でコードの変更を提案する仕組み。従来はオープンソースへの主な参加経路だった。
出典
PRs NOT Welcome: How Top AI Open Source Projects Are Managing Thousands of Contributors
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する