JustFit
ブログ
Claude Codeのレビューが一般提供、深さを選べる

Claude Codeのレビューが一般提供、深さを選べる

2026.10.18 JustFit編集部（運営：株式会社LEGAREA）

この記事では、Anthropicが2026年10月15日にClaude Codeの「Code Review」を一般提供にした内容を、公式の情報で確認できた範囲で整理します。あわせて、AIでコードを書く量が増えたときに、新規事業のシステム開発で「確認の仕事」がどう変わるかを、JustFit編集部の見方として書きます。

10月15日に一般提供になった「Code Review」とは

Anthropicは10月15日、Claude Codeの「Code Review」をリサーチプレビューから正式な提供に移しました。対象はTeamプランとEnterpriseプランです。

Code Reviewは、プルリクエスト（PR）に対して動くレビュー機能です。PRとは、書いたコードの変更を本体に取り込む前に、他の人へ確認を頼む仕組みのことです。研究プレビュー時の公式ページでは、すべてのPRに複数のエージェントをチームとして走らせ、さっと目を通しただけでは見逃すバグを拾う機能と紹介されていました。Anthropic社内でも、ほぼすべてのPRで使っている仕組みだそうです。

背景として、一般提供の発表ではこう説明されています。コーディングエージェントのおかげでコードを書く速さは上がり続けているのに、レビューが詰まる問題は解消していないという認識です。プレビュー時のページにも、レビューがボトルネックになっており、多くのPRが深く読まれずに流し見されているという趣旨の記述があります。

公式で確認できた変更点：速さ・指摘の書き方・深さ

一般提供での変更は、公式の発表では3点です。

速さ：ほとんどのレビューが、プレビュー時の約20分から6〜10分に、約3倍速くなったとされています。
指摘の質：重要なバグをより多く見つけるようにし、指摘は「問題」「それが起きる条件」「直し方」を数文で書く形になりました。
柔軟性：管理者がリポジトリごとにQuick、Standard（既定）、Deepを選べます。日常的なコードには軽い確認、重要なものには深い確認を割り当てる使い方が想定されています。

Anthropicは、プレビューの利用者から「もっと静かで、変更の大きさに合った、速いレビューにしてほしい」という要望があったと説明しています。今回の変更は、その声に沿ったものと読めます。

使える条件と、動き方

公式ドキュメントとあわせて、使うための条件を整理します。

プランと設定：管理者がClaude Codeの設定でCode Reviewを有効にし、GitHub Appを入れて、対象のリポジトリを選びます。有効にしたあとは、新しいPRに自動でレビューが走り、開発者側の設定は要りません。
対象：ドキュメント上は、TeamまたはEnterpriseプランで、GitHubのリポジトリを使っている組織が、Ownerが有効にしたあとに使えます。
3つのレベル：Quickは軽い確認で、いちばん速く、費用も最も低いレベルです。Deepはいちばん丁寧な確認で、時間も費用も最もかかります。
使えない組織：Zero Data Retentionを有効にしている組織や、HIPAA構成を適用している組織では使えません。

また、ドキュメントの内容を紹介した記事（dev.to）には、レビューはAnthropic側のインフラで読み取り専用で動き、コードのビルドや実行はしない、レビューはPRを承認も阻止もしないという趣旨の記載が引用されています。つまり、最後にマージするかどうかを決めるのは人です。これは公式ドキュメントの原文ではなく紹介記事の引用なので、導入を考えるときは公式ドキュメントで確認するのが確実です。

編集部の見方：コードが増えるほど、確認の設計が必要になる

ここからは事実ではなく、JustFit編集部の見方です。

書く速さが上がると、詰まる場所が移る

AIでコードを書くと、動くものが短期間で形になります。新規事業にとっては大きな利点です。いっぽうで、Anthropic自身が「レビューが詰まる」と書いているように、書く量が増えるほど、確かめる側に負荷が移ります。AI駆動開発の進め方と役割分担は、AI駆動開発とは｜AIと人の役割分担と発注側の要点でも整理しています。今回のニュースは、レビュー自体をAIに任せる選択肢が、製品として一般提供になった出来事だと私たちは見ています。

「動いた」と「安全」は別の確認になる

AIがコードを書き、AIが見る形になっても、確認の目的は分けて考える必要があります。直近のLSCBench公開の記事では、動くコードと安全なコードの両立を測る試験を取り上げました。レビューAIがバグを拾うことと、事業が扱うデータに見合った安全性を確かめることは、同じ作業ではありません。安全面の確認点はAI生成コードのセキュリティ｜確認点と人の役割にまとめています。

深さを選べることは、事業の中の「重さの違い」を言葉にする機会になる

QuickとDeepをリポジトリごとに選べるということは、システムのどこが重く、どこが軽いかを先に決めておく必要がある、ということでもあります。たとえば決済や個人情報を扱う部分と、画面の文言を直すだけの部分では、確認にかける時間が違って当然です。新規事業の初期は、全部を重く確認するより、小さく作って確かめる進め方のほうが合う場面も多いはずです。考え方は新規事業の開発は小さく作って確かめる投資判断の進め方で書いています。

レビューが基準にするのは、決まっている要件まで

自動レビューは、コードの差分と、PRに書かれた目的をもとに確認します。つまり、「そもそも何を作るのか」が曖昧なままでは、確認の基準も曖昧になります。要件を言葉にしておく工程は、AIが書く時代にも残ります。この点は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方とAI要件定義で変わること｜AIが整理し人が決める範囲で整理しています。

人の確認は、減らすのではなく置き場所が変わる

レビューAIがPRの承認も阻止もしないとされている点は、「最終判断は人」という考え方と重なります。人が見るのは全行ではなく、変更の意図や事業上のリスクになっていくのでしょう。ただし、どこまで人が見るかは、システムの性質で変わります。AI開発でも品質には人の確認が必要な理由も参考になります。

数字を読むときに、立ち止まりたい点

今回の発表を読むときに、私たちが気をつけたい点は3つあります。

「3倍速」の比較相手：公式の数字は、プレビュー期間との比較です。人によるレビューと比べた数字ではありません。
指摘の精度：公式の発表は「重要なバグをより多く見つける」と書いていますが、今回確認できた範囲では、検出率などの具体的な数字は見当たりませんでした。
Anthropic自身の報告：同じ日にAnthropicのClaude Codeチームが、自分たちのレビューのやり方を公開したと報じられています。報道によれば、6月から9月にかけて、マージされたPRは2倍超になり、取り消しが必要になった割合は40%超減ったとのことです。これは同社の自社リポジトリでの結果です。扱うコードも体制も違う他の組織に、そのまま当てはまるとは限りません。

また、他社のコーディングツールにある類似のレビュー機能との比較は、今回は確認していないので書いていません。ツールの特徴を並べて見たいときは、AIコーディングツール比較｜特徴と向く使い方｜2026年10月も参考になります。

まとめ

Claude CodeのCode Reviewは、10月15日にTeamとEnterprise向けの一般提供になりました。公式の発表では、レビュー時間がプレビュー時の約20分から6〜10分になり、リポジトリごとにQuick・Standard・Deepを選べます。

新規事業の開発にとっての論点は、AIが書く量が増えるほど「確認をどう設計するか」が大事になる、という点だと私たちは見ています。レビューAIは確認の手間を減らす助けになりますが、何を作るかを決めることと、事業のリスクに見合った品質の最終判断は、人の仕事として残ります。

JustFitは、AIを活用した独自の開発基盤「LAF」を使っています。LAFでは、要件定義・設計・DB設計・実装・テスト・レビューを担う複数の専門AIがチームとして開発を進め、人の役割は「何を作るかを決めること」と「品質の最終判断」です。構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから判断できる進め方もご用意しています。新規事業のシステム化を検討する段階であれば、JustFitのサービス紹介をご覧ください。

参考にした情報

← ブログ一覧へ