AIゲートウェイにおけるレートリミット：完全ガイド

大規模言語モデル（LLM）は強力な機能を提供しますが、同時に高い インフラコスト、予測不可能な使用パターン、悪用の可能性といった課題も生じます。企業がLLMを顧客向けツール、社内コパイロット、APIプラットフォームに統合するにつれて、制御された信頼性の高いアクセスへのニーズが不可欠になります。ここでレート制限が重要な役割を果たします。

LLM推論の文脈では、従来の1秒あたりのリクエスト数（RPS）によるレート制限では不十分です。LLMはリソースを大量に消費し、トークンベースであり、計算負荷が非常に変動しやすいという特性があります。700億パラメータモデルへの単一のプロンプトで数千のトークンを消費し、GPUのレイテンシに大きな影響を与える可能性があります。適切な制御がなければ、共有インフラはすぐに不安定になったり、コストがかかりすぎたりする可能性があります。

本記事では、 AIゲートウェイにおけるレート制限の仕組み、それがスケーラブルなAIインフラにとってなぜ不可欠なのか、そしてTrueFoundryがマルチテナントデプロイメント全体で公平な利用、コスト効率、本番環境レベルのパフォーマンスを確保するために、どのようにデフォルトでそれを有効にしているのかを解説します。

‍

レート制限とは何か、そしてAIゲートウェイにとってなぜ不可欠なのか

レート制限とは、クライアントが特定の時間枠内でシステムに送信できるリクエストの数を制御するために使用されるメカニズムであり、現代の AIゲートウェイ がLLMトラフィックを管理する上での主要な機能です。特にマルチユーザー環境において、公平性を確保し、過負荷を防ぎ、可用性を維持します。従来のAPIは、ユーザーあたり1分間に100リクエストといった単純な制限を適用することが多く、これは標準的なRESTサービスにはうまく機能します。

しかし、LLMの動作は大きく異なります。各リクエストは、入力サイズ、モデルタイプ、および期待される出力に基づいて、インフラに劇的に異なる負荷をかける可能性があります。例えば、7Bモデルへの20トークンのプロンプトはすぐに完了するかもしれませんが、65Bモデルへの2000トークンのリクエストは、GPUを数秒間ブロックする可能性があります。異なるモデルへの2つの同一のリクエストでさえ、計算コストが5倍以上異なることがあります。

このため、リクエストベースの制限では不十分です。現代のLLMゲートウェイは、実際に処理されたトークンの数と呼び出しあたりの計算負荷を考慮する、トークンを考慮したレート制限を採用する必要があります。

トークンを考慮したレート制限で考慮される主な要因は次のとおりです。

• 処理された合計トークン数（入力 + 出力）
• モデルのサイズとアーキテクチャ
• リクエストの種類（チャット、埋め込み、またはRAG）
  

固定リクエスト制限と比較して、トークン認識型制限は：

• さまざまなワークロードに対してより公平な適用を実現します
• 正確なコスト追跡と請求を可能にします
• ノイジーなユーザーや悪意のあるユーザーからシステムを保護します
  

生成AIワークフローでは、レート制限はさらに重要になります。1人のユーザーが長文プロンプト、ドキュメント取り込み、または多段階エージェントを介して大規模なバックエンド処理をトリガーする可能性があります。制御がないと、これはGPUの輻輳、高遅延、または予期せぬコストにつながる可能性があります。

実際の使用状況は、フロントエンドアプリ、テストループ、または自動化によって予測不能なことが多いです。レート制限は、インフラがユーザーやテナント間で共有されている場合でも、これらのインタラクションが安定して効率的であることを保証します。

あらゆる本番環境でのデプロイメントにおいて、 最高のLLMゲートウェイ は、スケーラビリティ、信頼性、およびコスト管理のための基本的な要件として、インテリジェントなレート制限を提供する必要があります。 

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

80+ Essential Criteria for AI Gateway Selection

A practical guide used by platform & infra teams

プラットフォームがレート制限を実装する理由

レート制限は、単なるバックエンドの保護機能ではありません。LLMを提供するプラットフォーム、特にパブリックAPIやマルチテナントAPIを提供するプラットフォームにとって、それは安定性、ガバナンス、およびビジネスアライメントのための戦略的な層として機能します。OpenAI、Anthropic、またはTrueFoundryで構築されたプラットフォームのいずれであっても、レート制限はいくつかの重要な目的を果たします。

インフラを悪用から保護する

生成AIの推論はリソースを大量に消費します。長文プロンプトや同時リクエストの突然の急増は、GPUキューを圧倒し、レイテンシを増加させ、あるいはサービスを停止させることさえあります。レート制限は、トラフィックが制御され、優先順位付けされた方法で処理されることを保証し、リソースの枯渇を防ぎます。

ユーザーまたはテナント間での公平性を確保する

マルチユーザーシステムでは、あるクライアントの使用が他のクライアントのパフォーマンスを低下させてはなりません。レート制限は、ユーザー、チーム、またはAPIキー間での分離を強制するのに役立ちます。これにより、同時にアクティブなユーザー数に関係なく、一貫したサービスレベルが保証されます。

使用状況を料金プランに合わせる

多くの生成AIプラットフォームは、トークンまたは使用量ティアに基づいて収益化しています。レート制限は、これらの境界を強制するのに役立ちます。例えば：

• 無料ユーザーは1分あたり10リクエストに制限される場合があります
• 有料ティアは、より大きなモデルまたはより高いスループットにアクセスできます
• エンタープライズ顧客は、カスタムクォータまたはバースト容量を受け取ることができます
  

予期せぬコストや予算超過を防ぐ

LLMの利用は、静かに、そして急速に拡大する可能性があります。適切な制限がなければ、トークン消費量やGPU利用率が急増し、予期せぬインフラコストが発生したり、予算管理が困難になったりする恐れがあります。レート制限は、これらの問題を未然に防ぎ、予算を適切に管理するために役立ちます。

信頼性とユーザーエクスペリエンスの向上

利用が制御されると、システムキューは安定した状態を保ちます。これにより、レイテンシーの低減、成功率の向上、そしてより一貫したユーザーエクスペリエンスが実現されます。これは、SLA（サービス品質保証）が求められる本番環境において特に重要です。

AI Gatewayにおけるレート制限オプション

LLMベースのシステムでは、すべてのリクエストが同じ影響を与えるわけではありません。小規模モデルへの短いプロンプトは最小限のリソースしか使用しない一方で、大規模モデルへの長いクエリはかなりのGPU時間を消費する可能性があります。このような変動性があるため、最新のプラットフォームでは、リクエスト数のみに依存するのではなく、複数の側面でレート制限を適用しています。

効果的なレート制限に用いられる最も一般的な側面は以下の通りです。

• APIキーまたはユーザー別: 個々のユーザーまたはAPIトークンに制限を適用できます。これにより、不正利用の防止、ユーザーレベルの監視、そして異なるクライアントやアプリケーション間での公平な利用が実現されます。
• 組織またはチーム別: マルチテナント環境では、各チームまたは顧客が独自のクォータを持つことができます。これにより、特定のテナントが共有リソースを過剰に消費するのを防ぎ、各組織に差別化されたサービスレベルを提供することが可能になります。
• モデルタイプ別: LLMはサイズと計算コストが異なります。例えば、7Bモデルは65Bモデルよりもリソース要求が低いです。モデルタイプごとに個別の制限を適用することで、異なるワークロード間でのコストとパフォーマンスを効果的に管理できます。
• リクエストタイプ別: LLMゲートウェイは、チャット補完、埋め込み、検索ベースのクエリなど、複数のリクエストタイプを処理することがよくあります。各タイプは異なるリソースプロファイルを持つため、リクエストタイプごとのレート制限は、軽量なトラフィックをブロックすることなく、高負荷な操作を制御するのに役立ちます。
• トークン数別: トークンベースの制限は、リクエストベースの制限よりも高い精度を提供します。入力および出力トークンを測定することで、プラットフォームは実際のリソース使用量に基づいてクォータを適用できます。これにより、公平な消費と正確なコスト管理が保証されます。
• リージョンまたはデプロイメントクラスター別: グローバルに分散されたシステムでは、レート制限は場所によって異なる場合があります。これにより、各クラスターまたはゾーンの容量に合わせてポリシーを調整することで、より良い負荷分散と地域的な飽和の回避が可能になります。

これらの側面を活用することで、プラットフォームチームは、インフラの制約、ユーザーのニーズ、およびサービスレベルの期待に合わせてリソース使用量を柔軟に調整できるようになります。

TrueFoundryがレート制限をどのように実装しているか

TrueFoundryは、プラットフォームチームがリクエスト数やトークン使用量に基づいてLLMエンドポイントへのアクセスを制御できる、堅牢で柔軟なレート制限システムを提供します。これにより、コンピューティングリソースの公平な割り当てが保証され、不正利用が防止され、組織のポリシーや課金プランに沿った利用が可能になります。

TrueFoundryのレート制限メカニズムの中核をなすのは、ルールベースの設定システムです。これにより、チームはユーザー、チーム、仮想アカウント、モデル、およびリクエストメタデータ全体にわたって、きめ細かなポリシーを定義できます。

‍

‍

ルールベースの設定

TrueFoundryのレート制限は一連のルールによって定義され、各ルールは以下を指定します。

• 対象: ユーザー、チーム、仮想アカウントなどの対象となるID
• モデル: ルールが適用される特定のモデルID
• メタデータ: 環境やカスタムタグなどのオプションのフィルター
• 制限: 許可されるリクエスト数またはトークン数
• 単位: 適用される時間枠（1分あたり、1時間あたり、または1日あたり）
  

ルールは順番に評価されるため、正しくマッチングされるように、より具体的なルールはより広範なルールよりも上位に配置する必要があります。

サポートされる制限タイプ

TrueFoundryは、リクエストベースとトークンベースの両方の制限をサポートしており、さまざまな時間間隔で適用できます。

• 1分あたりのリクエスト、1時間あたりのリクエスト、1日あたりのリクエスト
• 1分あたりのトークン、1時間あたりのトークン、1日あたりのトークン
  

これにより、実際の計算使用量を反映したポリシーを適用できるようになります。これは、異なるサイズのモデルに可変長のプロンプトを提供する際に特に重要です。

一般的なユースケース

設定システムの柔軟性により、幅広いユースケースに対応できます。

• 特定のユーザーを1日あたり1,000リクエストに制限する
• チームのトークン使用量を全てのモデルで制限する
• GPT-4へのアクセスを制限しつつ、より小さいモデルは無制限に使用できるようにする
• 環境固有の制限を定義する（例：ステージング環境では本番環境よりも低い制限を設定する）
  

設定例

name: ratelimiting-config
type: gateway-rate-limiting-config
rules:
 - id: "specific-rule"
   when:
     subjects: ["user:bob@email.com"]
     models: ["openai-main/gpt4"]
   limit_to: 1000
   unit: requests_per_day

この例では、特定のユーザーのGPT-4使用量を1日あたり1,000リクエストに制限しています。TrueFoundryのレート制限システムは、強力でありながら管理しやすいように設計されています。トークンを意識した制御、きめ細かなターゲティング、明確なYAMLベースのポリシーにより、チームはインフラとコストを管理しながら、LLMの使用を安心して拡張できます。

設定の適用方法

1. TrueFoundry CLIをインストールする:

pip install -U "truefoundry"
tfy login --host https://app.truefoundry.com

2. お使いの config.yaml をプロジェクトディレクトリに配置します。

3. 以下のコマンドで設定を適用します:

tfy apply -f config.yaml

この宣言的なアプローチにより、レート制限はバージョン管理され、再現可能になり、GitOpsのベストプラクティスに沿ったものとなります。

レート制限に関するリアルタイムフィードバック

TrueFoundryのレート制限システムは、制限が超過された場合や上限に近づいている場合に、クライアントに即時かつ透過的なフィードバックを提供するように設計されています。これにより、開発者は使用量の上限を理解し、アプリケーションでスロットリングを適切に処理できるようになります。

リクエストが定義されたレート制限を超過した場合:

• サーバーはHTTP 429 (Too Many Requests) で応答し、レート制限が超過されたことを明確に示します。
• 応答とともに、クライアントがどのように処理を進めるべきかを判断するのに役立つヘッダーが含まれます。

このフィードバックメカニズムは、より良いクライアントの動作をサポートし、自動再試行ロジックを可能にし、推測に頼ることなく使用量がクォータの範囲内に収まることを保証します。

ダッシュボードとアラート

TrueFoundryは、プラットフォームチームがリアルタイムでレート制限ポリシーを監視および最適化するのに役立つ、組み込みの可観測性を提供します。

LLM Gatewayダッシュボードを使用すると、以下を追跡できます:

• レート制限超過によりブロックされたリクエスト
• 利用頻度上位のユーザー、チーム、またはモデル

これらの分析結果は、不正利用の検出、制限の事前調整、そして価値の高いユーザーへの安定したサービス提供に役立ちます。

TrueFoundryでのフォールバック設定方法

レート制限、内部エラー、一時的な停止などによりLLM APIが失敗した場合でも、フォールバックメカニズムによってアプリケーションはスムーズに稼働し続けます。TrueFoundryは、エンドユーザーにエラーを返す代わりに、リクエストをバックアップモデルまたはプロバイダーに自動的にルーティングし、最小限の混乱で可用性を維持します。

フォールバックルールは、モデルID、リクエスト元のユーザーまたはチーム、429や500などの応答コードといった特定の条件に基づいてトリガーされます。リクエストがこれらの条件を満たすと、フォールバック設定で指定された1つ以上の代替モデルにルーティングされます。これらのフォールバックターゲットには、オプションでtemperatureやmax tokensなどのパラメーターの上書きを含めることができ、モデルプロバイダーに応じて動作を微調整できます。評価時には最初に一致したルールのみが適用されるため、予測可能で決定論的な障害処理が保証されます。

TrueFoundryにおける一般的なフォールバックルールは、以下のコンポーネントを含みます。

• 条件 (when): モデルID、顧客IDなどのリクエストメタデータ、またはユーザーやチームなどのリクエスト元に基づいて、ルールが適用されるリクエストを定義します。
• トリガーとなるステータスコード: 500、503、429などのどの応答コードがフォールバックをアクティブにするかを指定します。これらは通常、回復可能なエラーです。
• フォールバックターゲット (fallback_models): トラフィックをルーティングするバックアップモデルまたはエンドポイントのリストで、試行されるべき順序で指定します。
• オプションのパラメーター上書き: フォールバックモデルに転送する際に、temperatureやmax_tokensなどのリクエストパラメーターを調整し、異なるモデルの動作に合わせてカスタマイズできるようにします。

フォールバック設定の例:

name: model-fallback-config
type: gateway-fallback-config
# ルールは順番に評価されます。リクエストが1つのルールに一致すると、それ以降のルールはチェックされません。
rules:
 # openai-main/gpt-4が500または503で失敗した場合、AzureまたはAWS上のgpt-4にフォールバックします。
 # openai-main ターゲットは、temperature や max_tokens などのリクエストパラメータも上書きします。
 - id: "openai-gpt4-fallback"
   when:
     models: ["openai-main/gpt4"]
     response_status_codes: [500, 503]
   fallback_models:
     - target: openai-main/gpt-4
       override_params:
         temperature: 0.9
         max_tokens: 800
 # customer1 の bedrock/llama3 が 500 または 429 エラーで失敗した場合、Azure または AWS の LLaMA3 にフォールバックします。
 - id: "llama-bedrock-customer1-fallback"
   when:
     models: ["bedrock/llama3"]
     metadata:
       customer-id: customer1
     response_status_codes: [500, 429]
   fallback_models:
     - target: aws/llama3
     - target: azure/llama3

TrueFoundryのLLMゲートウェイは、設定システムの一部として宣言的なフォールバック設定をネイティブでサポートしています。これにより、チームはフォールトトレラントなルーティングポリシーを定義し、特に複数のプロバイダーと連携する際に、手動介入なしで稼働時間を維持できます。スマートなレート制限と自動フォールバックが連携することで、高可用性Gen AIサービスの基盤が構築されます。

TrueFoundryを使ったマルチテナントAIにおけるレート制限の管理方法

あらゆるマルチテナントAIプラットフォームにおいて、レート制限は安定性、公平性、コストガバナンスを確保するために不可欠です。これにより、チームはカスタムロジックを必要とせずに、個々のユーザーだけでなく、チーム、仮想アカウント、特定のモデル全体にわたってアクセス境界を定義できます。

TrueFoundryのゲートウェイは、YAML設定を介した宣言的なレート制限をサポートしており、ルールは順番に評価されます。最初の一致するルールが適用されるため、より具体的なルールは上部に、より一般的なルールは設定の下部に配置する必要があります。この構造により、クリーンで読みやすい設定を維持しながら、階層的な制御が保証されます。

各ルールには以下のコンポーネントを含めることができます。

• subjects: レート制限の対象となるエンティティ（個々のユーザー（例：user:bob@email.com）、チーム（例：team:backend）、仮想アカウント（例：virtualaccount:va-james）など）を指定します。
• Models: 特定のモデルID（例：openai-main/gpt4）に基づいてレート制限をフィルタリングします。
• metadata: 環境や顧客IDなど、追加のフィルタリングのためのオプションフィールドです。
  limit_to and unit: 指定された時間枠内での数値の上限（トークンまたはリクエスト）を定義します。
  

マルチテナントレート制限の例

特定のユーザーリクエストを制限する: ユーザーbob@email.comとjack@email.comがopenai-mainアカウントからgpt4モデルに対して行うすべてのリクエストを、1日あたり1000リクエストに制限したいとします。

- id: "user-gpt4-limit"
 when:
   subjects: ["user:bob@email.com", "user:jack@email.com"]
   models: ["openai-main/gpt4"]
 limit_to: 1000
 unit: requests_per_day

チーム全体の制限を適用する: 'frontend'チームのリクエスト総数を1日あたり5000に制限したい場合

- id: "team-frontend-limit"
 when:
   subjects: ["team:frontend"]
 limit_to: 5000
 unit: requests_per_day

仮想アカウントを制限する: 仮想アカウント'va-james'のリクエスト数を1日あたり1500に制限したい場合

- id: "va-james-limit"
 when:
   subjects: ["virtualaccount:va-james"]
 limit_to: 1500
 unit: requests_per_day

すべてのユーザーとモデルにわたってグローバルな上限を設定する:

- id: "{user}-{model}-daily-limit"
 when: {}
 limit_to: 1000000
 単位: 1日あたりのトークン数

この設定により、プラットフォームチームは事業部門全体で利用状況をセグメント化し、環境ごとのクォータを適用し、高価なモデルエンドポイントを保護しながら、スケーラブルで信頼性の高いAIワークロードをサポートできます。

結論

レート制限は、単なるバックエンド制御にとどまりません。それは、大規模なLLMインフラストラクチャの信頼性、費用対効果、および公平な利用を可能にする重要な要素です。マルチテナントプラットフォームを運用している場合でも、顧客に段階的なアクセスを提供している場合でも、チーム全体で社内AIワークロードを実行している場合でも、スマートでトークンを意識したレート制限を実装することで、システムは負荷がかかっても予測可能な状態を維持できます。

レート制限と並行して、フォールバックルーティング、リアルタイムフィードバック、きめ細かな設定などの機能は、エンジニアリングチームにパフォーマンスと制御のバランスを取るためのツールを提供します。TrueFoundryのLLMゲートウェイは、これらの機能を宣言型インターフェースと統合し、プラットフォームチームが透明性、監査可能性、組織目標との整合性のあるポリシーを定義できるようにします。

生成AIの導入が加速するにつれて、ユーザーエクスペリエンスや稼働時間を犠牲にすることなくインテリジェントなアクセス制御を適用するシステムが、次世代のインフラストラクチャの回復力を決定づけるでしょう。AIゲートウェイを構築または拡張している場合、レート制限は単に検討すべき事項ではありません。それは初日から正しく設定すべきものです。

‍

よくある質問

LLMゲートウェイにおけるレート制限とは何ですか？

LLMゲートウェイにおけるレート制限とは、特定の時間枠内でユーザー、チーム、またはアプリケーションが処理できる受信リクエストの頻度やトークンの量を制御するために使用されるメカニズムを指します。従来のAPIスロットリングとは異なり、トークンを意識しており、異なるモデルアーキテクチャの実際の計算負荷を考慮に入れるため、リソースを大量に消費するクエリによってシステムがクラッシュするのを防ぎます。

レート制限はLLMのコスト管理にどのように役立ちますか？

LLMゲートウェイ環境でレート制限を実装することは、予期せぬトークン消費の急増や暴走スクリプトを防ぐことで、コスト管理に役立ちます。日次または時間単位で詳細なクォータを設定することで、組織は特定のユーザーや非本番環境での支出に上限を設けることができ、AI実験が予測可能な予算内に収まるようにしつつ、高額な請求の予期せぬ事態から保護します。

LLM APIにとってレート制限が重要なのはなぜですか？

LLMゲートウェイ設定におけるレート制限は、インフラストラクチャを不正利用から保護し、すべてのユーザーに高い可用性を確保するために不可欠です。これにより、単一の「ノイジーネイバー」がプロバイダーのクォータやGPU容量を使い果たすのを防ぎます。そのような事態が発生すると、レイテンシの増加や頻繁な429「Too Many Requests」エラーにつながる可能性があります。この管理レイヤーは、本番環境で安定したSLAを維持するために極めて重要です。

LLMゲートウェイではどのような種類のレート制限戦略が使用されますか？

LLMゲートウェイにおける一般的なレート制限戦略には、リソース使用量を正確に測定するRequest-Per-Minute (RPM) および Token-Per-Minute (TPM) 制限があります。高度なゲートウェイは、ユーザーロールやモデルタイプに基づいた段階的な制限もサポートしており、ミッションクリティカルなタスクには高い優先順位を与え、優先度の低い開発ワークロードは混雑時にスロットリングされるようにします。

レート制限はLLMの応答レイテンシに影響しますか？

LLMゲートウェイにおけるレート制限は、わずかな処理ステップを追加しますが、通常、4ミリ秒未満のオーバーヘッドしか発生しません。これは、モデル生成に必要な数秒と比較すると無視できるレベルです。実際、バックエンドキューが飽和状態になるのを防ぐことで、体感レイテンシを向上させることが多く、タイムアウトやサービス障害を引き起こすことなくリクエストがスムーズに処理されるようにします。

TrueFoundryはLLMゲートウェイでレート制限を提供していますか？

はい、TrueFoundryは、宣言型でルールベースの設定を通じて、LLMゲートウェイにおける本番環境レベルのレート制限実装を提供しています。これにより、チームはシンプルなYAMLファイルを使用して、複数のモデルプロバイダーとテナントにわたってトークンを意識した制限を適用できます。このシステムは、リアルタイムのフィードバックと詳細なダッシュボードを提供し、プラットフォームチームが厳格なコストとリソースのガバナンスを維持しながらAIワークロードを拡張できるようにします。

AIレートリミットはどのように機能しますか？

AIレートリミットは、ユーザーがAI APIにリクエストを送信する頻度を追跡することで機能します。システムは、一定の時間枠内でリクエストまたはトークンをカウントします。ユーザーが許可された制限を超えると、APIは制限がリセットされるまで新しいリクエストを一時的にブロックするか、エラーを返します。これにより、サーバーが過負荷になるのを防ぎます。

レートリミットはインフラコストの管理に役立ちますか？ 

もちろんです。トークン使用量とリクエストレートに上限を設けることで、ゲートウェイは予期せぬGPUの過剰使用やクラウド費用の増加を防ぎます。組織は、使用量を予算に合わせ、段階的なアクセスを計画し、コストのかかる過剰なプロビジョニングを削減しながら、重要なワークロードに対して一貫したサービスを維持できます。

急激なトラフィックの急増に合わせて、レートリミットを動的に調整できますか？ 

はい。TrueFoundryのような最新のAIゲートウェイは、チームがレートリミットルールをリアルタイムまたは自動スクリプトを介して更新できるようにし、インフラストラクチャが予期せぬ急増にダウンタイムやパフォーマンスの低下なしで対応できるようにします。動的な調整により、テナント全体で公平な使用を維持しながら、サービスを応答性の高い状態に保ちます。