MetaがCatching JiTTestsを詳述、各変更に失敗するテストを生成し、上半期の74件の重大なプライバシーバグの捕捉で重要な役割を果たしたと説明

Metaのエンジニアリングチームは2026年10月29日、「Catching JiTTests」（ジャストインタイムの捕捉テスト）が本番環境でどう動いているかを紹介した。大規模言語モデルが、提案された各コード変更に対して、失敗するように設計した実行可能なテストを生成し、その失敗で変更が持ち込んだバグを明らかにする仕組みである。Metaによれば、記事執筆時点で589人のエンジニアが関与し、エンジニアからの報告では真陽性率は60%だった。2026年上半期には、diffの段階で74件の重大（SEV）なプライバシーバグの捕捉に重要な役割を果たしたという。

Metaはこの手法を一般的なAIコードレビューと区別する。LLMを使う多くの手法は人間のレビュアーと同じようにコードを読み、経験からどこが間違いやすいかを判断する。Catching JiTTestsは、変更が生んだ具体的な振る舞いの違いを示す実行可能なテストを生成する。Metaは計算ステップが増えることを認めつつ、LLMやエージェントによるレビューが見逃しうる種類のバグを捉えられるとする。難しさは規模にある。数億行のコードが絶えず変わる中で、生成されたテストには本物のバグを示す「強い捕捉」と、誤検知かもしれない「弱い捕捉」が混ざる。それをエンジニアの速度を落とさずに自動で見分ける必要がある。

システムは5段階で動く。第1段階は対象選定と起動で、余剰の計算能力を使って夜間に実行し、前日に提出されたdiffのうち「リスクが高い」と判定されたものだけを扱う。判定にはDiff Risk Scoreに似た仕組みを使い、過去のコード変更で学習している。第2段階は2つの並行するテスト生成だ。「dodgy diff」は各diffを変異体（バグ入りの版）とみなし、変異に基づくLLMのテスト生成で、diffと親の版の振る舞いを分けるテストを作る。意図は推測せず、弱い捕捉の母数を増やすのが狙いだ。「intent-aware」はまずLLMがコード変更、タイトル、要約からdiffの意図を推測し、その意図の実装が失敗しうる「リスク」を述べ、それに基づいて変異体を作り、各変異体を倒すテストを生成する。このテストを実際のdiffで実行し、失敗したものが弱い捕捉として集められる。

第3段階は「LLM-as-Judge」で、複数の先進モデルが、弱い捕捉のテストコード、実行結果（失敗コード、メッセージ、トレース）、親子間の差分、推測した意図を見て、誤検知か本物のバグかを判断する。第4段階はルールベースの評価器RubFakeで、検証可能で決定的な判断を与え、LLMの判断が非決定的で検証しにくい点を補う。両者で弱い捕捉に順位を付ける。第5段階は「human-on-the-loop」で、順位に基づきシステムがエンジニアに連絡するかを決める。エンジニアは基準を定め、結果を集計の水準で確認し、出力を一つずつ監督することはしない。

報告された数字には、範囲を押さえるべきものがある。589人はMetaの働きかけ対象の64%だが、働きかけの総数は記事に書かれていない。60%の真陽性率はエンジニアの報告に基づく。74件の重大なプライバシーバグの捕捉で「重要な役割」を果たしたとされ、記事はこれを、同期間にプライバシーのSEV全体が20%減ったという話と同じ文で述べるが、対照となる基準は示さず、この仕組みだけが原因だとも書いていない。比較表と効果の図は原文では画像で、その数値はここでは使っていない。

他のチームが参考にできるのは、手順の形だ。リスクスコアで少数のdiffを選び、振る舞いの違いを示すテストを作り、モデルとルールの両方で誤検知を除き、順位が高いときだけ人を煩わせる。限界も明らかである。数字はMeta自身の導入によるもので、コストは追加の計算であり、結果はプライバシーのバグに関するものなので、あらゆる欠陥に広げて解釈すべきではない。