ClassLab Engineering の Dev チームメンバーが執筆しました。
「個人で使ってみた」記事は山ほどあります。でも、チーム全員がAIコーディングツールを使い、運用ルールを整備し、定量的に効果を測定している事例は、まだ少ないのではないでしょうか。
私たちClassLabは、10名のエンジニアチーム全員がClaude CodeとGitHub Copilotを日常業務で使っています。この記事では、チーム導入の設計判断、独自の成熟度モデル、3層アーキテクチャの全容、そして3ヶ月間の定量結果を包み隠さず公開します。
読者が持ち帰れるものとして、AI駆動開発 成熟度モデル（5段階）のセルフチェックシートと、Claude Code設定テンプレートを記事末尾に用意しました。
目次
- 背景 — なぜチーム全体でAIツールを導入したか
- 課題 — 導入前の5つの痛み
- 設計 — 2つのツールの使い分けと3層アーキテクチャ
- 実装 — 3フェーズの展開と運用ルール
- 結果 — 3ヶ月間の定量・定性データ
- AI駆動開発 成熟度モデル — チームの現在地を測る
- うまくいかなかったこと — 正直な失敗談5選
- 展望 — 次に取り組むこと
- 導入テンプレート — 明日から使える設定ファイル
1. 背景 — なぜチーム全体でAIツールを導入したか
ClassLabはライフライン（電気・ガス）の取次事業を基盤に、年間15万件の申込処理を支えるシステムを自社開発しています。エンジニアは約10名。少人数で複数の新規事業（AI音声研修、コールセンター自動化、不動産テック向けモバイルアプリなど）を同時に開発しています。
2025年後半、2つの限界に直面しました。
限界①: 開発速度がビジネスの成長に追いつかない
新規事業の立ち上がりが加速する一方、エンジニアの頭数は増えない。採用は半年〜1年かかる。「今いるメンバーの生産性を2倍にする」以外に解がなかったのが正直なところです。
限界②: AI活用が属人化していた
一部のメンバーがGitHub Copilotを使い始めていましたが、活用レベルはバラバラでした。
graph LR
A[メンバーA: コード補完のみ] --> X[ナレッジが分散]
B[メンバーB: テスト生成に活用] --> X
C[メンバーC: 未使用] --> X
X --> Y[チームとしての学習が進まない]
「あの人はAIをうまく使えている」という属人的な状態では、チーム全体の生産性は上がりません。AI活用を個人の好みからチームのインフラに引き上げる——これが全体導入の出発点でした。
2. 課題 — 導入前の5つの痛み
AIツール導入前のチームの状態を、5つの指標で定量化しました。
| # | 指標 | 導入前の値 | 痛みの本質 |
|---|---|---|---|
| 1 | コードレビュー待ち時間 | 平均4.2時間 | レビュアーのキャパがボトルネック。PRを出してから半日放置が常態 |
| 2 | ドキュメント作成時間 | 1件あたり3-5時間 | 設計書・議事録・運用手順書が溜まり続ける |
| 3 | テストカバレッジ | 42% | 「テストを書く時間がない」が口癖に |
| 4 | バグ修正の初動 | 平均1.5営業日 | 原因調査に時間がかかり、修正着手が翌日以降に |
| 5 | 1人あたり月間PR数 | 12件 | 月20営業日で12件 = 1.7日に1件。機能開発に手が回らない |
最も致命的だったのは①コードレビューの待ち時間です。
10名のチームでは、レビュアーに割ける人数が限られます。PRを出してから「見ました」の返事が来るまで4時間。修正指摘が入ればさらに1ラウンド。この待ち時間がデプロイ頻度のボトルネックになっていました。
graph TD
PR[PR作成] -->|待ち 4.2h| R1[レビュー1回目]
R1 -->|修正 1-2h| FIX[修正コミット]
FIX -->|待ち 2-3h| R2[レビュー2回目]
R2 --> MERGE[マージ]
style PR fill:#ef4444,color:#fff
style R1 fill:#f59e0b,color:#fff
style R2 fill:#f59e0b,color:#fff
style MERGE fill:#10b981,color:#fff
PR作成からマージまで平均7-9時間。 1日に1回のデプロイがやっとでした。
3. 設計 — 2つのツールの使い分けと3層アーキテクチャ
GitHub Copilot × Claude Code の役割分担
検討の結果、GitHub CopilotとClaude Codeを併用する方針に決めました。同じ「AIコーディングツール」ですが、得意領域がまったく異なります。
| 観点 | GitHub Copilot | Claude Code |
|---|---|---|
| 一言で言うと | 手を速くするツール | 頭を増やすツール |
| 主な用途 | コード補完・インライン生成 | マルチファイル編集・設計・レビュー・分析 |
| 作業粒度 | 行〜関数レベル | ファイル〜プロジェクトレベル |
| 使うタイミング | コーディング中（常時ON） | 設計・レビュー・調査・ドキュメント作成 |
| 得意なこと | パターンベースの高速補完 | 推論・対話・複数ステップの作業 |
| 苦手なこと | 複数ファイルの整合性 | リアルタイムの行単位補完 |
「Copilotで書いて、Claude Codeでレビューする」 ——この分業が私たちの基本パターンです。
Claude Code 3層アーキテクチャ
Claude Codeをインストールしただけでは「便利なチャットボット」止まりです。チームで本格運用するために、以下の3層でカスタマイズしています。
graph TB
subgraph L3["Layer 3: 外部連携（MCP サーバー 10+接続）"]
SF[Salesforce]
SL[Slack]
AS[Asana]
PW[Playwright]
GA[Google Analytics]
OTHER[その他 5+]
end
subgraph L2["Layer 2: 専門家（エージェント 15+種 / スキル 25+種）"]
CR[code-reviewer]
SR[security-reviewer]
AR[architect]
TD[tdd-guide]
PL[planner]
VF[verifier]
QA[qa-evaluator]
TR[tracer]
end
subgraph L1["Layer 1: 基盤（ルール + フック + パーミッション）"]
RULES[ルールファイル群
500+行]
HOOKS[フック
3イベント]
PERM[許可ツール
100+]
end
L3 --> L2
L2 --> L1
それぞれの層を詳しく解説します。
Layer 1: 基盤 — ルール・フック・パーミッション
全プロジェクト共通のコーディング規約・セキュリティルール・テスト要件をMarkdownファイルで定義しています。Claude Codeはこれらを常に参照し、ルールに従ったコードを生成します。
ルールファイルの構成:
| ファイル | 行数 | 役割 |
|---|---|---|
agents.md |
~90行 | エージェント一覧・使い分け・並列実行ルール |
coding-style.md |
~50行 | イミュータブルパターン必須・ファイル800行上限 |
development-workflow.md |
~100行 | リサーチ→計画→TDD→レビュー→コミットの順序 |
security.md |
~30行 | コミット前チェックリスト8項目・シークレット管理 |
testing.md |
~30行 | TDD必須・80%カバレッジ・テストタイプ3種 |
performance.md |
~130行 | モデル選定・コンテキスト管理・ハーネス簡素化 |
git-workflow.md |
~25行 | Conventional Commits・PR作成手順 |
patterns.md |
~30行 | Repository Pattern・API Response Format |
hooks.md |
~30行 | フック設計・TodoWrite活用 |
重要な設計判断: ルールをAI自身が読めるフォーマットで書く
人間が読んで理解するドキュメントと、AIが参照して従えるルールは別物です。私たちのルールファイルは、Markdownの表形式で条件→アクションを明示しています。
# 例: coding-style.md の一部
## Immutability (CRITICAL)
ALWAYS create new objects, NEVER mutate existing ones.
## File Organization
MANY SMALL FILES > FEW LARGE FILES:
- 200-400 lines typical, 800 max
- Extract utilities from large modules
「CRITICAL」「ALWAYS」「NEVER」といったキーワードでAIに優先度を伝え、曖昧な表現を排除しています。
フック（自動化の要）:
Claude CodeのHooks APIを活用し、特定のアクションの前後で自動処理を実行しています。
// settings.json のフック設定（簡略化）
{
"hooks": {
"PostToolUse": [
{
"matcher": { "toolName": "slack_reply_to_thread" },
"command": "python post_sync.py"
// Slack投稿後に自動でタスク管理システムと同期
}
],
"UserPromptSubmit": [
{
"command": "python prompt_validator.py"
// 送信前にプロンプトの品質を自動チェック
}
],
"SessionStart": [
{
"command": "python session_init.py"
// セッション開始時にプロジェクト文脈を自動読み込み
}
]
}
}
フックにより「Slackにメッセージを送ったら自動でタスク管理と同期」「セッション開始時にプロジェクトの進捗を自動で読み込み」といった処理が、開発者の意識なく動作します。
Layer 2: 専門家 — エージェントとスキル
用途別のエージェントを15種類以上、スキルを25種類以上用意しています。
主要エージェント一覧:
| エージェント | 役割 | 使用タイミング |
|---|---|---|
code-reviewer |
コード品質の静的レビュー | コード変更後（必須） |
security-reviewer |
セキュリティ脆弱性の検出 | コミット前（必須） |
architect |
システム設計・スケーラビリティ | 新機能・リファクタリング |
tdd-guide |
テスト駆動開発のガイド | 新機能・バグ修正 |
planner |
実装計画の策定 | 複雑な機能開発 |
verifier |
品質主張の証拠ベース検証 | 「テスト通った」等の主張時 |
qa-evaluator |
Playwright経由のUI/UXテスト | フロントエンド変更後 |
tracer |
仮説駆動デバッグ | バグ修正が3回失敗した後 |
build-error-resolver |
ビルドエラーの自動修正 | ビルド失敗時 |
エージェント運用の最も重要なルール: 生成者と評価者の分離
これが私たちの核心的な設計原則です。コードを生成したセッション（エージェント）が、自分の成果物を評価してはならない。
なぜか？ 自己評価は常にバイアスがかかるからです。AIエージェントであっても、自分が生成したコードに対しては「良さそう」「動くはず」という楽観的な判断をしがちです。
graph LR
GEN[コード生成
メインセッション] -->|別エージェント起動| CR[code-reviewer
品質チェック]
CR -->|別エージェント起動| SR[security-reviewer
セキュリティ]
SR -->|人間へ| HUMAN[人間のレビュー
最終判断]
style GEN fill:#3b82f6,color:#fff
style CR fill:#8b5cf6,color:#fff
style SR fill:#ef4444,color:#fff
style HUMAN fill:#10b981,color:#fff
AIの出力を別のAIがレビューし、その結果を人間が最終判断する。この3段階の評価チェーンが、AI活用で品質を落とさない仕組みです。
例外ルール: git diff --stat の変更行数が10行以下かつ既存テスト全PASSの場合はセルフチェック可。ただしセキュリティ関連は行数に関係なく必ず別エージェントレビュー必須。
Layer 3: 外部連携 — MCPサーバー
10以上のMCPサーバーを接続し、Claude Codeから直接業務システムを操作できるようにしています。
| MCPサーバー | 用途 | 主な操作 |
|---|---|---|
| Salesforce | 顧客データ分析 | レポート取得・SOQL実行 |
| Slack | チームコミュニケーション | メッセージ検索・投稿 |
| Asana | タスク管理 | タスク作成・更新・検索 |
| Playwright | E2Eテスト・QA | ブラウザ操作・スクリーンショット |
| Google Analytics | アクセス解析 | レポート取得・ファネル分析 |
| Context7 | ライブラリドキュメント | 最新API仕様の参照 |
| NotebookLM | ナレッジベース | 社内ドキュメント検索 |
MCPの最大の価値はコンテキストスイッチの削減です。「Salesforceのこのレポートを取得して分析して」「Slackのこのスレッドの議論を要約して」——こうした指示がClaude Codeの中で完結します。
4. 実装 — 3フェーズの展開と運用ルール
Phase 1: 環境標準化（1週間）
まず全員の開発環境を統一しました。Claude Codeのカスタマイズ設定をGitリポジトリで管理し、git pull一発で全員の環境を同期できるようにしました。
# 共有設定の構造（gitで管理）
~/.claude/
├── agents/ # 15+種のエージェント定義
│ ├── code-reviewer/
│ ├── security-reviewer/
│ ├── architect/
│ ├── tdd-guide/
│ └── ...
├── rules/ # 共通ルールファイル群（9ファイル / 500+行）
│ ├── coding-style.md
│ ├── security.md
│ ├── testing.md
│ └── ...
├── skills/ # 25+種のスキル
│ ├── wp-post/ # WordPress投稿
│ ├── salesforce-cx-ops/
│ └── ...
└── settings.json # フック + パーミッション設定
新しいエージェントやルールの追加はPRベースでレビューします。ルールの変更はプロダクトコードと同じ品質基準でレビューする——これが環境の品質を維持する秘訣です。
Phase 2: ペアプログラミング移行期間（2週間）
いきなり全員に「Claude Codeを使え」と言っても、使いこなせる人と使えない人に分かれます。最初の2週間はペアプロ期間として、以下の取り組みを行いました。
ペアプロのルール: – AI活用に慣れたメンバー(リード)と、まだ使い始めのメンバー(ジュニア)でペアを組む – リードは自分の操作を見せるのではなく、ジュニアにClaude Codeを操作させる – 「この場面ではCopilot」「この場面ではClaude Code」の判断基準を言語化して共有 – つまずきポイントは即座にSlackの共有チャンネルに投稿
2週間で見えてきたパターン:
| 場面 | 推奨ツール | 理由 |
|---|---|---|
| 関数の実装 | Copilot | パターンマッチが速い |
| テスト作成 | Claude Code | 仕様理解→テスト設計→実装の複数ステップが必要 |
| コードレビュー | Claude Code (code-reviewer) | 複数ファイルの文脈理解が必要 |
| バグ修正 | Claude Code (tracer) | 仮説生成→検証の繰り返しが必要 |
| API設計 | Claude Code (architect) | トレードオフの議論が必要 |
| リファクタリング | Copilot + Claude Code | Copilotでインライン変更、Claude Codeで整合性確認 |
| ドキュメント作成 | Claude Code | 構造化された長文生成が得意 |
Phase 3: 運用ルールの確立（継続的改善）
使い始めて見えてきた問題に対して、ルールを段階的に追加していきました。
| 発見された問題 | 発見時期 | 対策ルール |
|---|---|---|
| AIが既存コードと異なるスタイルで書く | 1週目 | coding-style.md: イミュータブルパターン必須、ファイル800行上限 |
| セキュリティ的に危険なコードが生成される | 2週目 | security.md: コミット前チェックリスト8項目 |
| テストを省略しがち | 2週目 | testing.md: TDD必須、80%カバレッジ |
| レビューが形骸化する | 3週目 | agents.md: 生成者と評価者の分離原則 |
| エージェントの使い分けが不明確 | 4週目 | agents.md: 場面別の即時エージェント使用ガイド |
| コンテキストウィンドウの枯渇 | 6週目 | performance.md: モデル別コンテキスト戦略 |
| ルール自体の肥大化 | 8週目 | performance.md: 四半期棚卸しプロセス |
開発ワークフロー全体の標準化:
graph TD
START[タスク受領] --> RESEARCH[0. リサーチ & 再利用
既存実装を検索]
RESEARCH --> PLAN[1. 計画
planner エージェント]
PLAN --> TDD[2. TDD
tdd-guide エージェント]
TDD --> RED[テスト作成 RED]
RED --> GREEN[実装 GREEN]
GREEN --> REFACTOR[リファクタリング]
REFACTOR --> CR[3. code-reviewer
品質レビュー]
CR --> SR[4. security-reviewer
セキュリティ]
SR --> HUMAN[5. 人間レビュー]
HUMAN --> COMMIT[6. コミット & プッシュ]
style RESEARCH fill:#3b82f6,color:#fff
style PLAN fill:#8b5cf6,color:#fff
style TDD fill:#f59e0b,color:#fff
style CR fill:#8b5cf6,color:#fff
style SR fill:#ef4444,color:#fff
style HUMAN fill:#10b981,color:#fff
5. 結果 — 3ヶ月間の定量・定性データ
定量結果
導入から3ヶ月後の数値です。
| # | 指標 | 導入前 | 導入後 | 改善 |
|---|---|---|---|---|
| 1 | コードレビュー待ち時間 | 4.2時間 | 1.1時間 | -74% |
| 2 | ドキュメント作成時間 | 3-5時間/件 | 0.5-1時間/件 | -80% |
| 3 | テストカバレッジ | 42% | 78% | +36pt |
| 4 | バグ修正の初動 | 1.5営業日 | 0.3営業日 | -80% |
| 5 | 1人あたり月間PR数 | 12件 | 28件 | +133% |
計測方法: GitHub Insights + 社内ダッシュボード（claude-activity-tracker）による3ヶ月平均値。PR数にはドキュメント更新・設定変更を含む。
①コードレビュー待ち時間 -74% の内訳:
graph TD
subgraph BEFORE["導入前: 平均7-9時間"]
B1[PR作成] -->|待ち 4.2h| B2[人間レビュー1回目]
B2 -->|修正 1-2h| B3[修正コミット]
B3 -->|待ち 2-3h| B4[人間レビュー2回目]
B4 --> B5[マージ]
end
subgraph AFTER["導入後: 平均2-3時間"]
A1[PR作成] -->|即時| A2[code-reviewer
自動一次レビュー]
A2 -->|修正 0.5h| A3[修正コミット]
A3 -->|待ち 1.1h| A4[人間レビュー
AIレビュー結果付き]
A4 --> A5[マージ]
end
ポイントは2つあります:
- AI一次レビューが即時に完了する: code-reviewerエージェントがPR作成直後にレビューを実行。人間のレビュアーが見る時点で、スタイル違反・セキュリティ問題・テスト不足はすでに解消されている
- 人間のレビューが軽くなる: AIが既にチェックした項目は人間がスキップできるため、レビュー1回で完了するケースが大幅に増加
定性的な変化
ジュニアメンバーの立ち上がりが速くなった
新メンバーが入社してから最初のPRを出すまでの期間が、約2週間から3日に短縮しました。エージェントがペアプロ相手になるため、シニアメンバーの「教える時間」が減りました。
特に効果が大きかったのはtdd-guideエージェントです。「まずテストを書いて、それが通る最小限のコードを書く」というTDDのサイクルを、エージェントが繰り返しガイドしてくれます。
ドキュメントの質と量が劇的に改善
「時間がないから書かない」がなくなりました。Claude Codeでの設計書・議事録・手順書の作成が日常化し、3ヶ月で50以上のドキュメントが生まれました。これは導入前の1年分に匹敵します。
セキュリティが「事後確認」から「事前確認」に
security-reviewerが自動でスキャンするため、「あとで確認する」→「コミット前に確認済み」に変わりました。コミット前のチェックリスト8項目（ハードコードされたシークレット、SQLインジェクション、XSS、CSRF、認証/認可、レート制限、エラーメッセージの情報漏洩、入力バリデーション）が自動化されています。
6. AI駆動開発 成熟度モデル — チームの現在地を測る
導入から3ヶ月の経験を基に、AI駆動開発の成熟度モデル（5段階） を体系化しました。
モデル概要
| Level | 名称 | 特徴 | 到達目安 |
|---|---|---|---|
| L1 | 個人利用 | 一部メンバーがCopilotを使用。組織的な管理なし | – |
| L2 | チーム標準化 | 全員がツールを使用。共通ルール整備。環境統一 | 1ヶ月 |
| L3 | 品質統合 | エージェントによる自動レビュー。TDD。評価チェーン確立 | 3ヶ月 |
| L4 | 外部連携 | MCP経由で業務システムと統合。ワークフロー全体が自動化 | 6ヶ月 |
| L5 | 自己最適化 | メトリクス駆動の継続改善。ルールの自動棚卸し。ハーネス簡素化 | 12ヶ月 |
各レベルの詳細チェックリスト
L1 → L2 への移行（環境統一）:
- [ ] 全メンバーがClaude CodeまたはCopilotを使用している
- [ ] 共有設定（ルールファイル）がGitで管理されている
- [ ] コーディング規約がAIが読めるMarkdown形式で定義されている
- [ ] ペアプロ期間を設けてナレッジを共有した
- [ ] Copilot / Claude Codeの使い分け基準が明文化されている
L2 → L3 への移行（品質統合）:
- [ ] code-reviewer相当のエージェントが全PRに対して実行されている
- [ ] security-reviewer相当のエージェントがコミット前に実行されている
- [ ] 「生成者と評価者の分離」原則が運用されている
- [ ] テストカバレッジ70%以上
- [ ] TDDワークフローが標準化されている
L3 → L4 への移行（外部連携）:
- [ ] 3つ以上のMCPサーバーが接続されている
- [ ] Hooksで自動処理が2つ以上稼働している
- [ ] 業務システム（タスク管理/チャット/CRM等）とClaude Codeが連携している
- [ ] コンテキストスイッチなしで調査→実装→レビューが完了できる
L4 → L5 への移行（自己最適化）:
- [ ] 生産性メトリクスを自動収集している
- [ ] 四半期ごとにルール・エージェントの棚卸しを実施している
- [ ] モデルのアップデートに合わせてハーネスを簡素化している
- [ ] 「なくても大丈夫なルール」を定期的に削除している
ClassLabの現在地
私たちは現在L4（外部連携）からL5（自己最適化）への移行途中です。メトリクス収集の仕組み（claude-activity-tracker）は構築済みで、四半期棚卸しプロセスも導入しました。次の課題は「モデル進化に合わせたハーネスの簡素化」です。
7. うまくいかなかったこと — 正直な失敗談5選
良いことばかりではありません。正直に共有します。
失敗①: Copilotの補完を信じすぎる問題
特に導入初期、「Copilotが書いたから正しいはず」という油断がありました。ロジック的に明らかにおかしいコードがそのままマージされたことが2件。
当初はCopilotとClaude Codeを独立したレイヤーとして設計していましたが、実運用で統合の必要性がわかりました。現在はCopilot生成コードも含めて全変更にcode-reviewerを通す運用にしています。
教訓: AIが書いたコードだからこそ、AIにレビューさせる。
失敗②: ルールの肥大化
3ヶ月で500行以上のルールファイルが蓄積しました。ルールが増えるほどClaude Codeのコンテキストウィンドウを消費し、本来の作業に使えるトークンが減ります。
対策として四半期棚卸しチェックリストを導入しました:
- 指示なしでもモデルが従っているルールは？ → 削除候補
- メインセッションと同じ出力のエージェントは？ → 統合候補
- 3ヶ月間一度も発火しなかったガードレールは？ → 削除検討
教訓: ルールは増やすだけでなく、定期的に減らす仕組みが必要。
失敗③: MCPサーバーの初期設定コスト
10以上のMCPサーバーの接続設定は正直面倒でした。認証情報の管理、APIの仕様差異、レート制限の考慮、WAFによるブロック回避——一つひとつは小さな問題ですが、積み重なると数日を要します。
教訓: 初期投資は覚悟する。ただし一度設定すれば、日々のコンテキストスイッチ削減効果は計り知れない。
失敗④: エージェントの過信
code-reviewerエージェントが「問題なし」と判断したコードに、実際にはロジックバグがあったケースがありました。エージェントはコードの構造的な品質は得意ですが、ビジネスロジックの正確性は人間の確認が不可欠です。
教訓: AIレビューは人間レビューの代替ではなく、補完。最終判断は人間が行う。
失敗⑤: 新しいモデルへの過剰な期待
モデルがアップデートされるたびに「これでエージェントの数を減らせるのでは」と期待しますが、実際にテストすると期待ほどの改善がないケースも多いです。
教訓: モデル進化を前提にハーネスを設計するが、削除は必ず2回のテストセッションで品質劣化がないことを確認してから。
8. 展望 — 次に取り組むこと
短期（3ヶ月以内）
- エージェント統合テスト: 言語別ビルドエラー解決エージェント（5種: C++, Go, Java, Kotlin, Rust）を汎用1種に統合できるか検証中
- Hooks APIメトリクス拡張: セッション単位の生産性メトリクスを自動収集し、ダッシュボードに統合
- 社内ナレッジベース連携: 社内WikiをMCPサーバー経由でClaude Codeに接続
中期（6ヶ月以内）
- CI/CDパイプラインとの統合: PRマージ時にcode-reviewer + security-reviewerを自動実行
- DORAメトリクスとの相関分析: AI活用度とデプロイ頻度・変更リードタイムの関係を定量化
この記事のまとめ
- Copilotは手を速くする。Claude Codeは頭を増やす。 役割が違うから併用が最適解
- 個人の道具ではなく、チームのインフラとして設計する。 ルール・エージェント・フック・MCPを標準化しGitで管理
- 生成者と評価者は必ず分離する。 AI → AI → 人間の3段階評価チェーン
- 成熟度モデル（L1〜L5）で現在地を把握する。 段階的に導入すれば10名チームでも1ヶ月で軌道に乗る
- うまくいかないことも設計の一部。 油断・肥大化・過信への対策を事前に用意する
AI駆動開発は、ツールを入れれば終わりではありません。チームとしてどう使うかの設計が、生産性を決定します。
9. 導入テンプレート — 明日から使える設定ファイル
最後に、読者が明日から使えるClaude Code設定テンプレートを公開します。
最小構成（L2: チーム標準化 到達用）
# CLAUDE.md — チーム共通ルール（最小構成テンプレート）
## コーディング規約
- イミュータブルパターン必須: オブジェクトを変更せず、新しいコピーを作成する
- ファイルは200-400行を目安、800行を上限とする
- 関数は50行以内に収める
- ネストは4段階以内
## テスト要件
- テストカバレッジ 80%以上
- ユニットテスト・統合テスト・E2Eテストの3種を必須とする
- TDD: テストを先に書き、失敗を確認してから実装する
## セキュリティ
- ハードコードされたシークレット禁止（環境変数を使用）
- 全ユーザー入力をバリデーション
- SQLはパラメータ化クエリのみ
- エラーメッセージに内部情報を含めない
## コミットメッセージ
- Conventional Commits形式: feat/fix/refactor/docs/test/chore
エージェント定義テンプレート（code-reviewer）
# code-reviewer エージェント
## 役割
コード変更の品質をレビューし、問題点を報告する。
## レビュー観点
1. コーディング規約への準拠
2. セキュリティ脆弱性（OWASP Top 10）
3. テストの十分性
4. パフォーマンス問題
5. 可読性・保守性
## 出力フォーマット
- 重要度: CRITICAL / HIGH / MEDIUM / LOW
- ファイルパス:行番号 を明記
- 修正提案を具体的に記載
セルフチェックシート
あなたのチームはどのレベルですか？以下のチェックリストで現在地を確認してください。
| Level | チェック項目 | あなたのチーム |
|---|---|---|
| L1 | 1人以上がAIコーディングツールを使っている | □ |
| L2 | 全員がツールを使い、共通ルールがある | □ |
| L2 | ルールがGit管理されている | □ |
| L3 | エージェントによる自動レビューが全PRに適用されている | □ |
| L3 | 生成者と評価者が分離されている | □ |
| L3 | テストカバレッジ70%以上 | □ |
| L4 | MCPサーバーが3つ以上接続されている | □ |
| L4 | Hooksで自動処理が稼働している | □ |
| L5 | 生産性メトリクスを自動収集している | □ |
| L5 | 四半期ごとにルールを棚卸ししている | □ |
L1-L2: まだ始めたばかり。環境統一から着手を L3: レビュー自動化ができればチームの生産性が跳ねる段階 L4-L5: 外部連携と自己最適化。ここまで来ればAI駆動開発が「当たり前」に
ClassLabで一緒にAI駆動開発を推進しませんか？
ClassLabでは、この記事で紹介した環境を日常的に使い、少人数で大きなインパクトを出すことを目指しています。
「AIツールを活用した開発チームで働きたい」「チームのインフラとしてAIを設計する側に回りたい」という方、まずはカジュアルにお話ししましょう。
