Claude Code特集2026年10月更新

Claude Code チーム導入ガイド|Team/Enterpriseプラン・権限設計・管理者設定を整理【2026年10月】

公開日: 2026/04/22
更新日: 2026/10/16
Claude Code チーム導入ガイド|Team/Enterpriseプラン・権限設計・管理者設定を整理【2026年10月】

この記事のポイント

Claude Codeをチームで導入するときのTeam/Enterpriseの選び方、料金(Teamは2人から・Enterpriseは席$20+利用分)、ロールと権限設計、managed settingsの設定、コスト管理、段階的な導入手順を2026年10月時点の公式情報で整理します。

Claude Codeを組織で導入するなら、150人以下で監査ログやSCIMが要らなければTeamプラン、監査ログ・SCIM・Compliance API・細かい権限設定が必要ならEnterpriseプランが、2026年10月時点の基本の考え方です。どちらを選んでも、managed settings(組織が強制する設定)で何を縛るかを決めずに配ると統制が効かないため、プラン選定と権限設計は一緒に決めます。

公式の条件には、以前から変わった点がいくつかあります。Teamは2人から契約できるようになり、Enterpriseは1席月$20(年払い)+利用分をAPI料金で課金する方式になっています。2026年4月からは日本の契約に消費税10%が別途かかります。

この記事でわかること

  • Claude Codeをチームで使う方法と、TeamとEnterpriseの違い(2026年10月時点の料金・条件)
  • Standard/Premiumシートの割り振り方と、人数別の費用の目安
  • ロール(User/Admin/Owner/Primary Owner)とカスタムロールの設計
  • SSO・JIT・SCIMでメンバーを追加するときの、シートの付き方と注意点
  • managed settingsの配り方4種類と、最初に入れておきたい最小構成
  • Bedrock・Google Cloud・Foundry経由で効かない管理機能と、その代わりの手段
  • 利用上限額・分析・監査の設定と、30-60-90日の導入手順

この記事が役立つ方

  • 開発部門からClaude Codeの全社導入を頼まれた情シス・セキュリティ担当の方
  • 個人のPro/Max契約が増えてきたので、Team/Enterpriseにまとめたい CTO・開発マネージャーの方
  • Teamプランを契約済みで、権限設計や上限額の設定を詰め切れていない管理者の方
Claude Codeをチーム導入する際の管理者向けダッシュボードのイメージ

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

Anthropic公式のClaude Code GitHubリポジトリ

出典:anthropics/claude-code(GitHub)

組織でClaude Codeを使う方法は、大きく個人プラン(Pro/Max)の寄せ集め・Teamプラン・Enterpriseプランの3つです。このほか、API(Claude Console)やAmazon Bedrockなどのクラウド経由で使う方法もあります。公式の組織向けセットアップ手順では、インフラ運用が要らないTeam/Enterpriseを基本の選択肢として案内しています。

Claude Code自体の機能や使い方はClaude Codeとは?機能・料金・使い方を整理でまとめています。

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

開発者がそれぞれ個人で契約し、経費で精算する使い方です。手軽に始められますが、組織で使うには次の問題があります。

  • 支払いがまとまらない
  • 誰がどれだけ使っているか見えない
  • 組織の設定(managed settings)をサーバーから配れない
  • 退職者のアクセス停止が本人任せになる

小さな試行には使えますが、本格的に使うならTeam以上に移るのが前提です。

Teamプラン(2〜150人、Webから申し込み)

Webから申し込めて、全席にClaude Codeが含まれます。

  • 2人から150人まで(料金ページの表記は「For teams of 2 to 150」)
  • Standard席とPremium席を同じ組織で混ぜられる
  • SSO(ドメインの確認・ドメインキャプチャ)、JITプロビジョニング、一括請求、利用分析、組織・個人単位の利用上限額に対応
  • 入力したデータは既定でモデルの学習に使われない
  • SCIM・監査ログ・Compliance API・カスタムロールは使えない
  • 支払いはクレジットカード(請求書払いは不可)

Enterpriseプラン(20席から、席料金+利用分)

150人を超える組織や、監査ログ・SCIM・Compliance APIが必要な組織向けです。2026年9月に改訂された公式ヘルプでは、課金方式が次のように説明されています。

  • 1席あたり月$20(年払い)+チャット・Claude Code・Coworkの利用分をAPI料金で別途課金
  • 席料金は利用する権利の料金で、席ごとの利用枠や付属トークンはない
  • 最低席数はWebからの購入で20席、営業経由で50席(機能と席単価は同じ。営業経由は多通貨・請求書払い・後払いに対応)
  • 以前からの席課金型の契約(Chat / Chat + Claude Code など)は、次の契約更新時にこの方式へ移る。それまでは今のシート種別と利用上限のまま

Enterpriseで追加される主な機能は次のとおりです。

  • カスタムロール(グループ単位の細かい権限設定)
  • SCIM(IdPからの自動追加・自動削除)
  • 監査ログ、Compliance API、Enterprise Analytics API
  • データ保持期間の設定
  • IP許可リスト・ネットワーク単位のアクセス制御(料金ページ記載)
  • HIPAAに対応した提供形態
  • 組織単位のモデル管理(モデルの無効化、既定モデル、ロールごとの推論の強さの上限)

なお、データを保存しない設定(ZDR)は標準のEnterpriseには含まれず、Anthropicの審査を経て個別に有効化されます。データ保持の考え方はClaudeの企業向けデータ保持も参考になります。

API(Console)・クラウド経由という選択肢

Claude Console(API)、Amazon Bedrock、Google Cloud(Agent Platform/旧Vertex AI)、Microsoft Foundry経由でもClaude Codeは使えます。使った分だけ払う形になり、AWSなど既存クラウドの請求やコンプライアンスの枠組みに乗せられるのが利点です。

ただし、クラウドセッション、Routines、Code Review、Remote ControlなどClaudeアカウント(Team/Enterprise)が必要な機能は使えません。管理コンソールから配る設定(server-managed settings)も届かないため、MDMでの設定配布か、自社で動かすClaude apps gatewayを使う前提で検討する必要があります。

Team と Enterprise の違い(比較表)

Claude CodeのTeamプランとEnterpriseプランを比較する概念図

管理面で大きく差が出るのは、SCIM・監査ログ・Compliance API・カスタムロール・IP許可リストです。費用の出方も違い、Teamは席ごとの定額、Enterpriseは席料金に利用分が上乗せされます。

項目

Teamプラン

Enterpriseプラン

料金

Standard 月$20(年払い)/$25(月払い)、Premium 月$100/$125

1席 月$20(年払い)+利用分をAPI料金で課金

人数

2〜150人

Web購入は20席から、営業経由は50席から

費用の出方

席ごとの定額(席ごとに利用枠あり)

席料金+使った分(席ごとの利用枠なし)

Claude Code

全席に含まれる

含まれる(利用分はAPI料金)

コンテキスト長

モデルにより最大1M(料金ページ表記)

モデルにより最大1M(料金ページ表記)

標準ロール

Primary Owner / Owner / Admin / User

同左

カスタムロール

×

○

SSO・JIT

○

○

SCIM

×

○

監査ログ・Compliance API

×

○

Enterprise Analytics API

×

○

Claude Code分析ダッシュボード

○

○

利用上限額の設定

○

○

server-managed settings

○

○

組織単位のモデル管理

×

○

IP許可リスト

×

○

データ保持期間の設定

×

○

HIPAA対応

×

○(構成の適用が必要)

支払い

クレジットカード

カード・ACH(Web)、請求書払い・後払い(営業経由)

料金はすべてUSD・税抜です。2026年4月1日から日本の契約には消費税10%が別途かかり、Anthropicは適格請求書発行事業者として円建ての税額を記載した請求書を出しています。Claude全体の料金体系はClaudeの料金プラン解説、Claude Code単体の費用はClaude Code 料金プラン解説を参照してください。

ロールについて補足すると、料金ページの比較表ではTeamの「Role-based access」が「なし」になっていますが、TeamのヘルプページはTeamの機能として標準ロールでの権限分けを挙げています。標準の4ロールはTeamにもあり、グループ単位の細かい設定(カスタムロール)はEnterpriseだけと理解しておくと混乱しません。

どれを選ぶかの早見表

状況

おすすめ

150人以下、監査ログ・SCIMは不要、費用を定額で読みたい

Teamプラン

監査ログ・SCIM・Compliance APIが必須、150人超

Enterpriseプラン

部署ごとに使える機能やモデルを変えたい

Enterpriseプラン(カスタムロール)

AWS・GCP・Azureの請求とコンプライアンスにまとめたい

Bedrock / Google Cloud / Foundry経由(必要ならClaude apps gatewayで統制)

CIやスクリプトから使う分を、使った分だけ払いたい

API(Console)

金融・医療・公共で厳しい監査が必要

Enterpriseプラン(監査ログ・HIPAA・データ保持の設定)

Enterpriseの費用はTeamより安いとは限らない

Enterpriseは席単価が$20でも、利用分がAPI料金で上乗せされます。公式のコストガイドでは、APIで使った場合の企業の平均が開発者1人あたり月$150〜250程度(稼働日1日あたり約$13)とされています。

仮に20人がこの平均どおりに使うと、席料金$400+利用分$3,000〜5,000で月$3,400〜5,400程度(税抜)になります。同じ20人をTeamで「Standard 15席+Premium 5席(年払い)」にすると月$800です。ただしTeamは席ごとに利用枠があり、超えた分はusage credits(追加利用)の購入になるため、単純な比較はできません。重い使い方の人が多い組織ほど、利用量の見込みを出してから判断してください。

Teamプランの料金とシート設計(Standard / Premium)

Claude公式サイトの料金ページで使われているClaudeのロゴ画像

出典:Claude 公式サイト(料金)

TeamプランにはStandard席とPremium席があり、同じ組織の中で混ぜて使えます。どちらもClaude Codeが使え、違いは利用量と料金です。

Teamプランの料金表(USD・税抜、2026年10月時点)

項目

Standard席

Premium席

年払い

$20/人/月

$100/人/月

月払い

$25/人/月

$125/人/月

利用量

Proの1.25倍(1セッションあたり)

Proの6.25倍(Standardの5倍)

上限のリセット

5時間ごと+1週間ごと(全モデル共通の週上限)

同左

Claude Code

含まれる

含まれる

毎月のAPIクレジット

$20

$100

利用上限は1人ごとで、ほかのメンバーと共有できません。上限はチャットやCoworkと共通で、5時間ごとと1週間ごとに戻ります。上限を超えても使い続けたい場合は、管理者がusage credits(以前のExtra usage)を有効にし、組織・グループ・個人の単位で上限額を決めます。

TeamのAPIクレジットはClaude Codeに使えない

2026年10月時点の公式ドキュメントでは、Teamに毎月のAPIクレジットが付きます。Standard 1席$20、Premium 1席$100を合算し、上限は月$500です(例: Standard 3席+Premium 2席なら月$260)。

誤解されやすい点ですが、このクレジットはClaude API・Managed Agents・Agent SDK・Playgroundの利用分に使うもので、Claude Codeやアプリの追加利用には使えません。翌月への繰り越しもありません。受け取るには、Primary OwnerかOwnerがClaude Consoleの組織とTeamを紐づける必要があります。

StandardとPremiumの割り振り方

  • Standardが合う人: チャット中心の人、調査や小さなスクリプトが中心の開発者、PM・デザイナー・CSなど開発以外の職種
  • Premiumが合う人: 毎日Claude Codeでまとまった実装をする開発者、サブエージェントやAgent Teamsを多用する人、長時間CLIを動かす人

上限は1人ごとにかかるので、「重い使い方の人だけPremium、ほかはStandard」と分けるのが費用を抑える基本です。まずStandardで配り、上限によく当たる人だけPremiumへ上げると無駄が出にくくなります。費用を抑える運用の工夫はClaude Codeのコスト削減ガイドにまとめています。

役割・権限設計(4ロール比較とカスタムロール)

Claude Code公式ドキュメントの認証(Authentication)ページ

出典:Claude Code Docs「Authentication」

管理者の権限はロールで決まります。標準のロールはUser・Admin・Owner・Primary Ownerの4つで、Primary Ownerは組織に1人だけです。

標準ロール(4種類)

ロール

位置づけ

公式で確認できる主な権限・注意点

Primary Owner

最上位の管理者

組織に1人だけ。ライセンスを1つ使う。個人に紐づかないサービスアカウントにもできる。Enterprise Analytics APIのキーを発行できる

Owner

管理者

server-managed settingsの閲覧・編集、分析の設定(GitHub連携)、組織全体の機能のON/OFF

Admin

運用担当

メンバーの管理、Claude Code分析ダッシュボードの閲覧。server-managed settingsは編集できない

User

利用者

Claude・Claude Codeの利用

公式の権限表(Roles and permissions)は改訂が続いています。請求や招待などの操作をどのロールに任せられるかを厳密に決めたい場合は、導入時に管理画面とヘルプの原表で確かめてください。

確実に押さえておきたいのは次の3点です。

  • Claude Codeの組織設定(server-managed settings)を触れるのはOwnerとPrimary Ownerだけ。Adminに任せる運用は組めない
  • Primary Ownerを特定の個人にすると、異動・退職で引き継ぎが必要になる。サービスアカウントにしておくと運用が楽になる
  • OwnerとPrimary Ownerは自分自身を組織から外せない

カスタムロール(Enterpriseのみ)

Enterpriseでは「Organization settings > Roles」からカスタムロールを作り、IdPのグループに割り当てられます。Claude Code、Cowork、Web検索、Fast modeなどの機能を部署ごとに出し分けるときに使います。

運用で気をつける点は次のとおりです。

  • ロールが「Custom」のメンバーは既定の権限を持たず、所属グループのカスタムロールだけで権限が決まる
  • 権限は足し算。あるロールで与えた権限を、別のロールで取り消すことはできない
  • 変更の反映には最大15分かかる
  • OwnerやAdminをカスタムロールに移すと、組み込みの管理権限を失う
  • 「Identity & Access」の管理権限を持つ人は自分のロールも変えられるので、信頼できる管理者に限る
  • 旧契約でChatのみの席の人には、ロールで許可してもClaude Codeは使えない(席の制限はロールで超えられない)

カスタムロールは「どの機能を使えるか」を決めるものです。Claude Codeの中で何を実行させるか(コマンドやファイルへのアクセス)は、managed settingsで別に決めます。

メンバー管理とプロビジョニング方式の選択

メンバーの追加方法は6つあります。人数が増えたらJIT(Team/Enterprise)かSCIM(Enterpriseのみ)に寄せるのが基本です。

招待方式の比較

方式

Team

Enterprise

補足

メール招待(一括可)

○

○

21日で失効。承諾前の招待も席を1つ使う

招待リンク

既定でON

SSOなしは既定でOFF、SSO利用時は使えない

再生成・無効化すると古いリンクは使えなくなる

メンバー同士の招待

既定でON

既定でOFF

既定は管理者の承認制

同じドメインの人の参加申請

○

○

自動追加か承認制を選ぶ

JIT(SSO初回ログイン時に作成)

○

○

IdPでAnthropicのアプリに割り当てた人が対象

SCIM(自動追加・自動削除)

×

○

席数の範囲で自動追加、IdPから外すと削除

メンバーを外しても契約の席数は自動では減りません。JITやSCIMでも空き席がなければ追加されないため、席数は少し余裕を持たせておくと現場の作業が止まりません。

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

SSOとSCIMを使ったIdPとClaudeのアイデンティティ管理の構成イメージ

TeamならSSO+JIT、EnterpriseならSCIMでIdPのグループをロールとシート種別に対応づけるのが運用しやすい形です。Okta、Microsoft Entra ID、Google Workspaceなど主要なIdPに対応しています。

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

  1. 招待のみ: JIT/SCIMを使わず、手動で招待する
  2. JIT: SSOで初めてログインしたときにアカウントを作る
  3. SCIM: IdPのユーザーとグループを正として同期する(Enterpriseのみ)

自動で付くシートに注意する

JIT・SCIMでは、IdPのグループをロールとシート種別に対応づけられます。対応づけをしていない場合に既定で付くシートは、方式ごとに違います。

入り方

既定で付くシート

JIT

空いている中で最も上位のシート

SCIM

上位のシートから順に配る

招待リンク・メンバー同士の招待

最も下位のシート(なければStandard)

JITで入った人に意図せずPremiumが付き、費用が膨らむことがあります。JITを有効にする前に、グループとシート種別の対応を必ず決めておきましょう。設計例は次のとおりです。

IdPグループ

Claudeのロール

シート種別

claude-admins

Owner

Standard(管理作業中心なら)

engineering-heavy

User

Premium

engineering-general

User

Standard

non-engineering

User

Standard

SCIMを安全に有効にする順番(Enterprise)

公式ヘルプが案内している順番は次のとおりです。順番を誤ると、メンバーが一時的にアクセスを失うことがあります。

  1. グループマッピングをOFFにしたままSCIM同期を保存し、初回の同期を終える
  2. 「Groups only」で同期する
  3. グループにカスタムロール(と利用上限額)を割り当てる
  4. グループマッピングをONにし、メンバーをCustomへ移す

SCIMを有効にする前に、Claudeを使う人全員がIdPのAnthropicアプリに割り当てられているかも確認してください。

Managed Settingsでポリシーを一元管理

Claude Codeには、組織が強制する設定(managed settings)があります。ユーザーやプロジェクトの設定、コマンドラインの指定より優先され、開発者側からは上書きできません。

Claude CodeのManaged Settingsで組織ポリシーを一元配信する構成のイメージ

設定の優先順位は「managed settings > コマンドライン(--settings)> プロジェクトのローカル設定(.claude/settings.local.json)> 共有のプロジェクト設定(.claude/settings.json)> ユーザー設定(~/.claude/settings.json)」です。permissions.allow / deny のような配列は結合されるため、開発者はルールを足せても、managedのルールを消すことはできません。

なお、SSO・SCIM・シートの割り当ては管理コンソール(Claudeアカウント側)で、Claude Codeの動作はmanaged settingsで管理します。設定する場所が2か所に分かれている点を、担当者の間で共有しておきましょう。

設定を配る4つの方法

方法

配り方

読み込むタイミング

向いている組織

server-managed

管理コンソール(Organization settings > Claude Code > Managed settings)、または自社運用のClaude apps gateway

起動時に取得し、セッション中は1時間ごとに再取得

MDMがない、管理外の端末がある(Team/Enterpriseが必要)

MDM・OSポリシー

macOS構成プロファイル(com.anthropic.claudecode)、Windows HKLM\SOFTWARE\Policies\ClaudeCode(Jamf・Intune・グループポリシーなど)

起動時+30分ごと

すでにMDMで端末を管理している

ファイル

managed-settings.json(macOS /Library/Application Support/ClaudeCode/、Linux/WSL /etc/claude-code/、Windows C:\Program Files\ClaudeCode\)。managed-settings.d/ に分けて置ける

起動時+ファイル変更時

MDMがない、Linuxサーバー、自前のイメージ

Windows HKCU

HKCU\SOFTWARE\Policies\ClaudeCode

起動時+30分ごと

統制には使わない(管理者権限なしで書き換えられる)

古い置き場所の C:\ProgramData\ClaudeCode\managed-settings.json は読み込まれません。以前の手順書で配っている場合は場所を移してください。MDM向けのテンプレート(Jamf・Intune・グループポリシーなど)は公式GitHubのexamplesにあります。

server-managedとMDM・ファイル配布の違い

項目

server-managed

MDM・ファイル配布

設定する場所

管理コンソール

MDM、端末上のファイル

MDMの要否

不要

MDMまたはファイル配置の仕組みが必要

編集できる人

Owner / Primary Owner

MDM・端末の管理者

グループ別の設定

できない(全員に同じ設定)

MDMで端末を分ければできる

managed-mcp.json

配れない(managedMcpServers でリモートMCPは配れる)

配れる

Bedrock・Google Cloud・Foundry経由

届かない

効く

Console APIキーで動かすCI

届かない

効く

Coworkのセッション

届かない

効く

強さ

管理外の端末では回避されうる

管理者権限のない利用者には書き換えにくい

使い分けの目安は次のとおりです。

  • MDMのない中規模組織: server-managedから始める
  • MDMで端末を管理している組織: MDMを基本にし、管理外の端末向けにserver-managedを併用する
  • Bedrockなどクラウド経由で使う組織: MDM・ファイル配布か、Claude apps gatewayを使う

複数の配り方が重なったときの挙動

同じ端末に複数の方法で設定が届くと、既定では最初に設定を届けた1つだけが使われ、ほかは無視されます(server-managed → MDM → ファイルの順)。すべてを合成したい場合は managedSourcesBehavior で指定します。

managed-settings.d/ に置いたファイルは、ファイル名のアルファベット順にまとめて読み込まれます(例: 10-telemetry.json、20-security.json)。値が1つの項目は後のファイルが優先され、配列は結合されます。

server-managed settingsの取得とキャッシュ

  • 初回ログイン時は最大5秒待って設定を取得してから起動する
  • 取得に失敗した場合、キャッシュ(~/.claude/remote-settings.json)があればキャッシュで、なければserver-managedなしで起動する
  • api.anthropic.com に届くことが前提。プロキシ環境では事前に通信を確認する
  • 公式は「クライアント側の統制であり、セキュリティ境界ではない」と明記している。管理外の端末では、キャッシュの書き換えなどで回避されうる

フックや一部の環境変数(プロキシ・ベースURLなど)、apiKeyHelper のようにシェルを動かす設定を配ると、開発者の画面に承認の確認が出ます。拒否するとClaude Codeは終了するため、配る前に「確認が出たら承認する」ことを周知しておくと問い合わせが減ります。

Server-managed settingsで制御できる主なポリシー項目

managed settingsで強制できる主な項目です(2026年10月時点の公式ドキュメント「Decide what to enforce」より)。

統制したいこと

設定キー

ツール・コマンドの許可/確認/禁止

permissions.allow / permissions.ask / permissions.deny

個人・プロジェクト側の許可ルールを無効にする

allowManagedPermissionRulesOnly

権限確認を飛ばすモード(--dangerously-skip-permissions)を禁止

permissions.disableBypassPermissionsMode: "disable"

auto modeを禁止

permissions.disableAutoMode: "disable"

起動時の権限モード

permissions.defaultMode

OSレベルでファイル・通信を隔離し、通信先を限定

sandbox.enabled、sandbox.network.allowedDomains、sandbox.network.allowManagedDomainsOnly

組織共通のCLAUDE.md

管理用パスのファイル、claudeMd キー

MCPサーバーの制限・配布

allowedMcpServers、deniedMcpServers、allowManagedMcpServersOnly、managedMcpServers

プラグインのマーケットプレイスを制限

strictKnownMarketplaces、blockedMarketplaces

スキル・フック・MCPを個人やプロジェクトから読み込ませない

strictPluginOnlyCustomization

フックを制限

allowManagedHooksOnly、allowedHttpHookUrls

ログイン方法と組織を固定(個人アカウントでの利用を防ぐ)

forceLoginMethod、forceLoginOrgUUID

使えるAPI提供元を限定

allowedProviders

使えるモデルを制限

availableModels、enforceAvailableModels

推論の強さ(effort)の上限

maxEffortLevel

バージョンの下限・範囲

minimumVersion、requiredMinimumVersion / requiredMaximumVersion

取得できなければ起動しない

forceRemoteSettingsRefresh: true

いくつか誤解しやすい点があります。

  • managedで model を指定しても既定値になるだけで、開発者は --model で変えられます。使えるモデルを縛るなら availableModels を使います。現在の既定モデルはTeam・EnterpriseともOpus 5.5です
  • テレメトリを止めるときは env に CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 を設定します。DISABLE_TELEMETRY=1 で止めると、分析ダッシュボードのデータも止まります
  • auto modeを許可するかどうかは、Claude Codeのauto modeとはを読んで仕組みを理解してから決めると判断しやすくなります

MCPの統制の考え方はClaude CodeのMCP連携ガイド、フックの書き方はClaude Code Hooks 使い方で詳しく解説しています。

絶対に入れるべきセキュリティ設定(最小構成JSON例)

最初に配っておきたいのは、権限確認を飛ばすモードの禁止・機密ファイルの読み取り禁止・個人側の許可ルールの無効化の3つです。公式の最小例をもとにすると次のようになります。

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

1. disableBypassPermissionsMode(最優先)

--dangerously-skip-permissions などで権限確認を飛ばすモード(bypassPermissions)を禁止します。このモードは .git や .claude などの保護されたパスへの書き込み確認も飛ばすため、使うならコンテナやVMの中に限るのが公式の考え方です。

2. permissions.deny(機密ファイルと危険なコマンドを止める)

.env や secrets/ 以下の読み取りを禁止します。ただし公式の注意として、Bash(curl *) はClaudeが書いた curl という文字列に一致するだけで、/usr/bin/curl や sh -c 'curl …' までは防げません。WebFetchを禁止しても、Bashが許可されていれば curl や wget で外部へ通信できます。通信を確実に止めたいなら、sandboxの allowManagedDomainsOnly で通信先を限定してください。

3. allowManagedPermissionRulesOnly(個人側の許可ルールを無効にする)

開発者が自分の設定に allow ルールを足して抜け道を作るのを防ぎます。最初から入れると現場の作業が止まりやすいので、パイロット期間に必要な許可ルールを集めてから有効にすると混乱が少なくなります。

4. 個人アカウントへの切り替えを防ぐ

開発者が個人のClaudeアカウントでログインし直すと、組織の設定は届かなくなります。forceLoginMethod と forceLoginOrgUUID でログイン先を自社の組織に固定し、ネットワーク側でもTenant Restrictions(利用できる組織の制限)を検討してください。

セキュリティ設定全般の考え方はClaude Codeのセキュリティ・安全な使い方で詳しく扱っています。

設定が届いているかの確認方法

配った後は、開発者の端末で次の3つを確認します。

  • /status: 「Setting sources」の行に Enterprise managed settings (remote) や (file) などと表示され、どの方法で届いたかがわかる
  • claude doctor: 「Managed settings (remote)」の行で、server-managed settingsの取得結果がわかる
  • /permissions: 実際に効いている許可・禁止ルールの一覧がわかる

managed settings関連の不具合修正は直近の版でも続いています。導入時は最新版にそろえ、requiredMinimumVersion で下限を決めておくと、古い版の端末で設定が効かない事態を防げます。

forceRemoteSettingsRefreshの実務リスク

forceRemoteSettingsRefresh: true にすると、設定を取得できなかったときにClaude Codeが起動しなくなります。設定を回避されにくくなる一方、api.anthropic.com に届かなくなった時点で全員が作業できなくなります。プロキシ・VPN・回線の冗長性を確かめてから有効にしてください。

CIで動かすClaude Codeには届かない

Claude ConsoleのAPIキーで動かしているセッション(GitHub ActionsなどのCI)には、server-managed settingsは届きません。Consoleの組織とclaude.aiの組織が別扱いだからです。CIにも同じ設定を効かせたい場合は、claude setup-token で作ったトークンを CLAUDE_CODE_OAUTH_TOKEN に設定するか、ファイルで配ります。CIでの使い方はClaude Code GitHub Actions 使い方を参照してください。

Bedrock / Google Cloud(旧Vertex AI)/ Foundry利用時の管理限界

Amazon Bedrock、Google Cloud(Agent Platform/旧Vertex AI)、Microsoft Foundry経由で使う場合、server-managed settingsは取得されません。既定以外の ANTHROPIC_BASE_URL を設定した場合や、CLAUDE_CODE_USE_* の環境変数を設定した場合も同じです。

使えない主な機能は次のとおりです。

  • server-managed settings、Claude Code分析ダッシュボード
  • クラウドセッション、Routines、Code Review、Remote Control
  • Fast mode、Channels
  • 組織単位のモデル管理(availableModels・maxEffortLevel などのmanaged settingsで代わりに縛る)
  • Web検索(Bedrockのみ)

管理機能の効き方(提供元別)

管理したいこと

Team / Enterprise

API(Console)

Bedrock・Google Cloud・Foundry

Claude apps gateway経由

server-managed settings

○

×(ファイル配布で代替)

×

○(IdPグループ別に配れる)

MDM・ファイル配布

○

○

○

○

分析ダッシュボード

○

×

×

OTLPで出力

利用者ごとの上限額

○

レート制限で調整

クラウド側で調整

○

OpenTelemetry

○

○

○

○

Claude apps gatewayで統制する

クラウド経由でも集中管理したい場合は、claude コマンドに含まれる自社運用のゲートウェイ「Claude apps gateway」(claude gateway --config gateway.yaml、v2.1.195以降)が使えます。開発者は社内IdPのSSOでログインし、APIキーやクラウドの認証情報を手元に持ちません。

  • IdPのグループごとに、使えるモデルとmanaged settingsを配れる
  • 利用者ごとの上限額を設定できる
  • リクエストごとの監査ログとOTLPメトリクスを出せる

一方で、キャッシュの保持時間が短くなる、一部の最適化が使えない、HIPAA構成の対象外、といった制約もあります。公式も、SCIMやWeb・モバイル版のClaude Codeが必要ならEnterpriseのほうが向くと案内しています。

支出コントロール(組織上限 / ユーザー上限)

Claude Codeの支出コントロールと分析ダッシュボードのイメージ

費用の上振れを防ぐ仕組みは、プランによって考え方が違います。Teamは「席の利用枠+usage creditsの上限額」、Enterpriseは「利用分そのものの上限額」で管理します。

プラン別の上限の考え方

  • Team: 各席に5時間ごと・1週間ごとの利用枠があり、超えた分を使わせるかどうかを管理者がusage creditsで決める。組織・グループ・個人の単位で上限額を設定する
  • Enterprise: 席に利用枠がなく、利用分はすべてAPI料金になる。管理者が組織・グループ・個人の単位で上限額を設定する

Enterprise向けの公式ガイドでは、グループ単位+個人単位の上限から始め、組織全体の上限は控えめに使うことを勧めています。組織全体の上限に達すると全員の利用が止まるためです。上限は毎月1日0時(UTC)に戻り、組織単位の上限は75%・90%で通知が届きます。複数の上限がある場合は、個人 → グループ → 組織の順に優先されます。

「上限に当たった」と言われたときの見分け方

開発者から問い合わせがあったら、表示されたメッセージで原因を切り分けます。

表示

原因

対応

session limit / weekly limit

席の利用枠(Team)

時間が経てば戻る。開発者は /usage-credits で追加利用を管理者に申請できる

individual spend limit

管理者が決めた個人の上限額

Organization settings > Usage で引き上げを検討

org's monthly spend limit

組織全体の上限額

同上。全員に影響するため早めに判断する

上限額の決め方

最初は次の2段構えが無難です。

  1. 個人の上限額: 公式の平均(月$150〜250)を参考に、少し上に置く
  2. 組織・グループの上限額: 予算に20〜30%の余裕を持たせて暫定で置き、利用額レポートを見ながら毎月見直す

社内の契約単価で費用を表示したい場合は、managed settingsの modelPricing(v2.1.242以降)で単価を指定できます。

分析と監査(Analytics / Compliance API)

Claude Code利用状況のAnalyticsダッシュボードとコンプライアンス監査のイメージ

Team・Enterpriseとも分析ダッシュボードと利用額レポートが使え、Enterpriseでは監査ログとAPIでのデータ取得が加わります。

機能

Team

Enterprise

内容

Claude Code分析ダッシュボード

○

○

受け入れたコードの行数、提案の受け入れ率、日ごとの利用者数・セッション数、ランキング、CSV出力。閲覧はAdmin・Owner

GitHub連携の貢献指標(public beta)

○

○

Claudeが関わったマージ済みPRの数と行数。PRに claude-code-assisted ラベルが付く。ZDR有効時・GitHub Enterprise Serverでは使えない

利用額レポート(CSV)

○

○

利用者・モデルごとのトークン数と推定額

Enterprise Analytics API

×

○

Primary Ownerが read:analytics のキーを発行。2026年1月1日以降のデータを、1回31日分まで取得

監査ログ・Compliance API

×

○

managed settingsの変更履歴も取得できる

OpenTelemetry出力

○

○

どの提供元でも使える、個人別のリアルタイムな指標

Compliance APIと監査ログ(Enterprise専用)

Compliance APIや監査ログのエクスポートを使うと、誰がいつmanaged settingsを変えたかまで追えます。SplunkやMicrosoft SentinelなどのSIEMに取り込めば、ほかのシステムの監査ログと並べて確認できます。

OpenTelemetry連携

Claude CodeはOpenTelemetry(OTLP)で指標を出せます。Bedrockなどクラウド経由でも使えるため、提供元が混在する組織では、DatadogやGrafanaなど既存の監視基盤にまとめるのが現実的です。

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

Claude Codeのチーム導入を段階的に進める30-60-90日ロードマップのイメージ

いきなり全社に配らず、3段階に分けると失敗しにくくなります。

0〜30日:パイロット

  • 目的: 使い方とリスクを実際に測る
  • 対象: 10〜30人程度の、Claude Codeに慣れた開発者
  • Teamプランを契約し、SSO・ドメインの確認を済ませる
  • JITを使うなら、先にグループとシート種別の対応を決める(Premiumの付けすぎを防ぐ)
  • Primary Ownerをサービスアカウントにするか決める
  • 最小構成のmanaged settings(disableBypassPermissionsMode・deny)を配り、/status と claude doctor で届いたか確かめる
  • 主要なリポジトリに CLAUDE.md を置く(開発者向けの使い方はClaude Code 使い方ガイドが参考になる)
  • 見る指標: 週ごとの利用率、PR数の変化、上限に当たった回数

31〜60日:部門展開

  • 目的: 運用の流れを固める
  • 対象: 1〜3部門、50〜150人程度
  • usage creditsの可否と、組織・個人の上限額を決める
  • allowManagedPermissionRulesOnly: true を有効にする
  • forceLoginMethod / forceLoginOrgUUID でログイン先を固定する
  • .claude/settings.json(共有)と .claude/settings.local.json(個人用、Git管理外)の使い分けをルールにする
  • StandardとPremiumの割り振りルールを決める
  • requiredMinimumVersion でバージョンの下限を決める

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

  • 目的: 統制を仕上げ、プランを見直す
  • 150人を超えそう、または監査ログ・SCIMが必要ならEnterpriseを検討する(利用分の見込み額も出す)
  • Enterpriseに移ったら、SCIMを公式の順番で有効にし、カスタムロールと上限額をグループに割り当てる
  • 監査ログ・Compliance APIをSIEMにつなぐ
  • Bedrockなどクラウド経由も使うなら、MDM配布かClaude apps gatewayで統制する
  • 退職時の手順に「IdPからの削除 → SCIMでの削除 → 席の整理」を入れる

Claude Codeで社内ツールや業務アプリの試作が進むと、次は社内の実データや既存システムにつないで業務で使う段階になります。そこでは、権限やデータの扱い、運用・保守を誰が担うかを改めて決める必要があります。AIで作ったアプリを開発会社へ引き継ぐにはで、そのときに準備することを整理しています。

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

Teamプランがおすすめの組織

  • 2〜150人規模で、全員に同じ設定を配れば足りる組織
  • SCIMまでは要らず、SSO+JITで十分な組織
  • 監査ログの要件が厳しくない業界
  • MDMがなくても、管理コンソールから設定を配りたい組織
  • 費用を席ごとの定額で読みたい組織

Enterpriseプランがおすすめの組織

  • 150人を超える、または急に人数が増える予定の組織
  • 金融・医療・公共など、監査ログ・Compliance API・IP許可リストが必須の業界
  • SCIMでIdPと連携し、異動や退職を自動で反映させたい組織
  • 部署ごとに使える機能やモデルを変えたい組織
  • 利用量に応じた費用でも予算を組める組織

Claude Codeのチーム導入をおすすめしないケース

  • 開発者の端末が個人所有で、MDMもSSOも整えられない組織
  • Bedrockなどを必須としながら、MDMもClaude apps gatewayも用意できない組織(設定を配る手段がない)
  • 患者情報など保護対象の医療情報をClaude Codeで扱いたいのに、EnterpriseのHIPAA構成を適用できない組織(IDE拡張はBAAの対象外)
  • 個人のMaxを全員で使い続け、統制を取るつもりがない組織

よくある質問(FAQ)

Q1. 「Teamプラン」と「Agent Teams」は同じものですか?

別のものです。Teamプランは組織向けの契約プランで、Agent TeamsはClaude Codeの中で複数のエージェントを協調させる機能です。名前が似ているため社内説明では混同されがちです。機能の詳細はClaude Code Agent Teamsとはを参照してください。

Q2. Teamに付く毎月のAPIクレジットで、Claude Codeの上限超過分を払えますか?

払えません。Teamに付くAPIクレジットは、Claude API・Managed Agents・Agent SDK・Playground用です。Claude Codeの追加利用はusage creditsで別に管理します。

Q3. StandardとPremiumは途中で切り替えられますか?

管理コンソールから変更できます。ただし、契約期間の途中で変えたときの日割りの扱いは公式ヘルプで確認できなかったため、会計上の影響は契約前にAnthropicに確認しておくと安心です。JITで意図せずPremiumが付くことがあるため、定期的に席の内訳を見直してください。

Q4. managed settingsはWeb版のClaudeやCoworkにも効きますか?

managed settingsはClaude Code向けの仕組みです。チャットの機能は管理コンソールの設定やカスタムロールで管理します。Coworkのセッションはserver-managed settingsを取得せず、端末のMDM・ファイル配布の設定を読みます。CoworkについてはClaude Coworkとはで解説しています。

Q5. Bedrock経由でも、サーバー側から集中管理する方法はありますか?

server-managed settingsは届きませんが、自社で動かすClaude apps gateway(v2.1.195以降)を使えば、IdPのグループごとにmanaged settingsと使えるモデルを配り、利用者ごとの上限額も決められます。gatewayを使わない場合は、MDMかファイルでmanaged settingsを配ります。

Q6. 招待の期限が切れてしまう運用を避けるには?

21日で失効するのはメール招待です。承諾前の招待も席を使うため、放置すると席が埋まります。人数が増えてきたら、SSOを入れてJIT(Team/Enterprise)かSCIM(Enterprise)に移すのが確実です。

Q7. 個人アカウントでの利用(シャドーAI)を防ぐ決め手はありますか?

1つの設定だけでは防げません。forceLoginMethod / forceLoginOrgUUID でログイン先を固定し、MDMでClaude Codeと設定を配り、ネットワーク側でTenant Restrictionsを使い、Enterpriseなら監査ログで確認する、という組み合わせが基本です。AIエージェント全般の対策はAIエージェント セキュリティ対策ガイドも参考になります。

Q8. TeamプランでMCPサーバーを制限・配布するには?

server-managed settingsで allowedMcpServers / deniedMcpServers を配れば、接続先を制限できます。v2.1.259以降は managedMcpServers でリモートMCP(http/sse)を全員に提供することもできます。managed-mcp.json そのものを配りたい場合は、MDMかファイル配布を使います。

Q9. Claude Codeを常に新しい版に保つには?

managed settingsの minimumVersion や requiredMinimumVersion / requiredMaximumVersion で、バージョンの下限や範囲を決められます。managed settings関連の修正は直近の版でも続いているため、導入時は最新版にそろえ、下限を決めておくことをおすすめします。

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

Claude Codeをチームで安全に導入するには、次の順番で決めていくのが近道です。

  1. 人数・監査要件・費用の出方でTeam / Enterprise / クラウド経由を決める(Enterpriseは席$20+利用分、日本は消費税10%が別途)
  2. StandardとPremiumの割り振りを決める(全員Premiumにする必要はない)
  3. SSO → ドメインの確認 → JIT/SCIMの順にIdPと連携し、グループとシート種別の対応を先に決める
  4. disableBypassPermissionsMode・deny・allowManagedPermissionRulesOnly・forceLoginOrgUUID を含むmanaged settingsを配る
  5. /status・claude doctor・/permissions で、開発者の端末に届いたかを確かめる
  6. usage creditsと上限額(Teamは席の枠+追加分、Enterpriseは利用分)を決める
  7. 分析ダッシュボード・監査ログで利用状況を見える化する
  8. Bedrockなどクラウド経由なら、MDM配布かClaude apps gatewayで統制する

いちばん危ないのは、「とりあえずTeamを契約し、managed settingsを入れないまま全員に配った」状態です。パイロットの段階で設定の骨組みを作り、上限額と席の割り振りを確かめてから広げてください。

関連記事

このツールを自社のシステムや業務にどう組み込むか、ご提案します

この記事の著者

AI革命

AI革命

編集部

AI革命株式会社の編集部です。最新のAI技術動向から実践的な導入事例まで、企業のデジタル変革に役立つ情報をお届けしています。豊富な経験と専門知識を活かし、読者の皆様にとって価値のあるコンテンツを制作しています。

AI・システム開発は、開始価格を公開しています

既存システムの改修 100万円〜・PoC 300万円〜(税別)。相談内容を送っていただくと、2営業日以内に担当者からご返信します