すべての Google ドライブのファイル、フォルダ、共有ドライブには、関連付けられた permissions
リソースがあります。各リソースは、特定の type
(user
、group
、domain
、anyone
)と role
(owner
、organizer
、fileOrganizer
、writer
、commenter
、reader
)の権限を識別します。たとえば、ファイルに特定のユーザー(type=user
)に読み取り専用アクセス(role=reader
)を許可する権限があり、別の権限で特定のグループ(type=group
)のメンバーにファイルにコメントを追加する権限(role=commenter
)を付与できます。
ロールと各ロールで許可されるオペレーションの一覧については、ロールと権限をご覧ください。
ドライブのリソースを共有するシナリオ
共有シナリオには次の 5 種類があります。
ユーザーがマイ ドライブ内のファイルを共有するには、
role=writer
またはrole=owner
が必要です。ファイルの
writersCanShare
ブール値がfalse
に設定されている場合、ユーザーにはrole=owner
が必要です。role=writer
を持つユーザーが有効期限と時刻で管理される一時的なアクセス権を持っている場合、そのユーザーはファイルを共有できません。詳細については、有効期限を設定してファイル アクセスを制限するをご覧ください。
マイドライブのフォルダを共有するには、ユーザーに
role=writer
またはrole=owner
が必要です。ファイルの
writersCanShare
ブール値がfalse
に設定されている場合、ユーザーにはより許容度の高いrole=owner
が必要です。role=writer
のマイドライブ フォルダでは、一時的なアクセス(有効期限の日時による管理)は許可されません。詳細については、有効期限を設定してファイル アクセスを制限するをご覧ください。
共有ドライブ内のファイルを共有するには、ユーザーに
role=writer
、role=fileOrganizer
、またはrole=organizer
の権限が必要です。writersCanShare
の設定は、共有ドライブ内のアイテムには適用されません。常にtrue
に設定されているものとして扱われます。
共有ドライブ内のフォルダを共有するには、ユーザーに
role=organizer
が必要です。- 共有ドライブの
sharingFoldersRequiresOrganizerPermission
制限がfalse
に設定されている場合、role=fileOrganizer
を持つユーザーは、その共有ドライブ内のフォルダを共有できます。
- 共有ドライブの
共有ドライブのメンバーシップを管理するには、
role=organizer
が必要です。共有ドライブのメンバーになれるのは、ユーザーとグループのみです。
有効期限を設定してファイルへのアクセスを制限する
機密性の高いプロジェクトで他のユーザーと共同で作業している場合、一定の期間が経過した後に、ドライブ内の特定のファイルへのアクセスを制限する必要があることがあります。マイドライブ内のファイルについては、有効期限を設定してアクセスを制限または削除できます。
有効期限を設定するには:
permissions
リソースでcreate()
メソッドを使用し、expirationTime
フィールド(および他の必須フィールド)を設定します。詳細については、権限を作成するをご覧ください。permissions
リソースでupdate()
メソッドを使用して、expirationTime
フィールドを設定します(他の必須フィールドも設定します)。詳細については、権限を変更するをご覧ください。
expirationTime
フィールドは、RFC 3339 日時を使用して権限が期限切れになる日時を示します。有効期限には次の制限があります。
- ユーザーとグループの権限に対してのみ設定できます。
- 時刻には将来の時刻を指定してください。
- 1 年以上先の日時は指定できません。
有効期限について詳しくは、以下の記事をご覧ください。
権限の伝播
フォルダの権限リストは下位に伝播され、すべての子ファイルとフォルダは親から権限を継承します。権限や階層が変更されると、ネストされたすべてのフォルダで伝播が再帰的に行われます。たとえば、フォルダ内にファイルが存在し、そのフォルダが別のフォルダ内に移動された場合、新しいフォルダの権限がファイルに伝播されます。新しいフォルダでファイルのユーザーに新しいロール(「書き込み者」など)が付与されている場合、古いロールはオーバーライドされます。
逆に、ファイルがフォルダから role=writer
を継承し、「リーダー」ロールを持つ別のフォルダに移動された場合、ファイルは role=reader
を継承するようになります。
継承された権限は、共有ドライブ内のファイルやフォルダから削除できません。代わりに、これらの権限は、継承元の直接的または間接的な親で調整する必要があります。継承された権限は、[マイドライブ] または [共有アイテム] のアイテムから削除できます。
逆に、マイドライブのファイルまたはフォルダでは、継承された権限をオーバーライドできます。そのため、ファイルがマイドライブ フォルダから role=writer
を継承する場合は、ファイルに role=reader
を設定して権限レベルを下げることができます。
機能
permissions
リソースは、最終的には現在のユーザーがファイルやフォルダに対してアクションを実行できるかどうかを判別しません。代わりに、files
リソースには、ファイルまたはフォルダに対してアクションを実行できるかどうかを示すブール値 capabilities
フィールドのコレクションが含まれています。Google Drive API は、ファイルまたはフォルダに関連付けられている現在のユーザーの権限リソースに基づいて、これらのフィールドを設定します。
たとえば、アレックスがアプリにログインしてファイルを共有しようとすると、アレックスのロールに基づいてファイルに対する権限がチェックされます。ロールでファイルの共有が許可されている場合、ファイルに関連する capabilities
(canShare
など)がロールに関連して入力されます。アレックスがファイルを共有しようとすると、アプリは capabilities
をチェックして、canShare
が true
に設定されていることを確認します。
ファイル capabilities
を取得する例については、ユーザー権限を確認するをご覧ください。
権限を作成する
権限を作成するときに必要なフィールドは次の 2 つです。
type
:type
は権限のスコープを識別します(user
、group
、domain
、anyone
)。type=user
を含む権限は特定のユーザーに適用されますが、type=domain
を含む権限は特定のドメイン内のすべてのユーザーに適用されます。role
:role
フィールドは、type
が実行できるオペレーションを識別します。たとえば、type=user
とrole=reader
の権限は、特定のユーザーにファイルまたはフォルダに対する読み取り専用アクセス権を付与します。type=domain
とrole=commenter
を含む権限では、ドメイン内のすべてのユーザーがファイルにコメントを追加できます。ロールと各ロールで許可されるオペレーションの一覧については、ロールと権限をご覧ください。
type=user
または type=group
の権限を作成する場合は、特定のユーザーまたはグループを権限に関連付ける emailAddress
も指定する必要があります。
type=domain
の権限を作成する場合は、特定のドメインを権限に関連付けるために domain
も指定する必要があります。
権限を作成するには:
- 関連付けられたファイルまたはフォルダの
fileId
パスパラメータを使用して、create()
メソッドを使用します。 - リクエストの本文で、
type
とrole
を指定します。 type=user
またはtype=group
の場合は、emailAddress
を指定します。type=domain
の場合は、domain
を指定します。
例を表示
次のコードサンプルは、権限を作成する方法を示しています。レスポンスには、割り当てられた permissionId
を含む Permission
リソースのインスタンスが返されます。
リクエスト
POST https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
{ "requests": [ { "type": "user", "role": "commenter", "emailAddress": "alex@altostrat.com" } ] }
レスポンス
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "commenter"
}
対象グループを使用する
対象グループとは、ユーザーにアイテムの共有先として推奨できる部門やチームなどのグループのことです。組織全体ではなく、より限定された対象や特定のユーザーとアイテムを共有するようユーザーに促すことができます。対象グループを使用すると、データのセキュリティとプライバシーを強化し、ユーザーが適切に共有しやすくなります。詳細については、ターゲット オーディエンスについてをご覧ください。
対象グループを使用するには:
Google 管理コンソールで、メニュー アイコン > [ディレクトリ] > [対象グループ] に移動します。
このタスクを行うには、特権管理者権限を持つアカウントでログインする必要があります。
[対象グループ] リストで、対象グループの名前をクリックします。対象グループを作成するには、対象グループを作成するをご覧ください。
対象グループの URL から一意の ID(
https://admin.google.com/ac/targetaudiences/ID
)をコピーします。type=domain
を使用して権限を作成し、domain
フィールドをID.audience.googledomains.com
に設定します。
ユーザーが対象グループとどのようにやり取りするかについては、リンク共有のユーザー エクスペリエンスをご覧ください。
ファイル、フォルダ、共有ドライブのすべての権限を取得する
permissions
リソースの list()
メソッドを使用して、ファイル、フォルダ、共有ドライブのすべての権限を取得します。
例を表示
次のコードサンプルは、すべての権限を取得する方法を示しています。レスポンスで権限のリストが返されます。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions
レスポンス
{
"kind": "drive#permissionList",
"permissions": [
{
"id": "PERMISSION_ID
",
"type": "user",
"kind": "drive#permission",
"role": "commenter"
}
]
}
ユーザー権限を確認する
アプリでファイルを開くと、ファイルの機能を確認し、現在のユーザーの権限を反映するように UI をレンダリングする必要があります。たとえば、ユーザーにファイルに対する canComment
権限がない場合は、UI でコメント機能が無効になっている必要があります。
capabilities
の詳細については、機能セクションをご覧ください。
機能を確認するには、fileId
パス パラメータと fields
パラメータを capabilities
フィールドに設定して、files
リソースの get()
メソッドを呼び出します。fields
パラメータを使用してフィールドを返す方法について詳しくは、ファイルの特定のフィールドを返すをご覧ください。
例を表示
次のコードサンプルは、ユーザーの権限を確認する方法を示しています。レスポンスには、ユーザーがファイルに対して持っている機能のリストが返されます。各機能は、ユーザーが実行できるきめ細かいアクションに対応しています。一部のフィールドは、共有ドライブ内のアイテムにのみ入力されます。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID
?fields=capabilities
レスポンス
{ "capabilities": { "canAcceptOwnership": false, "canAddChildren": false, "canAddMyDriveParent": false, "canChangeCopyRequiresWriterPermission": true, "canChangeSecurityUpdateEnabled": false, "canComment": true, "canCopy": true, "canDelete": true, "canDownload": true, "canEdit": true, "canListChildren": false, "canModifyContent": true, "canModifyContentRestriction": true, "canModifyLabels": true, "canMoveChildrenWithinDrive": false, "canMoveItemOutOfDrive": true, "canMoveItemWithinDrive": true, "canReadLabels": true, "canReadRevisions": true, "canRemoveChildren": false, "canRemoveMyDriveParent": true, "canRename": true, "canShare": true, "canTrash": true, "canUntrash": true } }
共有ドライブ内のファイルとフォルダのロールのソースを特定する
ファイルまたはフォルダのロールを変更するには、ロールのソースを把握する必要があります。共有ドライブの場合、ロールのソースは、共有ドライブのメンバーシップ、フォルダのロール、ファイルのロールに応じて異なります。
共有ドライブまたはそのドライブ内のアイテムのロールのソースを特定するには、fileId
パスパラメータと permissionId
パスパラメータを使用して permissions
リソースの get()
メソッドを呼び出し、fields
パラメータを permissionDetails
フィールドに設定します。
permissionId
を見つけるには、fileId
パスパラメータを使用して permissions
リソースの list()
メソッドを使用します。list
リクエストで permissionDetails
フィールドを取得するには、fields
パラメータを permissions/permissionDetails
に設定します。
このフィールドには、ユーザー、グループ、ドメインの継承されたファイル権限と直接ファイル権限がすべて列挙されます。
例を表示
次のコードサンプルは、ロールのソースを特定する方法を示しています。レスポンスは、permissions
リソースの permissionDetails
を返します。inheritedFrom
フィールドには、権限の継承元となるアイテムの ID を指定します。
リクエスト
GET https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
?fields=permissionDetails&supportsAllDrives=true
レスポンス
{
"permissionDetails": [
{
"permissionType": "member",
"role": "commenter",
"inheritedFrom": "INHERITED_FROM_ID
",
"inherited": true
},
{
"permissionType": "file",
"role": "writer",
"inherited": false
}
]
}
権限を変更
ファイルまたはフォルダの権限を変更するには、割り当てられたロールを変更します。
permissions
リソースでupdate()
メソッドを呼び出し、permissionId
パス パラメータを変更権限に設定し、fileId
パス パラメータを関連付けられたファイル、フォルダ、共有ドライブに設定します。permissionId
を見つけるには、fileId
パスパラメータを使用してpermissions
リソースのlist()
メソッドを使用します。リクエスト内で、新しい
role
を特定します。
ユーザーまたはグループがすでにメンバーである場合でも、共有ドライブ内の個々のファイルまたはフォルダに対する権限を付与できます。たとえば、アレックスは共有ドライブのメンバーシップに role=commenter
が含まれています。ただし、アプリは共有ドライブ内のファイルに対して Alex に role=writer
を付与できます。この場合、新しいロールはメンバーシップを通じて付与されるロールよりも制限が緩やかであるため、新しい権限はファイルまたはフォルダの有効なロールになります。
例を表示
次のコードサンプルは、ファイルまたはフォルダの権限をコメント投稿者から作成者に変える方法を示しています。レスポンスには、permissions
リソースのインスタンスが返されます。
リクエスト
PATCH https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
{ "requests": [ { "role": "writer" } ] }
レスポンス
{
"kind": "drive#permission",
"id": "PERMISSION_ID
",
"type": "user",
"role": "writer"
}
保留中のアクセス権の提案を一覧表示して解決する
アクセス プロポーザルは、リクエスト元から承認者への提案で、受信者にドライブ アイテムへのアクセス権を付与します。
承認者は、ドライブ ファイル全体で未解決のアクセス プロポーザルをすべて確認して対応できます。つまり、アクセス プロポーザルをプログラムでクエリして解決することで、承認プロセスを高速化できます。また、承認者は提案を集約して表示することもできます。
Drive API には accessproposals
リソースが用意されているため、保留中のアクセス プロポーザルを表示して解決できます。accessproposals
リソースのメソッドは、ファイル、フォルダ、共有ドライブ内のファイルでは機能しますが、共有ドライブでは機能しません。
以下の用語は、アクセス提案に固有のものです。
- リクエスト元: ドライブ アイテムへのアクセスの提案を開始したユーザー。
- 受信者: アクセス プロポーザルが承認された場合に、ファイルに対する追加の権限を受け取るユーザー。多くの場合、受信者はリクエスト元と同じですが、常に同じとは限りません。
- 承認者: アクセス プロポーザルの承認(または拒否)を担当するユーザー。これは通常、そのユーザーがドキュメントのオーナーであるか、ドキュメントを共有する権限を持っているためです。
保留中のアクセス プロポーザルを一覧表示する
ドライブ アイテムの保留中のアクセス提案をすべて一覧表示するには、accessproposals
リソースで list()
メソッドを呼び出し、fileId
パス パラメータを指定します。
ファイルの保留中のプロポーザルを一覧表示できるのは、そのファイルの承認者のみです。承認者は、ファイルに対する can_approve_access_proposals
権限を持つユーザーです。リクエスト元が承認者でない場合は、空のリストが返されます。capabilities
の詳細については、機能のセクションをご覧ください。
レスポンスの本文は、ファイルに関する未解決のアクセス プロポーザルのリストを表す AccessProposal
オブジェクトで構成されています。
AccessProposal
オブジェクトには、リクエスト元、受信者、リクエスト元が追加したメッセージなど、各提案に関する情報が含まれます。また、リクエスト元が提案した role
を view
とグループ化する AccessProposalRoleAndView
オブジェクトも含まれます。role
は繰り返しフィールドであるため、プロポーザルごとに複数存在する可能性があります。たとえば、プロポーザルに role=reader
と view=published
の AccessProposalRoleAndView
オブジェクトと、role=writer
値のみを持つ追加の AccessProposalRoleAndView
オブジェクトが含まれる場合があります。詳細については、ビューをご覧ください。
次のクエリ パラメータを渡して、アクセス プロポーザルのページネーションのカスタマイズやフィルタリングを行います。
pageToken
: 前回の list 呼び出しから受け取ったページトークン。後続のページを取得するには、このトークンを指定します。pageSize
: ページごとに返されるアクセス提案の最大数。
保留中のアクセス権の提案を解決する
ドライブ アイテムの保留中のアクセス提案をすべて解決するには、accessproposals
リソースの resolve()
メソッドを呼び出し、fileId
パス パラメータと proposalId
パス パラメータを含めます。
resolve()
メソッドには、提案に対して行うアクションを示す action
クエリ パラメータが含まれています。Action
オブジェクトは、プロポーザルの状態変化を追跡し、承認または拒否されたかどうかを把握します。
resolve()
メソッドには、role
と view
のオプションのクエリ パラメータも含まれています。サポートされているロールは writer
、commenter
、reader
のみです。ロールが指定されていない場合、デフォルトの reader
が使用されます。オプションの send_notification
クエリ パラメータを使用すると、提案が承認または拒否されたときに、リクエスト元にメール通知を送信できます。
list()
メソッドと同様に、提案を解決するユーザーには、ファイルに対する can_approve_access_proposals
権限が必要です。capabilities
の詳細については、機能のセクションをご覧ください。
提案は、ドライブ リソースを共有するシナリオに記載されているパターンを使用して解決されます。同じユーザーに、ロールが異なる提案が複数ある場合は、次のようになります。
- 1 つの提案が承認され、もう 1 つが拒否された場合、承認されたロールがドライブ アイテムに適用されます。
- 両方の提案が同時に承認された場合、より高い権限を持つ提案(
role=writer
とrole=reader
など)が適用されます。他のアクセス提案はアイテムから削除されます。
resolve()
メソッドにプロポーザルを送信すると、共有アクションが完了します。AccessProposal
は list()
メソッドを介して返されなくなりました。提案が承認されたら、ユーザーは permissions
コレクションを使用して、ファイルまたはフォルダの権限を更新する必要があります。詳細については、権限を変更するをご覧ください。
ファイルまたはフォルダへのアクセス権を取り消す
ファイルまたはフォルダへのアクセス権を取り消すには、fileId
と permissionId
パスパラメータを設定して、permissions
リソースの delete()
メソッドを呼び出して、権限を削除します。
[マイドライブ] 内のアイテムについては、継承された権限を削除できます。継承された権限を削除すると、アイテムと子アイテム(存在する場合)へのアクセス権が取り消されます。
共有ドライブ内のアイテムの場合、継承された権限を取り消すことはできません。代わりに、親ファイルまたはフォルダの権限を更新または取り消します。
delete()
メソッドは、共有ドライブのファイルまたはフォルダに直接適用された権限を削除するためにも使用されます。
例を表示
次のコードサンプルは、permissionId
を削除してアクセス権を取り消す方法を示しています。成功すると、レスポンスの本文は空になります。権限が削除されたことを確認するには、fileId
パス パラメータを使用して permissions
リソースの list()
メソッドを使用します。
リクエスト
DELETE https://www.googleapis.com/drive/v3/files/FILE_ID
/permissions/PERMISSION_ID
ファイルのオーナー権限を同じ組織内の別の Google Workspace アカウントに譲渡する
[マイドライブ] に存在するファイルのオーナー権限は、1 つの Google Workspace アカウントから同じ組織内の別のアカウントに移行できます。共有ドライブを所有する組織が、その中のファイルを所有します。そのため、共有ドライブ内のファイルとフォルダのオーナー権限の移行はサポートされていません。共有ドライブの主催者は、その共有ドライブから自分の「マイドライブ」にアイテムを移動し、その「マイドライブ」にオーナー権限が譲渡されます。
[マイドライブ] 内のファイルのオーナー権限を譲渡するには、次のいずれかを行います。
特定のユーザー(
type=user
)にオーナー アクセス権(role=owner
)を許可するファイル権限を作成します。role=owner
で既存のファイルの権限を更新し、指定したユーザー(transferOwnership=true
)にオーナー権限を譲渡します。
ファイルのオーナー権限を 1 つのコンシューマ アカウントから別のコンシューマ アカウントに移行する
ファイルのオーナー権限は、コンシューマ アカウント間で移行できます。ただし、ドライブでは、移行先のオーナーが明示的に移行に同意するまで、2 つの一般ユーザー向けアカウント間でファイルのオーナー権限が移行されることはありません。ファイルのオーナー権限を一般ユーザー向けアカウントから別のアカウントに移行するには:
現在のオーナーは、移行先のオーナーのファイル権限を作成または更新して、オーナー権限の移行を開始します。権限には、
role=writer
、type=user
、pendingOwner=true
の設定を含める必要があります。現在のオーナーが新しいオーナーの権限を作成する場合は、ファイルの所有権を引き継ぐよう求められていることを示すメール通知が新しいオーナーに送信されます。新しいオーナーは、ファイルの権限を作成または更新して、オーナー権限の譲渡リクエストを承諾します。権限には、
role=owner
とtransferOwnership=true
の設定が含まれている必要があります。新しい権限を作成する場合、所有権が移行されたことを示すメール通知が以前のオーナーに送信されます。
ファイルが転送されると、以前のオーナーのロールが writer
に降格します。
バッチ リクエストで複数の権限を変更する
複数の権限を変更する場合は、バッチ リクエストを使用することを強くおすすめします。
次の例は、クライアント ライブラリを使用してバッチ権限変更を実行する方法を示しています。