最大規模のモノレポで58%のPRが人間のレビューなしでマージされる

当社で最も古く、最大のNext.jsアプリケーションの一つは、複数の重要なプロパティを含むモノレポジトリです：Vercelマーケティングサイト、ドキュメント、サインアップフロー、ダッシュボード、および内部ツール群。このリポジトリでは、平均して週に400以上のプルリクエストが作成されます。最近まで、マージ前にはそれぞれが人間の承認を必要としていました。 現在では、エージェントがそれらのプルリクエストの58%を人間のレビュアーなしでレビューおよびマージしており、平均マージ時間は29時間から10.9時間へと62%減少しました。 エージェント生成コードのマージは危険な場合があります。これは、エージェント自体を安全に本番環境へのデプロイに使用する方法の実際の例です。 問題：レビューのボトルネック 重要なデザイン更新やA/Bテストは可能な限り迅速に公開する必要がありますが、それらは我々が望むほど速く本番環境に到達していませんでした。リポジトリのPRを分析した後、レビュー準備完了からマージまでの平均時間が29時間であることがわかりました。それは、待機に費やされる完全な稼働日以上です。 さらに深く調査すると、PRの半数以上が（人間によって）コメントゼロで承認されていることがわかりました。18%は5分以内に形式的に承認されていました。 そこで我々は自問しました：ほとんどのレビューが何も検出していないなら、それらは実際に何から保護しているのか？ プルリクエストは、2つの異なる活動を容易に混同させることができます： アラインメントは、何を構築するか、どのように構築するかについて合意することです：アーキテクチャ、構造、および設計上の決定 検証は、構築されたものが正しく機能することを確認することです このような成熟したコードベースにおけるほとんどの変更は検証のみを必要とし、AIは検証をうまく処理できます。すべてのCSS調整やドキュメント更新に人間の承認を要求することは、コードベースをより安全にするのではなく、エンジニアを遅くし、基本的な更新を不必要に遅らせます。 皮肉なことに、AIは問題を悪化させています：エージェントがコードを生成するにつれて、より多くのPRがボトルネックに流れ込みます。しかし、解決策はエンジニアにレビューをより厳しく、より速く行うよう求めることではありません。人間の判断を必要とする変更と必要としない変更を区別できるシステムを構築することです。 以下に、我々が自動マージワークフローを構築した方法と、その過程で学んだことを説明します。 リスクフレームワークから始める 重要な洞察は、初期分析において明白でした：すべてのPRが同等のリスクを負うわけではありません。ドキュメント修正と認証変更では、根本的に異なる影響範囲があります。我々はそのリスクを自動的に分類する方法を必要としていました。 我々はGeminiを使用したLLMベースのPR分類器を構築し、差分、タイトル、および説明に基づいてすべてのPRを評価します。分類器は2つのラベルのいずれかを割り当てます。 HIGHリスクには、認証、支払い、データ整合性、セキュリティ、およびインフラストラクチャへの変更が含まれます。これらは常に人間のレビューを必要とします LOWリスクには、UI変更、スタイリング、テスト、ドキュメント、リファクタリング、およびオフになっているフィーチャーフラグが含まれます。これらは自動承認の候補です。 分類器は構造化されたJSONを返します： スキーマはevidenceQuotesを最初に、riskLevelを最後に配置します。これにより、モデルは分類する前に逐語的な差分スニペットを抽出し、それらについて推論することを強制されます。実際のコードにリスクの証拠を見つけられない場合、デフォルトでLOWになります。決定はPRタイトルではなく、差分に基づいています。 分類器はまた、誤ったLOWよりも誤ったHIGHを優先するように調整されています。誤ったHIGHは1つの不要なレビューを要します。誤ったLOWはリスクのあるコードをレビューなしで出荷させます。データ整合性PRの93%とセキュリティPRの92%をHIGHリスクとしてフラグ付けします。一方、スタイリングPRの0.2%とドキュメントPRの0.4%がHIGHとしてフラグ付けされます。 これらのカテゴリは固定されていません。すべてのリスク評価には「Incorrect?」リンクが含まれており、応答をDatadogに記録し、通知をSlackにルーティングします。エンジニアが誤分類をフラグすると、我々はそれをレビューし、分類器が間違っていた場合、そのPRを評価セットに追加します。 2つの厳格なルールがLLMをバイパスします：100以上の変更ファイルがあるPRは常にHIGHであり、CODEOWNERSで保護されたパスは常に人間のレビューを必要とします。 すべてのLLM呼び出しは、キャッシング、レート制限、および可観測性のためにVercel AI Gatewayを経由します。コストは評価あたり約$0.054、または週約$51です。 このアプローチは、我々が最近実行可能ガードレールとして説明したものを実践しています。何がリスクと見なされるかをリストするWikiページの代わりに、その判断をパイプライン自体にエンコードしました。 テスト、検証、およびロールアウト 我々はこれを3つのフェーズでロールアウトし、各フェーズはマージ自律性のレベルを上げる前に信頼を構築するように設計されました。テストを開始する前に、キルスイッチを定義しました。実験は以下の場合に終了します： リバート率が1.7%のベースラインの3倍（5.1%の閾値）を超えた場合 ロールバック率がベースラインの3倍（7.2/週の閾値）を超えた場合 チームの感情が否定的に変わった場合 以下は実験のフェーズと各フェーズで起こったことです： フェーズ1：サイレント分類 LLMはすべてのPRをLOWまたはHIGHリスクとしてラベル付けし始めました。唯一の可視信号は、分類を表示する情報提供のGitHubチェックでした。運用上は何も変更されませんでした。 我々はデータを収集し、リスクに関する我々自身の評価に対して精度を検証しました。精度閾値を満たすには約3週間のプロンプト反復が必要でした。その時点で、我々はエンジニアリングチームと結果を検証する準備ができました。 フェーズ2：可視ラベル Vercel Agentは、リスク分類と理論的根拠を含むコメントをすべてのPRに付け始めました。エンジニアはその推論を見て、異議を唱え、「Incorrect?」をクリックして誤りをフラグすることができました。 フェーズ3：強制 このフェーズでは、LOWリスクPRはVercel Agentによって自動承認され、人間のレビュアーなしでブランチ保護を満たしました。HIGHリスクPRは警告コメントを受け取り、依然として人間の承認を必要としました。 エンジニアは依然として提出した任意のPRにレビューをリクエストすることができました。変更点は、低リスク変更においてレビューがブロッカーではなくなったことです。 結果はすべての安全閾値をクリアし、ワークフローは現在リポジトリのデフォルトです。 SOC-2コンプライアンスは、実験および強制プロセス全体で維持されました。詳細は以下のコンプライアンスセクションで説明します。 結果 レビューをスキップしてもリバートは増加しなかった これが最も重要な質問でした。低リスクPRにレビューをスキップさせると、より多くの悪いコードが本番環境に到達するでしょうか？ 671の低リスクPRがレビューをスキップしました。ゼロがリバートされました。（Wilson 95% CI上限：0.6%、我々の1%安全閾値をはるかに下回ります。） 対照群（依然としてレビューを受けた低リスクPR）は同じリバート率でした：1,047件中2件（0.2%）。レビューをスキップしても測定可能な差はありませんでした。 デプロイメントロールバックは週2.8回から1.9回に減少しました。実験中のロールバックのいずれも、自動承認PRによって引き起こされたものではありませんでした。我々はVercelアクティビティログを介して各ロールバックされたデプロイメントをトリガーPRにマッピングしました。 インシデントを引き起こした1つのロールバックは、ミドルウェアリダイレクト変更でした。分類器はそれをHIGHとしてフラグ付けしました。人間がそれをレビューし、承認し、マージしました。分類器は危険な変更を検出しましたが、人間がそれを通過させました。 エンジニアは62%速く出荷した レビューをスキップしたPRの中央マージ時間は0.5時間で、レビューされたPRの2.3時間と比較されました。差はテールで広がります：p90では、スキップPRはレビューPRよりも58.3時間速かったです。 採用は即時でした。強制が開始された週、低リスクPRの61%がレビューをスキップしました。 個人の人間のスループットは46%増加しました。アクティブ作成者あたりのPRは週2.6件から3.8件へと増加しました。 ピークマージ時間は午後2-4時から午後6-10時（PST）にシフトしました。時間外マージは7.5パーセントポイント増加し、週末マージは6.3パーセントポイント増加しました。エンジニアはレビュアーがオンラインのときではなく、作業が完了したときにマージします。 人間のレビューは重要な場所で改善された HIGHリスク、大規模差分PRにおける初回レビューまでの時間は24.7時間から9.0時間に減少し、2.7倍の改善です。リスクのある変更に人間の目が必要な場合、より速くそれらを得ます。 レビュアーのワークロードも週13PRからわずか5強に減少しました。レビューするPRが少ないため、実行される評価はより徹底的です。 HIGHリスクPRにおける形式的承認率は安定しました（11.9% vs 12.4%ベースライン）。レビューでフラグ付けされたセキュリティ懸念は6.3%から27.2%に急増しました（フェーズ2でのn=261 HIGHリスクPR）。小規模HIGHリスク差分におけるレビューの深さが改善されました（Cohen's d = 0.44）。 エンジニアは分類器に同意するか？ 我々はエンジニアの不同意をアンケートではなく行動を通じて測定しました。 信号 割合 LOWリスクPRに対するCHANGES_REQUESTED 0.9% LOWリスクPRのリバート 0.2% 低リスクPRの43%は、必須でないにもかかわらず、依然として自発的なレビューを受けました。それらの70%はコメントゼロでした。一部のチームは依然としてコラボレーションと知識共有のためにレビューを好みますが、重要な点はレビューをゲートではなく選択にすることです。 敵対的強化 分類器はユーザー制御入力（user-controlled input）を処理し、結果に基づいて自動承認します。これは敵対的攻撃面（adversarial surface）です。 アーキテクチャ システムは、完全に侵害されたLLM出力でも重大な害を引き起こせないように設計されています： ゼロツール。LLMは構造化されたJSONを出力します。コード実行、ファイルアクセス、API呼び出しはありません。 制約された出力、事前決定されたアクション。モデルは2つの有効なリスクレベルのみを返すことができ、それらは2つの可能なシステムアクション：APPROVEまたはWARNING COMMENTにマッピングされます。LLM出力から任意の動作へのパスはありません。 フェイルオープン。LLMが失敗するか無効な出力を返した場合、PRは標準の人間レビューにフォールバックします。 入力強化 不可視Unicode除去。すべてのLLM入力からタグ文字（U+E0000-E007F）、バリエーションセレクタ、および双方向テキストオーバーライドを除去します。これらの不可視文字はプロンプトに命令を密輸することができます。GitHubは差分でそれらを保持します。これはGlassWormキャンペーン（151以上のリポジトリ、不可視プロンプトインジェクション）で悪用されました。 出力サニタイゼーション。モデル生成テキストはGitHubに投稿される前にサニタイズされます。非HTTPSリンクと画像埋め込みは除去されます。 作成者ゲーティング。信頼されていない作成者（初回貢献者、プレースホルダーアカウント）からのPRは分類と評価の投稿を受けますが、自動承認は決されません。 敵対的評価スイート。3つのプロンプトインジェクションシナリオ（Unicode密輸、XMLタグインジェクション、コードコメント操作）がすべてのデプロイで100%精度ゲートで実行されます。 我々が検討し却下したこと 追加の強化アプローチを検討しましたが、実装はしませんでした。 防御 理由 ソルト付きXMLタグ チャットボットの脅威モデルであり、構造化された分類ではありません。プロンプトキャッシュを破壊します。 サンドイッチ防御 公開された研究では5.5-85.6%の攻撃成功率；適応型攻撃に対しては>95% XMLエスケープ入力 正当なコードを破損します 制限事項 分類は確率的です。Carlini et al. (2025) は、公開された12のプロンプトインジェクション防御が71-100%の成功率で回避されることを示しました。単一の絶対的な防御は存在しません。 分類器は簡単な判断を高速化します。難しい判断における人間の判断を置き換えるものではありません。HIGHリスクの変更は常に人間によるレビューを必要とします。攻撃が成功した場合の最悪のシナリオは、1つの低リスクPRが自動承認されることです。私たちはリバート率とロールバック率を継続的に監視し、逸脱を検知しています。 コンプライアンス エンジニアリングリーダーからよく寄せられる質問は、コンプライアンスはどうなるのか、というものです。 コンプライアンスフレームワークが要求するのは、明確に定義された変更管理プログラムであり、必ずしも手動のピアレビューではありません。重要なのは、変更が承認され、文書化され、テストされ、一貫した監査可能なプロセスを通じて承認されることです。 LLMベースのリスク分類器を追加することは、以下の3つの方法で当社の変更管理プロセスを強化します： より良い文書化。すべてのPRが、根拠、証拠、分類を含む構造化されたリスク評価を今では受けます。必須レビュー下では、承認の52%が全く文書化されていませんでした。監査証跡は、単一の承認クリックから、PRごとの完全なリスク根拠へと進化しました。 リスクベースのルーティング。すべての変更を同じように扱う代わりに、分類器は人間の注目を最も重要なHIGHリスクの変更に向けます。LOWリスクの変更は、一貫した監査可能な承認プロセスを通過します。セキュリティに敏感なパスは、CODEOWNERSを介して指定されたレビュアーを依然として必要とします。 継続的監視。リバート率、ロールバック率、分類器の精度は毎週追跡されます。これにより、必須レビューにはなかったフィードバックループが生まれます：プロセスが機能しているかどうかを測定でき、単にそう想定するだけではありません。 当社の内部リスクベースアプローチに基づいてモデル化されたLLMベースのPR分類器を含めることは、当社の変更管理プロセスを強化し、監査可能性のための追加文書を提供しました。 学んだこと 必須レビューはすでに形骸化していました。レビューの52%は何も生み出しませんでした。自動承認は、機能している安全網を取り除いたのではありません。機能していなかったものを要求するのをやめたのです。671件のレビューがスキップされ、レビューされたPRと同じリバート率、62%高速なマージ。 真の利益は速度だけでなく、集中です。レビュアーはHIGHリスクPRに2.7倍速く到達します。重要なPRのボトルネックは、レビュー能力では決してありませんでした。それはレビューの割り当てでした。 保守的な分類が正しいデフォルトです。誤ってHIGHと判定するコストは、1つの不要なレビューです。誤ってLOWと判定するコストは、レビューされていない危険なコードがリリースされることです。過剰にフラグを立て、エンジニアにオプトアウトさせましょう。 レビューはゲートではなく、選択肢になりました。低リスクPRの43%は依然として自主的なレビューを受けました。コラボレーションと知識共有のためにレビューを好むチームもあり、それは問題ありません。 次のステップ レビューをスキップするワークフローは、当社最大のモノレポで恒久的になりました。同じ3段階アプローチを使用して、より多くのリポジトリに展開しています。 エージェントがより多くのコードを生成し、PRの量が増加するにつれて、適応しないチームにとってレビューのボトルネックは悪化するだけです。答えは、より一生懸命レビューすることではありません。リスク判断をパイプラインに組み込むシステムを構築することです。 希少な資源は人間の判断です。それが重要である場所に費やしましょう。 続きを読む

最大規模のモノレポで58%のPRが人間のレビューなしでマージされる

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト