5.1標準
顧客IDを分析用プロンプトへ含める必要がある。
モデルには実IDを渡さず、後から業務系で対応付ける。
対策として適切なものを2つ選べ。
× 不正解
機密値はトークン化して対応表を別権限で保管し、再識別可能性・ログ・保持・出力を引き続き管理する。
詳細解説
誤り対応表をプロンプトへ毎回埋め込む
実IDとトークンの分離を失う。
誤りトークンは匿名化なので全ての規制・権限管理が不要になる
対応表や組み合わせで再識別できる。
正しいトークン化後も再識別、ログ、出力、保持、アクセスを監査する
トークンが漏れても影響を管理しやすい。
正しい実IDをランダムなトークンへ置換し、対応表を別の権限境界で保管する
モデル入力から直接識別子を減らせる。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
AWS公式AIF-C01 Domain 5.1のデータ保護、トークン化、最小権限を確認する。
参考にした公式資料
確認できる内容
トークン化がアクセス分離であり、完全な匿名化を自動保証しないと説明できる。
理解のポイント
- トークン化
- 対応表
- 再識別
確認時の注意
- 確認環境: AWS公式AIF-C01試験ガイドとAWS公式ドキュメントの確認
- AWS公式ドキュメントで、対象サービスが提供する機能と前提条件を確認する。
- モデル、データ、アプリケーション、利用者の責任分界を混同しない。
基礎のおさらい
トークン化
機密値を代替トークンへ置き換え、対応表を分離して扱う方法。
再識別可能性
他の情報や対応表と組み合わせて元の個人・機密値が分かる可能性。
問題IDAWS-AIF-291
確認環境AWS公式AIF-C01試験ガイドとAWS公式ドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告