「先月まで問題なく回っていた夜間バッチが、今週から途中で止まるようになった」という相談は、処理内容もデータ量も変えていないときほど原因が見えません。ログには 403 が並び、少し時間を置いて再実行すると成功する。負荷が増えたわけでもない。
こういうとき、疑うべきは上限の値ではなく上限の数え方です。 Google ドライブと連携する自作ツールやバックアップ処理では、2026年にその数え方自体が切り替わりました。同じ処理でも、どのプロジェクトで動いているかによって当たる天井が違います。
リクエスト数ではなく「重み」で数えるようになった
これまで Drive API の上限は、リクエストの本数で決まっていました。100秒あたり何回まで、という素直な数え方です。この方式では、1KB のファイル情報を取得するのも 500MB のファイルを落とすのも、同じ「1回」でした。
新しいモデルでは、リクエストの種類ごとに重みが付きます。公開されている単価は次のとおりです。
| 操作の種類 | 消費するクォータ単位 |
|---|---|
| 基本的な読み取り | 5 |
| 編集 | 50 |
| 一覧の取得（list） | 100 |
| ダウンロード | 200 |
ダウンロードは基本的な読み取りの40倍、一覧取得は20倍を消費します。 ここが実務上いちばん効きます。ファイルを列挙して片端から落とす処理は、まさにこの2種類だけで構成されているためです。
上限は、プロジェクト単位で毎分100万単位、ユーザー単位で毎分32万5,000単位。日次では4億単位が目安として示されています。
素朴に計算すると、ダウンロードだけを続けた場合はプロジェクト全体で毎分5,000ファイル、1ユーザーの権限で回すなら毎分1,625ファイルで頭を打ちます。「毎分数千回まで大丈夫だった」という感覚は、ダウンロード主体の処理ではもう成り立ちません。
自分の環境がどちらのモデルか
厄介なのは、この切り替えが一斉には起きていない点です。
適用されているのは、2026年5月1日以降に新しく作られた Google Cloud プロジェクトです。それ以前から Drive API を使っていたプロジェクトは、当面は従来のリクエスト数ベースの上限のまま動きます。順次の移行は2026年内に進む見込みとされています。
この非対称性が、切り分けを難しくします。よくある詰まり方は次の形です。
- 本番は数年前からのプロジェクトで動いており、従来モデルのまま安定している
- 検証用に新しくプロジェクトを切ったところ、同じコードなのに検証側だけ落ちる
- コードもデータも同じなので、環境差ではなくコードのバグを疑って時間を溶かす
まず確認すべきは、そのツールが使っている Google Cloud プロジェクトの作成時期です。 5月以降に作ったものなら、数え方が違う前提で読み直す必要があります。
1日1TBという、別方向の天井
もうひとつ、単位の話とは別に効いてくる制限があります。プロジェクトあたりの日次エグレス（外向きのデータ転送量）が 1TB という上限です。
回数の制限とは性質が違います。単位のほうは「速すぎる」ことへの制限なので、間隔を空ければ回避できます。エグレスは総量なので、ゆっくり回しても同じ日に 1TB を超えれば当たります。 待機を挟む実装では回避できません。
これが直撃しやすいのは次のような処理です。
- Drive 全体を別ストレージへ複製する、全量バックアップ
- 他サービスへの移行時に一括で吸い出す、初回同期
- 動画や設計データなど、1ファイルが大きい業務での定期同期
いずれも「一度きり、または低頻度だが、1回の総量が大きい」処理です。開発中は小さなフォルダで検証し、本番の全社データで初めて当たる、という順序になりがちなところも共通しています。
総量が読める処理では、着手前に対象データの合計サイズを出しておくのが確実です。 1TB を超えるなら、日をまたぐ分割を最初から設計に入れます。走らせてから止まると、どこまで転送済みかの突合から始めることになります。
連携ツールを持っている会社が、いま見ておくこと
Google ドライブと外部を繋ぐ仕組みは、規模の大小にかかわらず社内に何かしら存在します。Apps Script で書いた集計、業務システムからの添付ファイル保存、退職者データの引き上げ、SaaS 経由の自動バックアップ。
その全部を今すぐ点検する必要はありませんが、次の2点は棚卸ししておく価値があります。
一覧取得とダウンロードを繰り返す処理があるか。 重みが大きい2種類です。ファイル数が増えるほど、処理時間ではなく上限のほうに先に当たります。
その処理が、誰の権限とどのプロジェクトで動いているか。 ユーザー単位の上限は権限の持ち主ごとに数えます。1つのサービスアカウントに全部の連携処理を集約していると、個々は小さくても合算で上限に届きます。
外部ベンダーに作ってもらったツールなら、エラー時に何回・どの間隔で再試行する実装になっているかを聞いておくと、後々の切り分けが早くなります。 上限に当たった 403 は、間隔を空けた再試行で成功する性質のエラーです。即座に再試行を繰り返す実装だと、上限をさらに消費して復旧を遅らせます。
Apps Script 側の制限とも重なる話なので、実行時間で詰まった経験がある場合はApps Scriptが6分で止まるときの分かれ目も合わせて読むと、どちらの天井に当たっているかを見分けやすくなります。連携先の通信の棚卸しについてはGASの外部通信をURL許可リストで洗い出す話で扱っています。
次にやること
社内で Google ドライブに API 経由でアクセスしている処理を1つ選び、それが使っている Google Cloud プロジェクトの作成日を確認してください。 5月以降なら、ダウンロードと一覧取得の回数を1分あたりで概算します。
全量移行や全社バックアップを計画中であれば、対象データの合計サイズを先に出してください。 1TB を超えるなら、実行日を分ける設計に切り替えるだけで、途中停止からの復旧作業を丸ごと避けられます。
Google Workspace と業務システムの連携、Drive を使った自動化の設計・見直しについては、グリームハブの IT・Google Workspace 無料相談で承っています。お問い合わせからご相談ください。
