変更要約: 初版: ドメイン3（安全性・セキュリティ・ガバナンス）の4節を作成
3.1入出力のセーフティ制御
有害な入力・出力から守る多層防御を学びます。Bedrock Guardrails による入出力フィルタ、毒性/モデレーション、ハルシネーション低減（Knowledge Base 根拠付け・JSON Schema）、プロンプトインジェクション／ジェイルブレイク検出を扱います。
GenAI は有害入力（攻撃プロンプト）と有害出力（毒性・幻覚・PII 漏えい）の両方に対処が必要です。単一の防御でなく、前処理・モデル層・後処理の多層防御で守ります。
3.1.1多層のセーフティ
- Bedrock Guardrails：入力/出力をフィルタ（禁止トピック・毒性・PII・単語）。責任ある AI のルールを宣言的に強制する中核。
- ハルシネーション低減：Knowledge Base で回答を根拠付け（grounding）、信頼度スコア/意味的類似度で検証、JSON Schema で構造化出力を強制。
- 多層防御：前処理（Comprehend フィルタ）→モデル層（Guardrails）→後処理（Lambda 検証）→API 層（API Gateway 応答フィルタ）。
- 脅威検出：プロンプトインジェクション／ジェイルブレイクの検出、入力サニタイズ、セーフティ分類器、敵対的テストの自動化。
「入出力の安全フィルタ＝Guardrails」「幻覚を減らす＝KB 根拠付け＋JSON Schema 強制」「攻撃プロンプト＝プロンプトインジェクション/ジェイルブレイク検出」「単一でなく多層防御」 は頻出です。Guardrails は入力側と出力側の両方に適用できます。
安全設計は「攻撃を入れない・有害を出さない・幻覚を出さない」を多層で実現します。入力側は Comprehend や分類器で前処理し、プロンプトインジェクション（指示の上書き）や ジェイルブレイク（制約回避）を検出・サニタイズ。モデル層は Bedrock Guardrails で禁止トピック・毒性・PII・単語を遮断（入力/出力の双方）。出力側は Lambda で後処理検証、API Gateway で応答フィルタを追加します。幻覚対策は Knowledge Base で回答を根拠付けし（出典提示）、信頼度スコアや意味的類似度で事実確認、JSON Schema で形式を固定、決定的な結果が要る箇所は text-to-SQL など決定論に寄せます。敵対的入力には自動敵対的テストを CI に組み込み、Guardrails の有効性を継続検証します。重要なのは「Guardrails だけ」「プロンプトだけ」に頼らず、前処理〜API 層まで冗長に重ねることです。
| 脅威 | 対策 | 層 |
|---|---|---|
| 有害入力/攻撃プロンプト | インジェクション検出＋サニタイズ | 前処理 |
| 有害出力（毒性/PII） | Bedrock Guardrails | モデル層（入出力） |
| 幻覚 | KB 根拠付け＋JSON Schema | 検索＋後処理 |
| 回避の継続検証 | 自動敵対的テスト | CI/CD |
ひっかけ： 「システムプロンプトに“無視しないで”と書けばプロンプトインジェクションは防げる」は誤りです。プロンプトだけに頼らず、検出/サニタイズ＋Guardrails＋後処理の多層で守ります。また「Guardrails は出力にだけ効く」も誤り（入力側にも適用可）。
3.1.2この節のまとめ
- 安全＝多層防御（前処理→Guardrails→後処理→API）
- 幻覚＝KB 根拠付け＋JSON Schema／攻撃＝インジェクション/ジェイルブレイク検出
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. カスタマー向け生成 AI が禁止トピックへの言及や PII の出力をしないよう、入力と出力の両方をフィルタしたい。中核となるのは？
Q2. RAG ベースの回答で事実に基づかない幻覚を減らしたい。最も効果的な対策の組み合わせは？
Q3. ユーザーがシステムの制約を回避しようとする「指示の上書き」攻撃に備えたい。適切な設計は？