上限と割り当ては、Reports API を不適切な方法で使用する自動プロセスから Google のインフラストラクチャを保護します。API からの過剰なリクエストは、無害な入力ミスが原因である場合もあれば、不必要な API 呼び出しを行う非効率的な設計のシステムが原因である場合もあります。こうした原因とは無関係に、Google Workspace システムの全体的な正常性を維持するには、特定のソースからのトラフィックが一定のレベルに達した場合にトラフィックをブロックする必要があります。つまり、あるデベロッパーの操作によってコミュニティに悪影響が及ぶ事態を防ぎます。
API リクエストが失敗した場合は、HTTP ステータス コード レスポンスが返されます。ステータス コード 403 には、入力が正しくないというエラー情報が含まれています。ステータス コード 503 には、どの API 割り当てが超過したかを示すエラー情報が含まれています。これらのレスポンスにより、カスタム アプリケーションはこれらのエラーを検出し、適切なアクションを実行できます。
リクエストを一定期間内に完了する必要がある場合は、リクエストを並行して送信するか、Java または C# アプリケーションで複数のスレッドを使用します。並列リクエストの例としては、1 人のユーザーから大量のメールを同時に追加または削除するのではなく、複数のユーザーから少量のメールをリクエストすることが挙げられます。スレッドの場合は、ユーザーのメールアドレスごとに 1 つのスレッドを使用して、10 個のスレッドから始めてみてください。なお、スレッドの推奨事項にはトレードオフがあり、すべての API の状況で有用とは限りません。リクエストの数が多すぎると、割り当てエラーが発生します。
時間ベースのエラー（スレッドあたり N 秒で最大 N 個）すべて、特に 503 ステータス コード エラーについては、コードで例外をキャッチし、指数バックオフ アルゴリズムを使用して、失敗した呼び出しを再試行する前に少し待機することをおすすめします。1 つのスレッドの Reports API の例では、5 秒待ってから失敗した呼び出しを再試行します。リクエストが成功したら、他のスレッドについてもこのパターンを繰り返します。2 回目のリクエストが成功しなかった場合、呼び出しが成功するまで、リクエストの頻度を減らす必要があります。たとえば、最初の 5 秒の遅延を 10 秒に増やして、失敗した呼び出しを再試行します。また、再試行の制限も決定します。たとえば、アプリケーションがユーザーにエラーを返す前に、異なる遅延時間でリクエストを 5 ～ 7 回再試行します。
上限
| API の上限カテゴリ | 上限 |
|---|---|
| QPS と QPD のレートを報告する | API は、Google Cloud プロジェクトのリクエスト数を制限します。Google Cloud コンソールで設定されるデフォルト値は、ユーザーごと、Google Cloud プロジェクトごとに 1 分あたり 2,400 件のクエリです。この上限は、Google Cloud プロジェクトの Admin SDK API の割り当てページで引き上げることができます。 これらの上限を超えると、サーバーは HTTP 503 ステータス コードを返します。リクエストを再試行する際は、指数バックオフ アルゴリズムを使用します。 |
activities.list の追加の制限 |
activities.list API には、1 分あたり 250 件のフィルタ クエリ（1 時間あたり 15,000 件のフィルタ クエリ）という追加の制限があります。フィルタ クエリは、次のクエリ パラメータのいずれかを 1 つ以上含む API リクエストです。
|
| API 割り当てカテゴリ | 割り当て |
| maxResults | API のレスポンスの各ページに表示されるレコード数は 0 ～ 1,000 件です。デフォルトは 1,000 件のレコードです。 |
その他の種類の制限
| その他の種類の制限 | 制限事項とガイドライン |
|---|---|
| データ形式、デフォルト | デフォルトのデータ形式は JSON です。API は Atom 形式もサポートしています。 |
| 承認されていないリクエスト | Google は、API への不正なリクエストを許可していません。認証トークンが提供されていない場合、リクエストは未承認とみなされます。詳細については、リクエストの承認をご覧ください。 |
| 警告メッセージ |
|
activities.list のベスト プラクティス
activities.list メソッドは、監査調査に使用されることが想定されています。パフォーマンスを最大限に高めるには、startTime パラメータと endTime パラメータを使用して、リクエストに期間を含める必要があります。時間範囲を狭めると、応答時間が大幅に短縮されます。この方法は、監査ログを大量に取得するためのものではありません。activities.list フィルタ リクエストの割り当てが常に不足している場合は、次のオプションを検討してください。
- Google Workspace ログの BigQuery へのエクスポートを設定し、BigQuery の強力なクエリ API を使用して、API 割り当ての制約なしで必要なデータを取得して分析します。
- フィルタ リクエストを使用する代わりに、期間を指定してフィルタなしのリクエストを使用し、クライアントサイドのフィルタリング（アプリケーションでフィルタリング ロジックを実行）を行います。これにより、1 分あたり 250 件のフィルタ クエリの上限を超えることができますが、Google Cloud プロジェクトごとにユーザー 1 人あたり 1 分あたり 2,400 件のクエリの上限は引き続き適用されます。