Skip to content
Published on

コードレビュー自動化 2026 — Graphite / Aviator / Mergify / Greptile / CodeRabbit / Copilot Code Review 徹底ガイド

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

「レビューはコードを読むのではなく、意思決定を読む仕事だ。AIはコードは読めても意思決定は読めない。」 — あるスタッフエンジニア

本記事は 2026年5月時点のコードレビュー自動化市場マップである。2024年にGitHub Copilot Code Reviewがプレビュー登場し、2025年にGAとなって以来、AIコードレビューは「目新しい新商品」ではなく「当然オンになっているデフォルト」になった。並行してCodeRabbit、Greptile、Bito、Sourceryといった専業AIレビューSaaSが急成長し、Graphiteは「スタックPR」ワークフローを主流に引き上げ、AviatorとMergifyはマージキュー市場でGitHubネイティブと競い合っている。

本記事ではAIレビューSaaS(CodeRabbit, Greptile, Bito, Sourcery, Tab, Codium)、プラットフォーム統合型(GitHub Copilot Code Review, Cognition Devin)、ワークフローツール(Graphite, Aviator, Mergify, Reviewable, Reviewpad)、品質/セキュリティ視点(Sonar, Snyk Code, Aikido)を網羅的に比較する。最後に韓国のトス/カカオ、日本のメルカリの事例を取り上げ、「我々のチームはどう組むべきか」の意思決定ガイドで締めくくる。

1. 2026年のコードレビュー自動化マップ — 4分類

2026年のコードレビューツールを把握するには、まず分類が必要だ。「全部AIレビュー」のような粗い見方ではツール選定にならない。

  • AIレビューSaaS: CodeRabbit, Greptile, Bito, Sourcery, Codium, Tab Code Review
  • プラットフォーム統合型: GitHub Copilot Code Review, GitLab Duo Code Review, Cognition Devin
  • ワークフローツール(スタックPR / マージキュー / ルール): Graphite, Aviator, Mergify, Reviewpad
  • レビューUI代替: Reviewable, Gerrit, Phabricator(レガシー)
  • 品質/セキュリティレビュー(分離レイヤ): Sonar(SonarLint/SonarQube/SonarCloud), Snyk Code(旧DeepCode), Aikido, Semgrep, Codiga(JetBrains/Datadogに吸収)

この4分類は責任境界が異なる。AIレビューSaaSは「人間のレビュアーが見落としそうなもの」を拾い、プラットフォーム統合型は「どうせPRページ上で見ていたものをもう一段自動化」し、ワークフローツールは「PRそのものをどう作りどう統合するか」を扱い、品質/セキュリティツールは「決定論的な静的解析で拾えるもの」を別個に見る。

最もよくある誤解は「AIレビューが静的解析を置き換える」というものだ。2026年時点でもそうではない。Sonar/Snyk/Semgrepが拾う決定論的ルール(SQLインジェクションパターン、未使用変数、ライセンス違反)はAIレビューが苦手で、逆にAIレビューが得意な「このPRの意図がこの関数に合っていない」のような文脈意見は静的解析にはできない。2つのレイヤを分離して並べて入れておくのが2026年のベストプラクティスだ。

もう1つの大きな潮流はスタックPRである。Meta社内で使われていたPhabricatorのstacked diff文化が、Graphite/Sapling/GitButlerを経由して一般企業に広がった。「大きなPR1つ」ではなく「小さく依存し合うPRを複数」積み上げるワークフローだ。これは単なるツール変化ではなく、レビュー単位そのものを変えるパラダイムシフトである。

2. CodeRabbit — AIレビューの代表

CodeRabbitは2023年に米国で始まり、2024-2025年の間にAIレビューSaaSの事実上の代表格となった。GitHub Appとしてインストールすると、PRが開いた瞬間に自動レビューコメントが付く構造だ。

動作方式:

  • PR diffを受け取りLLM(Anthropic Claude, OpenAI GPT, 一部社内ファインチューン)が解析
  • 変更ファイルとその依存ファイルを文脈として投入(RAG方式でコードベースをインデックス)
  • 行単位コメント + PRサマリ + シーケンス図(mermaid)の自動生成
  • 「@coderabbitai」メンションで追加質問が可能(インタラクティブレビュー)
# .coderabbit.yaml — リポジトリ直下に置くと動作をチューニング
language: ja-JP
reviews:
  profile: assertive          # chill / assertive
  request_changes_workflow: true
  high_level_summary: true
  poem: false                  # ポエム生成オフ(有名なデフォルト)
  sequence_diagrams: true
  path_filters:
    - "!**/*.lock"
    - "!**/generated/**"
  path_instructions:
    - path: "src/api/**"
      instructions: "API変更時はOpenAPI仕様との同期を確認すること。"
chat:
  auto_reply: true

CodeRabbitの強み:

  • PRサマリとシーケンス図が標準で良い。レビュアーが大きなPRを素早く把握するのに有効
  • インタラクティブチャット: コメントに返信するとLLMが追加解析を回す。「なぜ危険なのか」を説明
  • 言語多様性: Python/JS/TS/Go/Rust/Java/Kotlin/Swift/PHP/Rubyを全カバー、韓国語/日本語レビューも対応
  • 価格が比較的透明。開発者あたり月額
  • OSSは一定枠まで無料

CodeRabbitの弱み:

  • ノイズが多いというのが最も多い批判。「この関数にコメントを追加するとよい」のような軽いnitを多用する → profile: chillやpath filterで調整が必要
  • コードベース全体を見ないと意味ある意見(例: 「この関数はすでにutilsに存在する」)は出にくい。RAGは助けにはなるが限界がある
  • セキュリティ脆弱性検出はSnyk/Semgrepより弱い → セキュリティは別途入れろという公式立場

誰が使うべきか: PRが日に10件以上立つ中規模~大規模チーム、レビュアーが多忙で一次コメントだけでも自動化したい現場、OSSメンテナで外部貢献者のPRが多いプロジェクト。

3. Greptile — コードベース理解 + AIレビュー

Greptileは2023年に米国で始まり、「コードベース全体を理解するAIレビュアー」を標榜する。CodeRabbitがPR中心なら、Greptileはコードベースインデキシング中心だ。

Greptileの差別化:

  • グラフベースのコードベースインデキシング: 関数/クラス/モジュールをノード、呼び出し/import関係をエッジとしたコードグラフを構築する。PR変更が他に与える影響をグラフ探索で見つける。
  • API優先設計: SaaSダッシュボードよりAPI/CLI/Slack/Linear統合が強み。自前ワークフローへの差し込みやすさ。
  • **「このPRが既存コードを壊す可能性」**を明示的に解析。他ツールは変更行自体しか見ないが、Greptileは変更関数を呼ぶ全呼び出し箇所まで見る。
  • Y Combinator出身(2023 W23)
# Greptile APIの例 - リポジトリをインデックス
curl -X POST https://api.greptile.com/v2/repositories \
  -H "Authorization: Bearer $GREPTILE_API_KEY" \
  -H "X-GitHub-Token: $GH_TOKEN" \
  -d '{
    "remote": "github",
    "repository": "myorg/my-monorepo",
    "branch": "main"
  }'

# 自然言語クエリ
curl -X POST https://api.greptile.com/v2/query \
  -H "Authorization: Bearer $GREPTILE_API_KEY" \
  -d '{
    "messages": [{"role": "user", "content": "注文作成フローで決済検証はどこで行われている?"}],
    "repositories": [{"remote": "github", "repository": "myorg/my-monorepo", "branch": "main"}]
  }'

Greptileの強み:

  • モノレポで光る。数十万行のコードベースでも「このPRが影響を与える下流関数12個」を見つけ出す
  • 副次ツールとしての価値: レビュー以外にも「このコードはなぜこう書かれているか説明して」のコードベースQ&A用途で使うチームも多い

Greptileの弱み:

  • UI/ダッシュボード完成度はCodeRabbitより劣る。開発者がAPI/CLIフレンドリーだと使いこなしやすい
  • 初回インデキシングが大規模モノレポでは時間がかかる(数十分~数時間)

誰が使うべきか: モノレポで運用する中~大規模組織、コードベース依存関係を理解したレビューが必要なチーム、API統合で自前ワークフローを組みたい現場。

4. Bito / Sourcery / Codium / Tab — その他のAIレビュー

Bitoは2022年に米国で始まったAIコーディングアシスタントで、2024年からPRレビュー機能(AI Code Review Agent)を本格的に投入している。強みは開発者IDE統合(VS Code, JetBrains)が一緒についてくることだ。レビューを見るだけでなく、IDE内で「この関数を説明して」「テストを書いて」までできる。Ciscoが2024年にBitoの一部機能を自社ツールに統合した。

Sourceryは2019年に英国で始まった。最初はPythonリファクタリング自動化で有名になり、2024年からAIレビューへ領域拡大した。Pythonエコシステムに深く入り込んでいるため、「もっとPythonicに書き直そう」のような意見をうまく出す。JS/TSもサポートするがPythonほどではない。

Codium(あるいはCodiumAI)は2022年にイスラエルで始まった。最初はテスト自動生成で有名になり、その流れでPRレビューにまで領域を広げた。PR-Agentというオープンソースツールも並行運営している(github.com/qodo-ai/pr-agent、社名は2024年にQodoへリブランド)。最大の差別化はセルフホスト可能なことだ。データを自社クラスタ外に出せない金融/公共の組織が好む。

# Qodo/Codium PR-Agent - ローカルまたはセルフホストで実行
docker run --rm -it \
  -e OPENAI_KEY=$OPENAI_KEY \
  -e GITHUB_TOKEN=$GH_TOKEN \
  -e CONFIG.GIT_PROVIDER=github \
  codiumai/pr-agent:latest \
  --pr_url https://github.com/myorg/myrepo/pull/123 review

Tab Code Reviewは2023年頃に始まった新興だ。差別化は多様性/包括性(DEI)観点でレビューを見る点。コードの変数名、コメント、UIテキストに差別的表現が含まれないか、アクセシビリティ(a11y)違反はないかを自動チェックする。大企業よりも価値整合性を重視するOSSプロジェクトが導入する。

ツール比較マトリクス:

ツール強み弱み価格
CodeRabbit自動サマリ、シーケンス図ノイズ多い開発者あたり月額
Greptileコードグラフ、モノレポUI弱いシート + API
BitoIDE統合同伴レビュー単独は平凡開発者あたり月額
SourceryPythonリファクタ他言語弱い開発者あたり月額
Codium (Qodo)セルフホスト、OSS PR-Agent自社SaaS UIは発展途上OSS無料 / SaaS別途
TabDEI/アクセシビリティ観点一般レビューは補助的シート基盤

5. GitHub Copilot Code Review — 2024プレビュー → 2025 GA

GitHubは2024年秋のGitHub UniverseでCopilot Code Reviewを発表した。最初はベータ/プレビューで、2025年に一般提供(GA)となった。2026年時点ではGitHub Enterprise Cloudユーザーにとって事実上の標準オプションだ。

動作方式:

  • PRを開く、またはPRに「@copilot review」とコメント
  • Copilotがレビュアーとして自動アサインされ、行コメントを付ける
  • コメントは「Copilotが提案する変更」として、GitHubの「Apply suggestion」UIから1クリック適用可能
  • リポジトリ直下に.github/copilot-instructions.mdを置くとコンベンション学習が可能
<!-- ファイル: .github/copilot-instructions.md (サンプルコンベンション) -->
# Copilot Code Review ガイドライン (サンプル)

## 一般
- 関数は60行以下を推奨する。
- すべてのpublic APIにはJSDoc/TSDoc/godocを要求する。

## TypeScript
- 新規コードはstrictモード前提。any型は拒否。
- Reactコンポーネントは関数型のみ。

## テスト
- src/配下の変更があれば、同じディレクトリの.test.tsも変更されているか確認。
- E2Eテストはe2e/に配置。

Copilot Code Reviewの利点:

  • GitHubネイティブ: 別途インストール不要、有効化するだけ。データがGitHubの外に出ない(エンタープライズのデータガバナンス上有利)
  • Apply suggestion UI: 提案を1クリックで適用可能。CodeRabbit/Greptileがコメントを付けるだけなのとの差別化
  • 組織レベルのポリシー: GitHub Enterprise管理者がどのリポジトリで有効にするかを中央管理可能
  • 価格がCopilotサブスクリプションに含まれる(Business/Enterpriseプラン)

弱点:

  • 品質にばらつきがあるとの評がよく聞かれる。nit的コメントが多く、深い意見が少ない
  • リポジトリ文脈活用はCodeRabbit/Greptileより浅い(改善中)
  • セルフホスト(GitHub Enterprise Server)ではモデル/レイテンシに差がある

2026年のパターンは「Copilot Code Reviewをデフォルトでオンにしつつ、特定リポジトリにはCodeRabbitやGreptileを追加して深掘り」だ。データガバナンスで外部ツールが使えない組織はCopilotのみという場合も多い。

6. Graphite — スタックPR + AI

Graphiteは2021年に米国で始まった会社だ。Meta/Airbnb出身のエンジニアが作り、コア製品はスタックPR(stacked PR)ワークフローである。2024-2025年の間にDiamondというAIレビュー機能を追加し、レビュー自動化領域にも進出した。

スタックPRとは何か。大きな変更を1つのPRで一度に出す代わりに、小さなPRを複数に分割して上に積み上げていく方式だ。PR AがmainにあってPR BがAの上、PR CがBの上にある。各PRが小さいのでレビューが楽で、依存関係が明示的なのでマージ順序が明確だ。

# Graphite CLI (gt) の基本
gt create feat/add-user-table          # 最初のPR (A)
# ...コード変更...
gt submit                              # PR Aをプッシュ + 作成

gt create feat/add-user-api            # 2つ目のPR (B) - Aの上にスタック
# ...コード変更...
gt submit                              # PR Bをプッシュ + 作成

gt create feat/add-user-ui             # 3つ目のPR (C) - Bの上にスタック
# ...コード変更...
gt submit                              # PR Cをプッシュ + 作成

# スタック全体を同期 (Aがマージされたら B/C を自動リベース)
gt sync
gt restack

Graphiteの中核機能:

  • gt CLI: スタックPRを作る全コマンド。gitベースだがスタック認識付き
  • Graphite Web: PRをスタック木として可視化。レビュアーが「これはスタックの3番目のPR」という文脈を即座に把握
  • Diamond (AIレビュー): 2024年追加。変更の意図/リスク評価、コードスメル検出
  • Merge Queue: GitHubのマージキューと類似だがスタックPRをファーストクラスサポート
  • Insights: PRサイクルタイム、レビュー待ち時間などのメトリックダッシュボード

スタックPRの利点:

  • レビュー単位が小さくなる: 200行のPR 5つ vs 1000行のPR 1つ。前者のレビュー品質が圧倒的に高いというのがGraphiteの主張
  • 速いフィードバック: Aがレビューを受ける間にB/Cを進められる
  • ロールバックが容易: 問題のあるPR 1つだけ戻せばよい

スタックPRの欠点:

  • 学習曲線: gitを熟知していてもrebase/restackの衝突処理は別途学習が必要
  • GitHub UIがスタックをファーストクラス扱いしない → Graphite Webを見ないと全体像が見えない
  • チーム全員が使わないと効果が出ない。一部だけ使うとPRがごちゃ混ぜになる

誰が使うべきか: PRサイクルタイムを短縮したいすべてのチーム、小さなPRに頻繁に分けたい開発者、モノレポで複数の変更を並行進行する必要のある組織。Vercel, Plaid, Asanaなどがユーザーとして知られる。

7. Aviator — マージキュー + AI

Aviatorは2021年に米国で始まった。最初から**マージキュー(merge queue)**市場を狙った。コア価値: 「複数のPRをマージする際、CIが毎回mainを壊さないよう自動で直列化する」。

マージキューの問題定義:

  • 開発者5人が同時にPRをマージしようとする
  • 各PRは自分のスナップショット時点のmain上でCIがグリーンだった
  • だが5人が同時にマージすると、合成されたmainでは衝突したりテストが落ちたりする
  • 「マージ直前のmain上でもう一度テスト」が必要だが、これをPRごとに人手でやるのは非効率

マージキューはこれを自動化する:

  1. ユーザーがPRを「ready to merge」とマーク
  2. マージキューがPRをキューに入れる
  3. キュー先頭のPRをmain最新の上にリベースしてCIを回す
  4. グリーンならマージ、レッドならキューから除外 + 通知
  5. 次のPRへ

Aviatorの差別化:

  • Speculative parallel testing: キュー上の複数PRを先回りで並列テスト開始 → キュースループット最大化
  • Affected tests: 変更範囲を解析し影響を受けるテストだけ回す。CI時間短縮
  • FlexReview/MergeQueue/Stacked PRs: マージキュー以外にスタックPRもサポート
  • CI統合: GitHub Actions, CircleCI, Buildkiteなどと自然に動く
  • VCS多様性: GitHubだけでなくGitLabも対応
# .aviator.yml 例 (簡略化)
merge_rules:
  labels:
    trigger: ready-to-merge
  required_checks:
    - "ci/build"
    - "ci/test"
    - "lint"
  branch_protection_rules_enforcement: true
  merge_strategy:
    name: squash
queue_settings:
  parallel_mode:
    use_parallel_mode: true
    max_parallel_builds: 10

Aviatorの弱み:

  • 価格が高い側。中規模~エンタープライズ向け
  • GitHubネイティブのマージキューが2023年にGAしてから「なぜAviatorを別途買うのか」という問いが増えた → Aviatorの答えは「並列化/affected tests/マルチVCS」

誰が使うべきか: PRが日に50件以上マージされる大規模モノレポ、CIが高価な組織、マージキューを既に運用していて限界を感じているチーム。

8. Mergify — 自動化ルールのクラシック

Mergifyは2017年にフランスで始まった。マージ自動化領域で最も歴史の長いツールの1つだ。コアはYAMLで記述するマージルールエンジンである。

# .mergify.yml 例 - 依存性の自動マージ
queue_rules:
  - name: default
    queue_conditions:
      - "#approved-reviews-by>=1"
      - check-success=ci
      - label=automerge
    merge_method: squash

pull_request_rules:
  - name: Automatic merge for Dependabot
    conditions:
      - author=dependabot[bot]
      - check-success=ci
      - "#approved-reviews-by>=1"
    actions:
      queue:
        name: default

  - name: Request review from frontend team
    conditions:
      - files~=^web/
    actions:
      request_reviews:
        teams:
          - frontend

  - name: Label backend changes
    conditions:
      - files~=^server/
    actions:
      label:
        add:
          - area/backend

Mergifyの強み:

  • 表現力: ラベル/レビュー/CI状態/ファイルパス/作者などほぼ何でも条件にできる
  • マージキュー内蔵: queue_rulesでマージキューも一緒に運用
  • Dependabot/Renovateフレンドリー: 依存性PR自動マージの標準ツール
  • SaaS + セルフホストオプション(エンタープライズ)
  • OSS無料(パブリックリポジトリ)

Mergifyの弱み:

  • AIレビュー機能はなし(他ツールと併用が必要)
  • YAMLルールが複雑になるとデバッグが大変
  • Mergify自体が落ちるとマージが止まる外部依存

2026年の見方: Mergifyは「AI時代のクラシック」だ。新規チームはGitHubネイティブのマージキュー + Copilot Code Reviewから入るが、既にMergifyを精緻に組んだ組織はそのまま維持する。ルールの表現力はGitHubネイティブが追いつかない。

誰が使うべきか: Dependabot/RenovateのPRが日に数十件立つOSSメンテナ、複雑なマージルールが必要な組織、複数リポジトリで一貫したポリシーを強制したいプラットフォームチーム。

9. Reviewable — UI代替

Reviewableは2015年頃に始まった。GitHubのPRレビューUIに満足できない人のためのレビューUI代替である。技術自体はGitHub PRの上に乗り、GitHubと双方向にコメントが同期する。

Reviewableの強み:

  • ファイルごとのレビュー状態追跡: 「このファイルは見た / 最後に見て以降変わった / 見ていない」を明示的に表示
  • N回ラウンドレビュー: GitHubのようなコメントタイムライン1本ではなく、ラウンドごとに変更累積/解決をきれいに見られる
  • ショートカット中心のUI: キーボード中心で素早くレビュー
  • きめ細かい通知制御: GitHub標準よりはるかに細かい

Reviewableの弱み:

  • UIがGitHubと違うので学習が必要
  • 市場モメンタムが弱い(GitHub UIの漸進改善 + AIレビューの台頭でUI代替需要が減少)
  • AIレビュー機能は別途

依然としてGoogleの一部チーム、精密なコードレビューが必要なRust/システムプログラミングチームがReviewableを好む。Reviewpad(2021年開始)は類似の自動化ルール市場を試みたが、2024年頃に活動が減少したように見える(Mergifyとの競争で押された側面)。結果として自動化ルール市場はMergify, GitHubネイティブ, Aviatorに整理された。

誰が使うべきか: GitHub PR UIに満足できない精密レビュー文化のチーム、N回ラウンドレビューが頻繁なシステムソフトウェア組織。

10. AIレビューのnoise vs signal — どうチューニングするか

AIレビューの最もよくある失敗は「ノイズに埋もれて人が無視する」ことだ。導入初週は新鮮だが、1か月経つと「AIコメントは取り敢えず無視」という文化が出来上がり、本当に重要な意見まで埋もれる。

2026年のベストプラクティス束:

1) 軽いモードから始める

CodeRabbitなら profile: chill、Copilot Code Reviewなら最初は小さなリポジトリだけで有効化する。nit比率を下げ、「バグ/リグレッションの可能性」中心にチューニング。

2) パスフィルタを積極的に使う

# 意味のない自動生成 / ロックファイルはレビュー除外
path_filters:
  - "!**/*.lock"
  - "!**/*.generated.*"
  - "!**/dist/**"
  - "!**/build/**"
  - "!**/node_modules/**"

3) コンベンションを文書化する

リポジトリ直下に .github/copilot-instructions.md を置くか、.coderabbit.yaml の path_instructions でチームコンベンションを明示。AIが同じnitを繰り返すのを減らせる。

4) 「必須承認」ゲートにAIを入れない

AIレビューコメントをマージブロック条件にしない。決定論的でないのでブロックゲートには不向き。AIは「追加情報を提供する」レイヤ、ブロックゲートは人間レビュー + 決定論的ツール(Sonar, Snyk)。

5) 「人間レビュアー1人 + AI」を推奨パターンと見なす

「AI一次コメント → 著者修正 → 人間レビュアー1人の最終確認」が最も安定する。AI単独承認は危険で、人間のみは遅い。

6) 効果測定指標を定義する

  • PRサイクルタイム(PR作成~マージまでの時間)
  • 一次レビュー応答時間(PR作成~最初のレビューコメントまで)
  • AIコメント採用率(AIコメントのうち著者が修正に反映した比率)
  • マージ後ホットフィックス率(リグレッション指標)

導入前後でこの4つがどう動くかを見ないと、「導入したが良くなったのかわからない」状態になる。

11. セキュリティ/品質レビューの分離 — Sonar / Snyk Code / Aikido

コードレビュー自動化でよく混同されるのが「AIレビューがセキュリティまでやってくれるのでは?」だ。答えは部分的にしかである。決定論的なセキュリティ解析は別のツールが必要だ。

Sonar (SonarLint / SonarQube / SonarCloud)

  • SonarSource(ルクセンブルク)が作る静的解析の代表
  • SonarLint = IDEプラグイン(リアルタイム解析、無料)
  • SonarQube = セルフホストサーバ
  • SonarCloud = SaaS
  • 30+言語、コードスメル/バグ/セキュリティホットスポットをルールベースで検出
  • 2024年にSonarLintが「SonarQube for IDE」へリブランド(ブランド統一)

Snyk Code (旧DeepCode)

  • DeepCodeは2016年にチューリッヒで始まったMLベース静的解析。2020年にSnykが買収しSnyk Codeとなった
  • 差別化: MLで学習したセキュリティパターン(単純ルールではなくコード文脈ベース)
  • Snyk Open Source(依存性)/Snyk Container/Snyk IaCと同じプラットフォーム上で動作
  • SASTカテゴリの強者。SQLインジェクション、XSS、SSRFなどのセキュリティ脆弱性をPR時点で検出

Aikido

  • 2022年にベルギーで始まる。「AppSecを一か所で」を標榜。SAST/DAST/SCA/IaC/Container/Cloud Postureを統合
  • Snykより合理的な価格と素早いセットアップが強み
  • 2024-2025年にスタートアップ/中規模で急速に導入拡大

Semgrep

  • 2017年にr2cが作るルールベースSAST。OSSコア + SaaS(Semgrep Cloud)
  • ルールをYAMLで直接書けるためカスタムが強力
  • OSSメンテナとセキュリティチームが好む

Codiga

  • 2020年開始の静的解析。2023年にDatadogが買収しDatadog Code Analysisに吸収。単独ブランドとしては消えた
  • Datadog APM/監視と同一画面で見られるのが差別化

推奨組み合わせ:

  • IDE: SonarLint(=SonarQube for IDE) もしくはSnyk IDEプラグイン
  • PRゲート: Snyk Code + Semgrep(または Aikidoで一括)
  • AIレビュー: 上記とは別レイヤでCodeRabbit/Greptile/Copilot
  • 人間レビュー: 最終1人

重要: AIレビューが「セキュリティもやる」と謳っていても、決定論的セキュリティゲートは別途運用すること。AIは非決定論的なため規制/監査要件を通せない。

12. スタックPR運動 — Graphite vs Sapling vs GitButler

スタックPRワークフローのツール競争は2024-2026年で大きく3つに整理された。

Graphite

  • 上で見たSaaS。gt CLI + Graphite Web + Diamond AI
  • 完成度が最も高く、チーム協業に強い
  • 価格: シート基盤。無料枠あり

Sapling (Meta)

  • Metaが2022年にオープンソース公開したVCS。Mercurial後継 + Meta社内ツールslの外部版
  • gitリポジトリの上でも動作(slがgitのフロントエンドとして動作)
  • スタックdiffワークフローがネイティブ
  • 無料(オープンソース)。欠点はGitHub UI統合が弱く、チーム単位の採用事例が少ない
# Sapling 基本コマンド (sl)
sl clone https://github.com/myorg/myrepo
sl status                      # git status相当
sl commit -m "first change"    # 最初の変更
sl commit -m "second change"   # 2つ目の変更(自動的に最初の上にスタック)
sl pr submit                   # スタックのPR群をGitHubへプッシュ

GitButler

  • 2024年頃に本格登場したクライアント。同じ作業ディレクトリ上で複数の仮想ブランチを同時管理
  • スタックPRの変種: 「複数の作業を分離したブランチ/PRとして同時並行」
  • TauriベースのデスクトップApp
  • 個人開発者/小規模チームに親和性

3ツールの比較:

ツール位置強み弱み
GraphiteSaaS + CLIチーム協業、Web UI、AI有料、GitHub依存
SaplingOSS VCSMeta検証済み、ネイティブスタックUI弱、採用少
GitButlerOSSデスクトップ仮想ブランチ、個人ワークフローチーム協業機能弱

2026年の潮流: チーム単位導入はGraphiteが優勢、個人開発者ワークフローはGitButlerが急成長中。Saplingは「Meta出身エンジニアがいるチーム」が時々導入。

スタックPRを導入するかしないかはツールの問題ではなくチーム文化の問題だ。「大きなPRに慣れたチーム」にスタックPRを強制すると抵抗が大きい。通常は「小さなPRを好むシニア1-2人がまず始める → 効果確認 → 漸進拡大」がうまくいく。

13. マージキュー — GitHubネイティブ vs Mergify vs Aviator

マージキューは2023年にGitHubがネイティブ機能をGAしてから市場が再編された。2026年時点の比較:

GitHubネイティブマージキュー

  • GitHub Enterprise Cloud/Teamに含まれる
  • セットアップ5分: Settings → Branches → Merge queueを有効化
  • 基本機能のみ(直列マージまたは単純並列)
  • 別途費用なし
  • Affected tests解析/スタックPRファーストクラス/マルチVCSは不可

Mergify

  • マージキュー + 広範な自動化ルール
  • YAML表現力が圧倒的
  • Dependabot/Renovate PR自動マージの標準
  • 価格: OSS無料、プライベートリポジトリは有料

Aviator

  • マージキュー + AI + スタックPR + speculative parallel testing
  • 大規模モノレポではCI時間短縮が最大の価値
  • 価格: 中規模~エンタープライズ

選定ガイド:

  • PRが日5件以下: GitHubネイティブで十分
  • Dependabot PRが多い、またはルールが複雑: Mergify
  • CIが高価でPRが多い(50+/日): Aviator
  • セルフホストが必要: Mergify Enterprise または Aviator on-prem

マージキューの罠: 「キューが詰まると全部詰まる」。キュー先頭のPRのテストがレッドだと後続も全部止まる。だからマージキュー導入と同時にCIのflake率を下げる作業が必要だ。Flakeが1%でもあるとキューが頻繁に詰まる。

もう1つ: マージキューを有効化するとPR作者の認知モデルが「マージを押す」から「キューに入れる」へ変わる。この変化をチーム全体に一度に案内しないと、最初の数日は混乱する。

14. 韓国 / 日本 — トス、カカオ、メルカリ

トス(Toss)は2023年頃からコードレビュー自動化に積極的だ。社内ツールを一部内製し、GitHub Copilot Code Reviewを組織単位で有効化した。トス技術ブログ(toss.tech)に「PRサイズガイドライン」や「レビュー応答時間SLA」のような文化記事が定期的に投稿される。トスの興味深い点は「AIレビューのノイズを減らす独自のポストプロセッシングレイヤ」を社内に作ったことだ。AIレビュー → 自前フィルタリング → PRへコメント投稿の順で動作する。

カカオ(Kakao)グループはカカオエンタープライズ、カカオバンク、カカオペイがそれぞれ異なるアプローチを取る。共通して自社GitLabインスタンスを運用するところが多く、GitLab Duo Code Reviewを評価中だ。カカオバンクは金融機関特性上セキュリティレビューが非常に厳格で、Sonar + 自社セキュリティルール + 人間レビューが必須。AIレビューは補助的位置づけ。カカオエンタープライズは社内LLMインフラを活用した独自コードレビューBotを一部試験中。

LINE(現LY Corporation)はモノレポ運用経験をOSSカンファレンスでよく共有する。2024年頃から一部チームでGraphiteまたは類似のスタックPRワークフローを導入した事例が知られている。社内では自社ビルドシステムと結合したaffected testsの自動解析が核心。

メルカリ(Mercari)は日本で開発者生産性(developer productivity)事例を最も活発に公開している会社の1つだ。Mercari Engineeringブログにコードレビューに関するSLA、DORAメトリクス、CI/CDパイプライン最適化の記事が定期的に上がる。マージキューはGitHubネイティブ + 一部自社ツールの組み合わせ。AIレビューはCopilot Code Reviewを社内標準として導入したと言われている。

サイボウズ / クックパッド / DeNAは日本のSaaS/サービス会社で、それぞれコードレビュー文化事例をブログで公開している。サイボウズはモノレポ + 自社ツール、クックパッドはGitHub + Mergify、DeNAはゲーム/エンタープライズが混在する多様な環境。

韓国/日本の共通パターン:

  • AIレビューは導入中だが補助的位置。人間レビューが最終権限
  • 金融/エンタープライズはデータガバナンスで外部SaaS利用に制限 → セルフホスト可能なQodo/PR-Agent、またはGitHub Copilot Code Review(データがGitHub内に留まる)
  • モノレポ運用経験が豊富 → affected tests、マージキュー、スタックPR導入への関心大
  • ブログ/カンファレンス発表が活発 → 韓国/日本ともに事例学習が容易

15. 誰が何を選ぶべきか — 意思決定ガイド

組織規模、ワークロード、ガバナンス要件によって推奨組み合わせが異なる。

個人開発者 / 小規模OSS

  • GitHub Copilot Code Reviewをオン(無料枠活用)
  • 必要ならCodeRabbit OSS無料枠
  • スタックワークフローが必要ならGitButler

シード/Series Aスタートアップ(エンジニア1-20名)

  • GitHub Copilot Code Review(既にCopilot Businessを使っているなら)
  • またはCodeRabbit単独
  • マージキューはGitHubネイティブ
  • Sonar/Snyk Codeは無料枠から開始
  • スタックPRはまだ早い(チームコンベンションから)

Series B-Cスタートアップ(エンジニア20-100名)

  • CodeRabbitまたはGreptile(モノレポならGreptile)
  • Copilot Code Reviewと併用
  • MergifyでDependabot自動化
  • Sonar(Quality Gate) + Snyk Code(セキュリティ)
  • Graphite導入を一部チームでパイロット

中規模(エンジニア100-500名)

  • AIレビュー: CodeRabbit + Copilot Code Reviewを併用
  • マージキュー: MergifyまたはAviator
  • スタックPR: Graphiteを組織標準化
  • セキュリティ: SnykまたはAikido(Aikidoは価格合理的)
  • 品質: SonarQubeセルフホストまたはSonarCloud
  • 自社PRメトリックダッシュボード運用

エンタープライズ(エンジニア500名+)

  • Copilot Code Review(データガバナンスで外部SaaSが難しいなら)
  • またはセルフホスト可能なQodo/PR-Agent
  • マージキュー: AviatorまたはMergify Enterprise
  • セキュリティ: Snyk + Semgrep + Aikidoからポリシーに合わせ選択
  • DORA/SPACEメトリクスの自社ダッシュボード
  • スタックPRはチーム選択(全社強制は非推奨)

OSSメンテナ

  • Mergify(Dependabot/Renovate自動マージの事実上の標準)
  • CodeRabbit OSS無料(外部貢献者PRの一次レビュー)
  • Semgrep(ルールベースセキュリティ)
  • GitHub Copilot Code Review(リポジトリ単位で有効化)

金融 / 公共 / 規制産業

  • GitHub Copilot Code Review(データがGitHub内に留まる)
  • セルフホストQodo/PR-Agent + 社内LLM
  • Snyk Enterprise(監査レポートが必要)
  • SonarQube Enterpriseセルフホスト
  • 外部AI SaaSはデータ処理付属書を確認後に決定

ツール選定で最も重要な決定はツール自体ではなく**「我々のチームでPRをどう定義しどう終わらせるか」の合意**だ。この合意がないとAIレビューはノイズになり、マージキューは人をイライラさせ、スタックPRは敬遠される。合意を先に作り、その合意を加速するツールを選ぶ。

コードレビュー自動化はツールの問題ではなくチーム文化の問題だ。2026年の違いはLLMが十分に良くなって一次レビューの相当部分を自動化できるようになった点と、同時にGitHub自体がマージキュー/Copilot Code Reviewをネイティブで提供して参入障壁が下がった点だ。ツール市場はその結果4分類に整理された。何を選んでも始まりは単純だ。Copilot Code Reviewをまずオンにし、PRサイズガイドラインを合意し、マージキューを導入する。その次にAIレビューSaaSを追加するか、スタックPRへ進むか、セキュリティツールを精緻化するかを決めればよい。

参考 / References

Discuss on Twitter • View on GitHub