AIが作った物の確認を、npakaさんが解説。Anthropicの7段階レビューと、人に残る5つの判断

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、npakaさんがnoteにまとめた、Anthropicのコードレビューの記事を読んで、解説します。

この記事は、私が保存したブックマークです。Anthropicは、AIが書いたコードの確認を、何層にも重ねています。その層の設計が、私が10月に書いた置き方の記事とつながると感じて、取り上げることにしました。

元ネタはソフトウェア開発の話です。でも私は、AIに書類や記事を作らせる側として読みます。「AIが作った物を、誰がどこまで確認するのか」の設計図として、一緒に読んでいきましょう。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「2-2. コードレビューの目的と課題」の節

重要なのは「人間がコードを読んだか」ではなく、「その変更で何が壊れる可能性があり、どの検査方法が適切か」という考え方です。

「人が読んだか」ではなく「何が壊れうるか」を考える。npakaさんは、コードレビューの考え方をこう整理しています。

Anthropicでは、Claude Codeのコードの約90%を、Claude自身が書いています。

npakaさんによると、主要なモノレポ（大きな1つの保管庫に、たくさんのコードをまとめて置く方式）で、1日の変更の数が2026年5月の約2,500件から、9月には3万件以上に増えました。

この量を、人が1行ずつ読むのは現実的ではない。ここが出発点です。変更はPR（コードの変更の提案書）の形で出され、本体に取り込むこと（マージ）の前に確認されます。

2026年6月から9月にかけて、マージされたPRは2倍以上になりました。それなのに、変更を取り消す割合（リバート率）は40%以上下がっています。数が増えて、質が落ちたわけではない、ということですね。

コードレビューの目的は、npakaさんによると2つです。1つは、不具合が本番に届く前に見つけること。もう1つは、チームがコードへの理解を共有することです。どちらも大事です。

そのうえで、確認の考え方が変わります。人が全部を読んだかではなく、この変更で何が壊れる可能性があり、どの検査方法が合っているかを考える。ここが大きな転換です。

レビューも、PRを出した後の最後の関門だけではない。コードを作っている最中から、続けて行うものに変えています。並走するイメージです。

Anthropicの原文によると、目標は、Claude Codeのほとんどの変更を、人間の関与を最大1人（書いた本人でもよい）で本体に取り込み、取り消しや障害を増やさないことです。

人の時間は、1件あたりの承認の数、人のコメントの数、人を待つ時間で測ります。取り消し率と障害率は歯止めだ。これが上がれば、人の時間を減らしたのではなく、別の所へ移しただけだからです。

あなたがAIに作らせた資料や見積書を、毎回1行ずつ読み直しているとします。量が10倍になったら、同じやり方が続くでしょうか。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「3-1. PR作成前のAIレビュー」の節

コード生成を担当したClaudeには、完了報告だけでなく、テスト、ビルド、スクリーンショットなどによる動作確認を求めます。さらに、別のサブエージェントが新しいコンテキストでコードの差分をレビューします。

作ったAIに、できましたと言わせるだけでは足りない。動作確認の結果を見せてもらい、さらに別のAIが新しい目で見直す。引用は、その2段をこう説明しています。

まず1段目です。コードを書いたClaudeには、完了報告だけでなく、テスト、ビルド、スクリーンショットで実際に動くことを確認させます。

Anthropicの原文は、デザインと見比べるスクリーンショットも例に挙げています。証拠つきで受け取るんです。

Claude Codeの作者のBoris Chernyさんは、AIに自分の仕事を検証する手段を渡すことが、いい結果のために最も大切だと見ています。最終結果が2〜3倍よくなるという見立てです。

次に2段目です。別のサブエージェント（別の役割で動くAI）が、新しいコンテキスト、つまり作った経緯を知らない状態で、変更点を見ます。作った本人の思い込みが入りにくい見方ですよね。ここが肝です。

この段階では、Anthropic社内のSkill（AIに渡す手順書）も使います。バグを探すもの、変更点を簡潔にするもの、端から端まで動作を確かめるものがあります。

画面の変更は、デザインの指針に照らして確認します。

レビューのルールは、2つの文書に書きます。CLAUDE.mdは、プロジェクトの説明書きだ。技術の構成、決まり、目標と目標でないことを書きます。毎回読み込むので、大きなコードでは短く保ちます。

REVIEW.mdについて、Anthropicの原文は、コードの持ち主が書くものだと説明しています。その部分で何が大事かを、点検役のAIに伝える文書です。

原文によると、よい書き方は、短く、その場所での「失敗」を一言で書くことです。たとえばドキュメントなら嘘をつくこと、設定なら別の場所へ流すことです。地味ですが効きます。

さらに原文は、細かい指摘に上限をつける、飛ばす場所を挙げる、推測でなく根拠となる場所を求める、直す物がなければ「ない」と言い切らせる、といった書き方も挙げています。

同じ指摘が繰り返されたら、個別に直すのではなく、Skillや書き方の自動チェックのルール、先ほどの文書を直して、根元で止めます。

AI氣道『別のAIに点検させる理由を、イケハヤさんが会員登録の例で話します』より

「モデルの名前を追いかける時間を減らし、作る担当と点検の担当だけを決めておく。AIに委ねて、人は積み減らして生き直す。点検の回数は、作った物が外に出た時に何が起きるかで決めます。それが私の置き方です。」

作る担当と点検の担当を分ける置き方を、私は『別のAIに点検させる理由を、イケハヤさんが会員登録の例で話します』で書いています。

作った本人に「終わった」を言わせない点は、同じです。AIに作らせる側の私にとって、ここがいちばん自分の置き方と重なります。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「3-2. 複数エージェントによるPRレビュー」の節

まず複数のエージェントが並列で問題を探し、別のエージェント群が各指摘の妥当性を判定します。十分な合意が得られた指摘だけを人間に提示することで、誤検知を減らしています。

点検するAIが出した指摘を、さらに別のAIが確かめてから人に出す。引用が言っているのは、この2段構えです。

Anthropicでは、すべてのPRに、人が見る前にClaudeがレビューをかけます。

変更した所だけでなく、リポジトリ全体（コードの保管場所の全体）と変更の意図に照らして、問題を解いているか、システムに合うか、他を壊さないかを見ます。

指摘の出し方が特徴的ですね。複数のエージェントが同時にバグを探し、別の群が各指摘に投票します。十分な数が本物と判断した指摘だけが投稿されます。絞ってから出すんです。

書き方の好みだけの指摘や、片付けだけの指摘は落とす。これは社内のPRで試して比べてから採用した、とAnthropicの原文は書いています。

コメントは重大度の順に並び、Important（重要）、Nit（細かい指摘）、Pre-existing（この変更が入れたのではない既存のバグ）のタグが付きます。すべての指摘に答えが必要ですよ。

直すか、理由を書いて閉じるかのどちらかです。

この仕組みの導入で、実質的なレビューコメントが付く社内PRの割合は、16%から54%になりました。1,000行を超えるPRのほとんどに指摘が付き、小さなPRにはほとんど付きません。

管理者は、リポジトリごとにQuick、Standard、Deepの3段階から深さを選びます。見逃した不具合1件の損が、追加のレビュー時間より大きい所では、Deepに価値があります。

セキュリティも、専用のAIレビューを別に走らせます。バグかセキュリティの指摘が1つでも開いたままだと、本体に取り込めません。誤検知なら、短い理由を書いて閉じる。ここは別枠です。

機械の検査も重ねます。書き方の自動チェック（Lint）、型の整合性の検査、各環境でのテスト、ビルドの成功確認です。PRには、どうテストしたかと、どう元に戻すかも書きます。ここは従来どおりです。

夜の間にAIが直し、朝には次の1周を終えたPRが待っていることもある、とAnthropicの原文は書いています。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「3-5. リスクに応じた人間の承認」の節

AIの承認が、人間の承認として数えられることはありません。

人が承認する数は、変更の危険度で変わります。AIが承認した分は、人の数に入れません。引用は、その線引きの核心です。

npakaさんがまとめた区分はこうです。低リスクは0人で、ドキュメントや文言の修正などが当たります。中リスクは1人で、通常の機能変更やキャッシュなどです。高リスクは2人で、特に危険度の高い変更です。

Anthropicの原文によると、低リスクには社内限定の機能や、スイッチの裏の追加的な変更も入ります。自動レビューとセキュリティ検査が通っていれば、人の承認は要りません。

階層を決めるのは、変更の中身だ。書いた人ではありません。分類器（AIの振り分け役）が変更を読んで階層を選び、別の分類器が、階層が不要と言っても、この変更には別の人が要るかを問います。ここが大事です。

持ち主が敏感な場所と指定したファイルや、CI（自動検査を動かす設定）のファイルは、常に人が見ます。

軽い道を使えるのは、リポジトリの信頼リストにある書き手、主に持ち主のチームだけです。それ以外は2人目の承認が要ります。

エージェントの承認は、人の承認に数えない。自動レビューは低リスクの変更を通せますが、人間を求める枠は埋められません。枠は別なんです。

AIが書いたPRでは、そのAIを指揮した人が、必要なレビュアーの1人に数えられます。自分でコードを打った場合と同じ扱いです。

承認は、特定の1つの変更に対するものです。AIが新しい変更を足したり、手で解決したりして、仕組みが保証できない変更が入れば、承認を取り直します。

つまり、点検役のAIを増やしても、人が持つ枠は減らない。減るのは、人が見る必要のない低リスクの確認です。ここがポイントです。

AI氣道『Claude Modsで、Claude Codeの「終わり」を別の判定者に言わせるやり方』より

「このブログでも、公開する現物は、作った人と別の系統のモデルに検収させます。公開の最終GOは、私が持ちます。」

検収は別の系統のAI、最終GOは私という線引きを、私は『Claude Modsで、Claude Codeの「終わり」を別の判定者に言わせるやり方』で書いています。

AIが点検するのはかまわない。ただ、人の枠は埋まらない。この向きは、私の線引きと同じだと読みました。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「3-7 障害検出とロールバック」の節

不具合の予防だけでなく、発生した不具合をすばやく発見して元に戻せることが重要になります。

不具合を完全になくすのは無理だ。だから、早く見つけて、すぐ戻せるようにしておく。引用は、その最後の層の考え方です。

マージの前には、マージキューという仕組みがある。他の変更と組み合わせた状態で、すべての検査をやり直します。別々なら通る2つの変更が、組み合わさると本体を壊すのを防ぐためです。合わせ技のチェックです。

新しい機能は、フラグ（機能のオン・オフのスイッチ）の裏に入れて、まずAnthropicの社員に出します。社員が多く使うので、利用者より先に不具合が見つかることが多いそうです。

公開は、一般向けのlatestチャンネルが先で、stableチャンネルは遅れて続きます。影響が出る範囲を、小さい所から広げていく順番です。広げ方も段階的です。

すり抜けても、フラグは公開し直さなくても切れます。変更の取り消しも、数分でできる形にしてあります。

Claude Codeには、週替わりのオンコール（当番）がいます。インシデント、つまり障害のレビューでは、どの層が捕まえるべきだったかを問います。問うのは仕組みの側です。

Anthropicの原文は、足りない所も書いています。数字が動いた時に承認を自動で厳しくする安全弁は、まだないそうです。人間なしでマージするコードを増やす前に、エンジニアが欲しがっているとのことです。

レビューするAI自身も育てる。過去に障害を起こしたPRと、その修正や取り消しの履歴を集めて、評価用のデータにします。レビュアーのAIを、毎日それで走らせます。

レビューの設定やモデルを変えた時も、同じデータで採点し直します。コメントを受けた人が、直した、間違いだった、意図した動作だった、どうでもよい、のどれで返したかも分類して、ノイズ（誤検知）を測ります。

AI氣道『AIチームビルディング｜AIの出力をそのまま出す人はサボりか。けんすうさんと篠塚孝哉さんの対談を私の運用の数字で確かめた』より

「私は、公開などの最後のGOと、自分が違和感を感じる所を持つ。数えられる確認は機械へ任せる。」

数えられる確認は機械へ、最後のGOと違和感は私という分け方を、私は『AIチームビルディング｜AIの出力をそのまま出す人はサボりか。けんすうさんと篠塚孝哉さんの対談を私の運用の数字で確かめた』で書いています。

機械の検査を重ねたうえで、人はリスクの高い所を持つ。元ネタのこの考え方と、私が持つ所の線引きは、重なると読みました。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「4-2. 無限レビューを防ぐ仕組み」の節

AIレビューでは、不具合の検出能力だけでなく、レビューが収束することも重要です。

AIが直して、別のAIが見て、また直す。この往復が終わらなくなる問題があります。引用は、見つける強さと同じくらい、終わることが大事だと言っています。

流れはこうです。AIがコードを直す、別のAIがレビューする、新しい指摘が出る、またAIが直す。人が止めなければ、続いてしまう。ここが落とし穴です。

Anthropicの原文によると、あるPRでは、一晩で50回を超えるレビューと修正が重なりました。書き手が止めるまで続いたそうです。

調べると、指摘され続けたコードの約59%は、最初のレビューの時点からあったものでした。点検役のAIが新しい不具合を見つけていたのではなく、古い不具合を毎回少しずつ見つけていたのです。意外な数字です。

Anthropicは、自分たちでも悪化させていた、と書いています。毎回数周まわすことに慣れていたからです。そこで、見つける力と一緒に、通るまでの回数も追うようにしました。

止める工夫は4つです。1つ目は、3回レビューしたら、点検役が書き手に方針そのものを見直すよう求める上限です。2つ目は、最初の数回のあとは、新しく変わった所だけを見直すことです。シンプルな上限です。

3つ目は、バグの種類を指摘して、同じ種類を全部の場所で直させることです。4つ目は、すでに投稿した指摘を繰り返さないことです。

夜の間には、既存のコードにもレビューのAIが走ります。古い不具合を、別の場所で見つかる前に拾うためです。

ノイズ（誤検知）の重さが、書き手が人かAIかで違う点も大事です。人は細かい指摘を数秒で流せます。でもAIは直してしまい、新しい変更と次のレビューが生まれます。

だから優先順位が文書に書いてあります。先は、本物のバグを捕まえること。次が、レビューの回数を減らすことです。

npakaさんのnote「AnthropicのAI時代のコードレビュー術 – Claude Codeによる自動レビューと人間の役割」の「5-1. 人間が担当する重要な判断」の節

AIがコード生成とレビューの大部分を担当しても、人間の役割がなくなるわけではありません。

AIがコードを書いて、AIがレビューしても、人の役割はなくならない。引用の言うとおり、残る判断を、npakaさんは5つに整理しています。

1つ目は開発方針で、そもそも、その機能を作るべきかです。2つ目は重要な変更で、課金、自動更新、CIなど危険度の高いものです。3つ目はアーキテクチャ、つまり今後の開発に影響する設計の判断です。どれも人の仕事です。

4つ目は検証結果で、テスト結果や、AIレビューの指摘が妥当かどうかです。5つ目は責任で、リリースした変更の結果に責任を持つことです。

Anthropicの原文は、証拠を読むことに触れています。テスト出力、実行したコマンドと返り値、スクリーンショット、点検役の指摘です。

チェックが何を見逃すかを言えないなら、さっと承認せず、本物のレビューを求める、と書いています。

責任の考え方は「着地させた人が持つ」です。小さな変更や中くらいの変更を着地させて何か起きたら、直すのは普通は着地させた人です。責めるためではなく、一番文脈を持っているからです。責任と責めは別物です。

これが回る理由として、変更が小さいこと、フラグやリバート、段階的な公開で多くの間違いが数分で元に戻せること、影響の大きさで基準が決まること、利用状況が素早く表に出ることを挙げています。

作るべきかの判断にも、人が出る。AIのおかげで着手が安いので、着地すべきでない仕事も出ます。その時は、早い段階の相談の場で理由を尋ね、別の方向を出して、PRを閉じるか作り直します。

理解を共有する正式な仕組みは、ないそうです。Claude Codeの頭の中のモデルを完全に持つ人はいない、と原文は書きます。知りたい部分があれば、その部分の解説をClaudeに書かせます。

数分でできて、今のコードを反映しています。

AI氣道『AIの速さに確認が追いつかない問題を、和田卓人さんが解説。「レビュー解体」と、任せても手放せない理解』より

「ただ、確認が通ったから中身を知らなくていい、とは私は思いません。何を任せていて、どこで間違うと誰が困るのか。そこは、手元に残したいです。」

確認が通っても中身は手元に残したいという考えを、私は『AIの速さに確認が追いつかない問題を、和田卓人さんが解説。「レビュー解体」と、任せても手放せない理解』で書いています。

私は、確認が通ったことと、理解していることを別に置きたいです。AIが作る量が増えるほど、この差が効いてくると読みました。

最後に、あなたの仕事に引き寄せてみます。AIに作らせる物を1つ決めて、3つの問いに答えてみてください。何が壊れうるか。どの確認が合っているか、別のAIか、機械か、人か。間違った時に戻せるか。

元記事の問いを、私はこう置き換えて考えます。

AnthropicのClaude Codeは、コードの約90%をClaudeが書く中で、確認を何層にも重ねています。npakaさんの記事は、その全体像を分かりやすくまとめていました。

層は、作った直後の別のAIの目、複数のAIと投票、機械の検査、リスクで変わる人の承認、段階公開とすぐ戻せる仕組み、の順に並びます。

AIレビューが終わらなくなる問題にも、3回で方針を見直すなど、収束させる工夫がありました。見つける強さと一緒に、終わることも設計するのです。

人には、作るべきか、高リスクの変更、設計、証拠を読むこと、責任が残ります。私は、確認が通ったから中身を知らなくていい、とは思いません。

元ネタはコードの話ですが、AIに書類や記事を作らせる私たちにも使えます。まず1つ、何が壊れうるか、どの確認が合うか、戻せるかを書き出してみてください。

この記事で学んだことを誰かに教えて恩送りして学びを深めよう！