Amazon Bedrock で大規模な自律型 AI オペレーションを構築する方法

Amazon Bedrock は、世界中の 10 万を超える組織——スタートアップから業界を問わずグローバル企業に至るまで——に生成 AI を提供しています。大胆なイノベーションを推進し、実際のビジネスインパクトをもたらす AI を実現するために必要な柔軟性、エンタープライズセキュリティ、実証済みのスケーラビリティを備え、本番環境で動作するアプリケーションやエージェントを確信を持って構築するための、実績のあるインフラと包括的な機能を提供します。Amazon Bedrock によって駆動される生成 AI アプリケーションを複数の基盤モデルおよび本番ワークロードに拡大する組織にとって、イノベーションの速度を維持するためには、先行的な運用管理が鍵となります。

生成 AI の採用が各チームに広がっていく中で、組織は以下の特徴を持つ目的特化型の運用監視ソリューションから恩恵を受けることができます。1) 採用の拡大に伴うクォータ増加の必要性を予測し、使用パターンを追跡することで先行的な多層監視を実現し、Amazon Bedrock を活用した生成 AI ワークロードの運用課題のトリアージを加速します。2) AWS サポートエンジニアが必要な情報を提供することで平均解決時間を短縮する、文脈を考慮したサポートケースの自動化。3) 同一のアラームカテゴリに未解決のケースが既に存在する場合に新しいケースの作成を抑止し、進行中の調査からの注意散漫を防ぐ重複ケース防止機能。4) AI SRE チームが迅速に対応できるよう支援する、文脈に基づいた通知。5) 手動による運用オーバーヘッドを削減することで、イノベーションへの継続的な集中を維持します。

本稿では、Amazon Bedrock Ops Alert をご紹介します。これは、運用上の課題を先行的に検出し、アラーム閾値を動的に調整し、カテゴリ別にアラームを分類し、文脈を考慮したサポートケースを自動的に作成し、同一のアラームカテゴリの未解決ケースが既にアクティブな場合に重複ケースの発生を防ぎ、AI SRE チームへ文脈に基づいた通知を提供する 3 レイヤー構成の自動化監視ソリューションです。本稿では、このソリューションアーキテクチャと、ご自身の環境でこれをデプロイする方法について詳しく解説します。

ジェネレーティブ AI ワークロードにおける運用成熟度のスケーリング

Amazon Bedrock は、顧客間でのリソース割り当てを管理するために、1 分あたりのリクエスト数 (RPM) および 1 分あたりのトークン数 (TPM) に関するサービスクォータを提供しています。これらのクォータは、ワークロードが拡大するにつれて AWS サポートケースを通じて増額することが可能です。初期段階で一般的に採用されるアプローチとしては、Amazon CloudWatch のメトリクスを基盤としたサードパーティ製のダッシュボードソリューションと、必要に応じてクォータの使用状況やリクエストの増加を手動で監視・処理するプロセスを組み合わせた方法があります。このアプローチは、導入初期段階にあるチームにとって十分に機能します。

採用が進むにつれ、組織は多くの場合、クォータの増加よりもワークロード最適化の方がキャパシティ要件に対してより効果的に対処できることに気づきます。クロスリージョン推論 は、異なる AWS リージョン間でコンピューティングリソースを活用することで、組織が予期せぬトラフィックの急増を管理するのを支援します。特定の地理領域に紐付けられた推論プロファイルを使用する場合、Amazon Bedrock はその地理領域内で最適な商用 AWS リージョンを自動的に選択し、推論リクエストを処理します。グローバルクロスリージョン推論 は、この機能を地理的な境界を超えて拡張し、世界中の商用 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 は、推論応答のレイテンシと入力トークンのコストを削減するためのオプション機能です。コンテキストの一部をキャッシュに追加することで、モデルは入力の再計算をスキップし、Amazon Bedrock が計算リソースの節約を共有して応答遅延を低減できます。Prompt caching は、複数のクエリで頻繁に再利用される長く反復的なコンテキストを持つワークロードにおいて特に有効であり、コストを最大 90%、レイテンシを最大 85% 削減し、直接トークン毎分の消費量を低下させます。Effectively use prompt caching on Amazon Bedrock の記事では、複数の API 呼び出し全体でキャッシュヒットを最大化するためのプロンプトの構成方法について解説しています。さらに、バッチ推論や Intelligent Prompt Routing（インテリジェント・プロンプトラウティング）などの追加技術により、各呼び出しに対して最もコスト効率の高いモデルを動的に選択することで、1 件あたりのオーバーヘッドをさらに削減できます。

組織がこれらの最適化戦略を採用し、複数の基盤モデルおよび本番ワークロードへと展開するにつれ、AI SRE チームはイノベーションの速度を維持し、平均修復時間を短縮するために、自動化された運用監視でこれらを補完することを目指します。具体的には、チームは一般的に改善が必要な 4 つの領域を特定しています。

• リアクティブ運用：AI SRE チームは、ビジネスユーザーから影響の報告があった場合にのみ運用上の問題に気づくことが多く、これがチームをリアクティブな運用体制に追い込み、影響が拡大する前に調査や対応を行うための時間が限られてしまいます。

• ケース文脈の強化の機会：クォータに関する問題が発生した際、サポートケースにはより豊富な文脈情報を付与することで、単純なクォータ増量リクエストと、より深い調査を要する事案を明確に区別でき、サポートエンジニアがケースを迅速に解決できるよう支援できます。

• 運用負荷の増幅：組織が異なるユースケースのために新しいファウンデーションモデルを採用するにつれ、各新モデルごとに独自の監視設定とクォータ増量リクエストが必要となります。この差異化されていない重労働は、モデルポートフォリオの拡大に伴って線形的に増加します。

• 警報閾値の移動目標：承認された各クォータ増量は、AI SRE チームが手動で CloudWatch の警報閾値を再計算し更新することを要求するため、運用オーバーヘッドが生じ、設定のドリフト（構成の逸脱）というリスクも伴います。

ソリューション概要

Amazon Bedrock Ops Alert は、AWS CloudFormation ベースのソリューションであり、3 つの補完的な検出レイヤーを通じて包括的な生成 AI 観測性を実装します。各レイヤーは、即座に発生する運用問題の検出から予測的な異常の特定に至るまで、生成 AI ワークロードに対する異なる可視性を提供します。

本ソリューションでは、Amazon CloudWatch アラーム、AWS Lambda 関数、Amazon Simple Notification Service (Amazon SNS)、Service Quotas API、および AWS Support API を活用しています。

以下の図は本ソリューションのアーキテクチャを示しています。

ワークフローの手順は以下の通りです。

• デプロイメント中、Lambda 関数（クォータ計算機）は 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、およびリクエストあたりの平均トークン数を取得します。また、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 アラーム（CloudWatch alarms）を用いた 3 つのモニタリングレイヤーを実装しています。

レイヤー 1: 重大エラーの検出

最初のレイヤーは、運用上の問題を示すエラーメトリクスを監視します:

• ClientErrors アラーム：InvocationClientErrors メトリクスを監視し、クォータ制限の超過、バリデーションエラー、または無効なパラメータなどのクライアント側の問題によりリクエストが拒否されたことを特定します。

• ServerErrors アラーム：Investigation が必要なサービス側のエラーを特定するために InvocationServerErrors メトリクスを監視します。

• Throttles アラーム：レート制限に達した際に明示的にスロットリング（Throttling）されるリクエストを特定するために InvocationThrottles メトリクスを監視します。

これらのアラームは、設定可能な閾値と評価期間を使用しています。エラー閾値を 0 に設定し、評価期間を 1 つにすることで、エラー発生時に即座にアラートがトリガーされます。一方、より高い値を設定することで、一時的な問題に対する許容度を高めることができます。

レイヤー 2: 使用率の監視

2 つ目のレイヤーは、動的に計算された閾値に対して使用量メトリクスを監視し、クォータ制限に達する前に予防的なアラートを提供します：

• HighInvocationRate アラーム：Invocations メトリクスを監視し、API 要求レートが設定された RPM（1 分あたりのリクエスト数）閾値の割合を超えた場合にトリガーされます。

• HighTPMQuotaUsage アラーム：EstimatedTPMQuotaUsage メトリクスを監視し、推定される 1 分あたりのトークン使用量が設定された TPM（1 分あたりのトーク数）閾値の割合を超えた場合にトリガーされます（キャッシュ書き込みトークンおよび出力バーンドウン乗数を含まれます）。

• 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 Quota の値からどのようにアラーム閾値が導出されるかを説明しています。

TPM 閾値パーセンテージは TPM クォータに直接適用されます。サポートケースのシナリオを決定する際、使用状況検証ではこの閾値に対して過去 14 日間のピーク TPM が比較されます。

自動サポートケース作成

本ソリューションは、運用上の問題が検出された場合に AWS サポートケースの作成をオプションで自動化します。この機能を利用するには、Support API アクセスのために AWS ビジネスまたはエンタープライズサポートプランへの加入が必要です。

ワークフローは以下の通りです：

• 子アラームが ALARM 状態になると、複合アラーム（composite alarm）がトリガーされます。
• Lambda 関数が複合アラームの状態をポーリングし、対象となる子アラームを確認します。
• 関数は Parameter Store に保存されたアラーム閾値を読み取り、過去 14 日間のピーク使用量と閾値を比較して、サポートケースのシナリオを決定します。
• 関数はアラームがクォータ関連か非クォータかを分類し、カテゴリ認識型の重複検出（設定可能なルックバックウィンドウ、デフォルトは 60 日）を使用して、Support API で未解決の既存ケースが存在するか確認します。
• 同じカテゴリの未解決ケースが存在する場合は、システムが既存のケースに通信を追加し、完全なアラーム詳細、更新されたメトリクス、緊急性の文脈を含めます。重複がない場合、システムはシナリオに応じたコンテンツで新しいサポートケースを作成します。これは、使用量が検証された詳細を含むクォータ増量リクエストか、クォータ詳細を含まないサービス調査リクエストのいずれかです。

本システムはアラームを 2 つのカテゴリに分類し、適切な対応を決定します。

クォータ関連のアラーム は、「クォータリクエスト」サポートケースをトリガーし、使用量が検証されたコンテンツを含みます：

• RPM 固有のアラーム（HighInvocationRate、InvocationAnomaly）は、RPM クォータの増額のみを要求します。

• TPM 固有のアラーム（HighTPMQuotaUsage、InputTokenAnomaly、OutputTokenAnomaly）は、TPM クォータの増額のみを要求します。

• 原因不明のクォータアラーム（Throttles、ClientErrors）は、RPM と TPM の両方のクォータ増額を要求し、どの制限に達したかを特定するためのコンテキストを提供します。

クォータ関連以外のアラーム（ServerErrors、HighLatency、LatencyAnomaly）は、「調査依頼」サポートケースをトリガーし、アラームのコンテキストと使用状況情報を提供します。