メインコンテンツにスキップ

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

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

開始する前に、以下について理解していることを確認してください:


開始する前に

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

注:これらのステップの一部には、Identity & Accessカスタムロール以上の権限が必要です。組織レベルで機能を有効にするにはオーナーロールが必要であり、メンバーロールを変更するにはUser Managementが「管理」に設定されている必要があります。

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

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

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

デュアルシートプラン。組織がデュアルシートエンタープライズプラン(ChatとChat + Claude Codeシート)を使用している場合、カスタムロールはシートレベルの制限をオーバーライドしません。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表示アクセスを付与する「エンジニアリングリード」ロールを作成できます。カスタムロールの管理権限について詳しく学ぶ。


ステップ1:現在の設定を監査する

  1. 組織設定 > 機能で、組織レベルで現在有効または無効になっている機能を確認します。

  2. 組織設定 > メンバーに移動して、メンバーリストをエクスポートまたは確認します。

  3. 各メンバーの現在の組み込みロール(ユーザー、管理者、またはオーナー)をメモします。

  4. 各チームまたは部門について、アクセスが必要な機能を決定します。

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

重要:ユーザーロールを持つメンバーとは異なり、カスタムロールに割り当てられたメンバーは、組織で有効になっている機能を自動的に継承しません。「カスタム」ロールメンバーが必要とするすべての機能は、そのグループの1つに割り当てられたカスタムロールによって明示的に付与される必要があります。


ステップ2:カスタムロールを作成する

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

  1. 組織設定 > ロールに移動します。

  2. 「ロールを追加」をクリックします。

  3. ロールに名前を付け、機能タブで適切な機能を有効にするか、「すべての機能」または「一般的に利用可能なすべて」を選択してすべてを一度に付与します:

  4. 権限タブで、ロールの管理権限を設定します。ステップ3を参照してください。

  5. コネクタタブで、ロールのコネクタ権限を設定します。ステップ4を参照してください。

  6. モデルタブで、ロールのモデルアクセスとデフォルトモデルを設定します。ステップ5を参照してください。

  7. 「保存」をクリックします。

  8. 計画内の各ロールについて繰り返します。

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

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


ステップ3:管理権限を設定する(オプション)

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

権限タブを見つける

  1. 組織設定 > ロールに移動します。

  2. 既存のロールを開くか、「ロールを追加」をクリックして新しいロールを作成します。

  3. 権限タブを選択します。機能とコネクタの間にあります。

管理者権限を設定する

権限タブには、各管理者領域が表示されます:Identity & Access、Billing、Analytics、Privacy、User Management、Libraries、Directory。各管理者領域を次のいずれかのオプションに設定します:

  • アクセスなし:メンバーは組織設定でこの領域を表示できません。

  • 表示可能:表示は読み取り専用アクセスを付与します。メンバーは、その領域を管理できるユーザーと同じページと設定を表示できますが、すべてのコントロールは無効化されるか読み取り専用として表示されます。このアクセス権限レベルは、コンプライアンスレビュアー、財務監査人、セキュリティチーム、または設定を変更せずに確認する必要があるユーザーに使用します。

  • 管理可能:管理は領域への完全な読み取り・書き込みアクセスを付与し、表示アクセスも含みます。

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

注:Identity & Accessが管理に設定されているロールは、グループとロール(独自のロール定義を含む)を作成および編集できます。このアクセス権限を持つメンバーは独自のアクセスを拡張できるため、信頼できるセキュリティおよびIT管理者に限定してください。

実装を確認する

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


ステップ4:コネクタ権限を設定する(オプション)

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

重要:Anthropicが組織のコネクタ権限を有効にすると、既存のすべてのカスタムロールに「すべてのコネクタ」権限が「常に許可」で設定されます。「常に許可」は最も許可的な権限であるため、組織全体のツールポリシーのみが有効化時の各メンバーの有効な上限を決定します。メンバーは有効化時にアクセスを獲得または失うことはありません。最初の設定パスはそのベースラインから絞り込みます。

注:新しく作成されたロールは、すべてのコネクタで「承認が必要」にデフォルト設定されます。ロール作成フローはコネクタタブをステップスルーするため、保存する前にこのデフォルトが表示されます。必要に応じてコネクタを「常に許可」に上げるか、「ブロック」に下げてください。

コネクタタブを見つける

  1. 組織設定 > ロールに移動します。

  2. 既存のロールを開くか、「ロールを追加」をクリックして新しいロールを作成します。

  3. コネクタタブを選択します。権限の隣にあります。

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

コネクタレベルの権限を設定する

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

  • 常に許可:コネクタ上のすべてのツールが利用可能で、メンバーは独自の承認を「常に許可」に設定できます。

  • 承認が必要:すべてのツールが利用可能ですが、メンバーは各呼び出しを確認します。

  • ブロック:コネクタはこのロールを持つメンバーから非表示になります。

  • カスタム:コネクタ上の各ツールを個別に設定します。下の「ツール単位の権限を設定する」を参照してください。

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

メンバーの接続方法を設定する

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

  • 個別:メンバーは独自のアカウントで各コネクタにサインインします。

  • 管理された認可:メンバーはID プロバイダーを通じて自動的に接続し、自分でサインインする必要はありません。

  • コネクタごとに設定:すべてのコネクタに対して1つの設定を使用する代わりに、各コネクタに対して個別に「個別」または「管理された認可」を選択します。

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

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

ツール単位の権限を設定する

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

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

ロール間の競合を確認する

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

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

実装を確認する

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

重要:組織がClaude Codeを使用している場合、コネクタ権限を有効にすると、組織全体のツールポリシーもClaude Codeに適用されます。これはツールアクセスを絞り込むことのみが可能で、拡大することはできず、すべてのメンバーに影響します。Claude Codeが広く展開されている場合、有効化前に組織全体のツールポリシーを確認してください。コネクタ権限とClaude Code管理設定は最も制限的なもので構成されます。Claude Code設定を参照してください。

注:メンバーがCoworkで書き込み可能なコネクタツールに「常に許可」を設定できるかどうかは、組織設定コネクタツールに「常に許可」を許可するによってさらに制御され、デフォルトではオフです。ロール権限はそれをオーバーライドできません。書き込みツールのCowork承認設定について詳しく学んでください。


ステップ5:モデルアクセスを設定する(オプション)

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

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

モデルタブを見つける

  1. 組織設定 > ロールに移動します。

  2. 既存のロールを開くか、「ロールを追加」をクリックして新しいロールを作成します。

  3. モデルタブを選択します。コネクタの隣にあります。

モデルアクセスを設定する

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

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

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

実装を確認する

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


ステップ6: グループを作成してロールを割り当てる

  1. 組織設定 > グループに移動します。

  2. 「グループを追加」をクリックして、プランの各チームまたはティアのグループを作成します。

  3. 各グループをステップ2で作成したカスタムロールに割り当てます。

  4. メンバーを適切なグループに追加します。

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

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

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

重要: 組織が招待のみまたはJITプロビジョニングを使用している場合、RBACには手動で作成されたグループのみを使用できます。SCIM同期グループはこれらのモードではサポートされていません。


ステップ7: グループとロール割り当てを確認する

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

  1. 組織設定 > メンバーに移動します。

  2. ロールとグループフィルターを使用して、グループに割り当てられていないメンバーを特定します。

  3. または、「CSVをエクスポート」をクリックして、ロールとグループ列を含む完全なメンバーリストをダウンロードして確認します。

  4. 割り当てられていないメンバーを続行する前に適切なグループに追加します。


ステップ8: メンバーをカスタムロールに移行する

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

重要: このステップは、カスタムロールを作成し、使用している場合は管理者とコネクタの権限を設定し、グループを作成し、すべてのメンバーがグループに割り当てられていることを確認した後にのみ完了してください。セットアップが完了する前にメンバーをカスタムロールに移動すると、すべての管理対象機能へのアクセスが直ちに失われ、以前のロールが失われます。オーナーまたは管理者をカスタムロールに切り替えると、オーナーまたは管理者アクセスが削除されるため、カスタムロール権限でそのアクセスを置き換える予定がない限り、オーナーまたは管理者を移行しないでください。

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

パスA: グループマッピングを有効にする(既に使用中の場合のみ)

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

  1. ロールマッピングセクションで、カスタムロールで管理する IdP グループを「カスタム」ロールに割り当てます。

  2. 変更を保存します。これらの IdP グループ内のメンバーは、次の同期時に「カスタム」ロールに移行されます。

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

パスB: 一括割り当てツール

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

警告: グループマッピングをまだ有効にしていない場合は、RBAC セットアップ中に有効にしないでください。最初にすべてのメンバーをマップされたグループに割り当てずに有効にすると、メンバーが組織へのアクセスを失う可能性があります。

  1. 組織設定 > メンバーに移動します。

  2. ロールとグループフィルターを使用して、移行するメンバーを選択します。

  3. 「選択した#を更新」をクリックします。

  4. アクションで、「ロールを変更」を選択します。

  5. ロールで、「カスタム」を選択します。

  6. 「メンバーを更新」をクリックします。

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

段階的なロールアウト

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

  1. 1つのチームまたは部門のパイロットグループから始めます。

  2. 移行後、パイロットグループが、グループとロール割り当てに基づいて正しい機能アクセスを持っていることを確認します。

  3. 何か問題がある場合は、調整している間、影響を受けたメンバーを以前のロールに戻します。

  4. セットアップが機能することを確認したら、より多くのメンバーに拡張します。


ステップ9: 組織レベルで機能を有効にする

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

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

  1. その機能の設定ページに移動します(Organization settings内)(例:Organization settings > Cowork)。

  2. 組織レベルで機能を有効にします。

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

注:これには、Organization settings > Artifacts内のDesign、Slides、およびDocs設定が含まれます。これらのロールを付与されていないメンバーでも、共有されたアーティファクトを開く、コメントする、使用することができます。


ステップ10:グループの支出制限を適用する(使用量ベースの組織のみ)

グループにユーザーあたりの月間支出制限を割り当てるには:

  1. Organization settings > Usageに移動します。

  2. Spend limitsの下の「By group/tier」タブを選択します。

  3. 「+」をクリックします。

  4. グループを選択してカスタム制限を追加します。

  5. 完了したら、「Add spend limit」をクリックします。

次の優先順位ルールに注意してください:

  • 個別の制限は常にグループの制限を上書きします。どちらが高いかに関わらず。

  • ユーザーが異なる制限を持つ複数のグループに属している場合、Spending defaultsの下のMulti-group spend limit設定により、より高い制限またはより低い制限のどちらが適用されるかが制御されます。

  • 組織全体の制限は厳密な上限のままです。

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


ステップ11:確認と監視

  1. アクセスの確認:Organization settings > Membersのメンバーの行の右側にある「⋮」メニューを開き、「View effective role」を選択します。モーダルには、メンバーがすべてのロール全体で持つすべての機能、管理者権限、およびコネクタが表示され、「Granted by」ラベルが各機能を提供するロールを示します。Organization settings > Groupsからグループに対して同じことを行うことができます。詳細については、Manage custom roles on Enterprise plansを参照してください。

  2. 制限された状態をテストする:Coworkなどの機能を持つべきではないメンバーとしてログインする(または依頼する)。グレーアウトされた状態で「Contact your admin to request access to this feature」というメッセージが表示されるはずです。

  3. 付与された状態をテストする:機能を持つべきメンバーが正常に機能しているのを確認します。

  4. エッジケースを確認する:複数のグループに属するメンバー、グループに属さないメンバー、SSOを介して参加する新しいメンバーをテストします。

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

  • グループとロールの割り当て:オーナーは、メンバーページでメンバーのグループ割り当てを確認し、ロールページでそれらのグループが割り当てられているロールを確認することで、メンバーのアクセスを確認できます。

  • Organization settings:組織設定では、メンバーは管理者権限がカバーするセクションのみを表示します。その他はすべて設定から非表示になります。表示アクセス権を持つメンバーはページを読み取り専用で表示し、コントロールは無効になります。

  • 分析アクセス:分析アクセス権を持つメンバーは、組織設定ではなくSettings > Analyticsで分析を表示します。

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

  • コネクタメニュー:ブロックされたコネクタは表示されず、少なくとも1つの付与されたツールを持つコネクタが表示されます。

  • コネクタ設定:ブロックされたツールは「This tool is not enabled for your role. Contact your administrator.」でグレーアウトされます。「Needs approval」に制限されたツールは、「Ask」と「Never」に限定された個人承認メニューを表示します。

  • 会話内:Claudeにブロックされたツールを使用するよう依頼すると、そのタスク用のツールがないと報告されます。「Needs approval」ツールを使用するよう依頼すると、「Always allow」オプションなしで承認プロンプトが表示されます。

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

  • モデルピッカー:無効なモデルは表示されず、努力メニューはロールの上限で停止します。

  • 会話内:メンバーに無効なモデルに切り替えるよう依頼します。リストに表示されず、Claude Code CLIでは/model <disabled-model>がエラーを返します。

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


ロールベースの機能でSCIMを使用する

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

IdPグループからロールへのマッピング

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

  1. ロールマッピングテーブルで、IdPグループを「Custom」ロールにマップします。

グループ同期

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

  1. SCIM syncセクションで「Check for updates」をクリックします。

  2. Groups、Members、またはBothを同期するよう求められたら、Groupsのみを選択します。メンバーの同期はプロビジョニングとメンバーアクセスに影響を与える可能性があります。

  3. IdPグループはリスト内のSCIM供給グループとして表示されます。

  4. 手動で作成されたグループと同じようにSCIMグループをカスタムロールに割り当てます。

  5. IdPでは、RBACまたは支出制限に実際に使用する予定のグループのみをプッシュします。すべてのIdPグループを同期すると、グループセクションのページロードが遅くなる可能性があります。

注:カスタムロール権限は、Organization settings > Membersで「Custom」ロールが選択されているメンバーにのみ適用されます。グループからロールへのマッピングを通じてIdPグループを別のロール(ユーザーなど)にマップしても、同じSCIMグループをカスタムロールに割り当てた場合、カスタムロールの権限は効果がありません。メンバーは割り当てられたロールから権限を取得します。カスタムロールを使用するには、IdPグループが「Custom」にマップされていることを確認してください。

SCIMによる継続的な管理

  • メンバーに機能へのアクセスを許可するには、適切なIdPグループに追加します。次の同期時に、そのグループに割り当てられたカスタムロールを取得します。

  • アクセスを取り消すには、IdPグループから削除します。次の同期時に、権限が削除されます。

  • グループセクションの「SCIM同期」をクリックして、次のスケジュール済み同期を待つのではなく、即座に同期を強制します。


ロールバック計画

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

  1. 移行の一部として有効化された組織レベルの機能をすべてオフにします。

  2. 影響を受けたメンバーを以前の組み込みロール(例:ユーザー)に戻します。

  3. そのロールからの静的権限が即座に復元され、カスタムロール権限の適用が停止されます。

  4. 必要に応じてロールとグループを調整してから、再度移行します。

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


よくある質問

一部のメンバーだけが機能を使用したい場合、組織レベルで機能を有効化する必要がありますか?

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

ロールが「カスタム」に設定されているメンバーがどのグループにも属していない場合、どうなりますか?

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

メンバーのモデルピッカーからモデルが見つかりません。

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

カスタムロールがチャットアクセスを許可しない場合はどうなりますか?

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

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

組み込みロールとカスタムロールの両方を使用できますか?

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

メンバーが異なるロールを持つ2つのグループに属している場合はどうなりますか?

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

SCIMグループと手動グループを一緒に使用できますか?

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

オーナーとプライマリオーナーはカスタムロール権限の影響を受けますか?

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

これは親組織と子組織全体でどのように機能しますか?

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

コネクタ権限が有効化されたときに、既存のカスタムロールはどうなりますか?

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

新しいロールのデフォルトコネクタ権限は何ですか?

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

ロールが存在した後に新しいコネクタを追加するとどうなりますか?

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

ロール内のコネクタをブロックしましたが、そのロールを持つメンバーはまだそれを使用できます。なぜですか?

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

組織全体のツールポリシーがすでにツールをブロックしています。すべてのロールでそれをブロックする必要がありますか?

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

メンバーのロールと組織全体のポリシーの両方が「常に許可」に設定されていますが、Coworkで「すべてのタスクを許可」がグレーアウトされています。なぜですか?

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

ロールが組織全体のポリシーで「承認が必要」に設定されているツールを許可できますか?

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

コネクタ全体を許可せずに、コネクタ上の1つのツールを許可できますか?

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

コネクタ権限はWebサーチやコード実行などの組み込みツールに適用されますか?

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

コネクタ権限の変更はどのくらい速く有効になりますか?

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

カスタムロールを持つユーザーが権限を持っている場合、自分自身にさらにアクセス権を与えることができますか?

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

User、Admin、Owner、またはPrimary Ownerロールのメンバーに管理者権限を付与できますか?

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

特定の設定に対する権限がない場合、ユーザーには何が表示されますか?

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

管理者アクセス権を持つユーザーを監査するにはどうすればよいですか?

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

複数の領域にわたって権限が必要な場合はどうすればよいですか?

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

こちらの回答で解決しましたか?