AI にコードレビューを任せる現場で、「人が決めること」と「機械が決めること」の境界をどう制度にするか
はじめに
この稿が答えるのは、日本の開発チームが今週抱えそうな質問です。「AI にコードレビューや承認を任せてよいのか」。答えは 2 つです。任せてよい。ただし、人が決めることと機械が決めることの境界を、規則の中に書き下してからにしてください。
書き下す、とは「AI に任せる場面を列挙する」ことではありません。Zenn で 2026 年 11 月 8 日と 6 日に公開された 2 本の実践記事は、この境界を実際の仕組みとして書いています。1 本は PR のリスク点数を機械に出し、AI には補正の幅だけを与えるツール（karamage 氏、以下「レビュー記事」）。もう 1 本は、タスク管理までエージェントに任せ、人間の作業は判断への回答だけにした運用（しもち氏、以下「タスク記事」）。
背景：読む速度と書く速度の差
レビュー記事の出発点は、AI が書く速度は上がり続けても、人間が読む速度はほぼ変わっていない、という観察です。全部を人が読む運用は、レビュー待ちの山を積み上げるだけです。
レビュー記事はこの問題の規模感として、Claude Code を開発するチームの公式ブログ（2026 年 10 月 15 日公開、レビュー記事経由で確認）を挙げています。述べているのは 3 点です。1 つ目は、コードの約 90% を Claude が書いていることです。2 つ目は、2026 年 6 月から 9 月にかけてマージされた PR が 2 倍以上に増えたことです。3 つ目は、差し戻し率が 40% 以上下がったことです。読み取るのは、レビューを止めず、読む大部分を機械へ移し、リスクに応じた承認に人の時間を残した形です。
仕組みその一：点数の決まりを先に書いている
レビュー記事のツール「CC Auto Review」は、PR の変更リスクを 0 から 100 点で機械的に出します。見ているのは変更の規模と広がり、認証や決済やマイグレーションや CI のような影響の大きい領域、秘密情報や動的コード評価のような危険パターン、テストの不足の 7 要素です。
AI の役割は、この点数を補正することだけです。1 項目あたり ±15 点、合計で ±20 点まで。足し算と上限・下限の処理はサーバーが行い、AI には数値の提案しかさせません。50 点を超えた PR は人間のレビューに回ります。
ここに書いてある決まりが 4 つあります。
- 説明文で点数は動かない。同じ変更差分なら、何度測っても同じ点数である。
- 秘密情報の混入は 90 点、破壊的なマイグレーションは 75 点、プロンプトインジェクション文は 60 点という下限を決めている。
- AI が重大な問題を確認した場合だけ、エスカレーションとして 60 点以上に引き上げる。
- AI の承認は人間の承認として数えない。承認は特定のコミットに対してのみ有効で、レビュー投稿の直前に最新のコミットを確かめ、変わっていたら投稿しない。
この 4 点は、レビュー記事が引用する Claude Code 公式ブログの原則（変更が階級を決める、著者が決めるのではない）を数字として実装した形です。
仕組みその二：判断が 1 行に収まる運用
タスク記事の環境では、司令塔のエージェントがタスク全体を管理し、人間の作業は「確認待ち」への回答です。件名、判断に要る事実、選択肢が 1 画面に並び、答えは番号と一言（「41 OK」）です。
この運用で人が止まる場所は決まっています。他人の目に触れる手前（レビュー投稿の前、他人の PR への投稿の前）、方針の選択、自分しかできない作業、コマンドの許可待ちです。
レビュー記事のツールは、「人間に回す」条件を AI を呼ぶ前に決めています。CI やマイグレーションやインフラや秘密情報や認証や課金に関わるパスを触っている、変更が 1,000 行を超える、点数が 50 点を超える、エスカレーションされた。自然言語で基準を増やせます。
制度としての落とし方：境界を 4 項目で書く
この 2 本の記事に共通するのは、境界を「信頼の度合い」で書かず、「決まり」で書いていることです。社内規則に落とすなら、次の 4 項目が型になります。
- 機械的に決める数値を決める。何を見ているか、下限がどこか。
- AI が動かせる補正の幅を決める。項目あたりの上限、合計の上限、足し算の場所。
- 必ず人間に回す条件を決める。領域、規模、点数、エスカレーション。
- 承認がどの対象に対して有効か決める。特定のコミット、直前での再確認。
「AI に任せてよい場面を列挙する」形の規則は、この 4 項目のどれにも対応していません。列挙は場面を増やすたびに古くなります。決まりは、場面が増えてもそのまま動きます。
レビュー記事は、AI レビューの見落としはゼロにはならない、と書いています。だからこそ、この 4 項目が規則の中に数字として入っているかどうかが、任せてもよいかを決める根拠になります。
まとめ
AI にレビューや承認を任せる判断は、「任せる・任せない」の二択ではありません。境界をどこで引くか、という設計です。レビュー記事は点数の決まりで、タスク記事は判断の収束の形で、その境界をそれぞれの実装として書いています。
規則を作る側への示唆は単純です。列挙の代わりに、上 4 項目を自チームの数値で埋めてください。それが埋まっていなければ、今の運用は「AI を信じている」だけです。
参考情報
- karamage「危ない PR だけ人間が見て、レビューは AI に任せ。AI 自動レビューツールを作りました」Zenn、2026 年 11 月 8 日公開。本稿の一次資料。
- しもち「タスク管理まで AI エージェントに任せたら、確認待ちに答えるだけになった」Zenn、2026 年 11 月 6 日公開。
- Claude Code チームの公式ブログ（2026 年 10 月 15 日公開）。karamage 氏の記事経由で確認。90%、2 倍、40% 超の数字は同チームの実測値として、記事経由の転記である。本稿はこの転記のみを根拠に使用する。
本稿は AI の支援を受けて執筆されました。事実の確認と内容の責任は筆者にあります。