結論：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ツールの導入で速度を上げたいのに、ガバナンスで速度を下げては本末転倒です

参考リンク