Claude Code Review が一般提供開始 — REVIEW.md のルールはマージ後にのみ適用され、残りはブランチ保護が決定 (2026)

一般提供のアナウンスでは、3つの変更点が説明されています。レビューはプレビュー期間中よりも高速になりました。指摘事項は、問題、その原因、および修正方法を簡潔に述べるように短く書かれています。そして、管理者はリポジトリごとにレビューレベルを選択できるようになりました。「管理者はリポジトリごとに Quick、Standard（デフォルト）、または Deep を選択できるため、日常的なコードベースは素早くチェックし、最も重要なコードベースは深くレビューすることができます。」

製品の構成は同じです。複数のエージェントが各変更を読み込み、検証ステップが指摘事項をフィルタリングし、結果はインラインコメントと Claude Code Review という名前のチェックランとして届きます。何よりもまず、2つの特性が重要です。

• マージやブロックは行いません。 ドキュメントには「レビューがプルリクエストを承認またはブロックすることはないため、マージの決定はチームに委ねられます」とあります。
• 読み込みは行いますが、実行はしません。 レビューは「コードをビルドまたは実行することなく、差分と周囲のコードを読み取ることで機能します」。レビュー内では「リポジトリへのアクセスは読み取り専用であり、レビューによってコミットがプッシュされることはありません」。

したがって、レビューアの判断は、指示ファイルを含め、読み取った内容に依存します。

Code Review は、リポジトリ内の2種類のファイルからガイダンスを取得します。

CLAUDE.md は、Claude Code がすでに使用しているプロジェクト指示ファイルです。Anthropic はこれを「Claude Code がレビューを含むすべてのタスクで読み込むプロジェクト指示。Code Review はこれらをプロジェクトのコンテキストとして読み込み、違反する変更にフラグを立てます」と説明しています。レビューはリポジトリ内のすべての CLAUDE.md を読み込むわけではありません。「レビューは、リポジトリのルートにある CLAUDE.md と、変更された各ファイルの親ディレクトリにある CLAUDE.md ファイルを読み込みます。サブディレクトリの CLAUDE.md は、プルリクエストがそのパス配下のファイルを変更したときに読み込まれます。」

REVIEW.md は Code Review 専用のファイルです。これは「レビュー専用の指示です。チームが何をフラグ立てしたいか、どの重要度にするか、何をスキップするかを指定するために使用します」とされています。リポジトリのルートに1つ配置し、サブディレクトリにさらに追加して、それらのパス配下の変更に対するチェックを追加できます。その内容はレビューのすべての段階に届きます。「問題を検出するエージェントとそれを検証するエージェントは、Code Review のデフォルトのレビューガイダンスとともに、リポジトリのレビュー指示としてその内容を受け取ります。最終的なレビューを書き出すステップは、重要度を決定しサマリーを書き出す前に、このファイルを参照します。」

Anthropic が推奨する切り分けはシンプルです。「REVIEW.md はレビューの動作を変更する指示に留め、一般的なプロジェクトのコンテキストは CLAUDE.md に残してください。」 デフォルトでは、Code Review はフォーマットやテストカバレッジではなく、本番環境を壊すようなバグ、つまり正確性に焦点を当てています。REVIEW.md は、リポジトリのその境界線を移動させる方法です。何が「重要（Important）」とされるかを再定義し、細かい指摘（nits）を制限し、スキップするパスをリストアップし、チームが重視するチェックを追加し、あるいは特定の種類の指摘に対して証拠としてファイルと行を要求したりします。

Claude Code チームがどのようにコードレビューを行っているかに関する投稿で、Anthropic は次のように書いています。「CLAUDE.md は、スタック、規約、目標、非目標など、プロジェクトが何であるかを Claude に伝えます。すべてのレビューでこれがロードされるため、大規模なコードベースでは短く保ち、そこから他のドキュメントを指すようにしています。」 そして、「コードオーナーによって書かれた REVIEW.md は、コードのその部分で何が重要かをレビューアに伝えます。レビューアが実際にそれに従っているかどうかは、別途チェックしています。」

Anthropic は、ファイルが必ず遵守されるとは仮定していません。以下のルールは、作成したルールが適用されない可能性がある理由を説明しています。

ドキュメントは明確です。「Code Review は、プルリクエストのベースブランチまたはデフォルトブランチから REVIEW.md を読み込み、プルリクエスト自体の変更からは決して読み込みません。レビューの動作を変更するには、まず REVIEW.md の変更をマージしてください。」

実際、これは自然なワークフローでよく引っかかります。開発者が、レビューアが自動生成されたファイルにフラグを立てていることに気づき、コメントをトリガーしたのと同じプルリクエスト内の REVIEW.md にスキップルールを追加してプッシュします。次のレビューは、ベースブランチまたはデフォルトブランチにある REVIEW.md のコピーに対して実行されますが、そこにはまだ新しいルールがありません。変更がマージされるまで、コメントは届き続けます。

同様に、最初に REVIEW.md を導入するプルリクエスト自体は、それなしでレビューされます。

ドキュメントは理由を説明せずにこのルールを述べています。その効果として、プルリクエスト自体による REVIEW.md の編集によって、指摘事項の重要度を下げたり、変更したファイルを除外したりすることはできません。その決定は、レビューが読み込むブランチへのマージを制御する人に委ねられます。

実用的な結論：REVIEW.md の変更は、それ自体を小さなプルリクエストとして扱い、影響を与えたい作業の前にマージしてください。

REVIEW.md をマージすれば終わりではありません。Code Review は、読み込み元のブランチが保護されているかどうかをチェックし、その結果によって読み込む内容と尊重する内容が変わります。

Anthropic のガイダンスは「REVIEW.md をデフォルトブランチに置き、そのブランチを保護する」というものです。保護されたデフォルトブランチ上のコピーをレビューが読み込む場合、ルートファイルからの3種類の指示を尊重します。

• 指摘事項の重要度を下げる
• パス、ファイル、または問題のクラスを除外する
• 細かい指摘（nit）コメントを制限する

これらは、ドキュメントがそもそも記述することを推奨している5種類の指示のうちの3つです。ロックファイルを無視し、細かい指摘を最小限に抑えるように指示する REVIEW.md が効果を発揮するかどうかは、ブランチ保護に依存します。

ドキュメントでは、4つの状況が提示されています。

2つの行に注目する必要があります。3番目の行では、サブディレクトリの REVIEW.md ファイルがまったく読み込まれないため、ディレクトリごとのチェックが機能しなくなります。4番目の行では、REVIEW.md が一切読み込まれません。ドキュメントには、このケースには「クラシックルールのみを持つベースブランチを持つ、保護されていないデフォルトブランチが含まれる」と記されています。

何をもって保護とするかも具体的です。デフォルトブランチの場合、Code Review は「クラシックなブランチ保護ルールまたはルールセット」を受け入れます。その他のブランチについては、「ルールセットのみ」です。そして、すべてのルールセットが対象となるわけではありません。「ルールセットは、更新を制限するか、少なくとも1つの承認を伴うプルリクエストを要求する場合にカウントされます。プルリクエストを要求する場合、新しいプッシュでその承認を却下するか、最後のプッシュの後に承認を行うことを要求する必要があります。」

チェックランは、これがいつ発生しているかを教えてくれます。あるメッセージには「このレビューは、直接プッシュに対して保護されていないデフォルトブランチから、リポジトリのレビュー指示（REVIEW.md）を適用しました」と表示されます。これは、ルートファイルのみが読み込まれたことを意味します。別のメッセージでは、指示が「このレビューには適用されませんでした：ブランチ保護を確認できませんでした」と表示され、何も適用されなかったことを意味します。

Code Review には、自身のセッションで実行される兄弟機能があります。ドキュメントではその違いを直接指摘しています。「Code Review サービスとローカルの /code-review コマンドは2つの別個のツールであり、異なるファイルを読み込みます。」

サービスは CLAUDE.md と REVIEW.md の両方を読み込みます。ローカルコマンドは、非インタラクティブな -p 実行を含め、CLAUDE.md に従います。「REVIEW.md は読み込みません。」

これは、ルールの書き方に影響を与えます。REVIEW.md にのみ存在するチェックは、プルリクエストのレビューには表示されますが、開発者がプルリクエストを開く前にローカルで /code-review を実行したときには表示されません。Anthropic のアドバイスは次の通りです。「両方の場所に適用したいガイダンスは CLAUDE.md に記述し、REVIEW.md はプルリクエストレビューに特化したルール用として残してください。」

プッシュする前にローカルでレビューする開発者は、重複しつつも異なる指示に基づいて動作する2つのレビューアを目にすることになります。

新しい REVIEW.md がプッシュされるとすぐに機能すると仮定すること。 これは、Code Review が読み込むブランチにマージされて初めて機能し、そのブランチが保護されている場合にのみ完全に機能します。エージェントが指示ファイルを無視する理由に関するガイドでは、コーディングセッションにおける同様のギャップについて説明しています。

返信によってレビューアが学習すると仮定すること。 指摘事項への返信は、そのプルリクエストの次のレビューとの会話であり、永続的なルールではありません。「返信するだけでは指摘は却下されません。」 次のレビューは「以前の指摘に対する返信を読み取り、スレッドを解決するか、1つの追跡返信を投稿することができます。」 指摘が繰り返される場合のドキュメントのアドバイスは、「メンテナーに REVIEW.md へのルールの追加を依頼する」ことです。

CLAUDE.md はコーディングセッション専用であると仮定すること。 Code Review はこれをプロジェクトのコンテキストとして読み込み、違反にフラグを立てます。Anthropic のチームは、自社のレビューアも「その中の規約に違反するコードや、その中の行を古くしてしまう変更にフラグを立てる」と述べています。レビューアが CLAUDE.md を読み込むようになると、セッションだけでなくレビューにとっても、それを最新に保つことが重要になります。競合する CLAUDE.md レイヤーの調整に関するガイドでは、これらを見つけて修正する方法を説明しています。

ステップ 1：デフォルトブランチを保護し、どのコピーが読み込まれるかを確認する

上記の表に照らし合わせて、ブランチ保護を確認してください。デフォルトブランチにクラシックルールまたはルールセットを設定します。プルリクエストが他の長期運用ブランチをターゲットにしている場合、それらのブランチの REVIEW.md コピーを有効にするには、それらのブランチにルールセットが必要です。

その後、小さなテスト用のプルリクエストを開き、チェックランを確認します。指示が保護されていないブランチから取得された、または適用されなかったと表示されている場合は、まずそれを修正します。

ステップ 2：CLAUDE.md と REVIEW.md の間でルールを分割する

適用したいルールを確認し、次のように分類します。

• プロジェクト自体に関するルールは CLAUDE.md に記述します：規約、アーキテクチャの境界、変更が向かうべきではない非目標など。これらは、コーディングセッション、ローカルレビュー、およびプルリクエストレビューに適用されます。
• レビューに関するルールは REVIEW.md に記述します：このリポジトリで何が「重要（Important）」とされるか、投稿する細かい指摘（nits）の数、スキップするパス、常に実行するチェックなど。
• コードの特定の領域に関するルールは、サブディレクトリの CLAUDE.md または REVIEW.md に記述します。サブディレクトリの REVIEW.md ファイルはブランチ保護に依存します。

REVIEW.md の変更を単独でマージします。初めて CLAUDE.md ルールを作成する場合は、Claude にコーディングスタイルを遵守させる方法に関するガイドで、規約が遵守されるように表現する方法を説明しています。

ステップ 3：繰り返される指摘をマージされたルールに変換し、その理由を記録する

Anthropic 自身のプロセスがここでのモデルになります。「自動レビューアが同じことを指摘し続ける場合、私たちはソースでそれを修正します」とチームは書いています。彼らが推奨するロールアウト方法は、1つのリポジトリに AI レビューアを追加し、「数週間 REVIEW.md を調整してから、範囲を広げる」というものです。そして、レビューが何かを見落とした場合、「モデルの前に何が足りなかったのかを問いかけ、CLAUDE.md、スキル、または新しいチェックに修正を組み込みます。」

これらの修正のそれぞれが意思決定です。なぜ特定のパスが除外されたのか、なぜある指摘クラスがここでは「重要（Important）」で他では「細かい指摘（Nit）」なのか、どのインシデントがチェックにつながったのか。ルールはファイルに記述されます。その理由も残しておく価値があります。次に REVIEW.md を編集する人が、そのルールがまだ適用されるかどうかを知るために必要だからです。Claude Code が修正を忘れる問題に関するガイドでは、コーディングセッションにおける同様のパターンをカバーしています。最も重要な修正は、チーム全体が読めるファイルに属しています。

REVIEW.md はルールを保持します。インシデント、議論、却下した代替案など、その背景にある履歴は、その議論が行われた場所（プルリクエストのスレッド、チャット、個人の記憶など）に残ります。MemoryLake は、そのような意思決定の記録を維持管理する1つのリストに保存し、Claude Code や、レビューが後に読み込むコードを書く際に接続する他のアシスタントから利用できるようにするメモリレイヤーです。

エントリーはご自身で、ご自身の言葉で記述します。リポジトリの CLAUDE.md や REVIEW.md ファイル、プルリクエスト、Code Review の指摘事項、またはベンダーのストレージから何かが読み取られたり、書き込まれたり、削除されたりすることはありません。Code Review サービスはリポジトリ内にあるものだけを読み込むため、適用されるルールは引き続きそれらのファイルに属します。リポジトリの外部にプロジェクトの詳細を保存する前に、組織のポリシーを確認してください。

ステップ 1：API キーを作成する

サインインし、ダッシュボードからキーを生成します。このキーは MemoryLake ワークスペースに属し、Anthropic や GitHub のアカウントとは異なります。

ステップ 2：最初のメモリをアップロードする

レビュールールの背景にある理由から始めましょう。なぜパスがスキップされるのか、なぜ指摘クラスがこのリポジトリで「重要（Important）」なのか、どのインシデントがチェックにつながったのか。1つのエントリーに1つの決定を、日付とそれが説明するルールへのポインタとともに入力します。

ステップ 3：AI とエージェントを接続する

Claude Code や、使用しているその他のアシスタントを接続します。これにより、プルリクエストがレビューアに届く前の、コードが書かれている段階で、ルールの背景にある推論を利用できるようになります。

最初の変化は、チェックランでの予期せぬ事態が減ることです。ブランチ保護が確認されると、記述した除外設定や細かい指摘の制限が有効になります。2つ目は一貫性です。どこにでも適用すべきルールは CLAUDE.md に配置されるため、ローカルの /code-review とプルリクエストレビューで同じことが期待されます。3つ目は、意図的に改善されるセットアップであり、繰り返される指摘が、理由が記録されたルールに変換されます。コーディングエージェントが実際に読み込むものに関する考察では、なぜそのような文書化されたコンテキストがツール間で重要なのかを説明しています。

REVIEW.md の変更は単独でマージする。 プルリクエストはベースブランチのコピーを使用してレビューされます。

デフォルトブランチを保護する。 重要度の変更、除外設定、細かい指摘の制限はこれに依存します。

チェックランのメッセージを読む。 ルートファイルのみが読み込まれたか、あるいは何も読み込まれなかったかが表示されます。

共有ルールは CLAUDE.md に記述する。 ローカルコマンドは REVIEW.md を読み込みません。

両方のファイルを短く保つ。 レビューファイルに対する Anthropic 自身の見解：「優れたものは短い」

Code Review の一般提供により、すべてのプルリクエストに対する AI レビューが、Team および Enterprise 組織のデフォルトの選択肢になります。何に基づいてレビューするかは、引き続きチーム次第です。REVIEW.md はベースブランチまたはデフォルトブランチから読み込まれ、プルリクエスト自体の変更からは決して読み込まれません。サブディレクトリのファイルがカウントされるか、また重要度の変更、除外設定、細かい指摘の制限が尊重されるかは、ブランチ保護によって決まります。保護を確認できない場合、REVIEW.md は読み込まれません。ブランチを保護し、プロジェクトルールとレビュールールを分割し、繰り返される指摘を理由が記録されたマージ済みのルールに変換しましょう。