ひとことで言うと
モデルの外側に置く検査層です。入力プロンプトとモデル応答の両方を、設定したポリシー（有害コンテンツ・禁止トピック・単語・機密情報・根拠整合・自動推論）に照らして遮断またはマスクします。テキストでも画像でも、どの基盤モデルでも同じ設定が使えます。
要するに、空港の保安検査です。搭乗前（入力）と到着後（出力）の両方で荷物を開けます。検査場は航空会社（モデル）から独立しているので、機材を Claude から Nova に変えても検査基準は1文字も変わりません。しかも ApplyGuardrail API を使えば「飛行機に乗せずに手荷物だけ検査する」ことができ、Bedrock 以外のモデルの出力や、自前の後処理にも同じ検査を掛けられます。
この「モデルから独立している」という一点が、試験でも実務でも効いてきます。
なぜ生まれたか
| プロンプトエンジニアリングだけで守ろうとすると | Guardrails 側の受け皿 |
|---|---|
| モデルを変えるたびに system prompt を書き直す | ガードレールはモデルから独立。ID とバージョンを指定して付け替える |
| 「この話題には答えるな」が指示の隙間から漏れる | 禁止トピック（Denied topics）を宣言的に定義 |
| PII をログや要約に載せてしまう | 機密情報フィルタで BLOCK / ANONYMIZE（マスク） を型ごとに指定 |
| ジェイルブレイク・プロンプトインジェクション | コンテンツフィルタの Prompt Attack カテゴリ |
| RAG なのに検索結果から外れた回答をする | 根拠整合チェック（contextual grounding check） |
| 安全設定がアプリごとにバラバラ | 1アカウントに複数のガードレールを持ち、用途別に使い分ける |
構造として重要なのは、安全制御をプロンプトから設定に外出ししたことです。プロンプトに書いた禁止事項はモデルの気分で守られたり守られなかったりしますが、ガードレールは別の判定モデル群が実行します。だから「モデルを差し替えても安全性が保たれるか」という要件が、そのままガードレール採用の理由になります。
何に使うか
| ポリシー | 何を見るか | 関連する試験ドメイン |
|---|---|---|
| コンテンツフィルタ | Hate / Insults / Sexual / Violence / Misconduct / Prompt Attack の6カテゴリ。強度をカテゴリごとに設定 | D3 |
| 禁止トピック | アプリ文脈で望ましくない話題を定義して遮断 | D3 |
| 単語フィルタ | カスタム単語・フレーズの完全一致（競合名など）。プロファニティは既製リストあり | D3 |
| 機密情報フィルタ | 組み込み PII 型＋カスタム正規表現。BLOCK / ANONYMIZE / NONE | D3 |
| 根拠整合チェック | 応答が参照ソースに基づいているか（Grounding）、質問に答えているか（Relevance） | D3・D1 |
| 自動推論チェック | 論理ルール集合に照らして応答の正しさを検証し、修正案や暗黙の前提を示す | D3 |
Standard ティアでは、コンテンツフィルタと禁止トピックの検出がコード要素の中（コメント・変数名・関数名・文字列リテラル）まで広がります。「コードの中に有害な内容やPIIが埋め込まれている」というシナリオは、この差を見ています。
試験でどう問われるか
D3（20%）の 3.1 と 3.2 がほぼここです。**「どのポリシーを使うか」ではなく「どこに置くか・どう振る舞わせるか」**が問われます。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| RAG の回答が検索結果から外れる | 根拠との整合を機械で判定したい → 根拠整合チェック（Grounding しきい値） | temperature を下げる／プロンプトに「事実だけ答えて」と書き足す |
| 質問と噛み合わない回答が返る | 内容は正しいが的外れ → Relevance しきい値（Grounding ではない） | Grounding を上げる（グラウンデッドだが無関係、は通ってしまう） |
| 通話要約から個人情報を消したい | 要約自体は返したい → ANONYMIZE（マスク） | BLOCK（応答ごと消えるので要約が返らない） |
| 公開文書ベースのQ&Aで個人情報が来た | そもそも扱わせたくない → BLOCK | ANONYMIZE |
| Bedrock 以外のモデル／自前の後処理にも同じ検査を | モデル呼び出しと切り離したい → ApplyGuardrail API | 各モデル呼び出しに guardrail ID を付ける案（Bedrock 外には付けられない） |
| RAG で検索結果や会話履歴まで検査されてしまう | ユーザー入力だけを見たい → 入力タグ／guardContent の qualifier で範囲を絞る | プロンプト全体をそのまま検査する |
| ジェイルブレイク対策 | 敵対的入力 → コンテンツフィルタの Prompt Attack | 単語フィルタで攻撃文言を列挙する案 |
| 設定を本番に出す | 検証済みの構成を固定したい → バージョンを作成して参照 | 作業ドラフト（working draft）のまま本番で使う |
課金の効き方が、正誤の分かれ目になることがあります。入力がブロックされた場合はガードレールの評価分のみ課金され、基盤モデルの推論は課金されません（推論自体が破棄される）。一方、出力がブロックされた場合は、生成済みのモデル応答ぶんの推論料も課金されます。「コストを抑えつつ有害な入力を弾く」というシナリオでは、入力側で止める設計が正解に寄ります。
実務でどう使うか
- マスクはログには効きません。 モデル呼び出しログを有効にしている場合、CloudWatch Logs の
inputフィールドにはガードレールの介入に関係なく元のリクエストがそのまま入ります。さらにガードレールのトレース出力（GuardrailPiiEntityFilterのmatch）にもマスク前の実データが入る仕様です（アプリ側が検出結果を使えるようにするため）。「PII をマスクしたから安心」でログ設計を止めると、そこから漏れます - 根拠整合チェックは出力にしか掛かりません。 モデル応答が無いと判定できないため、プロンプト側では実行されません。しきい値は 0〜0.99 で設定し、1 は無効（全部ブロックになるため）。入力サイズの上限は参照ソース10万文字・クエリ1,000文字・応答5,000文字
- 根拠整合チェックは会話型チャットボットを対象外としています。 対応するのは要約・言い換え・質問応答。マルチターンの雑談に掛けて期待どおりに動かない、というのは仕様どおりです
grounding_sourceとqueryに入れた内容は、他のポリシーの検査対象から外れます。 参照ソースにも単語フィルタや PII 検出を効かせたいなら、guard_contentを併記して両方の役割を持たせます- 機密情報フィルタはテキスト出力のみ。 モデルが
tool_use（関数呼び出し）のパラメータとして PII を返した場合は検出しません。エージェント構成では、ツール呼び出し経路に別の防御が要ります - 入力と出力で挙動を変えられます。
inputAction/outputActionを分けて指定できるので、「入力は素通し（検出のみ）、出力はマスク」が可能です。カスタム正規表現は先読み・後読み（lookaround）に非対応
Knowledge Bases と組み合わせるときの注意: 根拠整合チェックを Knowledge Bases で使う構成は、Claude 3 Sonnet と Haiku ではサポートされていません。「RAG にグラウンディングチェックを入れたのに動かない」の原因がモデル選択にあることがあります（Knowledge Bases のノート）。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Comprehend の PII 検出 | Comprehend は前処理として使える独立サービス。Guardrails は推論の経路上に置く。多層防御では「Comprehend で前処理 → Bedrock → Lambda で後処理」と併用する |
| Amazon Macie | Macie は保管データ（S3）の機密情報を見つける。Guardrails は流れるデータを見る。「データレイクのPIIを棚卸ししたい」なら Macie |
| プロンプトに書く禁止事項 | プロンプトはモデルへの依頼、ガードレールは強制。モデルを差し替えても効くかが判断基準 |
| Bedrock Model Evaluations | 評価は出す前に測る（D5）。ガードレールは出す瞬間に止める（D3）。シナリオの時制で切り分ける |
| Knowledge Bases の引用 | 引用は「根拠を見せる」。根拠整合チェックは「根拠から外れていないか判定する」。前者は読者の目視、後者は機械判定 |
| 自動推論チェック | 根拠整合チェックが参照ソースとの一致を見るのに対し、こちらは論理ルール集合との整合を見る。「社内規程に矛盾しないこと」を保証したいならこちら |
想起チェック
Q1. 「要約に含まれる氏名とメールアドレスを消したいが、要約自体は返したい」ときの設定は？
**機密情報フィルタの ANONYMIZE（マスク）**です。検出された箇所が {NAME} {EMAIL} のような型名に置き換わります。BLOCK を選ぶと応答全体が設定済みのブロックメッセージに差し替わり、要約が返りません。
Q2. Grounding と Relevance のスコアを分ける基準は？
**Grounding は「参照ソースに書いてあることか」、Relevance は「ユーザーの問いに答えているか」**です。参照ソースから正しく引いていても質問と噛み合っていなければ Relevance が低くなります。片方だけを上げても、もう片方の失敗は止まりません。
Q3. Bedrock を経由しないモデルの出力にも同じ検査を掛けたい。どうする？
ApplyGuardrail API を使います。基盤モデルを呼び出さずにガードレールだけを実行できるので、外部モデルの出力・自前の後処理・バッチでの再検査に同じポリシーを適用できます。
Q4. 「有害な入力を弾きつつ推論コストを抑えたい」——入力側と出力側、どちらで止めるのが有利？
入力側です。入力でブロックされた場合はガードレールの評価分だけが課金され、基盤モデルの推論は実行も課金もされません。出力でブロックすると、生成済み応答の推論料は発生します。