Claude Codeをチームで使うと属人化する。共有すべき4つの置き場所と運用ルール

「Claude Code、めちゃくちゃ便利ですよ」とチームの一人が言い出して、半月後。気づいたら、その人のPRだけ妙にきれいで速くて、レビューもサクサク通る。残りのメンバーは相変わらず手で書いている。

これ、いいことに見えて、実は危ない兆候です。

僕が前に関わった4人のチームがまさにそうでした。一人がClaude Codeを使いこなして生産性を倍にした。でも、その人が一週間休んだ瞬間、チームの速度が元に戻った。どんなプロンプトを投げていたのか、どのコマンドを許可していたのか、何を禁止していたのか——全部その人の頭の中にしかなかったんです。

個人で使うClaude Codeと、チームで使うClaude Codeは、別物です。個人なら「便利なプロンプトを覚える」で十分。でもチームでは、そのノウハウを全員が同じように再現できる状態を作らないと、ただ一人だけ速い人が生まれて終わります。今日はその「再現できる状態」の作り方を、置き場所と運用ルールに分けて書きます。

この記事の要点

• Claude Codeのチーム導入で最初に壊れるのは「コードの難しさ」ではなく「個人技がバラけること（属人化）」。
• 共有すべきは4つ。CLAUDE.md（規約）、.claude/settings.json（権限）、.claude/commands/（定型コマンド）、.claude/rules/（部分的なルール）。全部Gitに乗せる。
• CLAUDE.md はAIへの「お願い」であって強制力はない。本当に止めたい操作は settings の権限や hooks で固める。
• 新メンバーの立ち上げは、Claude Codeにリポジトリ案内のたたき台を作らせ、ベテランが30分だけ直すのが速い。
• 引き継ぎの具体ルールは別記事に分けた。あわせて Claude Codeチーム引き継ぎルール を読むと運用がつながる。

チームで共有すべき4つの置き場所

属人化を防ぐ第一歩は、ノウハウを「人の頭」から「リポジトリの中」へ移すことです。Claude Codeには、まさにそのための置き場所が用意されています。下の4つをGitに乗せて、全員が同じ設定で起動できるようにします。

置き場所	何を入れるか	Gitに乗せる
CLAUDE.md	プロジェクト共通の規約・禁止事項・テスト手順	乗せる
.claude/settings.json	共有してよい権限、deny（禁止）ルール、hooks	乗せる
.claude/commands/*.md	レビューや調査などの定型コマンド	乗せる
.claude/rules/*.md	特定のフォルダ・ファイルだけに効くルール	乗せる

逆に、個人のサンドボックスURLや一時的な試行設定は .claude/settings.local.json に書き、.gitignore に入れます。ここが混ざると「人によって挙動が違う」という、一番デバッグしづらい状況になります。

公式ドキュメントでも、プロジェクトの CLAUDE.md と .claude/settings.json はソース管理でチームに共有する設計だと明記されています。詳しくは Claude Codeのメモリ機能 と 設定 を見てください。社内の細かい書き方は CLAUDE.mdの粒度と更新の原則 と Claude Code hooks実践ガイド に分けて書いています。

CLAUDE.mdは規約を共有する場所、ただし「お願い」止まり

CLAUDE.md は、チーム全員が毎回口頭で説明し直していることを書き留める場所です。コーディング規約、禁止事項、テストの回し方。ここを揃えるだけで、誰がClaude Codeを動かしても出力の方向が揃ってきます。

ただし、ひとつ大事な勘違いを先に潰しておきます。CLAUDE.md はAIへの「お願い」であって、強制力はありません。公式ドキュメントもはっきり「context（文脈）であって enforced configuration（強制設定）ではない」と書いています。つまり「migrations は触るな」と書いても、AIが無視する可能性は残る。本当に止めたい操作は、後で出てくる settings の権限や hooks で固めます。

もうひとつのコツは、長く書かないこと。公式は「200行以内を目安に」と言っています。長いほど守られにくくなる。僕も昔、技術スタックもデプロイ手順も全部詰め込んで200行を超えた結果、真ん中あたりの禁止事項を平気で無視されました。短く、具体的に。これが鉄則です。

チーム向けの最小例はこのくらいで十分です。

# Project instructions for Claude Code

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

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

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

すでに AGENTS.md を使っているリポジトリなら、CLAUDE.md から取り込めます。二重管理にならずに済みます。

@AGENTS.md

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

プロジェクト全体ではなく「src/api/ の下だけ」に効かせたいルールは、.claude/rules/ に分けると CLAUDE.md が太りません。該当ファイルを触ったときだけ読み込まれるので、普段は文脈を圧迫しないのが利点です。

権限境界をsettingsで固定し、属人化と事故を同時に防ぐ

チーム導入で一番危ないのは、「便利だから」と各自が勝手に権限を広げることです。Aさんは rm -rf を許可していて、Bさんは毎回確認している。これだと挙動が人によってバラけるうえ、誰かが本番を壊すのも時間の問題です。

そこで .claude/settings.json に「許可するもの（allow）」「毎回聞くもの（ask）」「絶対に拒否するもの（deny）」を書いて、全員で共有します。コツは、deny を先に書いてから allow を最小限に足すこと。広げるより狭めるほうが安全です。

{
  "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*)"
    ]
  }
}

設定の優先順位は、managed（組織）> コマンドライン > local（個人）> project（チーム）> user の順です。だから settings.json（project）にチーム標準を書き、個人の例外だけ settings.local.json に逃がす運用がきれいにハマります。

さらに hooks を足すと、CLAUDE.md の「お願い」では止められない操作を機械的に止められます。たとえば編集後に自動で lint を走らせる、危ないコマンドを実行前にブロックする、といった具合です。

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

ひとつ注意。重いモノレポでこれを毎回「全体 lint」にすると、編集のたびに数十秒待たされて全員がストレスを溜めます。僕はこれをやって総スカンを食いました。対象ファイルだけ検査するか、重い検査はCI側に寄せるのが現実的です。

カスタムコマンドで「上手いプロンプト」を全員のものにする

属人化の正体は、結局「いいプロンプトが個人の頭の中にしかない」ことです。これを解く一番効く手が、**カスタムコマンド（.claude/commands/）**です。よく使うプロンプトをファイルにしてGitに乗せれば、チーム全員が /コマンド名 で同じ品質の指示を呼び出せます。

たとえば PR の下読みレビュー。.claude/commands/pr-review.md を作ります。

---
description: PR差分を下読みレビューする
---

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

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

出力は「重大度（high/medium/low）/ ファイル / 行か関数 / 理由 / 修正案」の形で。
推測だけの指摘は「要確認」と明記してください。

これで誰でもセッション内から /pr-review を呼べます。「あの人のレビューだけ鋭い」がなくなり、レビューの最低ラインがチーム全体で揃う。属人化対策として、僕はこれが一番費用対効果が高いと思っています。

CLIから直接パイプで渡しても同じことが起きます。ローカルでサッと試すならこちら。

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

大事なのは線引きです。AIのレビューはあくまで下読みで、マージ可否は人間が決める。この一文を CLAUDE.md とPRテンプレートに書いておきます。下読みの考え方は公式の common workflows も参考になります。役割を分けた大きめの調査は サブエージェント活用パターン のように分担させると混ざりません。

新メンバーの立ち上げを30分で終わらせる

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

下のコマンドを、コピペでそのまま使えます。リポジトリのルートで実行してください。

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

不明な点は推測で埋めず『要確認』として列挙すること。
"

ポイントは、この出力をそのまま採用しないこと。AIが作るのは8割埋まったたたき台です。残りの2割——「この設定ファイルだけは触るな」みたいな地雷知識——はベテランが30分だけ足す。ゼロから手書きするより圧倒的に速いし、たたき台があるとベテランも「何を足すか」に集中できます。

このオンボーディング文書も .claude/commands/onboarding.md にしておけば、次の新人が来たときに /onboarding で即再生成できます。属人化を防ぐコツは、結局「一度やった作業を必ずリポジトリに残す」の繰り返しです。

チーム導入でやりがちな失敗と対策

僕や周りが踏んだ落とし穴を、表にまとめておきます。どれも「プロンプトの上手さ」ではなく「運用の抜け」で起きます。

失敗	何が起きるか	対策
ノウハウが個人の頭の中	キーパーソンが休むと速度が戻る	プロンプトをコマンド化してGitに乗せる
CLAUDE.md が古い	廃止したコマンドやAPIを使う	月1回、失敗例を見て更新する
権限が人によってバラバラ	挙動が再現せず事故も起きる	settings をGitで共有し deny 優先
AIレビューだけで承認	仕様判断や責任者確認が抜ける	マージ可否は必ず人間に限定
hooks が重すぎる	編集のたびに全員が待たされる	対象ファイルだけ／CI側へ分離
口頭で引き継ぐ	翌日、根拠が追えない	引き継ぎは別記事のルールに従う

最後の「引き継ぎ」は、それだけで1記事ぶんの分量があるので分けました。レビュー受領証、ロールバック、夜間の障害対応まで含めた具体手順は Claude Codeチーム引き継ぎルール にまとめてあります。

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

よくある質問

Q. CLAUDE.md と settings.json は何が違うんですか？ A. CLAUDE.md はAIへの「お願い」（守るかはAI次第）、settings.json の権限や hooks は「強制ルール」（クライアントが必ず効かせる）です。規約や方針は CLAUDE.md、絶対に止めたい操作は settings、と使い分けます。

Q. 個人の設定とチームの設定が混ざって挙動がバラつきます。 A. チーム共有は .claude/settings.json（Gitに乗せる）、個人の例外は .claude/settings.local.json（.gitignore に入れる）に分けてください。優先順位は local がチーム設定を上書きするので、個人の試行はlocal側に置けば全体を壊しません。

Q. CLAUDE.md が長くなってきました。分割すべき？ A. 200行を超えたら危険信号です。特定のフォルダだけに効くルールは .claude/rules/ に出すと、該当ファイルを触ったときだけ読み込まれ、普段の文脈を圧迫しません。

Q. AIにPRレビューを任せたら、人間のレビューは要らない？ A. いりません、にしないでください。AIレビューは下読みで、境界値やテスト漏れを先に拾う役です。仕様判断とマージ承認は人間に残す。この線引きを CLAUDE.md とPRテンプレートに明記しておくのが安全です。

Q. まず何から始めればいいですか？ A. 3点だけ。①CLAUDE.md に開発コマンドと禁止事項を書く、②settings.json で allow/ask/deny を分けてGitに乗せる、③pr-review コマンドを共有する。ここまでで属人化の半分は消えます。

実際に試した結果

冒頭の「一人だけ速いチーム」の話には続きがあります。そのキーパーソンの頭の中にあったプロンプトを .claude/commands/ に書き出し、権限設定を settings.json で共有しただけで、他の3人の出力が見違えるほど揃いました。レビューが通るスピードも、特定の人に依存しなくなった。

逆に、効果がいまひとつだったのもあります。編集のたびに全体 lint を走らせる hook は、モノレポでは重すぎて全員から不満が出ました。これはCIに寄せて正解でした。

結論はシンプルです。Claude Codeのチーム活用は、魔法のプロンプトを探すことではなく、一人の頭の中にあるものを、リポジトリの中に移す作業です。CLAUDE.md・権限・カスタムコマンドの3つから始めれば、効果はすぐ実感できます。引き継ぎまで含めて運用を固めたい人は チーム引き継ぎルール へ、社内展開用のテンプレートが欲しい人は ClaudeCodeLabの教材一覧 もどうぞ。