Claude Code チーム導入ガイド｜Team/Enterpriseプラン・権限設計・管理者設定を整理

Claude Codeを組織で導入する場合、人数が150人以下で一般的な開発用途ならTeamプラン、監査ログ・SCIM・Compliance APIが必要ならEnterpriseプランが現時点での基本線です。ただし実運用では「Managed Settingsでどこまでロックダウンするか」「Bedrock/Vertex AI経由だと何が効かないか」といった管理者向けの落とし穴があり、プラン選定と権限設計はセットで決める必要があります。

本記事では、プラン選定 → 権限設計 → 管理コンソール設定 → 監査・分析 → 段階的導入までを、2026年4月時点の公式情報に基づいて整理します。

この記事でわかること

• Claude Codeをチームで使う3つの方法と、TeamとEnterpriseの違い
• StandardシートとPremiumシートの選び分け、最小人数・料金の目安
• SSO/SCIMと、IdPのグループをロール・シート種別にマッピングする方法
• Server-managed settingsとEndpoint-managed settingsの使い分けと、絶対入れるべきセキュリティ設定
• Bedrock/Vertex AI経由のときに効かない管理機能
• 30-60-90日の段階的導入ロードマップ

この記事が特に役立つ方

• 情シス・セキュリティ担当で、開発部門からClaude Codeの全社導入を依頼されている方
• CTO・VPoE・開発マネージャーで、個人Max契約の乱立をTeam/Enterpriseに統合したい方
• 既にTeamプランを契約しているが、権限設計を詰め切れていない組織の管理者

Claude Codeをチームで使う3つの方法

Claude Codeを組織で使う選択肢は、現時点で個人プラン(Pro/Max)・Teamプラン・Enterpriseプランの3系統です。どれを選ぶかで、できること・管理機能・費用がまったく変わります。

個人プラン（Pro/Max）を部署内で使う方法

公式にもっとも非推奨のパターンです。各開発者がそれぞれ個人契約し、経費精算する運用です。

• 支払いが一元化できない
• 利用状況の可視化ができない
• セキュリティポリシーを集中的に適用できない
• 退職者のアクセス遮断が属人化する

小規模なPoCには向きますが、本格運用ではTeamプラン以上への移行が前提です。

Teamプラン（5〜150人、セルフサーブ）

もっとも一般的な選択肢です。管理コンソール（claude.com/settings/organization）からセルフサーブで契約でき、Claude CodeとClaude Coworkが全席に標準含有されます。

主な特徴は次のとおりです。

• 最小5人から、最大150席まで
• SSO、ドメイン検証、ロールベース権限、支出コントロール、使用量分析に対応
• モデル学習にデータが使われないデフォルト設定
• JIT（Just-in-Time）プロビジョニングには対応するが、SCIMには非対応

Enterpriseプラン（カスタム見積、SCIM/Compliance対応）

150席を超える、または監査ログ・SCIM・Compliance APIが必要な組織向けです。料金はカスタム見積のみで、最低人数の固定ルールは公開されていません（実務的にはTeamの上限を超えるケースか、統制要件が重い組織が対象）。

Enterpriseだけで使える代表的な機能は次のとおりです。

• SCIM（自動プロビジョニング）、カスタムロール
• IPアローリスト
• 監査ログ
• Compliance API（活動ログ・チャット履歴・ファイル内容へのプログラムアクセス）
• カスタムデータ保持設定
• HIPAA-readyオプション（ただしClaude Code本体はHIPAAカバー外）
• Amazon Bedrock / Google Vertex AI / Microsoft Foundryへのデプロイ先選択

Team と Enterprise の違い（比較表）

管理機能で決定的に差が出るのは、SCIM・監査ログ・Compliance API・カスタムロール・IPアローリストの5点です。

選び方の目安:

• 150人以下 × 監査ログ不要 × 通常クラウド利用 → Teamプランで十分
• 監査ログ・SCIM・Compliance APIが必須 → Enterpriseプラン一択
• Bedrock/Vertex AI経由で使いたい → Enterpriseプラン（ただし後述のとおりServer-managed settingsが効かない点に注意）

Teamプランの料金とシート選び（Standard / Premium）

TeamプランにはStandardシートとPremiumシートの2種類があり、同一組織内でミックス運用できます。全員をPremiumにする必要はなく、使用量が重い開発者のみPremiumに切り替える、という運用が現実的です。

Teamプランの料金表（USD建て・2026-04時点）

金額はUSD建てで、為替により日本円換算は変動します。 公式にunlimited（無制限）プランは存在しません。

StandardとPremiumをどう割り振るか

典型的な割り振り方は次のとおりです。

• Standard推奨: チャット利用中心・スクリプト/調査用途が多い一般開発者、CS/PM/デザイナーなど非開発ロール
• Premium推奨: Claude Codeで日常的にコード生成する中堅〜シニア開発者、Agent Teamsやサブエージェントを多用する開発者、1日中CLIを回しているような高負荷ユーザー

使用量上限はチーム合算ではなく1人単位で適用されるため、「重負荷な人だけPremium、他はStandard」という粒度での最適化が重要です。

メンバー管理とロール設計

Claude Codeの管理権限はロールで決まります。Primary Ownerは1名のみで、所有権の移譲は可能ですが分散はできません。

標準ロール

Server-managed settingsの設定権限はPrimary Owner / Ownerのみです。Adminでは触れない点に注意してください。

招待・プロビジョニングの選択肢

招待リンクの有効期限は21日間です。長期運用では手動招待に頼らず、JITかSCIMに寄せるのが鉄則です。

SSO / SCIMの設定と、IdPグループのマッピング

TeamプランならJIT、EnterpriseプランならSCIMでのグループマッピングが運用上の最適解です。WorkOS経由で以下のIdPに対応しています。

• Okta（SAML / SCIM）
• Microsoft Entra ID（SAML / SCIM）
• Google Workspace（SAML / Directory Sync）
• OneLogin（SAML / SCIM）
• JumpCloud（SAML / SCIM）

プロビジョニング方式の3択

1. Invite only: 手動招待のみ（JIT/SCIMを使わない）
2. Approve automatically（JIT）: SSOでログインした瞬間に自動でシート付与
3. Sync with SCIM: IdP側のグループを正として同期（Enterprise専用）

SCIMでグループ→ロール→シート種別を自動マッピングする

2026年4月のアップデートで、IdPのグループをClaudeのロールとシート種別に自動マッピングできるようになりました。典型的な設計例は次のとおりです。

重要な注意点:

• SCIM/Group未割当ユーザーは自動的に最高ランクのシートが付与される仕様です。想定外のPremium割当でコストが跳ねることがあるため、必ずデフォルトグループを定義してください。
• IdP側でユーザーをアプリに割り当てないまま保存すると、既存ユーザーが自動deprovisionされて削除される挙動があります。設定変更時は必ずステージング環境で挙動を確認してください。

Claude CodeのManaged Settings（Server-managed / Endpoint-managed）

Claude Codeには組織から強制できる設定が2系統あります。いずれも最上位優先度で、ユーザーやプロジェクトの設定・コマンドライン引数でも上書きできません。

2種類のManaged Settingsの違い

使い分けの基本:

• MDMを入れていない中規模組織 → Server-managed settingsが第一選択
• MDMで端末を集中管理している大企業 → Server-managedをベースに、MCP設定やグループ別ポリシーだけEndpoint-managedで補完
• Bedrock/Vertex AI/Foundry経由で使う → Server-managed settingsは効かないため、Endpoint-managed一択

優先関係とキャッシュの挙動（重要な落とし穴）

• Server-managedが先にチェックされ、何らかの非空設定を返すとEndpoint-managedは完全に無視されます（マージしません）。
• クライアントにはローカルキャッシュが残り、サーバ側を空に戻しても次回成功フェッチまでキャッシュが効きます。
• api.anthropic.comへのネットワーク到達性が必須です。プロキシ環境では事前に疎通確認してください。

絶対に入れるべき3つのセキュリティ設定

管理者が最初に設定すべき最小構成のManaged Settingsは次のとおりです。これはBedrock等の例外を除き、Claude Codeの安全運用における実質的な出発点になります。

1. disableBypassPermissionsMode（最重要）

--dangerously-skip-permissionsなどで権限確認をバイパスする行為をブロックする設定です。これを入れないとManaged Settingsの権限ルールが実質無力化されます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

2. permissions.deny（機密ファイル・危険コマンドの遮断）

.envやsecrets/配下への読み取り、危険なBashコマンドを禁止します。

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

3. allowManagedPermissionRulesOnly（ユーザー側のallow上書き封じ）

ユーザーがローカルでallowルールを追加して抜け穴を作る行為を防ぎます。

{
  "allowManagedPermissionRulesOnly": true
}

まとめた最小構成例

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "/usr/local/bin/audit-edit.sh" }
        ]
      }
    ]
  }
}

PostToolUseフックでは、Edit/Writeの直後に社内の監査スクリプトを強制実行できます。ログ集約やCI連携の足場として有効です。

forceRemoteSettingsRefreshの実務リスク

forceRemoteSettingsRefresh: trueを入れると、起動時にリモート設定の取得に失敗したらClaude Codeが起動不可（exit）になります。キャッシュでも起動しません。

この設定はポリシー迂回を完全に防げる一方、api.anthropic.comへの疎通が切れた瞬間に全員が開発できなくなるリスクを抱え込みます。プロキシ・VPN・オフィス回線の冗長性を確認してから有効化してください。また、一度配信されるとキャッシュにも残り自己永続化する点も把握しておきましょう。

Bedrock / Vertex AI / Foundry利用時の管理限界

Enterpriseプランでは、Anthropicクラウド以外のデプロイ先を選べます。

• Amazon Bedrock
• Google Vertex AI
• Microsoft Foundry
• カスタムANTHROPIC_BASE_URL / LLMゲートウェイ経由

ただし、これらの構成ではServer-managed settingsが適用されません（公式明記）。以下に該当する企業はこの制約を必ず事前に織り込んでください。

• AWS/GCP/Azureのガバナンスに統合する必要があるためBedrock/Vertex/Foundryを使う企業
• 内製のLLMゲートウェイ経由でレート制御・監査を一元化している企業

対策としては、Endpoint-managed settings（MDM配布）を前提にした運用設計に切り替える必要があります。Jamf/Kandji（macOS）やIntune/GPO（Windows）でmanaged-settings.jsonを配布する方式です。MDM未導入の組織がBedrock利用を急ぐと、結果的にガバナンスを敷けなくなる点に注意してください。

支出コントロール（組織上限 / ユーザー上限）

管理者が予算上振れを防ぐための仕組みが用意されています。

2段階の支出上限

• 組織単位の月間上限（Organization monthly spend cap）
• ユーザー単位の月間上限（Per-user spend cap）

上限到達後は、ユーザーは標準含有分で利用継続できますが、extra usageは停止します。つまり「使えなくなる」のではなく「Standard相当に戻る」挙動です。

設定はOrganization settings > Billingから行い、アクセス権はOwner / Primary Ownerのみです。

現実的な上限の決め方

初期段階では次の2段構えが安全です。

1. 組織単位：予算を20〜30％上回る水準で暫定上限を設定
2. ユーザー単位：平均使用量の2倍程度で上限を設定（個別の暴走を抑えつつ、通常業務は止めない水準）

上限に到達したユーザーはDMなどで通知されますが、管理者には別途Analyticsで可視化する運用が推奨です。

分析と監査（Analytics API / Compliance API）

管理コンソールの組織分析

Team / Enterprise双方で、管理パネルから以下のメトリクスを確認できます。

• 受け入れられたコード行数（lines accepted）
• 提案受け入れ率
• セッション数
• アクティブユーザー数
• シート種別ごとの使用量分布

Claude Code Analytics Admin API

Admin APIキー（sk-ant-admin...）を発行してプログラマブルに利用データを取得できます。Redash/Metabase/Looker Studioとの連携がしやすく、社内ダッシュボードを作りたい場合の基本ルートです。

Claude Enterprise Analytics API（Enterprise専用）

2026-01-01以降のデータを日次集計で、過去90日分まで取得できます。5エンドポイント構成で、Primary OwnerがAnalytics > API keysから発行します。

Compliance API（Enterprise専用）

Organization settings > Data and privacyから有効化します。取得可能なデータは以下のとおりです。

• アクティビティログ
• チャット履歴
• ファイル内容
• 監査ログイベント（Managed Settingsの変更履歴を含む）

Splunk / Datadog / Microsoft Sentinel等のSIEMに取り込むことで、誰がいつ何のManaged Settingsを変更したかまで追跡可能になります。選択的削除にも対応しており、データ保持ポリシーと整合させやすい設計です。

OpenTelemetry連携

API経由以外に、Claude CodeはOpenTelemetry（OTLP）エクスポートに対応しています。既存のDatadog APM・Grafana Tempo・New Relicにメトリクス/トレースを流し込むルートも現実的です。

30-60-90日 段階的導入ロードマップ

いきなり全社展開せず、フェーズを区切ると失敗しにくくなります。

0〜30日：パイロット

• 目的: 使用パターンとリスクの実測
• 対象：10〜30人のアーリーアダプター（シニア開発者中心）
• Teamプラン契約、SSO設定、ドメイン検証
• 最小構成のManaged Settings（disableBypassPermissionsMode / deny）を配信
• AGENTS.md / CLAUDE.mdを各主要リポジトリに追加
• KPI：週次アクティブ率、PR数の変化、ツール呼び出し失敗率

31〜60日：部門展開

• 目的: 運用フローの確立
• 対象：1〜3部門、50〜150人程度
• 支出上限（組織・ユーザー単位）を確定
• allowManagedPermissionRulesOnly: trueを有効化
• PostToolUseフックで監査ログ出力を開始
• .claude/settings.json（共有）と.claude/settings.local.json（個人・.gitignore対象）の分離ルールを明文化
• StandardとPremiumのシート種別判定ルールを策定

61〜90日：全社展開 or Enterprise移行判断

• 目的: ガバナンス完成と拡張判断
• 150人を超えそう、または監査ログ／SCIMが必要ならEnterpriseへアップグレード
• Enterprise契約後、SCIMでグループ→ロール→シート種別を自動マッピング
• Compliance APIをSIEMに連携
• Bedrock/Vertex AI利用を検討する場合、Endpoint-managed settingsへ移行
• 退職者プロセスに「SSO removal → SCIM deprovision → ローカルキャッシュクリア」を組み込む

こんな組織におすすめ / おすすめしない

Teamプランが向いている組織

• 社員5〜150人規模で、全員に同じポリシーで配りたい組織
• SCIMまでは不要で、JITとSAML SSOで十分な組織
• 監査ログ要件が厳しくない業界
• 管理コンソールでManaged Settingsを配信できる（MDM未導入でも問題ない）組織

Enterpriseプランが向いている組織

• 150人超、または急速に人数が伸びる予定の組織
• 金融・ヘルスケア・公共など監査ログ・Compliance API・IPアローリストが必須の業界
• SCIMでIdPと連携し、人事異動に追随させたい組織
• Bedrock / Vertex AI / Foundry経由で契約・請求を既存クラウドに寄せたい組織

Claude Codeのチーム導入が向いていないケース

• 開発者が常駐する端末を個人所有にしており、MDMもSSOも整備できない組織
• Bedrockを必須としながらMDMも未導入で、Endpoint-managed settingsを敷けない組織（ガバナンスが事実上ザル化する）
• HIPAA対象のPHIをClaude Code経由で処理したい組織（HIPAAカバーはTeam/Enterpriseのチャット領域で、Claude Code自体は対象外）
• 全員を個人Maxで回したまま統制を取らない前提の組織（Shadow AI化・退職者統制不可）

よくある質問（FAQ）

Q1. 個人Maxと Teamプランは併用できますか？

運用上は可能ですが、利用状況の一元把握ができないため推奨されません。個人Max $200プラン保有者が後からTeam組織に参加した場合の細かい挙動は公式に明文化されていないため、移行時期を決めて全員Teamシートに寄せるのが現実的です。

Q2. Standard → Premium、Premium → Standardの切り替えはすぐ反映されますか？

Owner操作でOrganization settings > Organizationから変更できます。Premiumから Standardへの自動ダウングレードはなく、必ず手動操作が必要です。途中切り替え時の課金按分ルールは公式Helpに明記されていないため、会計上の影響はAnthropic側に確認してから実施してください。

Q3. Claude CodeのManaged SettingsはWebのClaude（Cowork / Chat）にも効きますか？

Managed SettingsはClaude Codeクライアント向けの仕組みです。ChatやCoworkはまた別の管理コンソール設定で制御されます。混同しないよう、Claude Code専用のロックダウンポリシーとして設計してください。

Q4. Bedrock経由でもサーバ側で集中管理したいのですが方法はありますか？

2026年4月時点で、Bedrock / Vertex AI / Foundry / 独自baseURL利用時はServer-managed settingsが無効です。MDMでのEndpoint-managed配信か、社内のLLMゲートウェイ側でHTTPレベルのポリシーを敷く運用が現実解になります。

Q5. 招待リンクが21日で切れてしまう運用を回避するには？

JIT（Team以上）またはSCIM（Enterprise専用）に寄せるのが正攻法です。人数が少ないうちは個別招待でも回りますが、規模が拡大するとSSOを入れない限り破綻します。

Q6. Shadow AI（個人アカウント流用）を防ぐ決定打はありますか？

単一の設定では防げません。SSOドメイン制限＋Managed SettingsのdisableBypassPermissionsMode＋MDMでのClaude Code配布＋Compliance APIでの監査を重ねるのが定石です。ユーザーが別組織で再認証すればManaged Settingsは適用されなくなるため、端末側でログイン可能な組織を制限する運用も併用してください。

まとめ：Claude Codeチーム導入の最短ルート

Claude Codeをチームで安全に導入する最短ルートは、次の順番で決めていくことです。

1. 人数と統制要件でTeam / Enterpriseを決める
2. StandardとPremiumのミックス方針を決める（全員Premiumは不要）
3. SSO→ドメイン検証→JIT/SCIMの順でIdP連携を整備
4. disableBypassPermissionsMode / deny / allowManagedPermissionRulesOnlyを含むManaged Settingsを配信
5. 支出上限（組織・ユーザー単位）を設定
6. Analytics / Compliance APIで監査・可視化
7. Bedrock等の非標準デプロイならEndpoint-managed settingsに切り替え

プランと権限設計はセットで決める必要があります。「とりあえずTeamで契約したが、Managed Settingsを入れないまま全開発者に配った」状態がもっとも危険なので、パイロット段階でポリシーの骨格を作ってから広げてください。

関連記事

• Claude Codeの全体像を押さえたい方：Claude Codeとは？機能・料金・使い方を整理
• Claude Code自体の使い方ガイド：Claude Code 使い方ガイド
• Claude Codeの料金詳細：Claude Code 料金プラン解説
• Claude Codeのセキュリティ観点：Claude Code セキュリティ・安全な使い方
• Claude Code Hooksの実装：Claude Code Hooks 使い方
• エージェンティック開発の全体像：エージェンティックエンジニアリングとは
• AIエージェントのセキュリティ設計：AIエージェント セキュリティ対策ガイド