Amazon Bedrock、document history で RPM クォータ説明の更新を確認

Amazon Bedrock ユーザーガイド の document history では、RPM クォータ説明の更新として、Bedrock のエンドポイントごとのクォータ挙動が整理されています。公開ページ本文の日付行には 2026年6月30日の別更新も並ぶため、今回の記事では RPM クォータ説明の行を運用上の確認対象として扱います。

要点

• document history では、RPM クォータ説明の更新として、Bedrock エンドポイント間の挙動差が説明されています。
• bedrock-mantle は モデル単位 RPM クォータを公開せず、スロットリングはトークンベースのクォータで制御されるとされています。
• bedrock-runtime では RPM クォータがモデル固有で、一部モデルは RPM クォータの対象外と説明されています。
• RPM とトークン制限を混同すると、スロットリング原因やクォータ引き上げ対象を誤りやすくなります。

今回の更新で変わること

今回の document history 行は、Bedrock のクォータを読むときに、エンドポイントごとの違いを明確にする内容です。説明では、bedrock-mantle エンドポイントは モデル単位 RPM クォータを公開しておらず、スロットリングはトークンベースのクォータで制御されるとされています。一方、bedrock-runtime エンドポイントでは RPM クォータがモデル固有であり、Anthropic Claude Opus 4.7 や Claude Opus 4.8 など、一部モデルは RPM クォータの対象外と説明されています。RPM クォータがあるモデルについては AWS のクォータ管理コンソールを見る流れです。

この差分は、Bedrock を本番運用するチームにとって実務的です。アプリケーションが bedrock-runtime だけを使っている場合と、OpenAI互換の bedrock-mantle を含む場合では、スロットリング時に見るべき指標が変わります。前者ではモデル固有のリクエスト数制限とトークン制限を分けて確認し、後者ではリクエスト数よりも入力・出力トークン、並列実行、長文応答の影響を重視する必要があります。同じモデル名でもエンドポイントが違えば、運用上の制限の見え方が変わる点が読みどころです。

また、document history の性質上、この行はユーザー向けの詳細手順ではなく、どのドキュメントが変わったかを知らせる索引です。実際の設計では、クォータ ページ、bedrock-runtime のクォータページ、bedrock-mantle のクォータページ、トークン数の数え方を合わせて確認する必要があります。スロットリングを受けたときに「RPMを増やせば解決する」と決め打ちすると、トークン制限やエンドポイント選択が原因だった場合に対処が遅れます。

運用チームは、Bedrock を使う各アプリについて、エンドポイント、モデル、リージョン、ピーク時の入力トークン、出力トークン、リクエスト数、リトライ設計を一覧化したいです。エージェント型アプリでは、1つのユーザー操作から複数回のモデル呼び出しやツール呼び出しが発生するため、見かけの利用者数よりもトークン消費が早く増える場合があります。今回の更新は、そうした設計をRPM表だけで済ませないための確認材料です。

今回の更新が関係する人

Amazon Bedrock で生成AIアプリ、エージェント、互換API、長文生成、バッチ処理を運用する開発チームとSREに関係します。特に、Claude 系モデルや Mantle エンドポイントを含む複数経路で推論を呼び出している組織では確認しておきたいです。

実務で確認したいポイント

• Bedrock 呼び出しを bedrock-runtime と bedrock-mantle に分け、モデル単位で利用量を見る。
• RPM クォータの対象外モデルでも、入力・出力トークンや並列度による制約を確認する。
• スロットリング時のログに、エンドポイント、モデル、トークン量、リクエスト数を残す。
• クォータ引き上げ申請を行う前に、RPM、トークン、エンドポイントのどれが制約かを切り分ける。

結局、今回の更新をどう読むべきか

今回の document history 更新は、Bedrock のクォータ運用をより細かく読むための合図です。RPM という言葉だけに引きずられず、エンドポイント別の制御、モデル別の扱い、トークンベースの制限を分けて確認する必要があります。