LabHub

ブログ

現代のコードレビューとMergeパイプライン — PR・Merge Queue・Stacked PRs・Monorepo・AI Review・Trunk-Based・Husky・Semgrep 深掘りガイド (2025)

2026-04-15 · 17 分で読めます · #code-review#pull-request#merge-queue#monorepo#stacked-prs#ai-code-review#trunk-based#git#semgrep#developer-experience

한국어English日本語

コードレビューは仕事の半分だ — なぜほとんど語られないのか

エンジニアが1日に3〜5件のPRをレビューするとしよう。週5日、年50週で年間1,000件に達する。新機能を作る時間より他人のコードを読んで判断して提案する時間の方が多いかもしれない。それなのに、コードレビューについて驚くほど語られていない。「レビューが怖くてPRを大きくする」「承認されず2週間寝かせた」「レビューアが見落としたバグで障害」「AIレビューが自動スパム」— 毎日起きている。

2025年はその風景が激変している。Cursor・Copilot Review・CodeRabbit・Greptileといった AI レビューアが「一次レビューは機械」時代を開き、Graphite・Sapling・Jujutsu が Stacked PRs を主流ワークフローに押し上げ、Merge Queue は GitHub の標準機能になった。Monorepo ツール (Nx・Turborepo・Moon・Bazel・Buck2) も世代交代した。Trunk-based Development は「理想」から「デフォルト」に移った。

本稿は2025年のコードレビューと Merge パイプラインを徹底解剖する。

Platform Engineering と Observability の続編。プラットフォームが「セルフサービス提供」なら、コードレビューは「コード変更の品質ゲート」である。

第1部. PRの社会学 — ブロッカーにならない方法

1.1 レビューが辛い本当の理由

1.2 良いPRの4要素

  1. 小さい単位 — 400行以下推奨 (欠陥検出効率が最大)
  2. 単一の変更 — リファクタリングと機能を混ぜない
  3. 本文に文脈 — 何を・なぜ・どうテストしたか
  4. Self-review から — 作成者が自分でコメントしてから開く

1.3 良いレビューアの4原則 (Google Code Review Guide)

1.4 Conventional Comments

ブロッキング意図と強度を接頭辞で表示し、感情を排除。

praise: テストケースが丁寧です
nitpick: 名前がもっと明確に - userId -> userIdentifier
suggestion: util に抽出すると再利用しやすいです
issue: この状態で race condition の可能性 - TOCTOU
thought: A/B テストが必要かも?
question: retry 回数が3の理由はありますか?

第2部. Code Owner とレビューア割当

2.1 CODEOWNERS ファイル

# /auth/** は security チーム必須レビュー
/auth/**                        @org/security
/packages/payments/**           @org/payments-team
/infrastructure/terraform/**    @org/platform
*.md                            @org/docs

2.2 自動レビューア選定ツール

2.3 レビュー負荷の平準化

第3部. Merge Queue — 2024〜2025 デフォルト

3.1 問題

3.2 Merge Queue の役割

  1. merge 要求をキューに入れる
  2. キュー先頭で「現在の main + この PR」をシミュレーションビルド
  3. 通ったら実 merge
  4. 失敗したら作成者に戻す

Google・Facebook が10年以上社内で使ってきた方式。2023年に GitHub ネイティブ、2024年に標準推奨。

3.3 ツール

3.4 Batched Merge

大型モノレポは一度に複数 PR をバッチ処理。失敗時は二分探索 (bisect) で原因 PR を特定。Meta・Google 規模でのみ必要。

第4部. Stacked PRs — 大型変更を小さく分ける

4.1 問題

4.2 解決

変更を複数 PR にスタックし、それぞれ小さく。先頭 PR が merge されると次の PR が自動で main にrebase。

main <- PR1 (スキーマ) <- PR2 (API) <- PR3 (UI)

各 PR を独立してレビュー。ただし手動スタック管理は rebase 地獄。

4.3 ツール

4.4 Jujutsu が注目される理由

第5部. Monorepo vs Polyrepo — 2025年の結論

5.1 Monorepo が勝つとき

5.2 Polyrepo が勝つとき

5.3 実務合意

Google/Meta は10万人 monorepo。スタートアップは「小さく始めて規模が出たら monorepo に統合」が一般的。2024〜2025のトレンドは「サービスは monorepo、OSS ライブラリだけ別リポ」。

5.4 Monorepo 必須条件

  1. 高速ビルドキャッシュ (Remote Cache)
  2. Affected Detection — 変更プロジェクトだけビルド/テスト
  3. Merge Queue — 大量 PR の並列 merge
  4. Code Owner 自動ルーティング
  5. 規模別 Git 管理 — partial clone, LFS, VFS

第6部. Monorepo ビルドツール — Nx・Turborepo・Moon・Bazel・Buck2・Pants・Lerna の終焉

6.1 JavaScript/TypeScript 中心

6.2 言語中立

6.3 選択ツリー

6.4 Remote Cache

全ツールの共通勝負どころ。Turborepo/Nx は Vercel/Nx Cloud、Bazel は BuildBuddy/Remote Build Execution、Buck2 は独自プロトコル。5分かかっていた CI が 30秒になった事例は大抵 Remote Cache のおかげ。

第7部. AI コードレビュー — 2024〜2025 爆発

7.1 AI が得意なこと

7.2 AI が苦手なこと

7.3 ツール

7.4 AI レビュー導入の実務 Tips

第8部. Trunk-based Development

8.1 定義

8.2 なぜ勝つのか

8.3 Git Flow の死

8.4 Feature Flag ベース開発

第9部. Git 技術 — Rebase・Squash・Linear History

9.1 Merge vs Rebase 論争

9.2 チーム別ポリシー

9.3 共有ブランチへの force-push 禁止

git rebase 後の git push --force は共有ブランチで災難。--force-with-lease で防御。GitHub は最近 Protected Branch で force-push をデフォルト遮断。

9.4 Conventional Commits

feat(auth): add passkey support
fix(payments): handle stripe timeout
refactor(db): extract repository interface
chore: bump deps
docs: update README

第10部. Pre-commit / Pre-push フック — ローカルで CI を速く

10.1 フックマネージャ

10.2 必須フックセット

repos:
  - repo: local
    hooks:
      - id: lint
        name: eslint
        entry: pnpm lint --fix
        language: system
      - id: typecheck
        entry: pnpm typecheck
        language: system
      - id: test
        entry: pnpm test:affected
        language: system
      - id: secrets
        entry: gitleaks protect --staged
        language: system

10.3 フックが嫌われる理由と対策

第11部. 静的解析 — Semgrep・SonarQube・CodeQL・ESLint

11.1 Semgrep

11.2 SonarQube / SonarCloud

11.3 GitHub CodeQL

11.4 ESLint・Biome・Oxlint

11.5 セキュリティ特化

第12部. CI 速度 — PR merge が10分以下であるべき理由

12.1 Compound effect

12.2 改善戦略

12.3 Flaky Test

第13部. 実務 — チーム規模別コードレビューパイプライン

13.1 5人チーム

13.2 50人チーム

13.3 500人以上

第14部. チェックリスト12・アンチパターン10

チェックリスト12

  1. 平均 PR サイズが 400行以下か?
  2. PR merge まで P50 24時間以下か?
  3. CODEOWNERS が最新で機能しているか?
  4. Merge Queue が付いていて semantic conflict を遮断しているか?
  5. Stacked PRs がチームの通常ワークフローか?
  6. Conventional Commits が適用されているか?
  7. pre-commit/pre-push フックが高速 (10秒以内) で有用か?
  8. Biome/Oxlint のような高速 linter に移行したか?
  9. CI が平均 10分以下で終わるか?
  10. Flaky test 検出/隔離システムがあるか?
  11. AI レビューアのスパム比率が5%以下か?
  12. Trunk-based + Feature Flag が標準か?

アンチパターン10

  1. 1,000行 PR を「レビュー済」と署名
  2. PR タイトル・本文が空
  3. Long-lived feature branch が1ヶ月以上
  4. --no-verify でフック習慣的に迂回
  5. AI レビューの承認だけで merge
  6. Merge Queue なしで同時 merge → silent conflict
  7. Flaky test を if (retryCount < 3) で覆い隠す
  8. CODEOWNERS 未管理 → 自動レビューアが幽霊アカウント
  9. チーム全体のレビューが1人のシニアに集中
  10. Rebase/Squash ポリシーがチーム内で不一致 → 履歴混乱

次回予告 — 「エンジニアリングブログの時代: 技術ライティング・RFC・ADR・Design Doc・ブログ運営・コミュニケーション」

コードレビューを語ったなら、次は技術ライティング。RFC、ADR、Design Doc、社内 Wiki、外部ブログ。文章がうまいエンジニアは影響半径が10倍。

コードは結局、人々の間で生き残る。次回、その生存戦略を見る。

原文を読む: https://www.youngju.dev/blog/culture/2026-04-15-code-review-pr-merge-queue-monorepo-stacked-prs-ai-review-trunk-based-husky-semgrep-deep-dive-guide-2025.ja

コメント

まだコメントはありません。

ログインするとコメントできます