結論：Claude Codeのチーム導入は「運用設計」が9割
個人で使う分には最高だったClaude Codeを、5人チームに導入した瞬間に噴出した問題──その全てに対して今のところ機能しているルールを共有します。
先に結論を書きます。Claude Codeはツールとして優秀ですが、チームで使うと「誰がどこまで使っていいのか」「コストが青天井にならないか」「AI生成コードの品質は誰が担保するのか」という3つの問題が即座に発生します。 この記事では、3ヶ月の試行錯誤で定着した11のルールと、逆に失敗して撤廃した3つのルールを具体的に紹介します。
前提：チーム規模・技術スタック・導入前の開発フロー
| 項目 | 内容 |
|---|---|
| チーム人数 | 5人（バックエンド3人、フロントエンド2人） |
| 技術スタック | TypeScript / Next.js / NestJS / PostgreSQL |
| リポジトリ数 | モノレポ1つ + マイクロサービス3つ |
| 開発フロー | GitHub Flow（mainブランチ + featureブランチ） |
| CI/CD | GitHub Actions |
| Claude Code契約 | Max plan（5アカウント） |
導入前はCopilotをエディタ補完として使っていましたが、Claude Codeのように「タスク単位でコードを生成・修正できるエージェント」の導入は初めてでした。
ワークフロー全体像と11のルールの適用箇所
まず、現在のチーム開発ワークフロー全体を示します。各ステップにどのルールが関わっているかをアノテーションしています。
カテゴリ① 権限管理（ルール1〜3）
ルール1：リポジトリ単位のallowlist制
Claude Codeを使えるリポジトリを明示的にallowlistで管理しています。
理由： 導入初週に、本番DBのマイグレーションスクリプトを含むリポジトリでClaude Codeが意図しないスキーマ変更を提案し、危うくそのままPRが出るところでした。
# チームで管理している allowlist（社内Wiki管理）
allowed_repos:
- org/web-frontend # フロントエンド → 全員利用可
- org/api-server # バックエンド → バックエンドメンバーのみ
- org/shared-libs # 共有ライブラリ → テックリード承認制
denied_repos:
- org/infra-terraform # インフラ定義 → Claude Code利用禁止
- org/db-migrations # DBマイグレーション → Claude Code利用禁止
ルール2：--allowedTools による実行権限の段階管理
Claude Codeが実行できるツール（シェルコマンド、ファイル編集など）を段階的に制限しています。
// .claude/settings.json（リポジトリルートに配置）
{
"permissions": {
"allow": [
"Read",
"Edit",
"WebSearch"
],
"deny": [
"Bash(rm *)",
"Bash(docker *)",
"Bash(psql *)",
"Bash(npx prisma migrate deploy*)"
]
}
}
ポイント： denyを先に決めるのではなく、「何を許可するか」から設計しました。破壊的操作のdenylistは最低限のセーフティネットです。
ルール3：新メンバーは最初の2週間「読み取り専用モード」
新しくチームに入ったメンバーは、最初の2週間はClaude CodeをReadとWebSearchのみで利用します。
狙い： Claude Codeの出力傾向を理解してから書き込み権限を渡すことで、「AIが書いたコードの意味がわからないままPRを出す」事態を防いでいます。
カテゴリ② コスト管理（ルール4〜6）
ルール4：メンバー別の月額トークン消費上限
Max planではアカウント単位の利用状況を管理画面で確認できます。チームでは以下の目安を設定しています。
| ロール | 月額トークン目安 | 超過時の対応 |
|---|---|---|
| 一般メンバー | 〜$200相当 | テックリードに相談 |
| テックリード | 〜$350相当 | CTO判断 |
厳密な「ハードリミット」ではなく、週次ミーティングで消費量を共有する運用です。
ルール5：トークン消費の可視化
Claude Codeの利用状況を週次で可視化しています。
現時点ではAPIの利用量ダッシュボードを手動で集計していますが、今後はClaude Code CLIの--output-format jsonオプションを活用した自動集計を検討中です。
ルール6：「高コストタスク」の事前申請制
以下に該当するタスクは、着手前にSlackの#claude-code-opsチャンネルで事前申告します。
- 大規模リファクタリング（10ファイル以上の変更が見込まれる）
- 新規モジュールの0→1生成
- テストコードの一括生成（対象ファイル数が多いとトークンが膨らむ）
事前申告のテンプレートはこれだけです。
📋 高コストタスク申告
- タスク: [Jiraチケット番号]
- 想定変更規模: [ファイル数・行数の概算]
- 理由: [なぜClaude Codeに任せるのが妥当か]
- 承認者: [テックリードがスタンプで承認]
カテゴリ③ レビュー体制（ルール7〜9）
ルール7：AI生成コードにはai-generatedラベルを必ず付与
PRにai-generatedラベルを付けることで、レビュアーのレビュー観点を切り替えます。
これはGitHub Actionsで自動化しています。PR本文やコミットメッセージにClaudeやai-generatedのキーワードが含まれていれば自動でラベルを付与します。
# .github/workflows/ai-label.yml
name: Auto AI Label
on:
pull_request:
types: [opened, edited]
jobs:
label:
runs-on: ubuntu-latest
steps:
- uses: actions/github-script@v7
with:
script: |
const body = context.payload.pull_request.body || '';
const title = context.payload.pull_request.title || '';
const hasAiMarker = /claude|ai-generated|🤖/i.test(body + title);
if (hasAiMarker) {
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
labels: ['ai-generated']
});
}
ルール8：AI生成コードのレビューで見るべき3つのポイント
通常のレビューと「AI生成コードのレビュー」では、重点を置くポイントが異なります。
| 観点 | 通常のレビュー | AI生成コードのレビュー |
|---|---|---|
| ロジックの正しさ | 重要 | 最重要（もっともらしいが微妙に間違うことがある） |
| コーディングスタイル | 重要 | 中程度（CLAUDE.mdで制御済みのため） |
| 過剰実装の有無 | たまに見る | 必ず見る（AIは「聞かれてないことも実装する」傾向がある） |
| セキュリティ考慮 | 重要 | 最重要（入力バリデーションの漏れなど） |
| テストの妥当性 | 重要 | 最重要（テストが通るよう実装を歪めることがある） |
ルール9：AI生成PRのレビュアーは必ず「そのドメインを知る人間」
「AI生成コードだからサッと見ればいい」は真逆です。AIはドメイン知識なしにもっともらしいコードを書くため、ドメインを深く理解しているメンバーがレビューしないと、業務ロジックの微妙な誤りを見落とします。
具体例：あるAPIエンドポイントで、Claude Codeが「論理削除」を実装すべきところを「物理削除」で実装していたケースがありました。コードとしては完璧に動作しており、テストも通っていましたが、ビジネス要件上は誤りでした。
カテゴリ④ 品質担保（ルール10〜11）
ルール10：CLAUDE.mdのチーム共通テンプレート
CLAUDE.mdはClaude Codeに対するプロジェクト固有の指示ファイルです。個人ごとにバラバラだと出力品質がブレるため、チーム共通テンプレートをリポジトリルートに配置しています。
<!-- CLAUDE.md（チーム共通テンプレート・抜粋） -->
# プロジェクト規約
## コーディング規約
- 言語: TypeScript（strict mode）
- 命名: camelCase（変数・関数）、PascalCase（型・クラス）
- エラーハンドリング: Result型パターンを使用（throw禁止）
- ログ: pino を使用、console.logは使わない
## アーキテクチャ
- レイヤー構成: Controller → UseCase → Repository
- DIコンテナ: NestJSの標準DI
- DB操作: Prisma経由のみ（直接SQLは禁止）
## テスト
- ユニットテスト: vitest
- テストファイル命名: *.test.ts（*.spec.tsは使わない）
- モック: vi.mock()を使用
- カバレッジ: 新規コードは80%以上を目指す
## やってはいけないこと
- node_modules/ 配下の直接編集
- .env ファイルへのシークレット直書き
- any型の使用（やむを得ない場合はコメントで理由を明記）
ルール11：hooksによる自動品質チェック
Claude Codeのhooks機能を使い、コード生成の前後で自動チェックを実行しています。
// .claude/hooks.json
{
"PostEditHook": {
"command": "npx eslint --fix ${FILE} && npx prettier --write ${FILE}",
"description": "編集後に自動lint・フォーマット"
},
"PreCommitHook": {
"command": "npx vitest run --reporter=verbose --bail 1",
"description": "コミット前にテスト実行"
}
}
効果： hooks導入前は「Claude Codeが生成したコードがlintエラーだらけでCIが落ちる → 手動で修正」という手戻りが頻発していました。hooks導入後はPR段階でのlintエラーがほぼゼロになっています。
失敗したルール：2週間で撤廃した3つ
成功したルールだけ紹介しても片手落ちなので、導入したが機能しなかったルールも共有します。
❌ 失敗1：「AI生成コードは必ずペアレビュー（2人承認）」
意図： AI生成コードの品質を担保するため。
撤廃理由： レビュー待ちのボトルネックが深刻化しました。5人チームで2人承認を必須にすると、チームの40%がレビューに拘束されます。ルール8・9で「何を見るか」を明確にしたことで、1人レビューでも品質が維持できると判断しました。
❌ 失敗2：「Claude Codeのセッションログを全てSlackに自動投稿」
意図： 透明性の確保とナレッジ共有。
撤廃理由： ノイズが多すぎて誰も読まなくなりました。1回のセッションで数十メッセージのやり取りが飛ぶため、Slackチャンネルが埋もれます。現在は「PRの説明欄に要点を3行で書く」運用に落ち着いています。
❌ 失敗3：「1日のClaude Code利用時間を最大4時間に制限」
意図： AIに依存しすぎない開発スキルの維持。
撤廃理由： 「時間」で区切ることに意味がありませんでした。30分で高品質なコードが生成される場合もあれば、4時間かけても満足な結果が得られない場合もあります。コスト管理（ルール4〜6）で実質的に利用量はコントロールできているため、時間制限は不要でした。
運用3ヶ月の定量成果
導入前後の3ヶ月間の比較データです。
| 指標 | Before（導入前3ヶ月平均） | After（導入後3ヶ月平均） | 変化 |
|---|---|---|---|
| PR作成速度（起票→PR） | 2.1日 | 0.9日 | 57%短縮 |
| PR1件あたりのレビュー指摘数 | 3.2件 | 4.1件 | 28%増加 |
| レビュー指摘のうち重大な問題 | 0.8件 | 0.5件 | 37%減少 |
| 本番障害数 | 2件/月 | 1件/月 | 50%減少 |
| 月額コスト（Claude Code） | $0 | 約$800/チーム | — |
注目すべきはレビュー指摘数の増加です。 これは悪い数字ではありません。AI生成コードに対してレビュアーがより注意深く見るようになった結果、これまで見逃していた軽微な問題（命名の不統一、不要なnull チェックなど）も拾えるようになったためです。重大な問題の指摘数は減少しており、CLAUDE.mdとhooksによる事前品質チェックが効いていると考えています。
まとめ
- Claude Codeのチーム導入は「ツールの設定」ではなく「運用設計」が本丸。 allowlist・コスト管理・レビュー基準の3本柱を先に決めてから導入すべきです
- CLAUDE.mdとhooksを「チームの共通インフラ」として整備することで、個人差による品質のブレを大幅に減らせます。 個人のCLAUDE.mdに任せると、出力品質がメンバーごとにバラつきます
- 失敗ルールから学んだ最大の教訓は「過剰な統制はチームの速度を殺す」こと。 AIツールの導入で速度を上げたいのに、ガバナンスで速度を下げては本末転倒です