Claude Enterpriseでカスタムロールを作成する手順
Claude Enterpriseのカスタムロールは4段階の権限優先順位と4つの設定タブで機能アクセスを一元管理します。作成手順からメンバー移行・切り戻しまでをまとめます。
Claude Enterpriseのカスタムロールとは、メンバーが使える機能・管理権限・コネクタ・モデルを、Owner権限を与えずに細かく定義する仕組みです。ロールはグループへ割り当て、メンバーのロールを「Custom」に変えると、その組み合わせだけでアクセスが決まります。同じ「役割ベースでアクセスを絞る」考え方はClaude CoworkのRBAC運用にもありますが、対象は組織全体の機能・管理権限で、Cowork内のファイル権限とは別の設定です。
カスタムロールとは何を決めるものか
カスタムロールが対象にするメンバーは、組織ロールが「Custom」に設定された人だけです。User・Admin・Ownerのメンバーは、それぞれの組み込みロールから直接権限を得るため、カスタムロールの影響を受けません。
機能へのアクセスは4段階の優先順位で決まり、最も制限が厳しい階層が勝ちます。
| 階層 | 内容 |
|---|---|
| 1. プラットフォームレベル | 内容Anthropicが契約に基づき組織単位で強制的にオン・オフにする(組織設定からは変更不可) |
| 2. 組織レベルの設定 | 内容Owner・Primary Ownerが組織全体でオン・オフにする主電源。オフならどのカスタムロールも上書きできない |
| 3. カスタムロールの権限 | 内容組織レベルでオンの機能について、メンバーが持つロールのいずれかが許可していればアクセスできる(加算方式) |
| 4. メンバー個人の設定 | 内容ロールで許可されていても、メンバー本人が自分の設定でオフにしていれば使えない |
管理者向けの権限(後述のPermissionsタブ)だけはこの連鎖の外にあります。組織レベルのトグルにもメンバー個人の設定にも縛られず、ロールが許可すればそのまま適用されます。
4つの設定タブで何を設定できるか
ロール編集画面はCapabilities・Permissions・Connectors・Modelsの4タブに分かれています。
| タブ | 設定できること |
|---|---|
| Capabilities | 設定できることChat・Web検索・Cowork・Claude Code・Claude Designなど、メンバーが使える機能 |
| Permissions | 設定できることBillingやUser Managementなど、管理画面へのアクセス権限 |
| Connectors | 設定できることSlack・Google Driveなど、組織が追加したコネクタとツールへのアクセス |
| Models | 設定できること使えるモデルの範囲、モデルごとの最大effort、既定モデル |
Capabilitiesタブは項目を1つずつ切り替える以外に、「All capabilities」(ベータ含む全機能)か「All generally available」(正式リリース済みの全機能)を選ぶ一括指定もできます。この2つを選んだロールは、新しい機能が追加されるたびに自動で権限が増えます。「Only selected」を選んだロールは、明示的にチェックした機能だけに固定されます。
Claude Codeに関わる機能では、Dynamic workflows(数時間かかる大規模なエンジニアリングタスクを1セッションで完走させる機能)が既定で組織全体オンになっている点に注意が必要です。特定グループだけ止めたい場合はそのロールでこの権限をオフにします。組織全体で止めたい場合はmanaged-settings.jsonに"disableWorkflows": trueを設定するか、Organization settings > Claude CodeのWorkflowsトグルを切ります。Chatはどのカスタムロールでも既定でオンになっており、制限したい場合は個別にオフへ切り替えます。
ロール構成のパターンを決める
ロールを作り始める前に、組織にどのパターンが合うかを決めておくと手戻りが減ります。
| パターン | 構成 | 向く組織 |
|---|---|---|
| ベース+加算型 | 構成全員に「Standard Access」を割り当て、一部だけ「Cowork Enabled」等を追加 | 向く組織ほとんどの組織(推奨) |
| 階層型 | 構成Full Access・Standard Access・Restricted Accessの3段階 | 向く組織権限差がシンプルな組織 |
| 部門型 | 構成Engineering・Research・Businessなど部門名そのままのロール | 向く組織部門ごとに使う機能が明確に違う組織 |
| 管理委譲型 | 構成Billingだけを持つ「Finance」など、機能なしで管理権限だけを渡すロール | 向く組織経理・法務など管理業務だけを切り出したい組織 |
ベース+加算型が多くの組織で扱いやすいのは、権限が加算方式であるためです。全員に共通のベースロールを敷き、必要な人だけ追加のロールを重ねる構成は、組み合わせても権限同士が衝突しません。
カスタムロールを作成する手順
作成はOrganization settings > Rolesから行います。
- Organization settings > Rolesを開く
- 「Add role」をクリックする
- ロール名を入力する(例: 「Developer」「Restricted」)
- このロールを割り当てるグループを選ぶ
- Capabilitiesタブで機能を1つずつ切り替えるか、「All capabilities」「All generally available」を選ぶ
- Permissionsタブで管理権限を設定する(任意)
- Connectorsタブでコネクタ権限を設定する(任意)
- Modelsタブでモデルアクセスと既定モデルを設定する(任意)
- 「Save role」をクリックする
編集も同じ画面から行い、変更は「Save role」で保存します。ロールの変更が反映されるまで最大15分かかることがあり、メンバー側でブラウザーの再読み込みが必要になる場合があります。ロールを削除すると、割り当てていたすべてのグループから権限が外れます。所属メンバーは、他のロールが同じ権限を重ねて許可していない限り、その権限を失います。
管理者権限を委譲する(Permissionsタブ)
管理権限は7つのエリアに分かれ、それぞれ「No access」「Can view」「Can manage」の3段階で設定します。
| エリア | Can view | Can manage |
|---|---|---|
| Identity & Access | Can viewSSO・IPアローリスト・グループ/ロール定義の閲覧 | Can manage上記の編集、グループ・ロールの作成 |
| Billing | Can viewプラン・請求先・利用額の閲覧 | Can manageシート数変更・支払い方法・支出上限の編集 |
| Analytics | Can view利用状況分析の閲覧 | Can manage(Manageは無い) |
| Privacy | Can viewデータ保持設定・共有設定の閲覧 | Can manage保持期間の編集・データエクスポートの実行 |
| User Management | Can view(Viewは無い) | Can manageメンバーの招待・ロール変更・削除 |
| Libraries | Can view(Viewは無い) | Can manage組織共有スキル・プラグイン・コネクタの管理 |
| Directory management | Can view(Viewは無い) | Can manageディレクトリ掲載の申請・管理 |
管理権限にも及ばない領域があります。OwnerやAdminを他のロールへ変更する操作、Console側のAPIキー・ワークスペース管理、コンプライアンスAPIやセキュリティキーの管理、組織レベルの機能トグルそのものは、Owner・Primary Ownerだけの領域として残ります。
コネクタ権限の決まり方
コネクタとツールへのアクセスは、4段階の判定を順番に通過して決まります。
- ロールの許可: 各コネクタ・ツールを「Always allow」「Needs approval」「Blocked」のいずれかに設定する
- 複数ロール間の集約: メンバーが複数のロールを持つ場合、最も許可の広いものが採用される(加算方式)
- 組織全体のツールポリシー: Organization settings > Connectorsで設定した上限が天井になり、ロール側の許可はこれより広げられない
- メンバー本人の設定: 上記までで決まった実効上限の範囲内で、メンバーが自分の承認方法を選ぶ
新規作成したロールは、すべてのコネクタが「Needs approval」から始まります。Anthropicが組織に対してコネクタ権限を有効化した時点で、既存の全ロールに「All connectors: Always allow」が自動で付与され、有効化の前後でメンバーのアクセスは変わりません。そこから組織のポリシーに合わせて絞り込んでいきます。IDプロバイダー経由でコネクタ認証そのものを一括管理する設定は別にあり、Claude Enterpriseでコネクタを一括認証する設定手順で扱っています。
Cowork側には別の設定があります。「Allow "Always allow" for connector tools」という組織設定が既定でオフになっており、これがオフの間は、ロールと組織ポリシーの両方が「Always allow」でも、書き込み系のツールはタスクごとに承認が必要なままです。ロール側の設定では上書きできません。
Claude Codeを使うメンバーには、さらに5層目の判定が加わります。Managed Settingsのポリシーとここまでで決まったコネクタ権限は、どちらか制限の厳しい方に合成され、両方が許可した場合だけ確認なしでツールを呼び出せます。Managed Settingsで制限している組織は、ロール側だけ緩めても実効権限は広がりません。
グループ作成からメンバー移行までの手順
ロールを作り終えたら、次はグループを作り、メンバーを段階的に移行します。移行前に必ずメンバー一覧をCSVでバックアップしておくと、想定外の権限喪失が起きたときに復旧の手がかりになります。
グループの作り方そのものはClaude Enterpriseのグループ支出上限を設定する手順で扱っています。グループにロールを割り当てたら、メンバーの組織ロールを「Custom」に変更する段階に進みます。移行経路は2つです。
| 経路 | 使う場面 |
|---|---|
| Path A: グループマッピングの利用 | 使う場面すでにIDプロバイダーのグループをロールへ直接マッピングする設定を使っている組織 |
| Path B: 一括割り当てツール | 使う場面Organization settings > MembersでRole/Groupフィルターを使い、対象メンバーを選んで「Update # selected」からCustomへ変更する |
いきなり全社員を移行すると、設定ミスの影響範囲が組織全体に及びます。1つの部署やチームをパイロットとして先に移行し、アクセスが想定通りか確認してから対象を広げる進め方が実務的です。デュアルシートのEnterpriseプラン(Chat / Chat + Claude Codeのシート種別がある契約)では、カスタムロールがシート単位の制限を上書きしない点にも注意してください。ロールがClaude Codeを許可していても、Chat専用シートのメンバーは使えません。
組織レベルの機能を有効化するタイミング
ロール・グループ・メンバー移行がすべて終わるまで、対象の機能を組織レベルで有効化しないでください。組織のトグルは「全員に配る」スイッチではなく、「ロールベースの割り当て対象にする」スイッチだと捉えると順序を間違えにくくなります。
先に機能を有効化してからメンバーをCustomへ切り替えると、切り替えが完了するまでの間、その機能が旧ロールの既定権限で使える状態になります。ロール・グループ・移行の準備が整ってから組織レベルのトグルを入れる順序を守れば、この隙間は生まれません。
設定ミスに気づいたときの切り戻し
移行後にロール構成の誤りに気づいた場合は、まず移行時に有効化した組織レベルの機能をオフに戻します。次に、影響を受けたメンバーの組織ロールを元の組み込みロール(User等)へ戻します。これにより、そのロールが持つ静的な権限が即座に復活し、カスタムロールの適用は止まります。原因を調整したうえで、あらためて移行をやり直します。
グループマッピングを有効にしたことでOwner・Admin自身のアクセスを失った場合は、SCIM連携先のIDプロバイダー側でOwner・Adminに紐づくグループの割り当てを確認し、対象グループへ戻します。同期が完了すればアクセスは復旧します。
導入後に権限を確認する方法
Organization settings > Members(またはGroups)で対象の行にある「⋮」メニューから「View effective role」を選ぶと、そのメンバーが持つすべての機能・管理権限・コネクタ権限と、それぞれをどのロールが付与しているかが一覧表示されます。この画面は読み取り専用で、変更はロール編集画面から行います。
検証では、権限を持たないはずのメンバーで実際に機能がグレーアウトしているか、権限を持つはずのメンバーで正常に動くかの両方を確認します。複数グループに属するメンバー、どのグループにも属さないメンバー、SSO経由で新規参加したメンバーといった境界ケースも忘れずに確認してください。特にグループ・ロールの割り当てが1つも無いまま移行したメンバーは、対象機能へのアクセスをすべて失うため、移行前の一括割り当て画面で「未割り当てのメンバーが残っていないか」を必ずチェックします。
よくある質問
既存のOwnerメンバーの管理権限だけを絞りたいのですが可能ですか
できません。Owner・Primary Ownerは常にすべての機能へフルアクセスします。権限を絞りたい場合は、そのメンバーの組織ロールをCustomへ変更し、必要な権限だけを持つグループへ割り当てます。ただしこの操作でOwner権限自体は失われます。
複数の子組織を持つ場合、カスタムロールの割り当ては共有されますか
されません。グループ本体とSCIM同期は親組織レベルで管理されて全子組織に共有されますが、ロールの割り当てと支出上限は子組織ごとに独立して設定します。ある子組織での変更が他の子組織に波及することはありません。
Dynamic workflowsを特定チームだけ止めたい場合はどうしますか
対象グループに割り当てたロールのCapabilitiesタブで、この権限をオフにします。組織全体で止めたい場合はmanaged-settings.jsonのdisableWorkflowsか、Organization settings > Claude CodeのWorkflowsトグルを使います。
「Public projects」機能をロールで制限しても、組織側で無効化されていたら意味がありませんか
その通りです。組織レベルの設定は階層の2番目にあり、ここでオフにするとどのカスタムロールも上書きできません。組織全体でプロジェクト公開自体を止める手順はClaude組織のプロジェクト公開を無効化する方法にまとめています。
モデルへのアクセスがメンバーの一覧に表示されません
組織レベルでそのモデルが無効化されているか、メンバーが持つどのロールもそのモデルを許可していないかのどちらかです。組織レベルの無効化はOwner・Adminを含む全員に影響します。
まとめ
Claude Enterpriseのカスタムロールは、Capabilities・Permissions・Connectors・Modelsの4タブでメンバーの機能アクセスを定義し、組織ロールが「Custom」の人にだけ適用されます。アクセスの可否は組織レベルの設定を天井に、複数ロールの許可を加算する形で決まるため、ベースロールに加算ロールを重ねる構成が扱いやすくなります。ロール・グループを先に作り、メンバーをCustomへ移行してから組織レベルの機能を有効化する順序を守ることが、移行時の権限漏れを防ぐ最大のポイントです。