「Claude Code を個人では使えているけれど、チームで同じように使うにはどうすればいい？」——そう感じているリーダーや開発者は多いはずです。

Claude Code をチームで使いこなすには、プロジェクトの初期設定・CLAUDE.md の整備・Git との連携ルールの3点が鍵になります。これらを最初にしっかり整えておけば、メンバー全員が「Claude に毎回同じことを説明する」手間がなくなり、コードの品質と一貫性が自然に保たれます。

本記事はチーム全員が読んですぐに作業を開始できるように、プロジェクトのセットアップ手順から Git の基本コマンド・運用ルールまでを一冊にまとめました。

1. チーム開発での Claude Code の考え方

Claude Code をチームで使う場合、最も重要な原則は「Claude への指示をコード化して共有する」ことです。個人利用では「その場でプロンプトを書けばいい」で済みますが、チームでは以下の問題が起きます。

• メンバーごとに Claude への指示スタイルが異なり、生成コードのスタイルがバラバラになる
• 新しいメンバーが「このプロジェクトの Claude の使い方」を一から学ばなければならない
• 「以前うまくいったプロンプト」がメンバー間で共有されず属人化する

これを解決するのが CLAUDE.md と Git による設定ファイルの共有です。プロジェクトのルールを CLAUDE.md に書いて Git で管理すれば、全員が同じ前提で Claude を使えるようになります。

2. プロジェクトフォルダのセットアップ

推奨ディレクトリ構成

新しいプロジェクトを始めるとき、以下の構成を最初に作っておきましょう。

my-project/
├── .claude/
│   ├── settings.json       ← チーム共通の Claude Code 設定
│   └── settings.local.json ← 個人設定（.gitignore に追加）
├── CLAUDE.md               ← チーム共通の Claude への指示
├── CLAUDE.local.md         ← 個人の補足指示（.gitignore に追加）
├── .gitignore
├── README.md
└── src/

ステップ①：リポジトリを初期化する

# 新規プロジェクトの場合
mkdir my-project && cd my-project
git init
git branch -M main

# 既存リポジトリをクローンする場合
git clone https://github.com/your-org/my-project.git
cd my-project

ステップ②：.gitignore を作成する

個人設定ファイルはリポジトリに含めないようにします。

# .gitignore に追加する内容
.claude/settings.local.json
CLAUDE.local.md

# OS・エディタのファイル
.DS_Store
Thumbs.db
.vscode/
.idea/

# 環境変数
.env
.env.local

ステップ③：.claude/settings.json を作成する

チーム全員に適用される Claude Code の設定です。Git で管理してリポジトリに含めます。

{
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(npm:*)",
      "Bash(npx:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  },
  "env": {
    "NODE_ENV": "development"
  }
}

ステップ④：初回コミットをプッシュする

git add CLAUDE.md .claude/settings.json .gitignore README.md
git commit -m "chore: initial project setup with Claude Code configuration"
git remote add origin https://github.com/your-org/my-project.git
git push -u origin main

3. CLAUDE.md の書き方（チーム共通ルール）

CLAUDE.md は Claude Code が起動時に自動で読み込む設定ファイルです。「毎回 Claude に説明していること」をすべてここに書くのが基本です。

チーム向け CLAUDE.md テンプレート

# プロジェクト名

一言でプロジェクトの目的を説明する。

## 技術スタック

- フロントエンド: Next.js 15 / TypeScript / Tailwind CSS
- バックエンド: Node.js / Express / Prisma
- DB: PostgreSQL
- テスト: Vitest / Playwright
- CI/CD: GitHub Actions

## 開発コマンド

```bash
npm run dev      # 開発サーバー起動（localhost:3000）
npm run test     # テスト実行
npm run build    # 本番ビルド
npm run lint     # Lint チェック
```

## コーディング規約

- コメントは日本語で書く
- TypeScript の any 型を使用しない
- 関数は30行以内に収める
- 公開関数には JSDoc を必ず書く
- カバレッジ 80% 以上を維持する

## ディレクトリ構成

```
src/
├── app/          # Next.js App Router のページ
├── components/   # 再利用可能な UI コンポーネント
├── lib/          # ユーティリティ・ヘルパー関数
├── server/       # サーバーサイドロジック
└── types/        # TypeScript の型定義
```

## 禁止事項

- `any` 型の使用禁止
- `console.log` を本番コードに残さない
- `main` ブランチへの直接 push 禁止
- テストなしのコードを PR に含めない
- `git push --force` 禁止（`--force-with-lease` を使うこと）

## PR の作り方

1. `feature/` または `fix/` プレフィックスのブランチを切る
2. コミットメッセージは Conventional Commits 形式で書く
3. PR を出す前に `npm run test` と `npm run lint` を通す
4. レビュアーを最低1名アサインする

## 環境変数

`.env` は Git 管理外。`.env.example` を参考に各自作成する。
本番の環境変数は GitHub Actions Secrets で管理。

4. Git の基本コマンド早見表

チーム開発で毎日使う Git コマンドを場面別にまとめました。

リポジトリの操作

コマンド	意味
git clone <URL>	リモートリポジトリをローカルにコピー
git status	変更ファイルの確認（最初に必ず実行）
git log --oneline -10	直近10件のコミット履歴を表示
git diff	ステージング前の変更差分を表示
git diff --staged	ステージング済みの変更差分を表示

ブランチの操作

コマンド	意味
git branch	ローカルブランチの一覧表示
git branch -a	リモートを含む全ブランチの一覧
git checkout -b feature/xxx	新しいブランチを作成して切り替え
git switch main	main ブランチに切り替え（推奨）
git branch -d feature/xxx	マージ済みブランチを削除

変更の記録（コミット）

コマンド	意味
git add <ファイル名>	特定ファイルをステージング
git add -p	変更を部分的にステージング（対話形式）
git commit -m "feat: xxx"	メッセージ付きでコミット
git commit --amend	直前のコミットを修正（push 前のみ）
git reset HEAD <ファイル>	特定ファイルをアンステージング

リモートとの同期

コマンド	意味
git fetch origin	リモートの変更を取得（マージしない）
git pull origin main	リモートの変更を取得してマージ
git pull --rebase origin main	リベースでマージ（履歴をきれいに保つ）
git push origin feature/xxx	ブランチをリモートに push
git push --force-with-lease	安全な強制 push（他の変更がない場合のみ）

変更を一時退避する（stash）

コマンド	意味
git stash	作業中の変更を一時退避
git stash list	退避リストを表示
git stash pop	退避した変更を復元して削除
git stash drop	退避した変更を削除（復元しない）

5. チーム開発の Git 運用フロー

チームで使う標準的な開発フローです。毎日の作業は以下のサイクルで回します。

毎日の作業開始時

# 1. main の最新を取得する（必ず最初に実行）
git switch main
git pull origin main

# 2. 作業用ブランチを切る
git checkout -b feature/add-user-authentication

# 3. Claude Code を起動して作業開始
claude

作業中のコミット

# こまめにコミットする（1機能 = 1コミットが理想）
git add src/auth/login.ts src/auth/logout.ts
git commit -m "feat: ログイン・ログアウト機能を追加"

# テストも一緒にコミットする
git add src/auth/__tests__/login.test.ts
git commit -m "test: ログイン機能のテストを追加"

PR を出す前の確認

# 最新の main を取り込む（コンフリクトを早期発見）
git fetch origin
git rebase origin/main

# テストと Lint を通す
npm run test
npm run lint

# リモートに push
git push origin feature/add-user-authentication

コミットメッセージの書き方（Conventional Commits）

チーム全員が同じ形式でコミットメッセージを書くと、変更履歴が読みやすくなります。

プレフィックス	意味	例
feat:	新機能	feat: ユーザー認証機能を追加
fix:	バグ修正	fix: ログイン後のリダイレクトを修正
docs:	ドキュメント変更	docs: README にセットアップ手順を追記
style:	コードスタイルのみ（動作変更なし）	style: インデントを修正
refactor:	リファクタリング	refactor: 認証ロジックを共通化
test:	テストの追加・修正	test: ログアウトのテストケースを追加
chore:	ビルド・設定変更	chore: ESLint ルールを更新

6. ブランチ戦略とネーミングルール

ブランチの種類

ブランチ名	役割	直接 push
main	本番リリース済みのコード	❌ 禁止
develop	開発の統合ブランチ（大規模開発向け）	❌ 禁止
feature/xxx	新機能の開発	✅ 自分のみ
fix/xxx	バグ修正	✅ 自分のみ
hotfix/xxx	本番の緊急修正	✅ 自分のみ
docs/xxx	ドキュメントのみの変更	✅ 自分のみ

ブランチ名のネーミングルール

# 良い例（具体的で何をするか分かる）
feature/add-user-authentication
feature/PROJ-123-add-login-page
fix/login-redirect-bug
fix/PROJ-456-fix-token-expiry
hotfix/critical-sql-injection
docs/update-api-documentation

# 悪い例（何をするか分からない）
feature/test
fix/bug
my-branch
temp

7. プルリクエストの作り方・レビュー方法

PR を作る前のチェックリスト

• ✅ npm run test が通っている
• ✅ npm run lint が通っている
• ✅ git rebase origin/main で最新を取り込み済み
• ✅ コミットメッセージが Conventional Commits 形式になっている
• ✅ 不要な console.log や TODO コメントを削除した
• ✅ PR の説明に「何を・なぜ変更したか」を書いた

GitHub CLI で PR を作成する

# GitHub CLI（gh）を使った PR 作成
gh pr create \
  --title "feat: ユーザー認証機能を追加" \
  --body "$(cat <<'EOF'
## 変更内容
- ログイン・ログアウト機能を実装
- JWT 認証を導入
- セッション管理を追加

## 確認手順
1. `npm run dev` で開発サーバーを起動
2. `/login` にアクセスしてログインできることを確認
3. ログアウト後にリダイレクトされることを確認

## 関連チケット
PROJ-123
EOF
)"

Claude Code でコードレビューを依頼する

PR を出す前に Claude Code にレビューを依頼すると、人間のレビュアーが見落としやすい点を事前に修正できます。

# Claude Code に PR のレビューを依頼する例
"src/auth/ ディレクトリの変更をレビューして。
特に以下を確認してほしい：
- セキュリティの問題（SQLインジェクション・XSS など）
- エラーハンドリングの漏れ
- テストカバレッジの不足"

レビュワーとしての確認ポイント

8. コンフリクトの解消手順

同じファイルを複数人が編集するとコンフリクト（競合）が発生します。落ち着いて以下の手順で解消しましょう。

コンフリクトが発生したら

# rebase 中にコンフリクトが発生した場合
git rebase origin/main

# コンフリクトしているファイルを確認
git status
# → "both modified: src/auth/login.ts" と表示される

# エディタでコンフリクト箇所を編集して解消
# ファイル内の以下のマーカーを手動で修正する：
# <<<<<<< HEAD（自分の変更）
# =======
# >>>>>>> origin/main（リモートの変更）

# 解消したファイルをステージング
git add src/auth/login.ts

# rebase を続行
git rebase --continue

Claude Code でコンフリクトを解消する

コンフリクトが複雑な場合は Claude Code に解消を依頼できます。

"src/auth/login.ts にコンフリクトが発生しています。
<<<<<<< と >>>>>>> のマーカーを確認して、
両方の変更を意図通りに統合する形で解消してください。
どちらの変更も失わないように注意してください。"

rebase を途中でやめたいとき

# rebase を中断して元の状態に戻す
git rebase --abort

9. Claude Code をチームで使うコツ

① CLAUDE.md を定期的にメンテナンスする

プロジェクトが進むと技術スタックや規約が変わります。古い情報が残った CLAUDE.md は Claude が誤った情報を参照する原因になります。月に1回、チームで CLAUDE.md の内容を見直す時間を設けましょう。

② Claude への指示をチームで共有する

「このプロンプトでうまくいった」という経験は Slack や Notion にメモを残してチーム全員に共有しましょう。特に効果的な指示パターンは CLAUDE.md の「よく使うプロンプト例」セクションにまとめておくのもおすすめです。

③ レビュー前に Claude にセルフチェックを依頼する

コードを書いたら人間のレビュアーに出す前に Claude Code にセルフチェックを依頼します。「このコードに問題がないか確認して」と依頼するだけで、バグ・セキュリティ問題・テスト不足を事前に発見できます。

④ Claude にテストコードを書かせる

「このファイルのテストを書いて」と依頼するだけで、Vitest や Jest の形式でテストコードを自動生成してくれます。テストカバレッジを上げる作業が格段に速くなります。

⑤ 個人設定は CLAUDE.local.md に書く

「自分はコメントを英語で書きたい」「自分の環境だけ別のポートを使う」といった個人差は CLAUDE.local.md に書きます。Git 管理外なのでリポジトリに影響せず、チームの共通設定と個人設定を明確に分離できます。

まとめ

Claude Code をチームで使う最大のポイントは「Claude への指示をファイルに書いて Git で共有する」ことです。CLAUDE.md と settings.json を整えるだけで、新メンバーも即日から同じ品質でコードを書けるようになります。

最初は「チームの共通ルールを文書化する作業」が少し面倒に感じるかもしれませんが、一度整えてしまえば後の作業が圧倒的に楽になります。まずは CLAUDE.md に「毎回説明していること」を3つ書くところから始めてみてください。