ひとことで言うと
Bedrock 呼び出しの「数値」が着地する場所です。呼び出し数・レイテンシ・トークン数・スロットル数を AWS/Bedrock 名前空間のメトリクスとして自動公開しており、ダッシュボード化・アラーム化ができます。中身（プロンプトやレスポンス本文）は見ません。それは CloudWatch Logs の仕事です。
要するに、計器盤です。速度・回転数・燃料残量は出ますが、車内で誰が何を話したかは記録しません。「何を話したか」が要るなら Logs（ログ）に切り替える必要があります。
なぜ生まれたか
| Bedrock 運用で必要になること | CloudWatch 側の受け皿 |
|---|---|
| モデル呼び出しの成功・失敗・スロットルを数で追う | AWS/Bedrock 名前空間のメトリクス |
| ガードレールの介入率を追う | AWS/Bedrock/Guardrails 名前空間 |
| エージェントのモデル呼び出し・ツール呼び出しの内訳を追う | AWS/Bedrock/Agents 名前空間 |
| レイテンシ悪化が「モデルが遅い」のか「応答が長くなった」のかを切り分ける | TimeToFirstToken を使った OTPS（output tokens per second）計算 |
| エージェント全体のトレース・スパンを一元的に見る | AgentCore Observability の GenAI Observability ダッシュボード（CloudWatch 上） |
D4「運用効率と最適化」の 4.3（監視）と D5「テスト・検証・トラブルシュート」の 5.2（トラブルシュート）が、ほぼこのメトリクス群の読み方を問うています。
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| 呼び出し量・エラー率の常時監視 | Invocations / InvocationClientErrors / InvocationServerErrors をダッシュボード化 | D4 |
| スロットル検知 | InvocationThrottles（スロットルは Invocations にも Errors にもカウントされない点に注意） | D4, D5 |
| コスト・クォータの兆候把握 | InputTokenCount / OutputTokenCount / EstimatedTPMQuotaUsage | D4 |
| プロンプトキャッシュの効き具合 | CacheReadInputTokens（割引レート・TPM 対象外）／CacheWriteInputTokens（TPM 対象） | D4 |
| レイテンシ悪化の原因切り分け | OTPS = OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000 のメトリクス数式 | D5 |
| エージェントのボトルネック特定 | AWS/Bedrock/Agents の ModelLatency と TotalTime の差分 | D2, D5 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけ |
|---|---|---|
| 「呼び出しが遅い」だけの報告からアラームを組みたい | レイテンシ悪化の原因（サービス側かプロンプト長か）を切り分けたい → OTPS のメトリクス数式アラーム | InvocationLatency に単純な閾値アラームを張るだけ（プロンプトが長くなっただけでも誤検知する） |
| ガードレールの介入率を可視化したい | Guardrails 専用メトリクス → AWS/Bedrock/Guardrails 名前空間の InvocationsIntervened | AWS/Bedrock の Invocations を見る（介入は別名前空間） |
| 「スロットルされたリクエスト数を知りたいのに Invocations と合計しても合わない」 | スロットルは Invocations にも Errors にもカウントされない仕様 | 集計ミスと判断してコードを疑う |
| エージェントのどこで時間を食っているか特定したい | モデル呼び出し自体の時間 ModelLatency と、ツール呼び出し込みの全体時間 TotalTime の比較 | X-Ray を使わないと切り分けられないと誤解する（メトリクスだけでも粗い切り分けは可能） |
| プロンプトキャッシュのコスト効果を数値で示したい | CacheReadInputTokens と CacheWriteInputTokens を突き合わせる | InputTokenCount だけを見る（キャッシュ分が埋もれる） |
ストリーミングでないと TimeToFirstToken は出ません。ConverseStream / InvokeModelWithResponseStream 限定のメトリクスなので、同期 API（Converse / InvokeModel）だけを使っている構成では OTPS 計算そのものが組めません。「レイテンシの原因切り分けをしたい」というシナリオで、まずストリーミングを使っているかを確認する必要があります。
実務でどう使うか
- メトリクスのディメンションは
ModelIdが基本。 複数モデルを併用していると、集約された値だけを見て「遅い」「速い」を判断すると誤ります。モデルIDで分けて見る - OTPS のアラームは静的閾値と異常検知の2種類。 ベースラインが分かっているなら静的閾値（期待値の8割程度から開始）、負荷パターンが変動するなら異常検知（最低2週間分のデータが必要）を使う。新規デプロイでは異常検知はまだ使えないので静的閾値から始める
- Agents のメトリクスを受け取るには IAM ロールに
cloudwatch:PutMetricData（AWS/Bedrock/Agents名前空間限定）が要ります。 エージェント作成時のサービスロールにこの許可が無いと、メトリクス自体が飛んできません - AgentCore を使うなら「GenAI Observability」ダッシュボードが専用に用意されています。 ただし表示にはまず CloudWatch Transaction Search を有効化する一手間が要ります（既定では offです）
Guardrails の Latency と InvocationLatency は別物です。ApplyGuardrail API 呼び出し自体の InvocationLatency と、Automated Reasoning チェック用の Latency（InvokeAutomatedReasoningCheck）は指標も対象操作も異なります。同じ「レイテンシ」という語で片方だけ見ていると、もう一方の遅延を見落とします。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| CloudWatch Logs | CloudWatch（このページ）は数値。Logs は中身（プロンプト・レスポンス本文）。「介入した理由を知りたい」なら Logs 側が要る |
| CloudTrail | CloudWatch は「何が起きたか」の量。CloudTrail は「誰が」「いつ」「どの API を」の監査証跡。用途が違う |
| X-Ray | メトリクスは集約値。X-Ray はリクエスト単位のトレース（サービスをまたいだ時間の内訳）。エージェントの1リクエストがどこで詰まったかまで追うなら X-Ray |
| AgentCore Observability | AgentCore はエージェント専用の可観測性の仕組みで、内部的に CloudWatch（メトリクス・ログ）と X-Ray（トレース）の両方を使う。両者を代替するものではなく、その上に乗る専用ダッシュボード |
想起チェック
Q1. 「InvocationLatency が上がったが、原因がサービス側の劣化かプロンプトが長くなっただけか分からない」ときに見るべき指標は？
**OTPS（output tokens per second）**です。OutputTokenCount / (InvocationLatency - TimeToFirstToken) * 1000 で計算し、OTPS が安定していればレイテンシ増は出力トークン数の増加、OTPS が落ちていればサービス側の劣化と判断できます。ただしストリーミングAPIのみで計測可能です。
Q2. Guardrails の介入率を見たいとき、どの名前空間のどのメトリクスを見る？
**AWS/Bedrock/Guardrails 名前空間の InvocationsIntervened**です。AWS/Bedrock（モデル呼び出し本体）とは別名前空間なので混同しないこと。
Q3. スロットルされたリクエストは Invocations の分母に入る？
入りません。 InvocationThrottles は独立したカウントで、Invocations にも Errors にもカウントされません。成功率を計算するときにこれを見落とすと、実際より高い成功率が出ます。