ひとことで言うと
Bedrock を含む AWS アカウントで行われた API 呼び出しの証跡です。誰が（IAM識別情報）・いつ・どの API を・どこから呼んだかを記録します。リクエストの中身（プロンプト本文）までは記録しません。それは**モデル呼び出しログ（CloudWatch Logs / S3）**の仕事です。
要するに、入退室記録です。誰が何時にどのドアを開けたかは分かりますが、部屋の中で何を話したかは記録しません。「話した内容」まで要るなら別の仕組み（モデル呼び出しログ）が要ります。
なぜ生まれたか
| Bedrock 運用で必要になること | CloudTrail 側の受け皿 |
|---|---|
| 「このガードレールを誰が削除したか」を追いたい | 管理イベント（既定で記録） |
| 不正な設定変更を機械的に検知したい | GuardDuty が CloudTrail の管理・イベントログを継続分析 |
| エージェント・ナレッジベース・Flow の実行そのものを監査したい | データイベント（既定オフ・明示的な設定が必要） |
| 証跡を長期保存・分析対象にしたい | Trail を作成して S3 へ継続配信 |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| API 呼び出しの直近履歴を見る | Trail を作らなくても CloudTrail コンソールの「イベント履歴」で直近が見られる | D3 |
| 継続的な監査ログを残す | Trail を作成し S3 バケットへ配信 | D1, D3 |
| 不審な操作の自動検知 | GuardDuty が CloudTrail ログを分析（ガードレール削除・学習データバケットの変更など） | D3 |
| エージェント実行・KB検索・Flow実行の記録 | 高度なイベントセレクタでリソースタイプ別にデータイベントを有効化 | D1, D3 |
試験でどう問われるか
ここが最頻出の引っかけです。「モデル推論はデータイベントだろう」という直感は、Bedrock では外れます。
| 問われ方 | 正解に寄る条件 | 引っかけ |
|---|---|---|
「InvokeModel・Converse の呼び出し履歴を残したいが、追加設定はしたくない」 | これらは管理イベントとして既定で記録される（InvokeModel, InvokeModelWithResponseStream, Converse, ConverseStream, ListAsyncInvokes） | 「モデル推論はデータイベントだから、明示的に有効化しないと記録されない」と誤答する |
「InvokeAgent（エージェント実行）の呼び出しを記録したい」 | エージェント実行系はデータイベント → AWS::Bedrock::AgentAlias を対象にした高度なイベントセレクタが必要 | Trail を作っただけで満足する（データイベントは既定でオフ） |
「ナレッジベースの Retrieve/RetrieveAndGenerate を記録したい」 | データイベント → AWS::Bedrock::KnowledgeBase リソースタイプでの選択が必要 | 管理イベントのTrailだけで足りると考える |
「InvokeModelWithBidirectionalStream（双方向ストリーミング）を記録したい」 | 同じ bedrock-runtime エンドポイントの操作でも、これはデータイベント（InvokeModel/Converseとは扱いが違う） | 「Runtime API は全部管理イベント」で一括りにする |
| 「データイベントを有効にしたらコストが増えた」 | データイベントは高頻度操作向けで、既定オフなうえ追加料金がかかる | 管理イベントと同じ課金だと思い込む |
「Runtime API＝データイベント」ではありません。公式ドキュメントは明示的に、InvokeModel・InvokeModelWithResponseStream・Converse・ConverseStream・ListAsyncInvokes を管理イベントとして分類しています。データイベントになるのは InvokeModelWithBidirectionalStream・GetAsyncInvoke・StartAsyncInvoke、そしてエージェント実行系（InvokeAgent/InvokeInlineAgent）・KB検索系（Retrieve/RetrieveAndGenerate）・Flow実行系（InvokeFlow）・RenderPrompt です。「推論＝データイベント」という思い込みは試験で狙われます。
実務でどう使うか
- データイベントはリソースタイプ単位で選択します。
AWS::Bedrock::AgentAlias（InvokeAgent）、AWS::Bedrock::InlineAgent（InvokeInlineAgent）、AWS::Bedrock::KnowledgeBase（Retrieve/RetrieveAndGenerate）、AWS::Bedrock::FlowAlias（InvokeFlow）、AWS::Bedrock::ModelとAWS::Bedrock::AsyncInvoke（双方向ストリーミング・非同期呼び出し）、AWS::Bedrock::Guardrailなど。どれか1つ有効にしても他は記録されません - データイベントは高頻度操作を想定しているため追加料金がかかります。 全部有効化する前に、監査で本当に必要な範囲かを見極める
eventNameやresources.ARNでさらに絞り込めます。 カスタムログセレクタテンプレートで、特定のエージェントやナレッジベースだけに絞ることも可能- GuardDuty は CloudTrail の管理・イベントログを継続的に分析します。 「新しい場所からログインしてガードレールを削除した」のような異常操作の検知は GuardDuty 側の仕事で、CloudTrail 自体にはアラート機能はありません
データイベントを有効化しすぎるとコストが跳ねます。エージェント実行・KB検索は本番トラフィックでは高頻度になりがちで、全リソースタイプを何でも有効化すると想定外の CloudTrail 課金が発生します。監査要件で本当に必要な範囲だけを選ぶのが定石です。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| モデル呼び出しログ（CloudWatch Logs / S3） | CloudTrail は「誰が呼んだか」。呼び出しログは「何を投げて何が返ったか」（プロンプト本文まで）。監査の粒度が違う |
| CloudWatch メトリクス | CloudTrail はイベント単位の証跡。メトリクスは集約された数値。「何回呼ばれたか」はメトリクス、「誰が呼んだか」は CloudTrail |
| GuardDuty | CloudTrail はログを記録するだけ。異常検知・アラートは GuardDuty がログを分析して行う |
| AgentCore のスパン/トレース | CloudTrail は API 呼び出しの証跡。AgentCore のトレースはエージェント内部の処理区間（ツール呼び出しの連鎖など）の可観測性で、目的が異なる |
想起チェック
Q1. `Converse` API の呼び出しは、追加設定なしで CloudTrail に記録される？
されます。 Converse・ConverseStream・InvokeModel・InvokeModelWithResponseStream・ListAsyncInvokes は管理イベントとして既定で記録されます。追加設定が要るのはデータイベント（エージェント実行・KB検索・Flow実行・双方向ストリーミングなど）です。
Q2. `InvokeAgent`（エージェント実行）の呼び出し履歴を残すには何が必要？
高度なイベントセレクタで AWS::Bedrock::AgentAlias リソースタイプのデータイベントを明示的に有効化する必要があります。Trail を作成しただけでは記録されません。
Q3. CloudTrail のログから、あるユーザーが Bedrock に送ったプロンプトの内容を確認できる？
できません。 CloudTrail は誰がどの API をいつ呼んだかの証跡で、リクエスト本文までは記録しません。プロンプト内容を監査するにはモデル呼び出しログ（CloudWatch Logs / S3）を有効化する必要があります。