Claude CoworkのRBAC運用 — ロール設計・ファイル権限・監査ログの実装手順

要点

Claude Coworkは「デスクトップ上でローカルファイル・外部サービスを自律的に触るエージェント」であり、誰が何にアクセスできるかがそのままセキュリティ境界になります。この記事はTeam / Enterpriseを前提に、標準ロールと Custom roles の違い、グループ駆動の設計、プロジェクト単位のファイルアクセス、監査ログ運用を管理コンソールの操作順に追います。

最初に押さえたいのは1点です。Custom roles の権限が効くのは、メンバーの役割が「Custom」になっている人だけです。User・Admin・Ownerのままの人には何も影響しません。どの機能にどこまで権限が効くかは、Cowork完全ガイドの機能一覧で確かめられます。

RBACがなぜCoworkで重要か

RBAC(Role-Based Access Control、役割ベースのアクセス制御)は、メンバー個別にではなく「役割(管理者 / 一般メンバー / 閲覧者など)」単位で権限をまとめて定義し、各メンバーに役割を割り当てる仕組みです。大規模チームでも「役割を付け替えるだけ」で権限管理できるのが最大の利点です。

Coworkは従来のチャットと違い、ローカルファイル、外部コネクタ(Google Drive / Gmail / DocuSign等)、プラグイン、Claude Codeと同じエージェント基盤を組み合わせて多段階タスクを実行します。1人の権限が「どのファイルを読み、どのSaaSと通信し、何を書き出せるか」を規定するわけです。

Teamプランの初期は標準ロール(Primary Owner / Owner / Admin / User)で十分です。ところが「Coworkは可だがClaude Codeは不可」「Engineeringにだけコード実行を解放」といった要件が出ると粒度が足りなくなり、Enterpriseの Custom roles とグループが必要になります。

プロダクト全体像はClaude Cowork完全入門、機能の深掘りはCowork機能ディープダイブも参照してください。RBACは「誰が何に触れるか」を決める層です。「触れる操作を実行前にどう確認させるか」は別の層で、部門ごとの承認ゲートの設計はCowork Approval Gatesを部門ごとに設計する考え方で扱っています。

前提条件

Custom roles と監査ログはEnterprise限定です。席の種類にも注意が要ります。Chat席とChat + Claude Code席を持つ旧来のデュアルシート型Enterpriseでは、ロールで席の制限を上書きできません。Chat席のメンバーは、ロールがClaude Codeを許可していても使えません。逆に、ロールがチャットを許可していなければ、席の種類にかかわらずチャットは使えません。

自分の組織に合うロールの作り方

出発点になる設計パターンは4つあります。相互排他ではなく組み合わせられますが、どれを骨格にするか先に決めると設計が速く済みます。

Base Plus Additiveでは、たとえば全員を「All Users」グループに入れて「Standard Access」ロール(Web検索とメモリー)を付けます。そのうえでEngineeringグループにだけ、CoworkとClaude Codeを許可する「Developer」ロールを付けます。両方に属する人は4つの権限をすべて持ちます。権限は足し算で、あるロールで別のロールの許可を取り消すことはできません。

Admin delegationのロールは、チャットやClaude Codeの権限を一切持たなくても成り立ちます。「Finance」ロールに請求の管理だけを持たせる、といった使い方です。

組織サイズ別 × 推奨ロール設計 早見表

組織規模と運用コストの兼ね合いで「そもそも Custom roles を使うか」「どのモデルから始めるか」を決める早見表です。

ロールが効くメンバーと効かないメンバー

移行で最初につまずきやすいのが、メンバーの役割(Members画面のRoleプルダウン)です。ここを「Custom」にしない限り、Custom roles はそのメンバーに作用しません。

くらべる

役割がUserのメンバーとCustomのメンバー

組織設定に従う

役割が User のメンバー

組織レベルで有効にした機能を、そのまま受け継ぎます。Custom roles で何を許可しても、このメンバーの権限は変わりません。

グループのロールで決まる

役割が Custom のメンバー

組織で有効な機能を自動では受け継ぎません。所属グループに付いたロールが許可した機能だけが使えます。グループに属さなければ、使えるプロダクトがなく、サインイン後は自分の設定ページに着きます。

OwnerやAdminをCustomに切り替えると、そのOwner / Adminの権限は外れます。管理者を移行するのは、その分の権限をロールで補うと決めたときだけにします。

設定手順

Enterprise前提で、管理コンソールの操作を順に追います。Teamプランは標準ロールのまま、ファイルアクセスと監査ログの節から読んでください。

手順

RBACを組む7つの手順

1. 1

   現状の機能トグルを棚卸しする

   Organization settings > Capabilities でWeb search / Memory / プロジェクト共有 / Cowork / Claude Code / code execution / Fast modeのオン・オフを書き出します。この段階では変えないのがポイントです。現状を固定してから、どこに差を付けたいかを文書にします。

2. 2

   ロールを作る

   Organization settings > Roles で Add role を押し、ロール(例: Engineer-Full)を作ります。Capabilitiesタブで機能を個別にトグルするか、「All capabilities」または「All generally available」で一括付与します。どちらも新機能が出るたびに自動で付与範囲が広がります。All capabilitiesにはベータや研究プレビューの機能も含まれます。

   ロール編集画面には、Capabilities・Permissions・Connectors・Modelsの4タブがあります。コネクタの権限は Always allow / Needs approval / Blocked の3段階で、新しく作ったロールは全コネクタが Needs approval から始まります。Modelsタブでは、モデルごとの許可を決めます。組織レベルで無効にしたモデルは、ロール側では付与できません。

3. 3

   グループを作ってロールを紐付ける

   Organization settings > Groups > Add group でグループ(例: Engineering)を作り、メンバーとロールを紐付けます。ロールはグループに付けるのが原則で、個人には直接付けられません。SCIM連携や異動時の運用コストも下がります。

4. 4

   グループ未所属のメンバーを洗い出す

   Members画面のRoleフィルタとGroupフィルタで、どのグループにも入っていないメンバーを探します。CSVエクスポートでも確認できます。グループ未所属のままCustomへ移すと、Coworkを含む管理対象の機能がすべて使えなくなります。

5. 5

   メンバーの役割をCustomに移す

   Path A(IdP経由)は、すでにグループマッピングを使っている組織向けで、IdPグループを「Custom」に対応付けます。使っていない組織が、このタイミングで新たに有効にするのは避けます。全員をマッピング済みのグループに入れる前に有効にすると、組織へのアクセスを失うメンバーが出ます。Path B(手動一括)は、Members画面のフィルタで対象を選び、Update selectedから役割を一括で変更します。どちらも、まず1チームで試して権限を確かめてから広げます。

6. 6

   組織レベルの機能を有効にする

   最後に、グループごとに出し分けたい機能を組織レベルでオンにします。これは「全員に配る」ではなく「ロールで割り当てられる状態にする」操作です。ここまでを逆順に進めると、旧ロールのまま機能を使える空白時間が生まれます。

7. 7

   代表メンバーで反映を確かめる

   各グループの代表メンバーで、Cowork起動、外部コネクタ接続、Claude Codeの呼び出しの可否を試します。メンバーの行の「⋮」から「View effective role」を開くと、その人が持つ権限と、それを許可しているロール名が一覧で出ます。

数字

運用で押さえておく4つの数字

• ロール変更の反映

  最大15分

  メンバーはブラウザーの再読み込みが必要な場合あり

• グループ数の上限

  1,000/組織

  1人が属せる数に上限はないが、250超で性能低下の可能性

• 監査ログの遡及

  180日

  Export logsで集計される範囲

• ログのダウンロードリンク

  24時間

  依頼したOwnerへメールで届く

組織レベルの設定とロールの設定は、どちらもオンでなければ機能は使えません。これらはすべて組織・ロール単位の制御です。管理対象デバイスごとにローカルMCPサーバーや拡張機能の実行そのものを止めるMDM管理者設定は別の層で、キーの詳細はCoworkのMDM管理者設定にまとめています。

権限が重なったとき何が勝つか

機能へのアクセスは、4つの層を順に通って決まります。プラットフォーム側の強制設定、組織レベルのトグル、ロールの許可、本人の設定の順で、最も制約の強い層が勝ちます。組織レベルでオフの機能は、どのロールでも解放できません。

複数のロールを持つ場合は、また別のルールになります。ロール同士は足し算で、1つでも許可していれば使えます。

Cowork固有の注意点が1つあります。書き込みを伴うコネクタのツールには、組織設定「Allow "Always allow" for connector tools」という独立した関門があります。初期状態はオフで、ロールが「Always allow」を付与しても上書きできません。オフのままだと、メンバーはCoworkのタスクごとに承認します。

コネクタ全般の権限は、ロールの許可と組織全体のツールポリシーのうち、厳しいほうが上限になります。ロールは組織ポリシーの範囲内で絞る手段で、広げる手段ではありません。ブロックされたコネクタはメンバーのメニューに出ず、ツール単位でブロックされた場合は灰色になります。

メンバー側の画面では、層ごとの違いは分かりません。組織がオフにした機能は「This feature is disabled for your organization.」、ロールが許可していない機能は「Contact your admin to request access to this feature.」と表示されます。問い合わせを受けたら、まずこの文言で層を切り分けられます。

管理権限だけを分けて渡す

ロールには機能の許可に加えて、管理画面の権限を持たせられます。管理者を増やさずに、請求の担当者や監査担当者に必要な範囲だけを渡す使い方です。

領域は8つあり、それぞれ「No access / Can view / Can manage」の3段階で設定します。領域の中で個別のページだけを許可することはできません。Can viewの人には画面は見えますが、操作はすべて無効になります。

上の4領域のほかに、Analytics(閲覧のみ)、Libraries(組織共有のスキル・プラグイン・コネクタの管理)、Directory management、Claude Design Adminがあります。

Identity & AccessをCan manageにしたロールは、自分自身のロールも編集できます。つまり権限を自分で広げられる状態なので、渡す相手はセキュリティやITの管理者に限るのが無難です。

次の操作は、管理権限を持たせても委譲できず、Owner専用のままです。OwnerとAdminの付け外し、APIキーとワークスペースの管理、Compliance APIの設定、組織レベルの機能トグルです。

ファイルアクセス権限の粒度

RBACで抜け落ちやすいのがファイル側の権限です。Coworkが触るデータは3層あり、制御ポイントが別です。

プロジェクトは Public(組織全員が閲覧・利用可)と Private(招待制)の2レベルです。Privateはメンバーごとに Can view と Can edit を分けます。Enterpriseではグループ単位の共有もできます。この共有はベータで、事前にグループ側で「Share resources with this group」をオンにしておく必要があります。グループを削除すると、そのグループに共有されていたプロジェクトへのアクセスも消えます。

個別チャットは、共有プロジェクトの中でも明示的に共有するまで本人のみに見えます。Publicプロジェクトでも同じです。アーカイブしても共有設定は解除されません。メンバーも権限もそのまま残るので、離職時の棚卸しでは、アーカイブ済みプロジェクトも共有設定から外しておくと漏れがありません。

プラグインのinstallation preferencesは Installed by default / Available to install / Required / Not available の4段階です。複数グループで設定が食い違うと、最も許容的な設定が勝ちます。順序はRequired > Installed by default > Available to install > Not availableです。特定のグループ以外には出したくないプラグインは、組織全体の設定を Not available にしたうえで、必要なグループにだけ許可します。グループ側を全部 Not available で揃えようとするより確実です。

なお、Required にしたプラグインは、ClaudeアカウントでサインインしたメンバーのClaude Codeにも入ります。フックなどがメンバーのPC上で動くため、設定前に中身を見てください。

監査ログとトラブルシューティング

監査ログはEnterpriseのOwner / Primary Ownerのみが Organization settings > Data and Privacy > Export logs から取得します。依頼後に集計され、ダウンロードリンクがメールで届きます。集計に時間がかかるため、メールは即座には来ません。顧客管理の暗号化キーを使うEnterpriseでは、このボタンが使えず、Compliance APIから取得します。

各エントリは created_at / actor_info / event / event_info / entity_info / ip_address / device_id / user_agent / client_platform を含みます。チャットやプロジェクトのタイトルと本文はエクスポートされず、識別子だけが入ります。会話の入出力が必要なときは、Primary Ownerが取得するデータエクスポートと組み合わせます。

記録対象のイベント一覧には、ロールやグループの作成・変更に当たる項目が載っていません。誰がいつロールを書き換えたかを、このログだけで追えるとは限りません。変更の履歴は、管理者側の申請記録にも残しておくと安心です。

設定したのに効かないとき

典型的なつまずきを、症状から並べます。

ロールを編集した直後にテストしたら、権限が変わっていない。反映には時間がかかります(前掲の数字を参照)。編集直後のテストは避け、メンバーにはブラウザーの再読み込みを頼みます。

以前は使えたCoworkが、移行後に起動できなくなった。サインイン後に自分の設定ページへ着き、使えるプロダクトがない状態なら、グループに入っていないか、グループにロールが付いていないケースです。手順4と同じ理由で、グループとロールの割当を先に終えてから、役割をCustomに移します。

SCIMを入れてから、Customだったメンバーが元の役割に戻った。SCIMディレクトリ同期とグループマッピングが有効な組織では、メンバーの役割はIdPの対応付けで決まります。以前にMembers画面でCustomにした人は、次の完全同期で、対応付けられた役割に戻ります。この戻りは監査ログに記録されず、同期が走るまでは普通に動くため、原因が見えにくくなります。Customのまま保つには、「Custom」に対応付けたIdPグループへその人を入れ、同期を実行します。

招待制やJITの組織で、SCIMのグループをロールに使えない。この2つのプロビジョニングでは、RBACに使えるのは手動で作ったグループだけです。SCIM同期のグループはサポートされません。役割の移行には、前掲のPath Bを使います。

IdPのグループ構造が反映されない。Claudeが扱うのは直接のメンバーシップだけです。IdPで入れ子にしたグループは、SCIMで押し出されても入れ子の関係が無視されます。プロバイダーによっては入れ子を展開して送るため、子グループのメンバーが直接のメンバーに見えることがあります。

グループ同期でページが重くなった。IdPからは、RBACや支出上限に使うグループだけを押し出します。同期の際は、メンバーまで同期せず、グループだけを選びます。メンバーの同期は、プロビジョニングやアクセスに影響することがあります。

移行後に構成がおかしいと気づいた。ロールバックできます。有効化した組織レベルの機能をオフにし、影響したメンバーを元の役割(Userなど)へ戻します。元の役割の権限はすぐ戻り、ロールの権限は効かなくなります。調整してから、もう一度移行します。

まとめ

移行は、グループへのロール割当を済ませてから役割をCustomに移す順序を守れば、問題が出ても組織レベルの機能をオフにして元の役割へ戻せます。SCIMのグループマッピングを使う組織では、Members画面でCustomにした人が次の同期で戻る点だけ、導入前に押さえておいてください。