Bedrock AgentCoreのログが1エージェント1ロググループに統合 — 監査境界とIAMスコープをどう設計し直すか
Amazon Bedrock AgentCoreのログ・トレースが1エージェント1ロググループに統合されました(2026年7月23日発表)。命名規則・有効化条件を整理し、監査境界とIAMアクセス制御をエージェント単位で設計し直す判断を解説します。
- #Bedrock AgentCore
- #オブザーバビリティ
- #IAM
- #CloudWatch
- #生成AIエージェント
Amazon Bedrock AgentCoreで本番のAIエージェント基盤を運用する場合、監査やトラブルシュートのたびに複数のロググループを横断して調べる負担が課題になります。2026年7月23日、AWSはAgentCoreのテレメトリ（トレース・プロンプト・構造化ログ・標準出力）を、エージェントごとに1つのロググループへ統合する変更を発表しました。本記事は、この変更の内容を正確に整理したうえで、ロググループがエージェント単位になったことで可能になるIAMアクセス制御・監査境界の設計をどう見直すべきかを解説します。対象読者は、AgentCoreでマルチテナントまたはマルチプロジェクトの本番エージェントを構築・運用する層です。
何が変わったか — テレメトリが1エージェント1ロググループに統合
変更前、AgentCoreのテレメトリは分散していました。トレーススパンは全エージェント共有のaws/spansロググループに送られる一方、プロンプトや入出力を含むイベントログなどはリソースごとの別ロググループに記録されていました。監査や障害調査の際は、この複数のロググループを横断して突き合わせる必要がありました。
変更後は、エージェントごとに/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>という命名規則のロググループ1つに、トレーススパン・構造化ログ・標準出力がまとめて記録されます。対応リージョンで2026年7月20日以降に作成された新規エージェントは、追加設定なしでこの統合ロググループがデフォルトの送信先になります。既存エージェントは自動的には切り替わらず、エージェントランタイムの環境変数UNIFIED_TRACES_DESTINATION_ENABLEDをtrueに設定することでオプトインできます（逆にfalseにすると共有ロググループに戻せます）。対象リージョンはAgentCoreランタイムが利用可能な全商用リージョンです。なお、公式発表・公式ドキュメントのいずれにも本機能自体への追加料金の記載はなく、記録先はCloudWatch Logsの通常料金が適用される前提です。
なぜロググループの分散が本番運用の障害だったのか
ロググループが分散していると、2つの実務上の課題が生じます。第一に、障害調査です。あるエージェントの挙動を追うには、共有のaws/spansから該当エージェントのスパンを検索で絞り込み、さらに別ロググループのイベントログと時刻や識別子を突き合わせる必要がありました。第二に、権限設計です。共有ロググループへのアクセス権限は、性質上そのロググループを使う全エージェント分のテレメトリに及びます。特定のエージェントのログだけを見せたい、あるいは特定のエージェントのログだけを暗号化キーで分離したいといった要件を、ロググループ単位のIAMポリシーやリソースポリシーで素直に表現できませんでした。
ロググループがエージェント単位に分かれたことで、この2つの課題に対する解像度が上がります。次章では、この構造変化を活かしたIAM設計を具体的に見ていきます。
設計判断①：エージェント単位のIAMスコープでログアクセスを絞る
ロググループ名に<agent_id>-<endpoint_name>が含まれるため、CloudWatch LogsのIAMポリシーでロググループARNをエージェント単位に指定した許可・拒否を書けます。マルチテナントやマルチプロジェクトでAgentCoreを運用する場合、テナントごと・プロジェクトごとのIAMロールに、対応するロググループのARNだけをResourceに列挙するポリシーを割り当てれば、閲覧できるログの範囲をエージェント単位に閉じ込められます。同様に、ロググループごとにカスタマー管理キー（CMK）による暗号化スコープを分けることも可能になります。
この仕組みを機能させるには、前提設定も必要です。公式ドキュメントによれば、AgentCoreがエージェント自身のロググループへスパンを配信するには、（1）アカウントでCloudWatch Transaction Searchを有効化しトレースセグメントの送信先をCloudWatch Logsにしていること、（2）エージェントの実行ロール（execution role）に対象ロググループへのlogs:PutResourcePolicy権限を付与し、AWS X-Rayがそのロググループへスパンを配信できるようにしていること、（3）エージェントがADOT（AWS Distro for OpenTelemetry）バージョン0.18.0以上を使用していること、の3点がそろっている必要があります。これらが欠けていると、環境変数を設定しても実質的に無効のまま、従来の共有ロググループに配信され続けます。
設計判断②：既存エージェントの移行手順と注意点
既存エージェントを統合ロググループへ移行する手順は、前章の3条件を満たしたうえで、対象エージェントのランタイムにUNIFIED_TRACES_DESTINATION_ENABLED=trueを設定することです。ここでの注意点は、この切り替えが遡及しないことです。公式ドキュメントは、送信先を変更しても既存のスパンデータは移動しないと明記しています。つまり切り替え前のログ・トレースは元のロググループに残ったままになるため、監査で過去分を参照する際はどちらのロググループを見るべきか（切り替え日時を基準に）を運用上明確にしておく必要があります。
もう一つの注意点は、3条件のうち1つでも欠けると移行が「見かけ上は設定したが実際は反映されない」状態になることです。特にADOTのバージョンは、エージェントのコンテナイメージやランタイム依存関係を個別に更新しないと上がらないため、環境変数だけ設定して満足してしまう移行漏れが起きやすいところです。マルチテナントで多数のエージェントを一括移行する場合は、環境変数の設定状況だけでなく、ADOTバージョンと実行ロールの権限もあわせてエージェントごとにチェックリスト化して確認することが実務上重要です。
まとめ
AgentCoreのテレメトリは2026年7月23日の発表により、エージェントごとの1ロググループ（/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name>）に統合されました。新規エージェントは対応リージョンでデフォルト有効、既存エージェントは環境変数の設定に加え、CloudWatch Transaction Searchの有効化・execution roleへの権限付与・ADOT 0.18.0以上へのアップグレードという3条件がそろって初めて機能します。ロググループがエージェント単位になったことで、IAMポリシーによるテナント単位・プロジェクト単位のログアクセス制御や暗号化スコープの分離がしやすくなる一方、切り替えは遡及せず既存ログは移動しないため、移行時は3条件の充足状況をエージェントごとに確認することが求められます。