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

要点

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

RBACがなぜCoworkで重要か

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

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機能ディープダイブも参照してください。

前提条件

Custom roles と監査ログはEnterprise限定です。Custom roles を適用したメンバーはデフォルト権限を失い、グループ経由で付与されたcapabilityしか使えません。

ロール設計の基本3モデル

公式ガイドではRBACの出発点として3パターンが示されます。相互排他ではなく組み合わせられますが、どれを骨格にするか先に決めると設計が速く済みます。

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

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

設定手順

Enterprise前提で管理コンソール操作を順に追います。TeamプランはStep 2 〜 3をスキップし、標準ロールのままStep 4以降を運用します。

Step 1: 現在のcapabilityを棚卸しする

Organization settings > Capabilities でWeb search / Memory / Projects / Cowork / Claude Code / code execution / fast-modeのオン・オフを確認します。ここでは変えないのがポイントで、現状固定してから「どこに差を付けたいか」をドキュメント化します。

Step 2: Custom roles を作る

Organization settings > Custom roles > + Add role からロール(例: Engineer-Full)を作り、Claude Cowork / Claude Code / Claude Design / Fast-mode / Code execution / Web search / Memoryを個別にトグルします。反映は最大1分ほど。

Step 3: グループを作りロールを割り当てる

Organization settings > Groups > Add group でグループ(例: Engineering)を作り、メンバーと Custom roles を紐付けます。上限は100グループ。ロールはグループに付けるのが原則で、SCIM連携や異動時の運用コストを下げます。

Step 4: メンバーを Custom roles に移行する

Path A(IdP経由)はSCIMのrole mappingでIdPグループを Custom roles に対応付け、Path B(手動一括)はMembers画面のフィルタとバルク編集で変更します。まず1チームで試験導入し、capabilityが想定通り制限されるのを確認してから展開します。切替後はデフォルト権限を失うため、グループ未所属だとCoworkすら起動できない点に注意。

Step 5: Organizationレベルのcapabilityを有効化

ロールとグループの準備後に Capabilities で機能をオンにします。階層は "プラットフォーム制限 → 組織 → Custom roles → 個人設定" で最も制約的なレイヤーが勝つため、組織レベルで無効化した機能はどのロールでも解放できません。

Step 6: 反映確認

各グループの代表メンバーでCowork起動・外部コネクタ接続・Claude Code呼び出しの可否を確認します。Enterpriseでは Usage ページからグループ単位のspend limitも設定でき、コストのガードレールを同時にかけられます。

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

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

プロジェクトは Public(組織全員閲覧可)と Private(招待制)の2レベル。後者はメンバーごとに Can view と Can edit を分けます。installation preferencesは Installed by default / Available / Not available / Required の4段階。個別チャットは共有プロジェクト内でも明示共有するまで本人のみ、アーカイブ時に共有設定が全解除される挙動は離職時棚卸しで効きます。コネクタは複数グループで設定衝突時に最も許容的な設定が勝つため、Not available を徹底するには全グループで揃える必要があります。

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

監査ログはEnterpriseのOwner / Primary Ownerのみが Organization settings > Data and Privacy > Export logs から取得します。保持期間は過去180日、依頼後24時間有効なダウンロードリンクがメールで届きます。プログラマティック取得にはCompliance APIが使えます。

各エントリは created_at / actor_info / event / event_info / entity_info / ip_address / device_id / user_agent / client_platform を含みます。チャットやProject本文は監査ログに含まれないため、会話内容が必要なら別途データエクスポートと組み合わせます。

典型的なつまずきは3点。反映遅延があるため Custom roles 編集直後のテストは避ける。グループ未所属の機能喪失を防ぐため移行とグループ割当は同時に行う。SCIMとJIT / 招待制は非互換で、IdPグループマッピングはSCIMでしか動かず、JITや招待制の組織はPath Bに頼ります。

まとめ

Claude CoworkのRBACは、見かけ上は Organization settings のトグル群ですが、実態は「グループをsource of truthにしてcapabilityを積み上げる」設計です。小規模なら標準ロール、中規模ならBase Plus Additive、大企業ならDepartment-Based × SCIM、と入り口が決まればStep 1 〜 6をなぞるだけで最小権限に近づきます。ファイル側はプロジェクト可視性とコネクタ管理の二階建て、監査ログは180日保持・API取得可を押さえれば内部統制の証跡として機能します。まず Capabilities の現状棚卸しと、権限の強い1 〜 2グループの試験導入から始めるのが安全です。