ソフトウェア開発や保守の現場では、日々寄せられる不具合報告や問い合わせの滞留が深刻な課題になりがちです。数百万の開発者が利用するNext.jsのリポジトリでも、コーディングエージェントの普及によって詳細な報告が作成しやすくなった一方、保守担当者が確認すべきIssueの件数が急増するという事態が生じていました。
こうした課題に対し、Next.jsのチームが2026年9月、AIエージェントを活用してGitHub Issueを調査・整理した運用プロセスを公開しました。詳細はNext.jsの公式ブログ記事で説明されています。この取り組みで注目すべきは、AIにクローズ処理の権限を丸ごと渡したのではなく、調査と証拠集めに徹させ、最終的な判断を人間の保守担当者が担う安全設計を採った点です。
無活動期間による自動クローズが抱える限界
Next.jsのリポジトリでは、未解決のIssueが2025年1月に3,109件に達していました。そこで当初は、2年間（後に18か月）更新がないIssueに「stale（無活動）」の印を付け、猶予期間を経て自動的に閉じるワークフローを導入していました。これにより2026年8月10日時点では2,244件まで減少したものの、運用上の問題が浮き彫りになったと説明されています。
最終更新日からの経過時間だけでは、そのIssueがすでに修正済みなのか、重複報告なのか、仕様通りの動作なのか、あるいは「誰も再確認していない重大な未対応不具合」なのかを区別できません。単なる無活動期間でクローズしてしまうと、本来残すべき重要な報告まで誤って葬ってしまう恐れがありました。
調査エージェント「closability」の証拠収集と反証探索
そこでNext.jsのチームは、Issueがクローズ可能かどうかを調査する専用エージェント「closability」を構築しました。エージェントは独立したサンドボックス環境で動作し、以下の手順で事実関係を洗出します。
- Issueの会話内容を確認し、対象バージョンが現在もサポートされているかを照合する
- 関連する過去のIssue、プルリクエスト、コミットログ、リリースノート、公式ドキュメントを検索する
- 必要に応じて、報告されたバージョン、最新の安定版、開発版（canary）で不具合の再現を試みる
- 初期の判断仮説と矛盾する証拠（残すべき根拠）がないかを能動的に探索する
この設計で極めて重要なのが、矛盾する証拠の探索です。単に「最新版で再現しなかった」という理由だけで安易にクローズを推奨することはせず、強い最新の根拠があり、かつ信頼できる反証が見当たらない場合にのみ高い確信度スコアを算出するよう設計されました。
さらに、この調査エージェントにはサンドボックス外での書き込み権限が与えられていません。コメントの投稿、Issueのクローズ、コードのプッシュやデプロイといった更新操作は行えず、読み取り専用で調査結果を構造化データとしてまとめる役割に限定されました。
確認キューと14日間の再オープン手段による二重の防壁
調査結果は「Close Queue」と呼ばれる確認画面に集約され、保守担当者がエージェントの提示した要約と根拠資料を1件ずつ確認してクローズを判断しました。Next.jsチームの報告によると、2026年8月10日から9月4日までの約3週間で、新しく届いた218件の報告に対応しながらも、リポジトリ全体で1,462件のIssueをクローズし、バックログを995件まで圧縮したとされています。なお、この1,462件の集計には、今回の一連のレビュー運用とは別に保守担当者が個別にクローズしたIssueも含まれています。
同リポジトリの自己報告によると、クローズされた1,462件の主な理由は、対応済みが37％（543件）、重複が19％（278件）、仕様通りの動作が16％（237件）、再現不能が6％（89件）、サポート終了が5％（66件）でした。
また、保守担当者がIssueをクローズした際には、GitHub Actionsのボットが「クローズ前の作成者またはコメント投稿者であれば、14日以内に理由を添えて返信することで自動的に再オープンできる」という案内を投稿しました。14日を経過した場合は、最新情報と再現手順を添えて新規Issueを立てる運用としています。この救済措置の結果、9月4日時点の報告では再オープンされたのは3件にとどまり、全体の99.8％（1,459件）はクローズされた状態を維持したとされています。
なお、原典が公開された2026年9月4日時点の方針として、チームは確信度スコアが80点以上の場合に限り、第二のエージェントが残すべき証拠を探索した上で、週最大25件に絞って自動クローズを行う計画を公表しています。
プロンプトや文脈の変更がもたらす品質リスク
AIを活用した運用では、一度安定して動いた仕組みであっても、プロンプトの調整や文脈処理の最適化が思わぬ品質低下を招くことがあります。Anthropicが公開した品質レポートに関する事後報告では、応答の冗長さを抑えるためのシステムプロンプト追加や、キャッシュ効率化のための思考ログ削除処理の不具合が、AI支援ツールの性能低下につながった経緯が詳しく説明されています。
同社は発生した不具合や問題のプロンプトを修正・差し戻した上で、今後の再発防止策として、モデルごとの広範な評価スイートの実行やプロンプト変更の監査ツールの導入、品質低下のリスクがある変更に対する待機期間の設定や段階的ロールアウトなどを導入・強化していく方針を示しました。AIエージェントを自社の業務プロセスに組み込む際にも、プロンプトやパラメータの変更が意図しない挙動変化を招かないよう、段階的な展開や継続評価の仕組みを考慮することが重要な検討観点となります。
自社の問い合わせ・不具合管理へ応用するための着眼点
Next.jsの事例はオープンソース開発のリポジトリを対象としたものですが、自社製品のサポートデスクや社内システムの不具合管理にも共通する指針を含んでいます。例えばSaaS事業者が顧客からの障害報告を整理する場面を仮定すると、いきなりAIに自動対応やステータス変更を行わせるのではなく、次のような段階を踏むことが現実的です。
- 分類と根拠の整理: 滞留しているチケットを「対応済み」「仕様」「情報不足」「重複」などに分類し、それぞれを判断するために必要な参照情報（過去のリリースノート、更新履歴、関連チケット）を洗い出す
- 参照権限と権限境界の定義: AIエージェントには閲覧権限のみを付与し、チケットの完了や顧客への返信といった実処理権限を持たせない
- 差し戻し手順の策定: 担当者の誤認や調査不足に備え、利用者側からワンアクションで再受付や差し戻しができるルールを事前に定めておく
既存の課題管理ツールや社内リポジトリとどう連携するか、個人情報や機密データをどこまで参照範囲に含めるかといった個別環境の条件は、組織ごとに慎重な精査が必要です。
デノフへのご相談で具体化できること
AIを業務プロセスに組み込む際、単に自動化の割合を高めることだけを目指すと、誤判定への対処に追われかえって現場の負荷が増すことがあります。重要なのは、AIに「調査と根拠の整理」を担わせ、人間が「確認と承認」を行う境界線をどこに引くかという設計です。
デノフへのご相談では、こうした海外の実践知を参考にしながら、既存の問い合わせ管理や不具合対応の現場において、調査支援AIをどのように位置付けるかという導入条件の整理を検討いただけます。どの業務を調査対象とするか、参照させる社内情報の範囲、エージェントに持たせる権限の境界、人間が確認するレビュー手順や誤判定時の差し戻しルールなど、具体的な設計論点を整理することが可能です。
自社の保守・問い合わせ運用の改善に向けた論点整理をご検討の際は、デノフのサービス案内をご覧いただくか、デノフへの相談窓口よりお気軽にお問い合わせください。
