Claude Code をチームに入れたいが、最初に何をルール化すべきか分からない。個人利用ではうまく動いたのに、組織に広げた途端に「誰のアカウントで動いているのか」「どの権限を常時許可してよいのか」「MCP を自由追加してよいのか」「レビュー証跡はどこに残るのか」が曖昧になる。ここを放置すると、導入は速く見えても、あとで止められない自動化になります。
この記事では、Claude Code の組織導入を 初日・30日・90日で段階的に広げる運用ルールとして整理します。Claude Code の基本操作は Claude Code の使い方 実践ガイド、全社レベルの生成AI導入方針は 生成AIの組織導入ガイド、開発部門向けの禁止・許可テンプレは AIコーディングツールの社内ガイドライン に分けています。本記事はその間にある、Claude Code 導入担当者向けの rollout plan です。
既存記事との役割も明確にしておきます。Claude Code managed settings 設計ガイド は permissions.deny や managed-mcp.json の配布設定が主題です。Claude Code MCP ガイド は claude mcp add、stdio、remote HTTP の接続手順を扱います。MCP エンタープライズ運用ガイド は認証、監査、allowlist の組織統制を扱います。この記事は、それらを いつ誰に開放するか を決める導入ルールに絞ります。
先に結論: 初日は機能解放ではなく責任境界を決める
Claude Code の組織導入で最初に決めるべきことは、便利なプロンプト集ではありません。私なら、初日に次の6項目だけを固定します。
- 利用できるアカウント種別
- 対象リポジトリ
- shared settings の置き場
- permission mode の初期値
- MCP を誰が追加できるか
- 成果物のレビュー責任者
この6項目がないまま「各自で使ってよい」とすると、個人契約、個人設定、個人判断の allow、未承認 MCP、GitHub Actions token が混ざります。後から中央管理しようとしても、すでに便利な抜け道が現場に定着しているので戻しにくいです。
逆に、最初からすべてを managed settings で縛る必要もありません。導入初期の目的は、自由度を消すことではなく、事故が起きたときに「どのルールを破ったのか」「どこを止めればよいのか」を説明できる状態にすることです。
導入初日: アカウントと対象 repo を絞る
最初にやるべきは、Claude Code を誰の認証で使うかを決めることです。公式ドキュメントでは、個人の Claude.ai アカウント、Claude for Teams / Enterprise、Claude Console、Amazon Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry、Claude apps gateway など複数の認証経路が整理されています。組織導入では、ここを曖昧にしない方がよいです。
小規模チームなら、まず Claude for Teams で中央請求とメンバー管理を揃えます。監査、SSO、domain capture、role-based permissions、compliance API、managed policy settings が必要なら Enterprise を検討します。すでにクラウドプロバイダ経由でモデル利用を統制している会社なら、Bedrock や Google Cloud 経由も候補になります。
私なら初日は、次のような短い導入メモにします。
claude_code_rollout:
phase: day_0
allowed_accounts:
- company_claude_team
allowed_repositories:
- internal-tools
- docs-site
forbidden_repositories:
- payments
- identity
- customer-data-export
owner:
policy: platform-team
review: repo-owner重要なのは「全員が使える」ではなく「どの repo から始めるか」です。支払い、認証、個人情報、顧客データに近い repo は最初から入れない方がよいです。最初の2週間は、ドキュメント、社内ツール、テストが厚い周辺 repo で使い、ルールの穴を見ます。
30日目: shared settings と個人例外を分ける
Claude Code の settings は、ユーザー、共有プロジェクト、プロジェクトローカル、managed のスコープを分けられます。組織導入で最初に使いやすいのは、リポジトリに .claude/settings.json を置く shared project settings です。ここには、チーム全員に揃えたい permissions、hooks、telemetry、plugins を入れます。
一方で、個人の都合は .claude/settings.local.json に逃がします。ここに個人の一時的な allow が保存されることもあります。だからこそ、導入ルールでは「shared に入れてよいもの」と「local にしか置いてはいけないもの」を分ける必要があります。
私なら30日目の gate はこうします。
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"permissions": {
"allow": ["Bash(pnpm run build)", "Bash(pnpm test *)"],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Bash(git push --force*)",
"Bash(npm publish*)"
]
},
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_LOGS_EXPORTER": "otlp"
}
}これは完成形ではありません。狙いは、よく使う検証コマンドを許可し、秘密情報、force push、公開操作を止めることです。Claude Code の permissions は read-only、Bash、file modification、WebFetch、WebSearch、MCP などで扱いが違います。自然言語で「危ないことは禁止」と書くより、tool と操作単位で許可・禁止を置く方がレビューできます。
permission mode は部署ではなく作業 lane で分ける
Claude Code には Manual mode や auto mode などの permission mode があります。auto mode では別の classifier model が action を確認し、明示的な ask / deny ルールも引き続き効きます。ただし、これを「上級者は auto、初心者は manual」と分けると失敗しやすいです。
分けるべき軸は人ではなく作業です。
| 作業 lane | 初期 mode | 理由 |
|---|---|---|
| 調査、設計、ドキュメント | Manual または制限付き auto | 外部副作用が少ない |
| 通常実装、テスト追加 | Manual から開始 | 差分レビューを癖づける |
| 依存関係追加、DB、認証、課金 | Manual + 明示承認 | 失敗時の戻しコストが高い |
| GitHub Actions automation | 専用 workflow 権限 | 人間の端末権限と分ける |
| MCP write 操作 | 原則 ask | 接続先の副作用を見落としやすい |
この分類を作ってから、必要な repo だけ auto mode を試します。最初から「Claude が安全判定するから大丈夫」とは見ない方がよいです。auto mode は便利な reviewer であって、組織の責任者ではありません。
MCP は30日目まで自由追加させない
Claude Code は MCP と相性がよいですが、組織導入では最も混線しやすい場所でもあります。stdio の MCP server はローカルコマンド実行に近く、remote HTTP は認証、scope、監査、session lifecycle を伴います。
初期 rollout では、MCP を次の3段階に分けます。
- 接続禁止: 最初の2週間。Claude Code 単体で運用ルールを確認する
- read-only MCP: docs search、issue search、repository metadata だけを許可する
- write MCP: チケット更新、Slack投稿、deploy などは申請制にする
この段階設計をしないと、MCP が「便利な拡張」ではなく「誰の権限で外部操作したか分からない経路」になります。Claude Code 側の接続手順は Claude Code MCP ガイド、MCP server の owner / endpoint / scope / risk tier は MCP サーバーカタログ設計ガイド に分けて確認してください。
Hooks は強制ではなく観測から始める
Hooks は Claude Code の lifecycle に合わせて shell command、HTTP endpoint、LLM prompt を実行できます。PreToolUse、PostToolUse、PermissionRequest、Stop、SessionEnd などの event を使えば、危険操作の検知や検証コマンドの補助に使えます。
ただし、導入初期から Hooks で何でも止めると、現場は何が原因で止まったのか分からなくなります。私なら最初は observe-only で始めます。
hooks_rollout:
week_1:
mode: observe
record:
- permission_request
- denied_tool
- failed_bash
week_3:
mode: warn
block:
- env_file_read
- force_push
- unknown_mcp_write
week_6:
mode: enforce
require:
- build_result
- reviewer_noteHooks は制御に使えますが、制御する前にログを見る期間が必要です。どの command が実務で本当に必要か分からない状態で deny を増やすと、ルールが現実から外れます。
90日目: 監査とレビュー gate を接続する
90日目の目標は、Claude Code を使える人を増やすことではありません。使った結果を後から説明できることです。
Claude Code は OpenTelemetry による metrics、logs/events、traces の export に対応しています。usage、cost、tool activity を組織の観測基盤へ出せるなら、少なくとも次を追います。
- session count
- tool execution
- failed tool
- permission denied
- model usage
- cost trend
- user prompt event
ここで raw prompt を全部保存する必要はありません。むしろ、個人情報や秘密情報を含む可能性があるなら、保存項目を絞ります。監査ログの考え方は AIエージェント監査ログ設計ガイド に分けていますが、Claude Code rollout では「誰が、どの repo で、どの permission と MCP scope で、どの成果物を出したか」まで見えれば初期運用としては十分です。
GitHub Actions で Claude Code を使う場合は、端末上の利用とは別ルールにします。workflow token、Secrets、pull request permission、review before merge を分ける必要があります。API key や OAuth token を repo に置かず GitHub Secrets に置くこと、workflow に必要最小限の permission だけを与えることは、導入ルールの本文に明記します。PR 上のレビュー運用は Claude Code code review 実践ガイド、security 専用 lane は Claude Code security review 設計ガイド に分けてください。
私が使う90日 rollout checklist
最後に、実務で使うならこの粒度で十分です。
| 時期 | gate | 合格条件 |
|---|---|---|
| 初日 | account gate | 会社管理アカウントだけでログインできる |
| 初日 | repo gate | 対象 repo と禁止 repo が明文化されている |
| 7日 | command gate | 許可する build / test command が決まっている |
| 14日 | secret gate | .env、token、customer data の読み取り禁止が設定されている |
| 30日 | settings gate | .claude/settings.json がレビュー済みで commit されている |
| 30日 | MCP gate | read-only MCP だけが catalog 登録済み |
| 60日 | automation gate | GitHub Actions は専用権限と Secrets で動く |
| 90日 | telemetry gate | usage、tool、permission event を確認できる |
| 90日 | review gate | merge 前に人間が見る差分種別が決まっている |
Claude Code の組織導入は、ツールを配る作業ではなく、開発の責任境界を作り直す作業です。初日は便利機能を広げすぎず、30日目で shared settings と permission を揃え、90日目で監査と review gate を接続する。この順番にすると、個人の成功体験をそのまま会社に持ち込むより、事故が少なく、継続運用に乗せやすくなります。