AWSは2026年5月27日、Amazon Bedrockのbedrock-runtimeとbedrock-mantleに関するクォータ資料を更新し、リクエスト数とトークン量の制限方法の違いを明確にした。
両エンドポイントは同じAmazon Bedrockのモデルへアクセスする場合でも、スロットリングの単位が同じではない。従来のbedrock-runtime向けに作った「1分当たりのリクエスト数」を中心とする制御を、そのままMantleへ適用すると、実際の制限要因を正しく把握できない可能性がある。
何が違うか
主要な違いは次の通りである。
| 項目 | bedrock-runtime | bedrock-mantle |
|---|---|---|
| RPM制限 | モデルによって存在する | RPM制限なし |
| 入力・出力TPM | 入力と出力を合算したモデル別TPM | 入力TPMと出力TPMを別々に管理 |
| クォータの範囲 | モデル別、リージョン別 | モデル別、リージョン別 |
| キャッシュ読み取り | モデルと機能の条件に従う | キャッシュから読んだ入力トークンは入力TPMに算入しない |
| 主な確認先 | Service Quotas Console | Mantleのクォータ資料とService Quotas |
RPMはrequests per minute、TPMはtokens per minuteを意味する。
bedrock-runtimeの制限
bedrock-runtimeでは、モデルごと、リージョンごとにトークン制限が設定される。主な項目は次の通りである。
- Cross-Region InvokeModel tokens per minute
- On-demand InvokeModel tokens per minute
- Model invocation max tokens per day
- InvokeModel requests per minute
入力トークンと出力トークンは、合算して1つのモデル別TPMクォータへ計上される。出力トークンはモデル固有のburndown rateでクォータ使用量へ換算されるため、APIレスポンスの出力トークン数だけをそのまま制限値と比較できない場合がある。
RPM制限はすべてのモデルへ一律に適用されるわけではない。AWSは例として、Anthropic Claude Opus 4.7とClaude Opus 4.8にはRPMクォータがなく、トークンベースのクォータだけで制御されると説明している。
したがって、「RPMが上限へ達していないから余裕がある」という判断は成立しない。RPMが存在しないモデルでも、TPMまたは日次トークン上限でスロットリングされる。
bedrock-mantleの制限
bedrock-mantleはOpenAI互換のAPIエンドポイントを提供する経路であり、RPMクォータを適用しない。スロットリングは入力トークンと出力トークンのクォータで決まる。
重要な点は、入力TPMと出力TPMが分離されていることである。短い入力から長い出力を生成する処理と、長い入力を短く要約する処理では、ボトルネックになるクォータが異なる。
また、プロンプトキャッシュから読み取られた入力トークンは、Mantleの入力TPMへ算入されない。キャッシュ利用は料金だけでなく、入力側の処理容量にも影響する。
誰に影響するか
影響が大きいのは次のシステムである。
bedrock-runtimeからbedrock-mantleへ移行する- OpenAI SDKのbase URLを変更してBedrockを利用する
- 1分当たりのリクエスト数だけで流量を制御している
- 入力と出力のトークン量を分けて記録していない
- 長文生成やエージェント処理で出力トークンが大きい
- 大規模RAGで入力トークンが大きい
- 複数リージョンまたはCross-Region Inferenceを使う
- クォータ増加申請を本番直前に行う
SDK互換性があっても、運用上の容量設計まで互換になるわけではない。
起きやすい誤り
RPMだけを監視する
MantleにはRPM制限がないため、RPMダッシュボードが正常でも、入力または出力TPMが上限へ達する。リクエスト件数ではなく、リクエストごとのトークン量を計測する必要がある。
平均トークン数だけで設計する
平均が小さくても、一部の長文リクエストが短時間に集中するとTPMを消費する。P50だけでなく、P95、P99、最大値を確認する。
入力と出力を同じキューで扱う
Mantleでは入力と出力の上限が別である。長文入力型と長文出力型を同じ優先度で処理すると、片側のクォータだけが枯渇する可能性がある。
モデル間でクォータ仕様が同じと考える
bedrock-runtimeのRPM有無はモデル固有である。モデルを変更すると、同じエンドポイントでもボトルネックが変わる可能性がある。
クォータ増加を即時反映と考える
AWS Supportとの確認が必要になる増加申請もある。本番負荷試験の直前ではなく、必要量を早めに算定する必要がある。
必要な対応
1. 利用エンドポイントを明確にする
コード、SDK設定、base URL、IAM権限、監視ダッシュボードから、bedrock-runtimeとbedrock-mantleのどちらを使っているかを特定する。サービスごとに混在している場合は台帳化する。
2. 入力・出力トークンを分離して記録する
少なくとも次の指標をモデル別、リージョン別に収集する。
- 1分当たりの入力トークン
- 1分当たりの出力トークン
- 1日当たりの合計トークン
- リクエスト件数
- スロットリング件数
- 再試行回数
- キャッシュ読み取りトークン
- リクエストのP50、P95、P99トークン数
3. トークンベースのレート制御を導入する
各リクエストの予想入力トークンとmax_tokensを使い、送信前に必要容量を見積もる。一定件数を機械的に送るのではなく、利用可能なトークン予算に合わせてキューから取り出す。
4. 入力型と出力型のワークロードを分ける
RAG、長文要約、コードベース解析は入力側を消費しやすい。レポート生成、コード生成、エージェントの長い応答は出力側を消費しやすい。ワークロード別にキューと同時実行数を分けると制御しやすい。
5. クォータ超過時の再試行を制御する
即時再試行を繰り返すと、制限が解除される前にさらに負荷を加える。指数バックオフ、ジッター、最大再試行回数、デッドレターキューを設定する。
6. 本番相当の負荷試験を行う
短いテストプロンプトを大量送信するだけでは、実運用のTPMを再現できない。実際の入力長と出力長の分布を使い、リージョン、モデル、キャッシュ有無ごとに試験する。
編集部分析
今回の明確化は、Amazon Bedrockの容量設計を「API呼び出し回数」から「トークン流量」へ移す必要性を示している。生成AIでは1リクエストの重さが大きく変動するため、毎分100件という指標だけでは負荷を表せない。
特にエージェント処理では、1つのユーザー操作が複数回のモデル呼び出しと長い出力を発生させる。画面上の利用者数が変わらなくても、ツール呼び出し回数やコンテキスト蓄積によりTPMが急増する。
また、Mantleでキャッシュ読み取りが入力TPMへ算入されないことは、キャッシュを単なる料金削減機能ではなく、容量確保の手段として評価できることを意味する。ただし、キャッシュ対象の選定、書き込み費用、内容更新時の無効化は別途検証が必要である。
実務チェックリスト
- [ ] 利用中のBedrockエンドポイントを特定した
- [ ] モデル別・リージョン別のクォータを確認した
- [ ] RPMの有無をモデルごとに確認した
- [ ] 入力TPMと出力TPMを分けて監視した
- [ ] 日次トークン上限を監視した
- [ ] キャッシュ読み取り量を計測した
- [ ] トークン量を考慮する送信制御を実装した
- [ ] 指数バックオフとジッターを設定した
- [ ] 本番相当の入力・出力分布で負荷試験した
- [ ] 必要なクォータ増加を早期に申請した