個人で使い始めた Claude Code をチームに広げようとしたとき、最初に判断を迫られるのが .claude/ ディレクトリの扱いです。すべてを Git にコミットすれば全員が同じ設定で始められそうですが、個人の API トークンやセッション履歴まで共有してしまうと、事故の温床になります。逆に .claude/ を丸ごと .gitignore に入れてしまうと、せっかく整備したカスタムコマンドやサブエージェントがチームに引き継がれません。
私は4つの個人プロジェクトで Claude Code を運用し、そのうち2つでチーム展開を進めるなかで、.claude/ の境界が曖昧なまま走ると再現性が崩れる瞬間に何度もぶつかりました。ここでは「何を Git に入れて、何を個人領域に残すか」を、実用的なパターンとして整理します。
.claude/ の中身を分類する
Claude Code の .claude/ には用途の異なるファイルが混在しています。まず構成要素を分類しないと、Git 戦略の議論は前に進みません。代表的な要素は次のとおりです。
settings.json— プロジェクト共通の設定（モデル選択・許可ツール・MCP サーバー定義など）settings.local.json— 個人ローカルの上書き設定（既定で gitignore 推奨）commands/— カスタムスラッシュコマンド（.mdファイル群）agents/— カスタムサブエージェント定義CLAUDE.md— プロジェクトの作業指針（コードベース上位の知識ファイル）history/またはsessions/— Claude Code が記録するセッション履歴
このうち、チームで共有する価値があるのは「コマンド」「エージェント」「共通 settings」「CLAUDE.md」の4つです。残りは原則として個人領域に置きます。判断基準はシンプルで、「同じリポジトリで作業する全員が、同じ挙動で Claude Code を使えるべき情報か？」を問うだけです。
チームで共有する4つのファイル
私の判断軸は明確で、「再現性に寄与する設定」だけを Git に入れるというものです。具体的にはこの4種類が該当します。
commands/*.md は共有しないと意味がありません。「/release でリリース手順を実行する」「/migrate でマイグレーションスクリプトを生成する」といったコマンドは、チームの作業手順そのものです。個人別に違う実装を持つ理由がないので、リポジトリ直下の .claude/commands/ にコミットします。レビューを通して品質を上げていける副次効果も大きいです。
agents/ も同じ性質を持ちます。たとえば「PR レビュー専用エージェント」や「テスト失敗の原因を切り分けるエージェント」は、定義を共有しないと「誰々さんの環境でだけ動く」属人性が生まれます。サブエージェントは設計次第で生産性に大きく差が出るので、ここを共有しない手はないと考えています。
CLAUDE.md はプロジェクトのドメイン知識・コーディング規約・テスト戦略を Claude に伝える中核ファイルです。これがリポジトリに入っていないと、新しく参加した開発者が Claude Code を使っても文脈ゼロから始まることになり、Claude Code の真価が発揮されません。
settings.json のうち共有してよいのは、「許可コマンド一覧」「使用モデル」「MCP サーバーの接続先 URL」など、機密情報を含まない部分です。設定の細かいフィールドについては Claude Code の settings.json 完全ガイド も参考にしてみてください。
個人領域に残すべきもの — 私が実際にやらかした落とし穴
Git に入れてはいけないものも明確にしておきます。ここを曖昧にすると、ある日突然 .git/objects の中に API キーが永久保存される事故が起きます。
settings.local.json は Claude Code が「個人の上書き」として認識するファイルで、デフォルトで gitignore に入れることが推奨されています。ここに個人の API トークンや、ローカル限定の許可設定を書きます。
history/ や sessions/ のセッション履歴は、個人の作業内容そのものです。コミットしてしまうと、プロンプトの試行錯誤や、社内の機密情報を含む会話まで公開されてしまいます。私は最初の頃 .claude/ 全体を git add してしまい、レビュアーから「このコミットに OPENAI_API_KEY が混ざっている」と指摘されて慌てて push 前に取り消したことがあります。これは git push 後だったら BFG Repo-Cleaner で履歴ごと書き換える羽目になっていました。
MCP サーバー設定のうち認証情報（OAuth トークン、API キー、データベース接続文字列）は絶対に共有しません。共有 settings.json には「接続先 URL」「サーバー名」までを書き、認証は各自が個別にセットアップする運用にします。settings.local.json 側で mcpServers の認証情報だけを上書きする構造にすると、共有部分と個人部分がきれいに分離できます。
実用 .gitignore テンプレート
私が4つのプロジェクトで使い回している .gitignore のパターンを共有します。
# Claude Code 個人設定
.claude/settings.local.json
.claude/history/
.claude/sessions/
.claude/cache/
.claude/projects/
# 一時ファイル・OS固有ファイル
.claude/*.tmp
.claude/.DS_Store
# 認証情報の保険（万が一書いてしまった時の最後の砦）
.claude/secrets.json
.claude/.env*
.claude/**/credentials.json逆に、.claude/commands/ .claude/agents/ .claude/settings.json CLAUDE.md は 明示的にコミット対象 とします。
.gitignore を整備したら、git status -- .claude/ で意図したファイルだけが追跡対象になっているかを必ず確認してください。新しいバージョンの Claude Code が新しいサブディレクトリを作る可能性もあるので、月に1回程度は git status -- .claude/ を眺めてみることをおすすめします。私はこの確認をしていなかった時期に、新規追加された .claude/projects/ をうっかりコミットしてしまったことがあります。
チーム展開時の段取り
個人で使っていた Claude Code をチームに広げる際は、次の順序で進めると摩擦が少なくなることに気づきました。
- 既存の
.claude/settings.jsonから個人情報（トークン・絶対パス・自分のメールアドレス等）をsettings.local.jsonに分離する .gitignoreを整備し、git status -- .claude/でクリーンな状態を確認commands/とagents/を整理し、チームで使うものだけを残す（試作品は_archive/に移動か削除）CLAUDE.mdの冒頭に「このリポジトリで Claude Code を使う前に読むべきこと」セクションを追加- プルリクエストとして他メンバーにレビューしてもらい、意図しない個人情報が混入していないか確認
特に5番目は省略しないでください。自分では気づかない個人情報（過去のディレクトリパス、社内の社員名、サンプルとして入れたメールアドレスなど）が commands/ の .md 内に紛れ込んでいることが意外と多くあります。コミット前のレビューは、技術的な正しさよりも「公開していい情報かどうか」をチェックする場として使うのが効果的です。
CLAUDE.md の設計思想については CLAUDE.md 設計パターン — プロジェクトインテリジェンスの育て方 で詳しく扱っていますので、チームで活用する前に一読することをおすすめします。
全体を振り返って — 今日からできる小さな一歩
.claude/ の Git 戦略は、一度決めれば長く使える「土台」の部分です。今すぐすべてを整える必要はありません。今日のところは .gitignore に .claude/settings.local.json と .claude/history/ .claude/sessions/ の3行を追加し、git status -- .claude/ でクリーンになっているかを確認するだけで十分です。これだけでも、機密情報が漏れる事故の大半は防げます。
そのうえでチーム展開を考える段階になったら、コマンドとエージェントを整理し、CLAUDE.md を整える、という順序で広げていくのが、私の経験上もっとも摩擦が少ない進め方でした。Claude Code の真価は「同じ前提を共有したチーム」で使ったときに最も発揮されると感じています。