Google Chat API は共有サービスであるため、すべてのユーザーが公平に使用できるように割り当てと上限を適用し、Google Workspace の全体的なパフォーマンスを保護しています。
割り当てを超えると、429: Too many requests HTTP ステータス コード レスポンスが返されます。Chat
バックエンドに対する追加のレート制限チェックでも、同じエラー レスポンスが生成されることがあります。このエラーが発生した場合は、
指数バックオフ
アルゴリズム
を使用して、後で再試行してください。次の表に記載されている 1 分あたりの割り当て内であれば、1 日に送信できるリクエスト数に制限はありません。
Chat API メソッドには、プロジェクトごと、スペースごと、ユーザーごとの割り当てなど、複数の割り当てタイプが適用される場合があります。
プロジェクトごとの割り当て
プロジェクトごとの割り当ては、Google Cloud プロジェクトのクエリレートを制限します。したがって、指定された Chat API メソッドを呼び出す単一の Chat アプリに、割り当てごとに適用されます。
次の表に、プロジェクトごとのクエリ上限の詳細を示します。これらの上限は、[割り当て] ページでも 確認できます。
プロジェクトごとの割り当て |
Chat API メソッド |
上限(60 秒あたり) |
|---|---|---|
1 分あたりのメッセージ書き込み数 |
|
3000 |
1 分あたりのメッセージ読み取り数 |
|
3000 |
1 分あたりのメンバーシップ書き込み数 |
|
300 |
1 分あたりのメンバーシップ読み取り数 |
|
3000 |
1 分あたりのスペース書き込み数 |
|
60 |
1 分あたりのスペース読み取り数 |
|
3000 |
1 分あたりの添付ファイルの書き込み数 |
|
600 |
1 分あたりの添付ファイルの読み取り数 |
|
3000 |
1 分あたりのリアクション書き込み数 |
|
600 |
1 分あたりのリアクション読み取り数 |
|
3000 |
1 分あたりの CustomEmoji 書き込み数 |
|
600 |
1 分あたりの CustomEmoji 読み取り数 |
|
3000 |
1 分あたりのセクション書き込み数 |
|
600 |
1 分あたりのセクション読み取り数 |
|
3000 |
1 分あたりの可用性の読み取り数 |
|
3000 |
1 分あたりの可用性の書き込み数 |
|
3000 |
スペースごとの割り当て
スペースごとの割り当ては、特定のスペースのクエリレートを制限します。この割り当ては、そのスペースで動作するすべての Chat アプリで共有され、割り当てごとにリストされている Chat API メソッドを呼び出します。
次の表に、スペースごとのクエリ上限の詳細を示します。
スペースごとの割り当て |
Chat API メソッド |
上限(1 秒あたり) |
|---|---|---|
1 秒あたりの読み取り数 |
|
15 |
1 秒あたりの書き込み数 |
|
1 |
1 秒あたりのリアクション作成の書き込み数 |
|
5 |
Google Chat にデータをインポートする際の 1 秒あたりのメッセージ書き込み数 |
|
10 |
ユーザーごとの割り当て
ユーザーごとの割り当ては、Google Chat ユーザーのクエリレートを制限します。クエリは、ユーザーに代わって(ユーザー認証を使用して)Chat API メソッドを呼び出すすべての Chat アプリに関連します。
次の表に、ユーザーごとのクエリ上限の詳細を示します。
ユーザーごとの割り当て |
Chat API メソッド |
上限(1 秒あたり) |
|---|---|---|
1 秒あたりの CustomEmoji 書き込み数 |
|
1 |
1 秒あたりの CustomEmoji 読み取り数 |
|
15 |
1 秒あたりの書き込み数 |
|
1 |
1 秒あたりの読み取り数 |
|
15 |
その他の使用量上限
同じスペースをターゲットとする API トラフィックが多いと、 追加の内部上限がトリガーされる可能性があります。これは [割り当て] ページには表示されません。
時間ベースの割り当てエラーを解決する
時間ベースのエラー(X 分あたり最大 N リクエスト)については、 コードで例外をキャッチし、切り捨てられた指数バックオフを使用して、 デバイスが過剰な負荷を生成しないようにすることをおすすめします。
指数バックオフは、ネットワーク アプリケーションに使われる標準的なエラー処理方法です。 指数バックオフのアルゴリズムは、リクエスト間の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。 リクエストがまだ成功しない場合は、 リクエストが成功するまでリクエスト間の遅延を徐々に増やすことが重要です。
アルゴリズムの例
指数バックオフのアルゴリズムは、再試行の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。次に例を示します。
- Google Chat 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
時間に達した後も再試行を続けることができます。
この時点より後の再試行では、バックオフ時間を増加させ続ける必要はありません。たとえば、クライアントが maximum_backoff 時間として 64 秒を使用している場合、この値に達すると、クライアントは 64 秒ごとに再試行できます。ある時点で、
クライアントが無期限に再試行しないようにする必要があります。
適切な再試行間の待ち時間と再試行回数は、ユースケース とネットワークの状態により異なります。
プロジェクトごとの割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当ての調整をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用しているとみなされます。割り当ての調整を申請しても、必ずしも承認されるとは限りません。割り当て値を大幅に増やす割り当て調整リクエストは、承認に時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が増えるにつれて、割り当て値を増やす必要が生じる場合があります。使用量の大幅な増加が見込まれる場合は、事前に [割り当て量の調整] を Google Cloud コンソールの [割り当てとシステム上限] ページからリクエストできます。
詳細については、次のリソースをご覧ください。
Chat MCP サーバーの割り当て
Chat MCP サーバーは、クエリ費用の割り当て指標を使用します。次の表に、Chat MCP サーバーのメソッドごとのクエリ費用をセクション別に示します。
Chat MCP の割り当て
次の 2 種類の割り当てが適用されます。
プロジェクトごとに 1 分あたり: これは、1 分間の Google Cloud プロジェクトのクエリ費用です。
プロジェクトごとに 1 分あたり、ユーザーごとに: これは、特定のユーザーが使用できる 1 分間の Google Cloud プロジェクトのクエリ費用です。この上限は、ユーザー間で使用量を公平に分配できるようにすることを目的としています。
次の表に、これらの割り当ての詳細を示します。
| 使用量上限のタイプ | クエリ費用 |
|---|---|
| プロジェクトごとに 1 分あたり | 3,000 |
| プロジェクトごとに 1 分あたり、ユーザーごとに | 300 |
Chat MCP ツールセット
次の表に、chatmcp.googleapis.com ツールセットごとのクエリ費用を示します。
エンドポイント |
ツール |
クエリ費用 |
|---|---|---|
/mcp/v1 |
|
1 |
|
10 |
|
|
10 |
|
|
10 |
詳細については、Chat MCP API リファレンスをご覧ください。