Anthropicは2026年3月9日、Claude Code向けのCode Reviewをリリースした。その発表には、あらゆるエンジニアリングマネージャーを顔しかめさせる数字がひとつあった。Anthropic社内では、エンジニア1人あたりのコード出力量が1年で200%増え、レビューがボトルネックになっていたのだ（Anthropic）。本質はそこにある。AIコーディングはレビュー作業を消し去らなかった。圧力がかかる場所を移しただけだ。
有効な対応は、「Claudeに自分の宿題を採点させよう」ではない。それをやると、礼儀正しいバグ製造機ができあがる。有効な対応は、Claude Code Reviewを、チームが本気で信じているルールにもとづく再現可能なPRゲートに変えることだ。
Anthropicのセットアップドキュメントのおかげで、これはもう現実的になっている。レビュアーは@claude reviewとコメントしてレビューを起動でき、Code Reviewはリポジトリ内のCLAUDE.mdファイルと、ルート階層のREVIEW.mdを読む。CLAUDE.md違反はnitレベルの指摘として扱われ、ClaudeはPRによってCLAUDE.mdが古くなった場合にそれを指摘することさえできる（Claude Help Center）。REVIEW.mdはレビュー専用ルールを書く場所だ。Anthropicが例として挙げている「新しいAPIルートには必ず統合テストが必要」といったルールを置く。
この一文が要だ。AIレビュアーに「気をつけて」と頼むのをやめよう。リポジトリの法律を与えるのだ。
問題: AIによってPRレビューは騒がしくなった
コミュニティでの議論がややこしいのは、どちらの側も正しいからだ。
Claude Code Reviewに関するHacker Newsのスレッドでは、開発者たちが価格、価値、そしてAIベンダーがAI生成コード向けのレビュアーを売っているという居心地の悪い事実に突っ込んでいた。あるコメント投稿者は、Anthropic自身の大規模PRに関する数字を指して、エージェント型開発の品質に対する警告サインだと読んだ。一方で、深く見てくれる第二の目こそ、このツールが価値を発揮する場所だと主張する人もいた（Hacker News）。
Redditには、同じ議論のより実務的な版がある。あるスレッドでは、開発者が「Claudeが自分には理解できないコードを書くことがあるのに、Claude生成コードをレビューなしで通すほど本当に信頼しているのか」と問いかけた。回答は率直だった。レビューしろ、検証しろ、変更を小さく保て、委任したからといって責任が消えるふりをするな（Reddit）。別のスレッドでは、Claudeの出力を別のAIエージェントでレビューすることについて話し合われていた。ただし、そのレビュー自体もコードベースに照らして確認する前提だった（Reddit）。
私の見方はこうだ。Claudeが書いたコードをClaudeにレビューさせるのは、それを独立した判断だと扱わない限り問題ない。膨大なコンテキストを持ち、所有意識はない、非常に速くて非常に文字通りに読むジュニアレビュアーだと思えばいい。退屈な抜け漏れ、ファイル間の不整合、足りないテスト、セキュリティ上の落とし穴、古くなったドキュメント、人間のレビュアーが読み飛ばしがちな箇所を拾うべきだ。
最終承認者にしてはいけない。
Anthropicもこれを明言している。Code ReviewはPRを承認しないし、それ単体でブロックもしない。既存のレビューワークフローはそのまま残る（Claude Help Center）。だから「ゲート」はチームのゲートだ。Claudeが実行されるまで人間は承認しない。Importantの指摘は解消するか明示的に却下する。PR作者はリポジトリ固有のルールに対応する。
退屈だ。いいことだ。退屈なゲートがインシデントを防ぐ。
セットアップ: 2つのMarkdownファイル、2つの役割
Claude Code Reviewには重要な記憶面が2つある。
CLAUDE.mdは共有のプロジェクトコンテキストだ。レビューだけでなく、Claude Codeセッション全般に適用される。Anthropicは、コマンド、規約、短いアーキテクチャメモ、厳格な制約、既知の注意点を書く場所として使うことを推奨している。また、コンテキストに読み込まれるため、シグナル密度を高くし、おおむね200行未満に保つことも推奨している。Enterpriseセッションではプロンプトキャッシュにより繰り返しのトークンコストは減るが、それでも同じだ（Claude Help Center）。
REVIEW.mdは別物だ。リポジトリのルートに置き、レビュー専用で使う。AnthropicのCode Reviewドキュメントによると、その内容はすべてのレビューエージェントに高優先度の指示として注入される。severity、nitの量、スキップルール、リポジトリ固有のチェック、検証基準、再レビュー時の挙動を制御する場所だ（Claude Code Docs）。
私ならこう分ける。
| File | Purpose | Good rules | Bad rules |
|---|---|---|---|
CLAUDE.md | すべてのClaude作業向けのプロジェクトメモリ | ビルドコマンド、アーキテクチャ、「リクエスト検証にはZodを使う」 | 長い経緯、曖昧な好み、重複したAPIドキュメント |
REVIEW.md | PRレビューポリシー | 「新しいAPIルートには統合テストが必要」 | 「きれいなコードを書こう」のような一般論 |
| CI config | 決定的な強制 | 型チェック、ユニットテスト、lint、マイグレーションチェック | コンパイラで証明できることに対するLLMのみのチェック |
安定したコンテキストはCLAUDE.mdに置く。レビューの圧はREVIEW.mdに置く。決定的に判定できるものはCIに置く。
APIルートのための本物のゲート
あるバックエンドチームが、正常系のユニットテストはあるが統合カバレッジのないルートを出し続けているとする。人間のレビュアーは時々それを拾う。Claude生成のPRは事態を悪化させる。エージェントはそれっぽいハンドラーコードを生成するのは得意だが、チーム固有のレビューの傷跡を覚えておくのは苦手だからだ。
まずはCLAUDE.mdから始める。
# Project conventions
- API routes live in `src/routes`.
- Integration tests live in `tests/integration`.
- Use `requireAuth()` on non-public routes.
- Validate request bodies with Zod schemas from `src/schemas`.
- Run `pnpm test:integration` before marking API work complete.次に、ルート階層のREVIEW.mdを追加する。
# Code Review Rules
Treat these as Important unless stated otherwise.
## API routes
If a PR adds or changes a file under `src/routes/**`:
- Flag missing integration test coverage in `tests/integration/**`.
- Flag routes without explicit auth, unless the route is listed as public.
- Flag request bodies that are not validated with a Zod schema.
Do not accept unit tests as a substitute for route-level integration tests.
## Evidence bar
For every Important finding, cite the changed file and the missing or conflicting evidence.
If the claim depends on a convention, cite this REVIEW.md rule.最後のセクションが重要だ。LLMレビュアーは自信満々にデタラメを出すことがある。根拠を求めることで、指摘をファイル、行、または明示的なポリシーに結びつけざるを得なくなる。誤検知はなくならないが、レビューの形は「雰囲気」から「見せて」に変わる。
ここでPRが次を追加したとする。
// src/routes/billing.ts
router.post("/billing/plan", async (req, res) => {
const result = await updatePlan(req.body.planId);
res.json(result);
});良いClaude Code Reviewのコメントは、だいたいこうなるはずだ。
- Important:
src/routes/billing.tsが新しいPOSTルートを追加しているが、見える範囲にauthがない。 - Important: リクエストボディがスキーマ検証なしに
req.body.planIdを読んでいる。 - Important:
tests/integration/**配下に対応する統合テストが追加されていない。
それでも判断するのは人間のレビュアーだ。もしかすると、ルーターには上位でauthミドルウェアが適用されているかもしれない。統合テストは生成された契約テストスイートにあるかもしれない。それでいい。マージ前にその議論を強制できたなら、ゲートは仕事をしている。
お金を燃やさずに起動する
Anthropicはリポジトリのトリガーモードを3つ用意している。PR作成後に1回、pushごと、手動だ。手動の場合、誰かが@claude reviewとコメントするまでコストは発生しない。その後、そのPRへの追加pushでは自動的にレビューが走る（Claude Help Center）。
ほとんどのチームでは、「pushごと」から始めるべきではないと思う。Anthropicによると、Code Reviewは平均で約20分かかり、一般に1レビューあたり15〜25ドル程度、PRのサイズと複雑さに応じて増える（Anthropic）。本番インシデントに比べれば安い。ESLintを走らせるのに比べれば高い。
段階的なゲートを使う。
- すべてのPRで通常のCIを実行する。
- リスクの高いPRには
@claude reviewを付ける。 - 大きなPR、auth変更、決済変更、マイグレーション、公開API変更は、人間の承認前にClaudeレビューを必須にする。
- ちょっとしたタイポ修正のたびではなく、大きな変更後にClaudeレビューを繰り返す。
- 最終承認は人間が持つ。
軽量なGitHub PRチェックリストにすると、ゲートが明確になる。
## AI Review Gate
- [ ] CI is green.
- [ ] `@claude review` has run, or this PR is exempt.
- [ ] Important findings are fixed or explained.
- [ ] If this PR changes conventions, `CLAUDE.md` is updated.
- [ ] If this PR changes review policy, `REVIEW.md` is updated.自分たちのワークフロー内でClaudeを走らせたいなら、AnthropicのGitHub Actionsドキュメントにはanthropics/claude-code-action@v1とコードレビュープラグイン設定が載っている。APIキーにはGitHub Secretsを使うというおなじみの注意もある（Claude Code Docs）。この方法ならCI側の制御がしやすい。マネージドなCode Reviewルートなら、Anthropicが説明する、より深いマルチエージェントレビュアーを使える。
混同してはいけない。片方はプログラム可能な自動化。もう片方は有料の、深掘り型レビュアーだ。
コツ: Claudeにスタイルではなく契約をレビューさせる
悪いREVIEW.mdはフォーチュンクッキーみたいに読める。
Please ensure the code is clean, maintainable, secure, and well tested.これではぐちゃっとした出力になる。
良いREVIEW.mdは傷跡をエンコードする。
## Database migrations
Flag as Important if:
- A migration adds a non-null column without a default on an existing table.
- A migration backfills data without batching.
- Application code starts reading a new column before the migration is deployed.
Skip:
- Formatting comments in generated Prisma client files.ここでAIレビューは役に立つ。シニアエンジニアの審美眼を置き換えるのではない。チームの制度的記憶を、すべてのPRで再生するのだ。
うまく機能するルールをいくつか挙げる。
## Re-review behavior
On the first review, report Important and Nit findings.
On later reviews of the same PR, suppress new Nits unless they are directly caused by the latest push.
## Test policy
Flag missing tests only when the changed behavior is observable through a stable public interface.
Do not request snapshot tests for purely visual copy changes.
## Security policy
Flag any new endpoint that:
- Accepts user input without validation.
- Performs authorization by trusting a user-provided account ID.
- Logs tokens, session IDs, API keys, or full request bodies.ないものに注目してほしい。「コードをエレガントにしろ」はない。エレガンスは人間がレビューで議論すればいい。Claudeが確認すべきなのは契約だ。
スレッドで見落とされていること
HNやRedditの議論は、同じ問いをぐるぐる回っている。AIはAIコードをレビューすべきか？
問いが間違っている。
正しい問いは、レビューのどの部分を明文化する覚悟があるか、だ。
レビュー文化がシニアエンジニアの頭の中にだけあるなら、Claude Code Reviewはうるさくて恣意的に感じられる。レビュー文化がリポジトリのルールとして書かれているなら、それは増幅器になる。CLAUDE.mdはプロジェクトの動き方をClaudeに伝える。REVIEW.mdはチームがマージを拒むものをClaudeに伝える。
これは「Claudeのためにドキュメントを書くのか」という不満への答えにもなる。そう、開発者はいまやエージェント向けにドキュメントを書いている。馬鹿げて聞こえるかもしれないが、そのドキュメントはオンボーディング資料であり、レビューポリシーであり、インシデント予防でもある。良いCLAUDE.mdは、人間にとってもより良い「このリポジトリの仕組み」ファイルになる。
鋭い刃は責任だ。Claudeがバグを見逃しても、マージしたのはあなたたちだ。Claudeがバグをでっち上げても、それを却下する必要があるのはあなたたちだ。Claudeが自分の出力をレビューしているなら、それでも独立したシグナルが必要だ。テスト、型システム、静的解析、可観測性、そして変更を理解している人間。
Claude Code Reviewは裁判官ではなくゲートとして使う。毎回、面倒な質問をさせる。
- 統合テストはどこにある？
- authはどこで強制されている？
- このPRで
CLAUDE.mdは嘘になっていないか？ - この生成ファイルにコメントする価値はあるか？
- この指摘はコードに裏付けられているのか、それともただの勘か？
適切なPRに対しては、それだけで元が取れる。
同じセットアップをClaude Fable 5 on OneHopで試してみよう。差し替えるだけで使えて、$10分を無料で始められる。
さらに読む: Claude Fable 5を始める.
