使用制限
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
Google Sheets API は共有サービスであるため、割り当てと制限が適用されます。
すべてのユーザーが公平に使用できるようにし、
Google Workspace システムの健全性を確認できます。
割り当てを超えた場合、通常は
429: Too many requests
HTTP ステータス コード レスポンス。そのような場合は、
指数バックオフ アルゴリズムを使用して、再試行する
後で説明します以下の 1 分あたりの割り当ての範囲内であれば、
1 日あたりのリクエスト数に上限が設けられています。
次の表に、リクエストの上限を示します。
| 割り当て |
| 読み取りリクエスト |
| 1 プロジェクト、1 分あたり |
3000 |
| 1 プロジェクト、1 ユーザー、1 分あたり |
600 |
|
|
コストの高い読み取りリクエスト
（presentations.pages.getThumbnail リクエストに使用されます）
|
| 1 プロジェクト、1 分あたり |
300 |
| 1 プロジェクト、1 ユーザー、1 分あたり |
60 |
|
| 書き込みリクエスト |
| 1 プロジェクト、1 分あたり |
600 |
| 1 プロジェクト、1 ユーザー、1 分あたり |
60 |
|
時間ベースの割り当てエラーを解決する
すべての時間ベースのエラー（X 分あたり最大 N 個のリクエスト）に対しては、
例外をキャッチし、切り捨て型指数バックオフを使用して、
デバイスに過度の負荷が発生しないようにすることができます。
指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法です。「
指数バックオフ アルゴリズムにより、待機時間が指数関数的に増加してリクエストを再試行
最大バックオフ時間まで再試行可能です。それでもリクエストが失敗する場合は、
リクエストが成功するまで、リクエスト間の遅延が時間の経過とともに増加することに注意してください。
アルゴリズムの例
指数バックオフ アルゴリズムはリクエストを指数関数的に再試行するため、待ち時間が長くなる
最大バックオフ時間内に再試行します。例:
- Google Sheets API にリクエストを送信します。
- リクエストが失敗した場合、1 +
random_number_milliseconds 待ってから再試行する
表示されます。
- リクエストが失敗した場合は、2 +
random_number_milliseconds 待ってから再試行する
表示されます。
- リクエストが失敗した場合は、4 +
random_number_milliseconds 待ってから再試行する
表示されます。
- このようにして、最大
maximum_backoff 時間まで繰り返します。
- 再試行の最大回数まで待機と再試行を続けるが、待機は増加しない
間隔を空けておけます
ここで
- 待ち時間は
min(((2^n)+random_number_milliseconds), maximum_backoff)です。
n は、反復（リクエスト）のたびに 1 ずつ増加します。
random_number_milliseconds は、ミリ秒以下の乱数です。
1,000 になります。これにより、複数のクライアントが同期される事態を回避でき、
同時に再試行して、リクエストを同期された状態で送信し、
あります。random_number_milliseconds の値は、
リクエストを再試行します。- 通常、
maximum_backoff は 32 秒または 64 秒です。適切な値
ユースケースによって異なります
クライアントは、maximum_backoff 時間に達した後も再試行を続行できます。
この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。対象
たとえば、クライアントが 64 秒の maximum_backoff 時間を使用している場合、
この値を指定すると、クライアントは 64 秒ごとに再試行できます。ある時点で
無期限に再試行しないようにする必要があります。
再試行までの待ち時間と再試行回数はユースケースによって異なる
ネットワーク状態を確認できます。
料金
Google スライド API はすべて追加料金なしでご利用いただけます。割り当ての超過
リクエストの上限によって追加料金は発生せず、アカウントへの請求は行われません。
割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当てをリクエストする必要があります。
増加します。サービス アカウントによる API 呼び出しは、
できます。割り当ての増加を申請しても、承認が保証されるわけではありません。大
割り当ての増加が承認されるまで時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。ますます Google Cloud を使用する傾向にあるため、
割り当ての増加が必要になる場合があります今後のイベントで
使用量が増加した場合は、事前に
割り当ての調整をリクエストする
[割り当て] ページで
確認できます。
詳細については、次のリソースをご覧ください。
特に記載のない限り、このページのコンテンツはクリエイティブ・コモンズの表示 4.0 ライセンスにより使用許諾されます。コードサンプルは Apache 2.0 ライセンスにより使用許諾されます。詳しくは、Google Developers サイトのポリシーをご覧ください。Java は Oracle および関連会社の登録商標です。
最終更新日 2025-03-21 UTC。
[null,null,["最終更新日 2025-03-21 UTC。"],[],[],null,["# Usage limits\n\nAs the Google Slides API is a shared service, we apply quotas and limitations\nto make sure it's used fairly by all users and to protect the overall\nhealth of the Google Workspace system.\n\n\nIf you exceed a quota, you'll generally receive a\n`429: Too many requests`\nHTTP status code response. If this happens, you should use an\n[exponential backoff algorithm](#exponential) and try again\nlater. Provided you stay within the per-minute quotas below, there's no\nlimit to the number of requests you can make per day.\n\nThe following table details the request limits:\n\n| Quotas ||\n|---------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------|\n| Read requests | |---------------------------------|------| | Per minute per project | 3000 | | Per minute per user per project | 600 | |\n| Expensive read requests (Used for `presentations.pages.getThumbnail` requests.) | |---------------------------------|-----| | Per minute per project | 300 | | Per minute per user per project | 60 | |\n| Write requests | |---------------------------------|-----| | Per minute per project | 600 | | Per minute per user per project | 60 | |\n\nResolve time-based quota errors\n-------------------------------\n\n\nFor all time-based errors (maximum of N requests per X minutes), we recommend\nyour code catches the exception and uses a *truncated exponential backoff* to make sure your\ndevices don't generate excessive load.\n\n\nExponential backoff is a standard error handling strategy for network applications. An\nexponential backoff algorithm retries requests using exponentially increasing wait times\nbetween requests, up to a maximum backoff time. If requests are still unsuccessful, it's\nimportant that the delays between requests increase over time until the request is successful.\n\n### Example algorithm\n\n\nAn exponential backoff algorithm retries requests exponentially, increasing the wait time\nbetween retries up to a maximum backoff time. For example:\n\n1. Make a request to Google Slides API.\n2. If the request fails, wait 1 + `random_number_milliseconds` and retry the request.\n3. If the request fails, wait 2 + `random_number_milliseconds` and retry the request.\n4. If the request fails, wait 4 + `random_number_milliseconds` and retry the request.\n5. And so on, up to a `maximum_backoff` time.\n6. Continue waiting and retrying up to some maximum number of retries, but don't increase the wait period between retries.\n\n\nwhere:\n\n- The wait time is `min(((2^n)+random_number_milliseconds), maximum_backoff)`, with `n` incremented by 1 for each iteration (request).\n- `random_number_milliseconds` is a random number of milliseconds less than or equal to 1,000. This helps to avoid cases in which many clients are synchronized by some situation and all retry at once, sending requests in synchronized waves. The value of `random_number_milliseconds` is recalculated after each retry request.\n- `maximum_backoff` is typically 32 or 64 seconds. The appropriate value depends on the use case.\n\n\nThe client can continue retrying after it has reached the `maximum_backoff` time.\nRetries after this point don't need to continue increasing backoff time. For\nexample, if a client uses a `maximum_backoff` time of 64 seconds, then after reaching\nthis value, the client can retry every 64 seconds. At some point,\nclients should be prevented from retrying indefinitely.\n\n\nThe wait time between retries and the number of retries depend on your use case\nand network conditions.\n\nPricing\n-------\n\n\nAll use of the Google Slides API is available at no additional cost. Exceeding the quota\nrequest limits doesn't incur extra charges and your account is not billed.\n\nRequest a quota increase\n------------------------\n\n\nDepending on your project's resource usage, you might want to request a quota\nadjustment. API calls by a service account are considered to be using a\nsingle account. Applying for an adjusted quota doesn't guarantee approval. Quota adjustment\nrequests that would significantly increase the quota value can take longer to be approved.\n\n\nNot all projects have the same quotas. As you increasingly use Google Cloud over\ntime, your quota values might need to increase. If you expect a notable upcoming\nincrease in usage, you can proactively\n[request quota adjustments](https://cloud.google.com/docs/quota#requesting_higher_quota)\nfrom the [Quotas page](https://console.cloud.google.com/iam-admin/quotas)\nin the Google Cloud console.\n\nTo learn more, see the following resources:\n\n- [About quota adjustments](https://cloud.google.com/docs/quotas/overview#about_increase_requests)\n- [View your current quota usage and limits](https://cloud.google.com/docs/quota#viewing_your_quota_console)\n- [Request a higher quota limit](https://cloud.google.com/docs/quota#requesting_higher_quota)"]]
