Bedrock Invocation LogsとCloudWatch Logs InsightsでBedrock Agentの呼び出しログを覗いてみた

こんにちは、ゲームソリューション部のsoraです。
今回は、Bedrock Invocation LogsとCloudWatch Logs InsightsでBedrock Agentベースのキャラクターチャットアプリの呼び出しログを覗いてみました。

Bedrock Invocation Logsとは

Bedrockのモデル呼び出しに対して、プロンプト本文・モデル応答・トークン数・EmbeddingベクトルといったデータプレーンをまるごとS3やCloudWatch Logsに記録できるマネージド機能です。
CloudTrailで取れる「いつ・誰がAPIを呼んだか」では見えない、「何を投げて何が返ったか」を直接記録できるのが特徴です。
有効化はBedrockのアカウント設定から行うため、アプリ側のコード変更は不要です。

コンソールでInvocation Logsを有効化する

Bedrockコンソールにて、設定 → モデル呼び出しのログ記録から有効化します。

ログに記録するデータタイプは、テキストと埋め込みをONにし、画像はOFFにしました。
ログ記録先はS3とCloudWatch Logsの両方を指定し、「大量のデータ配信のためのS3の場所」には同じバケット内のlarge-data/プレフィックスを指定しています。

保存先と100KB超の挙動

ログ記録先はS3のみ・CloudWatch Logsのみ・両方の3択ですが、それとは別に「大量のデータ配信のためのS3の場所」を指定できます。
100KB超のペイロードやバイナリは、ログ記録先ではなくこちらに個別オブジェクトとして格納される仕様です。

ペイロードサイズ別の挙動は以下のとおりです。

• 100KB以下：通常のログ記録先（S3 / CloudWatch Logs）に記録される
• 100KB超・バイナリ：通常のログ記録先には載らず、「大量のデータ配信のためのS3の場所」に個別オブジェクトとして格納される

ログ記録先を「両方」にしていても、100KB超のデータは「大量のデータ配信のためのS3の場所」を指定していないと取りこぼします。

動作確認

チャットを叩いてログを生成する

S3とCloudWatch Logsに実際にログが流れるかを確認するため、Flutterアプリから経路の異なる4つのリクエストを送りました。

• こんにちは：Foundation Modelで通常応答
• どこに住んでいるの？：Knowledge Bases検索（Agent経由）
• 自己紹介を声で聴かせて：Action Group speakAsOwner → Polly → S3 → presigned URL
• 好きな食べ物は？：Foundation Modelで通常応答

Bedrock側では合計7イベントとして記録されました。
Bedrock Agentの内部で、1リクエストが複数のモデル呼び出しに展開されるためです。

S3への記録を確認する

S3バケットを覗くと、以下の階層でgzip圧縮されたNDJSONが格納されていました。

AWSLogs/123456789012/BedrockModelInvocationLogs/ap-northeast-1/2026/05/05/09/
  20260505T090717458Z_xxxxxxxxxxxxxxxx.json.gz  (14,753 bytes)
  20260505T090837598Z_xxxxxxxxxxxxxxxx.json.gz  (5,709 bytes)

• 1ファイルに複数イベントをまとめてgzip圧縮（NDJSON、1行1イベント）
• large-data/配下は今回100KB超のペイロードが発生せず空でした

CloudWatch Logsへの記録を確認する

ロググループ/aws/bedrock/bedrock-chat-app-invocation-logs、ストリームaws/bedrock/modelinvocationsに、permission check 1件と実イベント7件で計8イベントが記録されていました。

Knowledge Bases Retrieve時のEmbeddingイベントだけが他の約8倍（44KB）あります。
output.outputBodyJson.embeddingにfloat配列のベクトルがそのまま入るため、テキストイベントよりサイズが膨らみます。

ログの中身を見る

こんにちはの通常応答（Converse）の例です。

{
  "timestamp": "2026-05-05T09:06:24Z",
  "operation": "Converse",
  "modelId": "arn:aws:bedrock:ap-northeast-1:123456789012:inference-profile/jp.anthropic.claude-haiku-4-5-20251001-v1:0",
  "input": {
    "inputTokenCount": 2375,
    "inputBodyJson": {
      "messages": [{"role": "user", "content": [{"text": "こんにちは"}]}],
      "system": [{"text": "# キャラ設定\nあなたは「ミケ」という名前の三毛猫です。..."}]
    }
  },
  "output": {
    "outputTokenCount": 82,
    "outputBodyJson": {
      "output": {
        "message": {
          "content": [{"text": "こんにちは、にゃ！ 私はミケだよ。三毛猫だよ😸..."}]
        }
      }
    }
  }
}

Embedding（InvokeModel / Titan Embed Text v2）の例です。

{
  "timestamp": "2026-05-05T09:06:35Z",
  "operation": "InvokeModel",
  "modelId": "arn:aws:bedrock:ap-northeast-1::foundation-model/amazon.titan-embed-text-v2:0",
  "input": {
    "inputTokenCount": 27,
    "inputBodyJson": { "inputText": "ミケはどこに住んでいるか、どこに暮らしているか" }
  },
  "output": {
    "outputBodyJson": {
      "embedding": [-0.00799, 0.01803, -0.01148]
    }
  }
}

プロンプト本文・応答本文・Embeddingベクトルといった呼び出しの中身まで、そのままの形で見えます。

CloudWatch Logs Insightsで分析する

ロググループ/aws/bedrock/bedrock-chat-app-invocation-logsに対して、トークン消費量を中心にいくつかクエリを叩いてみます。

CloudWatch Logs Insightsの便利な点は、JSONを自動的に平坦化してドット記法でクエリできることです。
input.inputBodyJson.messages.0.content.0.textのように、ネストしたフィールドを直接fields句やstats句に書けます。
output.outputBodyJson.metrics.latencyMsを集計すれば、応答時間のp95などもInsights単独で出せます。

全イベント一覧

fields @timestamp, operation, modelId, input.inputTokenCount, output.outputTokenCount
| sort @timestamp desc
| limit 50

トークン使用量の合計

stats sum(input.inputTokenCount) as totalInput,
      sum(output.outputTokenCount) as totalOutput,
      count(*) as invocations

invocationsの8件にはpermission checkが含まれており、トークンが計上されている実呼び出しは7件分です。
合計で約2万トークンの入力に対して出力は約600トークン、inputがoutputの30倍以上ある点が特徴的です。

オペレーション別

stats count(*) as cnt,
      sum(input.inputTokenCount) as inTok,
      sum(output.outputTokenCount) as outTok
by operation

InvokeModel（Titan Embed）はoutput.outputTokenCountが空です。
Embeddingモデルは出力がベクトルで、トークンの概念がないためです。

1呼び出しあたりのトークン統計

stats avg(input.inputTokenCount) as avgIn,
      max(input.inputTokenCount) as maxIn,
      min(input.inputTokenCount) as minIn,
      avg(output.outputTokenCount) as avgOut
by operation

最後に

今回は、Bedrock Invocation LogsとCloudWatch Logs InsightsでBedrock Agentベースのキャラクターチャットアプリの呼び出しログを覗いてみました。
この記事がどなたかの参考になれば幸いです。