58%のPRをAIが自動承認する開発の未来

深夜の障害対応や、リリース直前のマージブロックに頭を抱えた経験のないエンジニアなどいないだろう。昨今、CursorやGitHub CopilotといったAIコーディングツールの普及により、我々デベロッパーがコードを書き出すスピードは劇的に向上した。しかし、ここで一つの冷酷な現実が突きつけられる。コードが爆速で生成されるようになった結果、今度は「コードレビュー」という品質担保のプロセスが未曾有のデッドロックを引き起こしているのだ。

SHE株式会社の開発責任者である@qsona氏が直面したのも、まさにこの「価値創出のボトルネック」だった。彼らが直近3週間に人間レビューへ回ったPull Request（PR）75件を全数分析したところ、衝撃的な事実が明らかになった。なんと、全体の60%は「無言のapprove」または「LGTM（Look Good To Me）」のみで通過していたのだ。実質的な指摘がついたのはわずか1割にとどまり、しかもその大半は以前から導入されていたレビューAIによるものだったという。

このデータが意味するものは重い。我々が「品質担保のため」と信じ込み、数時間、時には数日間もPRを放置してレビューアの時間を奪っていたプロセスは、実質的に「ただの儀式」と化していたのではないか。AIがコードを書き、人間がiPadでカジュアルにPRを承認するような時代において、従来の「人間が一行ずつコードを目視する」というレビューモデルは完全に破綻しつつある。開発生産性の指標であるFour Keysをいくら改善しようとしても、この「レビューの渋滞」を解消しなければ、ビジネス価値のデッドロックは解けない。私は、この課題こそが現代のソフトウェアエンジニアリングにおける最大の「技術負債」であると考える。

では、このボトルネックをどう破壊するか。SHEが導き出した答えは、AIにコードレビューだけでなく「Approve（承認）の判断」までを委ねるという、極めて大胆なワークフローの構築だった。しかし、単にLLMに「このコードをレビューして承認して」と丸投げするだけでは、スパゲッティコードやセキュリティホールの温床になりかねない。ここで光るのが、彼らが設計した「決定的ゲート判定」と「LLMによる多角的なリスク審査」を組み合わせたハイブリッドなアーキテクチャだ。

まず、決済や売上、監査法人との取り決めに関わるクリティカルなコード変更については、LLMではなく、ファイルパスのマッチングやモデル参照検知といった「決定的なロジック」で強制的に人間レビューを必須とするゲートを設けている。実行のたびに判断が揺らぎうるLLMに統制系の判断を委ねないという設計は、シニアエンジニアとして極めて妥当であり、大いに賛同できる。

その上で、LLM（Claude）レイヤーが以下の8つのリスク項目を審査する。

• 統制系変更（control_plane_change）：レビュー・審査・CIなど統制の仕組みそのものに触れる変更
• 不可逆操作（irreversible_operation）：データ削除や外部送信など、実行後に取り消せない操作
• セキュリティ境界（security_boundary_change）：認証・認可・権限チェックなど守りの境界の変更
• 個人情報フロー（personal_data_flow_change）：個人情報の取得・保存・出力経路の変更
• 外部契約（external_contract_change）：外部APIやスキーマなど外部との取り決めの変更
• 新規パターン導入（architectural_precedent）：コードベースに前例のない実装パターンの持ち込み
• 高リスク値計算（high_stakes_calculation）：金額など誤りの影響が大きい値の計算の変更
• 実行時ハザード（runtime_hazard）：重いクエリやジョブなど実行時に事故を起こしうる変更

さらに、このシステムの最もエレガントな部分は、「AIの意見（Approve / Pending / Need Fix）」と「人間レビューの要否（Required / Optional）」という2つの独立した軸を定義した点にある。これにより、「AIとしてはコードに問題はないと判断したが、新規パターンの導入に該当するため、念のため人間も目を通すべき」という、極めてグラデーションのある運用が可能になるのだ。あいまいな指示を出すと安全側に倒れてすべてを「人間レビュー必須」にしてしまうLLMの特性を理解し、明確な8項目を定義して意思決定の責任を開発責任者が引き受けた点に、私は強いプロフェッショナリズムを感じる。

この自動承認システムをさらに実用的なものにしているのが、「pending（保留）」というステータスの設計だ。実際の開発において、PRの差分（diff）だけを見て100%の正しさを保証することは不可能に近い。例えば、データベースのマイグレーションにおいて「古い仕様に依存しているクライアントが本当に存在しないか」といった、コードの外側にあるコンテキストに正しさが依存する場合が多々あるからだ。

従来のAIレビューツールであれば、ここで「問題なし」と誤判定するか、あるいは一律で却下するかの二者択一になりがちだった。しかし、SHEのシステムでは、審査エージェントが承認を保留し、PR作成者に対して「⏳ Pending — 確認したいことがN件あります」と具体的な質問を投げかける。開発者は特別なスラッシュコマンドを使う必要はなく、GitHub上で通常通りコメントを返信するだけで、軽量モデル（claude-haiku-4-5）によるプリフィルタを経て自動的に再審査が走る。この「対話型」のプロセスこそ、AIを単なる静的解析ツールから「自律的な開発パートナー」へと昇華させる鍵である。

このアプローチは、GitHubがパブリックプレビューを開始した「Stacked pull requests」（大規模な変更を小さなPRの連鎖として管理する手法）などの最新トレンドとも非常に親和性が高い。PRが細分化されればされるほど、レビューの回数は増え、人間のコンテキストスイッチのコストは跳ね上がる。しかし、細分化された小さなPRの58%をAIが自動で承認し、人間が本当に見るべき「高リスクなPR」だけをスタックの上位でフィルタリングできるようになれば、開発のリードタイムは劇的に短縮される。ベースマキナがAIファーストな社内システム操作をCLIやAPIで提供し始めたように、開発プロセスそのものが「AIが自律的に動き、人間は例外処理と最終承認のみを行う」というAIファーストな体験へと急速にシフトしているのだ。

SHEの導入実績において、運用開始からわずか2週間で「全体のPRの58%がAIによって自動承認されるようになった」という数値は、一見すると輝かしい成功体験に思える。しかし、我々シニアエンジニアがこの数字の裏にある本質的なパラダイムシフトから目を背けてはならない。

かつて、コードレビューとは単なるバグ潰しの場ではなかった。「誰かの書いたコードを、チーム全員のコードにする」という、コードの共同所有権（コードオーナーシップ）を醸成し、中長期的な技術的負債を防ぐための神聖な儀式であったはずだ。しかし、AIがコードを書き、AIがそれを承認し、人間がただマージボタンを押すだけの世界において、我々は本当にそのコードベースに対して「当事者意識」を持ち続けられるのだろうか。一行一行のロジックを誰も深く理解していない「ゴーストコード」が積み重なったとき、数年後に発生するシステム全体のアーキテクチャ崩壊を、一体誰が食い止めるのか。

我々が明日から取り組むべき処方箋は、AIに仕事を奪われることを恐れることではない。むしろ、AIに「どの部分のオーナーシップを委ね、どの部分を人間が死守すべきか」という境界線を、組織の技術スタックやビジネスモデルに応じて冷徹に再定義することだ。例えば、AWS Amplifyのようなオープンソースへのコントリビュート活動を通じて、フレームワークやインフラの深い理解をエンジニア個人のコアコンピタンスとして磨き続ける一方で、日常の定型的なビジネスロジックのレビューは徹底的にAIに自動化させる。

AIが58%のPRを承認する時代において、あなたの価値は「コードをレビューできること」にはない。AIが提示した「Pending」の問いに対して、システムの未来を見据えた正しい意思決定を下せるか。そして、ブラックボックス化していくコードベースの舵取りを担う覚悟があるか。この問いに、あなたはどう答えるだろうか。