Claude Code チーム導入ガイド｜設定をリポジトリで共有して全員の品質を揃える

Claude Code を個人で使い込むと、CLAUDE.md・許可設定・スラッシュコマンド・サブエージェント……と、自分専用の“効く設定”がたまっていきます。ところがチームで使い始めると、ある壁にぶつかります。同じリポジトリなのに、人によって Claude の振る舞いも品質もバラバラ。片方はテスト実行を毎回自動化しているのに、もう片方は毎回手で許可を出している——そんな状態です。

原因はシンプルで、設定が各自のマシンに散らばっているから。これを解くのが「設定をリポジトリに置いて共有する」設計です。Claude Code は、チームで共有すべき設定をリポジトリにコミットするファイルと、各自の手元に置く個人設定にきれいに分けられます。この記事では、触り始めたチームに向けて、どのファイルを共有し、どれを手元に残すかを、公式ドキュメント（code.claude.com/docs）の裏取り範囲で整理します。そのままコミットできる共有対象の早見表・.gitignore テンプレ・新メンバーのオンボーディング手順も置いておきます。

🎯 なぜ「リポジトリで共有」なのか

Claude Code の設定は、置き場所によって効く範囲が変わります。大きく3系統です。

• ユーザー設定（~/.claude/ 配下）＝そのマシンの全プロジェクトに効く。自分だけのもの。

• プロジェクト設定（リポジトリ内の .claude/ や直下ファイル）＝そのリポジトリで作業する全員に効く。共有するもの。

• ローカル設定（.claude/settings.local.json など）＝そのリポジトリだが自分だけ。共有しない。

チームで品質を揃えたいなら、狙うのは真ん中のプロジェクト設定です。ここに置いた .claude/settings.json や CLAUDE.md はバージョン管理（git）を通じてチームに配られるため、git clone した瞬間に全員が同じ土台を手にします。「口頭で設定を伝える」のをやめ、設定そのものをコードとして配る——これがチーム導入の核心です。

🗂 共有できる設定の全体像：リポジトリに入る4系統

リポジトリにコミットして共有できる設定は、大きく4つに分かれます。まずここを押さえます。

• ① 挙動の設定：.claude/settings.json（許可ルール・環境変数・フックなど）

• ② 指示（メモリ）：CLAUDE.md（または .claude/CLAUDE.md）と .claude/rules/

• ③ 再利用パーツ：.claude/commands/（スラッシュコマンド）・.claude/agents/（サブエージェント）・.claude/skills/（スキル）

• ④ 外部連携：.mcp.json（プロジェクトの MCP サーバー定義）

いずれもリポジトリ直下または .claude/ の下に置くのがポイントです。共有したいものは .claude/（＝コミット対象）、自分だけのものは ~/.claude/（＝ホーム、コミット圏外）——「点は共有、チルダは個人」と覚えると迷いません。

📋 共有する／しないファイル 早見表（コピペ保存版・その1）

チーム導入でいちばん事故りやすいのが「共有すべきものを .gitignore してしまう」「個人設定をうっかりコミットする」の2つです。次の早見表を、そのままチームの取り決めにしてください。

■ Claude Code 設定ファイル 共有/個人 早見表
ファイル / ディレクトリ            コミット?   スコープ        内容
.claude/settings.json             ✅ する    プロジェクト     チーム共有の許可ルール・env・フック
.claude/settings.local.json       ❌ しない  ローカル        自分だけの上書き・お試し（自動 gitignore）
~/.claude/settings.json           －（圏外） ユーザー        自分の全プロジェクト設定（テーマ等）
CLAUDE.md / .claude/CLAUDE.md      ✅ する    プロジェクト     チーム共有の指示（規約・コマンド・構成）
CLAUDE.local.md                    ❌ しない  ローカル        自分だけのメモ（.gitignore 対象）
~/.claude/CLAUDE.md                －（圏外） ユーザー        自分の個人的な好み
.claude/rules/                     ✅ する    プロジェクト     トピック別・パス別ルール
.claude/commands/                  ✅ する    プロジェクト     チーム共有のスラッシュコマンド
.claude/agents/                    ✅ する    プロジェクト     チーム共有のサブエージェント
.claude/skills/                    ✅ する    プロジェクト     チーム共有のスキル
.mcp.json                          ✅ する    プロジェクト     チームで使う MCP サーバー定義
~/.claude.json                     －（圏外） ユーザー        個人の MCP・認証（絶対に共有しない）

要点は3つ。（1）.claude/ 直下の設定・パーツ系は基本コミット。（2）末尾が .local. のもの（settings.local.json／CLAUDE.local.md）は個人用でコミットしない。（3）ホーム（~/）配下は最初からリポジトリの外。この3原則を外さなければ、共有の取り違えはほぼ防げます。

🧱 設定の階層と優先順位——なぜ「個人の上書き」が壊さないのか

「共有設定を配ったら、各自の好みを反映できなくなるのでは？」という不安には、階層の優先順位が答えになります。Claude Code の設定は複数の層が重なり、より狭い（自分寄りの）層が優先されます。優先度は高い順に次のとおりです。

■ settings の優先順位（高い→低い）
1. 管理ポリシー（managed-settings.json：組織が配布・上書き不可）
2. コマンドライン引数（--settings など：その場限り）
3. ローカル   .claude/settings.local.json（自分・このリポジトリ）
4. プロジェクト .claude/settings.json（チーム共有）
5. ユーザー   ~/.claude/settings.json（自分・全プロジェクト）

つまり、チーム共有の .claude/settings.json を土台にしつつ、各自は .claude/settings.local.json で上書きできます。共有設定を壊さずに「自分だけこのコマンドは常に許可」といった調整が可能です。

ひとつ注意したいのが許可ルール（permissions の allow / ask / deny）だけは挙動が違う点。許可ルールは上書きではなく各スコープが合算（マージ）されます。たとえばプロジェクトの deny と個人の deny は両方効きます。「共有の禁止ルールを個人設定で緩める」ことは基本できない設計になっているので、チームの安全ルール（deny）は .claude/settings.json に置けば全員に一律で効く、と理解しておきましょう。

🚫 .gitignore の設計（コピペ保存版・その2）

共有を安全にする土台が .gitignore です。個人用ファイルがうっかりコミットされないよう、リポジトリの .gitignore に次を足しておきます。

# --- Claude Code：個人設定はコミットしない ---
.claude/settings.local.json
CLAUDE.local.md

# 必要なら：各自の実験用スキル/コマンドを個人フォルダに分けている場合
# .claude/skills/local/
# .claude/commands/local/

補足として、.claude/settings.local.json は Claude Code が自動生成したときには自動で gitignore 設定されます。ただし自分で手作りした場合は自動では無視されないので、上のように明示しておくと安全です。逆に、.claude/settings.json・CLAUDE.md・.claude/commands/・.claude/agents/・.claude/skills/・.mcp.json はignore しない——共有したいものを消してしまわないよう、.gitignore に広すぎるパターン（例：.claude/）を書かないこと。

🔐 ワークスペース信頼（workspace trust）——共有設定が“いきなり全開”にならない仕組み

チーム共有で見落としがちなのが安全ゲートです。リポジトリを clone しただけで、共有された許可ルールやフックが無条件に有効になると、悪意ある設定を踏むリスクがあります。そこで Claude Code はワークスペース信頼という確認を挟みます。

具体的には、.claude/settings.json（共有）に書かれた allow ルールは、そのフォルダを「信頼する」と承認するまで効きません。一方、自分で書いた .claude/settings.local.json の allow は信頼承認なしで効きます（自分が書いたものだから）。フックの実行も同じ信頼ゲートの内側です。

.mcp.json（共有 MCP サーバー）も同様で、初回はプロジェクトの MCP サーバーを使ってよいか確認が入ります。チーム全体で毎回確認を省きたい場合は、.claude/settings.json に次のような設定を置けます（想定例）。

{
  "enableAllProjectMcpServers": true,
  "enabledMcpjsonServers": ["github", "sentry"]
}

enabledMcpjsonServers で使うサーバーを明示、disabledMcpjsonServers で除外——というように、共有はするが有効化はチームの合意で制御できます。「共有＝即・全許可」ではない、という安心設計です。

🚀 新メンバーのオンボーディング手順（コピペ保存版・その3）

ここまでを、新しく入った人がその日に同じ品質へ揃う手順に落とします。README かチームの CLAUDE.md に貼っておくと効きます。

■ Claude Code チーム オンボーディング チェックリスト
□ 1. リポジトリを git clone する
□ 2. Claude Code を起動し、対象フォルダの「信頼（trust）」を承認
      → 共有の allow ルール・フック・MCP がここで有効化される
□ 3. /context を実行し、CLAUDE.md と .claude/rules が読み込まれているか確認
□ 4. .mcp.json の MCP サーバー利用を承認（初回のみ）
□ 5. 自分だけの好みは .claude/settings.local.json に書く（共有設定は触らない）
□ 6. 迷ったら /doctor で設定の健康診断（読み込み状況・肥大化の点検）

ポイントはステップ2の「信頼の承認」。ここを通して初めて共有設定が効くので、「設定を入れたのに効かない」の多くはこの承認漏れです。そしてステップ5の原則——新メンバーが最初にやりがちな「共有の settings.json を自分好みに直接書き換える」を防ぎ、個人の調整は必ず .local へを徹底します。これで、全員が「同じ土台＋各自の微調整」という理想形になります。

💡 なぜ共有すると品質が揃うのか（原理）と、落とし穴

手順で終わらせないための、一段深い部分です。

原理：設定を「コード」にすると、品質が“属人”から“資産”に変わる

口頭やチャットで共有した設定は、伝えた瞬間から劣化します（言い忘れ・バージョン違い・人による解釈差）。一方、.claude/settings.json や CLAUDE.md をリポジトリにコミットすると、設定はレビューでき・差分が追え・巻き戻せる「コード」になります。新メンバーの立ち上がりは git clone だけ、規約の更新は Pull Request だけ。属人的だった“効く設定”が、チームの共有資産に変わる——これが「設定を共有する」ことの本質的な効果です。テストコマンドや禁止操作を全員が同じように扱えるので、レビューで指摘する回数そのものが減っていきます。

落とし穴1：秘密情報を共有ファイルに直書きしない

最重要の注意です。.claude/settings.json はコミットされる＝リポジトリを見られる全員に見えるため、APIキー・トークン・社内URLなどの秘匿情報を直接書いてはいけません。環境変数が必要なら、値は各自の環境や ~/.claude/settings.json（個人・圏外）に置き、共有側にはキー名だけを前提にします。認証を動的に生成したいなら apiKeyHelper（値ではなくスクリプトを指定）を使う手もあります。共有ファイルに秘密を書いた瞬間、git履歴に残って消せなくなる——ここは事故になりやすいので、運用ルールとして別記事（No.68）で線引きを詳しく扱います。

落とし穴2：.gitignore が広すぎて共有パーツごと消える

「.claude/ をまとめて無視」してしまうと、共有したい settings.json や commands/ まで git 圏外になり、「自分の環境では動くのに、他の人には共有されない」が起きます。無視するのは末尾 .local. の個人ファイルだけにとどめ、共有対象は必ずコミットされているか、git status で確認する癖をつけましょう。

落とし穴3：CLAUDE.md を全員で共有＝“みんなの持ち物”になる

共有した CLAUDE.md は全員に毎セッション読み込まれます。裏を返すと、一人が雑に増やすと全員のトークンとノイズが増える。共有メモリは「誰が・いつ・なぜ更新したか」をレビューで管理しないと、すぐ肥大化して逆効果になります。この運用ルール（レビュー・棚卸し・秘匿情報の線引き）は次の記事 No.68 で体系化します。本記事は「何を・どこに置いて共有するか」の土台までを担当します。

🧾 コピペ保存版まとめ：3点セット

この記事の保存版要素をひとまとめにします。（1）共有/個人の早見表（上掲）で「どのファイルを配るか」を決め、（2）.gitignore テンプレ（上掲）で個人ファイルの流出を止め、（3）オンボーディング チェックリスト（上掲）で新メンバーを同じ品質へ揃える。この3枚をリポジトリの README かチーム CLAUDE.md に貼れば、チーム導入の骨格は完成です。

❓ よくある質問（つまずきの回収）

• Q. まず何を最初に共有すべき？

CLAUDE.md（/init で出発点を生成）と、チームの安全ルールを書いた .claude/settings.json（とくに permissions.deny）の2つです。この2枚だけでも、規約と禁止操作が全員に揃います。

• Q. 共有設定を入れたのに効かない。

多くはワークスペース信頼の承認漏れです。共有の allow ルールやフックはフォルダを信頼するまで有効になりません。/context で CLAUDE.md や rules が読み込まれているかも確認しましょう。

• Q. 各自の好みはどう反映する？

.claude/settings.local.json（このリポジトリだけ・自分だけ）か ~/.claude/settings.json（全プロジェクト・自分だけ）へ。共有の .claude/settings.json は直接編集せず、上書きは個人層で行います。

• Q. MCP サーバーはチームで共有できる？

.mcp.json をコミットすれば定義を共有できます。初回は利用承認が入り、enableAllProjectMcpServers や enabledMcpjsonServers で有効化をチームの合意に沿って制御できます。ただし認証情報は .mcp.json に直書きしない（落とし穴1と同じ）。

• Q. スラッシュコマンドやサブエージェントも配れる？

.claude/commands/・.claude/agents/・.claude/skills/ をコミットすれば共有されます。個人層（~/.claude/…）と同名がある場合はプロジェクト側／個人側の優先順位に従うので、チーム標準はプロジェクト側に置きます。

おわりに：まず CLAUDE.md と deny を1枚ずつ配る

要点を3行で。

• 共有はプロジェクト設定（.claude/ 直下・リポジトリ直下）に置いてコミット。個人設定は.local かホーム配下に逃がす（「点は共有、チルダは個人」）。

• 共有設定はワークスペース信頼を承認して初めて効く。新メンバーは clone → 信頼承認 → /context 確認、で同じ土台に揃う。

• 共有ファイルに秘密は書かない。運用の線引き（レビュー・棚卸し・秘匿情報）は次記事 No.68 へ。

最初の一歩は、いまの自分の CLAUDE.md とチームで守りたい禁止操作（permissions.deny）を、.claude/ に置いてコミットしてみること。次に clone した人が同じ挙動になったら、あなたのチームは「設定を共有する」土台に乗れています。