ひとことで言うと
Bedrock のモデル呼び出しの「中身」（リクエスト本文・レスポンス本文・トークン数・呼び出し元）を記録する先です。Bedrock 側では「モデル呼び出しログ（model invocation logging）」という機能名で、既定では無効になっており、有効化して初めて溜まり始めます。
要するに、ドライブレコーダーです。CloudWatch のメトリクスが速度計なら、Logs は車内と車外の映像そのもの。ただし録画ボタンを自分で押さないと記録は始まりません（既定オフ）。
なぜ生まれたか
| Bedrock 運用で必要になること | CloudWatch Logs 側の受け皿 |
|---|---|
| 「誰が・いつ・どのモデルに・何を投げて・何が返ってきたか」を追いたい | モデル呼び出しログ（ModelInvocationLog スキーマ） |
| チーム・環境ごとにトークン消費を按分したい | リクエスト単位のメタデータタグ（requestMetadata）をログに埋め込む |
| ログをその場で対話的に検索・集計したい | CloudWatch Logs Insights（クエリ言語で fields / stats / sort） |
| エージェントのスパン（処理の各区間）を残したい | AgentCore が aws/spans またはエージェント専用ロググループに配信 |
要点は**「メトリクスは量、ログは中身」**という役割分担です。「なぜこのリクエストは介入されたのか」「このユーザーはどんなプロンプトを送っていたのか」に答えられるのはログだけです。
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| モデル呼び出しの記録を残す | Bedrock コンソールの Settings → Model invocation logging で有効化。宛先は S3 のみ／CloudWatch Logs のみ／両方から選択 | D1, D3 |
| コスト・利用状況を呼び出し元単位で追う | Converse/ConverseStream は body の requestMetadata、InvokeModel 系は X-Amzn-Bedrock-Request-Metadata ヘッダでタグを付与 | D4 |
| ログをその場で集計・検索 | CloudWatch Logs Insights のクエリ（fields → stats sum() by） | D4, D5 |
| エージェントのトラブルシュート | AgentCore が配信するスパンのログストリーム（/aws/bedrock-agentcore/runtimes/<agent_id>-<endpoint_name> の spans ストリームなど） | D2, D5 |
試験でどう問われるか
D1 の 1.6（プロンプトエンジニアリングとガバナンス）で「CloudTrail・CloudWatch Logs で利用追跡」と明記されており、「誰が何を投げたか」の監査という文脈でまず出ます。D4/D5 では運用・トラブルシュートの文脈です。
| 問われ方 | 正解に寄る条件 | 引っかけ |
|---|---|---|
| 「モデルに送られたプロンプトの内容を監査したい」 | 呼び出しの中身が要る → モデル呼び出しログを有効化（既定オフなので後から遡って見られない） | CloudTrail を見る（CloudTrail は API 呼び出しの記録で、リクエスト本文までは踏み込まない） |
| チームごとのトークン消費を按分したい | 呼び出し単位の付帯情報が要る → リクエストメタデータ（requestMetadata）をログに埋め込み、Logs Insights で by 集計 | IAM のタグだけで按分しようとする（セッション単位の粒度しか出ない） |
| 画像やバイナリを含む大きい入出力を記録したい | 100KB を超えるバイナリ・JSON は個別オブジェクトとして扱われる → S3 宛先が必要（CloudWatch Logs 単独では扱えない） | CloudWatch Logs だけを宛先に選ぶ |
| 「ログはあるのに直近数分のイベントが見えない」 | ロググループの作成時刻より前のイベントは Logs Insights から見えない仕様 | クエリの時間範囲の設定ミスだと決めつける |
モデル呼び出しログを有効化していないと、リクエストメタデータは記録されません。タグを付けてリクエストを送っても、呼び出したリージョンでロギングが有効になっていなければメタデータは捨てられます（リクエスト自体は成功する）。「タグを付けたのに集計に出てこない」は、まずロギングの有効化状況を疑う場所です。
実務でどう使うか
- 既定は無効。有効化した瞬間からしか記録が残りません。 事後にログを見たい事故対応では手遅れになるので、本番運用前に有効化しておく
- CloudWatch Logs 宛先は 100KB までの入出力本文しか載りません。 それを超えるものや画像などのバイナリは、S3 宛先を併用していれば S3 側に個別オブジェクトとして保存され、ログ側には参照だけが残ります
- リクエストメタデータは最大16件、キー・値それぞれ最大256文字。 高カーディナリティな値（セッションIDなど）を安易に詰め込むと集計がしにくくなるので、
team/environmentのような低カーディナリティなキーを基本にする - リクエストメタデータは Cost Explorer や CUR には流れません。 ログの中でしか使えないので、Cost Explorer 側で按分したいなら Application inference profiles のコスト配分タグを別途使う
- Logs Insights のクエリはスキャンしたデータ量に課金されます。 クエリタイムアウトは60分、結果の保持は7日間
SigV4 署名の対象からメタデータヘッダを漏らすと失敗します。InvokeModel/InvokeModelWithResponseStream で X-Amzn-Bedrock-Request-Metadata ヘッダを手動で付ける場合、SignedHeaders にこのヘッダを含めないと InvalidSignatureException になります。AWS SDK 経由でメタデータを渡す実装なら自動処理されるので気にする必要はありません。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| CloudWatch（メトリクス） | Logs は個々のリクエストの中身、CloudWatch は集約された数値。「介入率が知りたい」ならメトリクス、「なぜ介入されたか知りたい」ならログ |
| CloudTrail | CloudTrail は「誰がどの API を呼んだか」の監査証跡（管理イベント/データイベント）。モデル呼び出しのプロンプト本文まではCloudTrailには載らない。本文が要るなら Logs |
| AgentCore のスパン | エージェント固有の処理区間の記録で、配信先自体は CloudWatch Logs（もしくは X-Ray 経由のトレース）。Bedrock 単体のモデル呼び出しログとは別の設定が必要 |
| S3 宛先 | 100KB 超のデータやバイナリの実体は結局 S3 に落ちる。CloudWatch Logs 単独運用でも大きなペイロードがあるなら S3 宛先の設定は避けられない |
想起チェック
Q1. モデル呼び出しログを有効化する前に投げたリクエストのプロンプト内容は、後から確認できる？
できません。 モデル呼び出しログは既定で無効で、有効化した時点からのログしか記録されません。過去に遡っての記録はありません。
Q2. `requestMetadata` で付けたタグは AWS Cost Explorer にそのまま出る？
出ません。 リクエストメタデータはモデル呼び出しログの中だけに記録され、Cost Explorer や CUR には流れません。Cost Explorer 側で按分したいなら Application inference profiles のコスト配分タグを使います。
Q3. 画像入力を含む大きなリクエストを記録したい。宛先は CloudWatch Logs だけで足りる？
足りません。 100KB を超える入出力本文やバイナリデータは、S3 宛先が設定されていないと保存されません。CloudWatch Logs 単独では大きなペイロードを扱えないので、S3 を宛先に含める必要があります。