powered by TechFeed
表示モード
Deep Dive

VercelがAI SDKの1,000件超のIssueをAIエージェントに処理させたら、4週間でマージPRの半数以上をAIが担うようになった

8月12日、Vercelが「Building a software factory for AI SDK」と題した記事を公開した。この記事では、AI SDKのIssue・PRをAIエージェントが自動処理する「ソフトウェアファクトリー」の構築と、4週間での実績について詳しく紹介されている。

8月12日、Vercelが「Building a software factory for AI SDK」と題した記事を公開した。この記事では、AI SDKのIssue・PRをAIエージェントが自動処理する「ソフトウェアファクトリー」の構築と、4週間での実績について詳しく紹介されている。


1,000件超のIssueをどう処理するか

Vercel AI SDKは週2,000万回以上のnpmダウンロードを誇り、GitHubスターは26,000超を持つ大規模OSSプロジェクトだ。モデルプロバイダーの追加、UIフレームワークのバインディング、サンドボックス環境、各種ハーネスの対応と、メンテナンス対象は常に複数の方向に動き続けている。

その結果、元記事によればオープンIssueが1,022件、PRが約800件という状態に陥った。Anthropicのモデルリリース後にPRが急増したことが引き金となったとされている。

記事はこの状況を「規律の問題ではない」と明言している。どれだけ優秀なメンテナーでも、コード生成がほぼコストゼロになった時代に個人の努力だけでこのギャップを埋めることはできない。そこでVercelは「ソフトウェアファクトリー」の構築を選んだ。


4週間で出た数字

稼働4週間時点の実績がこれだ:

  • 週次マージPRの25〜35% がファクトリーのエージェントによる作成
  • v6リリースラインへのバックポートPRでは週次マージの50%超をファクトリーが担当
  • 7月のクローズIssueの75%超がファクトリーによるクローズ
  • オープンIssueは1,022件のピークから844件まで減少、オープンバグは約25%減

バックポート(古いバージョンへの修正適用)はこれまで「マージコンフリクト対応のコストに見合わない」として後回しにされがちだったが、ファクトリー導入後はv5・v6ともに手厚くサポートできるようになったという。


ファクトリーの設計思想:エージェント1つ=タスク1つ

ai-sdk-factory は以下の専用エージェントで構成されている:

  • バグ再現
  • バグ修正
  • PRレビュー
  • バックポート
  • ドキュメント更新
  • 機能分析(feature analysis)
  • 機能実装(feature implementation)

当初は「すべてのステップをこなす単一エージェント」も検討したが、メンテナンスとデバッグのコストが高くなることが判明し、タスクごとに独立したエージェントを用意する設計に落ち着いた。各エージェントは独自のプロンプト、コンテキスト、評価基準(evals)を持つ。

インフラはVercel Functions(API・ワーカー)、Vercel Queues(タスク実行)、Vercel Blob(ログ)、Vercel Sandbox(エージェント実行環境)、Neon Postgres(ファクトリーデータ)で構成されている。


セキュリティを最初から組み込む

公開リポジトリを対象とするファクトリーは、すべての入力を攻撃者が制御しうるものと見なす必要がある。IssueのテキストもPRのコードも、その中に含まれるリンクも、すべて信頼できない入力だ。

対策の中心はサンドボックスだ。全エージェントはVercel Sandbox内の隔離環境で動作し、そのタスクに必要なシークレットだけにアクセスできる。加えて、ネットワークアクセスを制御するシールドレイヤーを設け、サンドボックス外へのシークレット漏洩経路を遮断している。

最後の防線は人間によるレビューだ。すべての変更はAI SDKチームの人間がマージする。完全自動化ではなく、「人間の判断を中心に置きながら、その周囲を自動化する」設計だ。


実際の処理フロー:Issue #17898の例

記事では、7月24日にコミュニティから寄せられた「OpenAI Web SearchにブロックドメインのサポートをほしUい」(原文ママ)というIssue #17898を例に、ファクトリーの全工程を解説している。

  1. 分類エージェント:「機能リクエスト(高信頼度)」と判定し、根拠をIssueにコメント
  2. 分析エージェント:機能の不在を確認するプローブコードを生成・実行し、欠如を証明。仕様(blockedDomainsフィルターを追加しプロバイダーのblocked_domainsフィールドにマッピング)を策定
  3. 実装エージェント:仕様に基づき実装し、wikipedia.orgをブロックしたライブE2Eテストを実施してPR #18033を作成
  4. レビューエージェント:副作用リスク「低」、パフォーマンスリスク「なし」、後方互換性リスク「低」と評価・承認
  5. 人間レビュー:Lars(メンテナー)がエージェントの証拠チェーンとコードを確認しマージ
  6. バックポート:v6・v5向けのPRを自動作成。v5はコンフリクトが発生したが、ファクトリーが自律的に修正し17分後にプッシュ

失敗から自動化の境界を広げる

ファクトリーの各実行は「成功・不完全・ブロック・手動」の4つで終わる。成功以外はすべてフィードバックとして再入力される。

  • 不完全:プロンプトやコンテキストの改善、新しいevalケースの追加
  • ブロック:クレデンシャルや依存関係の不足 → プロビジョニングで解消
  • 手動:意図的に引いた境界線 → その境界を取り除くに値するか判断

これはCIパイプラインやテストスイートの運用と同じ規律だが、「チェックするシステム」ではなく「作業するシステム」に向けられている点が異なる。ファクトリーのすべてのPRはGitHubで公開されており、実際の動作を確認できる。


詳細はBuilding a software factory for AI SDKを参照していただきたい。