Grok 4.6 on Amazon Bedrock で Guardrails を試してみた
はじめに
xAI の Grok 4.6 は、2026年8月に Amazon Bedrock で利用できるようになりました。
Grok 4.6 のモデルカードには、本記事執筆時点で Guardrails 対応についての記載がありません。一方で、2026年9月に公開された AWS ブログでは、Grok 4.6 が Amazon Bedrock Guardrails に対応していることが紹介されています。
そこで今回は、Amazon Bedrock 上の Grok 4.6 に Guardrails を適用し、PII の EMAIL ブロックが実際にどう動作するかを確認しました。
事前準備
Guardrail を使うための IAM 権限
アプリケーションの実行ロールには、モデル呼び出しの権限に加えて bedrock:ApplyGuardrail が必要です。Guardrail 自体の作成・更新（bedrock:CreateGuardrail など）は管理側の操作なので、実行ロールとは分けて付与する想定で、以下のポリシー例には含めていません。
アプリケーション実行ロール向けの IAM ポリシー例
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"bedrock:InvokeModel",
"bedrock:InvokeModelWithResponseStream"
],
"Resource": [
"arn:aws:bedrock:*::foundation-model/xai.grok-4.6",
"arn:aws:bedrock:*:*:inference-profile/global.xai.grok-4.6"
]
},
{
"Effect": "Allow",
"Action": "bedrock:ApplyGuardrail",
"Resource": "arn:aws:bedrock:ap-northeast-1:<account-id>:guardrail/<guardrail-id>"
}
]
}
Guardrail の作成
Grok 4.6 はグローバル推論プロファイル（global.xai.grok-4.6）で呼び出すため、Guardrail 側にもクロスリージョン推論の設定（--cross-region-config）を指定しています。モデル側のクロスリージョン推論と Guardrail 側のクロスリージョン推論は別の仕組みで、後者は Guardrail の評価処理をリージョン横断で行うためのものです。Guardrail 側のクロスリージョン推論は Standard tier の機能として位置づけられていますが、PII フィルタには tier の設定項目がありません。
作成した Guardrail には、PII の EMAIL ブロックを設定しました。--cross-region-config には APAC のプロファイルを指定しています。PII の設定では action に加えて inputAction / outputAction で入力側・出力側の動作を個別に指定できます。今回はいずれも BLOCK にしています。
# Guardrail を作成する
aws bedrock create-guardrail \
--region ap-northeast-1 \
--name "my-guardrail" \
--cross-region-config '{"guardrailProfileIdentifier": "apac.guardrail.v1:0"}' \
--sensitive-information-policy-config '{
"piiEntitiesConfig": [
{
"type": "EMAIL",
"action": "BLOCK",
"inputAction": "BLOCK",
"outputAction": "BLOCK"
}
]
}' \
--blocked-input-messaging "このリクエストはポリシーによりブロックされました。" \
--blocked-outputs-messaging "この応答はポリシーによりブロックされました。"
# バージョンを切る
aws bedrock create-guardrail-version \
--region ap-northeast-1 \
--guardrail-identifier "<guardrail-id>" # create-guardrail の出力 guardrailId
create-guardrail で作った下書きは DRAFT のままでも呼び出せますが、アプリケーションから参照するバージョンを固定するため、create-guardrail-version でバージョンを切りました。以降の <guardrail-id> は create-guardrail の出力にある guardrailId、<version> は create-guardrail-version の出力にある version（"1" のような数値文字列）を指します。
検証環境と呼び出し方法
呼び出しは ap-northeast-1 の bedrock-runtime から Converse API を使い、modelId には inference profile の ID global.xai.grok-4.6 を指定します。
Guardrail は guardrailConfig で渡します。trace を enabled にすると、どのポリシーが何を検出したかがレスポンスに含まれます。
なお、本記事に掲載するレスポンスはいずれも要点のみを抜粋・整形したものです。trace 内の invocationMetrics や、検出なしのポリシーなどは省略しています。
import boto3
client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
response = client.converse(
modelId="global.xai.grok-4.6",
messages=[
{"role": "user", "content": [{"text": "AWSのBedrockについて1文で説明してください。"}]}
],
guardrailConfig={
"guardrailIdentifier": "<guardrail-id>",
"guardrailVersion": "<version>", # 例: "1"
"trace": "enabled",
},
)
正常系
「AWSのBedrockについて1文で説明してください。」というプロンプトを送ったケースです。EMAIL を含まないため、Guardrail を付けたまま通常どおり応答が返りました。
{
"stopReason": "end_turn",
"output": {
"message": {
"role": "assistant",
"content": [
{
"text": "Amazon Bedrockは、AnthropicやStability AIなどの主要AI企業の基盤モデルに単一APIでアクセスでき、生成AIアプリをインフラ管理なしで構築・スケールできるAWSのフルマネージドサービスです。"
}
]
}
},
"usage": {
"inputTokens": 29,
"outputTokens": 490,
"totalTokens": 519
}
}
1 文の回答に対して outputTokens が 490 と大きめですが、本文以外のトークンも含まれている可能性があり、本記事では深掘りしません。
PII ブロック（inputAction / outputAction: BLOCK）
BLOCK を指定すると、PII を含む入力・出力をブロックして blocked-input-messaging / blocked-outputs-messaging に設定したメッセージを返します。
入力側ブロック（inputAction: BLOCK）
test.user@example.com を含むプロンプトを送ったケースです。入力評価の段階でブロックされ、モデルは呼ばれません。
{
"stopReason": "guardrail_intervened",
"output": {
"message": {
"content": [{"text": "このリクエストはポリシーによりブロックされました。"}]
}
},
"usage": {"inputTokens": 0, "outputTokens": 0, "totalTokens": 0},
"trace": {
"guardrail": {
"modelOutput": [],
"inputAssessment": {
"<guardrail-id>": {
"sensitiveInformationPolicy": {
"piiEntities": [{"match": "test.user@example.com", "type": "EMAIL", "action": "BLOCKED", "detected": true}]
}
}
},
"actionReason": "Guardrail blocked."
}
}
}
出力側ブロック（outputAction: BLOCK）
「架空のユーザーのメールアドレスを1つ作って出力してください」というプロンプトを送ったケースです。入力にはメールアドレスが含まれないため入力評価は通過し、モデルが生成した応答が出力評価でブロックされています。
なお、モデル自体は呼ばれているにもかかわらず、レスポンスの usage は入力側ブロックと同じく 0 で返ってきました。課金上の扱いがどうなるかは本記事では確認していません。
{
"stopReason": "guardrail_intervened",
"output": {
"message": {
"content": [{"text": "この応答はポリシーによりブロックされました。"}]
}
},
"usage": {"inputTokens": 0, "outputTokens": 0, "totalTokens": 0},
"trace": {
"guardrail": {
"outputAssessments": {
"<guardrail-id>": [
{
"sensitiveInformationPolicy": {
"piiEntities": [{"match": "taro.yamada@example.com", "type": "EMAIL", "action": "BLOCKED", "detected": true}]
}
}
]
},
"actionReason": "No action.\nGuardrail blocked."
}
}
}
actionReason の 1 行目が入力評価（検出なし）、2 行目が出力評価（ブロック）に対応していると読めるため、入力側ブロックの "Guardrail blocked." と見分けられます。ただし actionReason は表示用の文字列なので、アプリケーションでどちら側のブロックかを判定する場合は、この文字列ではなく inputAssessment / outputAssessments のどちらに検出結果が入っているかで見る方が確実です。
ストリーミング（converse_stream + sync）
converse_stream でも guardrailConfig は同じ形で渡せます。streamProcessingMode には sync を指定しました。sync は出力側の Guardrail 評価が終わってからチャンクを返すモードで、async より応答は遅れますが、ブロック対象の内容がクライアントに流れてしまうことを避けられます。
入力評価でブロックされた場合も、イベント列は通常応答と同じ構造（messageStart 〜 metadata）で流れ、ブロック用メッセージが contentBlockDelta として届きます。
import boto3
client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
response = client.converse_stream(
modelId="global.xai.grok-4.6",
messages=[
{"role": "user", "content": [{"text": "私のメールアドレスはtest.user@example.comです。そのまま繰り返してください。"}]}
],
guardrailConfig={
"guardrailIdentifier": "<guardrail-id>",
"guardrailVersion": "<version>",
"trace": "enabled",
"streamProcessingMode": "sync",
},
)
for event in response["stream"]:
print(event)
PII の入力側ブロックが発火したときのイベント列です（実際は print ごとに dict が出力されますが、見やすさのため 1 つの配列にまとめています）。
[
{"messageStart": {"role": "assistant"}},
{"contentBlockDelta": {"delta": {"text": "このリクエストはポリシーによりブロックされました。"}, "contentBlockIndex": 0}},
{"contentBlockStop": {"contentBlockIndex": 0}},
{"messageStop": {"stopReason": "guardrail_intervened"}},
{"metadata": {
"usage": {"inputTokens": 0, "outputTokens": 0, "totalTokens": 0},
"trace": {
"guardrail": {
"inputAssessment": {
"<guardrail-id>": {
"sensitiveInformationPolicy": {
"piiEntities": [{"match": "test.user@example.com", "type": "EMAIL", "action": "BLOCKED", "detected": true}]
}
}
},
"actionReason": "Guardrail blocked."
}
}
}}
]
この入力側ブロックのケースでは、イベントを最後まで読む実装にしておけば、非ストリーミングと同じ判定材料（stopReason・inputAssessment・actionReason）が取れました。出力側ブロックがストリーミングでどのように流れるか（途中まで流れたチャンクの扱いなど）は、今回は未検証です。
まとめ
Amazon Bedrock の Grok 4.6 で Guardrails が動作したことを確認できました。
すでに Amazon Bedrock の Converse API と Guardrails を組み合わせて稼働しているワークロードでは、Guardrail 側がクロスリージョン推論（--cross-region-config）に対応した構成になっていれば、modelId の変更のみで既存の Guardrail 設定を流用できる可能性があります。
また、Grok の実行基盤の選定過程で Amazon Bedrock が候補に挙がっている場合は、IAM 認証やログ連携といった観点に加え、Guardrails も併せて評価いただくことをおすすめします。
