はじめに
Amazon Bedrock AgentCore でエージェントを運用していると、標準出力のログは CloudWatch Logs に、トレース(スパン)はaws/spansという別のロググループに、と分かれて配信されていて「同じエージェントの話なのに行ったり来たりして見づらいな」と感じたことがある方は多いのでないでしょうか。
2026年7月のアップデートで、この 2 つが 1 つのロググループへまとまるようになりました。
本記事では、AgentCore CLI と Amazon Nova 2 Lite で実際にエージェントをデプロイし、ログとトレースが本当に 1 箇所にまとまっているかを CloudWatch Logs で確認してみます。
忙しい人のための要約
- AgentCore Runtime のログ・トレース(スパン)・標準出力が、エージェントごとの単一の CloudWatch ロググループ
/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>にまとまるようになった - 2026年7月20日以降に新規作成したエージェントはデフォルトで有効。既存エージェントは
UNIFIED_TRACES_DESTINATION_ENABLED=trueを設定すれば移行できる
統合オブザーバビリティとは
これまで AgentCore Runtime で動くエージェントのテレメトリは、次のように送り先が分かれていました。
今回のアップデートで、スパンの送り先をエージェントごとのロググループ(/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>)に変更できるようになったという話です。
やってみた
検証環境
- AgentCore CLI(
@aws/agentcore) - Strands Agents
- Amazon Nova 2 Lite(
jp.amazon.nova-2-lite-v1:0)
エージェントプロジェクトの作成
npm install -g @aws/agentcore
agentcore create --name ObsDemo --framework Strands --protocol HTTP --model-provider Bedrock --memory none --build CodeZip
モデルはデフォルトだと Claude Sonnet になっているので、app/ObsDemo/model/load.py を書き換えて Nova 2 Lite にします。
from strands.models.bedrock import BedrockModel
def load_model() -> BedrockModel:
return BedrockModel(model_id="jp.amazon.nova-2-lite-v1:0")
デプロイ先は agentcore/aws-targets.json に自分で書く必要があります。
[
{
"name": "default",
"account": "123456789012",
"region": "ap-northeast-1"
}
]
CloudWatch Transaction Search の有効化
スパンをエージェント専用ロググループに配信するには、あらかじめ CloudWatch Transaction Search を有効にしておく必要があります。未設定だと、後述の spans ストリームにデータが来ません。
aws xray update-trace-segment-destination --destination CloudWatchLogs
デプロイと呼び出し
cd ObsDemo
agentcore deploy -y
agentcore invoke "こんにちは、あなたは何のモデルですか？一言で答えてください"
ロググループの中身を確認
デプロイ時に払い出された Runtime ID(ObsDemo_ObsDemo-xxxxxxxxxx)を使って、ロググループのストリーム一覧を見てみます。
aws logs describe-log-streams \
--log-group-name "/aws/bedrock-agentcore/runtimes/ObsDemo_ObsDemo-xxxxxxxxxx-DEFAULT" \
--region ap-northeast-1
runtime-logs-<session-id>... ← アプリの標準出力
otel-rt-logs ← OpenTelemetryの構造化ログ
spans ← トレース(スパン)
同じロググループの中に、アプリの標準出力・OTELログ・スパン の3種類のストリームが同居していました。
spansストリームの中身を覗くと、traceIdやspanId、gen_ai.user.messageといった OpenTelemetry の GenAI セマンティック規約に沿ったスパンが記録されていて、確かにトレースがここに来ていることが確認できます。
既存エージェント
2026年7月20日より前に作成したエージェントは、リージョンが対応していても引き続き共有のaws/spansがデフォルト送信先のままです。
移行するには実行ロールにlogs:PutResourcePolicyを付与したうえで、UNIFIED_TRACES_DESTINATION_ENABLED=trueを環境変数に設定します
まとめ
エージェントごとにログとトレースが 1 つのロググループにまとまったことで、CloudWatch Logs Insights で両方を横断して追いかけやすくなりそうです。
既存エージェントで何かしらの分析を既に行っている場合は、移行のタイミングを検討する必要がありそうです。