Amazon Bedrock におけるモデル使用量制限リクエストと運用課題の自動処理機能

[Amazon Bedrock](https://aws.amazon.com/bedrock/) は、世界中の 10 万を超える組織——スタートアップから業界を問わずグローバル企業まで——に生成 AI を提供しています。大胆なイノベーションを推進し、実際のビジネスインパクトをもたらす AI を実現するために必要な柔軟性、エンタープライズセキュリティ、実証済みのスケーラビリティを備え、本番環境で動作するアプリケーションやエージェントを自信を持って構築するための、実績のあるインフラストラクチャと包括的な機能を提供します。Amazon Bedrock によって駆動される生成 AI アプリケーションを複数の基盤モデルおよび本番ワークロードにスケールさせる組織にとって、イノベーションの速度を維持するためには、積極的な運用管理が鍵となります。 生成 AI の採用が各チームに広がっていく中で、組織は目的別に構築された運用監視ソリューションの恩恵を受けることができます。このソリューションは以下の機能を提供します：1) 採用拡大に伴うクォータ増分の必要性を予測するプロアクティブな多層監視（利用パターンの追跡を通じて）、および Amazon Bedrock を活用した生成 AI ワークロードにおける運用課題のトリアージ加速；2) AWS サポートエンジニアに必要な情報を提供し、平均解決時間（MTTR）の短縮に寄与する文脈を考慮したサポートケース自動化；3) 同一アラームカテゴリで未解決のケースが既に存在する場合に新規ケース作成を抑止し、進行中の調査への支障を防ぐ重複ケース防止機能；4) AI SRE チームが迅速に対応できるよう支援する文脈付き通知；5) 手動による運用負荷を軽減することでイノベーションへの継続的な集中を可能にする機能です。 本稿では、Amazon Bedrock Ops Alert をご紹介します。これは、運用課題をプロアクティブに検出し、アラーム閾値を動的に調整し、カテゴリ別にアラームを分類し、文脈を考慮したサポートケースを自動的に作成し、同一カテゴリの未解決ケースが既にアクティブな場合に重複ケースの発生を防ぎ、AI SRE チームへ文脈付き通知を提供する 3 レイヤー構成の自動化監視ソリューションです。本稿では、このソリューションのアーキテクチャと、ご自身の環境でどのようにデプロイできるかについて詳しく解説します。 ## ジェネレーティブ AI ワークロードにおける運用成熟度のスケーリング Amazon Bedrock は、顧客間でのリソース割り当てを管理するために、1 分あたりのリクエスト数 (RPM) および 1 分あたりのトークン数 (TPM) に関するサービスクォータを提供しています。これらのクォータは、ワークロードが拡大するにつれて AWS サポートケースを通じて増加させることができます。一般的な初期のアプローチとしては、[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) メトリクスを基盤とするサードパーティ製のダッシュボードソリューションと、クォータの消費状況や必要な場合のリクエスト増額を監視するための手動プロセスを組み合わせた方法があります。このアプローチは、採用初期段階においてチームに有効な役割を果たします。 採用が進むにつれ、組織は多くの場合、ワークロードの最適化がクォータの増加よりも容量要件に対してより効果的に対処できることに気づきます。[クロスリージョン推論](https://docs.aws.amazon.com/bedrock/latest/userguide/cross-region-inference.html) は、異なる AWS リージョン間でコンピューティングリソースを活用することで、組織が予期せぬトラフィックの急増を管理するのを支援します。特定の地理領域に紐付けられた推論プロファイルを使用する場合、Amazon Bedrock はその地理領域内で最適な商用 AWS リージョンを自動的に選択し、推論リクエストを処理します。[グローバルクロスリージョン推論](https://docs.aws.amazon.com/bedrock/latest/userguide/global-cross-region-inference.html) は、この機能を地理的な境界を超えて拡張し、世界中の商用 AWS リージョンに対して推論リクエストをルーティングすることで、利用可能なリソースを最適化し、より高いモデルスループットを提供します。グローバル推論プロファイルを使用すると、ワークロードは個々のリージョンの容量に制約されなくなり、地理的なクロスリージョン推論と比較してはるかに大きなリソースプールへのアクセスが可能となり、コストを約 10% 削減できます。 ポスト「Anthropic の Claude Sonnet 4.5 を使用した Amazon Bedrock 上の新しいグローバルクロスリージョン推論によるグローバル AI 推論のスケーラビリティの解放」(https://aws.amazon.com/blogs/machine-learning/unlock-global-ai-inference-scalability-using-new-global-cross-region-inference-on-amazon-bedrock-with-anthropics-claude-sonnet-4-5/) では、グローバル推論プロファイルが AWS のグローバルインフラストラクチャ全体にリクエストを動的にルーティングし、本来はクォータの増加が必要となるような需要を吸収する方法について詳しく解説しています。 [Prompt caching](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html) は、推論応答のレイテンシと入力トークンコストを削減するためのオプション機能です。コンテキストの一部をキャッシュに追加することで、モデルは入力の再計算をスキップし、Amazon Bedrock が計算リソースの節約を共有して応答遅延を低減できます。Prompt caching は、複数のクエリで頻繁に再利用される長く反復的なコンテキストを持つワークロードにおいて効果的で、コストを最大 90%、レイテンシを最大 85% 削減し、直接トークン毎分の消費量を低下させます。[Effectively use prompt caching on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/effectively-use-prompt-caching-on-amazon-bedrock/) の記事では、複数の API 呼び出し全体でキャッシュヒットを最大化するためのプロンプトの構成方法について解説しています。バッチ推論や [Intelligent Prompt Routing](https://aws.amazon.com/bedrock/cost-optimization/) などの追加技術により、各呼び出しに対して最もコスト効率の高いモデルを動的に選択することで、リクエストごとのオーバーヘッドがさらに削減されます。 [max_tokens](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas-token-burndown.html) パラメータを最適化することで、割り当てられたクォータ容量を効率的に活用できます。max_tokens の値は、各リクエストの開始時にクォータから差し引かれます。処理中は、生成された実際の出力トークン数に応じて消費されるクォータが定期的に調整され、リクエスト終了時には未使用のトークンがクォータに戻されます。後続の投稿「Amazon Bedrock における推論ワークロードの運用可視性を向上させるため、TTFT と推定クォータ消費量に関する新しい CloudWatch メトリクスを導入する」(https://aws.amazon.com/blogs/machine-learning/improve-operational-visibility-for-inference-workloads-on-amazon-bedrock-with-new-cloudwatch-metrics-for-ttft-and-estimated-quota-consumption/) では、リクエストタイプごとに max_tokens の決定を導くために、InputTokenCount および OutputTokenCount という CloudWatch メトリクスをどのように監視するかについて詳しく解説しています。 組織がこれらの最適化戦略を採用し、複数の基盤モデルや本番ワークロードに展開するにつれ、AI SRE チームはイノベーションの速度を維持し、平均修復時間 (MTTR) を短縮するために、自動化された運用モニタリングでこれらを補完しようとしています。具体的には、チームは一般的に改善が必要な 4 つの領域を特定しています。 - リアクティブな運用：AI SRE チームは、ビジネスユーザーから影響の報告があった場合にのみ運用上の問題に気づくことが多く、これがチームを反応的な運用に追い込み、影響が拡大する前に調査や対応を行う時間が限られてしまいます。 - ケース文脈の強化の機会：クォータに関する問題が発生した際、サポートケースにはより豊富な文脈を提供することで、単純なクォータ増量リクエストと、より深い調査を要する事案を区別し、サポートエンジニアがケースを迅速に解決できるよう支援できます。 - 運用負荷の増大：組織が多様なユースケース向けに新しいファウンデーションモデルを採用するにつれ、各新モデルには独自の監視設定とクォータ増量リクエストが必要となります。この区別のない重労働は、モデルポートフォリオの拡大に伴い線形的に増加します。 - アラーム閾値の移動目標：承認された各クォータ増量は、AI SRE チームが手動で CloudWatch のアラーム閾値を再計算・更新することを要求し、運用オーバーヘッドと設定のドリフトリスクを生み出します。 ## ソリューション概要 Amazon Bedrock Ops Alert は、[AWS CloudFormation](https://aws.amazon.com/cloudformation/) ベースのソリューションであり、3 つの補完的な検出レイヤーを通じて包括的な生成 AI 観測性を実装しています。各レイヤーは、即座の運用問題の検出から予測的な異常の特定に至るまで、生成 AI ワークロードに対する異なる可視性を提供します。 本ソリューションは、Amazon CloudWatch アラーム、[AWS Lambda](https://aws.amazon.com/lambda/) 関数、[Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/)、[Service Quotas](https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html) API、および [AWS Support API](https://docs.aws.amazon.com/awssupport/latest/user/about-support-api.html) を活用しています。 以下の図は、本ソリューションのアーキテクチャを示しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/02/ML-20534-1.png) ワークフローの手順は以下の通りです。 - デプロイ中に、Lambda 関数（Quota Calculator）は Service Quotas API をクエリして現在の RPM および TPM クォータ値を取得し、設定されたパーセンテージを適用することでアラーム閾値を計算します。 - 計算された閾値は AWS Systems Manager Parameter Store に保存され、AI SRE チームのメール連絡先は AWS Secrets Manager に保存されます。 - Amazon Bedrock は、ランタイムメトリクス（呼び出し回数、トークン数、エラー、スロットリング、レイテンシ）を CloudWatch に公開します。これらのメトリクスは 3 つの独立した監視層によって評価されます： レイヤー 1（クリティカルエラー検出）は、即時アラートのためにスロットリング、クライアントエラー、およびサーバーエラーを監視します。 - レイヤー 2（使用率モニタリング）は、RPM、TPM、およびレイテンシを動的に計算された閾値と比較します。 - レイヤー 3（異常検出）は、CloudWatch の機械学習を使用してメトリクス全体で異常なパターンを特定します。 - 子アラームがトリガーされると、複合アラームがその状態を集約します。 - 複合アラームは SNS トピック（Raw Alarm Topic）に公開されます。 - この SNS トピックは、Lambda 通知プロセッサ関数を呼び出し、この関数は複合アラームをポーリングしてどの子アラームがトリガーされたかを特定し、アラームの重大度（クリティカルまたは警告）を決定します。 - 通知プロセッサは Service Quotas API をクエリして現在の RPM および TPM クォータ値を取得します。 - 通知プロセッサは CloudWatch をクエリして現在の使用率メトリクスを取得し、過去 14 日間の定常状態およびピークの RPM/TPM、および 1 回あたりの平均トークン数を含みます。また、Parameter Store に保存されたアラーム閾値を読み取り、ピーク使用量を閾値と比較してサポートケースのシナリオを決定します。 - 自動化されたサポートケース作成が有効になっている場合、この関数はアラームをクォータ関連または非クォータに分類し、カテゴリ認識型の重複検出（設定可能なルックバックウィンドウ、デフォルトは 60 日）を使用して未解決の既存ケースがあるかを確認します。そして、既存のケースに通信を追加するか、新しい AWS Support ケースを作成します。クォータ関連のアラームの場合、ケースには使用量が検証されたコンテンツを含む事前入力済みのクォータデータが含まれます。非クォータアラーム（永続的なエラーやレイテンシ異常など）の場合、根本原因分析を支援するためのコンテキストを提供します。 - サポートケース処理が完了した後、関数は 2 つ目の SNS トピック（Formatted Notification Topic）を通じて、通知設定（すべて、クリティカル、または警告）でフィルタリングされたステークホルダーにフォーマットされたメール通知を送信します。サポートケースが作成された場合、メールにはケース ID と AWS Support コンソールへの直接リンクが含まれます。 - フォーマットされた通知は、購読しているステークホルダーに対してメールとして配信されます。 - 設定可能なスケジュールで、Amazon EventBridge ルールが Lambda 関数（Alarm Updater）をトリガーします。 - Alarm Updater は Service Quotas API をクエリして現在の RPM および TPM クォータ値を取得します。 - Alarm Updater は設定されたパーセンテージを適用してアラーム閾値を再計算し、新しい閾値で CloudWatch アラームを更新します。 - 更新された閾値は、履歴を追跡するためのタイムスタンプと共に Parameter Store に保存されます。 ## 3 層モニタリングアーキテクチャ 本ソリューションは、異なる段階で運用上の問題を検出するために独立して動作する CloudWatch アラームを使用して、3 つのモニタリング層を実装しています。 **レイヤー 1: 重大エラーの検出** 最初のレイヤーは、運用上の問題を示すエラーメトリクスを監視します: - ClientErrors アラーム：InvocationClientErrors メトリクスを監視し、クォータ制限の超過、バリデーションエラー、または無効なパラメータなどのクライアント側の問題により拒否されたリクエストを特定します。 - ServerErrors アラーム：Investigation が必要なサービス側のエラーを特定するために InvocationServerErrors メトリクスを監視します。 - Throttles アラーム：レート制限に達した際に明示的にスロットリングされるリクエストを特定するために InvocationThrottles メトリクスを監視します。 これらのアラームは、設定可能なしきい値と評価期間を使用しています。エラーしきい値を 0 に設定して評価期間を 1 とすることで、エラー発生時に即座にアラートがトリガーされますが、より高い値を設定することで一時的な問題に対する許容度を高めることができます。 **レイヤー 2: 使用率モニタリング** 2 つ目のレイヤーは、動的に計算されたしきい値に対して使用量メトリクスを監視し、クォータ制限に達する前に予防的なアラートを提供します： - HighInvocationRate アラーム：Invocations メトリクスを監視し、API 要求レートが設定された RPM（リクエスト毎分）閾値の割合を超えた場合にトリガーされます。 - HighTPMQuotaUsage アラーム：EstimatedTPMQuotaUsage メトリクスを監視し、推定される 1 分あたりのトークン使用量が設定された TPM（トータル・ミニッツ・パーミッション）閾値の割合を超えた場合にトリガーされます（キャッシュ書き込みトークンおよび出力バーンドウン乗数を含みます）。 - HighLatency アラーム：InvocationLatency メトリクスを監視し、応答時間が設定されたレイテンシ閾値を超えた場合にトリガーされます。 本ソリューションは、Service Quotas API をクエリしてアラーム閾値を自動的に計算し、設定可能なパーセンテージを適用します。例えば、80% の閾値と 100 RPM のクォータの場合、RPM アラームは 1 分あたり 80 リクエストでトリガーされます。TPM の場合も同様に、1,000,000 TPM のクォータに対して 80% の閾値を適用すると、有効なトークン閾値は 800,000 トークンとなります。TPM アラームは、キャッシュ書き込みトークンおよび出力バーンドウン乗数を含む推定 TPM クォータ使用量を追跡する EstimatedTPMQuotaUsage メトリクスを使用します。 **レイヤー 3：異常検知** 第 3 レイヤーでは、CloudWatch の異常検知を閾値タイプとして使用し、メトリクス全体にわたる異常なパターンを識別します： - InvocationAnomaly アラーム：異常検出を使用して Invocations メトリクスを監視し、予期せぬリクエスト量の増減を検出します。 - InputTokenAnomaly アラーム：異常検出を使用して InputTokenCount メトリクスを監視し、入力トークンの使用における異常を検出します。 - OutputTokenAnomaly アラーム：異常検出を使用して OutputTokenCount メトリクスを監視し、出力トークンの使用における異常を検出します。 - LatencyAnomaly アラーム：異常検出を使用して InvocationLatency メトリクスを監視し、パフォーマンスの低下傾向を検出します。 CloudWatch の機械学習は、履歴データを分析して正常な動作の基準値を確立し、現在のメトリクスが期待される範囲の上限閾値を超えた場合にアラートを発令します。本ソリューションは上昇方向への逸脱のみを監視しており、使用量の減少は介入を要しないポジティブなシグナルとみなされます。このアプローチにより、静的な閾値では見逃されがちな問題、例えば段階的なクォータ消費の増加や予期せぬ使用量の急増などを検出することが可能です。 ## 自動閾値管理 本ソリューションは、自動閾値再計算を通じてクォータの変更に対して動的に適応します： - 初期計算：デプロイ時に Lambda 関数が Service Quotas API を照会し、現在のクォータと設定されたパーセンテージに基づいてアラーム閾値を計算します。 - 定期更新：EventBridge ルールが構成可能なスケジュール（デフォルト：1 日ごと）で閾値の再計算トリガーとなります。 - アラーム自動更新：承認されたクォータ増加分によりクォータ値が変更されると、本ソリューションは CloudWatch アラームを新しい閾値で更新します。 - 閾値履歴：計算された閾値は、AWS Systems Manager の機能である Parameter Store にタイムスタンプと共に保存されます。 この自動化により、追加のクォータ増分リクエストが承認された際の手動による閾値メンテナンスを軽減できます。AI SRE チームはもはやクォータ変更を追跡してアラーム設定を手動で更新する必要がなく、システムが自己修正します。 以下の表は、Service Quotas の値からどのようにアラーム閾値が導出されるかを説明しています。 | **Threshold** | **Formula** | **Example** | |---|---|---| | RPM threshold | RPM quota × (RequestsPerMinuteThresholdPercent / 100) | 10,000 RPM quota × 80% = 8,000 | | TPM threshold | TPM quota × (TokensPerMinuteThresholdPercent / 100) | 6,250,000 TPM quota × 80% = 5,000,000 | TPM 閾値パーセンテージは TPM クォータに直接適用されます。サポートケースのシナリオを決定する際、使用状況検証ではこの閾値に対して過去 14 日間のピーク TPM が比較されます。 ## オートメーション化されたサポートケースの作成 本ソリューションは、運用上の問題が検出された際に AWS サポートケースを自動的に作成する機能をオプションで提供します。この機能を利用するには、Support API へのアクセス権限を持つ AWS ビジネスまたはエンタープライズサポートプランへの加入が必要です。 ワークフローは以下の通りです： - コンポジットアラーム（複合アラート）が子アラームのいずれかが ALARM 状態になった際にトリガーされます。 - Lambda 関数がコンポジットアラームの状態をポーリングし、対象となる子アラームを確認します。 - 関数は Parameter Store に保存されたアラーム閾値を読み取り、過去 14 日間のピーク使用量と閾値を比較して、サポートケースのシナリオを特定します。 - 関数はアラームがクォータ関連か非クォータ関連かを分類し、カテゴリ認識型の重複検出（設定可能なルックバックウィンドウ、デフォルトは 60 日）を使用して、Support API で未解決の既存ケースが存在するか確認します。 同じカテゴリの未解決ケースが存在する場合、システムはその既存ケースに完全なアラーム詳細、更新されたメトリクス、および緊急性の文脈を含む通信を追加します。重複するケースが存在しない場合、システムは新しいサポートケースを作成し、sce

Amazon Bedrock におけるモデル使用量制限リクエストと運用課題の自動処理機能

背景や根拠まで確認しますか？

調べる

選ぶ

サイト