Claude Code攻略#Claude Code#チーム開発#ワークフロー
チームでClaude Codeを使うワークフロー
複数人でClaude Codeを使う際のCLAUDE.md共有、ブランチ運用、コードレビュー、ナレッジ蓄積の実践ガイド。
チームでClaude Codeを使うワークフロー
1人で使うClaude Codeと、チームで使うClaude Codeは運用が全く異なります。この記事では、3-10人規模のチームがClaude Codeを導入する際の実践的なワークフローを解説します。
この記事で学べること
- CLAUDE.mdをチーム設定ファイルとして設計する方法
- ブランチ戦略とコンフリクト回避
- AI生成コードのレビュー基準
- チーム全体のナレッジ蓄積の仕組み
- コスト管理と予算策定
- 新メンバーのオンボーディング
- よくあるトラブルと対処法
1. CLAUDE.mdをチームで共有する
CLAUDE.mdはプロジェクトのルートに置くチーム共有の設定ファイルです。全メンバーが同じルールでClaude Codeを使えるようになります。
チーム版CLAUDE.mdテンプレート
# CLAUDE.md（チーム版テンプレート）
## プロジェクト概要
- サービス名: ○○
- 技術スタック: Next.js 14, TypeScript, Tailwind CSS, PostgreSQL
- デプロイ先: Vercel
- 本番URL: https://example.com
## コーディング規約
- コンポーネント: 関数コンポーネント + TypeScript
- スタイル: Tailwind CSS（CSS Modulesは使わない）
- API: App Router の Route Handlers
- テスト: Playwright (E2E), Vitest (Unit)
- フォーマット: Prettier（設定は.prettierrcに従う）
## ディレクトリ構造
- app/ — ページとAPIルート
- components/ — 再利用可能なUIコンポーネント
- lib/ — ビジネスロジックとユーティリティ
- content/ — MDXコンテンツファイル
## やってはいけないこと
- .envファイルをコミットしない
- console.logを本番コードに残さない
- anyを使わない（unknown + type guardを使う）
- 既存のテストを削除しない
- package.jsonのバージョンを勝手に上げない
## ブランチ戦略
- main: 本番（直接pushしない）
- develop: 開発統合ブランチ
- feature/*: 機能ブランチ（1人1ブランチ）
## 過去の教訓（チームで蓄積）
- ここに日々の気づきを追記していく
CLAUDE.mdの管理ルール
| ルール | 理由 |
|---|---|
| Gitで管理する | 変更履歴が追える |
| PRレビュー対象にする | 全員が合意したルールになる |
| 月1回見直す | 古い教訓の削除、新しい教訓の追加 |
| 200行以内に保つ | 長すぎるとトークン消費が増える |
ポイント: CLAUDE.mdは「AIへの指示書」であると同時に「チームの暗黙知を形式知にするドキュメント」です。人間が読んでも有用な品質を保ちましょう。
2. ブランチ運用のルール
チームでClaude Codeを使う場合、ブランチ戦略が非常に重要です。
基本フロー
# 1. developから最新を取得
git checkout develop && git pull
# 2. featureブランチを作成
git checkout -b feature/add-user-profile
# 3. Claude Codeで実装
claude "ユーザープロフィールページを作って"
# 4. 変更を確認（diffを必ず見る）
git diff
# 5. コミット
git add -p # 変更を確認しながら段階的にステージング
git commit -m "Add user profile page"
# 6. PRを作成
gh pr create --title "Add user profile page" --base develop
絶対に守るルール
- 1ブランチ = 1人 — 同じブランチで複数人がClaude Codeを使うとコンフリクトが頻発する
- mainに直接pushしない — 必ずPRを経由する
git add -Aを避ける — Claude Codeが意図しないファイル（.envなど）を変更している可能性がある。git add -pで確認しながらステージング- 大きなタスクは分割する — 1つのPRが20ファイル以上になったら分割を検討
コンフリクトが起きたら
# developの最新を取り込む
git fetch origin
git rebase origin/develop
# コンフリクトを解消（Claude Codeに頼める）
claude "rebaseでコンフリクトが発生しました。解消してください"
3. コードレビューのポイント
Claude Codeが生成したコードは、人間が書いたコードと同じ基準でレビューします。加えて、AI特有のチェックポイントがあります。
AI生成コードのレビューチェックリスト
| チェック項目 | 確認内容 | よくある問題 |
|---|---|---|
| 不要なコメント | 説明過多ではないか | Claude Codeは「何をしているか」を大量にコメントする傾向 |
| 未使用import | 削除漏れがないか | コード修正時に使わなくなったimportが残る |
| テストの品質 | 実際に意味のあるテストか | expect(true).toBe(true) のような無意味なテスト |
| 秘密情報 | ハードコードされていないか | APIキー、パスワード、テスト用トークン |
| 依存パッケージ | 勝手に追加していないか | package.jsonに新しい依存が増えていないか |
| 型定義 | any が使われていないか | TypeScript strict modeの違反 |
| エラーハンドリング | catch節が空になっていないか | catch {} で握りつぶしていないか |
PRテンプレート（AI利用時）
## 概要
<!-- 何を実装したか -->
## Claude Code利用
- [ ] AI生成コードを手動レビュー済み
- [ ] テストが意味のあるアサーションを含む
- [ ] .envや秘密情報が含まれていない
- [ ] 不要なコメントを削除した
- [ ] package.jsonの変更がある場合は理由を記載
## テスト
<!-- テスト方法と結果 -->
4. ナレッジの蓄積
チームで使い続けると「この指示の出し方がうまくいく」というパターンが見つかります。これを組織の資産として蓄積する仕組みが重要です。
CLAUDE.mdに教訓を蓄積する
## 過去の教訓（チーム蓄積）
<!-- 新しいものを上に追加 -->
### 2026-04
- 「型を作って」→ interface/typeの両方が生成される → 「typeで統一して」を追加
- 画像最適化でnext/imageを提案 → 外部画像はdomains設定が必要。CLAUDE.mdに明記済み
- Tailwind v3とv4の構文を混ぜる → バージョンを明記したら解決
### 2026-03
- 大きなファイル（500行超）を一度に修正させると品質が落ちる → 関数単位で分割指示
- テスト生成時に「失敗するケースも含めて」と指示すると品質UP
プロンプトライブラリの共有
チームで効果的だったプロンプトをまとめておく:
# prompts/README.md（チーム共有プロンプト集）
## コードレビュー依頼
claude "このPRの変更を読んで、バグ・セキュリティ・パフォーマンスの観点でレビューして"
## テスト生成
claude "このファイルに対してPlaywrightテストを書いて。正常系3件、異常系3件。アサーションは具体的な値で"
## リファクタリング
claude "この関数を読んで、可読性を上げてリファクタリングして。ロジックは変えないで"
## ドキュメント生成
claude "このディレクトリのREADME.mdを作って。セットアップ手順、環境変数、開発コマンドを含めて"
5. コスト管理と予算策定
チームで使うと個人利用の3-10倍のコストがかかります。予算策定の参考にしてください。
利用パターン別の月額シミュレーション
| パターン | 内容 | Claude Pro | API (Sonnet) |
|---|---|---|---|
| ライト（5人） | 日に2-3回、簡単な質問 | $100/月 | $25-75/月 |
| ミドル（5人） | 日に5-10回、コーディング | $100/月（制限注意） | $150-400/月 |
| ヘビー（5人） | 終日利用、大規模開発 | $500-1,000/月（Max必要） | $500-1,500/月 |
コスト最適化の方針
- Claude Pro から始める — $20/人/月。まずは使い方を学ぶフェーズ
- ヘビーユーザーだけMax — 全員Maxにする必要はない。実際の利用量を見て判断
- API併用 — CI/CDのPRレビューなど自動化はAPI（Sonnet）を使う。安い
- 月次で利用量レビュー — Anthropic Consoleで実際の使用量を確認
6. 新メンバーのオンボーディング
新しいチームメンバーがClaude Codeを使い始めるための手順:
Day 1: セットアップ
# 1. Claude Codeインストール
npm install -g @anthropic-ai/claude-code
# 2. プロジェクトをクローン
git clone <repo-url> && cd <project>
# 3. Claude Codeを起動して動作確認
claude "このプロジェクトの構造を教えて"
Day 2-3: CLAUDE.mdとブランチ戦略を理解
- CLAUDE.mdを読む（チームのルールを理解）
- featureブランチでの作業フローを練習
- 最初のPRを出す（小さいタスクで）
Week 2: 本格運用
- レビューチェックリストを使ったコードレビュー経験
- プロンプトライブラリの活用
- 教訓のCLAUDE.md追記
よくあるオンボーディングの失敗
| 失敗 | 対策 |
|---|---|
| CLAUDE.mdを読まずに使い始める | Day 1のタスクに「CLAUDE.mdを読む」を必須にする |
| mainに直接pushする | ブランチ保護ルールをGitHubで設定 |
| 秘密情報をコミットする | .gitignoreの確認をセットアップ手順に含める |
| Claude Codeに丸投げ | 最初の1週間はペアプログラミング形式で使う |
7. よくあるトラブルと対処法
「Aさんの変更がBさんの作業と競合する」
原因: 同じファイルを同時に変更している 対処: 朝会で「今日触るファイル/機能」を共有する。影響範囲が重なる場合はペアで作業
「Claude Codeの回答品質がメンバーによって違う」
原因: プロンプトの出し方に個人差がある 対処: プロンプトライブラリを共有。「こう聞くとこう返ってくる」を標準化
「CLAUDE.mdが肥大化して読めない」
原因: 教訓を追加するだけで削除しない 対処: 月1回のCLAUDE.mdレビュー。古い教訓は別ファイル（lessons-archive.md）に移動
「コストが予算を超えた」
原因: ヘビーユーザーが想定以上に使っている 対処: Anthropic Console で個人別の使用量を確認。Max 5xへの移行を検討
まとめ: チーム導入の5原則
- CLAUDE.mdが唯一の真実 — ルールは会話ではなくファイルに書く
- 1ブランチ1人 — コンフリクトを物理的に防ぐ
- AI生成コードも必ずレビュー — AIを信頼しすぎない
- 教訓を蓄積する — 同じ失敗を繰り返さない仕組み
- コストを可視化する — 月次レビューで予算を守る