Claude CodeでBedrock Guardrailsを設定しコンテンツをフィルタリングする
Claude CodeでAmazon Bedrock Guardrailsのコンテンツフィルタリングを設定する手順と、クロスリージョン推論・ゲートウェイ配信時の注意点をまとめます。
Amazon Bedrock Guardrailsは、Bedrock経由で使うClaude Codeにコンテンツフィルタリングを組み込む仕組みです。Claude Code側に専用の設定画面があるわけではなく、Bedrockコンソールで作ったGuardrailをカスタムヘッダーとして渡すだけの薄い統合です。手順自体は短いですが、クロスリージョン推論との組み合わせや、組織配布時の承認ダイアログでつまずきやすい点があります。
Bedrock Guardrailsとは何か
Amazon Bedrock Guardrailsは、AWS側が提供するコンテンツフィルタリング機能です。有害コンテンツの検出やトピックの制限といったポリシーをBedrockコンソール上で定義し、モデル呼び出しに適用します。Claude Code自身はGuardrailの中身(フィルタリング条件)を関知しません。役割は、リクエストにGuardrailを指定する2つのヘッダーを載せて送るだけです。
前提として、/setup-bedrockウィザードの手順などでBedrock経由のClaude Codeがすでに動いている必要があります。Guardrailsはこの上に載せる追加のレイヤーで、Bedrock自体の設定を代替するものではありません。
Guardrailの作成からヘッダー設定までの3ステップ
手順は次の3段階です。
- Amazon BedrockコンソールでGuardrailを作成する
- 作成したGuardrailのバージョンを発行する(ヘッダーに書くGuardrailバージョンは、発行済みバージョンを指しているか確認します)
- 発行したGuardrail IDとバージョン番号を、Claude Codeの設定ファイルに
ANTHROPIC_CUSTOM_HEADERS環境変数として追加する
3つ目のステップでどの設定ファイルに書くかは、適用したい範囲で選びます。自分だけの検証なら~/.claude/settings.json(ユーザー設定、そのマシンの全プロジェクトに効く)、チーム全員に同じGuardrailを使わせたいならリポジトリ直下の.claude/settings.json(シェアードプロジェクト設定、コミットして配布)に書きます。どちらも通常のプロジェクト設定として適用されるだけで、後述する組織配信時の承認ダイアログの対象にはなりません。ただし共有プロジェクト設定は、そのワークスペースを信頼する前は適用されません。メンバーが該当ディレクトリを初めて開いたときのワークスペース信頼を経て初めて、コミットしたGuardrailのヘッダーが効きます。設定ファイルへの追記例は次のとおりです。
{
"env": {
"ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: your-guardrail-id\nX-Amzn-Bedrock-GuardrailVersion: 1"
}
}ANTHROPIC_CUSTOM_HEADERSはClaude Code v2.1.227以降で使える環境変数で、改行区切りで複数のヘッダーを1つの値にまとめる仕組みです。Guardrail専用ではなく、他のカスタムヘッダーを送りたいときにも使う汎用の変数です。値にHTTPヘッダーが扱えない文字(改行・NULバイト・スマートクォートやゼロ幅スペースなどU+00FF超の文字)が混じっていると、Invalid ANTHROPIC_CUSTOM_HEADERSという送信前チェックで弾かれます。ただしこのチェックは、Claude APIへ直接送るときとLLMゲートウェイ経由のときにしか走りません。Amazon Bedrockのようなサードパーティのクラウド経由では、この送信前チェック自体がスキップされます。Guardrail IDをドキュメントからコピー&ペーストして不可視文字が紛れ込んでいても、Claude Code側では検知されずそのままAWS側へ送信されるため、原因の切り分けがしづらくなります。値は手で打ち直すか、コピー元を信頼できるプレーンテキストに限定するのが安全です。
Claude CodeのBedrock利用に必要なIAMポリシーは、通常bedrock:InvokeModelとbedrock:InvokeModelWithResponseStreamを軸にした標準的な構成です。Guardrailはこの呼び出しに乗せるヘッダーとして働くため、公式ドキュメントにGuardrail専用の追加IAMアクションは明記されていません。IAM側で新たにポリシーを足す前に、まずヘッダー設定だけで動くかを確認するのが手戻りが少ない進め方です。
クロスリージョン推論プロファイルを使うなら追加設定が要る
Claude CodeはBedrockのInvoke APIで、モデルIDをリージョンごとの接頭辞(us. eu. apac. global.など)を持つクロスリージョン推論プロファイルに解決してから呼び出します。既定のモデルはこの仕組みでリクエストごとに異なるリージョンへ流れうるため、Guardrail側でもCross-Region inferenceを有効にしておかないと、リクエストが実際に処理されるリージョンとGuardrailの適用範囲がずれる可能性があります。自前の推論プロファイルにモデルをマッピングして固定リージョンで運用している場合でも、この設定は確認しておく価値があります。
X-Amzn-Bedrock-*ヘッダーは承認ダイアログの対象になる
ANTHROPIC_CUSTOM_HEADERSを個人の設定ファイルではなく組織側から配信する場合、ヘッダーの中身によって承認ダイアログの要否が変わります。タグ付け目的の汎用ヘッダー(Accept-Languageなど)は確認なしで適用されますが、認証情報・組織識別子・ルーティングやAPIの挙動に関わるヘッダーは配信のたびにユーザーの承認が必要です。X-Amzn-Bedrock-GuardrailIdentifierとX-Amzn-Bedrock-GuardrailVersionはどちらも後者に含まれ、開発者は初回起動時に「この設定が何を変更しようとしているか」を示すダイアログを見ることになります。
組織がGuardrailのヘッダーを個々の設定ファイルではなくClaude apps gatewayのポリシー経由で配信している場合も扱いは同じで、承認が必要な設定として扱われます。ゲートウェイ経由の配信を採用しているチームは、Guardrailを追加・変更するたびに開発者側の承認ステップが発生する前提で展開計画を立てる必要があります。
Guardrailの配信経路をどう選ぶか
| 経路 | 誰が管理するか | 承認ダイアログ | 向いている場面 |
|---|---|---|---|
個人の~/.claude/settings.json | 誰が管理するか開発者本人 | 承認ダイアログ出ない(自分の変更なので確認不要) | 向いている場面個人の検証・自分のマシンだけで試したい |
共有プロジェクトの.claude/settings.json(コミット) | 誰が管理するかリポジトリの誰か(チームで管理) | 承認ダイアログ出ない(通常のプロジェクト設定として適用。ただしワークスペースを信頼するまでは未適用) | 向いている場面そのリポジトリを触るチーム全員に同じGuardrailを配りたい |
server-managed settings / managed-settings.json | 誰が管理するか組織の管理者 | 承認ダイアログ配信のたびに開発者が承認 | 向いている場面部門・組織単位でGuardrailを統一したい |
| Claude apps gatewayのポリシー | 誰が管理するかゲートウェイ運用者 | 承認ダイアログ配信のたびに開発者が承認 | 向いている場面すでにゲートウェイでマルチクラウドをSSO統合している組織 |
これらは重ねて使えますが、優先度は固定です。managed設定が最も強く、次いでコマンドライン指定、プロジェクトローカル(.claude/settings.local.json)、共有プロジェクト(.claude/settings.json)、ユーザー(~/.claude/settings.json)の順に弱くなります。自分の~/.claude/settings.jsonでGuardrailのヘッダーを変えても、組織がmanaged設定で別のGuardrailを配信している場合はそちらが勝ちます。「ヘッダーを書き換えたのに反映されない」と感じたら、自分より優先度の高い設定ファイルで同じANTHROPIC_CUSTOM_HEADERSが定義されていないか確認してください。
GuardrailsはBedrock経由のときだけ有効
GuardrailsはAmazon Bedrock Invoke APIのヘッダーとして実装されている機能なので、Bedrock以外の面では使えません。Google Cloud's Agent Platform(旧Vertex AI)やMicrosoft Foundry、Anthropic直接APIを経由するセッションには、この仕組みそのものが存在しません。各プロバイダーで使える機能の違いはClaude Codeの機能比較 — Bedrock・Vertex・Foundry別対応表にまとめてあります。マルチクラウドでClaude Codeを展開していて、Bedrock以外の面でもコンテンツフィルタリングが要る場合は、各クラウド側が提供する同等機能を個別に確認してください。
BedrockにはInvoke APIとは別にMantleエンドポイントもありますが、公式ドキュメントはGuardrailsとMantleの組み合わせを明記していません。Mantle経由で運用している場合は、ヘッダーが実際に適用されるかを個別に確認したうえで展開してください。
よくあるつまずき
- 発行前のGuardrailをヘッダーに指定してしまう: ヘッダーに書くバージョンが発行済みバージョンを指しているか、コンソール側で確認します。Guardrail IDとバージョン番号は別々の値なので、どちらか一方だけ更新して食い違わせないよう注意します
- クロスリージョン推論との不一致に気づかない: Guardrail側でCross-Region inferenceを有効にし忘れると、モデル呼び出しのリージョンとGuardrailの適用範囲が食い違う可能性があります
- 組織配信後に承認待ちで止まっていると誤解する:
X-Amzn-Bedrock-*ヘッダーは承認ダイアログの対象なので、配信直後に全開発者へ一括で効くわけではありません。各自が初回起動時に承認するまでは適用されません
まとめ
Bedrock GuardrailsはBedrockコンソールで作成・発行し、ANTHROPIC_CUSTOM_HEADERSにIDとバージョンを載せるだけでClaude Codeに適用できます。クロスリージョン推論プロファイルを使っているならGuardrail側のCross-Region inferenceも有効にし、組織配信ではヘッダーが承認ダイアログの対象になる前提で展開を計画してください。この機能はBedrock経由のセッションに限られ、Vertex/FoundryやAnthropic直接APIには存在しません。