Google カレンダー API には、すべてのユーザーが公平に使用できるように割り当てが設定されています。Calendar API を使用する際には、次の 3 つの重要な制限事項を考慮する必要があります。
API 使用量の割り当て: プロジェクトごと、ユーザーごとに適用されます。詳細については、Calendar API の使用量割り当ての種類をご覧ください。
Google カレンダーの一般的な使用量上限: Google Calendar API は、Google Workspace システムの全体的なパフォーマンスを保護するために制限が設けられている共有サービスです。詳細については、カレンダーの使用制限を回避するをご覧ください。
オペレーションの上限: これらの上限は、いつでも制限される可能性があります。たとえば、1 つのカレンダーに短時間で連続して書き込もうとした場合などです。
Calendar API の割り当て
適用される割り当てには次の 2 種類があります。
1 分あたり、1 プロジェクトあたり: Google Cloud プロジェクトが 1 分間に作成できるリクエストの数です。
1 分、1 ユーザー、1 プロジェクトあたり: これは、特定のユーザーが Cloud プロジェクトで行うことができるリクエストの数です。この上限は、ユーザー間で利用量を公平に分配できるようにすることを目的としています。
割り当ては、スライディング ウィンドウを使用して 1 分ごとに計算されます。1 分間に分単位の割り当てを超えるトラフィックが急増すると、次のウィンドウでレート制限が適用され、平均して使用量が割り当て内に収まるようになります。
次の表に、これらの上限の詳細を示します。
| 使用量上限の種類 | 上限 |
|---|---|
| 1 プロジェクト、1 分あたり | 10,000 件のリクエスト |
| 1 分、1 ユーザー、1 プロジェクトあたり | 600 リクエスト |
1 日の最低配信数
このプロジェクトごとの 1 日あたりの上限は、Google Cloud プロジェクトで 24 時間以内に使用できるリクエストの最大数を定義します。この上限を超えると、料金が適用されます。
このしきい値未満の使用量に対して追加料金は発生せず、Google Cloud アカウントに請求されることもありません。請求に関する詳細情報は、2026 年後半に、変更が有効になる 90 日以上前にお知らせします。
この 1 日あたりのしきい値の上限の引き上げをリクエストすることはできません。
次の表に、上限の詳細を示します。
| しきい値の上限タイプ | 上限 |
|---|---|
| 1 日あたり、プロジェクトごと | 1,000,000 件のリクエスト |
詳細については、エージェント ツールと API の Google Workspace 標準モデルをご覧ください。
時間ベースの割り当てエラーを解決する
時間ベースのエラー（X 分あたり最大 N 件のリクエスト）については、コードで例外をキャッチし、指数バックオフを使用してデバイスが過剰な負荷を生成しないようにすることをおすすめします。
指数バックオフは、ネットワーク アプリケーションの標準的なエラー処理方法です。指数バックオフのアルゴリズムは、リクエスト間の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。それでもリクエストが失敗する場合は、リクエストが成功するまで、リクエスト間の遅延を徐々に長くすることが重要です。
アルゴリズムの例
指数バックオフのアルゴリズムは、再試行の待ち時間の間隔を最大バックオフ時間まで増加させながら、指数関数的にリクエストを再試行します。次に例を示します。
- Google カレンダー 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 秒ごとに再試行できます。いずれかの時点で、クライアントが無限に再試行を行わないようにする必要があります。
適切な再試行間の待ち時間と再試行回数は、ユースケースとネットワークの状態により異なります。
料金
Google Calendar API の標準的な使用はすべて、追加料金なしでご利用いただけます。割り当てリクエストの上限を超えると、2026 年後半に Google Cloud 請求先アカウントに料金が発生する予定です。詳細については、エージェント ツールと API の Google Workspace 標準化モデルをご覧ください。
割り当ての増加をリクエストする
プロジェクトのリソース使用量に応じて、割り当ての調整をリクエストできます。サービス アカウントによる API 呼び出しは、単一のアカウントを使用していると見なされます。割り当ての調整を申請しても、必ずしも承認されるとは限りません。割り当て値を大幅に増やす割り当て調整リクエストは、承認に時間がかかることがあります。
割り当て量はすべてのプロジェクトで同じとは限りません。Google Cloud の使用量が多くなるに伴い、割り当て値を増やすことが必要になる場合があります。使用量の大幅な増加が見込まれる場合は、事前に Google Cloud コンソールの [割り当てとシステム上限] ページから割り当ての調整をリクエストできます。
詳細については、次のリソースをご覧ください。
トラブルシューティング
いずれかの割り当てを超えると、レート制限が適用され、クエリに対するレスポンスとして 403
usageLimits ステータス コードまたは 429
usageLimits ステータス コードが返されます。
この場合は、次のことを試してください。
指数バックオフの使用、トラフィック パターンのランダム化、プッシュ通知の使用など、すべてのベスト プラクティスを実践してください。
プロジェクトが拡大し、ユーザーが増えた場合は、割り当ての増加をリクエストできます。
ユーザーごとの割り当て上限に達した場合は、次のことができます。
サービス アカウントを使用する場合は、ユーザーに負荷を割り当てるか、複数のサービス アカウントに分割します。
ユーザーあたりの割り当ての増加をリクエストすることはできますが、一般的には、デフォルト値を超えて増加させることはおすすめしません。アプリケーションが他の種類の上限（一般的なカレンダーの使用量上限やオペレーションの上限など）に達する可能性があるためです。
割り当て上限をテストするには、本番環境プロジェクトと同様の構成を持つテスト専用プロジェクトを別途登録します。詳細については、割り当て上限の処理をテストするをご覧ください。
トラフィック パターンをランダム化する
カレンダー クライアントは、複数のクライアントが同時にオペレーションを実行するため、トラフィック パターンが急増する傾向があります。たとえば、カレンダー クライアントの一般的な不適切なプラクティスは、深夜に完全同期を実行することです。これにより、1 分あたりの割り当てを超過し、レート制限とバックオフが発生する可能性が高くなります。
これを回避するには、可能な限りトラフィックを 1 日全体に分散させてください。クライアントが毎日同期する必要がある場合は、クライアントにランダムな時間（クライアントごとに異なる時間）を決定させます。定期的にオペレーションを実行する必要がある場合は、間隔を +/- 25% 変更します。これにより、トラフィックがより均等に分散され、ユーザー エクスペリエンスが大幅に向上します。
プッシュ通知を使用する
一般的なユースケースは、ユーザーのカレンダーで何かが変更されるたびにアクションを実行することです。ここでのアンチパターンは、対象となるすべてのカレンダーを繰り返しポーリングすることです。これにより、割り当てがすぐに使い果たされます。たとえば、アプリケーションに 5,000 人のユーザーがいて、各ユーザーのカレンダーを 1 分に 1 回ポーリングする場合、作業が完了する前でも、1 分あたり 5,000 件以上の割り当てが必要です。
サーバーサイド アプリケーションは、プッシュ通知に登録できます。これにより、関心のあるイベントが発生したときに通知を受け取ることができます。設定に手間がかかりますが、割り当てを大幅に効率化し、ユーザー エクスペリエンスを向上させることができます。通知を受け取る eventType を指定してください。詳細については、プッシュ通知をご覧ください。
サービス アカウントによる適切な割り当て
アプリケーションがドメイン全体の委任を使用してリクエストを実行している場合、デフォルトでは、権限を借用しているユーザーではなく、サービス アカウントが「プロジェクトごと、ユーザーごと、1 分あたり」の割り当てに対して課金されます。つまり、サービス アカウントが複数のユーザーのカレンダーを操作している場合でも、割り当てが不足してレート制限が適用される可能性があります。
これを回避するには、quotaUser URL パラメータ（または x-goog-quota-user HTTP ヘッダー）を使用して、各ユーザーを一意に識別する任意の文字列（最大 40 文字）を指定します。Calendar API は、この値を割り当ての計算にのみ使用します。
quotaUser を使用して、異なるユーザーにユーザーごとのレート制限を適用するには、リクエストが次の要件を満たしている必要があります。
IP 制限付き API キーを含める:
keyクエリ パラメータで API キーを渡し、バックエンド サーバーのパブリック IP アドレスを指定する IP アドレス制限を使用してそのキーを構成します。API キーを省略するか、IP アドレス制限を構成しない場合、Calendar API はquotaUserを無視し、認証済みアカウント（サービス アカウントなど）に割り当てを課金します。X-Goog-User-Projectヘッダーを省略する:quotaUserを使用するリクエストでX-Goog-User-ProjectHTTP ヘッダーを送信しないでください。ユーザー プロジェクトを指定すると、割り当ての帰属に関する API キーがオーバーライドされるため、Calendar API はquotaUserを無視します。
詳細については、ユーザーあたりのリクエスト数の制限をご覧ください。
割り当て上限の処理をテストする
アプリケーションが実際に割り当て上限に達した場合に適切に処理できるように（たとえば、指数バックオフによる再試行など）、また、ユーザーへの潜在的な影響を最小限に抑えるために、実際の環境でシナリオをテストすることを強くおすすめします。
実際のアプリケーションの使用に影響を与えずにテストするには、Google Cloud コンソールでテスト専用のプロジェクトを登録し、本番環境プロジェクトと同様に OAuth 同意画面を構成することをおすすめします。このプロジェクトに人為的に低い割り当て上限を設定し、アプリケーションの動作を観察できます。
カレンダー MCP サーバーの割り当て
カレンダー MCP サーバーは、クエリ費用割り当て指標を使用します。次の表に、Calendar MCP サーバーの各メソッドのクエリ費用をセクションごとに示します。
カレンダー MCP の割り当て
適用される割り当てには次の 2 種類があります。
プロジェクトごとに 1 分あたり: これは、Google Cloud プロジェクトの 1 分あたりのクエリ費用です。
1 分、1 ユーザー、1 プロジェクトあたり: これは、特定のユーザーが 1 分間に使用できる Google Cloud プロジェクトのクエリ費用です。
次の表に、これらの割り当ての詳細を示します。
| 使用量上限の種類 | クエリの費用 |
|---|---|
| 1 プロジェクト、1 分あたり | 10,000 |
| 1 分、1 ユーザー、1 プロジェクトあたり | 600 |
カレンダー MCP ツールセットの割り当て
次の表に、各 calendarmcp.googleapis.com ツールセットのクエリ費用を示します。
| エンドポイント | ツール | クエリの費用 |
|---|---|---|
/mcp/v1 |
|
1 |
|
10 |
|
|
1 |
|
|
1 |
|
|
1 |
|
|
1 |
|
|
1 |
|
|
1 |
|
|
1 |
詳細については、Calendar MCP API リファレンスをご覧ください。