使用制限

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

割り当てを超過すると、429: Too many requests HTTP ステータス コードのレスポンスが返されます。Chat バックエンドでの追加のレート制限チェックでも、同じエラー レスポンスが生成される可能性があります。このエラーが発生した場合は、指数バックオフ アルゴリズムを使用して、後でもう一度お試しください。次の表に示す 1 分あたりの割り当て内であれば、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

その他の使用量上限

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

同じスペースをターゲットとする API トラフィックが多いと、[割り当て] ページに表示されない追加の内部上限がトリガーされることがあります。

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

すべての時間ベースのエラー（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 ミリ秒以下の乱数です。これにより、なんらかの状況によって多数のクライアントが同期され、再試行が一度に実行されて、リクエストが同時に次々と送信されるような状況を避けることができます。random_number_milliseconds の値は再試行リクエストごとに再計算されます。
• 通常、maximum_backoff は 32 秒または 64 秒です。適切な値はユースケースによって異なります。

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

適切な再試行間の待ち時間と再試行回数は、ユースケースとネットワークの状態により異なります。

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

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

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

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

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