Claude Code でチーム開発やってみよう！具体的な手順全部公開

SHARE

こんにちは！今回は Claude Code を使って、実際に複数人でシステム開発する時のやり方をガッツリ解説していきます。

「AI にコード書かせるのって 1 人でやるもんでしょ？」って思ってる方、実はチームで使った方がめっちゃ効率的なんです。今日はその具体的なやり方を、明日から真似できるレベルで紹介しますね。

まず全体像を把握しよう

チーム開発の流れはこんな感じです。

  1. 環境準備：Git と CLAUDE.md を整える
  2. 役割分担：AI に PM・開発・レビューを割り当てる
  3. 計画フェーズ：設計してタスクを細かく切る
  4. 実装フェーズ：ブランチ分けて並列で進める
  5. 検証・マージ：テストして OK ならマージ

「なんか難しそう…」って思った？大丈夫、1 つずつ見ていけば簡単だから。

1. 環境準備：土台を固めよう

Git リポジトリを作ろう

まずはチーム全員で使う Git リポジトリを用意します。

mkdir my-project
cd my-project
git init
git checkout -b main
git checkout -b develop

これだけで OK。main ブランチと develop ブランチを作っておけば、あとは機能ごとにブランチを分けていけばいいだけ。

CLAUDE.md を作るのが超重要

ここが一番のポイントなんだけど、CLAUDE.md というファイルをプロジェクトのルートに作ります。これ、チーム全員で共通のルールを書いとく場所なんです。

# プロジェクト概要
- 技術スタック: Python 3.11, FastAPI, PostgreSQL
- ビルドコマンド: pip install -r requirements.txt
- テストコマンド: pytest tests/

# 開発ルール
- 型ヒントは必須
- docstring は Google 形式
- 変更時は必ずテストを追加
- 禁止: グローバル変数、print デバッグの本番残し

# 権限制御
- 本番 DB 書き込み禁止
- 外部 API キーは環境変数のみ

これを作っておくと、どの AI に聞いても同じルールでコードを書いてくれるから、コードの統一性が保てるんです。

settings.json も作っておこう（任意）

チーム全体で「このコマンドは実行させたくない！」ってのがあるなら、.claude/settings.json を作ります。

{
  "permissions": {
    "allowedCommands": ["git", "pytest", "ruff"],
    "blockedCommands": ["rm -rf", "DROP TABLE"]
  }
}

これで危ないコマンドを実行しようとした時に止めてくれます。

2. 役割分担：AI に役職を与えよう

ここが面白いところなんだけど、Claude Code って1 つのプロジェクトに複数人（？）の AI を配置できるんです。

例えばこんな感じで役割を分けます。

役割担当
PM/設計要件整理、設計ドキュメント作成
開発 Aフロントエンド実装
開発 Bバックエンド実装
レビューコードレビュー、セキュリティチェック
テスト単体テスト・結合テスト作成

「AI に役職？」って思うかもだけど、実際に「あなたは PM として振る舞って」って指示すると、ちゃんと PM っぽい動きをしてくれるんです。

並列セッションの作り方

ターミナルを複数開いて、それぞれ別の AI セッションとして使います。

# ターミナル 1: PM 用
claude --name pm

# ターミナル 2: 開発 A 用
claude --name dev-a

# ターミナル 3: レビュー用
claude --name review

シェルエイリアスを作るともっと楽になります。

# .bashrc または .zshrc に追加
alias za="claude --name dev-a"
alias zb="claude --name dev-b"
alias zc="claude --name review"

これで za と打つだけで開発 A のセッションに切り替えられるから、めっちゃ快適。

3. 計画フェーズ：設計から始めよう

ステップ 1: PM に要件を渡す

まずは PM 役の AI に、要件を渡して設計ドキュメントを作らせます。

【要件】
- ユーザー管理機能（登録、ログイン、プロフィール編集）
- 認証は JWT 使用
- フロントは React、バックは FastAPI

【制約】
- 2 週間以内に MVP 完成
- チーム 3 名（PM1、開発 2）

ここで重要なのが、「コードは書かずに設計だけして」って伝えること。

あなたは PM 兼テックリードです。
上記要件をもとに、以下のドキュメントを docs/plans/01_design.md として作成してください：

1. システムアーキテクチャ図（ASCII で可）
2. 使用する技術スタックの選定理由
3. 主要コンポーネントの責務
4. リスクと対策
5. 2 週間のマイルストーン

※ コードは書かないでください。設計のみです。

こうすると、AI がいきなりコードを書き始めるのを防げて、後々の手戻りが激減します。

ステップ 2: 実装担当にタスクを切らせる

設計ドキュメントができたら、次は実装担当の AI にタスクを細かく切らせます。

docs/plans/01_design.md を参照して、以下のタスクに分解してください：

- タスク 1: ユーザーモデルと DB スキーマ作成
- タスク 2: 認証 API（登録、ログイン）実装
- タスク 3: フロントエンドのログイン画面
- タスク 4: プロフィール編集機能

各タスクについて：
- 対象ファイル
- 依存関係
- 検証方法（テストコマンド）
- 見積工数（時間）

を docs/plans/02_tasks.md として出力してください。

これで「誰が何をやるか」が明確になります。

ステップ 3: 他 AI にレビューさせる（余裕があれば）

もっとクオリティを上げたい時は、別の AI に「シニアエンジニアとしてレビューして」ってお願いするのもアリ。

あなたはテックリードです。
docs/plans/02_tasks.md の実装計画をレビューしてください。

以下の観点で指摘をお願いします：
1. 技術的リスク
2. 見落としのあるテストケース
3. セキュリティ上の懸念
4. パフォーマンス上の問題

指摘があれば、具体的な修正案を提示してください。

4. 実装フェーズ：並列で進めよう

Git 運用の基本ルール

各タスクは必ず別ブランチで作業します。

# タスク 1: ユーザーモデル作成
git checkout develop
git checkout -b feature/user-model

# 実装後
git add .
git commit -m "feat: add user model and migration"
git push origin feature/user-model

これ、超基本なんだけど意外とやらない人がいるので注意。

ワークツリーを使うとさらに便利（上級者向け）

複数の機能を同時に進めたい時は、Git ワークツリーが便利です。

cd my-project

# ワークツリー作成（機能 A 用）
git worktree add ../my-project-feature-a feature/user-model

# ワークツリー作成（機能 B 用）
git worktree add ../my-project-feature-b feature/auth-api

これで同じリポジトリを複数ディレクトリで同時に編集できるから、ブランチの切り替えがめっちゃ楽になります。

実装時のコツ

各開発 AI には、以下のルールを守らせます。

  • 1 チャット 1 タスク: 1 つのセッションでは 1 つのタスクだけ
  • コンテキスト制限: 500k トークンを超えたら新規セッション
  • 差分の読み合わせ: 実装後は必ず git diff で変更内容を確認
  • ドキュメント更新: 設計変更は必ず docs/ に記録
あなたはバックエンド開発担当です。
docs/plans/02_tasks.md の「タスク 1: ユーザーモデル」を実装してください。

【ルール】
1. 作業前に現在のコードベースを /ls で確認
2. 変更ファイルは 5 個以内に抑える
3. 実装後は必ず pytest tests/test_user.py を実行
4. 失敗した場合は /edit で CLAUDE.md を更新して再発防止

5. 検証・マージ：品質ゲートを設けよう

自動テストの実行

実装が終わったら、テスト担当の AI に検証を依頼します。

あなたは QA エンジニアです。
feature/user-model ブランチの変更をレビューし、以下の検証を行ってください：

1. 既存テストの実行: pytest tests/
2. カバレッジ確認: pytest --cov=src tests/
3. Lint チェック: ruff check src/
4. 型チェック: mypy src/

すべて合格したら、PR 作成の準備をしてください。

PR レビューフロー

GitHub を使っている場合、こんなフローがおすすめ。

  1. 開発者が feature ブランチを push
  2. GitHub で Pull Request 作成
  3. レビュー AI に「/review_pr #123」と指示
  4. 指摘事項を修正
  5. 承認後、develop ブランチへマージ

マージ後のスモークテスト

マージしたら、最後に全体動作を確認します。

develop ブランチにマージされました。
以下のスモークテストを実行してください：

1. アプリ起動: uvicorn src.main:app --reload
2. ユーザー登録 API に POST
3. ログイン API でトークン取得
4. プロフィール取得 API で 200 OK を確認

すべて成功したら、main ブランチへのマージを提案してください。

失敗から学ぶ：CLAUDE.md を育てよう

ここが一番大事なんだけど、AI がミスしたら CLAUDE.md に記録させること。

先ほどのミス（型ヒント忘れ）を再発防止するために、
CLAUDE.md の「開発ルール」セクションを更新してください。

具体的には：
「すべての関数・メソッドに型ヒントを必須とする。
 違反時は ruff check でエラーとする」

というルールを追加してください。

こうすると、チームの CLAUDE.md がどんどん賢くなっていくんです。

よくある失敗と対策

失敗パターン原因対策
1 人に全部任せて品質低下役割分担なしPM/開発/レビューを別 AI に
設計変更がドキュメントに反映されない会話内に決定事項必ず docs/plans/ に記録させる
トークン切れで文脈喪失1 チャット長期使用500k でセッション分割、docs 参照
権限管理が甘いsettings.json 未設定禁止コマンドを明示、フックで事前チェック

4 週間導入ロードマップ

チーム導入は、以下の 4 週間計画で進めるのがおすすめ。

週次目標具体的产出
第 1 週パイロット導入1 チームで CLAUDE.md・権限ルールを試行
第 2 週ガイドライン整備settings.json テンプレート・禁止コマンド一覧を作成
第 3 週全チーム展開managed settings 配布・ダッシュボードで採用率監視
第 4 週改善サイクル失敗事例を CLAUDE.md に反映・Skills 追加

最後に

Claude Code のチーム開発で一番大事なのは、「複数 AI 並列＋Git 運用＋検証フロー」の 3 つです。

  1. CLAUDE.md で共通ルールを定義
  2. PM/開発/レビュー/テストに役割分担
  3. Plan モードで設計→タスク分解
  4. ブランチ/ワークツリーで並列実装
  5. 自動テスト→PR レビュー→マージ

まずは 1 チームで試してみて、失敗事例を CLAUDE.md に蓄積しながら改善を繰り返してみてください。

「AI と一緒にチーム開発」って最初は不思議な感じするけど、慣れるとめっちゃ快適ですよ！

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です


上の計算式の答えを入力してください

CAPTCHA


前の記事

Excelを使って、大量のデータを活用する方法