💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「レビューはコードを読むのではなく、意思決定を読む仕事だ。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](https://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プロジェクトが導入する。

ツール比較マトリクス:

| ツール | 強み | 弱み | 価格 |

|---|---|---|---|

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`を置くとコンベンション学習が可能

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ツールの比較:

| ツール | 位置 | 強み | 弱み |

|---|---|---|---|

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

- CodeRabbit — https://www.coderabbit.ai

- CodeRabbit Docs — https://docs.coderabbit.ai

- Greptile — https://www.greptile.com

- Greptile API Docs — https://docs.greptile.com

- Bito — https://bito.ai

- Sourcery — https://sourcery.ai

- Qodo (旧 CodiumAI) — https://www.qodo.ai

- Qodo PR-Agent (OSS) — https://github.com/qodo-ai/pr-agent

- Tab Code Review — https://tabnine.com (類似カテゴリ、参考)

- GitHub Copilot Code Review — https://docs.github.com/en/copilot/using-github-copilot/code-review

- GitHub Copilot Code Review (2025 GA発表) — https://github.blog/news-insights/product-news/

- Cognition Devin — https://www.cognition.ai/devin

- Graphite — https://graphite.dev

- Graphite Diamond (AI Review) — https://graphite.dev/features/diamond

- Sapling (Meta) — https://sapling-scm.com

- GitButler — https://gitbutler.com

- Aviator — https://www.aviator.co

- Mergify — https://mergify.com

- Mergify Docs — https://docs.mergify.com

- GitHub Merge Queue — https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

- Reviewable — https://reviewable.io

- Sonar (SonarLint / SonarQube / SonarCloud) — https://www.sonarsource.com

- Snyk Code (旧 DeepCode) — https://snyk.io/product/snyk-code/

- Aikido — https://www.aikido.dev

- Semgrep — https://semgrep.dev

- Codiga (Datadog買収、吸収) — https://www.datadoghq.com/product/code-analysis/

- DORA Metrics — https://dora.dev

- Mercari Engineering Blog — https://engineering.mercari.com/en/blog/

- Cookpad Engineering Blog — https://techlife.cookpad.com

- Toss Tech Blog — https://toss.tech

- LY Corporation Tech Blog — https://techblog.lycorp.co.jp