Claude Enterpriseのグループ支出上限を設定する手順
Claude Enterpriseのグループは支出上限・カスタムロール・リソース共有をまとめて管理する単位です。作成手順、個人上限との優先順位、Customロールが効かなくなる原因、SCIM同期の落とし穴を扱います。
Claude Enterpriseのグループとは、メンバーを部署やチームの単位でまとめ、支出上限・アクセス権限・リソース共有を一括で適用する仕組みです。メンバー1人ずつ設定する手間を省き、グループ単位で予算とアクセスを統制できます。
Claude Enterpriseのグループとは
グループを作ると、3つのことができるようになります。支出上限をグループの全員へ一括適用すること、カスタムロールによるアクセス制御をグループ単位で振り分けること、プロジェクトやスキル、プラグインをグループへまとめて共有することです。
1組織あたり作成できるグループは最大1,000個です。1人のメンバーが所属できるグループ数に上限はありませんが、250個を超えて所属すると動作が遅くなることがあります。グループは手動で作成するほか、IDプロバイダーからSCIM経由で同期することもできます。
グループはプラグインの配布範囲を決めるのにも使われます。マーケットプレイスの各プラグインには、グループ単位の上書きを設定できます。選べるのは「Available to install」「Installed by default」「Required」「Not available」で、対象はチャット・Cowork・Claude Codeです。Coworkのロール設計全般はClaude CoworkのRBAC運用にまとめています。
グループを管理できるのは、Owner・Primary Owner、またはIdentity & Access権限が「Can manage」のカスタムロールを持つメンバーです。支出上限の設定には、Billing権限が「Can manage」のカスタムロールか、Owner・Primary Ownerが必要です。
グループを作成する手順
作成はOrganization settings > Groupsから行います。
- 「Add group」をクリックする
- Group nameを入力する
- 任意でDisplay nameを入力する(プロジェクト共有の選択画面など、製品内の表示でGroup nameの代わりに使われる。空欄ならGroup nameのまま)
- このグループに割り当てるカスタムロールを選ぶ(任意)
- Visibility settingsで、発見・共有・閲覧を許可する範囲を選ぶ(任意)
- メンバーを検索して追加するか、「Add all members」で組織の全員を追加する
- 「Add group」をクリックして保存する
作成後に直す場合は、一覧でグループをクリックすると編集フォームが開きます。複数のグループをまとめて変えるときは、チェックボックスで選んで「Edit settings」を押します。
グループの可視性 — 3つのトグルで何が変わるか
可視性は既定ですべてオフで、オフのグループは管理者向けの画面にしか出てきません。メンバーが共有先に選べるようにするには、次の3つを必要な分だけ開きます。
可視性設定の3つのトグル
Discover this group
メンバーがグループ名で検索できます。所属者・支出上限・ロールの割り当ては見えません。
Share resources with this group
メンバーがプロジェクト、スキル、プラグインをこのグループへ共有できます。
See group members
メンバーが所属者の名前とメールアドレスを閲覧できます。
各設定は「Group members(所属者のみ)」か「Everyone(組織全員)」に許可範囲を絞れます。両方のチェックを外せば、その設定はオフのままです。Owner・Primary Owner、およびIdentity & Access権限を持つカスタムロールは、可視性にかかわらず常にすべてのグループを見られます。
変更した設定がアプリに反映されるまで、数分かかることがあります。保存した直後にメンバーの画面で確認して「効かない」と判断しないほうが安全です。
親組織の配下に複数の子組織がある場合、グループ本体・所属メンバー・SCIM同期は親組織で管理され、全子組織に共有されます。一方、可視性・ロールの割り当て・支出上限は子組織ごとに設定します。ある子組織で変えても他の子組織には響きません。
グループ単位で支出上限を設定する
支出上限はメンバー1人あたりの月次上限です。グループに設定すると、所属する全メンバーへ同じ上限が適用されます。SCIMで同期したグループも、手動で作ったグループと同じように上限を設定できます。
グループの支出上限を設定する流れ
- 1
Organization settings > Usageを開く
「By group/tier」タブを選びます。
- 2
対象グループのメニューから上限編集を開く
グループの右側にあるメニューボタンから「Edit limits」を選びます。
- 3
上限の種類と金額を決める
「No member limit」(上限なし)か「Member limit」(金額を指定)を選び、金額を入力します。
- 4
保存する
「Save」をクリックします。個人上限を持つメンバーには、この上限は効きません。
上限の変更に必要なのはIdentity & Accessではなく、Billing権限です。グループは作れるのに「Edit limits」へたどり着けない場合は、権限の種類が違っています。
上限に当たったメンバーの把握には、Organization settings > Usage上部の「Blocked by a spend limit」が使えます。ただしこの表示は、使用量ベース(usage-based)のEnterpriseプラン向けに作られています。使用量ベースの席がない組織では、いま上限に達している、または近づいているメンバーの人数しか分かりません。
個人上限・グループ上限・上限なしの優先順位
メンバーの実効上限は、次の順に決まります。
| 優先順位 | 条件 | 適用される上限 |
|---|---|---|
| 1 | 条件個人に上限が設定されている | 適用される上限所属グループに関係なく個人の上限 |
| 2 | 条件個人に上限がなく、上限つきグループに所属 | 適用される上限複数所属なら「Multi-group spend limit」の設定に従う |
| 3 | 条件個人にもグループにも上限がない | 適用される上限上限なし |
1人が上限つきの複数グループに入っているとき、どちらを採用するかは組織で1つの設定です。場所はOrganization settings > Usageの「Spending defaults」です。「Member limit from groups」のプルダウンから「Lower group limit」か「Higher group limit」を選びます。
「Lower group limit」は、大きなグループに広めの上限を敷き、特定チームだけ厳しく絞るときの選択肢です。「Higher group limit」は、大きなグループに保守的な基準値を置き、特定チームへ余裕を持たせたいときに向きます。この設定は組織全体に効くので、片方のチームの都合で切り替えると、複数グループに入る他のメンバーの上限も動きます。
上限が思った通りに効かないときの切り分け
支出上限まわりの相談は、突き詰めると次のどれかに当たります。上から順に確認すると、原因に早くたどり着けます。
| 症状 | まず疑うこと | 見る場所 |
|---|---|---|
| グループに上限を付けたのに、あるメンバーだけ変わらない | まず疑うことそのメンバーに個人上限がある(個人が常に優先) | 見る場所Organization settings > Usageの個人設定 |
| 複数グループの所属者の上限が想定と逆 | まず疑うこと「Member limit from groups」が高い方(Higher)になっている | 見る場所Spending defaults |
| 一部のグループの所属者だけ上限がない | まず疑うことそのグループ自体が「No member limit」のまま | 見る場所By group/tierタブ |
| 上限は設定したが「Edit limits」が出ない | まず疑うことBilling権限がない | 見る場所自分のロールの権限 |
上限は「個人 → グループ → なし」の順にしか読まれません。グループの上限を下げて効かせたいなら、先に個人上限が残っていないかを見るのが近道です。
Customロールで権限が消えたように見える原因
グループはアクセス権限の一元管理にも使えます。メンバーのロールを「Custom」にすると、そのメンバーの機能アクセスは所属グループに割り当てられたカスタムロールだけで決まります。User・Admin・Ownerの既定の権限は引き継がれません。
導入は、次の順で進めるのが公式の手順です。
Customロールへの移行の順序
- 1
カスタムロールを作る
Organization settings > Rolesで、必要な権限を持つロールを作ります。
- 2
グループを作り、ロールを割り当てる
手動で作るか、IDプロバイダーから同期します。
- 3
メンバーを入れ、ロールをCustomにする
Organization settings > Membersで、各メンバーのロールを「Custom」に切り替えます。
- 4
最後に、組織レベルで機能を有効化する
先に有効化すると、切り替えが終わるまでの間、旧ロールの権限で機能に触れる時間ができます。
ロールをCustomにしたメンバーが、どのグループにも属していない、または所属グループにロールが割り当てられていない場合、権限はゼロです。どの製品も使えず、サインイン時に設定ページへ着地します。
もう1つ、見落としやすい罠があります。SCIMのディレクトリ同期でグループマッピングを有効にしている場合、メンバーのロールはIDプロバイダー側のグループ対ロールの対応で決まり、同期が管理します。マッピングの有効化前にCustomにしていたロールは、次のフル同期で再計算され、マッピング上のロールに戻ります。同期が走るまでは普通に動き、戻った事実は監査ログにも残りません。そのため「カスタムロールの権限が突然効かなくなった」ように見えます。
Customのままにしたいメンバーは、IDプロバイダー側で「Custom」に対応づけたグループへ入れます。対応づけはOrganization settings > Organization and accessで行い、そのあと同期を実行します。
「Public projects」のような機能アクセスも、グループに割り当てたカスタムロールで個別に開放や制限ができます。組織全体でその機能自体を止めたい場合は、ロールより前段の組織レベルの設定が優先されます。手順はClaude組織のプロジェクト公開を無効化する方法にあります。カスタムロールの権限設計そのものはClaude Enterpriseでカスタムロールを作成する手順で扱っています。
SCIM同期で起きること
IDプロバイダー側のグループは、SCIMで自動的にClaudeへ同期されます。同期されたグループは、カスタムロールの割り当ても支出上限も、手動作成のグループと同じように使えます。ただしClaude側では名前の変更も削除もできず、所属メンバーの管理もIDプロバイダー側で行います。
自動の同期は、IDプロバイダーがWorkOSへ変更をプッシュするたびに走ります。Claude側はWorkOSを1分ごとに確認してキューで処理するため、反映は通常数分以内でも、混雑時には数時間かかることがあります。「グループに入れたのにまだ上限が変わらない」ときは、まず時間を疑う余地があります。
手動で同期するボタンは、公式ヘルプの2つのページで名前が違います。グループ管理のページは、Groups画面の「SCIM Sync」ボタンと書いています。SCIM同期の解説ページは、同じ画面の「Check for updates」から同期するメンバー・グループ・両方を選ぶと書いています。画面のバージョンによって呼び名が違うと考えられるので、ボタンが見つからないときは両方の名前で探してください。Organization settings > Organization and accessのUser provisioningにある「Sync」ボタンからも同期できます。
手動同期の所要時間は、100メンバーで約1分が目安です。1,000人規模の組織では約10分かかります。同期を実行する前には、追加・削除・変更される人数のプレビューが表示されます。想定と違う人数、たとえば退職者より明らかに多い削除件数が出たら、実行せずに中止してIDプロバイダー側のディレクトリとマッピングを確認します。削除が極端に多い場合は警告も出ます。
再同期には、グループ運用に直結する注意が4つあります。
- ロールのマッピングが不完全だと、含まれないメンバーが組織から外れます(席の階層のマッピングは別で、含まれなくても外れません)
- メンバーのメールアドレスを更新すると、旧アドレスのメンバーが外れて新しいメンバーが作られます
- プロビジョニングモードをSCIMに切り替えると、IDプロバイダーのディレクトリにいないメンバーが外れます
- 同じ親組織の下でSCIMを使う組織は、1つ再同期すると他にも連鎖します。同じ親組織を共有するサンドボックス組織も含まれます
ネストしたグループの扱いも見落としやすい点です。Claudeが対応するのは直接所属だけで、IDプロバイダー側でグループの中にグループを入れ子にしていても、その関係はSCIM経由では無視されます。一部のプロバイダーはプッシュ前にフラット化するため、その場合は子グループのメンバーも直接の所属者として現れます。動作はプロバイダー次第なので、導入前に確認します。
グループを削除・編集するときに何が起きるか
グループの削除は、割り当てていたカスタムロールの定義に影響しません。ロールは残り、他のグループにも使えます。組織からメンバーが外れることもありません。
影響が出るのは共有だけです。削除したグループに共有していたプロジェクトへのアクセスは失われ、他の経路でアクセス権を持たないメンバーは見られなくなります。
「Share resources with this group」をオフにしても、止まるのは新規の共有だけで、既存の共有は取り消されません。取り消すには、編集画面のVisibility settingsで「Remove this group's access to all[件数]projects」を選び、グループを保存します。この操作は既存の共有だけを取り消すので、将来の共有も止めたいなら、先ほどのオフ設定も併せて行います。取り消しはバックグラウンドで動きます。共有プロジェクトが1,000件を超えるグループでは、完了まで数分以上かかります。
支出上限をどの粒度で設計するか
上限をどの単位に置くかは、組織の規模とSCIM運用の有無で変わります。
| 組織の状況 | 向いている設計 |
|---|---|
| 数十人規模で部署が少ない | 向いている設計全メンバーを入れた全社共通のグループ(「Add all members」で作成)に1つの上限を設定 |
| 部署ごとに予算が大きく異なる | 向いている設計部署別グループを作り、それぞれに個別の上限 |
| 特定メンバーだけ特別扱いしたい | 向いている設計個人の支出上限を設定(グループ上限より優先される) |
| IDプロバイダーでグループを管理済み | 向いている設計SCIM同期を有効化し、手動作成と二重管理しない |
大半のメンバーをグループ管理に任せ、例外的な数人だけ個人設定を残す組み合わせは崩れにくい設計です。この記事で扱った上限は、メンバー1人ごとの月次上限です。グループ全体で1つの月次予算を共有する別レイヤーの機能(ベータ)もあります。こちらはClaude Enterpriseのプール型グループ予算(ベータ)を設定するで扱っています。
よくある質問
グループとカスタムロールは同時に使う必要がありますか
必須ではありません。支出上限だけを目的にグループを作り、アクセス制御はUser・Admin・Ownerの組み込みロールのまま運用できます。
Teamプランでもグループ機能は使えますか
公式ヘルプはグループと支出上限の機能をEnterpriseプラン向けと案内しています。TeamとEnterpriseの違い全般はClaude Enterpriseとはにあります。
まとめ
グループは、上限を人ではなく所属で決める仕組みです。上限が効かないときはまず個人上限を、権限が消えたときはまずグループマッピングによるロールの巻き戻しを疑うと、原因に最短でたどり着けます。