AIが9割書いたコードを誰がレビューする?――Intercom・Onaに学ぶ「リスク別自動承認」という現場の解

2026年8月20日

AIエージェントがコードの大半を書く時代になり、現場のボトルネックは「執筆」から「レビュー」へと移った。GitLabやLinearBなど複数の2026年調査は、AI生成コードのレビュー待ち時間やPRサイズが軒並み悪化していると報告している。その中でIntercomやOnaは、すべてのPRを一律に人間がレビューするのではなく、リスクの低い変更はAIエージェントが自動承認し、リスクの高い変更だけ人間に回す「リスク別自動承認」という運用でレビュー渋滞を解いた。本稿はその実務と、見落とせないセキュリティ面の注意点を整理する。

レビューが新しいボトルネックになった

GitLabが2026年6月に発表した「AI Accountability Report」(6カ国のエンジニア・技術系意思決定者1,528人対象)によれば、85%が「AIによってボトルネックがコード執筆からレビュー・検証へ移った」と回答し、80%は「自社はガバナンス整備よりも先にAI導入を進めてしまった」と答えている。AI生成コードで何らかのガバナンス課題を抱えていると答えた組織は92%にのぼる一方、AI導入によるROIが期待を上回ったとする回答も60%あり、恩恵と統制コストの両方が急拡大している構図が見える。

LinearBが4,800チーム・42カ国・810万件のPRを分析した「2026 Software Engineering Benchmarks Report」では、エージェントが書いたPRはレビュー担当者に着手されるまで平均1,055分と、人間が書いたPR(201分)の5.3倍待たされている。着手後のレビュー自体は約2倍速く終わるが、そもそも列に並ぶ時間が長い。さらに75パーセンタイルで見るとAI支援PRは408行と、人間PR(157行)の2.6倍の大きさになりやすく、レビュアーがそのまま承認する割合はボット作成PRで32.7%、人間作成PRで84.4%と大きな差がある。

Faros AIが22,000人のエンジニア・2年分のデータをもとにまとめた「Acceleration Whiplash」レポートでも、コードレビューにかかる時間の中央値は441.5%増、PRサイズは51.3%増、1PRあたりの変更ファイル数は59.7%増と軒並み悪化している。一方でエンジニア1人あたりの完了エピック数は66%増、タスク完了率も34%向上しており、「執筆は速くなったが、その分レビューに時間を吸われる」という生産性パラドックスが数字にはっきり表れている。CircleCIの「2026 State of Software Delivery」(2,800万件超のCIワークフロー分析)も同様の傾向で、フィーチャーブランチ上のスループットは前年比約50%伸びた一方、mainブランチへの反映は伸びておらず、両方を同時にスケールできたチームは20チームに1チーム未満だったという。

数字で見る「詰まり具合」

調査	対象規模	主な指標
GitLab AI Accountability Report(2026年6月)	6カ国・1,528人	85%が「ボトルネックはレビューへ移った」と回答
LinearB 2026 Benchmarks	42カ国・4,800チーム・810万PR	AI製PRの着手待ちは人間製の5.3倍
Faros AI Acceleration Whiplash	22,000人・2年分	レビュー時間の中央値が441.5%増
CircleCI State of Software Delivery	2,800万件超のCIワークフロー	featureブランチ急増もmain反映は伸びず

解決策は「リスクで分けて自動承認」

Intercom:PRの93%がエージェント関与、19%以上を無人承認

Intercomは公式ブログ「AI is approving our pull requests: Here’s how we made it safe」(2026年4月21日)で、主要2コードベースにおいてPRの93%以上がエージェント主導になっていることを明かした。そのうち19%超は人間レビュアーなしで自動承認されている。仕組みは、社内のコーディング規約を学習させたレビュー用エージェントが、スタイルの一貫性・テストカバレッジ・セキュリティ上の脆弱性・アーキテクチャ指針をチェックし、リスクが低いと判断した変更だけを自動承認、曖昧・複雑な変更は人間にエスカレーションするというもの。SOC 2やHIPAA、ISO 27001、ISO 42001、AIUC-1といったコンプライアンス要件を満たし続けられるかを検証するため、外部監査法人Schellmanを早い段階から巻き込んでいる点も特徴だ。

Ona:承認までの時間を74%短縮

Ona(旧Gitpod)の事例「How auto-approving low-risk PRs with AI cut our lead time by 74%」によれば、初回承認までの中央値は2時間49分から3.8分へ短縮し、リードタイム全体は74%減少、デプロイ頻度はチーム規模を変えずに3倍になった。導入前は10分以内に承認されるPRが13%しかなかったが、導入後は73%に上昇している。Onaの自動化ボットはすべてのPRをまずレビューし、リスクが低いものはボットの承認で足りるとし、それ以外は人間がdiffを開く前に表面的な問題を先にスクリーニングする。あわせて、機械的なレビュアー自動割り当てをやめ、PR作成者自身にレビュアーを選ばせる運用に変えたことも、無視されがちな通知を減らす効果があったという。

画面に映るコードとプログラマーの反射 — Photo: qubodup / CC BY 2.0(Openverse経由)

セキュリティ面のブレーキも忘れずに

自動承認を広げる際に無視できないのが、AI生成コードのセキュリティ品質だ。Veracodeの「Spring 2026 GenAI Code Security Report」(2026年7月28日発表)では、AIコード生成タスクの安全性合格率は56%で頭打ちになっており、約44%のタスクでOWASP Top 10に該当する脆弱性が検出されている。構文・コンパイルの合格率は2023年以降50%前後から95%まで伸びた一方、セキュリティ合格率はモデル世代が進んでも45〜55%からほとんど動いていない。特にXSS対策を要するタスクの合格率はわずか15%だった。AI導入企業ではコミットされるコードの「およそ半分」がAI製になっているというから、この合格率の低さは軽視できない。独立系ベンチマーク「AppSec Santa」の2026年調査でも、6種のLLMを横断してOWASP Top 10相当の脆弱性が確認されたコードは全体の25.1%(最良モデルで19.1%、最悪クラスで29.2%)にのぼり、確認された脆弱性のうちインジェクション系(CWE-78/89/94)が33.1%を占めたと報告されている。

ツール側の対応はまだ発展途上

現場の運用が先行する一方、プラットフォーム側の機能はまだ追いついていない。GitLabのイシュートラッカーには「AI作成コミットを含むマージリクエストには追加承認を要求したい」という要望(issue #578758、2025年10月頃オープン、2026年8月時点で未実装)が挙がっている。人間作成のMRは通常1承認で済ませつつ、AIサービスアカウントによるコミットを含むMRだけ2人承認を必須にしたい、という具体的な要望だが、まだ機能要望のままだ。GitHub Copilotについても、自動レビューコメントは組織が必須とする人間承認数にはカウントされず、あくまで参考情報という位置づけになっている点は運用設計時に押さえておきたい。

現場で試す際のポイント

いきなり全PR自動承認を目指さず、影響範囲が小さい変更(ドキュメント修正、テスト追加、依存関係の軽微な更新など)から自動承認の対象を絞る。
自動承認エージェントには自社のコーディング規約・セキュリティチェックリストを明示的に学習させ、判断基準をログとして残す。
SOC 2やISO 27001など既存の認証・監査要件に自動承認フローがどう影響するか、早い段階で監査担当や外部監査法人に確認する。
レビュアー自動割り当てのような「形だけの人間レビュー」を減らし、人間が本当に見るべき変更に注意を集中させる設計に変える。
セキュリティ合格率は生成AIのモデル世代が進んでも大きく改善していないため、自動承認の対象からセキュリティ影響の大きい変更(認証・認可・出力エスケープ処理など)は当面外しておく。

主な情報源

各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。