Claude Code チーム開発での使い方｜共有設定とベストプラクティス
Claude Code チーム開発 設定
チーム開発でClaude Codeを使う意義
個人開発でClaude Codeの威力を実感している方は多いでしょう。しかし、チーム開発で導入する際には、個人利用とは異なる課題があります。
- メンバー間でClaude Codeの出力品質にばらつきが出る
- コーディング規約に沿わないコードが生成される
- セキュリティ上のリスク管理が必要
- チーム全体のワークフローとの統合
この記事では、これらの課題を解決し、チーム全体の生産性を向上させるための方法を解説します。Claude Codeの基本的な使い方を理解していることを前提としています。
CLAUDE.md のチーム共有戦略
プロジェクトルートのCLAUDE.md
CLAUDE.mdをリポジトリのルートに配置し、Gitで管理します。これにより、チーム全員が同じコンテキストでClaude Codeを使用できます。
# プロジェクト名
## 技術スタック
- TypeScript 5.x
- React 19
- Next.js 15 (App Router)
- Prisma + PostgreSQL
- Vitest + Testing Library
## コーディング規約
- 変数名・関数名: camelCase
- コンポーネント名: PascalCase
- ファイル名: kebab-case
- インデント: スペース2つ
- セミコロン: 付けない
- 文字列: シングルクォート
## アーキテクチャ方針
- Server Componentsをデフォルトで使用
- データフェッチはServer Componentsで行う
- 状態管理はuseStateとuseReducerを優先（外部ライブラリは最小限）
- APIはRoute Handlers（app/api/）に集約
## テスト方針
- ユニットテスト: 全ユーティリティ関数に必須
- コンポーネントテスト: ユーザーインタラクションのあるコンポーネントに必須
- E2Eテスト: 主要ユーザーフローをカバー
## 禁止事項
- any型の使用（unknownを使う）
- console.logのコミット（デバッグ時のみ）
- 未使用のimportディレクトリ別のCLAUDE.md
大規模なプロジェクトでは、ディレクトリごとにCLAUDE.mdを配置することもできます。
project/
├── CLAUDE.md # プロジェクト全体の方針
├── src/
│ ├── components/
│ │ └── CLAUDE.md # コンポーネント設計の方針
│ ├── api/
│ │ └── CLAUDE.md # API設計の方針
│ └── lib/
│ └── CLAUDE.md # ユーティリティの方針プロジェクトレベルの設定
.claude/settings.json の共有
プロジェクト固有の設定を .claude/settings.json に記述し、Gitで管理します。
{
"permissions": {
"allow": [
"Read",
"Glob",
"Grep",
"Bash(npm run lint)",
"Bash(npm run test)",
"Bash(npm run build)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(git push --force)",
"Bash(npm publish)"
]
},
"hooks": {
"PostToolUse": [
{
"matcher": "Edit",
"command": "npx prettier --write $CLAUDE_FILE_PATH 2>/dev/null || true"
}
]
}
}カスタムスラッシュコマンドの共有
チーム共通のスラッシュコマンドを .claude/commands/ に配置します。
<!-- .claude/commands/code-review.md -->
以下のファイルの変更をレビューしてください。
チェック項目:
1. TypeScriptの型安全性（any型が使われていないか）
2. エラーハンドリングの適切さ
3. パフォーマンスの問題（N+1クエリ、不要な再レンダリング）
4. セキュリティ上の問題（SQLインジェクション、XSS）
5. テストの網羅性
対象: $ARGUMENTS<!-- .claude/commands/create-component.md -->
以下の要件でReactコンポーネントを作成してください。
ルール:
- TypeScriptで型定義を含める
- Tailwind CSSでスタイリング
- propsの型はinterfaceで定義
- Storybookのstoryファイルも作成
- ユニットテストも作成
要件: $ARGUMENTSチームワークフローへの統合
コードレビューでの活用
プルリクエストの作成前にClaude Codeでセルフレビューを行うワークフローを導入しましょう。
# PRを作成する前にセルフレビュー
git diff main...HEAD | claude -p "/project:code-review"ブランチ戦略との統合
1. featureブランチで開発（Claude Codeを活用）
2. Claude Codeでセルフレビュー
3. PRを作成
4. 人間によるコードレビュー
5. mainにマージCI/CDでの活用
Claude Code APIを使って、CI/CDパイプラインにClaude Codeを組み込むことも可能です。
# .github/workflows/ai-review.yml
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: AI Review
run: |
git diff origin/main...HEAD | claude -p "このdiffをレビューして、問題があればコメントして" > review.md
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}オンボーディングの効率化
新メンバーのオンボーディングにもClaude Codeは有効です。
CLAUDE.md にオンボーディング情報を含める
## 新メンバー向け
- 環境構築: `npm install && cp .env.example .env && npx prisma migrate dev`
- 開発サーバー: `npm run dev`（http://localhost:3000）
- テスト: `npm run test`
- このプロジェクトの概要をClaude Codeに質問してください新メンバーは Claude Code に「このプロジェクトの構造を説明して」と聞くだけで、CLAUDE.mdとコードベースを元にした説明が得られます。
セキュリティの考慮事項
チーム開発でClaude Codeを使う場合、セキュリティ面での配慮が重要です。
APIキーの管理
- APIキーは個人ごとに発行する
- 共有のAPIキーは使わない
- CI/CD用のキーはGitHub Secretsなどで管理する
機密情報の保護
.claudeignoreファイルで機密ファイルを除外する- 環境変数ファイル（.env）がClaude Codeに読まれないようにする
- 本番データベースへの接続情報を含むファイルを制限する
# .claudeignore
.env
.env.local
*.pem
*.key
credentials/チーム導入のステップ
- パイロット期間 - まず1〜2名のメンバーで試験導入する
- CLAUDE.md整備 - パイロット期間の知見をもとにCLAUDE.mdを整備する
- ガイドライン策定 - チームでのClaude Code利用ガイドラインを作成する
- 段階的展開 - チーム全体に展開し、定期的にCLAUDE.mdを更新する
まとめ
チーム開発でClaude Codeを効果的に使うには、CLAUDE.mdの共有と設定の統一が不可欠です。個人の生産性向上だけでなく、チーム全体のコード品質と一貫性を高めるツールとして活用しましょう。