コンプライアンス・モデルカード・監査証跡設計（何を残すか）｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D3 タスク 3.3.1（コンプライアンス要件への適合）と 3.3.2（監査証跡・文書化）。SageMaker Model Cards・AWS CloudTrail・IAM Access Analyzer・Bedrock の呼び出しログ・組織ポリシー（SCP）を横断し、監査証跡として「何をどこに残すか」を設計する判断力を身につけます。

解説

コンプライアンス対応の核心は「あとから第三者が検証できるよう、何の記録をどこに残すか」の設計です。生成 AI では「モデルの素性」「誰が何を呼んだか」「権限の実態」「組織としての禁止事項」を別々のサービスで証跡化します。一つの機能に寄せすぎないことが重要です。

監査証跡は「目的ごとに残し場所が違う」

残したい証跡	使う AWS 機能	何が記録されるか
モデルの素性・意図・制限・評価結果	Amazon SageMaker Model Cards	モデルの目的・想定用途・リスク・評価指標を構造化文書化
誰がいつどの API を呼んだか	AWS CloudTrail	Bedrock など API の操作履歴（管理イベント・データイベント）
実際の権限が広すぎないか	IAM Access Analyzer	外部公開・過剰権限・未使用アクセスの可視化と検証
推論の入出力ログ	Bedrock のモデル呼び出しログ	プロンプト・レスポンス・Guardrail 介入の記録（S3/CloudWatch Logs へ）
組織としての禁止・強制	AWS Organizations の SCP（組織ポリシー）	リージョン・サービス・モデルの利用可否を組織横断で強制

SageMaker Model Cards でモデルを文書化する

Amazon SageMaker Model Cards は、モデルの目的・想定用途・学習データ・評価結果・既知の制限・リスク評価を構造化された文書として残す仕組みです。監査では「このモデルが何のために、どんな前提で使われているか」の説明責任が問われます。これはバイアスの数値（Clarify）やドリフトの監視（Model Monitor）とは別の、ガバナンス文書としての証跡です。

CloudTrail で操作証跡を残す

AWS CloudTrail は誰がいつ Bedrock の API（モデル呼び出しやガードレール変更など）を実行したかを記録します。Bedrock のデータイベントを有効化すると、推論の呼び出し操作も証跡化できます。これは「操作の事実」の証跡で、プロンプト本文そのものは Bedrock のモデル呼び出しログ側で残します。

IAM Access Analyzer で権限を検証する

IAM Access Analyzer は、リソースが意図せず外部公開されていないか、過剰・未使用の権限がないかを検証します。最小権限が「設計通り維持されているか」を継続的に点検する証跡になります。

組織ポリシー（SCP）で強制する

AWS Organizations のサービスコントロールポリシー（SCP）で、特定リージョン外での Bedrock 利用禁止、承認外モデルの呼び出し禁止などを組織横断で強制します。個別アカウントの IAM では破られうる境界を、組織レベルで担保します。

Python

# 証跡の役割分担の例
# - SageMaker Model Cards: モデルの素性・意図・制限を文書化
# - CloudTrail: API 操作の who/when/what
# - Bedrock モデル呼び出しログ: プロンプト/レスポンス本文
# - IAM Access Analyzer: 権限が過剰でないかの検証
# - Organizations SCP: 組織としての利用可否の強制

試験で問われるポイント

監査証跡は一つのサービスに寄せない。モデルの素性は Model Cards、操作は CloudTrail、入出力本文は Bedrock の呼び出しログ、権限実態は IAM Access Analyzer、組織の禁止は SCP と、目的ごとに残し場所が違う
SageMaker Model Cards（ガバナンス文書）と SageMaker Clarify（バイアス測定）と Model Monitor（ドリフト監視）は別物。「モデルの目的・制限・想定用途を監査向けに文書化」と来たら Model Cards であって Clarify/Model Monitor ではない（D3 をこの 2 つに寄せすぎない）
AWS CloudTrail（操作の who/when/what）と Bedrock モデル呼び出しログ（プロンプト/レスポンス本文）は記録対象が違う。「誰が API を実行したか」は CloudTrail、「どんなプロンプトが投げられ何が返ったか」は呼び出しログ
組織横断の強制境界は SCP。個別 IAM では「うっかり許可」を防ぎきれない要件で効く
権限が設計通りかの継続検証は IAM Access Analyzer。一度設定して終わりではない
試験で問われるのは AWS のどの機能でどの証跡を残すかであり、コンプライアンス制度そのものの解説ではない

サービスの使い分け早見表

残したい証跡	使うもの	混同しやすいもの
モデルの目的・制限・評価の文書	Amazon SageMaker Model Cards	SageMaker Clarify（バイアス測定）/ Model Monitor（ドリフト監視）
誰がいつどの API を実行したか	AWS CloudTrail	Bedrock モデル呼び出しログ（プロンプト/レスポンス本文側）
プロンプト・レスポンスの内容	Bedrock モデル呼び出しログ	CloudTrail（操作の事実は残すが本文は残さない）
権限が過剰・公開されていないかの検証	IAM Access Analyzer	IAM ポリシー単体（書くだけで継続検証はしない）
組織横断の利用禁止・強制	AWS Organizations SCP	個別アカウントの IAM（組織境界の強制には弱い）

まとめ

監査証跡設計は「何を、どこに、なぜ残すか」の役割分担です。モデルの素性は SageMaker Model Cards、API 操作は CloudTrail、入出力本文は Bedrock の呼び出しログ、権限の実態は IAM Access Analyzer、組織の強制は SCP。Model Cards・Clarify・Model Monitor の区別と、CloudTrail と呼び出しログの記録対象の違いが頻出論点です。

次のステップ

次のクイズレッスンで、本番形式のシナリオ問題に挑戦して監査証跡設計の判断力を確認しましょう。