あなたのグループ

これは依然として5つの意思決定のうち最初の「構造とアイデンティティ」です。組織の境界はすでに設定しました。次は、その中身、つまりグループとそれが持つロールに進みます。グループは、後続のほぼすべての意思決定が紐づく単位です。

グループは、ほぼすべてのコントロールが紐づく単位です

このモジュールの他のすべては、グループとは何か、そしてそれが何を持つかから導かれます。

1. グループとは、名前の付いたメンバーの集合です。

   あなたのアイデンティティプロバイダーはすでにメンバーをグループに分類しており、ClaudeはSCIM同期からそれらを自動的に読み取ります。メンバー数は数百人から数万人に及ぶこともあるため、メンバーを1人ずつ設定していては対応しきれません。グループを使えば、1人ずつではなく、多数のメンバーの機能を一度に設定できます。

2. 1つのグループ構造が、契約が対象とするすべてのサーフェスにまたがります。

   サーフェス（例えばCoworkやClaude Code）ごとに1つずつではなく、単一のグループ構造を構築します。グループに紐づけたロールはClaudeの各サーフェスに適用されるため、あるプロダクトでそのロールが付与する権限を、次のプロダクトのために作り直す必要はありません。

3. この先の4つの意思決定における設定のほぼすべてが、グループに紐づきます。

   設定するもののほぼすべてはグループ単位で設定します。一部の設定は組織全体の上限として扱われ、それらが登場する際にはレッスン内で明示します。

後になって、特定のサブセット（「この3人のメンバーだけ」「契約社員を除く全員」）にコントロールの範囲を絞りたくなった場合、それはおそらく、組織にもう1つグループが必要であることを構造が示しているのです。

RBACの仕組み：メンバー、グループ、ロール

Claude Enterpriseはロールベースアクセス制御（RBAC）を使用します。これには3つの要素があります。

• メンバー： あなたの組織の人々。
• グループ： 名前の付いたメンバーの集合で、アイデンティティプロバイダー（IdP）からSCIM経由で同期されるか、同期しない場合は組織設定で手動作成されます。
• ロール： グループに紐づける権限の集合です。カスタムロールを持つすべてのメンバーは、自分が属するグループのロールが付与するものを得ます。

アクセスはメンバー単位ではなく、ロール単位で設定します。あるメンバーが何をできるかを確認するには、そのメンバーが属するグループのロールを確認します。ロールを変更すれば、そのグループのすべてのメンバーが一度に変わります。

ロールには3種類あります。

• 管理者ロール（Primary Owner、Owner、Admin）： メンバーの招待、上限の編集、請求情報の閲覧（後者2つはOwner以上）など、設定を変更できる人を定めます。Adminはメンバーを管理できますが請求情報は扱えません。Ownerはほとんどの管理者アクションを実行できますが、組織のデータのエクスポートや、Primary Ownerロールの他の人への引き渡しなど、Primary Ownerに限定された一部のアクションは実行できません。誰にPrimary Ownerロールを持たせるかを決める前に、ロールと権限で完全な一覧を確認してください。
• ユーザーロール（User）： 機能、モデルアクセス、Claudeがメンバーに代わって使用できるツールなど、メンバーがClaude内でできることを定めます。本コースの大部分は、これらをカスタムロール（下記参照）を通じて範囲設定します。
• カスタムロール： 組み込みロールが適合しない場合に定義する権限セットです。管理者権限またはユーザー権限のいずれも持つことができます。

カスタムロールは4種類のアクセスを設定し、それぞれを組織全体のデフォルトとは異なる形で保持できます。

• 機能： Claude CodeやCoworkなど、どの機能が有効かを定めます。
• モデルアクセス： グループが使用できるClaudeモデルを定めます。
• コネクタ権限： グループがアクセスできるコネクタと、それを通じて書き込みができるかどうかを定めます。
• 管理者権限： カスタム管理者ロールの場合、実行できる管理者アクションを定めます。

これらはカスタムロールを持つメンバーにのみ適用されます。組み込みロールを持つメンバーは、組織全体で有効なすべてのサーフェス、モデル、コネクタを保持し続けます。手動またはIdPのロールマッピングを通じてロールをCustomに設定することは、このレッスンの引き継ぎ事項の一部です。

メンバーが複数のグループに属している場合、その権限はすべてのグループのロールの和集合になります。いずれかのグループが機能を付与していれば、そのメンバーはそれを持つことになり、より狭いグループがより広いグループの付与を取り消すことはできません。より厳格な境界を保つには、そうしたメンバーを独自のロールを持つ専用のグループに入れ、機密性の高い権限を持つ広いグループからは外しておきます。

Plutoのグループ

Plutoのグループ構造はハイブリッドパターンです。組織図を反映し、事業部門ごとに1つのグループと、部門横断のEngineeringグループを設けていますが、Payments & Trustだけは例外です。この部門のエンジニアは、そうしなければ和集合を通じてEngineeringの広範なコネクタアクセスを継承してしまうためです。そこでPlutoは独自のロールを持つ専用のpayments-engグループを追加し、決済担当のエンジニアは広いEngineeringグループではなくそちらに所属させることで、必要な権限だけを確実に得られるようにしています。

以下のインタラクティブウィジェットでは、1人のメンバーをPlutoの2つのグループに所属させ、和集合ルールの下で実際に何を得るかを示します。

1 · あなたの意思決定

あなたのコントロールはどのグループパターンに紐づきますか。あなたのグループは何で、それぞれが後続のどのコントロール（サーフェス、コネクタ、ガバナンス、上限）を持ちますか。

2 · 選択できる選択肢

3 · 後で変更する場合

グループ構造そのものを変更することのリスクは低いです。グループを追加したり、名前を変更したり、紐づけたロールを変更したりできます。注意して扱うべきなのはマッピングです。つまり、IdPグループへの所属がClaudeのロールを付与するというルールです。マッピングが稼働し始めると、それを変更すると対象となるすべてのメンバーのアクセスが変わり、元に戻すことは単純な取り消しではなく、2回目の大規模な変更を意味します。

セットアップリソース

決定を下したら、グループとそのロール割り当ては組織設定内に存在し、メンバーシップ自体はアイデンティティプロバイダーから同期されます。

• Enterpriseプランでのグループとグループ支出上限の管理：グループの作成とロールの紐づけ。
• Enterpriseプランでのカスタムロールの管理：組み込みロールが適合しない場合のロール定義。
• ロールと権限：各組み込みロールが付与するもの。グループが意図した範囲に合ったロールを持つようにするためのものです。
• Enterpriseプランでのロールベース権限の設定：ロールの権限をグループに紐づける方法。
• Enterprise組織向けSCIM同期の仕組み：同期されたディレクトリグループが、手動の保守なしでメンバーシップを最新に保つ仕組み。

レッスン演習

和集合ルールに照らして、あなたのグループを書き出してみましょう。各グループと、そのロールが付与するものを列挙し、厳格に境界を設けるべきメンバーや機能、そしてそれを境界づける専用グループの名前を挙げます。規制対象の機能がある場合は、そのメンバーが正しく制限されていることを確認してください。

アイデンティティチームに持参するもの： 選択したパターン、IdPグループをClaudeグループに変換するルール（および例外があればそれ）、標準のカスタムロールと異なるロールを持つグループ、そしてどのIdPグループがCustomロールにマッピングされるか。プロビジョニングを自分で実行しない場合、これが彼らに渡すべき概要です。

→ これをワークアロング・コンパニオンのレッスン5セクションに記録してください。

次のステップ

次のレッスンでは、各グループにどのClaudeサーフェスを付与するか、そのアクセスをどう段階的に展開するか、そして組織全体およびロールごとのモデルデフォルトが各グループの実行基盤をどう決定するかを扱います。