コードレビューに「承認待ち」は必要か──変更のリスクで使い分けるマージ戦略

「コードレビュー」と聞いて、何を思い浮かべるか

ほとんどのエンジニアにとって、コードレビューとは GitHub の Pull Request（PR）画面のことだろう。ブランチを切り、PR を開き、レビュアーにアサインし、コメントが返ってくるのを待ち、指摘を直し、もう一度待ち、承認されたらマージする。この流れが「コードレビュー」として定着している。

だが、この「全部の変更を誰かに承認してもらってからマージする」というやり方は、本当に唯一の正解なのだろうか。

2026 年 3 月、Claude Code に Code Review 機能がリリースされた。面白いのは、この機能が GitHub PR を前提にしていない使い方もできるという点だ。ターミナル上でローカルの変更に対してレビューを実行できる。PR という「承認ゲート」を経由しないコードレビュー——これは何を意味するのか。

この記事では、まず「コードの変更をどうやってマージするか」という戦略の全体像を整理し、そのうえで AI レビューツールがどこに位置づけられるのかを考える。

そもそも、すべての変更に承認は要るのか—— Ship/Show/Ask

Martin Fowler のサイトに、Rouan Wilsenach という開発者が書いた記事がある。「Ship/Show/Ask」と題されたこの記事（2021 年公開）は、PR の扱い方を 3 つに分類する提案だ。

3 つのカテゴリ

核心は Show にある。PR を「承認ゲート」ではなく「情報共有の記録」として使う。変更はすでにマージされているから、レビュアーのスケジュールに開発が左右されない。フィードバックがあれば次のコミットで反映すればいい。

「全部 Ask」の問題

多くのチームが「すべての PR にレビュー必須」というルールを採用している。これは安全に見えるが、現実にはいくつかの問題を生む。

1. レビュー待ちがボトルネックになる。 コードを書いた開発者は承認が返ってくるまで手が止まるか、別のタスクに切り替えて頭の切り替えコストを払う。Google のエンジニアリング・プラクティスガイドでさえ、「レビューに 1 営業日以上かかるべきではない」と書いている。だが現実には数日塩漬けになる PR は珍しくない。

2. 変更が大きくなる。 PR プロセスにコストがかかるため、「1 つの PR でまとめて出そう」というインセンティブが生まれる。結果、レビューしにくい巨大 PR ができあがり、レビュアーの負担がさらに増えるという悪循環に入る。

3. 形式的な承認になる。 レビュー疲れが蓄積すると、本当に見るべき変更と機械的に Approve するだけの変更の区別がつかなくなる。「LGTM」のスタンプが品質保証として機能しなくなる。

Ship/Show/Ask の考え方は、変更のリスクに応じてレビューの深さを変えるというものだ。すべてを同じゲートに通す必要はない。

AI コーディングの時代に「全部 Ask」は耐えられるか

2025 年後半から 2026 年にかけて、AI コーディングエージェントの普及が急速に進んだ。arXiv に投稿された大規模調査によると、2026 年初頭の時点で GitHub PR 全体の 15〜23% が AI エージェントによるものと推定されている。新しく書かれるコードの約 41% が AI 支援を受けているという数字もある。

コードが生成されるスピードが上がると、レビューのスピードが追いつかなくなる。AI エージェントが 10 分で機能を実装しても、人間のレビュアーが 4 時間かけてコンテキストを把握し、フィードバックを返すのでは、開発速度は完全にレビュー待ちで制約される。

Anthropic 自身もこの問題を認識している。Claude Code Review 機能のリリースブログで、エンジニアあたりのコード出力が大幅に増加し、レビューがボトルネックになったと述べている。レビューが不要になったのではなく、人間だけでレビューを回す仕組みが限界に達したのだ。

Claude Code Review は何をするのか

Claude Code の Code Review 機能には 2 つの形態がある。

マネージドレビュー（Teams/Enterprise 向け）

GitHub PR が開かれたとき、または更新されたときに自動で起動する。複数の専門エージェントが並列に diff とコード全体を分析し、バグ、スタイル違反、既存の問題を検出する。結果は PR にインラインコメントとして投稿される。

重要な点がある。このレビューは承認も却下もしない。あくまでコメントを残すだけで、マージの判断は人間が下す。つまり、既存のレビューワークフローを壊さない設計になっている。

ローカルレビュー（プラグイン）

Claude Code 上で /review コマンドを実行すると、ローカルで 4 つの並列エージェントが走る。プロジェクトのルール準拠チェック、バグ検出、git 履歴分析などを行い、信頼度スコアが 80 以上の指摘だけを報告する。

ターミナルに結果を出力するモードでは、PR が存在しなくてもレビューを実行できる。ただし内部的には PR のメタデータを参照する設計になっており、完全なオフラインレビューツールとは言えない。

このツールは未来に向いているのか、それとも過渡期のプロダクトか

ここからが本題だ。Claude Code Review を、Ship/Show/Ask の枠組みで評価してみよう。

Ask 型を強化するツールとして

現状のマネージドレビューは、GitHub PR をトリガーとして動く。つまり Ask 型のワークフローの中に組み込まれるツールだ。PR を出し、AI レビューが走り、人間レビュアーが確認し、承認してマージする。従来の流れを変えるのではなく、その中の「人間レビュアーの負担を軽減する」という位置づけになる。

この使い方は現時点で非常に実用的だ。Anthropic の発表によると、レビューで実質的なコメントがつく PR の割合が 16% から 54% に上がったという。人間が見落としていた問題を AI が拾っているわけで、Ask 型ワークフローの品質を確実に底上げしている。

Show 型を安全にするツールとして

一方、ローカルレビュー機能の存在は示唆的だ。PR を開く前に、手元で AI レビューを通す。問題がなければそのままマージし、PR は記録として残すだけ——これはまさに Show 型のワークフローだ。

AI レビューが「最初の目」として機能することで、人間の承認を待たなくても一定の品質保証が得られる。Ship/Show/Ask の枠組みでいえば、AI レビューは Ask から Show へ、Show から Ship へと変更を安全に格下げする役割を果たす。

過渡期のプロダクトか？

正直に言えば、現時点では過渡期のプロダクトだと思う。理由はこうだ。

マネージドレビューが GitHub PR 前提の設計であること自体が、「Ask 型が主流である現実」への適応だ。世の中の大多数のチームはまだ「全部 Ask」で開発している。そのマーケットに向けて作られたツールだから、PR 中心の設計になるのは当然だ。

だが、AI がコードを書く割合が増えるにつれて、「全部 Ask」は物理的に持続不可能になる。Sonar の 2026 年 1 月の調査では、コミットされたコードのうち AI 由来が 42% を占めるようになり、新たなボトルネックは「コードの検証」だと報告されている。コード量が倍になったのにレビュアーの数は変わらないなら、何かを変えなければならない。

その「変える先」が Ship/Show/Ask 的な思考だ。すべてを同じ深さでレビューするのをやめ、変更のリスクに応じて戦略を分ける。AI レビューは、その戦略分けを支える基盤になる。

ただし、Ask がなくなるわけではない

誤解のないように書いておくと、Ask 型が完全に時代遅れになるわけではない。「全部 Ask」が時代遅れになるのだ。

設計判断が必要な変更、セキュリティに関わる変更、チーム全体の合意が要る変更——こうしたものは依然として人間の議論と承認を経るべきだ。GitHub 自身も 2026 年 2 月に Required Reviewer ルールを正式リリースしており、認証や SQL などセンシティブなパスに対する承認要件をむしろ強化している。

重要なのは、Ask をデフォルトにするのではなく、必要なときだけ使う選択肢にすることだ。

実際に使って感じたこと

筆者のリポジトリでは、GitHub PR を使わずに feature ブランチからローカルでマージする開発フローを採っている。この環境で Claude Code Review がどう使えるかを試してみた。

/review コマンドは、PR が存在する前提の部分があるため、完全にオフラインでは動かない場面もある。だが、マージ前にローカルで AI に変更をチェックさせるという発想自体は、Ship/Show/Ask 的なワークフローと非常に相性がいい。

自分の開発フローに当てはめると、こうなる。

• Ship: ドキュメント更新、設定ファイルの微修正 → そのままマージ
• Show: 通常の機能実装 → AI レビューを通してからマージ。PR は作らないが、コミットログで経緯は追える
• Ask: アーキテクチャの根本変更 → 人間（または複数の AI エージェント）にレビューを依頼

PR 文化がないリポジトリでも、AI レビューを導入することで「レビューゼロ」と「全部レビュー」の間にグラデーションを作れる。これが最も実用的な使い方だと感じている。

まとめ

コードレビューの本質は「変更の品質を担保する仕組み」であって、「Pull Request で承認をもらうこと」ではない。Ship/Show/Ask という考え方は、変更のリスクに応じてレビューの深さを変えるべきだと教えてくれる。

Claude Code Review のようなツールは、現時点では Ask 型ワークフローの強化ツールとして機能している。だが、その先にあるのは Show 型や Ship 型のワークフローを安全にする基盤だ。「全部 Ask」から「リスクに応じた使い分け」への移行—— AI レビューツールは、その過渡期を支えるプロダクトであり、同時にその先の未来を形作るものでもある。

あなたのチームでは、すべての PR に同じレビュープロセスを適用しているだろうか。もしそうなら、「この変更は Ship か、Show か、Ask か」と問いかけることから始めてみてほしい。答えが見えたとき、AI レビューツールの使いどころも自然と見えてくるはずだ。