【2026年5月】PR レビュー工数を減らす実践と事例｜AI レビューの育て方・リスク振り分け

01.結論：レビュー工数の削減は『人間が全行を見る』を捨て、4 つの取り組みに作り替えること

コードレビューは、長らく「人間のシニアエンジニアが、変更された行を上から下まで読む」作業として運用されてきました。この前提は、コードを書くのが人間で、1 人が 1 日に出せる PR の数に上限があった時代には合理的でした。しかし、AI コーディングエージェントがコードの大半を書くようになった 2026 年には、この前提が崩れています。レビュー対象の流入量が桁違いに増える一方で、レビューできる人間の数は増えないからです。

本記事の中核となる主張は、レビュー工数を減らす取り組みは「レビューを省く」ことではなく「レビューを作り替える」ことだという点です。具体的には、レビューを次の 3 層に分解して考えます。

• レビューの基準（何を見るか）：これをテキスト・skill として外部化し、資産として育てる（取り組み①②）
• レビューの実行（誰が見るか）：AI を一次レビューに置き、人間はリスクの高い PR だけを見る（取り組み③）
• レビューの結果（どう通すか）：低リスクから順に、人手を介さずマージできる範囲を広げる（取り組み④）

そして、この作り替えだけでは埋まらない穴があります。仕様そのものの誤り、ビジネス的な誤り、全体設計の誤り、コードベース把握不足による見落とし——AI レビューが構造的に弱いこの 4 類型への打ち手を 第 8 章で扱います。本記事は、レビューの『書く側』が爆速化した経緯を整理した 『なぜ Anthropic は開発が異常に速いのか』の続編にあたります。

02.背景：AI がコード生成を爆速化した

レビューがボトルネックになった理由を理解するには、まず「書く速度」がどれだけ跳ね上がったかを押さえる必要があります。2026 年に入って、AI を使いこなす開発組織では、コード生成の量が前年比で大きく増えています。

これらの数字が意味するのは、同じ人数のエンジニアが、これまでの数倍の量の PR を生み出すようになったということです。Anthropic CPO の Mike Krieger 氏は、ボトルネックが「コードを書くこと」から「意思決定」と「マージキュー（コードを本番に乗せる工程）」へ移ったと 明言しています。コードを書く工程はすでに十分速く、詰まっているのはその後ろの工程だということです。

03.レビューが 2026 年のボトルネックになった

書く速度が上がった分の負荷は、そのままレビュー工程に積み上がります。Claude Code を作った Boris Cherny 氏は、社内向けにコードレビュー機能を開発した理由を「レビューがボトルネックだった」と端的に説明しています。エンジニア 1 人あたりのコード出力が 2 倍になれば、レビューすべき差分も 2 倍になりますが、レビューに割けるシニアエンジニアの時間は 2 倍にはなりません。

したがって本記事で扱う取り組みは、すべて「増えた流入量を、限られた人間のレビュアーでさばききるにはどうするか」という 1 つの問いに答えるものです。以下、4 つの取り組みを順に見ていきます。

04.取り組み①：レビュープロンプトを『資産』として育てる

最初の取り組みは、レビューの「基準」を人間の頭の中から取り出し、テキストや skill として外部化することです。AI にレビューさせるとき、AI が参照できる基準が書かれていなければ、AI はその場で基準を推測します。推測されたレビューは、チームの意図とずれます。逆に言えば、レビュー基準を明文化して持つほど、AI レビューの精度と一貫性は上がります。

CLAUDE.md / AGENTS.md / REVIEW.md にレビュー基準をテキストで持つ

AI コーディングエージェントは、リポジトリ内の決まったファイルを「指示書」として読み込みます。代表的なのが次の 3 つです。

ポイントは、これらのファイルが バージョン管理されたテキストだということです。レビュー基準がコードと同じリポジトリに入っていれば、基準そのものを PR でレビューでき、変更履歴も残ります。「シニアの頭の中にしかないレビュー観点」を、チームの共有資産に変える第一歩がこれです。

skill とカスタムサブエージェントへレビューの観点を分業する

1 つの長いレビュー指示書にすべてを詰め込むと、AI はどの観点も中途半端にしか見なくなります。そこで、レビュー観点を skill（特定の手順や判断基準を 1 ファイルにまとめ、関連する作業のときだけ読み込ませる仕組み）や カスタムサブエージェントに分けて持たせる構成が広がっています。サブエージェントとは、メインのエージェントとは別に起動する補助役の AI です。1 体ごとに「何を見るか」「どう報告するか」という専用の指示を与え、独立して（多くは並列で）走らせます。Claude Code では .claude/agents/ にファイルとして定義し、1 体の持ち場を絞って使います。

Anthropic が公開している PR Review Toolkit は、この分業の具体例です。テストの十分性を見る pr-test-analyzer、握りつぶされた例外（silent failure）を探す silent-failure-hunter、型設計を見る type-design-analyzer、コメントの是非を見る comment-analyzer——というように、持ち場ごとに専門のサブエージェントが用意されています。1 回のレビューで複数のサブエージェントを並列に走らせ、見つかった指摘をさらに別のサブエージェントが検証する構成です。人間 1 人がすべての観点を同時に見るより、持ち場を分けて並列に当てるほうが、見落としが減り、各観点の指摘も深くなります。

分業を自分のチームで始めるときは、いきなり同じ数の担当に分けなくて構いません。REVIEW.md に書き出したレビュー基準を読み返し、「見る対象が違うもの」を 1 つの担当にまとめるのが出発点です。テストの担当、エラー処理の担当、命名・型の担当——という 3 つくらいから始め、指摘の質を見ながら担当を足していきます。担当の境界が REVIEW.md の見出しと揃っていれば、基準を更新したときにどの担当へ反映すればよいかが一目で分かります。これは、CLAUDE.md を短く保ち、細かい基準を別ファイルに逃がす設計とそのままつながります。

good / bad コーパスを実 PR から継続更新する

レビュー基準は、抽象的なルールだけでは精度が出ません。「良い実装の例」と「避けるべき実装の例」を具体的なコードスニペットで持ち、レビュー時に AI へ参照させると、判断が安定します。重要なのは、このコーパス（例の集合）を固定せず、実際の PR から継続的に更新することです。

実務でレビュー指摘が発生したら、その「悪い例」と「修正後の良い例」をコーパスに足す。これを繰り返すと、レビュー基準はチームの実コードに即した形で育っていきます。AI モデルを差し替えなくても、基準（指示）を磨くだけでレビューの質は上がる——複数の実践者がそろってこの効果を報告しています。レビュープロンプトは「一度書いて終わり」ではなく育てていく資産である、と捉えるのが取り組み①の核心です。

05.取り組み②：レビュー観点を PR 後に『自動でスキル化』する運用

取り組み①の「コーパスを育てる」を、もう一段システム化したのが取り組み②です。1 回のレビュー指摘を、その場限りの会話で終わらせず、全 PR に効く恒久ルールへ自動的に昇格させる運用が、すでに製品機能として実用化されています。

CodeRabbit Learnings：指摘＋人間の返信をルール化する閉ループ

AI コードレビューツールの CodeRabbit には「Learnings」という機能があります。動きはこうです。CodeRabbit が PR に何かを指摘する。それに対して開発者が「これはこのリポジトリでは問題ない（例：このマイグレーションはデプロイ時に自動生成される）」と返信する。すると CodeRabbit はそのやり取りをリポジトリ固有のルールとして保存し、以後の同種の指摘（偽陽性）を出さなくなります。

さらに、蓄積した知見は .coderabbit.yaml や、平易な言葉で書く「Pre-Merge Checks（マージ前のカスタムチェック）」として、強制ルールへ昇格させられます。「指摘 → 人間の返信 → ルール化 → 全 PR へ適用」という閉ループが、製品の標準機能になっているわけです。本記事が掲げる「PR 後に重要なレビュー観点を自動でスキル化する運用」は、まさにこの形で実在します。

REVIEW.md と学習ループ：訂正を次の基準に昇格させる

専用ツールを使わなくても、同じ閉ループは作れます。Claude Code では、レビュー専用ルールを REVIEW.md に蓄積していく運用がそれにあたります。レビューで人間が「その指摘は違う」「この観点が抜けている」と訂正したら、その訂正内容を REVIEW.md に 1 行追記する。次回のレビューからは、その行が基準として効きます。

より自律的なエージェントでは、「コマンドが失敗した」「ユーザーに訂正された」「より良いやり方が見つかった」といったイベントを検知して、学びを再利用可能な skill として自動的に書き出す閉ループを持つものも登場しています。共通する発想は、レビューで発生した『気づき』を、二度と手作業で繰り返さないために、その場で資産に変換するという点です。

feedback loop の設計：誰がいつ何をルールに上げるか

この運用は、放っておくと「ルールが無秩序に増え続けて、誰も把握できない指示書」になりがちです。実務では、「code quality feedback loop（コード品質のフィードバックループ）」として、昇格の手順を決めておくのが有効です。

レビュー基準は「足す」だけでなく「捨てる」運用までセットにして初めて、育つ資産になります。

06.取り組み③：レビュアーを減らす — リスクで振り分け、AI を一次レビューに

取り組み①②でレビュー基準を資産化したら、次は「誰が見るか」を作り替えます。すべての PR を人間が見るのをやめ、AI を一次レビューに置き、人間は高リスクの PR だけを見る。文言変更のような簡易な内容は AI レビューに任せ、重要度の高いものだけ人間に回す——この振り分けが取り組み③です。

ここで実務上いちばん問われるのが、「どの PR を低リスクと判断するのか」という判断のロジックです。判断は単一のブラックボックスではなく、実際には次の 3 つの方式が使い分けられています。

判断の作り方①｜決定的ルールで安全な変更を抜く

1 つ目は、AI を一切使わない決定的なルールです。ワークフロー自動化ツールの gitStream は、PR の差分を allDocs（変更がドキュメントだけ）、allTests（テストだけ）、isFormattingChange（整形だけ）、allImages（画像だけ）といったフィルタで照合します。差分がそれらだけで構成されていれば「safe」ラベルを付けて自動承認し、自動承認した理由をコメントとして残します。

この方式の利点は、判断根拠が YAML に明示されていて監査可能なことです。ドキュメント・テスト・整形・画像のみの PR は、ここでレビュー対象から抜けます。文言変更はこのバケットに入ることが多く、最も導入が簡単な振り分けです。

判断の作り方②｜客観的な多基準ゲートで low-risk を定義する

2 つ目は、複数の客観基準を組み合わせたゲートです。Ona は、すべての PR を自動評価し、次の条件をすべて満たした場合だけ low-risk に分類します。

• 変更が 1,000 行未満（追加・削除の合計）
• 機微な領域（認証・決済など）に触れていない
• テストが通っている
• インフラを変更していない

1 つでも条件を外れれば、その PR は人間レビューへ回されます。重要なのは、エンジニアが自分で「これは low-risk です」と申告できない設計になっている点です。判定はあくまで客観基準にもとづいて自動で行われるため、基準を都合よく解釈する余地がなく、low-risk の境界は監査可能なものになります。「ごまかしの効かない振り分け」を作るうえで、この『自己申告を許さない』設計は本質的です。

判断の作り方③｜AI 分類器がリスクをスコアリングする

3 つ目は、決定的ルールでは判定しきれないグレーゾーンを、AI 分類器がスコアリングする方式です。Claude Code の Auto Mode に組み込まれた permission classifier（許可分類器）は、エージェントの各アクションを次の軸で評価します。

コードレビューに引き直せば、同じ発想で「この PR は影響範囲が広いか」「巻き戻せる変更か」「機微な領域に触れているか」をスコアリングし、深く見るべき PR を選り分けられます。Anthropic のコードレビュー機能自体も、PR の規模・複雑さに応じてレビューの深さ（投入するエージェント数）をスケールさせる設計になっています。大きく複雑な PR には多くのエージェントで深く、些細な PR には軽く——という振り分けです。

共通原則：AI は全 PR を見る、ゲートは『人間も見るか』だけを決める

運用面では、PR を小さく保つこと、そして関連する変更を段階的に積み重ねる「スタックド PR」によって 1 つの PR の責務を明確にすることが、リスク振り分けの精度を高めます。境界がはっきりした小さな PR ほど、決定的ルールや多基準ゲートで安全に自動処理できるからです。

07.取り組み④：自動マージという理想 — どこまで来て、どこで止まっているか

4 つ目の取り組みは、レビューの「結果」をどう通すか——人手を介さずにマージできる範囲をどこまで広げられるか、です。これは多くの開発者が思い描く理想形ですが、2026 年 5 月時点の現在地を正確に捉えるには、いくつかの切り分けが要ります。

『誰が PR を書くか』と『人を介さずマージするか』は別軸

まず切り分けたいのが、第 2 章で触れた Cursor の「マージ PR の 35% が自律エージェント発」という数字です。これは PR の『書き手』が誰かを示す指標であって、自動マージの指標ではありません。エージェントが書いた PR も、通常はレビューを経てマージされます。

つまり「自動マージ」を論じるときは、(a) PR を書くのが人間かエージェントか、と (b) マージに人間の承認が要るか要らないか、という 2 つの軸を分けて考える必要があります。本章が扱うのは (b) の軸です。

自動マージの仕組み自体は枯れている

マージを自動化する仕組み自体は、AI 以前から成熟しています。GitHub のネイティブ auto-merge は、必須レビューと必須ステータスチェックがすべて通った瞬間に PR を自動マージします。Mergify のようなツールも同種の自動化を提供します。

これらは、依存ライブラリの更新（Dependabot の PR など）や、取り組み③でルール分類済みの低リスク PR では、すでに広く実運用されています。「条件を満たしたら自動でマージする」という機械的な処理は、技術的にはまったく新しくありません。

AI 生成の機能コードでは『自動承認』が現在地

では、AI が書いた機能コードを、人間のレビューなしで自動マージしている組織はあるのでしょうか。ここがいちばん気になるところだと思います。実際のところ、無人での自動マージは、AI 生成の機能コードではまだ主流になっていません。広く使われているのは、その一歩手前の「自動承認」です。

第 6 章で触れた Ona の事例が象徴的です。Ona は低リスク PR を AI に自動承認させることで lead time（着手からマージまでの時間）を 74% 短縮しました。ただしボットが行うのは「承認（approve）」までで、「マージ」自体は実行しません。承認と最終マージを切り分け、マージのトリガーは人間が握る——これが慎重な組織の現在地です。完全な無人マージは、まだ実験段階にとどまっています。

逆風と着地点：ゲートを残し、要所以外を自走させる

さらに 2026 年に入って、自動マージには逆風も吹いています。サプライチェーン攻撃（依存ライブラリ経由で悪意あるコードを混入させる攻撃）の急増を受けて、CI がグリーンでも auto-merge を外す判断をするチームが出てきました。「テストが通る」ことと「マージして安全」であることは別だ、という認識です。

後の 第 9 章で詳しく見るように、OpenClaw の Peter Steinberger 氏ですら、未レビューの PR を自動マージし続ける運用を「dark factory（暗闇の工場）」と呼んで明確に拒否しています。

したがって取り組み④の落としどころは、「全 PR を無人でマージする」ことではありません。承認ゲートは残したまま、エージェントが要所以外を自走する形です。CI の失敗を検知して自動修正の PR を出す「CI auto-fix」のような機能は、その方向にある一例です。目指すのは「人手ゼロのマージ」ではなく、「人間が判断すべき要所だけに人手を集中させたマージ」——2026 年 5 月時点では、ここが取り組み④の到達点だと捉えるのが妥当です。

「要所にだけ人間のゲートを残す」設計は、コード以外の作業にも応用できます。GTMのタグ設定をAIエージェントで自動化し、公開だけ人間が承認する形にする構成を、別記事で扱っています。

08.AI レビューが取りこぼす 4 類型と打ち手

ここまでの 4 つの取り組みは、レビューの「処理能力」を上げるものでした。しかし、AI レビューには処理能力とは別に、構造的に苦手な領域があります。要件を与えられない AI レビューができるのは、パターン照合・コードの不吉な兆候（code smell）の検出・競合状態の検出といった構造的な解析にとどまります。「このコードは正しそうに見えるか」は問えても、「このコードは意図した通りか」までは問えないのです。

AI レビューはセキュリティの定型的な脆弱性や null 安全には高い精度を出す一方、ビジネスロジックや設計判断には精度が落ちる——この傾向は 複数の調査で一致しています。実務で問題になりやすい次の 4 類型と、それぞれの打ち手を整理します。

仕様書バグ：レビュー対象を仕様・プランへ前倒しする

仕様書バグとは、コードは仕様の通りに正しく実装されているのに、その仕様自体が間違っている類型です。コードだけをいくら丁寧にレビューしても、仕様が誤っていれば検出できません。

打ち手の方向は、レビューする対象をコードより手前——仕様とプラン——に移すことです。Spec-Driven Development（SDD：仕様駆動開発）は、書かれた仕様を実装と並ぶ重要な成果物として扱い、コードに入る前に仕様そのものをレビューする進め方です。Claude Code の Plan モード（エージェントを読み取り専用に制限し、コードを書く前に実装プランを提示させる機能）も、同じ「手前で見る」発想です。OpenAI の Harness Engineering の「Spec → Plan → Review → Execute」のように、各社がこの方向を試しています。

ただし、SDD が仕様書バグの決定的な解決策として固まっているわけではありません。仕様をどこまで細かく書き、どの段階で誰がレビューすれば実装の誤りを十分に防げるのか——その型は、業界全体でいままさに手探りされている最中です。仕様を手前でレビューする発想は有望ですが、確立した正解として一気に導入するのではなく、自社で効き目を確かめながら少しずつ取り入れる対象として見ておくのが安全です。

ビジネス的に誤りのバグ：社内コンテキストを持たせる

2 つ目は、コードとしては正しいのに、自社の業務ルールに照らすと誤っている類型です。たとえば「割引は税抜価格に適用する」という社内ルールを知らなければ、税込価格に割引を適用するコードも、AI レビューには『正しそう』に見えます。

打ち手の方向は 2 つあります。1 つは、社内コンテキストを AI に持たせること——取り組み①の REVIEW.md / CLAUDE.md / AGENTS.md にドメインルールを書き、取り組み②の Learnings で業務知識を蓄積する。これで「既知の業務ルール」に対する違反は検出できるようになります。もう 1 つは、限界を認めることです。明文化されていない業務判断や「そもそもこの機能を作るべきか」という問いは、良い仕様と人間の最終判断が引き受けるべき領域として、AI レビューの外に置きます。すべてを AI に検出させようとせず、人間が見る範囲を意図的に残す設計が要ります。

全体設計のバグ：コードベースのグラフ索引を使う

3 つ目は、個々のファイルは正しいのに、変更が全体設計の方向性として誤っている類型です。差分と周辺の数十行しか見ない単一ファイル解析では、この誤りは見えません。

打ち手は、コードベース全体の構造を AI に持たせることです。Greptile は、リポジトリ全体の「どのモジュールがどこに依存しているか」を semantic graph（意味的なグラフ）として構築し、その上でレビューします。Qodo は複数リポジトリにまたがる依存関係を理解し、統合バグを検出します。「ある API 契約の変更が、下流の 3 つの利用箇所を壊す」といった波及は、グラフ索引があって初めて指摘できます。

ただし注意も要ります。設計上の欠陥は、コードをスキャンするだけでは見えない「意図」の問題を多く含みます。グラフ索引は波及の検出を助けますが、アーキテクチャの方向性が正しいかという判断は、人間のレビューにも残すべき領域です。

コードベース把握不足の漏れ：全体文脈を持つレビュー基盤

4 つ目は、③と近いものの、レビュアー（人間でも AI でも）が既存コードベースを把握しきれていないために起きる見落としです。巨大なリポジトリでは、変更がどこに波及するかを頭の中に保持できません。

打ち手は、③と同じくコードベース全体を文脈に持てるレビュー基盤を使うことです。Cloudflare は、AI コードレビューを大規模に展開した事例を 公開しています。導入から最初の 30 日で、5,169 のリポジトリにまたがって 131,246 回のレビューを実行し、レビュー完了までの時間は中央値で 3 分 39 秒だったと報告しています。人間が頭の中に収めきれない規模のコードベースを、レビュー基盤の側が文脈として持つ——これが 4 類型のうち③④に共通する打ち手です。

09.事例：各社は実際どう PR をレビュー・マージしているか

ここまでの取り組みと打ち手が、実際の AI ネイティブ企業でどう実装されているか。Anthropic・OpenAI・OpenClaw（Peter Steinberger 氏）の 3 つを、公式ブログ・公式ドキュメント・関連記事・カンファレンス登壇から具体的に見ていきます。

Anthropic：全 PR にエージェントチームのレビューを当てる

Anthropic は 2026 年 3 月 9 日、Claude Code の Code Review 機能を公開しました。特徴は、先に社内向けに作り、全チームで使い込んでから外部公開したという順序です。仕組みはこうです。PR が開かれると、エージェントの一団が動き出し、並列でバグを探索します。見つかった候補は別のエージェントが検証して偽陽性を取り除き、深刻度でランク付けします。最終的に、1 件の要約コメントと、具体的なバグへのインラインコメントを生成します。レビューの深さは、PR の規模に応じて変わります。

社内データとして公表されている数字が、この機能の効果を示しています。

この事例が示すのは、取り組み①〜③の組み合わせです。観点ごとに専門エージェントを分業させ（取り組み①）、全 PR に AI 一次レビューを当て、PR の規模でレビュー深度を振り分ける（取り組み③）。そして「社内で先に使い倒してから外に出す」という順序自体が、レビュー基準を実 PR で育てる運用（取り組み②）になっています。Anthropic の開発速度を支える dogfooding 文化が、レビュー機能にもそのまま現れています。

OpenAI：Codex が PR の大半を見て、工数を agent-to-agent へ寄せる

OpenAI の社内では、PR レビューの大半をコード生成エージェント Codex が担っています。OpenAI 公式は、社内の大多数の PR が Codex のレビューを受けていると説明しています。公式の解説によれば、PR を完成へ導くために Codex は次のループを回します。

• 自分が書いた変更を、まずローカルで自己レビューする
• 追加のエージェントレビューを、ローカルとクラウドの両方で依頼する
• 人間・エージェントから来たフィードバックに対応する
• すべてのエージェントレビュアーが満足するまで、このループを繰り返す

注目すべきは、人間のレビューは可能だが必須ではないという点です。OpenAI は時間をかけて、レビュー工数のほぼ全部を「agent-to-agent（エージェント同士）」のレビューへ移しました。レビュー基準は AGENTS.md で与えられ、変更されたファイルに最も近い AGENTS.md のガイダンスが適用されます。これは取り組み①（基準のテキスト化）の徹底です。

ただしこの運用には強い前提があります。テストが、Codex のレビューを意味あるものにできるだけの質を持っていることです。OpenAI 内で最も成果を出しているチームは、先に失敗するテストを書いて全部が落ちることを確認し、その失敗テストをチェックポイントとしてコミットしてから、テストが全部通るまで Codex に実装させます。このとき「テスト自体は書き換えるな」と明示します。検証層への先行投資があって初めて、agent-to-agent レビューは成立します。

Peter Steinberger / OpenClaw：速さとマージの規律を両立させる

個人のローカル常駐型 AI エージェント OpenClaw を公開し、急成長させた Peter Steinberger 氏のやり方は、文脈によって 2 つに分かれます。これを混ぜずに見ることが大切です。

自分自身の開発では、Peter 氏は PR を「Prompt Request（プロンプトの提案）」と捉えます。コードを行単位でレビューすることはせず、見るのは「どんなプロンプトがそのコードを生んだか」と「検証ループ」です。エージェントが自分でコンパイル・lint・実行・検証を回せるように設計し、その仕組みを信頼します。Peter 氏自身が 「I ship code I don't read（私は自分が読まないコードを出荷する）」と公言しているのは、この検証ループへの信頼が前提にあるからです。Peter 氏は、行単位のコードレビューの比重は下がり、アーキテクチャレビューの比重が上がっていくと見ています。個々の行が規約どおりに書けているかを細かく追うのではなく、データモデルや「そもそもこの機能を作るべきか」を議論する、ということです。人間の判断を 第 8 章の仕様書バグ・全体設計バグに寄せる発想と重なります。

一方、OpenClaw の OSS メンテナとしては、まったく違う規律を敷いています。OpenClaw には外部から大量の PR が流入し、The Pragmatic Engineer の記事によれば、公開から 3 か月弱で貢献者は 600 人、コミットは 1 万件、ピーク日には 1 日 600 コミットがマージされる規模に達しました。これをさばくため、Peter 氏は OpenClaw の CONTRIBUTING.md に次の運用を明文化しています。

• PR 数の上限：1 人あたりの同時オープン PR を 20 件に制限する『ハードリミット』を設けている。超過すると r: too-many-prs ラベルが付き、PR は自動クローズされる
• 「テストが通る」だけでは通さない：外部 PR には実際に動かした証跡（Real behavior proof）の記入を必須とし、「ユニットテスト・モック・lint・型チェック・CI はそれだけでは要件を満たさない」と明記している
• レビュー指摘の解消を必須化：Codex によるレビューを「現時点で最も高い水準の AI レビュー」と位置づけて PR 提出前のローカル実行を求め、レビュー bot が残した指摘は作成者が解消・返信してから再レビューを依頼する決まりにしている。指摘を未解消のままマージへ進ませない

Peter 氏の事例が示すのは、「読まずに出荷する」ほどの速さと、「未レビューでは自動マージしない」というマージの規律は両立するということです。鍵は、人間のレビューを省くのではなく、人間が見るべき層（プロンプト・検証ループの設計、アーキテクチャ、トリアージの方針）に判断を移し替えている点です。Peter 氏の AI 駆動開発手法の詳細は別記事で扱っています。

10.どこから着手するか／まとめ

ここまで見てきた取り組みは、いきなり全部を導入するものではありません。レビュー基準が薄いまま AI レビューの自動承認だけを広げると、品質事故につながります。検証層を厚くしてから自律の範囲を広げる、という順序が大切です。無理なく着手するための順番を、5 つの STEP に整理します。

この順序の背骨にあるのは、「人間が全行をレビューする」を捨てる代わりに、「人間がレビューすべき範囲を絞り込む」という考え方です。AI 一次レビューは全 PR に当てる。レビュー基準は資産として育て、指摘は恒久ルールへ昇格させる。リスクで振り分け、低リスクは自動で通す。そして、仕様書バグ・ビジネス的な誤り・全体設計の誤りといった AI が構造的に苦手な領域には、人間の判断を意図的に残す。

レビュー工数の削減は、レビューをやめることではありません。レビューという作業を、資産化・自動化できる部分と、人間にしか担えない部分に切り分け、それぞれを最適な担い手に割り当てる——その作り替えこそが、増え続ける PR の流入量に開発組織が追いつくための道筋になります。