VercelがAI SDKで組んだエージェント7体、マージPRの3割はもうAIが書いています

週2,000万ダウンロードのライブラリで、issueが1,022件、PRが800件近く積み上がっていました。

Vercelがこれをどう片付けたかというと、人を増やすんじゃなくてエージェントを7体置いています。

4週間後、マージされるPRの3割前後を書いているのは、もう人じゃありません。

issue1,022件、PR800件近く、AI SDKは自力で捌ける量を超えていました

まず規模から。

AI SDKはnpmで週2,000万ダウンロードを超えていて、GitHubのスターも26,000超え。

TypeScriptでLLMアプリを書くなら、まず候補に挙がるライブラリです。

そのリポジトリに、2026年6月下旬の時点でopen issueが1,022件、open PRが800件近く溜まっていました。

数字だけだとピンとこないので言い換えます。

メンテナーが1日10件さばいても、issueだけで100日かかる量です。

その間も新しいissueは積み上がり続ける。

GitHub - vercel/ai: The AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents

The AI Toolkit for TypeScript. From the creators of Next.js, the AI SDK is a free open-source library for building AI-powered applications and agents - vercel/ai

github.com

バグ再現から実装まで、置かれたエージェントは7系統に分かれています

Vercelが2026年8月12日に出したソフトウェアファクトリーの解説で、いちばん面白かったのがこの設計です。

万能エージェントを1体置いて全部やらせる、じゃないんですよ。

役割で7つに割っています。

1. バグ再現
2. バグ修正
3. PRレビュー
4. バックポート
5. ドキュメント更新
6. 機能分析
7. 機能実装

この並び、よく見るとissueが飛んできてからマージされるまでの工程そのままです。

報告が来る、再現する、直す、レビューする、過去バージョンに当て直す。

人間のチームが分担するのと同じ粒度で切っている。

効いているのが数字にも出ていて、v6へのバックポートは週次マージの50%超をファクトリーが占めています。

バックポートって、修正の中身は決まっていて、それを別ブランチに正しく当てるだけの作業なんですよね。

判断が要らなくて手数だけかかる。

そういう工程を切り出して専用エージェントに渡す発想自体は分かるんですが、7つまで割っている例は初めて見ました。

4週間でマージPRの25〜35%、issueの7割超が動きました

出ている成果はこれです。

• マージされるPRの25〜35%をファクトリーが執筆（週ごとの比率）
• 7月にクローズされたissueの75%超がファクトリーによるもの
• open issueは6月下旬のピーク1,022件から8月上旬に844件へ
• open bugsは約25%減

ここ、注意点があります。

同じ件をまとめたLatent Spaceの記事では、issueのクローズ率が70〜80%と書かれています。

Vercel公式は「7月に75%超」、Latent Spaceは「70〜80%」。

矛盾しているわけじゃなくて、公式が特定の月の実績を出しているのに対して、外部記事が期間をならして幅で書いている。

どちらかに寄せて断定するより、この幅ごと持っておくほうが正確です。

あと勘違いしやすいんですが、エージェントが書いたPRを最終的にマージしているのは人です。

勝手にmainへ入っているわけじゃありません。

信頼していたのはエージェントではなく、その構成でした

AI SDKの開発を率いてきたLars Grammelさんの発言が、この取り組みの芯だと思っています。

とても具体的なプロンプトで最適化した、とても具体的なエージェントがある。過去の積み重ねから、ある種類のバグを直すのにそれが非常にうまくいってきたと分かっている。そうなると、その特定のエージェント構成に対する信頼が育つんです

原文だと "we develop trust in that particular agent configuration" です。

信頼している対象が「AI」でも「そのエージェント」でもなくて、configuration、つまり構成のほうなんですよ。

ここ、うまいこと言うなと思いました。

エージェント単体は毎回同じ挙動をしません。

でも「このプロンプト、このモデル、この種類のバグ」まで絞れば、成功率の履歴が取れる。

履歴が取れれば、次も通るかどうかを見積もれます。

裏を返すと、履歴の取れない相手は信頼のしようがない。

外から飛んでくるPRって、まさにそれなんですよね。

誰が書いたか分からない、どう検証したか分からない、次も同じ品質で来るか分からない。

レビューコストが下がらない理由がここにあります。

外部PRを止めたのはVercelではなく、tldrawとFlueでした

この話、日本語で広まるとき誤解されそうなので先に潰しておきます。

Vercelは外部PRを止めていません。

vercel/ai のCONTRIBUTINGを実際に開いて確認しましたが、今も "Contributions to the AI SDK are welcome and highly appreciated." のままです。

外部PRの受付そのものをやめているのは、別のプロジェクトです。

1つはtldraw。

無限キャンバスのSDKで5万スター超のプロジェクトですが、リポジトリのトップにこう書いてあります。

We are not accepting contributions at this time. If you've found a bug or have a feature request, please create an issue and we can discuss it there.

PRは受け付けない、バグや要望はissueへ、という運用です。

作者のSteve Ruizさんは、この判断の背景に開発の進め方そのものの変化を挙げていて、議論が増えてエージェントが増えたことを理由にしています。

GitHub - tldraw/tldraw: Build infinite canvas apps in React with the tldraw SDK. World's best, top-most agent recommended #1 five star SDK.

Build infinite canvas apps in React with the tldraw SDK. World's best, top-most agent recommended #1 five star SDK. - tldraw/tldraw

github.com

もう1つがFlue。

Astro共同創業者のFred Schottさんが作っているエージェントフレームワークで、こちらは外部PRを自動でクローズして、issueかdiscussionに変換します。

バグ報告や修正提案はissueへ、機能要望はdiscussionへ。

理由として挙げられているのは、通りすがりに投げ込まれるAI量産PRへの対策です。

GitHub - withastro/flue: The sandbox agent framework.

The sandbox agent framework. Contribute to withastro/flue development by creating an account on GitHub.

github.com

そしてAstro本体は、また別の話です。

こっちはPRを止めた側じゃなくて、issueのトリアージが自動化された側。

Schottさんは10年以上のOSS経験で見たことがない変化だと表現していて、毎週issueに優先順位を付けられる状態になったこと自体を成果として挙げています。

止める側と、捌く側。

同じエージェント導入でも、入れている場所が違います。

コードを書くだけの貢献が、通りにくくなっていきます

ここからが僕らに関係のある話です。

OSSにPRを送って実績を作る、という動き方をしている人は少なくないと思います。

その前提が今、変わりつつあります。

メンテナー側から見ると、issueスレッドを自前のエージェントに渡して直させるほうが、外部PRをレビューするより速い。

Vercelの数字はそれを示しています。

だとすると、価値が下がるのは「仕様が曖昧なまま出されたコードPR」です。

逆に上がるものが3つあると思っています。

1. 再現手順まで書けるissue。エージェントに渡した瞬間に着手できるissueは、それ自体が仕事です
2. 設計の議論。何を作るかが決まっていない領域は、まだ人が持っています
3. 仕様の言語化。tldrawもFlueも「issueかdiscussionで」と言っているのは、そこを求めているからです

もう1つ、書く側じゃなくて組む側に回る視点も要ります。

自分のリポジトリにbotを置くとして、万能な1体にするか、役割で割るか。

Vercelの結論は後者でした。

判断が要らない工程、たとえばバックポートやドキュメント更新だけを切り出して専用に渡す。

そこからでも効き方は変わるはずです。

PRが通らない時代、と書くと悲観的に聞こえますが、実際に減っているのはレビュー待ちの行列のほうです。

コードを書く手はもう足りている。

足りていないのは、何を作るべきかを言葉にできる側です。