使用制限

Google Chat API は共有サービスであるため、すべてのユーザーが公平に使用でき、Google Workspace の全体的なパフォーマンスが保護されるように、割り当てと上限が適用されます。

割り当てを超過すると、429: Too many requests HTTP ステータス コード レスポンスが返されます。Chat バックエンドで追加のレート制限チェックを行い、同じエラー レスポンスが生成される場合があります。このエラーが発生した場合は、指数バックオフ アルゴリズムを使用して、しばらくしてからもう一度お試しください。次の表に示す分単位の割り当ての範囲内であれば、1 日に実行できるリクエストの数に制限はありません。

Chat API メソッドには、スペースごととプロジェクトごとの割り当ての 2 つの割り当てタイプが適用されます。

スペースごとの割り当て

スペースごとの割り当てでは、特定のスペースにおけるクエリのレートが制限されます。また、割り当てごとに、リストされている Chat API メソッドを呼び出すすべての Chat アプリで共有されます。

次の表に、スペースごとのクエリ上限の詳細を示します。

スペースごとの割り当て	Chat API メソッド	上限（60 秒あたり、スペース内のすべての Chat アプリで 共有）
1 分あたりの読み取り数	media.download spaces.get spaces.members.get spaces.members.list spaces.messages.get spaces.messages.list spaces.messages.attachments.get spaces.messages.reactions.list	900
1 分あたりの書き込み数	media.upload spaces.delete spaces.patch spaces.messages.create（受信 Webhook にも適用されます） spaces.messages.delete spaces.messages.patch spaces.messages.reactions.create spaces.messages.reactions.delete	60

プロジェクトごとの割り当て

プロジェクトごとの割り当てでは、Google Cloud プロジェクトに対するクエリのレートが制限されます。したがって、割り当てごとに指定された Chat API メソッドを呼び出す単一の Chat アプリに適用されます。

次の表に、プロジェクトごとのクエリの上限の詳細を示します。これらの上限は、[割り当て] ページでも確認できます。

プロジェクトごとの割り当て	Chat API メソッド	上限（60 秒あたり）
1 分あたりのメッセージ書き込み数	spaces.messages.create spaces.messages.patch spaces.messages.delete	3000
1 分あたりのメッセージ読み取り数	spaces.messages.get spaces.messages.list	3000
1 分あたりのメンバーシップの書き込み数	spaces.members.create spaces.members.delete	300
1 分あたりのメンバーシップ読み取り	spaces.members.get spaces.members.list	3000
1 分あたりのスペース書き込み数	spaces.setup spaces.create spaces.patch spaces.delete	60
1 分あたりのスペース読み取り数	spaces.get spaces.list spaces.findDirectMessage	3000
1 分あたりのアタッチメントの書き込み数	media.upload	600
1 分あたりの添付ファイルの読み取り	spaces.messages.attachments.get media.download	3000
1 分あたりのリアクションの書き込み数	spaces.messages.reactions.create spaces.messages.reactions.delete	600
1 分あたりのリアクションの読み取り数	spaces.messages.reactions.list	3000

追加の使用量上限

spaces.create または spaces.setup メソッドを使用して GROUP_CHAT または SPACE タイプのスペースを作成するには、追加の割り当て上限があります。これらのタイプで作成するスペースは 1 分あたり 35 個未満、1 時間あたり 210 個未満です。DIRECT_MESSAGE タイプのスペースには、これらの追加の割り当て上限は適用されません。

同じスペースをターゲットとする API で秒間クエリ数（QPS）が大きいと、[割り当て] ページに表示されない追加の内部上限がトリガーされる可能性があります。

時間ベースの割り当てエラーを解決する

すべての時間ベースのエラー（X 分あたり最大 N 件のリクエスト）については、コードで例外をキャッチして切り捨て型指数バックオフを使用して、デバイスが過剰な負荷を生成しないようにすることをおすすめします。

指数バックオフは、ネットワーク アプリケーション向けの標準的なエラー処理戦略です。指数バックオフ アルゴリズムは、リクエスト間の待機時間を最大バックオフ時間まで、指数関数的に増加させながらリクエストを再試行します。それでもリクエストが失敗する場合は、リクエストが成功するまで、時間の経過とともにリクエスト間の遅延が増加することが重要です。

アルゴリズムの例

指数バックオフのアルゴリズムは、指数関数的にリクエストを再試行し、再試行間の待ち時間が最大バックオフ時間に達するまで増加させます。次に例を示します。

1. Google Chat API にリクエストを送信します。
2. リクエストが失敗した場合、1 + random_number_milliseconds 待ってから、リクエストを再試行します。
3. リクエストが失敗した場合、2 + random_number_milliseconds を待ってから、リクエストを再試行します。
4. リクエストが失敗した場合、4 + random_number_milliseconds を待ってから、リクエストを再試行します。
5. このようにして、最大 maximum_backoff 時間まで繰り返します。
6. 再試行の最大回数まで待機と再試行を続行しますが、再試行間の待機時間は増加させません。

ここで

• 待ち時間は min(((2^n)+random_number_milliseconds), maximum_backoff) で、n は反復（リクエスト）のたびに 1 ずつ増加します。
• random_number_milliseconds は、1,000 ミリ秒以下の乱数です。これにより、状況によって多数のクライアントが同期され、すべてが一度に再試行されて、同期された Wave でリクエストを送信するケースを回避できます。random_number_milliseconds の値は再試行リクエストの後に毎回再計算されます。
• 通常、maximum_backoff は 32 秒または 64 秒です。適切な値はユースケースによって異なります。

クライアントは、maximum_backoff 時間に達した後も再試行を続けることができます。この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントが 64 秒の maximum_backoff 時間を使用する場合、この値に達した後は、クライアントは 64 秒ごとに再試行できます。いずれかの時点で、クライアントが無限に再試行を行わないようにする必要があります。

再試行の間隔と再試行回数は、ユースケースとネットワーク状態によって異なります。

プロジェクトごとの割り当ての増加をリクエストする

プロジェクトのリソース使用量に応じて、割り当ての増加をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用しているとみなされます。割り当ての増加を申請しても、承認が保証されるわけではありません。割り当ての増加が大きい場合は、承認に時間がかかることがあります。

割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が多くなるに伴い、割り当ての増加が必要になる場合があります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの [割り当て] ページから割り当ての調整をリクエストできます。

詳細については、次のリソースをご覧ください。

• 割り当ての増加リクエストについて
• 現在の割り当て使用量と上限を表示する
• 割り当て上限の引き上げをリクエストする