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

誰に何を使わせるか

  • レッスン 3
  • 13分

このレッスンで

終わる頃には、次ができるようになります

  • 標準ロールとカスタムロールの違いと、それぞれの権限の継承のされ方を説明できる
  • コネクタが実際に使えるようになるまでの3つのゲートを説明できる
  • 複数グループに属すメンバーの権限がどう合成されるかを説明できる

組織の形と本人確認が決まったら、次は「誰が何を使えるか」を決める番です。この決定は、前のレッスンで作ったグループを単位に設定します。グループの形が固まっていない段階でここに手をつけると、あとで作り直しになるのはすでに触れたとおりです。

標準ロールとカスタムロール

前のレッスンで見たUser・Admin・Owner・Primary Ownerは、組織を管理する側の権限を決めるロールでした。ここで扱うのは、機能そのものへのアクセスです。

User・Admin・Ownerのロールを持つメンバーは、組織全体で有効にした機能を自動的に使えます。それに対してEnterpriseプランのカスタムロールは仕組みが逆で、組織が機能を有効にしていても、カスタムロールを割り当てられたメンバーは、そのロールが明示的に許可した機能しか使えません。チャット・Claude Cowork・Claude Code・ウェブ検索といった機能単位の許可に加え、組織が追加したコネクタへのアクセスも、カスタムロールで個別に設定できます。

つまり、「標準ロールは組織の設定に乗っかる」「カスタムロールは自分で全部組み立てる」という向きの違いがあります。部門ごとに使わせたい機能がはっきり違うなら、カスタムロールで組み立てたほうが、あとから見て何を許可しているかが分かりやすくなります。

補足

Claude Codeの中身はこのレッスンでは扱わない

Claude Codeをどのグループに使わせるかはここで決めますが、Claude Code自体の権限モードやマネージド設定といった、開発の現場での運用は別の話題です。詳しくはClaude Codeを組織に入れるで扱っています。

複数グループに属すと権限はどう合成されるか

1人のメンバーが複数のグループに属すことはよくあります。エンジニアリング部門に所属しながら、部門横断のプロジェクトチームにも入っている、というような場合です。

このとき、メンバーの実際のアクセスは、属しているすべてのグループの権限を足し合わせたものになります。片方のグループである機能をブロックしても、もう片方のグループがその機能を許可していれば、そのメンバーは使えます。厳しくしたいメンバーがいる場合は、広いグループから外して専用の狭いグループに移す必要があり、「狭いグループに入れれば厳しくなる」という発想は通用しません。

厳格化したいメンバーへの対応

狭いグループに追加するだけ

規制対象の業務を担当するメンバーを、制限の厳しい専用グループに追加する。しかし元々所属していた広いグループの権限は残ったままなので、実際のアクセスは広いグループの権限のまま変わらない。

広いグループから外して専用グループに移す

規制対象の業務を担当するメンバーを、広いグループから外し、制限の厳しい専用グループだけに所属させる。これで初めて、そのメンバーのアクセスが専用グループの範囲に制限される。

コネクタが使えるようになるまでの3つのゲート

コネクタは、Claudeが社内のドライブやWiki、チケット管理システムといった外部のアプリにアクセスする仕組みです。ある人がコネクタを実際に使えるようになるには、3つのゲートがすべて開いている必要があります。

コネクタの3つのゲート

1

組織ゲート

Owner・Primary Ownerが、そのコネクタを組織全体に追加しているか

2

ロールゲート

そのメンバーが属すグループのロールが、そのコネクタへのアクセスを許可しているか

3

深さのゲート

読み取り専用か、読み取り書き込みまで許すか

コネクタを組織に追加しただけでは、誰にも自動的に権限は渡りません。組織ゲートを開いた時点ではまだ何も起きず、ロールゲートまで開いて初めてそのグループのメンバーが使えるようになります。書き込み権限は、チケットの起票やページの編集など、元に戻しにくい操作を含むことが多いため、読み取り専用から始めて必要な部署だけ書き込みまで広げる、という順番が安全です。

コネクタの権限は、コネクタ単位・機能単位で「常に許可」「承認が必要」「ブロック」の3段階でも設定できます。すべてを常に許可にするのではなく、リスクの高い操作だけ承認を挟む、という組み合わせ方ができます。

例で見る、アクセスの決め方

一般企業であれば、全部門にチャットとCoworkを許可しつつ、社内Wikiのコネクタは読み取り専用で全部門、チケット管理システムへの書き込みはエンジニアリング部門のみ、といった組み立てが考えられます。

病院であれば、多くの部署にチャットを許可しつつ、Claude Codeのような開発寄りの機能は情報システム部門だけに絞り、個人情報を多く扱う部署(会計・医事課など)には、外部コネクタを一切付与しない、という判断がありえます。いずれの場合も、患者の氏名・ID・生年月日・特定できる所見をClaudeに入力しないという原則は、アクセスの設計とは別に、利用ガイドラインとして周知しておく必要があります。

やってみよう

演習1:グループごとに許可する機能を書き出す

自分の組織のグループ(部門やチーム)を2〜3個思い浮かべ、それぞれにチャット・Cowork・Claude Code・コネクタのうちどれを許可するか、書き出してみてください。

演習2:複数グループ所属の人を思い浮かべる

自分の組織で複数のグループに属していそうな人を1人思い浮かべ、その人の実際のアクセスが「属す全グループの合計」になることを踏まえて、意図しない広いアクセスが発生していないか考えてみてください。

今日のまとめ

3行で振り返ります。

  • 標準ロールは組織の設定を自動継承するが、カスタムロールは明示的に許可した機能しか使えない、という向きの違いがある
  • 複数グループに属すメンバーの権限は和集合になるため、厳格化したいメンバーは広いグループから外して専用グループに移す必要がある
  • コネクタは組織ゲート・ロールゲート・深さのゲートの3つがすべて開いて初めて使えるようになる

次のレッスンでは、メンバーが自分でスキルやプラグインを作るとき、それをどこまで自由にし、どこから統治するかというガバナンスの決定を見ていきます。

セルフチェック

1. 標準ロールとカスタムロールの違いとして正しい説明はどれですか。

2. 複数のグループに属すメンバーの権限について正しい説明はどれですか。

3. コネクタが実際に使えるようになるまでの3つのゲートに含まれないものはどれですか。

SourceARTICLE
Enterpriseプランでのロールベース権限の設定

標準ロールとカスタムロールの違い、複数グループ所属時の和集合ルールの一次情報

WebClaude Support
support.claude.com/en/articles/13930458-set-up-role-based-permissions-on-enterprise-plans
SourceARTICLE
コネクタを使ってClaudeの機能を拡張する

コネクタの仕組みと、組織全体での有効化が個別付与を意味しないことの一次情報

WebClaude Support
support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities

このレッスンは役に立ちましたか?