Claude Codeチーム活用ガイド: 引き継ぎ・レビュー・権限設計の実践

Claude Codeを個人で使うと、調査、修正、テスト作成が速くなります。けれどもチームで導入すると、便利さと同時に「誰が何を許可したのか」「どの前提でAIが直したのか」「レビュー済みと言ってよいのか」という運用の穴が一気に見えます。

この記事では、Claude Codeをチーム開発に入れるときの実践ルールをまとめます。対象は、2〜10人規模のWeb開発チーム、業務システムの保守チーム、AIレビューをPR前の下読みとして使いたいチームです。

キーワードは、CLAUDE.md、権限境界、引き継ぎ、レビュー受領証、オンボーディングです。専門用語を最初に言い換えると、権限境界は「Claude Codeに読ませる・編集させる・実行させる範囲」、レビュー受領証は「AIの指摘を人間がどう扱ったかを残す短い記録」です。

flowchart LR
  A["担当者の依頼"] --> B["CLAUDE.md / ルール"]
  B --> C["Claude Codeの作業"]
  C --> D["テストと差分確認"]
  D --> E["レビュー受領証"]
  E --> F["人間のPRレビュー"]

まずチームで決める4つの置き場所

Claude Code運用は、よいプロンプトを個人が覚えるだけでは安定しません。チームで再現できる場所にルールを置く必要があります。

置き場所	目的	Git管理
CLAUDE.md	プロジェクト共通の開発規約、禁止事項、テスト手順	する
.claude/settings.json	共有してよい権限、denyルール、hooks	する
.claude/settings.local.json	個人のサンドボックスURLや一時設定	しない
.claude/prompts/*.md	引き継ぎ、レビュー、調査などの定型プロンプト	する

Anthropic公式ドキュメントでも、CLAUDE.mdはチーム共有の指示として使える一方、強制力のある制御はsettingsやhooksで扱う設計です。詳しくはClaude Codeのメモリ、設定、権限、セキュリティを確認してください。

内部の詳細設計は、CLAUDE.mdベストプラクティス、Claude Code hooks実践ガイド、GitHub Actions高度活用もあわせて読むとつながります。

ユースケース1: 作業者からレビュアーへの引き継ぎ

最初のユースケースは、実装者がClaude Codeで下調べや修正を行い、別の人がPRレビューする場面です。失敗しやすいのは、「Claudeが直しました」だけでレビューを渡してしまうことです。レビュアーは、AIが見たファイル、見ていないファイル、承認されたコマンド、未確認の懸念を知る必要があります。

.claude/prompts/handoff.mdとして次を置きます。

# チーム引き継ぎメモを作成してください

あなたは実装担当者の補助者です。現在の差分を読み、次の形式で引き継ぎを書いてください。

## 目的
- この変更で解決したい問題:

## 変更範囲
- 触ったファイル:
- 触っていないが影響しそうなファイル:

## 実行した確認
- 実行したコマンド:
- 成功/失敗:
- 失敗した場合のログ要約:

## レビュアーに見てほしい点
- 仕様判断:
- セキュリティ:
- パフォーマンス:
- テスト不足:

## 次の担当者への依頼
- すぐ確認してほしいこと:
- 後回しでよいこと:

使うときは、差分を作ったあとに次を実行します。

claude -p "git diffを読み、.claude/prompts/handoff.mdの形式でチーム引き継ぎメモを作ってください"

このメモをPR本文に貼るだけで、レビュアーは「どこを疑えばよいか」から入れます。特に複数人が時差で作業するチームでは、Slackの断片的な説明よりもPRに残る引き継ぎのほうが後から追跡できます。

ユースケース2: PRレビューをAIで下読みする

Claude CodeにPRレビューを任せるときの目的は、人間の代替ではなく下読みです。セキュリティ、境界値、不要な差分、テスト漏れを先に拾わせると、人間のレビュー時間を設計判断に寄せられます。

.claude/prompts/pr-review.mdを作ります。

# PR下読みレビュー

以下の観点で差分をレビューしてください。

1. バグになりそうな条件分岐、null/undefined、境界値
2. 認可、入力検証、秘密情報の露出
3. N+1、過剰な再レンダリング、重い同期処理
4. 既存のCLAUDE.mdルール違反
5. テストで足りないケース

出力形式:
- 重大度: high / medium / low
- ファイル:
- 行または関数:
- 理由:
- 修正案:

推測だけの指摘は「要確認」と明記してください。

ローカルでは次のように実行できます。

gh pr diff 123 | claude -p "$(cat .claude/prompts/pr-review.md)"

GitHub Actionsで自動化する場合は、PR作成時に下読みコメントを作るだけに留め、マージ可否は人間が決めます。

name: Claude PR pre-review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  pre-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Install tools
        run: npm install -g @anthropic-ai/claude-code
      - name: Run Claude Code review
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}
        run: |
          gh pr diff "$PR_NUMBER" > /tmp/pr.diff
          claude -p "$(cat .claude/prompts/pr-review.md)

          差分:
          $(cat /tmp/pr.diff)" > /tmp/claude-review.md
          gh pr comment "$PR_NUMBER" --body-file /tmp/claude-review.md

公式のcommon workflowsにもPRやテスト支援の考え方があります。チームでは「AIコメントは参考、承認は人間」という線引きをCLAUDE.mdとPRテンプレートに明記してください。

ユースケース3: 新メンバーのオンボーディング

新メンバーが最初に困るのは、コードの難しさよりも「どのコマンドが正しいのか」「どのディレクトリを見ればよいのか」「壊してはいけない業務ルールは何か」です。Claude Codeには、リポジトリの初回案内を作らせると効果があります。

claude -p "
このリポジトリを新メンバー向けに説明してください。
必ず次を含めてください。
- 主要ディレクトリと責務
- ローカル起動、lint、test、buildのコマンド
- 最初に読むべき3ファイル
- 変更前に確認すべき業務ルール
- よくある失敗と回避策
- 30分でできる練習タスク

不明な点は推測で埋めず、要確認として列挙してください。
"

この出力をそのまま採用せず、ベテランが30分だけ修正します。AIが作ったたたき台に人間の地雷知識を足すと、オンボーディング文書の鮮度を保ちやすくなります。大きな調査はサブエージェント活用パターンのように役割分担すると、調査と要約が混ざりにくくなります。

ユースケース4: 障害調査と夜間引き継ぎ

障害対応では、Claude Codeにログ要約や仮説整理を頼みたくなります。ただし、秘密情報を貼る、未検証の仮説を事実のように共有する、担当交代時に「何を試したか」が消える、という失敗が起きやすいです。

次のチェックリストを.claude/prompts/incident-handoff.mdに入れておくと、夜間や休日の引き継ぎが安定します。

# 障害対応の引き継ぎ

## 現象
- いつから:
- 影響範囲:
- ユーザー影響:

## 観測した事実
- ログ:
- メトリクス:
- 再現手順:

## 試したこと
- コマンド:
- 結果:
- 失敗した仮説:

## まだ危ないこと
- データ破壊の可能性:
- セキュリティ影響:
- ロールバック可否:

## 次の担当者へ
- 最初に見るべき画面/ログ:
- 絶対に実行しないコマンド:

AIに貼るログは、メールアドレス、アクセストークン、顧客IDをマスクしてから使います。Claude Codeのセキュリティ文書にも、権限承認とプロンプトインジェクションへの注意が説明されています。

CLAUDE.mdに入れるべきルール

CLAUDE.mdは、チーム全員が毎回説明し直していることを置く場所です。ただし、長すぎると守られにくくなります。公式ドキュメントは、具体的で短い指示のほうが安定しやすいと説明しています。

# Project instructions for Claude Code

## 作業前
- 変更前に `git status --short` を確認する。
- 既存のユーザー変更を戻さない。
- 不明な仕様は推測で実装せず、PR本文に「要確認」と書く。

## コード規約
- API入力は必ずバリデーションする。
- DB更新処理はトランザクション境界を明示する。
- UI文言は既存の翻訳キーを優先する。

## テスト
- ロジック変更では単体テストを追加する。
- バグ修正では再発防止テストを1つ追加する。
- 実行できなかったテストは理由を残す。

## PR
- PR本文に「変更内容」「確認したこと」「未確認リスク」を書く。
- Claude Codeの提案は、人間が確認したものだけ採用する。

既にAGENTS.mdを使っているリポジトリでは、CLAUDE.mdから取り込めます。

@AGENTS.md

## Claude Code固有ルール
- 課金、認証、削除処理ではplan modeで作業方針を先に出す。
- `git push`、本番デプロイ、マイグレーション実行は人間が行う。

権限境界をsettingsで固定する

チーム導入で一番危ないのは、便利だからといって権限を広げすぎることです。Claude Codeは読み取り専用を基本にし、編集やコマンド実行には承認を求める設計ですが、チームでは共有設定で「許可するもの」「毎回聞くもの」「拒否するもの」を明文化します。

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm test)",
      "Bash(git diff *)",
      "Bash(git status *)",
      "Edit(src/**)",
      "Edit(tests/**)"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(git commit *)",
      "Write(.github/**)"
    ],
    "deny": [
      "Read(.env*)",
      "Read(**/secrets/**)",
      "Bash(git push --force*)",
      "Bash(rm -rf *)",
      "Bash(npm publish*)"
    ]
  }
}

さらにhooksで、編集後にlintを走らせたり、危険なコマンドを止めたりできます。hooksの仕様は公式hooks referenceが詳しいです。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint -- --quiet"
          }
        ]
      }
    ]
  }
}

この例は、npm run lintがあるプロジェクト向けです。重いモノレポでは毎回全体lintを走らせると作業が止まるため、対象ファイルだけ検査するhookに変えます。

レビュー受領証をPRに残す

AIレビューの弱点は、指摘が当たっていたか、誰が採用を決めたかが消えやすいことです。PRテンプレートにレビュー受領証を入れると、AIの提案が監査可能になります。

## Claude Codeレビュー受領証

- 実行したプロンプト:
- Claude Codeが見た差分:
- 採用した指摘:
- 採用しなかった指摘と理由:
- 人間が追加で確認した点:
- 実行したテスト:
- 未確認リスク:

最終判断者:

この欄は、AIを使っていないPRでも「未使用」と書けば十分です。大事なのは、AIを使ったときだけ透明性を下げないことです。

具体的な落とし穴と対策

よくある失敗は、プロンプトの上手さではなく運用の抜けです。

失敗例	何が起きるか	対策
CLAUDE.mdが古い	古いコマンドや廃止APIを使う	月1回、失敗例を見て更新する
権限が広すぎる	秘密情報や本番操作に近づく	denyを先に書き、allowは最小化する
AIレビューだけで承認する	仕様判断や責任者確認が抜ける	PR承認は必ず人間に限定する
口頭で引き継ぐ	翌日、根拠が追えない	引き継ぎメモをPRかIssueに貼る
/clearで履歴を消す	なぜ変更したか分からなくなる	/compact前後に要約を残す
hooksが重すぎる	開発体験が悪化する	ファイル単位、非同期、CI側へ分離する

コミュニケーションの失敗もあります。「いい感じに直して」と頼むと、Claude Codeは完成条件を推測します。「この関数だけ」「DBスキーマは触らない」「テスト失敗ログを先に読む」のように、範囲と禁止事項を短く指定してください。

チーム導入の最小チェックリスト

• CLAUDE.mdに開発コマンド、禁止事項、PRルールを書いた
• .claude/settings.jsonでallow/ask/denyを分けた
• .claude/settings.local.jsonを.gitignoreに入れた
• 引き継ぎ、PRレビュー、障害対応のプロンプトを共有した
• PRテンプレートにレビュー受領証を追加した
• AIコメントを採用する最終責任者を決めた
• 新メンバーが30分で試せる練習タスクを用意した

ClaudeCodeLabでは、こうしたチーム導入テンプレートを継続的に更新しています。AI開発の社内展開やテンプレート整備を早く進めたい場合は、ClaudeCodeLabのプロダクトも参考にしてください。

まとめ

Claude Codeのチーム活用は、魔法のプロンプトを探すことではありません。共有されたCLAUDE.md、狭い権限境界、残る引き継ぎ、監査できるレビュー受領証をそろえることです。

個人の生産性向上だけを狙うなら、便利なプロンプトを覚えるだけでも効果があります。しかしチームでは、同じ結果を別の人が再現できること、失敗したときに原因を追えること、AIの判断と人間の判断を分けて残すことが重要です。

この記事で紹介した内容を実際に試した結果、Masaの検証用リポジトリでは、PR本文に引き継ぎメモとレビュー受領証を入れるだけで、レビュアーが最初に質問する回数が減りました。一方で、全体lintを毎回hookで走らせる設定は重すぎたため、CIに寄せるほうが現実的でした。まずはCLAUDE.md、PR下読みプロンプト、レビュー受領証の3点から始めるのが一番効果を確認しやすいです。