Amazon BedrockでOpenAI互換APIやAnthropic互換APIを使うチームにとって、2026年6月1日のAWS What’s Newで発表されたbedrock-mantleエンドポイント向けCloudWatchメトリクスは、早めに確認しておきたい更新です。
この更新は、単に「CloudWatchで見える項目が増えた」という話ではありません。既存のAmazon Bedrock Runtime向けダッシュボードを持っているチームほど、AWS/BedrockとAWS/BedrockMantleを分けて見ないと、本番トラフィックを見落とす可能性があります。
この記事では、bedrock-mantleを通るResponses API、Chat Completions API、Anthropic Messages APIの監視で、どのメトリクスをどの粒度で見るべきかを整理します。日本のAWS利用者に関係する東京リージョンの確認点も含めます。
Amazon Watch JapanはAmazon.com, Inc.、Amazon Web Services, Inc.、OpenAI、Anthropicおよび各関係会社と提携していない独立サイトです。この記事は製品・サービス更新の確認を目的としており、投資助言ではありません。
3行まとめ
`bedrock-mantle`向けメトリクスは、CloudWatchの`AWS/BedrockMantle`名前空間で確認します。
Responses API、Chat Completions API、Anthropic Messages APIを通る推論が対象です。
推論回数、クライアントエラー、入力・出力トークンを、Account、Project、Model、Project+Modelで分けて見ます。
既存の`AWS/Bedrock`監視とは、名前空間と対象APIを分けて確認します。
- Amazon Bedrockの
bedrock-mantleエンドポイント向けCloudWatchメトリクスは、AWS/BedrockMantle名前空間に出ます。既存のAWS/Bedrockダッシュボードやアラームには自動では混ざりません。 - 対象は
bedrock-mantle経由のResponses API、Chat Completions API、Anthropic Messages APIです。bedrock-runtime経由のConverseやInvokeModelは従来のRuntimeメトリクスを見る必要があります。 - 本番監視では、
Inferences、InferenceClientErrors、TotalInputTokens、TotalOutputTokensに加え、Project+Model粒度のInputTokensとOutputTokensを使い、費用配賦、異常検知、モデル別の利用傾向を分けて確認します。
今回の確認日は2026年6月3日 Asia/Tokyoです。リージョン、メトリクス名、ディメンション、対応APIはAWS公式情報を基準にしています。
何が追加されたのか
- 1bedrock-mantleエンドポイント
OpenAI互換APIやAnthropic Messages APIに近い形で、Bedrock上のモデル利用へ接続します。
- 2対象API
Responses API、Chat Completions API、Messages APIを通じた推論を確認します。
- 3CloudWatchメトリクス
推論回数、入力・出力トークン、クライアントエラーを`AWS/BedrockMantle`で見ます。
- 4運用判断
本番監視、費用配賦、アラーム設計の入口として使います。
Bedrock全体ではなく、`bedrock-mantle`を通る互換APIの監視として読むのが重要です。
AWSは2026年6月1日、Amazon Bedrockのbedrock-mantleエンドポイントに対して、Amazon CloudWatchメトリクスを追加したと発表しました。発表の中心は、OpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages APIをBedrock上で使うアプリケーションについて、推論回数、入力・出力トークン数、クライアントエラー数をCloudWatchで監視できるようになった点です。
ここで大切なのは、対象がBedrock全体ではなく、bedrock-mantleエンドポイントを通る互換APIである点です。すでにBedrock Runtimeの監視を作っているチームでも、bedrock-mantleを使い始めたら、同じダッシュボードに自然に載るとは考えない方が安全です。
対象はOpenAI互換APIとAnthropic Messages API
Amazon Bedrockのドキュメントでは、bedrock-mantleエンドポイントがResponses API、Chat Completions API、Messages APIを扱うと整理されています。Responses APIは状態を持つ会話やエージェント型アプリケーションに向き、Chat Completionsは履歴管理をアプリケーション側で行う軽量なチャット用途に向きます。Messages APIはAnthropicのMessages形式で扱うための入口です。
つまり、OpenAI SDKやAnthropic SDKに近い形で既存アプリケーションをAWS側へ寄せる場合、bedrock-mantleは移行の入口になりやすいサービス面です。その入口にCloudWatchメトリクスが出るようになったことは、本番監視、費用配賦、アラーム設計の前提が一段整ったことを意味します。
根拠
AWS What’s Newは、bedrock-mantleエンドポイントがOpenAI Responses API、OpenAI Chat Completions API、Anthropic Messages APIをサポートすると説明しています。BedrockのAPI対応ドキュメントでも、bedrock-mantleとbedrock-runtimeで使うAPIのまとまりが分けられています。
ただし、すべてのモデルがすべてのAPIを同じ条件で使えるという意味ではありません。モデルごとの対応API、リージョン、利用条件は、Bedrockのモデル対応表や個別ドキュメントで確認する必要があります。
名前空間はAWS/BedrockMantle
今回のメトリクスはCloudWatchのAWS/BedrockMantle名前空間に発行されます。Bedrock Runtime向けのAWS/Bedrockとは別です。
ここを取り違えると、監視の空白が生まれます。たとえば、既存のBedrock RuntimeダッシュボードでInvocationsやInvocationLatencyを見ていても、bedrock-mantle経由のResponses APIトラフィックはそこに自動では入りません。アラームも同じで、既存のAWS/Bedrock名前空間だけを見ていると、bedrock-mantleの4xx増加やトークン消費増を拾えない可能性があります。
注意点
「Bedrockを使っているからCloudWatchで見えているはず」と考えず、アプリケーションがどちらのエンドポイントを呼んでいるかを先に分けてください。bedrock-runtime.<region>.amazonaws.comを呼ぶアプリケーションと、bedrock-mantle.<region>.api.awsを呼ぶアプリケーションでは、見る名前空間が違います。
AWS/BedrockMantleで見る主要メトリクス
CloudWatchメトリクスは請求明細そのものではないため、費用を見るときは価格、リージョン、契約条件、実際の請求項目と合わせて確認します。
AWS/BedrockMantleでまず見るべきメトリクスは、推論回数、クライアントエラー、入力トークン、出力トークンです。ここは、生成AIアプリの本番監視で最初に知りたい「呼ばれているか」「失敗していないか」「どれくらい使われているか」に直結します。
一方で、CloudWatchメトリクスは請求明細そのものではありません。トークン量は費用の入口になりますが、モデル別価格、リージョン、契約条件、割引、コミットメント、実際の請求項目と合わせて確認する必要があります。
推論回数とクライアントエラー
Inferencesは、Responses API、Chat Completions API、Messages APIを通じて完了した推論リクエスト数を見るメトリクスです。まずはアプリケーションのリリースやトラフィック増減と照合し、期待どおりに増減しているかを見ます。
InferenceClientErrorsは、4xx系のクライアント側エラーとして失敗した推論リクエストを確認するためのメトリクスです。APIキー、認証、モデルID、リクエスト形式、Projectの扱い、クォータ前提などを変更した直後は、ここが上がっていないかを見たいところです。
確認項目
本番リリース後は、まずAccount粒度でInferencesが想定どおり出ているかを確認します。次にProjectやModelの粒度へ降り、どのアプリケーション、どのモデルでエラーが増えているかを見ます。
InferenceClientErrorsは「すべての障害」を表すメトリクスではありません。サーバー側エラー、スロットリング、アプリケーション側のタイムアウト、ネットワーク問題、ユーザー体験としての失敗は、アプリケーションログ、分散トレース、CloudTrail、クライアント側のリトライ状況と合わせて確認します。
入力・出力トークンを見る
トークン関連では、TotalInputTokens、TotalOutputTokens、InputTokens、OutputTokensを分けて見ます。
TotalInputTokensとTotalOutputTokensは、一定の発行間隔内で処理された入力・出力の請求対象トークン量を集計するメトリクスです。Account、Project、Modelの粒度で出るため、全体の使用量、チーム別の使用量、モデル別の使用量をつかむ入口になります。
InputTokensとOutputTokensは、1回の完了した推論ごとの入力・出力トークン数を見るためのメトリクスです。AWSドキュメントではProject+Model粒度のみで発行され、p50、p90、p99などの分布確認に使うものとして説明されています。
注意点
平均値だけを見ると、大きなプロンプトや長い出力を伴う一部のリクエストを見落としやすくなります。RAG、コード生成、長文要約、マルチターンのエージェント処理では、少数の重いリクエストが費用と遅延の両方に効くことがあります。
そのため、全体のTotalInputTokensとTotalOutputTokensで増減を把握し、Project+Model粒度のInputTokensとOutputTokensで分布を見る、という二段構えが現実的です。FinOps担当は、ここにモデル価格、利用部門、社内Projectの命名、タグや請求データを合わせると、費用説明の精度を上げやすくなります。
ProjectとModelの粒度をどう使うか
Projectは社内タグや請求タグそのものではなく、費用配賦や責任分界を考える入口として扱います。
bedrock-mantleのCloudWatchメトリクスは、Account、Project、Model、Project+Modelの粒度で考えます。すべてを一つのグラフに入れるのではなく、目的に応じて粒度を変えることが重要です。
特にProjectディメンションは、bedrock-runtimeメトリクスとの差分として見逃せません。BedrockのOpenAI互換APIを複数チームや複数アプリケーションで使う場合、Project単位の見え方は、費用配賦や責任分界の入口になります。
Account粒度は全体の異常検知に向く
Account粒度は、まず全体の利用量、エラー率、トークン量を見るための場所です。リリース直後に推論回数がゼロのままなら、アプリケーションが実際にはbedrock-mantleを呼んでいないか、CloudWatchのリージョンを見間違えている可能性があります。
また、想定外の急増があった場合もAccount粒度は入口になります。たとえば、あるバッチ処理がプロンプトを増やした、チャットUIのリトライが増えた、テスト環境が本番Projectを使ってしまった、といった問題は、まず全体の山として見えることがあります。
評価基準
Account粒度は「何か起きているか」を見る場所です。費用の責任分解やモデルごとの最適化をAccount粒度だけで済ませない方がよいです。AWSドキュメントも、Account level metricsは高レベルのダッシュボードやアカウント全体アラームには向くが、モデルごとに価格が異なるためコスト分析には向かないと説明しています。
Project粒度はチーム別の見方に向く
Project粒度は、チーム別、アプリ別、用途別に利用量を見たいときに効きます。たとえば、社内検索、開発者支援、カスタマーサポート要約、営業資料生成を別Projectに分けていれば、どの用途がトークンを使っているかを比較できます。
ただし、ProjectはAWSタグやCost Allocation Tagと同じものではありません。CloudWatchメトリクス上のProject粒度は、あくまでbedrock-mantleの呼び出しをProject単位で見るための手掛かりです。実際の社内費用配賦では、請求データ、タグ、アカウント分割、組織上の責任者と合わせて読みます。
確認項目
運用開始前に、Projectの命名規則を決めておくと後から楽になります。環境、部門、アプリケーション、用途、データ分類をどこまでProject名や説明に入れるのかを決めておくと、CloudWatch上のグラフを見たときに説明しやすくなります。
Model粒度は移行と比較に向く
Model粒度は、どのモデルがどれくらい使われているかを見るための入口です。OpenAI互換APIやAnthropic Messages APIを使う場合、アプリケーション側のコードは似た形でも、モデルごとの価格、出力傾向、トークン消費、エラーの出方は違います。
既存のbedrock-runtime監視でModelIdを見ていたチームは、bedrock-mantle側でもModel粒度を使うことで、移行後のモデル別使用量を追いやすくなります。名前空間とメトリクス名は違いますが、「どのモデルが増えたか」を見る発想は引き継げます。
注意点
Model粒度だけでは、どのProjectがそのモデルを使っているかまでは切り分けにくくなります。複数チームが同じモデルを使う場合は、Project+Model粒度で見た方が、費用や異常の説明がしやすくなります。
Project+Model粒度は費用と分布の中心になる
Project+Model粒度は、ProjectとModelを同時に見たいときの主戦場です。費用分析、トークン分布、モデル別の重いリクエスト、特定Projectだけの異常を追うときは、この粒度が中心になります。
たとえば、同じチャット機能でも、社内向けProjectは短い回答が中心で、顧客向けProjectは長文の説明を返すかもしれません。同じモデルでもProjectごとに使い方が違えば、平均出力トークンやp90、p99の出方は変わります。
評価基準
Project+Model粒度では、InputTokensとOutputTokensの分布を見ると判断しやすくなります。p50だけでなく、p90やp99を確認し、少数の重いリクエストが費用や体感品質に与える影響を見ます。
bedrock-runtime監視との差分
名前空間とAPI経路が違うため、同じBedrockという理由だけでアラームやダッシュボードを共有しないことが大切です。
今回の更新で混乱しやすいのは、bedrock-mantleとbedrock-runtimeの監視が似ているようで違う点です。既存のBedrock Runtime監視を持っているほど、「同じBedrockだから同じ名前空間に出るだろう」と考えがちですが、AWSドキュメントでは明確に分けられています。
名前とメトリクス名が違う
bedrock-runtimeのCloudWatchメトリクスはAWS/Bedrock名前空間に出ます。Converse、ConverseStream、InvokeModel、InvokeModelWithResponseStreamなどのRuntime APIを使う場合はこちらを見ます。
一方、bedrock-mantleのメトリクスはAWS/BedrockMantleです。メトリクス名も、Runtime側のInvocationsではなくInferences、InvocationClientErrorsではなくInferenceClientErrors、InputTokenCountやOutputTokenCountではなくTotalInputTokensやTotalOutputTokensという形で整理されています。
確認項目
既存ダッシュボードを移植するときは、名前空間とメトリクス名を機械的に置き換えるだけで済ませない方がよいです。粒度、ディメンション、扱えるメトリクス、未提供の項目が違うため、グラフごとに目的を見直します。
Latency系メトリクスはまだ同じようには見ない
2026年6月3日確認時点のAWSドキュメントでは、bedrock-mantleにはInvocationLatencyやTimeToFirstToken相当のメトリクスはまだ公開されていないと説明されています。
これは、本番監視で無視できない差分です。推論回数、4xx、トークン量はCloudWatchで見やすくなりましたが、ユーザー体験に直結するレイテンシー、ストリーミングの初回トークン到達時間、アプリケーション全体の待ち時間は、アプリケーション側のログやトレース、カスタムメトリクスと組み合わせる必要があります。
注意点
「CloudWatchメトリクスが追加されたので本番監視は完成」とは考えない方がよいです。bedrock-mantleの公式メトリクスは、推論量、トークン量、クライアントエラーを確認する強い入口です。ユーザー体験、リトライ、タイムアウト、UI上の失敗、処理全体の遅延は、アプリケーションの観測設計として別に持ちます。
cross-region inference前提と混ぜない
AWSドキュメントでは、bedrock-mantleはin-regionで扱われ、メトリクスはリクエストを処理したリージョンに出ると説明されています。Bedrock Runtime側のcross-region inferenceの集計前提とは混ぜないようにします。
日本のチームが東京リージョンでbedrock-mantleを使う場合、CloudWatchも東京リージョンで確認するのが基本です。グローバルなダッシュボードを作るなら、リージョンごとに出るメトリクスをどう集約するかを別途決めます。
東京リージョンで使うときの確認
東京リージョンでは`https://bedrock-mantle.ap-northeast-1.api.aws/v1`を指しているか確認します。
CloudWatchコンソールでAsia Pacific (Tokyo)を選び、`AWS/BedrockMantle`名前空間を見ます。
呼び出し先、AWSアカウント、リージョン、Project、Model、アラーム、リリース後に見る時間帯を残します。
`store`が`true`の場合の保持、`false`の場合の扱いを、監視とは別の論点として確認します。
トークンメトリクスで利用量が見えることと、レスポンス保存の扱いは別の確認項目です。
AWS What’s NewとBedrockドキュメントでは、bedrock-mantleエンドポイントおよびCloudWatchメトリクスの提供地域にAsia Pacific (Tokyo)が含まれています。東京リージョンのエンドポイントはbedrock-mantle.ap-northeast-1.api.awsです。
日本の利用者にとって、東京リージョンで確認できることは大きな意味があります。社内規定、データ所在地、ネットワーク遅延、監査ログ、運用担当のCloudWatch確認手順が、東京リージョン前提で組まれているケースが多いからです。
エンドポイントとCloudWatchリージョンを合わせる
まず、アプリケーションのOPENAI_BASE_URLやSDK設定が、どのリージョンのbedrock-mantleエンドポイントを指しているかを確認します。東京リージョンならhttps://bedrock-mantle.ap-northeast-1.api.aws/v1の形です。
次に、CloudWatchコンソールで同じリージョンを選び、AWS/BedrockMantle名前空間を確認します。米国東部やオレゴンを見ていると、東京で処理されたメトリクスを見落とします。
確認項目
社内のRunbookには、次のような最低限の確認先を残しておくとよいです。呼び出し先エンドポイント、AWSアカウント、リージョン、CloudWatch名前空間、対象Project、対象Model、想定するアラーム、リリース後に見る時間帯です。
Responses APIの保存挙動も一緒に見る
Responses APIを使う場合は、CloudWatchメトリクスだけではなく、状態保存の挙動も確認しておきます。AWSドキュメントでは、Responses APIのstoreがtrueの場合、入力と出力を含むレスポンスがリクエスト元リージョンに30日間保持され、storeをfalseにすると保持しないと説明されています。
これはメトリクスそのものではありませんが、本番導入前に同じタイミングで確認すべき重要な運用条件です。特に、個人情報、機密情報、顧客データ、社内ソースコード、規制対象データを扱う可能性があるアプリケーションでは、storeの扱いをアプリケーション設定とレビュー手順に入れてください。
注意点
トークンメトリクスで利用量が見えることと、レスポンス保存の扱いは別の論点です。監視チーム、セキュリティチーム、アプリケーションチームがそれぞれ別々に見ていると抜けやすいため、bedrock-mantle導入チェックリストにまとめて入れるのが現実的です。
本番導入前のチェックリスト
- 1疎通を見る
Account粒度の`Inferences`で、リリース後に推論回数が想定どおり出ているか確認します。
- 2失敗を見る
`InferenceClientErrors`で、認証、モデルID、リクエスト形式、Project変更後の4xx系エラーを見ます。
- 3費用の入口を見る
Project、Model、Project+Modelでトークン量を分け、増減を説明できる状態にします。
- 4アラームを分ける
Account全体、Project別、Model別、Project+Model別のトークン分布を分けて設計します。
- 5アプリ側計測を足す
Latency、サーバー側エラー、タイムアウト、リトライ、ユーザー体験上の失敗はアプリケーション側の計測と合わせます。
CloudWatchだけで全障害を説明しようとせず、ログ、トレース、CloudTrail、クライアント側のリトライ状況と合わせて見ます。
bedrock-mantle向けCloudWatchメトリクスは、本番投入前後の確認手順に組み込みやすい更新です。最初から完璧なダッシュボードを作るより、推論が見えているか、失敗が増えていないか、トークン量を説明できるかを順番に確認する方が失敗しにくくなります。
リリース直後に見るもの
リリース直後は、Account粒度のInferencesでトラフィックが出ているかを見ます。続いてInferenceClientErrorsを見て、4xx系の失敗が増えていないかを確認します。
想定どおりにメトリクスが出ていない場合は、アプリケーションがbedrock-mantleではなくbedrock-runtimeや別の外部APIを呼んでいないか、CloudWatchのリージョンを見間違えていないか、AWSアカウントを取り違えていないかを確認します。
確認項目
リリース直後のRunbookには、少なくとも次の項目を入れたいところです。呼び出し成功率、4xxの増減、入力・出力トークンの急増、Project別の偏り、Model別の偏り、想定外Projectからの呼び出し、テスト環境の本番Project利用です。
費用配賦で見るもの
費用配賦では、ProjectとModelを分けて見ることが重要です。Projectだけではモデルごとの価格差を説明しにくく、Modelだけではどのチームやアプリが使ったのかを説明しにくくなります。
そのため、Project+Model粒度を中心に、TotalInputTokens、TotalOutputTokens、InputTokens、OutputTokensを組み合わせて見ます。CloudWatchは入口であり、最終的な請求分析ではAWSの請求データ、価格ページ、契約条件、社内のアカウント設計を合わせます。
評価基準
良いダッシュボードは、単に合計トークン数を出すだけではありません。どのProjectがどのModelを使い、どのProjectでp90やp99のトークン量が大きく、どの変更以降に増えたのかを説明できる形にします。
アラームで見るもの
最初に作るアラームは、少数で構いません。Account全体のInferenceClientErrors急増、特定Projectの急激なTotalInputTokens増加、重要Project+ModelのOutputTokens分布の変化など、行動に結びつくものを選びます。
アラームは鳴らすだけでは意味がありません。誰が確認し、どのログを見て、どのProject ownerに連絡し、どのリリースを戻すのかまでRunbookに入れておく必要があります。
注意点
トークン量の急増は、必ずしも障害ではありません。新機能のリリース、キャンペーン、バッチ処理、ユーザー増、長文入力の増加でも起きます。アラームの文面は障害と決めつけず、確認すべきProject、Model、リリース、プロンプト変更を示す方が運用しやすくなります。
読者タイプ別の見方
担当ごとの見方は優劣ではなく、同じメトリクスを別の判断に使うための分担です。
今回の更新は、開発者、SRE、FinOps、セキュリティ担当で見るポイントが少し違います。全員が同じダッシュボードを見るより、共通の名前空間と粒度を理解したうえで、それぞれの判断に必要な形へ分けるのがよいです。
開発者はAPI経路とProjectを確認する
開発者は、まずアプリケーションがどのAPI経路を使っているかを確認します。Responses APIなのか、Chat Completionsなのか、Anthropic Messages APIなのか。bedrock-mantleを使っているのか、従来のbedrock-runtimeを使っているのか。ここを曖昧にしたままでは、監視も費用説明もずれます。
次に、Projectの分け方を確認します。開発、検証、本番でProjectを分けているか。機能ごとにProjectを分けているか。複数チームが同じProjectを使っていないか。あとからCloudWatchで見たときに、責任範囲が説明できるかが大切です。
SREは名前空間とアラームの空白を見る
SREやプラットフォームチームは、既存のAWS/Bedrock監視に空白がないかを見ます。Bedrock Runtimeのアラームはあるが、AWS/BedrockMantleがない場合、OpenAI互換APIやAnthropic互換APIのトラフィックは別途監視が必要です。
また、Latency系の公式メトリクスがまだ同じようには出ていない点も重要です。アプリケーション側でリクエスト開始時刻、レスポンス完了時刻、ストリーム開始時刻、リトライ回数、タイムアウトを記録しているかを確認します。
FinOpsはProject+Modelを中心に見る
FinOps担当は、合計トークンだけではなくProject+Model粒度を重視します。モデルごとに価格が違うため、Account粒度のトークン総量だけでは費用説明に限界があります。
Project+Model粒度で見ると、どのProjectがどのModelを使い、どの用途で入力が重く、どの用途で出力が長いのかが見えてきます。ここに請求データと社内の責任分解を合わせると、費用削減の議論も「生成AIが高い」という抽象論から、「このProjectのこのModelのこの用途を見直す」という具体論に変わります。
セキュリティ担当は保存とアクセス権を見る
セキュリティ担当は、CloudWatchメトリクスだけでなく、Responses APIの保存挙動、Projectの分け方、CloudWatchを見られる権限、Bedrock APIキーやAWS認証の扱いを確認します。
メトリクスは利用量とエラーを示しますが、入力内容そのものの妥当性を保証するものではありません。機密データの投入制御、ログに残す内容、保存を許すかどうか、データ分類ごとの利用可否を、アプリケーション設計と合わせて見ます。
2026年6月のBedrock更新として追うポイント
- 互換APIの利用経路を確認
OpenAI互換APIやAnthropic Messages APIを、どのアプリケーションが`bedrock-mantle`経由で使うのかを整理します。
- CloudWatchメトリクス追加を確認
2026年6月1日の更新として、`AWS/BedrockMantle`で推論回数、エラー、トークン量を見ます。
- 関連するBedrock更新と合わせる
モデル提供開始や一般提供のニュースと並べて、本番運用に必要な監視条件を確認します。
- 一次情報を見に行く
AWS What’s New、Bedrock User Guide、CloudWatchメトリクス一覧の順に、名称、リージョン、ディメンションを確認します。
今回の更新は、Bedrockを本番運用に近づけるための監視・費用説明の材料として追うと判断しやすくなります。
今回のCloudWatchメトリクス追加は、6月のBedrock関連トピックの中では「本番運用に近づけるための更新」として見たいものです。モデル追加や一般提供のニュースは注目を集めやすいですが、実際に企業が使う段階では、監視、費用配賦、権限、ログ、データ保持の方が導入判断に効きます。
Amazon Watch Japanでは、6月のAmazon/AWS関連トピックを<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>に集約しています。今回のようなBedrockの運用系更新も、モデル提供開始やイベント発表と同じ月次の流れで追うと、判断材料を見落としにくくなります。
OpenAI on Bedrockの一般提供記事と合わせて読む
2026年6月1日のOpenAIモデルとCodexのBedrock一般提供については、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-14-openai-codex-bedrock-ga/">OpenAI GPT-5.5/5.4とCodexがAmazon Bedrockで一般提供</a>で整理しています。そちらは、モデル、Codex、Responses API、料金確認、リージョン確認の入口です。
今回の記事は、その次の段階として、bedrock-mantleを本番で呼び始めた後に何を見るかを扱います。モデルを使えることと、運用できることは別です。導入チームは、両方をセットで確認してください。
Anthropic系の使い分けともつながる
AnthropicモデルをAWSで使う読者は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-15-claude-opus-48-aws-bedrock-platform/">Claude Opus 4.8がAWSで提供開始</a>の記事も合わせて見ると、BedrockとClaude Platform on AWSの使い分けを確認できます。
bedrock-mantleのCloudWatchメトリクスは、Anthropic Messages APIも対象に含みます。ただし、AnthropicモデルをどのAPIで呼ぶか、どのリージョンで使うか、どのモデルがどのAPIに対応するかは、個別の公式ドキュメントで確認が必要です。
一次情報を見に行く順番
読者が自分の環境で再確認するときは、まずAWS What’s Newで発表日と対象を確認し、次にBedrockのCloudWatchメトリクスドキュメントで名前空間、メトリクス名、ディメンションを確認します。そのうえで、API対応ドキュメント、Responses APIドキュメント、Bedrock Runtimeメトリクスとの差分を照合します。
Amazon Watch Japanの<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/">資料・確認ログ</a>も、公式ページへ戻る入口として使えます。記事を読んだあとに、必ず自分のAWSアカウント、リージョン、Project、Model、実際のリクエスト設定で確認してください。
読了後にAmazon/AWSの公式発表やサービス更新の通知を受け取りたい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>で月次まとめや重要トピックの更新を追えます。本文の判断材料を置き換えるものではなく、一次情報を見に行くきっかけとして使ってください。
次に読むなら
参照した主な情報源
確認日: 2026年6月3日 Asia/Tokyo。
- AWS: Amazon Bedrock adds Amazon CloudWatch metrics for OpenAI- and Anthropic-compatible APIs
https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-supports-cloudwatch-metrics-bedrock-mantle-endpoint/
- Amazon Bedrock User Guide: Monitor
bedrock-mantleinference using CloudWatch metrics
https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-mantle-metrics.html
- Amazon Bedrock User Guide: APIs supported by Amazon Bedrock
https://docs.aws.amazon.com/bedrock/latest/userguide/apis.html
- Amazon Bedrock User Guide: Inference using Responses API
https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-mantle.html
- Amazon Bedrock User Guide: Monitor
bedrock-runtimeinference using CloudWatch metrics
https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-runtime-metrics.html