AWS Certified Generative AI Developer - Professional 資格対策コース
Amazon Bedrock Guardrails で入出力を安全化する
このレッスンで学ぶこと 対応試験ドメイン D3 タスク 3.1.1(入力コントロールの実装)と 3.1.2(出力コントロールの実装)。Amazon Bedrock Guardrails で入力と出力の両方向に安全コントロールを適用し、AWS Step Functions と組み合わせて安全なワークフローを組む設計判断を身につけます。
解説
生成 AI アプリでは「ユーザーが何を入れてくるか」と「モデルが何を返すか」の両方を制御する必要があります。AWS でこれを担う中心サービスが Amazon Bedrock Guardrails です。Guardrails はモデルとは独立した安全レイヤーで、基盤モデルを問わず(さらに Bedrock 外の自社モデルにも ApplyGuardrail API 経由で)一貫したポリシーを適用できます。
Guardrails の主なコントロール
Guardrails には複数のポリシーがあり、入力側と出力側それぞれに効かせられます。主なものは次の通りです。
| ポリシー | 役割 | 入力/出力 |
|---|---|---|
| コンテンツフィルタ | 暴力・憎悪・性的・侮辱・違法行為などを強度別に遮断 | 両方 |
| 拒否トピック | 自然言語で定義した話題(例 投資助言)をブロック | 両方 |
| 単語フィルタ | 禁止語・プロファニティを遮断 | 両方 |
| 機微情報フィルタ | PII を検出してブロックまたはマスキング | 両方 |
| プロンプト攻撃フィルタ | プロンプトインジェクション・ジェイルブレイクを検出 | 入力 |
| contextual grounding | 出典に基づかない回答(ハルシネーション)を抑制 | 出力 |
ポイントは、同じ Guardrail を入力プロンプトと出力レスポンスの両方に適用できることです。たとえば拒否トピックは、ユーザーがその話題を「聞いてくる」のも、モデルが「答えてしまう」のも両方止められます。
入力と出力の両方に効かせる
Converse や InvokeModel で guardrailIdentifier を渡すと、入力と出力に自動適用されます。Bedrock 外のモデルや独自パイプラインでは ApplyGuardrail API を単体で呼び、任意のテキストを検査できます。
Python
import boto3
client = boto3.client("bedrock-runtime", region_name="us-east-1")
resp = client.converse(
modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
guardrailConfig={
"guardrailIdentifier": "abcd1234",
"guardrailVersion": "DRAFT", # 本番では発行済みバージョンを固定
},
messages=[{"role": "user", "content": [{"text": "..."}]}],
)
# Guardrail が介入した場合は stopReason が guardrail_intervened になるStep Functions で安全なワークフローにする
複数ステップのオーケストレーション(検査 → 生成 → 後処理 → 人手レビュー分岐)が必要なときは AWS Step Functions でフローを組みます。入力検査で違反したら生成に進まず即座に定型応答へ分岐する、出力検査で疑わしければ人手レビューへ回す、といった条件分岐つきの安全パイプラインを宣言的に表現できます。Guardrails が「何を止めるか」、Step Functions が「止めたあと何をするか」を担います。
試験で問われるポイント
- 入力にも出力にも同じ Guardrail を適用するのが基本。「ユーザー入力だけ検査すれば十分か」という選択肢はひっかけで、出力側のハルシネーションや不適切生成も止める必要がある
- Amazon Bedrock Guardrails と AWS WAF は似て非なるもの。WAF は HTTP リクエストレベルの Web 防御(レート制限・IP・SQLi など)で、プロンプト内容の意味的な安全性は判断しない。プロンプトの中身・モデル出力の安全コントロールは Guardrails
- Bedrock 外のモデルや独自処理にガードを効かせたいなら
ApplyGuardrailAPI を単体で呼ぶ。これを知らないと「Bedrock のモデルしか守れない」と誤解しやすい - フィルタの強度設定(NONE/LOW/MEDIUM/HIGH)と、ブロックするのかマスキングするのかの選択は要件次第。PII は用途により「ブロック」と「マスキング」を使い分ける
- 試験で問われるのは AWS のどの機能で入出力を安全化するかであり、汎用的なモデレーション論ではない
サービスの使い分け早見表
| やりたいこと | 使うもの | 混同しやすいもの |
|---|---|---|
| プロンプトと出力の意味的な安全コントロール | Amazon Bedrock Guardrails | AWS WAF(HTTP レイヤーの防御で中身は見ない) |
| Bedrock 外のモデル・任意テキストにガード適用 | ApplyGuardrail API | Converse の guardrailConfig(Bedrock モデル呼び出しに紐づく) |
| 検査後の条件分岐・人手レビュー誘導 | AWS Step Functions | Guardrails 単体(止めるが分岐ロジックは持たない) |
まとめ
入出力の安全化は、Amazon Bedrock Guardrails で入力と出力の両方にコンテンツフィルタ・拒否トピック・PII・プロンプト攻撃フィルタを適用し、Bedrock 外には ApplyGuardrail API を使い、検査後の分岐は AWS Step Functions で組むのが王道です。WAF と Guardrails の役割の違いが頻出論点です。
次のステップ
次のクイズレッスンで、本番形式のシナリオ問題に挑戦して入出力安全化の判断力を確認しましょう。
関連レッスン
- ハルシネーション低減と contextual grounding(pro-hallucination-guard)
- プロンプトインジェクション・ジェイルブレイク検出(pro-threat-detection)
- PII 保護とプライバシー(pro-pii-privacy)