チーム導入の進め方 — 組織でClaude Codeを活かす
このレッスンで学ぶこと
- □個人利用からチーム利用へ移行する際の3つの壁（設定共有・品質担保・セキュリティ）
- □共有設計: CLAUDE.md / .claude/rules/ / .claude/skills/ のチーム運用
- □権限設計: Permission modesとAPIキー管理
- □チーム導入の5ステップ（段階的に広げる方法）
- □やってはいけない導入パターン
個人利用からチーム利用への3つの壁
Claude Codeを1人で使うのと、チームで使うのでは、考えるべきことが大きく異なります。 導入前にこの3つの壁を理解しておきましょう。
設定共有の壁
CLAUDE.mdやルールファイルを「どこに置くか」「誰が編集できるか」「変更をどうレビューするか」。 個人なら自由にいじれた設定ファイルが、チームでは「共有インフラ」になります。 変更がチーム全体に影響するため、PRベースでの変更管理が必要になります。
品質担保の壁
メンバーごとにClaude Codeの使い方が異なると、出力品質にばらつきが生じます。 「Aさんが書いたコードは高品質だがBさんのは低品質」を防ぐには、共通のルール・スキル・レビュー体制が必要です。
セキュリティの壁
Claude Codeはファイルの読み書き、コマンド実行、外部API接続が可能です。 チームで使う場合、「誰がどの操作を許可されるか」「機密ファイルへのアクセス制限」「APIキーの管理」を明確にする必要があります[3]。
共有設計 — チームで共有するファイル群
Claude Codeの設定は階層構造になっており、チーム共有の設定と個人設定を分離できます[2]。 リポジトリにコミットするファイルがチーム共通設定、ローカルに置くファイルが個人設定です。
チームで共有すべきファイル
| ファイル | 役割 | git管理 |
|---|---|---|
| CLAUDE.md | プロジェクトの基本ルール・コンテキスト | コミットする |
| .claude/rules/ | コーディング規約、セキュリティルール | コミットする |
| .claude/settings.json | 共通の許可/拒否ルール | コミットする |
| .claude/skills/ | チーム共通のワークフロー | コミットする |
| ~/.claude/settings.json | 個人の好みの設定 | コミットしない |
| ~/.claude/CLAUDE.md | 個人のグローバル設定 | コミットしない |
.claude/rules/ でパス別ルールを設定
.claude/rules/ 内のファイルにpaths: ヘッダーを書くと、特定のディレクトリにだけ適用されるルールを定義できます。 たとえば paths: src/api/** と書けば、 API関連のコードに対してだけ厳格なセキュリティルールを適用できます。権限設計 — Permission Modes
Claude Codeには3つの権限モードがあり、チームの運用方針に応じて選択できます[3]。
推奨デフォルトモード
ファイル読み取りは自動許可。ファイル書き込みやコマンド実行は毎回確認を求めます。 チーム導入の初期段階ではこのモードで慣らしていくのが安全です。
許可リストモード
.claude/settings.json のallowedTools に許可するツールとパターンを列挙。 リストにないツール使用は確認が入ります。チームルールとして「このプロジェクトでは安全なコマンドだけ自動許可」を設定できます。
注意YOLOモード（dangerously-skip-permissions）
すべてのツール実行を確認なしで許可します。チーム環境では基本的に使わないでください。個人開発の検証時やサンドボックス環境でのみ使うべきモードです。
APIキー管理のベストプラクティス
- 1.環境変数で管理 — APIキーは .env ファイルや環境変数で。コードにハードコードしない
- 2.メンバーごとにキーを分ける — 共有アカウントではなく、個人のAPIキーを使う
- 3..gitignore に含める — .env、APIキーを含むファイルは絶対にコミットしない
- 4.定期的にローテーション — 漏洩リスクを最小化するため、キーを定期的に更新する
全メンバーに同じAPIキーを共有しない
チーム導入の5ステップ
いきなり全員に展開するのではなく、段階的に広げていくのが成功の鍵です。
- 1
まず1人で使い込む
この講座のPhase 1-2の内容を、自分の業務で実践。CLAUDE.mdの書き方、よく使うコマンド、使えるMCP接続を把握する。最低2-3週間は自分で運用して「何が便利で何が危険か」を肌で理解する。
- 2
CLAUDE.mdをリポジトリにコミット
プロジェクトの基本ルール、コーディング規約、禁止事項をCLAUDE.mdに明文化。.claude/rules/ にセキュリティルール、.claude/settings.json に許可リストを設定。これがチームの「共通基盤」になる。
- 3
チーム内の1-2人に展開
ITリテラシーが高いメンバー、またはAI活用に積極的なメンバーを選ぶ。環境構築を一緒にやり、最初の1週間はペアで使ってフィードバックをもらう。
- 4
フィードバックを元にルール改善
「この操作は自動許可してほしい」「このルールが厳しすぎる」「こういうスキルが欲しい」。実際に使った声を元に、CLAUDE.mdとルールファイルをイテレーションする。
- 5
全員に展開
ルールが安定したら全メンバーに展開。オンボーディング資料（基本操作・よくあるユースケース・やってはいけないこと）を用意し、最初の1週間はサポート体制を厚くする。
やってはいけない導入パターン
全員に一斉導入
「来月から全員Claude Code使ってください」はほぼ失敗します。ルールが未整備なまま展開すると、 メンバーが混乱し、事故（意図しないファイル削除、機密情報の流出など）のリスクが高まります。 段階的に広げることで、問題を小さく抑えられます。
ルールなしで放置
「自由に使ってOK」は危険です。メンバーAはYOLOモードで本番DBを触り、メンバーBはAPIキーをコードにハードコードし、 メンバーCは社外秘ファイルをClaudeに渡してしまう。CLAUDE.mdとルールファイルの整備は導入の前提条件です。
「ツールを入れれば生産性が上がる」と思い込む
Claude Codeは強力ですが、使い方を知らなければ効果は出ません。 「効果的な指示の出し方」「CLAUDE.mdの設計」「Hooksの活用」を学ぶ時間を確保しないまま導入しても、 「使いにくい」で終わってしまいます。
チーム導入の成功指標
Lesson 11 まとめ
- ✅チーム導入の壁は「設定共有」「品質担保」「セキュリティ」の3つ
- ✅CLAUDE.md / .claude/rules/ / .claude/settings.json をリポジトリにコミットしてチーム共通基盤に
- ✅導入は段階的に: 1人で使い込む → 少人数に展開 → フィードバック → 全体展開
- ✅一斉導入・ルールなし放置・ツール信仰の3つのアンチパターンを避ける
あなたの番です
出典・参考文献
本レッスンで引用したデータの原典一覧です。数値は各調査の公開時点のものであり、閲覧時期により更新されている可能性があります。
- [1]Claude Code for Teams and Organizations — Anthropic（2025）
- [2]CLAUDE.md — Memory and Project Configuration — Anthropic（2025）
- [3]Claude Code Security and Permissions — Anthropic（2025）
よくある質問
チームプランは必須？個人プランの共有ではダメ？
個人プランでも設定ファイル（CLAUDE.md、ルールファイル）のリポジトリ共有は可能です。ただし、使用量の管理やメンバーごとの権限設定が必要な場合は、Claude Code for Teams / Enterpriseプランが適しています。まずは個人プランで始めて、ニーズが見えてからチームプランへ移行するのが現実的です。
CLAUDE.mdの変更はPRで管理すべき？
はい。CLAUDE.mdはチーム全体のAI動作に影響するため、コード変更と同様にPRベースでレビューしましょう。「なぜこのルールを追加するのか」「影響範囲はどこか」をPRの説明に書くことで、チームの合意形成もスムーズになります。
非エンジニアのチームメンバーにも使える？
Claude Codeはターミナル操作が前提のため、非エンジニアには敷居が高い面があります。ただし、スラッシュコマンドやスキルを整備すれば、定型操作は簡単に実行できます。非エンジニア向けには、よく使う操作をスキルとして用意し、最小限のコマンドで業務が完結するよう設計しましょう。
いよいよ最終レッスン。学んだ全てを統合して、自分だけのAIワークフローを完成させよう。
Lesson 12: 実践プロジェクト →