レビューの4割を機械に渡した会社があります
渡さなかった6割の決め方が本題です

「AIにレビューさせている」と聞いた方へ

開発チームからAIレビューの導入を提案されている、あるいは外注先から「レビューはAIで効率化しています」と説明を受けた発注側の方に向けて書いています。

聞くべきことは、入れるかどうかではありません。どこまで渡して、どこから渡さないかです。そこを数字と条件で答えられる相手かどうかで、話は変わります。

割合を公開した実例があります

株式会社Bizibl Technologiesが2026年8月21日、PRの自動承認を実運用している記録を公開しました（AIネイティブな開発組織へ PR自動承認の設計と運用）。

自動承認に到達した割合は、全体で約40%。内訳はFrontendが約55%、APIが約25%です。

同じ会社、同じ仕組みで、部位によって倍以上の開きがあります。ここが読みどころです。

差を作っているのは、技術の難しさではありません

APIのほうがFrontendより難しいから、ではありません。壊れたときに戻せるかどうかが違います。

判定は4つの項目で決まります

同じ記録には、PRごとに次の4項目を1〜4点で採点する仕組みが書かれています。

そしてRecoverability が4のものは人間のレビューを必須とすると明記されています。

「ウェビナー配信は時間を巻き戻せない」という自社の業務特性が、そのまま判定条件に落ちています。抽象的な重要度ではなく、その事業で何が取り返しのつかない失敗なのかを、点数の形にしている。

3つの層は、置き換えの関係にありません

同じ記録は、レビューを3層に分けています。静的解析が機械的な判定（規約違反、機密情報の検知）、AIエージェントが局所的な問題の発見（単一責務になっているか、仕様に合っているか）、人間が全体最適な設計と事業影響の判断です。

上の層が下の層を代替しているのではありません。見るものが違うので、重ねている。

AIが作ったコードを人が見る観点はAIが作ったコードを人がレビューする理由で整理しました。今回の記録は、その観点のうち機械に渡せる部分を切り出して、残りを明示した形になっています。

自動承認率は、成果ではなく設定値です

40%という数字を「達成した効率」と読むと間違えます。これはどこまで渡すと決めたかの結果です。

判定条件を緩めれば率は上がります。上がった率が良いことなのかは、緩めた先で何が起きるかで決まる。だから発注先や社内から自動化率を提示されたときに聞くべきなのは、率そのものではなく、その率を作っている条件のほうです。

権限の評価順序を取り違えると承認が素通りする話は承認を挟んだつもりが素通りしていましたで書きました。仕組みとして人が入る設計になっていても、条件の書き方ひとつで実際には通ってしまいます。

限界を書いている点も読みどころです

同じ記録は、GitHubの「会話解決前のマージ禁止」設定について、開発者の性善説に依存していると書いています。仕組みで完全には縛れていないと自分で明示している。

導入事例でここまで書かれることは多くありません。うまくいった率だけを出す説明と、残っている穴も出す説明とでは、受け取り方を変えていいと思います。

提案を受けたときに確認すること

判断基準そのものを資産として残す考え方は機構は買える側に回りましたで扱っています。今回の4項目スコアリングは、その具体例のひとつです。

渡す範囲は、事業の側から決まります

どこまで機械に渡せるかは、技術の成熟度では決まりません。その事業で何が取り返しのつかない失敗かによって決まります。だから正解は会社ごとに違い、外から持ってきた率をそのまま当てはめることもできません。

いまAIレビューの導入を検討している段階でしたら、お問い合わせからご相談ください。自社にとって戻せない変更は何か、というところから一緒に整理します。