チーム開発で Claude Code を活用する
チームでのClaude Code導入、コードレビュー自動化、CI/CD統合のベストプラクティス。
- 読了目安
- 約30分
- 演習込み到達目安
- 2〜4週間（パイロット運用を含む）
実践ゴール
- 前提: 上級者向け学習パスを終え、個人環境で CLAUDE.md・Hooks・権限設定を検証できる
- 所要時間: 読了 約30分 / 演習込み 2〜4週間（パイロット運用を含む）
- 作るもの: チーム共有の
CLAUDE.md、品質ゲート、段階導入チェックリスト- 完了条件: パイロット対象の変更1件を共有ルールと品質ゲートに通し、改善点を記録できる
チーム開発における Claude Code の位置づけ
Claude Code は個人開発ツールとして強力だが、チーム開発に導入することでさらに大きな効果を発揮する。コードレビューの自動化、CI/CDパイプラインとの統合、共通の開発規約の徹底など、チーム全体の生産性を向上させられる。
個人利用とチーム利用の違い
| 側面 | 個人利用 | チーム利用 |
|---|---|---|
| CLAUDE.md | 個人の好み | チーム共通の規約 |
| Hooks | 個人の作業効率化 | 全員の品質保証 |
| MCP サーバー | 個人のツール連携 | 共通の外部サービス連携 |
| 設定管理 | ローカルのみ | Gitで共有 |
| セキュリティ | 自己責任 | 組織のポリシー準拠 |
チーム導入のステップ
Step 1: パイロットメンバーの選定
まず1-2名のパイロットメンバーで試験運用を行う。Claude Code に慣れているメンバーが最適だ。
パイロット期間の目安: 2-4週間
パイロットで確認すること:
- 既存のワークフローとの整合性
- セキュリティ上の懸念
- コスト（API利用料）の試算
- チームメンバーの学習コスト
Step 2: 共通 CLAUDE.md の作成
パイロットメンバーの知見をもとに、チーム共通の CLAUDE.md を作成する。
# プロジェクト名
## 概要
プロジェクトの説明
## 技術スタック
- 言語: TypeScript
- フレームワーク: Next.js 15
- テスト: Vitest + Playwright
- パッケージマネージャ: pnpm
## コマンド
- 開発: pnpm dev
- ビルド: pnpm build
- テスト: pnpm test
- リント: pnpm lint
## チーム規約
- PRには必ずテストを含める
- コンポーネントは named export
- エラーハンドリングは必須
## 注意事項
- 本番環境のシークレットは絶対にコミットしない
- テナント分離のルールを遵守する
Step 3: 共通 Hooks の設定
.claude/settings.json（プロジェクト設定）にチーム共通のフックを定義する。
推奨設定:
- 保存時フォーマット: 全員のコードスタイルを統一
- TypeScriptチェック: 型エラーの早期発見
- console.log 警告: デバッグコードの混入防止
- セキュリティスキャン: 機密情報の検出
Step 4: 段階的な展開
パイロットの成果をもとに、チーム全体へ展開する。
パイロット(1-2名) → 早期導入(3-5名) → 全チーム展開
2-4週間 2-4週間 継続
共通 CLAUDE.md の運用
ファイル構成
プロジェクトルート/
CLAUDE.md # チーム共通（Git管理）
CLAUDE.local.md # 個人設定（.gitignore）
.claude/
settings.json # プロジェクト設定（Git管理）
commands/ # 共通カスタムコマンド
review.md
test.md
rules/ # パススコープルール
api-routes.md
components.md
CLAUDE.md の更新フロー
- 提案: Issue または PR で変更を提案
- レビュー: チームメンバーで内容を確認
- 承認: メインブランチにマージ
- 反映: 次回セッションから自動的に適用
個人設定の分離
個人の好み（使用言語、好みのライブラリなど）は CLAUDE.local.md に記述し、Git 管理外とする。
# CLAUDE.local.md（.gitignoreに追加）
- 私はVim派なので、エディタ関連の提案はVim向けで
- 日本語で回答して
コードレビュー自動化
自動レビューの設定
Claude Code のカスタムコマンドとフックを組み合わせて、コードレビューの一部を自動化する。
<!-- .claude/commands/review.md -->
---
description: "コードレビューを実行"
allowed-tools: ["Read", "Grep", "Glob", "Bash"]
---
以下の観点でコードをレビューしてください:
1. バグの有無
- 境界値の処理
- null/undefined チェック
- エラーハンドリング
2. セキュリティ
- 入力バリデーション
- SQL インジェクション対策
- 機密情報の漏洩
3. パフォーマンス
- 不要な再レンダリング
- N+1 クエリ
- メモリリーク
4. 可読性
- 命名規則
- 関数の長さ
- 適切なコメント
対象: $ARGUMENTS
PR テンプレートとの連携
PR テンプレートに Claude Code によるレビュー項目を組み込む。
<!-- .github/pull_request_template.md -->
## 変更内容
<!-- 変更の概要 -->
## チェックリスト
- [ ] テストを追加・更新した
- [ ] ドキュメントを更新した
- [ ] CLAUDE.md の規約に従っている
- [ ] セキュリティ上の懸念がない
## Claude Code レビュー
<!-- /review コマンドでレビューを実行 -->
CI/CD パイプラインへの統合
GitHub Actions での利用
CI/CD パイプラインで Claude Code を利用する場合の設定例。
Claude Code は CLI ツールとして動作するため、GitHub Actions のランナー上でも実行可能。API キーは GitHub Secrets に保存し、環境変数として渡す。
自動化できること
| タイミング | 自動化内容 |
|---|---|
| PR 作成時 | 自動コードレビュー、セキュリティスキャン |
| マージ時 | 自動ドキュメント更新、CHANGELOG 生成 |
| 定期実行 | 依存関係の更新確認、 Dead code の検出 |
| デプロイ前 | 型チェック、テスト、ビルドの検証 |
セキュリティ上の注意
CI/CD で Claude Code を利用する場合、以下に注意する:
- API キーの管理: GitHub Secrets に保存し、ログに露出させない
- 権限の最小化: 必要最小限のツールのみ許可
- 実行結果の検証: Claude の出力をそのまま本番に反映しない
- コスト管理: CI/CD での API 利用料を監視
セキュリティとコンプライアンス
チーム向けセキュリティチェックリスト
- CLAUDE.md に機密情報を含めていない
- CLAUDE.local.md が .gitignore に含まれている
- Hooks で機密情報の検出を設定している
- MCP サーバーのトークンを環境変数で管理している
- CI/CD の API キーが Secrets に保存されている
- テナント分離のルールが CLAUDE.md に記載されている（マルチテナントの場合）
データの取り扱い
Claude Code にコードを分析させる際、以下のデータには注意する:
| データ種別 | 取扱い |
|---|---|
| 本番データ | 分析に使用しない |
| 顧客個人情報 | 絶対に Claude に送信しない |
| シークレット・APIキー | .env ファイルは分析対象外にする |
| テストデータ | フィクションデータのみ使用 |
想定シナリオ
以下は導入設計を具体化するための架空のシナリオであり、実在組織の実績ではない。効果を評価するときは、導入前後で同じ対象期間・母数・測定方法を使う。
シナリオ1: 小規模スタートアップ
プロジェクト: BtoB SaaS の MVP 開発チーム
課題: 新しいメンバーへの説明が属人化し、技術責任者にコードレビューが集中している
使用ツール: Claude Code + チーム共通 CLAUDE.md + OMC hooks
手順:
- CTO が CLAUDE.md にアーキテクチャ方針・コーディング規約・レビュー基準を集約
hooks/pre-commitで型チェック・lint・テストを自動実行（スキップ不可）- PR 作成時に
/oh-my-claudecode:reviewで自動レビューコメントを生成 - 新人は CLAUDE.md を読んで Claude Code に質問しながら既存コードを理解
期待する変化: 新しいメンバーが同じ情報源を参照でき、技術責任者は設計判断が必要なレビューへ集中しやすくなる。
シナリオ2: 複数職能を含む Web 開発チーム
プロジェクト: フロントエンド、バックエンド、QA で構成する EC プラットフォーム開発チーム
課題: チーム間でコードスタイルが統一されておらず、PR レビューが一部のシニアメンバーに偏っている
使用ツール: Claude Code + GitHub Actions CI/CD + OMC team + チーム共通 hooks
手順:
- モノレポに共通 CLAUDE.md を配置し、フロント・バックエンド別のサブ CLAUDE.md でオーバーライド
- GitHub Actions で PR 作成時に Claude Code の自動レビューを実行し、CRITICAL 指摘があればマージブロック
OMC teamでフロント・バックエンド・テストの3エージェントを並列起動し、大型機能をスプリント内で完結- ECC
harness-auditを週次 CI で実行し、設定の劣化を早期検出
期待する変化: 機械的な指摘を品質ゲートへ移し、人のレビューでは設計・仕様・リスクに集中しやすくなる。
シナリオ3: 複数チームを持つエンタープライズ
プロジェクト: 金融系 SaaS 企業の複数開発部門
課題: セキュリティ審査・コンプライアンス要件を各チームが個別管理しており、ルール適用漏れによるインシデントリスクがあった
使用ツール: Claude Code Enterprise Policy + 中央管理 CLAUDE.md + AgentShield + ECC
手順:
- Enterprise Policy でorganization 全体のルール（禁止コマンド・アクセス許可リスト）を中央設定
- セキュリティチームが
rules/tenant-isolation.mdとrules/security.mdを管理し、全チームの CLAUDE.md が@security-rules/を参照する構成に統一 - AgentShield を CI に組み込み、CLAUDE.md やフック設定の変更が Policy 違反になっていないか自動チェック
- コスト管理: チームごとに月額利用予算の上限を設定し、超過アラートを Slack に通知
期待する変化: 共通ポリシーの変更履歴と CI の監査結果が残り、チームごとの適用漏れを継続的に確認しやすくなる。
まとめ
チーム開発での Claude Code 導入は、「共通の文脈（CLAUDE.md）」「自動品質保証（Hooks）」「外部連携（MCPサーバー）」の3本柱で構成する。段階的な導入とチーム内でのナレッジ共有が成功の鍵だ。
エージェントチームオーケストレーションについては、エージェントチームオーケストレーションで詳しく解説しています。OMC team パイプラインについては、OMC team パイプラインで詳しく解説しています。GitHub Actions CI/CD については、GitHub Actions CI/CDで詳しく解説しています。
関連ガイド:
- CLAUDE.md 完全ガイド - CLAUDE.md の書き方の詳細
- Hooks で作業を自動化する - フック設定の詳細
- MCP サーバーで機能を拡張する - MCP設定の詳細
- 上級者向け学習パス - さらなる高度な活用
リファレンス
- Claude Code 公式ドキュメント
- 中級者向け学習パス - ワークフローとスキルの活用