AIが書いた変更をチームで受け止める

Claudeが担当する仕事の数が増えても、レビューする人の数は増えません。ここまでの4回で、設定を揃え、並行作業を混ぜず、GitHubにClaudeを置き、自動レビューとIssueの整理まで任せてきました。仕組みは整いました。最後に残るのは、そこから出てくる変更をチームがどう受け止めるかという規律です。

「このPR、最終的に誰が見たことになっているんだっけ」「レビューする側もされる側も、まだ手探りのままだ」「Claudeをどれくらい使っているのか、誰も数字で把握していない」。仕組みを入れた直後のチームで、よく聞く声です。

今回はレビュー規約、組み込みのレビュー機能、コストの見える化、モデルとeffortの既定という4つを順に固めます。これで「チームで回す」の5回はひとまず完成です。

レビュー規約:誰が持つかを先に決める

規約と言うと大げさに聞こえますが、決めることはそれほど多くありません。

AIが書く変更の数は、人が一行ずつ書いていた頃より簡単に増えます。増えた分だけ全員が同じ基準でレビューできるようにするには、口約束ではなく決めごとにしておく必要があります。

差分そのものの読み方は差分でレビューするの回ですでに扱いました。範囲・削除・副作用の3点を見る、という型です。ここで固めるのは、その読み方を誰が・どの粒度で担当するかという役割分担のほうです。読み方が決まっていても、担当が決まっていなければ結局誰も見ないPRが生まれます。Claudeが書いても、責任の所在は変わりません。

4つ目は見落とされやすい項目です。隠す動機は誰にもないはずなのに、急いでいると省略されがちです。コミットメッセージの末尾に「Claude Codeで実装、テストは手動確認」のような一言を添えるだけで十分で、レビューする側も何を重点的に見ればいいかが分かりやすくなります。

組み込みのレビュー機能を使い分ける

前回、GitHub上での自動レビューを設定しました。ここで並べるのは、それとは別に、メンバー個人がその場で使える機能です。

コードの中身そのものをレビューするコマンドは/code-reviewです。/reviewはそのエイリアスで、--fixで修正まで自動適用させたり、--commentでPRやMRにインラインコメントを残したりできます。/security-reviewは名前が似ていますが別物で、脆弱性の観点に絞った単発パスです。どちらもメンバーが自分のセッションでその場で打つコマンドで、GitHub側の設定を待つ必要はありません。二つを混同すると「セキュリティは見たがロジックは見ていない」という抜けが起きるので、規約に両方の使いどころを書いておくと安心です。

PR上のCode Review製品は、ZDR(Zero Data Retention)を有効にした組織では使えません。また1回あたり数十ドルかかることがあり(2026年9月時点、金額は下のResourceCardから公式ドキュメントで確認できます)、プランに含まれる利用枠ではなく使用量クレジット側で別に課金されます。頻度をどう設定するか(PR作成時のみ・毎プッシュ・手動)は前回の範囲なので、ここではコストの性質だけ押さえておきます。

コストを見える化する

コストの比較の軸そのものはコスト規律の回で扱いました。ここではClaude Code固有の見る場所を並べます。

Pro・Maxのサブスクリプションで使っているメンバーにとって、/costが出すドル表示は請求に直結しません。利用量はサブスクリプションに含まれているためで、ここで慌てる必要はありません。API経由で使っているメンバーとサブスクリプションのメンバーが混在するチームでは、この違いを先に共有しておくと無用な不安を防げます。

分析画面の貢献度指標は、GitHub連携が必要な公開ベータで、ZDRを有効にした組織では使えません。OpenTelemetryの具体的な設定は情シス部門が担う内容なので、詳しくはClaude Codeを組織に入れるのコースで扱います。

モデルとeffortの既定をチームで決める

modelキーはどのスコープのsettings.jsonにも書けるので、設定をリポジトリで揃えるの回で見た共有ファイルにそのまま追記できます。書き換える担当は、その回で決めた更新担当と揃えておくと、変更のたびに揉めずに済みます。effortの水準ごとの向き不向きや選び方は考えさせてから作らせるの回で扱ったとおりです。ここでは、その選び方を個人の判断に任せきりにせず、既定を1つ決めておくという話になります。既定を上限として組織全体で強制したい場合は、管理者が決める設定の回で扱います。

よくある誤解と罠

• 規約を作った時点で満足し、実際にPRの説明を見て回らない。仕組みは、誰かが最初の数週間だけでも見て回らないと定着しません
• セキュリティのレビューだけ済ませて、ロジックのレビューをしたつもりになる。/security-reviewと/code-reviewは別物です
• コストの数字を見て、サブスクリプションのメンバーまで一律に節約を求めてしまう。まず自分のチームの契約形態を確認します

今日のまとめ

• レビュー規約は、承認者・小さく出す・テスト・AI明記の4点で足ります
• 組み込みのレビュー機能は5層あり、/code-reviewと/security-reviewは別物として使い分けます
• コストは/costと2種類の分析画面で見える化でき、モデルとeffortの既定は共有settings.jsonで揃えられます

これで「Claude Codeをチームで回す」の5回は完了です。組織全体に広げる段階に進むなら、次はClaude Codeを組織に入れるのコースに進んでください。