Next.jsが3週間でGitHub issueを1,462件整理 — AIエージェントが調査・判定、誤クローズはわずか0.2%

9月4日、Next.jsが「How we closed 1,500 GitHub issues in one month」と題した記事を公開した。AIエージェントを活用して約3週間で1,462件のGitHub issueを整理し、バックログを1,000件以下に抑えた取り組みを詳述している。

GitHub issueのバックログ問題はNext.jsに限らず、多くの大規模OSSが抱える構造的な課題だ。コーディングエージェントの普及でバグレポートの件数・詳細度が急増する一方、メンテナーのレビュー工数はほぼ変わらない。今回の取り組みが注目されるのは、単なる自動クローズではなく「根拠を調査した上で判定する」エージェントを構築した点にある。その仕組みは他のOSSプロジェクトにとっても十分に参考になるはずだ。

バックログは最大3,109件まで膨らんでいた

Next.jsのissueトラッカーには週平均36件の新規レポートが届く。コーディングエージェントの普及で詳細なバグレポートが増えた一方、レビューの手間も増大した。バックログは2025年1月に3,109件でピークを迎え、2026年8月10日時点でもまだ2,244件が未処理のまま残っていた。

修正済みのバグ、重複報告、サポート外バージョンへの問い合わせが、本当に対処が必要な現行のリグレッション（バグの再発）を埋もれさせていた。

最初の試みとして、2025年1月に18ヶ月間アクティビティのないissueを自動でstaleマーク→クローズするワークフローを導入した。しかしこのアプローチには限界があった。「古い」ことと「不要」であることは別物で、実際にはまだ有効なバグ報告まで閉じてしまうケースが生じた。タイムスタンプだけでは判断できないのだ。

AIエージェント「closability」の仕組み

そこでチームが構築したのが、issueを「クローズ可能か」判定するリサーチエージェント**closability**だ。基盤にはVercelのオープンソースエージェントフレームワークeve（GitHubリポジトリ）を使用し、Vercel Sandbox上の隔離された環境で動作する。

各issueの調査では以下を実行する：

1. GitHubのスレッドを読み、サポート対象バージョンを確認
2. 関連issue、PR、コミット、リリース、ドキュメントを検索
3. 必要に応じて、報告されたバージョン・最新安定版・canaryでバグの再現を試みる
4. 初期の結論に反する証拠を探す

調査結果は構造化データで返される。信頼スコア（closeConfidence）は保守的に設定されており、再現に失敗しただけではクローズ推奨にならない。高スコアには「現時点での強い根拠があり、反証がないこと」が必要だ。

{
  "assessment": {
    "closeConfidence": 86,
    "primaryReason": "fixed",
    "summary": "The reported crash was fixed and no longer reproduces on supported releases.",
    "evidence": [
      "PR #71234 merged in Next.js 15.1.4",
      "PR #70001 closed; superseded by merged PR #71234",
      "No longer reproduces on 16.3.0-canary.92"
    ]
  }
}

セキュリティ面では、エージェントはサンドボックス外では読み取り専用に制限されている。issueへのコメント、クローズ操作、コードのプッシュは一切できない。またプロンプトインジェクション対策として、issueのテキストやリポジトリ内に書かれた指示は無視するよう設定されている。

3週間で1,462件をクローズ、精度は99.8%

実際の運用では、全バックログを処理した。1件あたりの調査時間は平均30分で、最終的に200セッションを並列実行するまでスケールアップした（なお元記事のタイトルは「one month」だが、実際の処理期間は約3週間だったと記事内で説明されている）。

エージェントが算出した結果は「Close Queue」に積まれ、メンテナーが証拠を確認しながら最終判断を下した。クローズされた1,462件の内訳は以下の通りだ：

誤クローズへの対策として、クローズ時には14日以内であれば「Reopen: <理由>」と返信することで再オープンを申請できるGitHub Actionも導入した。issueを開いた本人やコメントしていたユーザーは自動で再オープンされる仕組みだ。

結果として、クローズされた1,462件のうち再オープンされたのはわずか3件（0.2%）。精度は**99.8%**という水準に達した。

継続的な運用と「Maintainer Agent」への発展

一度きりの大規模整理では意味がない。そこで毎週月曜日に、30日以上アクティビティのないissueを最大100件ずつ自動でレビューする仕組みを稼働させている。

さらに直近では、明確なケースについてはメンテナーの確認なしで自動クローズする運用も始めた：

1. closabilityがissueをレビューし、スコアが80以上の場合
2. 第2のエージェントがオープンに留めるべき証拠を探す
3. 両エージェントがクローズを推奨した場合のみ、自動でクローズ

現在は週最大25件から始めており、誤判定は従来通り再オープン申請で対応できる。なおコードの変更は引き続きすべて人間のレビューが必須だ。

closabilityはissueのバックログ整理に特化したエージェントだが、Next.jsチームはこれをより大きな取り組みの一部として位置づけている。issueの再現、canaryでの検証、変更の二分探索（bisect）、E2Eテスト作成、修正準備を担う独立したエージェント群をまとめて「Maintainer Agent」と呼んでおり、OSSメンテナンス全体のAI化を見据えた構想が透けて見える。コード生成にとどまらず、メンテナンス業務そのものにAIが実用レベルで入り込んだ事例として、他のOSSプロジェクトが同様のアプローチをどう取り入れていくかが今後の焦点になるだろう。

詳細はHow we closed 1,500 GitHub issues in one monthを参照していただきたい。