Claude Codeチーム導入ガイド — CLAUDE.md規約とレビュー体制の設計

Claude Codeをチームで使うと個人利用と何が変わるか

個人で使うClaude Codeは、自分のCLAUDE.mdと自分のsettings.jsonだけを気にすればすみます。チームで使うと事情が変わります。CLAUDE.mdは全員のセッションに読み込まれる共有ドキュメントになります。コードレビューはClaudeが書いたPRと人間が書いたPRを同じ基準で扱う必要が出てきます。権限設定はメンバーごとの裁量とプロジェクト全体の統制のバランスになります。

この記事では、チーム導入で設計が必要になる3つの領域を扱います。

• CLAUDE.mdの規約設計 — 誰が書き、どう更新し、モノレポでどう分割するか
• レビュー体制 — Claude Code Review機能とGitHub Actions、人力レビューの役割分担
• 権限とSkills共有 — settings.jsonの分担とプラグイン化

料金プランやシート数の話はClaude Teamプランガイドに譲り、導入後の運用設計に絞ります。

チーム共有のCLAUDE.mdはどこに何を書くか

CLAUDE.mdは4つの階層に配置でき、それぞれ共有範囲が違います。

管理ポリシーCLAUDE.mdの配置先はOSごとに固定されています。macOSは/Library/Application Support/ClaudeCode/CLAUDE.md、Linux/WSLは/etc/claude-code/CLAUDE.md、WindowsはC:\Program Files\ClaudeCode\CLAUDE.mdです。

チーム導入で最初に整えるのはプロジェクトCLAUDE.mdです。ビルド・テストコマンド、コーディング標準、アーキテクチャの決定、命名規則、共通ワークフローを書き、バージョン管理でチームと共有します。個人的な好みではなくプロジェクトレベルの標準に絞るのが原則です。

/init

/init はコードベースを分析し、ビルドコマンドやテスト手順、既存の規約を含むCLAUDE.mdを自動生成します。すでにCLAUDE.mdがある場合は上書きせず改善を提案します。CLAUDE_CODE_NEW_INIT=1 を設定すると対話型の多段フローになります。CLAUDE.md・Skills・Hooksのどれを整備するか選ぶと、サブエージェントがコードベースを探索して提案を出し、確認してから書き込みます。

CLAUDE.mdに追加すべきタイミングは4つあります。

• Claudeが同じ間違いを2回目に犯したとき
• コードレビューでコードベースの前提知識が足りなかったと指摘されたとき
• 前回と同じ修正や説明をチャットに入力しているとき
• 新しいメンバーが同じコンテキストを必要としているとき

逆に、複数手順の作業やコードベースの一部だけに関わる指示はSkillかパススコープルールに逃がします。

指示の書き方は具体性で効果が変わります。検証できる指示だけがClaudeの遵守率を上げます。

ファイル自体は200行以下を目安にし、長くなったら次節のルール分割を使います。

モノレポや大規模チームでCLAUDE.mdをどう分割するか

チームの規模が大きくなると、1つのCLAUDE.mdに全部を書くのは無理があります。.claude/rules/ディレクトリにトピックごとのファイルを置くと、指示がモジュール化されます。

your-project/
├── .claude/
│   ├── CLAUDE.md
│   └── rules/
│       ├── code-style.md
│       ├── testing.md
│       └── security.md

paths frontmatterを付けると、一致するファイルを開いたときだけそのルールが読み込まれます。

---
paths:
  - "src/api/**/*.ts"
---
 
# API開発ルール
 
- 全てのエンドポイントは入力検証を含める
- 標準エラー応答形式を使用する

ルールディレクトリはシンボリックリンクに対応しているため、~/shared-claude-rulesのような社内共通ルールセットを複数リポジトリにリンクして使い回せます。モノレポで他チームのCLAUDE.mdが自分の作業に無関係な指示を持ち込んでくる場合は、claudeMdExcludesでパス指定してスキップします。この設定は配列としてスコープ間でマージされるため、.claude/settings.local.jsonに足すだけで済みます。

組織全体にコーディング標準を強制したいなら、管理ポリシーの層を使います。管理設定とCLAUDE.mdは役割が異なり、混同すると事故のもとです。

管理設定はClaudeの判断に関わらずクライアント側で強制されますが、CLAUDE.mdの指示はコンテキストであってハード強制層ではありません。ファイル配布が面倒な場合、managed-settings.jsonのclaudeMdキーに文字列としてCLAUDE.md本文を直接埋め込むこともできます。管理ポリシーのCLAUDE.mdは個別設定で除外できず、ユーザーやプロジェクト側でclaudeMdを設定しても効果を持ちません。組織のセキュリティポリシーやコンプライアンス要件はこちらに置くのが安全です。

CLAUDE.mdの更新は誰がレビューするか

プロジェクトCLAUDE.mdはリポジトリにコミットされたファイルなので、通常のPRレビューフローにそのまま乗ります。CLAUDE.mdを変更するPRを他のコードと同列に扱い、レビュー担当(テックリードや当該領域のオーナー)を割り当てるだけで、規約の追加や矛盾を止められます。

矛盾する指示が積み重なるのがCLAUDE.md運用の典型的な劣化パターンです。2つのルールが食い違うとき、Claudeはどちらか一方を任意に選びます。CLAUDE.mdファイル、ネストされたファイル、.claude/rules/を定期的に見直し、古くなった指示を削除する棚卸しの機会を決めておくと防げます。CLAUDE.mdの10パターンは具体的な書き方の型を集めているので、規約テンプレートを作る際の出発点にしやすいです。

コードレビュー体制はどう設計するか

チーム導入でもっとも設計判断が要るのがレビュー体制です。選択肢は3つあり、排他的ではなく重ねて使えます。

Code Review機能はリサーチプレビュー段階で、Team / Enterpriseサブスクリプションのみで使えます(Zero Data Retentionを有効化した組織では利用できません)。管理者がclaude.ai/admin-settings/claude-codeでGitHub Appをインストールし、レビュー対象リポジトリを選び、リポジトリごとに実行タイミングを設定します。

結果は🔴 Important(マージ前に直すべきバグ)・🟡 Nit(軽微だが直す価値がある)・🟣 Pre-existing(このPRで持ち込まれていない既存バグ)の3段階でタグ付けされます。重要なのは、Code ReviewはPRを承認もブロックもしない点です。チェック実行は常に中立的な結論で完了するため、ブランチ保護でマージを止める仕組みにはなりません。マージ判断のゲートに組み込みたい場合は、チェック実行の出力テキストをgh apiとjqで解析して重大度別カウントを取り出す必要があります。

レビュー基準はCLAUDE.mdとREVIEW.mdの2つのファイルで調整できます。両者は効き方が違います。

REVIEW.mdはリポジトリルートに置く素のMarkdownで、@インポートは展開されずそのまま逐語で使われます。調整に向くのは次のような項目です。

• Importantの定義を狭める(本番を壊すバグだけに限定する等)
• Nitの投稿数に上限を付ける
• 生成コードやロックファイルをスキップ対象にする
• 「新しいAPIルートには統合テストが必須」のようなリポジトリ固有チェックを足す

長くしすぎると重要なルールが埋もれます。レビュー動作の変更だけに絞り、一般的なプロジェクト説明はCLAUDE.md側に残すのが実務的です。

料金は1レビューあたり平均15〜25ドルで、PRの大きさとコードベースの複雑さでスケールします。プランの含まれた使用量にはカウントされず、usage creditsとして個別請求されるため、claude.ai/admin-settings/usageで月次の支出上限を設定できます。GitHub Actionsのカスタムワークフローを使う場合の認証・コスト試算・つまずきどころはClaude CodeをGitHub Actionsに組み込むにまとめています。

ローカルでは、GitHub Appを入れなくても任意のセッションで/code-reviewを実行して差分をチェックできます。

/code-review --comment

デフォルトではブランチのアップストリームより先のコミットと、作業ツリーの未コミット変更が対象です。--commentでインラインPRコメントとして投稿、--fixでレビュー後にワーキングツリーへ結果を適用できます。ファイルパス・PR番号・ブランチ名・main...my-featureのようなref範囲も指定対象にできます。

Code Reviewは人力レビューの何を肩代わりするか

Code Reviewが得意なのは、コードベース全体のコンテキストを踏まえたロジックエラー・セキュリティ脆弱性・見落としやすいエッジケースの検出です。複数のエージェントが並行してdiffと周辺コードを検査し、検証ステップで実際のコード動作と突き合わせてから結果を絞り込む設計なので、単純な構文チェックより一段深いところまで拾います。

ただし、Code Reviewが肩代わりするのは一次スクリーニングであって、最終判断ではありません。PRを承認もブロックもしない仕様がそれを裏付けています。設計の妥当性、機能要件との整合性、この変更がプロダクトにとって正しい選択かという判断は、依然として人間のレビュアーの仕事です。Code Reviewが投稿するのはあくまで「ここにバグがありそうだ」という一次情報で、それをどう扱うかは人間が決めます。

現実的な体制は、Code Reviewを人力レビューの前段フィルタとして使うことです。プッシュのたびに走らせて機械的に拾えるバグを先に潰し、人間のレビュアーは設計判断とビジネスロジックの妥当性に集中する、という分担にすると、レビュー1件あたりの人間の負荷が下がります。Nitの投稿数が多すぎて逆にノイズになる場合は、REVIEW.mdでキャップをかける調整が効きます。

権限とsettings.jsonをチームでどう分担するか

CLAUDE.mdと同じく、settings.jsonにもチーム共有とローカルの区別があります。.claude/settings.jsonはプロジェクト共有の権限ルール(permissions.allow / ask / deny)やHooksを置くファイルです。git commitでチーム全員に配ります。個人固有の値(サンドボックスURLやテストデータ)は.claude/settings.local.jsonに置いて.gitignoreします。

組織として絶対に譲れない制約(危険なコマンドの禁止、サンドボックス強制、認証方式の固定)は、プロジェクト設定ではなく管理設定に置きます。プロジェクト設定はユーザー設定より強く、Managed層はさらにその上位にあり個別設定で上書きできないからです。権限モード・サンドボックス・データ扱いの3層の組み合わせ方はClaude Codeセキュリティ・権限ガイドが詳しいです。settings.jsonの全フィールドと環境変数はClaude Code設定ガイドにまとめています。

Skills・Hooksはプラグイン化してチーム共有する

.claude/ディレクトリへの直書き(スタンドアロン設定)は個人のワークフローや単一プロジェクトの調整には向きますが、チーム全体への配布には向きません。複数プロジェクトで同じSkillやSub-agentを使い回したい、バージョン管理して更新を配りたい、という場面ではプラグイン化します。

プラグインは自己完結ディレクトリです。.claude-plugin/plugin.jsonマニフェストと、skills / agents / hooks / .mcp.jsonなどの構成ファイルを持ちます。Skill名は/plugin-name:helloのように名前空間付きになるため、複数プラグインで同名Skillがあっても衝突しません。チーム内だけで配布したい場合は、プラグインマーケットプレイスをプライベートリポジトリでホストします。公開マーケットプレイスにはAnthropicキュレーションのclaude-plugins-officialと、サードパーティ提出のclaude-communityがあります。社内規約やドメイン固有のSkillはここに出さず、自社リポジトリで完結させます。

claude --plugin-dir ./my-team-plugin

開発中は--plugin-dirでインストールなしにテストし、/reload-pluginsで再起動せず変更を反映できます。既存の.claude/commandsや.claude/agentsをプラグインに移行する場合、挙動はファイル種別で異なるので注意が必要です。同名のプロジェクト/ユーザー定義エージェントはプラグイン版に上書きされるため、移行後は元のファイルを削除してから動作を確認します。一方Skill(.claude/commands)は/plugin-name:skill-nameという別の名前空間になるため、元の/skill-nameとプラグイン版は上書きされず共存します。削除するのはagentsだけで十分です。

よくある質問

Code Review機能は無料で使えますか

いいえ。リサーチプレビュー段階で、Team / Enterpriseサブスクリプションのみが対象です。Zero Data Retentionを有効化している組織では利用できません。料金はトークン使用量に応じ、1レビューあたり平均15〜25ドルがプランの含まれた使用量とは別に請求されます。

CLAUDE.mdとREVIEW.mdは両方用意すべきですか

必須ではありません。CLAUDE.mdだけでもCode Reviewはプロジェクトコンテキストとして読み、新規違反をNitとして拾います。レビュー基準を通常のセッションと切り離して細かく調整したい場合(重大度の再定義、Nitの上限、スキップ対象の指定など)にREVIEW.mdを足す、という順序で問題ありません。

Code ReviewとGitHub Actionsの導入順

役割が違うので、比較というより順番の話になります。まずCode Reviewでレビューの一次フィルタを整えます。レビュー以外の自動化(Issueからの実装、定期レポート、独自のCI連携)が必要になった時点で、GitHub Actionsのカスタムワークフローを足すのが無理のない導入順です。

個人利用からチーム展開まではどの順番で進めますか

CLAUDE.mdや権限設計はチーム展開の後半で効いてくる話です。触ってみる段階から組織の標準ツールにする段階までの判断基準はClaude Code業務導入の9ステップチェックリストにまとめています。両方を合わせて読むと、本記事の規約設計・レビュー体制をどのタイミングで着手すべきかが見えやすくなります。

管理ポリシーのCLAUDE.mdをメンバー側で除外できますか

できません。管理ポリシーのCLAUDE.mdはユーザー設定やプロジェクト設定のclaudeMdExcludesで除外対象にできず、個別設定に関係なく常に適用されます。組織全体のセキュリティポリシーやコンプライアンス要件をここに置く理由はこの強制力にあります。

モノレポで他チームのCLAUDE.mdが邪魔なときはどうしますか

claudeMdExcludesにパスまたはグロブパターンを指定してスキップします。配列はスコープ間でマージされるため、個人のマシンだけに限定したい場合は.claude/settings.local.jsonに書きます。管理ポリシーのCLAUDE.mdだけはこの方法で除外できません。

まとめ

Claude Codeのチーム導入は、CLAUDE.mdをどこに何を書くか決めることから始まります。プロジェクトCLAUDE.mdが共有の規約を、.claude/rules/がモノレポの分割を、管理ポリシーが組織の強制事項を担います。CLAUDE.mdの変更自体を通常のPRレビューに乗せると、規約の劣化を防げます。

レビュー体制はCode Review機能・GitHub Actionsのカスタムワークフロー・人力レビューの三層です。Code Reviewは承認もブロックもしません。一次フィルタとして人力レビューの前段に置く設計が現実的です。権限とSkillsの共有は、settings.jsonのプロジェクト/ローカル分担とプラグイン化で、個人の実験とチーム標準を分けて運用します。