対応する変更履歴（VCS）メトリクス

この章は、変更履歴メトリクス — big-code-analysis がソースの AST ではなくバージョン管理履歴から導出するシグナル — のガイドツアーです。対応するコードメトリクス の章が現在あるがままのコードの 形 を測定するのに対し、これらのメトリクスはそのコードが どうやってそこに至ったか を測定します。どれくらいの頻度で、どれだけの量が、何人によって、どのような種類のコミットで変更されるのか、です。各節は、そのシグナルを最初に欠陥と結び付けた経験的な論文から始まり、big-code-analysis がそれをどのように計算するかをたどり、実践でその数値をどう読むべきかを説明します。

このファミリー全体は bca vcs コマンドで計算され、bca metrics --vcs の出力に付加されます。Commands → Change-history (VCS) metrics のページが、フラグ、ウィンドウ、出力形式、キャッシュを説明しています。この章が 「なぜ」 を、あちらのページが どうやって を担います。

始める前に、いくつかの前提となる注意点を挙げます：

  • これらのメトリクスは欠陥が集まりやすい場所を予測するものであり、コードが正しいかどうかを予測するものではありません。 欠陥・脆弱性予測の文献は一貫して、プロセス シグナル — ファイルが時間とともにどう編集されてきたか — が、サイズや複雑度のような プロダクト シグナルを予測精度で上回ることを見いだしています。Graves らは 2000 年に率直にこう述べました。モジュールの変更回数は、その長さよりも優れた欠陥数の予測因子である、と。これらの数値はどれも正しさを測定しません。バグが潜んでいる確率でファイルをランク付けするのです。
  • すべては 2 つのウィンドウで測定されます。 呼び出しごとの 1 回の履歴走査で、長期ウィンドウ（デフォルト 12mo ≈ 365 日）と直近ウィンドウ（デフォルト 90d）の両方についてすべてのシグナルが生成されます。直近性はジャストインタイム欠陥予測の系譜における最も強い単独シグナルであるため、全体を通じて直近の活動は古い活動より重く重み付けされます。
  • 複合スコアは順序尺度であり、基数尺度ではありません。 risk_score、hotspot_score、コミットレベルの JIT スコアは温度計ではなく物差しです。意味を持つのは相対的な順位だけです。リポジトリのファイル（またはコミット）を互いに対して、あるいはそのリポジトリ自身の時間的な分布に対してランク付けしてください。絶対値を確率として読んだり、無関係なプロジェクト間で生のスコアを比較したりしないでください。
  • レコードが存在しないことはゼロではありません。 追跡されていないファイルにはレコードがまったく存在せず、これはウィンドウ内の活動がゼロの追跡対象ファイルとは区別されます。計算結果としての 0.0（たとえば、常に単独でしか変更されなかったファイルの共変更エントロピーはゼロです）は実際の測定値です。

一覧

メトリクス測定対象最初に欠陥と結び付けた研究
コミット頻度ファイルがどれくらいの頻度で変更されるかGraves et al.、2000 年
コードチャーン何行が変更されるかNagappan & Ball、2005 年
バースト直近ウィンドウへの変更の集中度直近性の原則（Graves、JIT の系譜）
作者と所有権何人の手がファイルに触れ、それがどれだけ集中しているかBird et al.、2011 年；Meneely & Williams、2009 年
修正・セキュリティ・リバートコミット是正的な変更の履歴Śliwerski, Zimmermann & Zeller、2005 年
経過時間と最終更新ファイルがいつ生まれ、いつ最後に触れられたかジャストインタイム欠陥予測の系譜
変更エントロピーファイルに触れるコミットがどれだけ 「分散」 しているかHassan, 2009
共変更エントロピーファイルの変更が波及する影響範囲がどれだけ広いかarXiv 2504.18511, 2025
複合リスクスコア上記すべてのシグナルの重み付き集約本プロジェクト（式 v2）
ホットスポットスコア複雑度 × 直近のチャーンTornhill, 2015
バスファクターファイル集合全体での知識の集中度Avelino et al., 2016
ジャストインタイムコミットスコア単一コミットの欠陥誘発リスクKamei et al., 2013

コミット頻度

最も単純な変更履歴シグナルは、ファイルにいくつの個別コミットが触れたかです。big-code-analysis はこれをウィンドウごとに commits_long と commits_recent として記録します。

このメトリクスの欠陥予測指標としての評価は、Todd Graves、Alan Karr、J. S. Marron、Harvey Siy による 2000 年の IEEE TSE 論文 Predicting Fault Incidence Using Software Change History に由来します。大規模な電話交換システムを研究した彼らは、変更履歴から導かれるプロセス指標が、コードそのもののどのプロダクトメトリクスよりも欠陥率をよく予測すること、なかでも過去の変更回数が最も強力な指標のひとつであることを見出しました。直観は単純です。誰も触れないファイルは、誰も壊していないファイルだということです。

アルゴリズム

1 回の履歴ウォークで、解析対象の ref から到達可能な各コミット（デフォルトでは first-parent のみ、--full-history で完全な DAG）を訪問し、そのコミットが変更する各ファイルに帰属させます。マージコミットは --include-merges を渡さない限り除外され、リネームはデフォルトで追跡されるため、ファイルの履歴は移動後も維持されます。ウォークが数えるのはファイルごと・ウィンドウごとの 個別コミット数 であり、diff やハンクの数ではありません。そのため、ファイルに 1 か所だけ触れるコミットも 3 つのハンクで触れるコミットも、どちらも 1 とカウントされます。

読み方

コミット頻度はレートであるため、ベースラインとの比較においてのみ意味を持ちます。すなわち、このファイルと兄弟ファイルの比較、あるいはこのファイルの今四半期と前四半期の比較です。一貫して高いカウントは、そのファイルが活発な機能開発の対象であるか、構造的に不安定であるかのどちらかを示します。コードチャーンと組み合わせれば両者を見分けられます。少数のコミットでの大量のチャーンと、多数のコミットでの少量のチャーンとでは事情が異なるからです。

コードチャーン

コードチャーンは変更の量です。ファイルに触れた追加行数と削除行数の合計で、ウィンドウごとに churn_long と churn_recent として記録されます。

チャーンの欠陥予測としての系譜は、Nachiappan Nagappan と Thomas Ball による 2005 年の ICSE 論文 Use of Relative Code Churn Measures to Predict System Defect Density にあります。Windows Server 2003 で検証された彼らの主要な発見は、絶対 チャーン単独では予測力が乏しい一方、ファイルサイズや変更の時間的な広がりに対する 相対 チャーンは欠陥密度を高い精度で予測する、というものです。big-code-analysis はウィンドウごとの生のチャーンをシグナルとして保持し、単一の絶対値を判定として報告するのではなく、複合スコアがそれをサイズや新しさと組み合わせられるようにしています。

アルゴリズム

ウィンドウ内でファイルに触れる各コミットについて、ウォークはその diff の追加行数と削除行数の合計を、当該ウィンドウにおけるそのファイルのチャーン合計に加算します。追加行と削除行を合算するため、1 行の編集は 2（削除 1、追加 1）とカウントされます。チャーンが測るのは 活動量 であって、正味の増加量ではありません。

読み方

チャーンは密度比の自然な分子です。コミットあたりのチャーンは、着実な編集と少数の大規模な書き換えを区別します。ファイルサイズに対するチャーンは Nagappan と Ball の相対指標を再現します。直近のチャーンが長期ウィンドウのチャーンに比べて高いファイルは、履歴から予測されるよりも速く変化しています。これがまさに後述のバーストシグナルです。

バースト

バーストは、ファイルの活動のうち直近ウィンドウに集中している割合で、commits_recent / commits_long を [0, 1] の比率として報告します。1 に近い値はファイルのコミットのほぼすべてが直近のものであることを、0 に近い値はファイルが昔は活発だったがその後静かになったことを意味します。

このシグナルは、変更履歴の研究文献を貫く新近性（recency）の原則から直接導かれます。Graves et al. は、古い変更よりも最近の変更の方が欠陥発生に強く影響することを見出しており、ジャストインタイム欠陥予測の系譜（JIT スコアを参照）も同じ観察の上に築かれています。変更履歴が 現在に前倒しで集中している ファイルは活発な変動のさなかにあり、活発な変動こそ欠陥が入り込む局面です。

読み方

バーストは単独の警報ではなく、判定の決め手（タイブレーカー）です。総履歴の少ないファイルでの高いバーストは、若く動きの速いファイルを意味します。深い履歴を持つファイルでの高いバーストは、突然目を覚ました古いファイルであり、多くの場合こちらの方が興味深いケースです。経過日数と合わせて読むことで両者を見分けられます。

作者数と所有権

関連する 2 つのシグナルが、ファイルを 誰が 変更しているかを表します。作者数（authors_long、authors_recent）は、各ウィンドウでそのファイルに触れた個別の人数を数えます。所有権（ownership_top_share、[0, 1] の比率）は、最も活発な単一の作者に帰属する編集の割合です。低いシェアは所有権が分散していることを、高いシェアは一人が支配的であることを意味します。

どちらも所有権とセキュリティに関する実証研究に遡ります。Christian Bird らによる 2011 年の FSE 論文 Don't Touch My Code! Examining the Effects of Ownership on Software Quality は、Windows Vista と 7 を対象に、分散した所有権（専門性の低い多数の貢献者と低いトップオーナーシェア）がリリース前の欠陥とリリース後の障害の両方を予測することを見出しました。セキュリティ面では、Andrew Meneely と Laurie Williams による 2009 年の CCS 論文 Secure Open Source Collaboration: An Empirical Study of Linus' Law が、Red Hat Enterprise Linux 4 において 9 人以上の開発者が触れたファイルは脆弱性を抱える可能性がおよそ 16 倍高いと報告しています。

アルゴリズム

作者の同一性はリポジトリの .mailmap を通じて正規化され、小文字化したメールアドレスでカウントされるため、2 つのアドレスでコミットする貢献者は 1 人として数えられます。Co-authored-by: トレーラーは参加者を追加します。ボットの ID（dependabot[bot]、renovate[bot]、github-actions[bot] など）はデフォルトで除外され、自動化によるチャーンがカウントを膨らませないようになっています。ownership_top_share は、ウィンドウ内でのそのファイルの総編集数に対するトップ作者の編集数の割合です。

読み方

長寿命のファイルで作者数が増えていくのは知識拡散のシグナルです。より多くの人がそのファイルを理解する義務を負うようになったことを意味します。複合リスクスコアはこれを 2 つの形で織り込みます。作者ファクターを所有権の 希薄化 項 (1 - ownership_top_share) でスケーリングするため、所有権が薄く広がっているときほど同じ人数がより大きく効きます。さらに、Meneely と Williams の RHEL4 しきい値を符号化した、開発者 6 人・9 人の節目でのカテゴリカルな加点を行います。1 つのファイル内ではなくファイルの 集合 をまたぐ知識の集中については、バスファクターを参照してください。

修正・セキュリティ・リバートコミット

big-code-analysis は、ファイルに触れる長期ウィンドウ内の各コミットをメッセージの意図で分類し、3 つのカウントを保持します。bug_fix_commits（バグ修正キーワードに一致するメッセージ）、security_fix_commits（CVE-####、security、vuln、exploit、sanitize などに一致するメッセージ）、revert_commits（リバートまたはロールバックである件名）です。

コミットの目的をメッセージから読み取る手法は、Jacek Śliwerski、Thomas Zimmermann、Andreas Zeller による 2005 年の MSR 論文 When Do Changes Induce Fixes? で導入されたもので、現在では SZZ という略称で広く知られています。前提となるのは、ファイルの 是正的 変更の履歴それ自体が予測力を持つということです。多くの修正を必要としてきたファイルは、さらに修正を必要とする可能性が高いファイルです。セキュリティ修正は通常のバグ修正より鋭いシグナルであり、リバートは取り消さざるを得なかった変更、つまりそこで何かがうまくいかなかったという局所的な自認を刻印します。

アルゴリズム

分類はコミットの件名と本文に対するキーワードベースです（src/vcs/classify.rs を参照）。意図的に単純で、言語にもトラッカーにも依存しません。課題トラッカーとの連携も、修正誘発コミットへの blame の遡及もないため、これは SZZ のうち軽量なメッセージ分類の半分であって、完全なアルゴリズムではありません。カウントは長期ウィンドウについてのみ保持されます。

読み方

bug_fix_commits の高いカウントは、修理を必要とし続けているファイルを意味します。複合スコアは 3 つのカウントすべてを、セキュリティ修正を 2 倍に重み付けした単一の対数スケール項に通します。そのため、セキュリティ修正の履歴を持つファイルは、それ以外が同一で通常のバグ修正しかないファイルより上位にランクされます。分類器はメッセージを読むため、その精度はプロジェクトのコミット規律に依存します。簡素なメッセージやテンプレート化されたメッセージのリポジトリでは過小カウントになります。

経過日数と最終更新

2 つのタイミングシグナルがファイルの履歴を区切ります。age_days はファイルの 最初の ウィンドウ内コミットからの経過日数（長期ウィンドウを上限とする）、last_modified_days は 最新の ウィンドウ内コミットからの経過日数です。

これらは、このファミリーの他のシグナルが依拠する新近性の推論を支えます。小さい age_days は 新しい ファイルを示し、新しく追加されたコードは高いリスクを伴います。これはジャストインタイム系の研究と、新たに追加された機能が不釣り合いに欠陥を出しやすかったという Chromium 自身の欠陥分析から得られた観察です。小さい last_modified_days は最近編集されたファイルを示しますが、この性質はウィンドウがすでに重み付けしています。

読み方

age_days の最大の用途は、リスクスコアに供給される新規ファイルトリガーです。直近ウィンドウ内で初めて観測されたファイルは小さな加点を得ます。これは、できたばかりのコードが実行やレビューを経る機会を最も持っていないことを反映しています。last_modified_days は逆方向の陳腐化の読み取りです。何か月も触れられていない高リスクファイルと、今日編集されているファイルとでは、保守上の位置付けが異なります。

変更エントロピー

変更エントロピーは、ファイルに触れるコミットがどれだけ 「分散」 しているかを測ります。ウィンドウごとに change_entropy_long と change_entropy_recent として、ビット単位で報告されます。

このメトリクスは、Ahmed Hassan の 2009 年 ICSE 論文 Predicting Faults Using the Complexity of Code Changes による History Complexity Metric です。アイデアは Shannon エントロピーをコミットに適用したものです。各コミットについて、チャーンが触れたファイル間にどう分布するかを取り、その分布のエントロピーをビット単位で計算します。1 ファイルにしか触れないコミットは 0 となり、チャーンを n ファイルに均等に分散させるコミットは log₂(n) に近づきます。分散した横断的コミットは、焦点の定まったコミットより理解が困難です。Hassan は、この変更プロセスの複雑さが従来のコードベースのモデルや変更回数モデルよりも欠陥をよく予測すると報告しました。後続の研究では、8 つの Apache プロジェクトにおいて、ファイルレベルの変更エントロピーが欠陥数と最大 0.54 の Pearson 相関を示すことが測定されています（共変更エントロピーを参照）。

アルゴリズム

big-code-analysis は各コミットについて、触れたファイル間のチャーン分布の Shannon エントロピー H を計算します（src/vcs/entropy.rs を参照）。次に、参加している各ファイルにそのコミットのチャーンシェア pᵢ·H（Hassan の History Complexity Metric）を付与し、これらのシェアをファイルごと・ウィンドウごとに合計します。拡散した複数ファイルの変更に繰り返し巻き込まれるファイルは高い変更エントロピーを蓄積し、常に焦点の定まったコミットでのみ変更されるファイルは低いままです。

読み方

変更エントロピーは、生のチャーンが同一であっても、大きく散漫な編集の一部として 変更されるファイルと、自己完結したコミットで変更されるファイルを区別します。高い変更エントロピーは 横断的関心事 の兆候です。このファイルへの編集が、いつも多くの他ファイルを巻き込んでいるということです。これは直近ウィンドウのリスク項に加算的に入り、チャーンやコミット数の言い換えではなく補完として働きます。

共変更エントロピー

共変更エントロピーは、ファイルの変更の 影響範囲 がどれだけ広いか、つまりどれだけ多くの異なるファイルと一緒に変更される傾向があるかを測ります。ウィンドウごとに cochange_entropy_long と cochange_entropy_recent として、ビット単位で報告されます。

このシグナルは 2025 年の研究 Co-Change Graph Entropy: A New Process Metric for Defect Prediction（arXiv 2504.18511）に由来します。2 つのファイルが同じコミットで変更されるたびに両者をエッジで結び、共有コミット数を重みとする重み付きグラフを構築します。ファイルの共変更エントロピーは、そのエッジ重み分布の Shannon エントロピーです。常に同じ 1 つの相手とだけ共変更されるなら低く、変更が多くの異なるファイルへ波及するなら高くなります。この研究では、8 つの Apache プロジェクトにおいて、変更エントロピーに共変更エントロピーを加えることで、従来のシグナル集合に対して 82.5% のケースで AUROC が改善したと報告されています。

アルゴリズム

ウォークはコミットごとに、どのスコープ内ファイルが一緒に変更されたかを記録して共変更グラフのエッジ重みを蓄積し、その後ウィンドウごとに各ファイルのエッジ重みエントロピーを計算します。1000 ファイル超に触れる一括インポートコミットは、エッジ数がコミット幅の 2 乗で増えるため共変更グラフから除外されますが、（線形コストの）変更エントロピーには引き続き寄与します。計算結果の 0.0 は、そのウィンドウにファイルの共変更相手が存在しないことを意味し、これは欠測ではなく実際の測定値です。

読み方

変更エントロピーが「このファイルに触れるコミットはどれだけ分散しているか」を問うのに対し、共変更エントロピーは「このファイルに触れると 「他の」 ファイルをいくつ巻き込むか」を問います。高い値は、編集の帰結が予測不能で広範囲に及ぶファイル、すなわち結合のホットスポットを示します。2 つのエントロピーシグナルは互いを補完するよう設計されており、リスクスコア v2 は両方の直近ウィンドウ項を加算します。

複合リスクスコア

リスクスコアは、上記のすべてのシグナルをファイルごとの単一の数値 risk_score に集約します。これは bca vcs の主要な出力であり、ランキングテーブルのソートキーとなるフィールドです。2 つの式が用意されており、どちらも単一の risk_score_version（現在は 2）で一緒にバージョン付けされるため、下流の消費者は変更を検出できます。

重み付き式（デフォルト）

デフォルトの式は、カテゴリカルな乗算的加点を伴う対数スケールの重み付き和です。カウントは ln(1 + x) に通されるため、10 コミットと 20 コミットの差は 110 と 120 の差よりも大きく効きます。これは変更活動が実際に飽和していく様子に合致します。

base = 0.30 · ln(1 + churn_recent)
     + 0.25 · ln(1 + commits_recent)
     + 0.15 · ln(1 + commits_long)
     + 0.15 · ln(1 + authors_long) · (1 + dilution)
     + 0.10 · ln(1 + bug_fix_commits + 2 · security_fix_commits)
     + 0.05 · ln(1 + churn_long)
     + 0.10 · change_entropy_recent + 0.05 · cochange_entropy_recent
     + ln(1 + sloc)² / 100

risk_score = base · (1 + dev_bonus + new_file_bonus)

ここで dilution = 1 - ownership_top_share であり、dev_bonus は長期ウィンドウの作者が 9 人以上で 0.35、6 人以上で 0.15、new_file_bonus は直近ウィンドウ内で初めて観測されたファイルに対して 0.15 です。重みは、本章で引用した文献に項ごとに根拠づけられています。直近のチャーンとコミット頻度が最大の重みを持ち（Nagappan & Ball、JIT 系）、作者ファクターは所有権の希薄化でスケーリングされ（Bird et al.）、RHEL4 の開発者数しきい値で加点され（Meneely & Williams）、セキュリティ修正は 2 倍に重み付けされ、2 つの直近ウィンドウのエントロピー項は加算的に入ります（Hassan、arXiv 2504.18511）。完全な導出は src/vcs/score.rs にあります。

サイズ項 ln(1 + sloc)² / 100 は本物の寄与項であり、和の末尾という位置から想像されるような小さなタイブレーカーではありません。10k SLOC で約 0.85 に達し、およそ 50k SLOC を超えると 1.0 を上回り、チャーン項に匹敵する大きさになります。大きなファイルと欠陥の相関は弱いに過ぎませんが、2 乗対数スケーリングにより、サイズは支配的になることなく第一級の加算シグナルであり続けます。

パーセンタイル式

--risk-formula percentile が代替の式です。各シグナルは解析対象の集合内でのパーセンタイルに再ランク付けされ、ファイルごとのパーセンタイルの平均がスコアになります。これは、文献でチューニングされた重みをプロジェクト横断の頑健性と引き換えにするものです。予測研究の文献は一般に、絶対的なハードしきい値よりも 相対的 トリガーを推奨しています。代償として、スコアは単一の実行のファイル集合内でしか意味を持ちません。

読み方

このスコアは順序尺度です。リポジトリのファイルをこれでソートしてリストの上位を見る、というランキングを生み出すことがこのスコアの存在目的です。生の risk_score を 2 つのリポジトリ間で比較したり、その大きさを欠陥確率として読んだりしないでください。単一ファイルの推移を時間軸で追うには bca vcs trend を使ってください。これは各履歴時点でウォークを再アンカーするため、系列は当時のファイルの実際の姿を反映します。

ホットスポットスコア

ホットスポットスコアは、ファイルの複雑度と直近チャーンの積です（hotspot_score = cyclomatic_sum × churn_recent）。これは Option であり、両方の半分を必要とするため、履歴と併せて AST 複雑度の数値が計算されている場合（たとえば bca metrics --metrics cyclomatic --vcs）にのみ存在します。

このメトリクスは、Adam Tornhill の 2015 年の著書 Your Code as a Crime Scene と、その上に築かれた CodeScene ツール群の中心的なアイデアです。論旨はこうです。複雑さ それ自体 は無視しても安上がりで（誰も触れない複雑なファイルには何のコストもかかりません）、チャーン単独もまた安上がりです。危険なのは両者の交差、すなわち複雑で かつ 頻繁に変更されているコードであり、そこに欠陥が集中し、開発者の労力が繰り返し費やされます。Tornhill は、コードベースのごく一部が変更活動の大半を占めるのが典型だと観察しており、ホットスポットスコアはその一部を見つけるために作られています。

読み方

リスクスコアと同様、ホットスポットの積は順序尺度です。ファイルをこれでランク付けし、大きさそのものは読まないでください。CLI は慣例として複雑度の軸にファイルレベルの cyclomatic 合計を使いますが、どの AST 複雑度の数値でも役割を果たします。このスコアの価値は 優先順位付け にあります。複雑なファイルすべての中から、現に編集されているものを浮かび上がらせます。それらは最も壊れやすく、かつ誰かの画面ですでに開かれている今こそ最も安上がりにリファクタリングできるファイルです。

バスファクター

ownership_top_share が単一ファイル 「内」 の知識集中を測るのに対し、バスファクター（トラックファクター とも呼ばれます）はそれを ファイル集合をまたいで 測ります。その離脱によってディレクトリのファイルの半分超が知識ある保守者を失うことになる、最小の開発者数です。この概念全般には Wikipedia の概説があります。big-code-analysis はこれを、リポジトリ全体、各トップレベルディレクトリ、およびその直下のサブディレクトリを対象とする vcs_aggregate オブジェクトとして出力します。

推定手法は、Guilherme Avelino、Leonardo Passos、Andre Hora、Marco Tulio Valente による 2016 年の ICPC 論文 A Novel Approach for Estimating Truck Factors のものです。各開発者の各ファイルに対する作者性は、彼らの Degree-of-Authorship ヒューリスティックでスコア付けされます。

DoA(d, f) = 3.293 + 1.098 · FA + 0.164 · DL − 0.321 · ln(1 + AC)

ここで FA は最初の作者性（開発者 d がファイル f を作成していれば 1）、DL は d の f への提供（変更）回数、AC は 「他の」 開発者による変更数です。開発者は、ファイルの最大値で正規化した DoA が 0.75（論文のしきい値）を超えるとき、そのファイルの作者とみなされます。

アルゴリズム

トラックファクターは貪欲な除去法で計算されます（src/vcs/bus_factor.rs を参照）。まだカバーされているファイルを最も多く作者として持つ開発者を繰り返し取り除き、--bus-factor-threshold（デフォルト 0.5、Avelino に準拠）を超える割合のファイルが孤児化した時点で停止し、取り除いた開発者数を報告します。集約は 1 回のウォークでスコープ内の全ファイルをカバーするため、by_directory の各エントリは各ディレクトリ配下の全ファイルを再帰的に対象として計算されます。

読み方

バスファクター 1 は、1 人を失うとその集合が孤児化することを意味します。これは、ほぼ単一作者のファイルからなるリポジトリではよくあることで、正しい結果です。この数値は保証ではなく計画のためのシグナルとして扱ってください。長期ウィンドウ内で 観測された 作者性に対するヒューリスティックであり、「最初の作者性」はそのウィンドウで観測された最初のコミットを意味し、必ずしもファイルの真の作成を意味しません。知識が危険なほど集中しているディレクトリを見つけ、それに応じてレビューを分散させるために使ってください。

ジャストインタイムコミットスコア

ここまでのすべては、ある時点での 「ファイル」 をランク付けするものでした。ジャストインタイム（JIT）スコアは代わりに、単一の 「コミット」 をその欠陥誘発リスクについてスコア付けします。これは継続的インテグレーションのゲートがチェックイン時に実際にレビューする単位です。bca vcs commit <commit> が生成し、グループごとの contributions 内訳を伴う順序尺度の risk_score として報告されます。

特徴量グループとその符号は、Yasutaka Kamei らによる 2013 年の IEEE TSE 論文 A Large-Scale Empirical Study of Just-in-Time Quality Assurance に始まり、公開追試の Commit Guru（FSE 2015）および Shane McIntosh と Yasutaka Kamei の Are Fix-Inducing Changes a Moving Target?（IEEE TSE 2018）で確認された、ジャストインタイム欠陥予測の文献から採られています。big-code-analysis は学習済みモデルではなく静的なルールベースのスコアラーを実装しているため、プロジェクトが古びても何もドリフトしません。

アルゴリズム

5 つの特徴量グループがスコアを動かします。各グループはコミットの第一親に対して評価されます（src/vcs/jit.rs を参照）。

グループ特徴量方向
サイズ追加 / 削除行数、変更ファイル数、diff ハンク数大きいほど ⇒ 高リスク
拡散度個別のサブシステム数とディレクトリ数、コミット内変更エントロピー分散しているほど ⇒ 高リスク
履歴触れたファイルの事前値（過去の変更回数、個別作者数、修正回数、およびそれらの複合リスク）をコミット 前 に測定したもの波乱の履歴 ⇒ 高リスク
経験作者のそれまでのコミット数（長期・直近）経験が多いほど ⇒ リスクは低下（このグループは減算）
目的メッセージの修正 / セキュリティ修正 / リバート分類修正は加算、リバートは減衰

contributions ブロックは各グループの符号付き寄与を報告するため、消費者はコミットが 「なぜ」 その位置にランクされたかを確認できます。マージコミットはフラグ付けされ、第一親に対してスコア付けされます。ルートコミットと新規ファイルは構造上、事前値がゼロになるため、スコアはサイズと作者の経験に依拠します。これはファイル履歴のない変更に対して文献が定める通りの挙動です。素の git diff もスコア付けできます（bca vcs commit --diff）が、diff から計算できるのはサイズと拡散度のグループだけなので、その経路は意図的に部分的な partial_risk_score を出力します。

読み方

ファイルレベルのスコアと同様、JIT スコアは順序尺度です。コミットをこれでランク付けするか、リポジトリ自身のコミットスコア分布と比較してください。ただし、その大きさを確率として読んではいけません。想定される用途はチェックインゲートです。bca vcs commit HEAD --fail-above <N> は、コミットのスコアがしきい値以上のとき非ゼロで終了します。しきい値は絶対値として扱うのではなく、自分たちの履歴に照らして調整してください。式に対するいかなる変更も、ファイルレベルの risk_score_version とは独立した jit_score_version を上げます。

次のステップ