すべての 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
リソースのメソッドは、ファイル、フォルダ、共有ドライブ内のファイルに対して機能しますが、共有ドライブ自体には機能しません。
以下の用語は、アクセス提案に固有のものです。
- リクエスト元: Google ドライブのアイテムへのアクセス権の提案を開始したユーザー。
- 受信者: アクセス プロポーザルが承認された場合に、ファイルに対する追加の権限を受け取るユーザー。多くの場合、受信者はリクエスト元と同じですが、必ずしもそうとは限りません。
- 承認者: アクセス プロポーザルの承認(または拒否)を担当するユーザー。これは通常、そのユーザーがドキュメントのオーナーであるか、ドキュメントを共有する権限を持っているためです。
保留中のアクセス プロポーザルを一覧表示する
ドライブ アイテムの保留中のアクセス提案をすべて一覧表示するには、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
に降格します。
バッチ リクエストで複数の権限を変更する
複数の権限を変更する場合は、バッチ リクエストを使用することを強くおすすめします。
次の例は、クライアント ライブラリを使用して一括で権限を変更する方法を示しています。