コードレビュー自動化はどこまで任せるか｜Will Larsonのsmall-changeの5条件をGitHubで再現して実測

AI のコーディングエージェントでプルリクエスト（PR）が増えると、待ち時間はコードレビューに移ります。では、コードレビューの自動化はどこまで進めてよいのか。Will Larson は 2026年10月17日のブログで、Imprint が試している small-change を公開しました。条件をすべて満たす小さな変更だけを、すぐ承認される道に回す仕組みです。本記事では条件の一つひとつが何を防いでいるかを整理し、GitHub の機能でどこまで再現できるかを、判定スクリプトを書いて確かめます。

CI/CD やワークフローの自動化の全体像は、AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方にまとめています。

AIレビュー後のコードレビューを速くする small-change の仕組み

マージ数とレビュー時間の伸び

Larson によると、Imprint のエンジニア1人あたりのマージ数は2年前の約4倍になり、約10倍になったチームも2つあります。同じ期間に、PR のレビュー時間の中央値は約33分から約77分に延び、その伸びはマージ数の増え方とよく重なっていました。品質の側では、半期どうしの比較でインシデントが42%、重大インシデントが78%減ったと書いています。いずれも Imprint の自己申告の数字で、外部の検証はありません。

Larson 自身はこの問題を「まったく解決していない（absolutely not solved）」と前置きしたうえで、今の試みとして small-change を紹介しています。完成した制度ではなく、初期の実験です。

判定のチェックとラベルの役割

流れは次のとおりです。PR がレビュー待ち（ready）になると、CI/CD が small-change に当てはまるかを判定し、GitHub のチェックとして結果を付けます。このチェックはビルドが管理していて、人が書き換えられません。ラベルも付きますが、それは見えるようにするためで、決め手はチェックの方です。

Imprint では Slack に貼られた PR のリンクに状態を表すリアクション（reacji）を自動で付けています。そこに small-change 用のリアクションを足し、どの PR が速い道に乗っているかを一目で分かるようにしました。

承認の側には review-small-change というスキルがあります。リポジトリの一覧を受け取り、下書きでない small-change の PR を見て、すべてのチェックが通っていて支払いやセキュリティのような領域に触れていなければ承認します。選べるのは「承認」か「何もしない」かの2つだけで、コメントは書きません。AI が出した指摘を読まずにそのまま転送するレビュー（Larson の言う meat proxy review）を広げないためです。

small-change の5条件は何を防いでいるか

条件ごとに防いでいるもの

条件は全部を満たす必要があります。原文の値と、それぞれが防いでいるもの（後者は本記事の整理）を並べます。

バックエンドの上限が3なのは、ふつうの変更でも gRPC のサービスと共有の HTTP ゲートウェイを両方触るからだと説明されています。.small_change はルールを調整している間、パス単位で細かく決めるための置き場です。

人のレビューが残る場所

初期の結果で small-change に当てはまったのは変更の約10%です。残りは今までどおり人がレビューします。支払いとセキュリティは条件を満たしても対象外で、コンプライアンス上の統制として「独立した人のレビュー」が求められているリポジトリもあると原文は書いています。

もう一つの決まりは、small-change が原因の誤りを、承認した人や作者の失敗ではなく仕組みの失敗として扱うことです。直す先は AI のコードレビュー、検証の仕組み、CI/CD の側になります。

GitHub の機能でどこまで再現できるか

標準機能との対応表

GitHub の公式ドキュメント（github/docs リポジトリの原文、2026-10-19 時点）と突き合わせると、small-change の部品は「設定で持てるもの」と「自分で書くもの」に分かれます。

判定を必須チェックにしない理由

small-change の判定は「速い道に乗せてよいか」の目安で、外れた PR も通常のレビューを経てマージできなければ困ります。判定をマージの必須条件にすると、外れた PR が止まります。危険なパスを守る役目は CODEOWNERS と Required reviewers に任せ、判定はラベルとチェックで見せるだけにするのが、原文の分け方にも近い置き方です。

コードレビュー自動化の試作：small-change の判定スクリプトを動かす

設定ファイルと判定スクリプト

GitHub の API を使わず、git の差分と履歴だけで条件を数える判定を Python で書きました。設定はリポジトリの直下に .small-change.json として置きます（ファイル名と項目は本記事の試作で、Imprint の形式ではありません）。

{
  "max_lines": 1000,
  "min_merged": 10,
  "service_root": "services/",
  "max_services": 3,
  "shared": ["libs/"],
  "exclude": ["services/payments/"]
}

services/<名前>/ を1つのサービスとみなし、作者の実績は「そのサービスのディレクトリを触った、基準ブランチ上のその作者のコミット数」で数えます。スカッシュマージなら1コミットが1件の PR に当たる、という前提です。AI レビューの指摘は [{"severity": "p2", ...}] の形の JSON を受け取ります。

#!/usr/bin/env python3
"""small-change の判定（試作）。git の差分と履歴だけで条件を数える。"""
import json, subprocess, sys

def git(*args):
    return subprocess.run(["git", *args], capture_output=True, text=True, check=True).stdout

def judge(base, author, cfg, findings):
    reasons = []
    rows = [r.split("\t") for r in git("diff", "--numstat", "--no-renames", f"{base}...HEAD").splitlines()]
    lines = sum(int(a) + int(d) for a, d, _ in rows if a != "-")
    paths = [p for _, _, p in rows]
    if lines >= cfg["max_lines"]:
        reasons.append(f"行数 {lines} が上限 {cfg['max_lines']} 以上")
    severe = [f for f in findings if f.get("severity") in ("p1", "p2")]
    if severe:
        reasons.append(f"AIレビューの重大指摘 {len(severe)} 件")
    blocked = [p for p in paths if any(p.startswith(x) for x in cfg["shared"] + cfg["exclude"])]
    if blocked:
        reasons.append(f"対象外のパス {blocked[0]}（計 {len(blocked)} 件）")
    root = cfg["service_root"]
    services = sorted({p[len(root):].split("/")[0] for p in paths if p.startswith(root)})
    if len(services) > cfg["max_services"]:
        reasons.append(f"サービス {len(services)} 個が上限 {cfg['max_services']} を超える")
    for s in services:
        n = len(git("log", base, "-F", f"--author={author}", "--format=%H", "--", root + s).split())
        if n < cfg["min_merged"]:
            reasons.append(f"{s} での実績 {n} 件が {cfg['min_merged']} 件未満")
    return reasons

if __name__ == "__main__":
    base, author = sys.argv[1], sys.argv[2]
    with open(".small-change.json", encoding="utf-8") as f:
        cfg = json.load(f)
    findings = []
    if len(sys.argv) > 3:
        with open(sys.argv[3], encoding="utf-8") as f:
            findings = json.load(f)
    reasons = judge(base, author, cfg, findings)
    print("small-change: 該当" if not reasons else "small-change: 対象外\n- " + "\n- ".join(reasons))
    sys.exit(0 if not reasons else 1)

PR のブランチで、基準ブランチと作者のメールアドレスを渡して実行します。該当なら終了コード0、対象外なら1と理由を出します。

git fetch origin main
python3 small_change.py origin/main "$(git log -1 --format=%ae)" findings.json
echo "exit=$?"

陽性・陰性の結果

偽のモノレポ（services/ の下に api・web・batch・search・payments、libs/shared）を作り、alice には各サービスで10〜12件、bob には api で2件のコミットを積んでから、PR に当たるブランチを切って判定しました（2026-10-19、Python 3.13.16・git 2.43.0）。

陽性は全部「該当」、陰性は全部が狙った理由だけで「対象外」になりました。

この判定で分からないこと

この結果は「速い承認に回してよいか」の目安で、変更が安全かどうかの判定ではありません。確かめた範囲には3つの限界があります。

1つ目は作者の実績です。git のコミットの作者欄は書き手が自由に設定できます。bob が alice の名前とメールアドレスでコミットを作ると、判定は「該当」になりました。実運用では PR を開いた GitHub アカウント（Actions なら github.event.pull_request.user.login）を基準に、マージ済みの PR を API で数える方が確かです。この部分は未検証です。

2つ目は数え方の前提です。マージコミットを残す運用では、コミット数とマージした PR の数が一致しません。3つ目は AI レビューの出力です。p1・p2 のような重大度の付け方と出力の形はボットごとに違い、本記事は形を決め打ちしています。GitHub Actions に組み込んでラベルとチェックを付ける部分も、実際のリポジトリでは動かしていません（未検証）。

自分のチームでコードレビュー自動化を試す順番

いきなり承認を速めず、判定を付けて数えるところから始めます。下の順番は原文の仕組みを GitHub に置き換えたときの本記事の提案です。

条件を決めるときは、小さい変更を勧める Google のレビュー指針（Google Engineering Practices完全解説：GitHubで公開されたGoogleのコードレビュー指針を読み解く）が使えます。p1・p2 を出す側のボット選びはAIコードレビューツール比較2026｜CodeRabbit・Greptile・Qodo・Bito・Sourcery・Codacyを使い分け解説で比べました。重大度の付け方まで作り込んだ例として、CloudflareのAIコードレビューシステム解剖｜7専門エージェント並列実行の仕組みと実績も参考になります。

参照ソース

・Speeding up code review with small-change（Will Larson、2026-10-17）
・About protected branches（GitHub Docs）
・Available rules for rulesets（GitHub Docs）
・About code owners（GitHub Docs）
・Managing GitHub Actions settings for a repository（GitHub Docs）
・github/docs: data/features/repo-rules-required-reviewer.yml