エンタープライズプランでロールベースの権限を設定する

このガイドでは、エンタープライズ組織のロールベースの権限を設定する手順を説明します。これにより、特定のチームやメンバーグループがアクセスできる機能やコネクタを制御し、全員に同じ権限を付与するのではなく、請求やユーザー管理などの特定の管理者アクセスを委任できます。

開始する前に、以下に精通していることを確認してください：

エンタープライズ組織へのオーナーまたはプライマリオーナーアクセス、またはアイデンティティとアクセスが「管理」に設定されたカスタムロールが必要です。

組織レベルで有効になっている機能を確認します。組織設定に移動し、メンバーが現在アクセスできる機能を把握していることを確認してください。RBACで管理される設定の場合、ユーザーがアクセスするには、組織設定とロール設定の両方がオンになっている必要があります。

メンバーリストをバックアップします。変更を加える前に、組織設定 > メンバーから現在のメンバーのCSVをエクスポートします。移行中に問題が発生した場合、これはアクセスを復元するための参照になります。チームプランとエンタープライズプランでメンバーを管理するを参照してください。

各機能が必要なチームまたは機能を決定します。例えば、エンジニアリングはClaude Code + Fast Modeを取得し、マーケティングはCowork + Web Searchを取得します。ここから、カスタムロールを定義します。

デュアルシートプラン。組織がデュアルシートエンタープライズプラン（ChatとChat + Claude Codeシート）を使用している場合、カスタムロールはシートレベルの制限をオーバーライドしません。Chatのみのシートに割り当てられたメンバーは、カスタムロールがそれを許可していても、Claude Codeにアクセスできません。逆も同じです。メンバーのカスタムロールがチャット機能を許可していない場合、シートタイプに関係なくチャットアクセスがありません。シート割り当てを念頭に置いてロール構造を計画してください。

グループの作成方法を決定します。Claudeでグループを手動で作成するか、SCIMを介してアイデンティティプロバイダー（IdP）から同期できます。両方の方法を同時に使用することもできます。OktaやEntra IDなどのプロバイダーからIdPグループを使用する予定がある場合は、SCIMディレクトリ同期が構成されていることを確認してください。JITまたはSCIMプロビジョニングを設定するを参照してください。

管理するコネクタを追加します。コネクタ権限は、オーナーまたはプライマリオーナーが組織設定 > コネクタの下で既に追加し、管理者認証情報で接続したコネクタのみをカバーします。組織全体のツールポリシーもそこで確認してください。ロール付与はその中で絞られ、その外に広がることはできません。コネクタを使用してClaudeの機能を拡張するを参照してください。

何かを作成する前に、各チームまたはメンバーグループがアクセスすべき機能を決定します。以下は4つの一般的なパターンです：

これはほとんどの組織に推奨されるアプローチです。Webサーチ、メモリ、プロジェクトなどの一般的な機能を備えた全員向けの「標準アクセス」ロールを作成します。次に、特定の機能を付与する加算ロールを作成します。例えば、Coworkのみを追加する「Cowork有効」ロール。「すべてのユーザー」グループを通じてすべてのメンバーをベースロールに割り当て、特定のメンバーを追加グループに追加して、追加機能をレイヤーします。

このパターンは柔軟です。権限は加算的であり、ベースロールと加算ロールを組み合わせると、競合なくきれいに構成されます。

異なる階層を作成します。「フルアクセス」（すべての機能）、「標準アクセス」（ほとんどの機能）、「制限付きアクセス」（最小限の機能）。各メンバーは1つの階層に割り当てられた1つのグループに入ります。

部門にマップするロールを作成します。「エンジニアリング」（チャット、Cowork、Claude Code、コード実行）、「リサーチ」（チャット、Webサーチ、メモリ、プロジェクト）、「ビジネス」（チャット、Webサーチ、プロジェクトのみ）。各部門グループを対応するロールに割り当てます。

オーナーロールを付与せずに管理の一部を委任するロールを作成します。管理権限を持つカスタムロールはユーザー機能を必要とせず、その逆も同じです。請求アクセスを付与するが、チャットやClaude Code機能を付与しない「財務」ロール、またはClaude CodeプラスAnalytics表示アクセスを付与する「エンジニアリングリード」ロールを作成できます。カスタムロールの管理権限について詳しく学ぶ。

覚えておいてください：グループごとに制御したい機能は、組織レベルで有効にする必要があります。機能が組織レベルでオフになっている場合、カスタムロールはそれへのアクセスを付与できません。

機能を有効にしたり、メンバーを移行したりする前に、カスタムロールを作成します。これにより、機能がオンになった瞬間にロールがアクセスを強制する準備ができます。

ロール変更は有効になるまで最大15分かかる場合があります。メンバーは更新されたアクセスを表示するためにブラウザをリフレッシュする必要がある場合があります。

利用可能な機能、管理権限、コネクタの詳細については、エンタープライズプランでカスタムロールを管理するを参照してください。

各ロールに管理権限を設定して、オーナーロールを付与せずに請求、ユーザー管理、プライバシーなどの管理設定へのアクセスを委任します。このステップはオプションです。設定しない場合、ロールは管理アクセスを付与せず、管理はオーナーとプライマリオーナーのままです。各権限領域がカバーする内容については、エンタープライズプランでカスタムロールを管理するを参照してください。

権限タブには、各管理者領域が表示されます：ID & アクセス、請求、分析、プライバシー、ユーザー管理、ライブラリ、ディレクトリ。各管理者領域を以下のいずれかのオプションに設定します：

領域内では、表示または管理のすべてを付与します。個別のページまたは設定を付与または制限することはできません。

メンバーを「カスタム」ロールに移行した後（ステップ7）、管理者権限を確認します。ステップ11：確認と監視を参照してください。

各ロールのコネクタ権限を設定して、ロールが使用できるコネクタと、それらのコネクタ上のどのツールを制御します。このステップはオプションです。設定しない場合、ロールは以下に説明されているデフォルト動作にフォールバックします。権限モデルがエンドツーエンドでどのように機能するかについては、エンタープライズプランでカスタムロールを管理を参照してください。

新しいロールのデフォルト設定は許可的です。ロールを作成または変更する場合、意図しない権限の付与を避けるために、各タブの設定を確認してください。

コネクタタブには、上部にすべてのコネクタ行が表示され、その後に組織が追加したすべてのコネクタが続きます。各行には4つのオプションを持つドロップダウンがあります：

「常に許可」、「承認が必要」、または「ブロック」を選択すると、そのレベルがコネクタ上のすべてのツールに適用されます。すべてのコネクタ行は同じ方法で1レベル上で機能します。すべてのコネクタ（後で追加するコネクタを含む）のベースラインを設定します。ロールのデフォルトを設定してから、個別のコネクタをオーバーライドするために使用します。

メンバーの接続方法ドロップダウンは、ロールのメンバーが自身のアカウントでコネクタにサインインするか、ID プロバイダーを通じて自動的に接続するかを制御します：

コネクタが個別と管理された認可の両方がオンになっている場合、Claudeは管理された認可を最初に試みます。それが失敗した場合、メンバーは自身のアカウントで個別にサインインできるため、ID プロバイダーの問題が解決されている間、コネクタからロックアウトされません。

すべてのコネクタ行で個別または管理された認可を選択すると、すべてのコネクタ（後で追加するコネクタを含む）のベースラインが設定されます。ロールのデフォルトを設定してから、個別のコネクタをオーバーライドするために使用します。

コネクタをカスタムに設定して、そのツールを個別の行として表示します。各ツールに対して「常に許可」、「承認が必要」、または「ブロック」を選択できます。

ツール単位の権限により、ロールはコネクタの一部に到達できます。たとえば、Jiraがカスタムに設定され、そのsearch_issuesツールが「承認が必要」に設定され、他のすべてのJiraツールが「ブロック」に設定されている場合、ロールを持つメンバーはJiraを検索できますが、他には何もできません。Claudeは付与したツールのみを表示するため、チケットを作成するよう求めると、エラーではなく「そのためのツールがありません」が返されます。

コネクタ権限はロール全体で加算されるため、1つのロールでコネクタをブロックしても、それを付与する別のロールも保持しているメンバーには影響がありません。各コネクタ行は、他のロールが同じコネクタを異なるレベルで付与している場合に警告を表示します。警告はそれらのロールに名前を付け、それらにリンクし、最も許可的な権限が適用されるものです。

リンクされたロールを開いたときに保存されていない編集がある場合、最初にそれらを破棄するよう求められます。

メンバーを「カスタム」ロールに移行した後（ステップ7）、コネクタ権限を確認します。ステップ11：確認と監視を参照してください。

各ロールのモデルアクセスを設定して、ロールが使用できるClaudeモデルを制御し、モデルごとの最大努力レベルを上限に設定し、新しい会話が開始するモデルを選択します。このステップはオプションです。設定しない場合、新しいロールは組織レベルで有効になっているすべてのモデルを、任意の努力レベルで使用でき、組織のデフォルトモデルで開始します。

モデルアクセスとデフォルトモデル設定がエンドツーエンドでどのように機能するかについては、組織のモデルアクセスを管理と組織のデフォルトモデルを設定を参照してください。

モデルアクセスの下で、このロールの各モデルをオンまたはオフにします。組織レベルで無効になっているモデルは表示されますが、組織設定 > モデルで組織に対してオンにするまで、ここで有効にすることはできません。Haikuモデルは常にオンであり、無効にすることはできません。

ロールがモデルで選択できる努力レベルを制限するには、モデルの横にある歯車アイコンをクリックしてレベルを選択します。

デフォルトモデルの下で、このロールの新しい会話が開始されるモデルを選択することができます。ロールがアクセスできるモデルのみを選択できます。

メンバーを「カスタム」ロールに移行した後、モデルアクセスを確認します。ステップ11: 確認と監視を参照してください。

SCIM ディレクトリ同期を使用している場合は、手動で作成する代わりに、ID プロバイダーからグループを同期できます。SCIM グループ同期の詳細については、エンタープライズプランでグループとグループ支出制限を管理するを参照してください。

同じ親組織の下にある複数の組織: グループは親組織レベルで管理され、すべての子組織に伝播します。グループに他の組織のメンバーが表示される場合がありますが、これは彼らがあなたの組織にアクセスできることを意味しません。グループに割り当てられたカスタムロールは、あなたの特定の組織に属するメンバーにのみ機能を付与します。

組織をある親から別の親に移動するようにリクエストした場合（実際にはまれです）、グループとロールは未定義になり、再作成する必要があります。

メンバーをカスタムロールに移行する前に、移行を計画しているすべてのメンバーが、カスタムロールに割り当てられた少なくとも1つのグループに属していることを確認します。グループまたはロールカバレッジなしで移行されたメンバーは、すべての管理対象機能へのアクセスを失います。

カスタムロール機能を有効にするには、メンバーのロールを「カスタム」に設定する必要があります。ユーザー、管理者、またはオーナーのロールを持つメンバーは、カスタムロールではなく、これらのロールから直接権限を取得します。

組織が既にグループマッピングを有効にしているかどうかに基づいて、移行パスを選択します。

このパスは、組織が既にロール割り当てのためにグループマッピングを有効にしている場合にのみ使用してください。この設定をまだ使用していない場合は、パスBにスキップしてください。

「カスタム」ロールにマップされた IdP グループ内のメンバーは、Claude でそのグループに割り当てられたカスタムロールの権限に従います。ユーザーにマップされた IdP グループ内のメンバーは、組織レベルの機能設定に従います。メンバーが両方のマッピング全体のグループに属している場合、「カスタム」ロールが優先されます。

組織がグループマッピングを有効にしていない場合は、このパスを使用してください。

まずパイロットグループ（1つのチームまたは部門）を移行し、アクセスが正しいことを確認してから、組織の残りの部分に拡張することをお勧めします。

どのパスを使用する場合でも、段階的に移行することをお勧めします。

ロール、グループ、およびメンバー移行が完了した後にのみ、組織レベルの機能を有効にしてください。これにより、カスタムロール機能が既に配置されており、権限のないメンバーが機能にアクセスできるウィンドウがありません。

グループごとに制御したい機能の場合：

組織レベルで機能を有効にしても、すべてのユーザーが利用できるわけではありません。カスタムロールの権限は既に設定されており、誰がそれを使用できるかを制御します。組織レベルのトグルは、機能を「すべてのユーザーに対してオン」にするのではなく、「ロールベースの割り当てに利用可能」にするものと考えてください。

グループにユーザーごとの月間支出制限を割り当てるには：

以下の優先順位ルールに注意してください：

メンバーシップの変更は自動的に有効になります。ユーザーはグループメンバーシップが変更されるとすぐに制限を継承または失います。使用量ベースの課金組織にのみ関連します。

管理者権限を設定した場合は、以下も確認してください：

コネクタ権限を設定した場合は、以下も確認してください：

モデルアクセスを設定した場合は、以下も確認してください：

ロールの変更がプラットフォーム全体で有効になるまで最大15分かかる場合があります。メンバーは更新されたアクセスを表示するためにブラウザを更新する必要がある場合があります。

SCIMは、一緒に機能する2つのメカニズムを通じてロールベースの機能に接続します。

これは、メンバーがプロビジョニングされるときに取得する組み込みロールを制御します。IdP グループを「Custom」ロールにマップして、新しいメンバーのアクセスがカスタムロール機能によって自動的に管理されるようにします。

これにより、IdP グループが Claude に取り込まれ、カスタムロールに割り当てることができます。

移行後にロール構造が誤って設定されていることに気付いた場合：

セットアップ中にグループマッピングを有効化してから管理者アクセスを失った場合は、JITまたはSCIMプロビジョニングの設定の「グループマッピングを有効化した後に管理者/オーナーアクセスを失った」セクションの復旧手順に従ってください。

はい。カスタムロールがメンバーごとのアクセスを制御するには、組織レベルのトグルがオンである必要があります。機能が組織レベルでオフの場合、ロールに関係なく誰もアクセスできません。メインスイッチと考えてください。カスタムロールはその下でアクセスを得られるユーザーを制御します。

カスタムロール権限がないため、権限が必要なすべての機能がグレーアウトまたは非表示になります。ロールが「カスタム」に設定されているすべてのメンバーが、カスタムロールに割り当てられた少なくとも1つのグループに属していることを確認してください。

モデルが組織レベルで無効化されているか（組織設定 > モデル）、メンバーのカスタムロールのいずれもそれを付与していません。組織レベルの無効化はオーナーと管理者を含むすべてのユーザーに影響します。

そのロールのメンバーはClaudeのチャットインターフェースを表示しません。サインイン時に設定ページに移動します。ロールがCoworkやClaude Codeなどの他の製品を付与している場合、それらは設定ページと関連アプリからアクセス可能なままです。

チャットはすべてのカスタムロールでデフォルトで有効化されているため、ロールのチャットを意図的にオフにした場合のみこれについて心配する必要があります。

はい。ユーザー、管理者、またはオーナーロールを持つメンバーは、それらのロールから直接権限を取得するため、カスタムロール権限の影響を受けません。ロールが「カスタム」に設定されているメンバーのみがグループとロールシステムによって制御されます。これにより段階的な移行が可能になります。

権限は加算的です。メンバーのチェーン内のいずれかのロールが機能を付与する場合、メンバーはそれを持っています。ロールを使用して別のロールによって付与された権限を削除することはできません。

はい。両方のタイプをカスタムロールに割り当てることができます。違いは、SCIMグループメンバーシップはアイデンティティプロバイダーで管理され、手動グループメンバーシップはClaudeの組織設定で管理されることです。

いいえ。オーナーとプライマリオーナーは常にすべての機能へのフルアクセスを持っています。

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

各既存ロールは「すべてのコネクタ」権限を「常に許可」でシードされるため、有効化時にメンバーのアクセスは変わりません。そこからアクセスを制限します。

すべてのコネクタで「承認が必要」です。ロール作成フローはコネクタタブをステップスルーするため、保存する前にこれを確認できます。

「すべてのコネクタ」行が「常に許可」、「承認が必要」、または「ブロック」に設定されているロールは、新しいコネクタをそのレベルで自動的にカバーします。「すべてのコネクタ」行が「カスタム」に設定されているロールは、設定するまで新しいコネクタを「ブロック」として扱います。

メンバーが別のロールを保持しているかどうかを確認してください。最も許可的な権限がロール全体で優先されるため、コネクタ行の競合警告にそれらのロールが表示されます。また、メンバーのロールが「カスタム」に設定されていることを確認してください。

いいえ。組織全体のポリシーは上限です。そこでブロックされたツールは、ロール権限に関係なく、すべてのユーザーに対してブロックされます。

Coworkには、書き込み可能なコネクタツールをゲートする別の組織設定「コネクタツールに対して「常に許可」を許可する」があります。デフォルトではオフです。オンになるまで、ロール権限とツールポリシーに関係なく「すべてのタスクを許可」はグレーアウトされたままで、以前に保存された常に許可の設定は尊重されません。読み取り専用ツールは、コネクタが読み取り専用として注釈を付けた場合のみ除外されます。ほとんどのカスタムコネクタはそうしません。詳細については、コネクタツール承認を参照してください。

ロールはそれを付与できますが、より厳しい設定が優先されるため、メンバーはそれを「承認が必要」で制限されたものとして表示します。メンバーが「常に許可」を設定できるようにするには、まず組織全体のポリシーを「常に許可」に引き上げてください。

はい。コネクタを「カスタム」に設定し、1つのツールを「常に許可」または「承認が必要」に設定し、残りを「ブロック」のままにします。

いいえ。組み込み機能は「機能」タブで管理されます。「コネクタ」タブは、組織が追加したコネクタを管理します。

ロール変更は有効になるまで最大15分かかる場合があります。メンバーはブラウザを更新する必要がある場合があります。

Identity & Access が「管理」に設定されている場合のみです。これはロールとグループの編集をカバーしています。ロール定義（自分自身のものを含む）の変更に使用できるため、信頼できるセキュリティおよび IT 管理者のためにこの権限を予約してください。

いいえ。管理者権限はカスタムロール内のメンバーにのみ適用されます。組み込みロール上のメンバーは、そのロールが付与するアクセス権を保持します。特定の管理者権限を誰かに付与するには、メンバーをカスタムロールに変更し、必要な権限を持つロールに割り当てられたグループに追加します。これにより、以前の組み込みロールアクセスが削除されることに注意してください。

組織設定には、権限がカバーするセクションのみが表示されます。アクセス権がないセクションは、組織設定から完全に非表示になります。

組織設定 > ロールには各カスタムロールが付与する管理者権限が表示され、組織設定 > グループには各ロールに割り当てられているグループとそのメンバーが表示されます。特定のメンバーを確認するには、組織設定 > メンバーでそのメンバーのグループを検索し、次にそれらのグループが割り当てられているロールを確認します。

複数の領域へのアクセスを付与するロールを 1 つ作成するか、メンバーを必要な領域をカバーするロールを持つ複数のグループに追加します。権限は加算的に組み合わされます。