Google Workspace共有ドライブにRBACを適用する：役割ベースで設計する権限管理と情シスの運用自動化ガイド

Google Workspace共有ドライブの権限管理は、組織の拡大とともに複雑化しやすい構造を持っています。この記事では、RBAC（役割ベースアクセス制御）の考え方を共有ドライブに適用し、GASとAdmin SDKで権限付与を自動化する方法を整理します。

この記事を読んだほうが良い人

100名規模以上の企業でGoogle Workspace共有ドライブを運用している情シス担当者
共有ドライブの権限付与が場当たり的になり、管理に課題を感じている方
異動や退職時の権限棚卸しに多くの時間を費やしている方
役割ベースアクセス制御（RBAC）の考え方を共有ドライブに適用したいと考えている方
Google Apps Script（GAS）とAdmin SDKを使った権限管理の自動化に興味がある方

Google Workspace共有ドライブの権限管理における課題

多くの企業では、共有ドライブの権限付与が個別の申請に基づいて行われがちです。新しいプロジェクトが始まるたびに、あるいは新入社員が入るたびに、情シス担当者が手動で共有ドライブへのアクセス権を設定しています。この場当たり的な運用は、以下のような課題を引き起こします。

セキュリティリスクの増大: 誰がどの共有ドライブにアクセスできるのか、全体像を把握しづらくなります。不要なアクセス権が付与されたまま放置されるリスクが高まります。
運用コストの増加: 異動や退職が発生するたびに、大量の共有ドライブから該当ユーザーの権限を手動で削除する作業が発生します。これは時間と労力を要し、ヒューマンエラーのリスクも伴います。
コンプライアンス違反のリスク: 監査時に正確なアクセス権限リストを提示できない、あるいはデータガバナンスポリシーが適用されていない状態になる可能性があります。
属人化の発生: 特定の担当者しか共有ドライブの権限構造を理解していないため、担当者不在時に対応が滞ることがあります。

これらの課題を解決し、体系的かつ効率的な権限管理を実現するために、役割ベースアクセス制御（RBAC）の考え方を共有ドライブに適用することが有効です。

共有ドライブ権限管理を体系化する「RBAC」の考え方

RBAC (Role-Based Access Control) は、ユーザーを特定の「役割（ロール）」に割り当て、その役割に紐づくアクセス権限を付与するセキュリティモデルです。個々のユーザーに直接権限を付与するのではなく、役割を介することで、権限管理の複雑さを大幅に軽減できます。

なぜ共有ドライブにRBACが必要か

共有ドライブにRBACを適用することで、以下のようなメリットが得られます。

管理の簡素化: ユーザーの異動や退職時には、ユーザーが属するグループや役割を変更するだけで、関連する共有ドライブの権限が自動的に変更されます。
セキュリティの向上: 役割に基づいた標準化された権限セットにより、過剰な権限付与を防ぎ、「必要最小限の権限だけを付与する」最小権限の原則（Principle of Least Privilege）を適用しやすくなります。
透明性の確保: どの役割がどの共有ドライブに、どのようなレベルでアクセスできるのかが明確になります。
自動化の促進: 役割と権限のマッピングが明確になることで、Google Apps Script（GAS）やAdmin SDKを利用した権限管理の自動化が容易になります。

業務役割とGoogle Workspace共有ドライブロールのマッピング設計

共有ドライブにRBACを適用する最初のステップは、自社の業務において必要な「業務役割」を定義し、それらの業務役割をGoogle Workspace（以下、GWS）の共有ドライブが提供する「標準ロール」にマッピングすることです。

1. 業務役割の定義例

まずは、自社の組織構造やプロジェクト体制に合わせて、具体的な業務役割を洗い出します。

プロジェクトリード: プロジェクト全体の管理、メンバー追加・削除、ファイルの最終承認など。
チームメンバー: プロジェクトファイルの作成・編集、情報共有など。
外部委託パートナー: 特定のファイルへの参照・編集（限定的）など。
監査担当: すべてのファイルへの参照（読み取り専用）、履歴確認など。
部門管理者: 部門内の共有ドライブ管理、メンバー管理など。

2. GWS共有ドライブの標準ロール

GWSの共有ドライブには、以下の5つの標準ロールが用意されています。

管理者 (Manager): 共有ドライブのメンバー管理、ファイル・フォルダの管理、設定変更など、共有ドライブのすべてを管理できます。
コンテンツ管理者 (Content Manager): ファイルの追加、編集、移動、削除が可能です。
投稿者 (Contributor): ファイルの追加、編集が可能です。
閲覧者（コメント可） (Commenter): ファイルの閲覧とコメントの追加が可能です。
閲覧者 (Viewer): ファイルの閲覧のみ可能です。

3. 業務役割とGWSロールの対応表

定義した業務役割を、GWSの標準ロールにマッピングします。このマッピングは、組織のポリシーや業務要件によって調整が必要です。

業務役割	GWS共有ドライブロール	備考
プロジェクトリード	管理者	共有ドライブの全体管理、メンバー変更権限が必要
チームメンバー	コンテンツ管理者	ファイルの作成・編集・削除権限が必要
外部委託パートナー	投稿者または閲覧者（コメント可）	外部パートナーの作業範囲に応じて限定的な権限を付与
監査担当	閲覧者	参照のみ。セキュリティ監査や情報確認のために全ファイルへのアクセス
部門管理者	管理者	部門内の共有ドライブを管理。必要に応じて複数ロールを持つ場合あり

4. 役割パターン定義（プロジェクト、部門、監査の3類型）

実際の運用では、共有ドライブの利用目的によって役割の適用パターンを類型化すると管理しやすくなります。

プロジェクト型: 特定のプロジェクト期間中のみ活動するチーム。プロジェクトリード、チームメンバー、外部委託パートナーといった役割を適用。プロジェクト終了時に役割を解除し、権限を自動削除。
部門型: 恒常的に存在する部門（営業部、開発部など）。部門管理者、部門メンバーといった役割を適用。異動時に役割を変更することで権限を調整。
監査・情報共有型: 全社的な情報共有や監査目的の共有ドライブ。監査担当、全社閲覧者といった役割を適用。

これらの類型に基づいて、GWSグループを事前に作成し、各グループにGWS共有ドライブロールを付与する運用が推奨されます。ユーザーの所属する業務役割に応じて適切なGWSグループにユーザーを追加することで、間接的に共有ドライブの権限を制御します。

GASとAdmin SDKを活用した権限適用自動化の具体例

ここでは、Google Apps Script（GAS）とAdmin SDK Directory Serviceを組み合わせて、グループベースで共有ドライブの権限を自動付与する例を紹介します。この例では、特定の共有ドライブに、特定のGWSグループを「コンテンツ管理者」として追加するスクリプトを考えます。

前提:

Google Workspaceの管理者権限を持つアカウントでGASプロジェクトを作成します。
GASプロジェクトで Admin SDK API と Drive API を有効にします。（「サービス」メニューから追加）
GWSグループ (projects-sales-team-content-managers@yourdomain.com) が事前に存在し、共有ドライブ (Sales Project 2024) も存在すると仮定します。

/**
 * 特定の共有ドライブにGWSグループをコンテンツ管理者として追加する関数
 */
function addGroupToSharedDriveAsContentManager() {
  const sharedDriveName = "Sales Project 2024"; // 権限を付与したい共有ドライブ名
  const groupEmail = "projects-sales-team-content-managers@yourdomain.com"; // 権限を付与したいGWSグループのメールアドレス

  try {
    // 1. 共有ドライブのIDを取得
    // Drive API v2を使用し、共有ドライブを検索します。
    // v3では共有ドライブの検索が異なるため注意が必要です。
    const drives = Drive.Drives.list({
      q: `name = '${sharedDriveName}'`,
      useDomainAdminAccess: true // 管理者権限でアクセス
    });

    if (!drives.items || drives.items.length === 0) {
      console.error(`共有ドライブ '${sharedDriveName}' が見つかりませんでした。`);
      return;
    }
    const sharedDriveId = drives.items[0].id;
    console.log(`共有ドライブID: ${sharedDriveId}`);

    // 2. 共有ドライブにグループを権限追加
    const resource = {
      role: 'fileOrganizer', // 付与するロール (organizer/管理者, fileOrganizer/コンテンツ管理者, writer/投稿者, commenter/閲覧者コメント可, reader/閲覧者)
      type: 'group',
      value: groupEmail
    };

    // Drive API v2のPermissions.insertを使用して権限を追加します
    // supportsAllDrives:true を渡すことで共有ドライブへの権限付与が可能になります
    Drive.Permissions.insert(resource, sharedDriveId, {
      supportsAllDrives: true, // 共有ドライブへの操作であることを示す
      sendNotificationEmails: false // 通知メールを送信しない
    });

    console.log(`グループ '${groupEmail}' を共有ドライブ '${sharedDriveName}' にコンテンツ管理者として追加しました。`);

  } catch (e) {
    console.error(`権限追加中にエラーが発生しました: ${e.message}`);
  }
}

/**
 * 例：新規ユーザーを特定のGWSグループに追加する関数
 * (Admin SDK Directory Serviceの利用例)
 */
function addUserToGroup() {
  const userEmail = "new-employee@yourdomain.com"; // 追加したいユーザーのメールアドレス
  const groupEmail = "projects-sales-team-content-managers@yourdomain.com"; // 追加したいGWSグループのメールアドレス

  try {
    // グループメンバーリソースを作成
    const member = {
      email: userEmail,
      role: "MEMBER" // MEMBER, MANAGER, OWNER
    };

    // AdminDirectory APIを使用してグループにメンバーを追加
    AdminDirectory.Members.insert(member, groupEmail);
    console.log(`ユーザー '${userEmail}' をグループ '${groupEmail}' に追加しました。`);
  } catch (e) {
    console.error(`ユーザーをグループに追加中にエラーが発生しました: ${e.message}`);
  }
}

注意点:

上記コードはDrive API v2を使用しています。Drive API v3では共有ドライブの検索や権限付与の方法が一部異なるため、バージョンを確認して利用してください。
useDomainAdminAccess: true は、管理者権限で実行していることを示します。
supportsAllDrives: true は、共有ドライブに対する操作であることをAPIに伝えます。
このスクリプトはあくまで一例です。実際の運用では、ユーザーの入社・異動・退職イベントと連携させ、自動的にグループメンバーシップを更新する仕組みと組み合わせることで、真の自動化が実現します。

共有ドライブ権限管理の制約と注意点

GASとDrive APIで権限管理を自動化する前に、共有ドライブ固有の制約を把握しておく必要があります。設計段階で見落とすと後から構造を作り直すことになるため、先に確認しておきます。

フォルダ単位での権限分離は不可

共有ドライブの権限はドライブ単位で設定されます。「このフォルダだけ別のロールにしたい」という要件には対応できません。フォルダごとに異なるアクセス権限が必要な場合は、別の共有ドライブとして切り出すのが標準的な設計です。

外部ユーザーへの権限付与は管理コンソール設定に依存

共有ドライブへのドメイン外ユーザーの追加は、管理コンソールの共有ドライブ設定「組織外のユーザーとの共有を許可する」が有効になっていることが前提です。組織のポリシーで外部共有を制限している場合、GASから外部グループを追加しようとするとAPIエラーになります。外部パートナーへの権限付与を自動化する場合は、事前に管理コンソール側の設定を確認してください。

GASの実行時間上限（6分）

GASの1回の実行は最大6分が上限です。共有ドライブ数が多い組織で全ドライブを一括処理しようとすると、タイムアウトのリスクがあります。ドライブ数が多い場合は、処理を分割してトリガーで継続実行する設計が必要です。

Drive API v2とv3の差異

今回のコードはDrive API v2を前提にしています。v3では共有ドライブが drives リソースとして整理されており、レスポンスの構造（items → drives）が異なります。将来的にv3へ移行する場合は、レスポンスのパース処理の見直しが必要です。現時点でGAS Advanced Serviceの Drive オブジェクトはv2ベースで動作するため、本記事のコードはそのまま使用できます。

RBAC設計と運用のチェックリスト

共有ドライブのRBACを導入する際に考慮すべきチェックリストです。

業務役割の明確化: 組織内の主要な業務役割がすべて定義されているか。役割の粒度が細かすぎると管理コストが増えるため、5〜8種類を目安に整理します。
GWSロールへのマッピング: 各業務役割が適切なGWS共有ドライブロールにマッピングされているか。過剰な権限付与がないか確認します。
GWSグループの活用: 各業務役割に対応するGWSグループが作成され、ユーザーが適切に割り当てられているか。グループ単位で権限を管理することで、ユーザー増減に対してドライブ設定を変更せずに対応できます。
共有ドライブの命名規則: 共有ドライブ名がその目的やアクセスレベルを推測できるものになっているか。命名規則を先に決めておくと、GASでのドライブ検索ロジックがシンプルになります。
定期的なレビュー: 定義した業務役割とGWSロールのマッピングが現状に合致しているか、定期的に見直す運用プロセスがあるか。
自動化の組み込み: ユーザーの異動・退職時に、GWSグループのメンバーシップが自動的に更新される仕組みが導入されているか。
監査ログの活用: 権限変更やアクセスログを定期的に監視し、不正なアクセスがないか確認する体制があるか。
ドキュメント化: RBACの設計思想、業務役割とGWSロールのマッピング、運用手順が文書化され、関係者間で共有されているか。属人化防止の観点からも、設計書は必ず残します。

まとめ：体系的な権限管理で情シスの負担を軽減する

Google Workspace共有ドライブの権限管理は、組織規模が大きくなるほど複雑化し、情シス担当者の大きな負担となります。この記事では、役割ベースアクセス制御（RBAC）の考え方を共有ドライブに適用し、業務役割とGWSロールのマッピングを通じて体系的な権限管理を実現する方法を解説しました。

RBACを導入することで、場当たり的な権限付与から脱却し、セキュリティの向上、運用コストの削減、そしてコンプライアンスの強化が期待できます。さらに、GASとAdmin SDKを組み合わせることで、権限付与のプロセスを自動化し、情シスの日常業務を大幅に効率化することが可能です。

具体的な次のアクションとして、まず自社に存在する業務役割を5〜8種類程度で書き出してみることをお勧めします。次に、GWSグループの命名規則（例: role-projectlead@yourdomain.com、role-contributor-sales@yourdomain.com など）を先に決めてください。命名規則が固まれば、GASでのグループ検索やメンバーシップ管理のロジックが自然に整理されます。役割設計とグループ命名規則の2点が決まれば、本記事のコードを土台に自動化の実装を進める準備が整います。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る

一社ずつ、一から。