Claude Enterpriseでカスタムロールを作成する手順

Claude Enterpriseのカスタムロールとは、メンバーが使える機能・管理権限・コネクタ・モデルを、Owner権限を与えずに細かく定義する仕組みです。ロールはグループへ割り当て、メンバーの組織ロールを「Custom」に変えると、その組み合わせだけでアクセスが決まります。同じ「役割ベースでアクセスを絞る」考え方はClaude CoworkのRBAC運用にもありますが、対象は組織全体の機能・管理権限で、Cowork内のファイル権限とは別の設定です。

ロールが効くのは「Custom」のメンバーだけ

カスタムロールの対象は、組織ロールが「Custom」の人だけです。User・Admin・Owner・Primary Ownerは組み込みロールから直接権限を得るので、カスタムロールを割り当てても何も変わりません。管理権限(後述)をUserロールの人に足すこともできず、足したいときはその人をCustomに変えます。ただし、それまで持っていた組み込みロールのアクセスは失われます。

IDプロバイダー(IdP)と連携している組織では、次の3点で「ロールを作ったのに効かない」が起きます。

• SCIMのグループマッピングを有効にした組織では、メンバーのロールは同期が管理します。マッピング有効化の前にCustomにしたメンバーは、「Custom」にマップされたIdPグループに入っていない限り、次のフル同期で元のマップ先ロールへ戻ります
• IdPグループを「User」にマップしたまま、同じSCIMグループにカスタムロールを割り当てても、ロールの権限は適用されません。メンバーは割り当て済みのロール(User)から権限を得ます
• 招待のみまたはJITプロビジョニングの組織では、RBACに使えるのは手動で作ったグループだけです。SCIMで同期したグループは使えません

SCIMでロールを管理する場合は、もう1点あります。Primary Ownerは、グループマッピングでは割り当てられません。Members画面での手動移譲だけが経路です。Owner・Adminはマップ済みグループに入っていないと、マッピング有効化時に外されます。

JITプロビジョニングでIdPグループを「Custom」にマップした場合も要注意です。JITはロールの種類を割り当てるだけで、グループの所属は同期しません。そのため該当ユーザーはログイン後に何も使えなくなります。対処は、Organization settings > Groupsで該当ユーザーを適切なグループに手動で追加するか、プロビジョニングをSCIMディレクトリ同期に切り替えることです。

機能アクセスが決まる順序

機能へのアクセスは、4段階を上から順に通り、最も制限が厳しい階層が勝ちます。

優先順位

機能アクセスの判定(上ほど強い)

1. 1

   プラットフォームレベル

   Anthropicが契約に基づき、組織単位で機能を強制的にオン・オフにします。組織設定からは変更できません。

2. 2

   組織レベルの設定

   Owner・Primary Ownerが組織全体でオン・オフにする主電源です。ここでオフなら、どのカスタムロールも上書きできません。

3. 3

   カスタムロールの権限

   組織レベルでオンの機能について、メンバーが持つロールのどれか1つが許可していればアクセスできます。

4. 4

   メンバー個人の設定

   ロールで許可されていても、本人が自分の設定でオフにしていれば使えません。

3段階目は加算方式です。複数のグループに属するメンバーは、全ロールの許可の和集合を得ます。たとえば「All Users」グループにStandard Access(Web検索・メモリ)、「Engineering」グループにDeveloper(Cowork・Claude Code)を割り当てると、その人は4つすべてを使えます。裏を返せば、あるロールで別のロールの許可を打ち消すことはできません。

管理権限だけは、この連鎖の外にあります。組織レベルのトグルにもメンバー個人の設定にも縛られず、ロールが許可すればそのまま適用されます。

4つの設定タブで何を設定できるか

ロール編集画面はCapabilities・Permissions・Connectors・Modelsの4タブに分かれています。

Capabilitiesタブは項目を1つずつ切り替える以外に、「All capabilities」(ベータとリサーチプレビューを含む全機能)か「All generally available」(正式リリース済みの全機能)を選べます。この2つを選んだロールは、新しい機能が追加されるたびに権限が自動で増えます。「Only selected」のロールは、チェックした機能だけに固定されます。

Customロールのメンバーは、Userロールと違い、組織で有効な機能を自動では継承しません。使わせたい機能は、すべていずれかのロールが明示的に許可する必要があります。

Claude Codeに関わる機能では、Dynamic workflows(数時間かかる大規模なエンジニアリングタスクを1セッションで完走させる機能)が組織全体で既定オンです。特定グループだけ止めたい場合は、そのロールでこの権限をオフにします。組織全体で止めるなら、managed-settings.jsonに"disableWorkflows": trueを設定するか、Organization settings > Claude CodeのWorkflowsトグルを切ります。

Chatはどのカスタムロールでも既定でオンです。制限したいロールでは個別にオフにします。

Claude Designには権限が2つあります。claude.ai/designの単体版はCapabilitiesの「Claude Design」で、会話内とArtifactsタブのClaude DesignはArtifacts配下の「Design」で別々に制御します。

旧デュアルシートのEnterpriseプラン(ChatとChat + Claude Codeの2種)では、カスタムロールでシート側の制限は上書きできません。Chat専用シートのメンバーは、ロールがClaude Codeを許可しても使えません。逆に、ロールがchat権限を付けなければ、シートの種類にかかわらずChatは使えません。

Modelsタブには、組織レベルのモデル設定が天井としてかかります。組織で無効なモデルは、ロール側で有効にできません。複数ロールを持つメンバーは、モデルの許可が加算され、effortの上限は最も高いものが採用されます。Haikuモデルは常に有効で、無効にできません。

ロール構成のパターンを決める

ロールを作り始める前に、組織にどのパターンが合うかを決めておくと手戻りが減ります。

ベース+加算型が扱いやすいのは、権限が加算方式だからです。共通のベースロールに、必要な人だけ追加ロールを重ねても、権限同士は衝突しません。

カスタムロールを作成する

作成はOrganization settings > Rolesから行います。

1. Organization settings > Rolesを開き、「Add role」をクリックする
2. ロール名を入力する(例: 「Developer」「Restricted」)
3. このロールを割り当てるグループを選ぶ
4. Capabilitiesタブで機能を切り替えるか、一括指定を選ぶ
5. Permissions・Connectors・Modelsの各タブを必要に応じて設定する(任意)
6. 「Save role」をクリックする

編集も同じ画面からで、変更は「Save role」で保存します。反映までは最大15分かかることがあり、メンバー側でブラウザーの再読み込みが必要になる場合があります。ロールを削除すると、割り当て先のすべてのグループから権限が外れます。所属メンバーは、他のロールが同じ権限を許可していない限り、その権限を失います。

管理権限を委譲する(Permissionsタブ)

管理権限は、エリアごとに「No access」「Can view」「Can manage」の3段階で設定します。Can viewは同じ画面を読み取り専用で見せ、Can manageは閲覧を含む読み書きです。エリアの中で、個別のページや設定だけを許可することはできません。

エリアの数は、公式ページ同士で食い違っています。ロール管理のページはClaude Design Adminを含む8エリアを挙げ、導入手順のページがPermissionsタブの項目として並べるのは7エリア(Claude Design Adminなし)です。Librariesの説明には「ディレクトリ管理も含む」とあり、別エリアのDirectory managementと重なって見えます。

管理権限を付けても、組織設定のどのページが開くかは権限ごとに決まっています。

権限のないエリアは、そのメンバーの組織設定から非表示になります。Analyticsだけは組織設定ではなく、ユーザーメニューのSettings > Analyticsから見ます。

管理権限が及ばない領域もあります。OwnerやAdminの付与・剥奪、Console側のAPIキー・ワークスペース管理、コンプライアンスAPIやセキュリティキーの管理、組織レベルの機能トグルは、Owner・Primary Ownerだけの領域として残ります。

コネクタ権限の決まり方

コネクタの各ツールは、「Always allow」「Needs approval」「Blocked」のいずれかで許可します。コネクタ単位で「Custom」にすると、ツールごとに別々に設定できます。判定は次の順に進みます。

1. ロールの許可: 各コネクタ・ツールにロールが付けた設定
2. 複数ロール間の集約: メンバーが複数のロールを持つなら、ツールごとに最も許可の広いものが採用される
3. 組織全体のツールポリシー: Organization settings > Connectorsの設定が天井になり、ロール側は広げられない
4. メンバー本人の設定: 上記で決まった上限の範囲内で、本人が承認方法を選ぶ

ロールと組織ポリシーは、厳しい方が実効の上限になります。ロールが「Always allow」でも組織ポリシーが「Needs approval」なら、メンバーの個人設定から「Always allow」は消え、「Ask」と「Never」だけが残ります。ロール側が「Blocked」ならツールはグレーアウトします。

一部のツールだけを渡すこともできます。たとえばJiraを「Custom」にして search_issues だけ「Needs approval」、他のツールを「Blocked」にすると、そのロールのメンバーは検索だけできます。チケット作成を頼むと、エラーではなく「そのためのツールがありません」という返答になります。

新規作成したロールは、すべてのコネクタが「Needs approval」から始まります。Anthropicが組織のコネクタ権限を有効化した時点では、既存の全ロールに「All connectors: Always allow」が自動で付き、メンバーのアクセスは前後で変わりません。そこから絞り込んでいきます。

あとからコネクタを追加したときの扱いは、「All connectors」行の設定で変わります。「Always allow」「Needs approval」「Blocked」の行なら、追加分も同じ水準で自動的にカバーされます。「Custom」の行なら、追加分は設定するまで「Blocked」として扱われます。

加算方式のため、あるロールでコネクタを「Blocked」にしても、別のロールが許可しているメンバーには効きません。コネクタ行には、他のロールが違う水準で許可しているときの警告が出て、該当ロールへのリンクが付きます。

OwnerとAdminは、設定のためにすべてのコネクタが常に見えます。ロール側の設定は、Customのメンバーにしか効きません。

この権限が及ぶのは、組織がOrganization settings > Connectorsで追加したコネクタだけです。メンバーが自分のPCで動かすローカルのコネクタと、サードパーティ基盤上のCoworkは対象外で、後者にはMDMを使います。Anthropicのサーバーで強制されるため、Web・デスクトップ・モバイル・Cowork・Claude Codeのどこでも効きます。ただしモバイルでは、ブロック済みのツールがコネクタ設定上でしばらく有効に見えることがあっても、呼び出しは拒否されます。

メンバーがコネクタにつなぐ方法は、Individually(各自が認証)とManaged authorization(管理者側で一括認証)から選びます。「All connectors」行で既定を決め、コネクタごとに上書きもできます。両方がオンのコネクタでは、Managedが先に試されます。

IDプロバイダー経由でコネクタ認証そのものを一括管理する設定は、Claude Enterpriseでコネクタを一括認証する設定手順で扱っています。Claude Codeで複数の管理設定ソースを統合する仕組みはmanagedSourcesBehaviorで扱っています。

Claude Codeを使うメンバーには、さらに5層目の判定が加わります。Managed Settingsのポリシーとここまでで決まったコネクタ権限は、制限の厳しい方に合成され、両方が許可した場合だけ確認なしでツールを呼べます。注意したいのは、コネクタ権限の有効化によって、組織全体のツールポリシーがClaude Codeにも適用される点です。これは絞る方向にしか働きませんが、全メンバーに影響します。Claude Codeを広く展開している組織は、有効化の前にポリシーを見直します。

Cowork側には別の設定があります。「Allow "Always allow" for connector tools」という組織設定が既定でオフで、これがオフの間は、ロールと組織ポリシーの両方が「Always allow」でも書き込み系のツールはタスクごとに承認が必要です。「Allow for all tasks」がグレーアウトし、以前に保存した常時許可の設定も効きません。読み取り専用として注釈されたツールだけは例外ですが、カスタムコネクタの多くは注釈を付けていません。

全メンバーをCustomに移行する順序

移行の前に、Organization settings > Membersからメンバー一覧をCSVで書き出しておきます。想定外の権限喪失が起きたときの復旧の手がかりになります。

手順

移行の順序

1. 1

   ロールを作る

   機能を有効にする前に、すべてのロールを作り終えます。

2. 2

   グループを作り、ロールを割り当てる

   SCIMで同期する場合は、「Check for updates」から同期するのは「Groups only」にします。メンバーまで同期すると、プロビジョニングやアクセスに影響が出ることがあります。IdP側では、RBACや支出上限に使うグループだけをプッシュします。全部を同期するとGroups画面の表示が遅くなります。

3. 3

   未所属のメンバーを探す

   MembersのRole・Groupフィルターで、どのグループにも入っていない人を見つけます。CSVを書き出して、ロールとグループの列で確かめる方法もあります。

4. 4

   パイロットだけをCustomにする

   1つの部署かチームを先に移行し、アクセスが想定どおりか確かめます。

5. 5

   残りを移行する

   問題がなければ対象を広げます。

6. 6

   組織レベルで機能を有効化する

   Organization settings > Coworkなど、各機能の設定ページで有効にします。

この順序は、権限のないメンバーが機能に触れられる時間をなくすためのものです。組織のトグルは「全員に配るスイッチ」ではなく、「ロールベースの割り当て対象にするスイッチ」にあたります。Design・Slides・Docsは正式版になり、Enterpriseでは2026年10月15日に既定でオンになります。それ以前に使うには、Organization settings > Artifactsで前倒しでオンにします。ロールの許可と合わせて使う点は変わりません。ロールが許可していないメンバーも、共有されたアーティファクトを開く・コメントする・使うことはできます。

どのグループにも属さないCustomメンバーは、権限がなく、ガバナンス対象の機能はすべてグレーアウトか非表示になります。設定ページだけが開き、使えるプロダクトが無い状態になることもあります。

メンバーをCustomにする経路は2つです。

グループマッピングをまだ使っていない組織は、RBACのセットアップ中に有効にしてはいけません。マップ済みグループへの全員の割り当てを済ませる前に有効にすると、組織へのアクセスを失うメンバーが出ます。両方のマッピングにまたがるメンバーでは、「Custom」が優先されます。

グループの作り方そのものはClaude Enterpriseのグループ支出上限を設定する手順で扱っています。

設定ミスに気づいたときの切り戻し

移行後にロール構成の誤りに気づいたら、まず移行時に有効にした組織レベルの機能をオフに戻します。次に、影響を受けたメンバーの組織ロールを元の組み込みロール(User等)へ戻します。そのロールが持つ静的な権限がすぐに復活し、カスタムロールの適用は止まります。調整してから、あらためて移行をやり直します。

グループマッピングの有効化でOwner・Admin自身のアクセスを失うのは、設定した本人が、AdminかOwnerにマップされたグループに入っていなかったときです。権限はUserへ下がります。復旧は2通りあります。

• 別のAdminかOwnerが、Organization settings > Organizationで本人のロールを戻す
• IdP側で、AdminかOwnerにマップされるグループへ本人を入れる。JITならログインし直し、SCIMなら別のAdminかOwnerが「Sync」を押すか自動同期を待つ

メンバーが使えないときの切り分け

使えないときは、メンバーに出る表示が原因の手がかりになります。

見分け方

機能が使えないときの表示

• 「This feature is disabled for your organization.」

  組織レベルで機能がオフです。機能はグレーアウトまたは非表示になります。

• 「Contact your admin to request access to this feature.」

  組織ではオンですが、メンバーのどのロールも許可していません。

• ログイン後に設定ページへ移る

  どのロールもプロダクトのアクセスを許可していません。Chatをオフにしたロールでも、CoworkやClaude Codeを許可していれば、設定ページと各アプリから使えます。

表示で分からないときは、症状から原因を探します。

「View effective role」は、そのメンバーが持つ機能・管理権限・コネクタ権限と、それぞれを付与しているロールを一覧にします。読み取り専用で、変更はロール編集画面から行います。

検証では、権限を持たないはずのメンバーで機能がグレーアウトしているか、持つはずのメンバーで正常に動くかの両方を見ます。複数グループのメンバー、グループ無しのメンバー、SSOで新規参加したメンバーも対象です。コネクタは、ブロックしたツールをClaudeに頼むと「ツールがない」と返り、「Needs approval」のツールでは「Always allow」のない承認プロンプトが出ます。モデルは、無効なモデルがピッカーに出ず、effortのメニューがロールの上限で止まります。Claude Code CLIでは、無効なモデルへの /model がエラーになります。

よくある質問

複数の子組織を持つ場合、カスタムロールの割り当ては共有されますか

されません。グループ本体とSCIM同期は親組織レベルで管理され、全子組織に共有されます。ロールの割り当てと支出上限は、子組織ごとに独立して設定します。グループのメンバーシップ変更とSCIMの再同期は、同じ親の下の全子組織に伝わります。

組織を別の親へ移す申請をすると、グループとロールが未定義になり、作り直しが必要です。

組織全体でプロジェクト公開を止めたいときは

「Public projects」はロールでも制限できますが、組織レベルでオフにすればどのロールも上書きできません。手順はClaude組織のプロジェクト公開を無効化する方法にあります。

まとめ

ロールを作る前に、IdPのグループがどのメンバーを「Custom」にマップしているかを確かめてください。未所属のメンバーや、Userのまま残っているメンバーには、作ったロールが届きません。