本文へ移動
技術を、自社の仕事に。
判断と実行を助けるメディア

記事を検索

Drive APIで承認依頼を自動化 開始・付け替えの条件

目次 · 9項目

見積書や契約書をGoogleドライブに置き、承認機能で上長や経理に回している。ところが、承認依頼は担当者がファイルを1つずつ開いて出し、承認者が休暇に入れば手で差し替え、期限を過ぎた依頼は誰かが気づくまで止まったまま。こうした手作業を、社内ツールや定期処理に任せられないかと考える担当者に向けた記事です。

Drive APIには、承認(Approvals)を操作するメソッドがそろっています。2025年12月17日に一般提供が始まった時点では承認の一覧と取得だけでしたが、2026年4月21日のリリースノートで、承認の開始・承認・差し戻し・承認者の付け替え・取り消し・コメントのメソッドが一般提供として加わりました。この記事では、Googleのリリースノート、ガイド「Manage approvals」、各メソッドのリファレンス、Drive API v3のDiscoveryドキュメント(APIの機械可読な定義。revision 20261012)をもとに、自動化に組み込む前に知っておきたい条件を整理します。

APIで呼べる承認の操作

承認は、ファイルにひも付くリソースとして files/{fileId}/approvals の下に定義されています。メソッドと、リファレンスとガイドに書かれた条件は次のとおりです。

メソッドできること公式に書かれている条件
approvals.start承認を開始する承認者のメールアドレスは必須。期限・メッセージ・ロック・編集時の扱いは任意
approvals.approve / decline承認する/差し戻す呼び出したユーザー自身の回答を更新する。差し戻すと承認全体が DECLINED で終わる
approvals.reassign承認者を追加・交代するファイルの編集者(writer)が、承認が進行中で、対象の承認者が未回答のときに呼べる。承認者を外すことはできない
approvals.cancel承認を取り消す依頼者か編集者が、承認が進行中のあいだに呼べる
approvals.comment承認にコメントする依頼者と承認者の両方に通知され、承認の記録にも残る
approvals.get / list承認の状態を読む読み取り専用のスコープでも呼べる

開始・承認・付け替えなどの書き込み系のメソッドは、drive・drive.file・drive.metadata のいずれかのスコープで呼べると定義されています。ファイルの中身を読む権限まで渡したくない場合も、drive.file(アプリで開いた・作ったファイルに限る)か drive.metadata の範囲で設計できるかを先に検討できます。

書き込み系のメソッドは、Drive APIのリリースノートで2026年4月21日に一般提供(GA)として告知されています。承認の途中でファイルが編集されたときの扱いを決める fileContentChangeBehavior は、少し遅れて2026年7月15日に一般提供になりました。クライアントライブラリでは、Pythonクライアント(google-api-python-client)に同梱されたDiscoveryドキュメントがrevision 20260428から、Node.js向けの @googleapis/drive が5月20日公開の20.2.0から、8つのメソッドに対応しています。

開始する前に確かめること

ガイドでは、承認を開始する前に、ファイルの canStartApproval という権限情報(capability)を files.get で確かめるよう案内しています。次のいずれかに当てはまると false になり、開始できません。

  • 管理者の設定で承認機能が制限されている
  • 利用しているGoogle Workspaceのエディションが対象外
  • ファイルの所有者が自分のドメインの外にいる
  • 呼び出すユーザーが、ファイルの編集者(writer)でない

もう1つ、自動化で抜けやすいのがファイルの共有です。ドライブは承認者にファイルを自動では共有しません。承認者がファイルにアクセスできないままだと、承認の依頼自体は成功しますが、承認者には通知が届かず、ファイルも開けないとガイドに書かれています。承認者のメールアドレスはGoogleアカウントにひも付いている必要があり、そうでないと依頼は失敗します。開始の処理の前に、承認者への共有を済ませる手順を入れておきます。

承認を開始するときに決める項目

approvals.start に渡すのは、次の5項目です。

  • reviewerEmails(必須):承認者のメールアドレスの配列
  • dueTime:期限
  • message:承認者への通知に添えるメッセージ
  • lockFile:開始と同時にファイルをロックするか
  • fileContentChangeBehavior:承認の途中でファイルが編集されたときの扱い

自動化で特に決めておきたいのは最後の項目です。値は2つあり、ガイドとリファレンスでは次のように説明されています。省略したときの既定値は RESET_APPROVAL です。

  • RESET_APPROVAL:承認が進行中にファイルの内容が変わると、承認済みの回答が未回答に戻り、承認者は新しい版を承認し直す。承認が完了(APPROVED)するとファイルはロックされる
  • NO_APPROVAL_ACTION:ファイルの内容が変わっても回答は戻らず、承認が完了してもロックされない。承認者は、完了前なら自分の承認を未回答に戻せる

契約書のように「承認した版」を固定したい文書には RESET_APPROVAL、方向性の合意だけを取りたい企画書には NO_APPROVAL_ACTION、という使い分けになります。画面側で同じ考え方の「アライメント承認」が加わった経緯は、Googleドライブの「アライメント承認」で整理しています。ただし、APIの値と画面の選択肢が完全に同じ挙動かは、編集部では確かめていません。

Drive APIの承認の状態と操作を整理した図。approvals.startで開始すると進行中(IN_PROGRESS)になり、必要な承認者の回答がそろうと承認済み(APPROVED)、1人でもdeclineすると差し戻し(DECLINED)、編集者のcancelで取り消し(CANCELLED)になる。進行中は、編集者が未回答の承認者を追加・交代でき、承認者を外すことはできない

承認者の付け替えと取り消しの条件

承認者が長期休暇に入ったときの付け替えも、自動化の候補になります。approvals.reassign の条件は細かく決まっています。

  • 呼び出せるのは、依頼者かファイルの編集者(writer)
  • 承認が進行中(IN_PROGRESS)で、付け替える承認者が未回答のとき
  • 閲覧者(reader)は、自分に割り当てられた承認だけを付け替えられる
  • 承認者を外すことはできない(追加と交代だけ)

リクエストには、追加する人(addReviewers の addedReviewerEmail)と、交代する人の組(replaceReviewers の removedReviewerEmail と addedReviewerEmail)を指定します。新しい承認者に送るメッセージ(message)も任意で付けられます。「Aさんを外してBさんを入れる」は交代として表現し、「Aさんを外すだけ」はできません。ガイドでは、承認者を外したいときは承認を取り消して開始し直すよう案内しています。すでに承認を済ませた人を差し替えることもできないため、付け替えの処理は、先に approvals.get で各承認者の回答(reviewerResponses)を確かめてから呼ぶ形にします。

取り消し(approvals.cancel)も、進行中の承認に対して依頼者か編集者が呼べます。期限を過ぎた依頼を自動で取り消す仕組みを作る場合、取り消す側のアカウントに編集者の権限が要ります。ファイルの権限の付け方はドライブ共有設定ガイドで整理しています。

一覧を取るときは fields を指定する

承認の状況を一覧にしたい場合は approvals.list を使います。リファレンスには、次の注意書きがあります。

By default, this method returns a minimal response that may not include the items array. To retrieve approval details, you must explicitly specify the fields you want using the fields query parameter.

fields を指定しないと、承認の中身(items)が返らない場合があります。状態・期限・各承認者の回答を取るなら、items(approvalId,status,dueTime,reviewerResponses(reviewer/emailAddress,response)),nextPageToken のように明示します。1回で返るのは、pageSize を省略した場合に最大100件です。ガイドによると、既定の項目が返らないのは list に限らず、approvals のどのメソッドでも同じです。開始や付け替えの応答から approvalId などを使う場合も、fields を指定します。

状態(status)は IN_PROGRESS・APPROVED・CANCELLED・DECLINED の4つ、承認者ごとの回答(response)は NO_RESPONSE・APPROVED・DECLINED の3つです。

リクエストの形をローカルで確かめた

編集部では、Node.js向けの @googleapis/drive 26.0.2の型定義で次のコードを型チェックし、APIの送り先をローカルのスタブ(決まった応答を返す検証用のサーバー)に向けて実行しました。実際のGoogleドライブには接続していません。

import { drive_v3 } from "@googleapis/drive";

export async function requestApproval(
  drive: drive_v3.Drive,
  fileId: string,
  reviewers: string[],
  dueTime: string,
) {
  const { data } = await drive.approvals.start({
    fileId,
    requestBody: {
      reviewerEmails: reviewers,
      dueTime,
      message: "見積書の確認をお願いします",
      fileContentChangeBehavior: "RESET_APPROVAL",
    },
  });
  return data;
}

export async function listApprovals(drive: drive_v3.Drive, fileId: string) {
  const { data } = await drive.approvals.list({
    fileId,
    fields:
      "items(approvalId,status,dueTime,reviewerResponses(reviewer/emailAddress,response)),nextPageToken",
  });
  return data.items ?? [];
}

スタブに届いたリクエストは、POST /drive/v3/files/{fileId}/approvals:start(本文に reviewerEmails・dueTime・message・fileContentChangeBehavior)と、fields を付けた GET /drive/v3/files/{fileId}/approvals でした。型チェック(TypeScript 5.9.3、strict)もエラーなく通っています。なお、上の requestApproval は fields を付けていないため、実際のAPIでは応答に承認の中身が入らない可能性があります。応答を使う場合は fields を加えてください。

自動化に組み込む前に決めること

ここからは編集部の提案です。

  1. 誰の名前で依頼を出すか。 承認の initiator は「承認を依頼したユーザー」と定義されています。共通のアカウントから出すと、承認者の通知に誰の依頼かが表れにくくなります。担当者本人として認証する(ドメイン全体の委任を使う場合を含む)形を基本に考えます。サービスアカウントで開始したときの扱いは確認していません
  2. 編集時の扱いを文書の種類ごとに決める。 RESET_APPROVAL と NO_APPROVAL_ACTION のどちらを使うかを、契約書・見積書・企画書などの種類ごとに決めてからコードに書きます
  3. 付け替えは、回答の状態を見てから。 未回答の人しか付け替えられないため、approvals.get で確かめてから reassign を呼びます
  4. 一覧は fields 付きで取り、期限切れを拾う。 期限(dueTime)を過ぎても IN_PROGRESS の承認を抽出し、依頼者に知らせる処理から始めると、既存の運用を変えずに効果を確かめられます

承認機能の使いどころと、専用のワークフローSaaSとの線引きはGoogleドライブの承認機能で稟議とサインオフを完結させるで整理しています。承認機能を使えるエディションは、導入前にGoogleのヘルプで確認してください。API側では、先に書いた canStartApproval で、対象のファイルで開始できるかを確かめられます。文書内のプルダウンでステータスを選ぶだけの簡易な管理は、誰でも選び直せるため承認の証跡にはなりません。

確認した範囲

2026年10月17日に、Drive API v3のDiscoveryドキュメント(revision 20261012)を取得し、approvals の各メソッド、Approval・StartApprovalRequest・ReassignApprovalRequest などの定義を原文で確認しました。メソッドが加わった時期は、google-api-python-client 2.195.0・2.196.0に同梱された定義(revision 20260405・20260428)と、npmの @googleapis/drive 20.1.0・20.2.0の型定義を比べて確かめました(資料調査)。あわせて、@googleapis/drive 26.0.2でコード例の型チェックと、ローカルのスタブに向けた実行を行いました。2026年10月19日に、Drive APIのリリースノート、ガイド「Manage approvals」、approvals のリファレンス(start・reassign・list ほか)を開き、一般提供の日付、開始の条件、承認者への共有、既定値、fields の扱いを確かめて本文に反映しました。対象エディションの一覧と、実際のGoogleドライブでの承認の動作は確認していません。

承認や稟議をGoogle Workspaceの標準機能とAPIでどこまで回せるか検討している場合は、IT・Google Workspace 無料相談からお問い合わせください。

参考資料

この記事を共有XFacebook
鈴木 翔

技術の可能性に魅了され、学生時代からプログラミングとデジタルアートの分野に深い関心を持つ

この記事のテーマを、自社の次の一歩へ

自社に合う、Workspaceの進め方を。

移行するデータ、共有ルール、管理体制を整理し、導入から日々の運用までの進め方を考えます。

  • 移行と初期設定
  • 共有・権限の整理
  • 管理体制
Workspaceの導入・運用を相談する

構想段階からご相談いただけます。この記事の情報を相談フォームに引き継ぎます。

最新記事をメールで受け取る