Code-Review
変更が第三者にレビューされているか

Scorecard は、直近のコミット（既定では最新30件程度）をさかのぼって、 それぞれが作成者以外のレビューを経て入ったかを確認します。

レビューされたとみなされるのは、たとえば次の場合です。

• Pull Request 経由でマージされ、作成者以外が承認している
• Gerrit などのレビュー基盤の記録が残っている
• コミットメッセージにレビュー済みの記録がある

作成者本人が承認した Pull Request は、レビューとして数えられません。

レビューを経たコミットの割合がそのまま点になるので、 「ときどき直接コミットしている」プロジェクトは中間の点になります。

点が低いということは、変更が誰の目も通らずに入っている、という意味です。

これがリスクになるのは、次のような場合です。

• メンテナーのアカウントが乗っ取られたとき、誰も気づかないまま悪意のあるコードが入る
• 単純な間違いが、そのままリリースまで届く
• 意図しない依存の追加や、権限の広い設定変更が見過ごされる

サプライチェーンの事故として実際に報告されているものの中には、 乗っ取られたアカウントから、レビューを経ずに小さな変更が入ったという形のものがあります。 このチェックはその経路を見ています。

一方、これは「コードの品質が低い」を意味しません。 テストが十分にあり、CI が厳格なら、レビューが無くても品質は保てます。

1. Contributors と一緒に見る。 関わっている人数が1人なら、この点が低いのは当然です。 人数がいるのに低い場合は、運用として直接コミットが行われている可能性があります。

2. コミット履歴を実際に開く。 Merge pull request が並んでいるか、直接コミットが積まれているかを見ます。

3. テストと CI の状況を合わせて見る。 レビューが無くても、CI-Tests が機能していれば、 壊れた変更はマージ前に止まります。

4. 1人プロジェクトなら、その1人が止まったときのことを考える。 レビューの有無より、そのライブラリが更新されなくなったときに 自分たちが困るかのほうが実務的な論点です。 フォークして自前で保守できる規模かどうかを見ておくと安心です。

複数人いる場合

• Pull Request を必須にし、承認1人以上を設定する → Branch-Protection
• 小さな変更でも直接コミットせず、PR を通す運用に揃える

1人で開発している場合

無理に点を上げる必要はありません。 このチェックは第三者の存在を前提にしており、1人では構造的に満たせません。

代わりに、次のことが実質的な効果を持ちます。

• 自分でも PR を通す。 レビューにはならなくても、CI が必ず走る経路になります。
• CI を厚くする。 テスト・型検査・静的解析を通す。 人の目の代わりを、機械にある程度させられます。 → CI-Tests / SAST
• README に開発体制を書く。 「作者1人で保守しています」と書いてあれば、 採用する側は Code-Review の低さを正しく解釈できます。