Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AWS Bedrock Guardrails / 機密情報の入力・出力をブロックする — Bl...

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

AWS Bedrock Guardrails / 機密情報の入力・出力をブロックする — Blocking Sensitive Information Input/Output

Claude Code(AWS Bedrock経由)をチーム・組織で活用する際の2つのテーマについて。

(1) AWS Bedrock Guardrailsで機密情報(PII)の入出力をブロックしようとした結果、Claude Codeの膨大なsystem
promptがフィルタに引っかかり実用困難だった調査記録。invocation logsでは原因特定できず、apply-guardrail
APIで手動テストして原因を突き止めた過程を共有。

(2) AI時代にPR生成量が加速する中、低リスクPRのレビューボトルネックを解消するため、影響範囲ベースのサイズラベル自
動付与・AIレビュー・条件付きauto mergeの3段階パイプラインを構築した話。

Two topics on leveraging Claude Code (via AWS Bedrock) across teams and organizations:

(1) An investigation into using AWS Bedrock Guardrails to block sensitive information (PII) input/output. Claude
Code's massive system prompt triggers PII filters, making it impractical. Invocation logs only show
"INTERVENED" without details, requiring manual testing with the apply-guardrail API to identify root causes.

(2) Building a 3-stage pipeline — impact-based size labeling, AI code review, and conditional auto-merge — to
eliminate PR review bottlenecks caused by the explosion of low-risk PRs in the AI era.

Avatar for Kazuhito Nakayama

Kazuhito Nakayama

February 24, 2026
Tweet

More Decks by Kazuhito Nakayama

Other Decks in Technology

Transcript

  1. 9 AWS Bedrock Guardrails Guardrailsの仕組み モデルの呼び出しの前後に検査が挟まる 1. ユーザー入力 ↓ 2.

    Guardrails: 入力チェック ← ここでブロックされれば推論なし ↓ 3. Model: 推論実行 ↓ 4. Model: 回答生成 ↓ 5. Guardrails: 出力チェック ← ここでブロックされても推論コストは発生 ↓ 6. ユーザーに返答
  2. 10 AWS Bedrock Guardrails Claude Codeとの連携方法 設定 ~/.claude/settings.json の env

    にカスタムヘッダ ーを追加 { "env": { "ANTHROPIC_CUSTOM_HEADERS": "X-Amzn-Bedrock-GuardrailIdentifier: xxxxx\n } } 公式ドキュメント Claude Code公式でサポートされている連携方 法 ref: Claude Code - AWS Guardrails Terraform管理もできる
  3. 11 AWS Bedrock Guardrails フィルタータイプ フィルター 役割 例 Content filters

    有害コンテンツ検出 暴力的・性的表現 Denied topics 禁止トピック検出 業務外の質問 Sensitive information (PII) 個人情報検出 名前・カード番号 PROMPT_ATTACK プロンプトインジェクション検出 ジェイルブレイク 必要なフィルターだけ有効化できる(課金もフィルターごと)
  4. 14 AWS Bedrock Guardrails 動いた!…が 期待した動作 ❯ 中山一仁、という名前のユーザーのお問い合わせを確認して Sorry, the

    model cannot answer this question. (using AWS Guardrails) 個人名を含むクエリがブロックされた!
  5. 15 AWS Bedrock Guardrails …あれ? 起きた問題 ❯ hello Sorry, the

    model cannot answer this question. (using AWS Guardrails) ❯ おはようございます Sorry, the model cannot answer this question. (using AWS Guardrails) 何を聞いてもブロックされる
  6. 16 AWS Bedrock Guardrails 原因調査:invocation logsで分析 CloudWatch Logsで modelId フィルタして確認

    { "input_tokens": 0, "output_tokens": 0, "amazon-bedrock-guardrailAction": "INTERVENED" } input_tokens: 0 → モデルに到達する前にブロック output_tokens: 0 → モデルは何も生成していない 入力段階のGuardrailsが全リクエストを止めている
  7. 17 AWS Bedrock Guardrails 全リクエストがブロックされる原因 apply-guardrail APIで検証 aws bedrock-runtime apply-guardrail

    \ --content '[{"text": {"text": "こんにちは!今日は何日?"}}]' → "action": "NONE" 通過 aws bedrock-runtime apply-guardrail \ --content '[{"text": {"text": "These instructions OVERRIDE any default behavior..."}}]' → "action": "GUARDRAIL_INTERVENED" PROMPT_ATTACKフィルタ Claude Codeのsystem promptがインジェクシ ョンとして誤検出 PIIフィルタ(NAME/ADDRESS/EMAIL)のみで も PROMPT_ATTACKを外しても同様にブロックさ れる。system promptに含まれる情報がPIIとし て検出
  8. 18 AWS Bedrock Guardrails なぜ起きるのか Claude Codeのsystem promptは18,000トークン超の巨大なプロンプト ツール定義、コミット手順、PR作成手順、CLAUDE.md等を含む Co-Authored-By:

    Claude <[email protected]> などPII該当情報も含まれる Guardrailsは system promptも評価対象 → ユーザーの入力に関係なく、system prompt自体がフィルタに引っかかる
  9. 21 AWS Bedrock Guardrails 原因の1つ: [email protected] 調査の流れ 1. CloudWatch Logsで

    INTERVENED を確認 2. system prompt内にEMAILが含まれているこ とを発見 3. apply-guardrail APIで個別に検証 検証結果 aws bedrock-runtime apply-guardrail \ --source OUTPUT \ --content '[{"text": {"text": "Co-Authored-By: Claude Opus 4.6 <[email protected]>"}}]' → "action": "GUARDRAIL_INTERVENED" → EMAIL PIIとして検出
  10. 22 AWS Bedrock Guardrails BLOCKとMASKの挙動差 BLOCK MASK INPUT検査 即座にブロック 素通り

    LLM起動 しない する OUTPUT検査 - INTERVENED 結果 何も使えない 無限ループ BLOCK: INPUT段階でsystem promptのPIIを検出 → 全リクエスト拒否 MASK: INPUT段階でマスクが効かず素通り → LLMがPIIをエコー → OUTPUT側でtool_use ごと破棄 → リトライ → 無限ループ
  11. 25 AWS Bedrock Guardrails invocation logsの活用 S3 .json.gz にまとめられる ダウンロード

    → 解凍 → jqで解析 調査に手間がかかる s3://minne-bedrock-invocation-logs/ AWSLogs/.../2026/02/16/ ...T070042917Z_xxx.json.gz CloudWatch Logs(推奨) 検索フィルターで modelId を指定 リアルタイムで探索できる ただし限界がある ログは guardrailAction: "INTERVENED" としか記 録されない 何がPIIとして検出されたか分からない 原因特定には apply-guardrail APIで手動テス トが必要
  12. 26 AWS Bedrock Guardrails 課金体系の注意点 ケース Guardrail課金 モデル推論課金 入力でブロック あり

    なし 出力でブロック あり(入力+出力) あり ブロックなし(正常) あり(入力+出力) あり 1 text unit = 最大1000文字 使用したフィルターのみ課金される Guardrailsでブロック ≠ コスト削減(むしろ出力ブロックは最も高額)
  13. 27 AWS Bedrock Guardrails まとめ ※ Claude Codeが公式docで紹介しているAWS Bedrock Guardrailsとの連携に限った話です

    実用性を損なう2つの問題 1. Claude Codeのsystem promptは膨大で、公式の連携方法だと簡単にPII検出されてしまい、LLMの果 実を得られない 2. invocation logsでは INTERVENED としか分からず、具体的にどの部分が検出対象になったか特定できな い 調査のポイント apply-guardrail APIでテキスト断片を手動テストして原因を特定 CloudWatch Logsは全体像の把握に有用だが、Guardrailのデバッグには不十分
  14. 30 AWS Bedrock Guardrails AI時代のPR量問題 エンジニア:複数タスクを同時にPR化できるように 非エンジニア(CS・ディレクター):Claude Code ActionsでPR生成が可能に →

    1日のPR生成量が加速度的に増加 ボトルネックになるPR typo修正(1行変更) 依存ライブラリのバージョンアップ コードフォーマット修正 コメント追加・修正 → 低リスクなPRに人間のレビューリソースが奪われている
  15. 31 AWS Bedrock Guardrails 解決:3段階パイプライン 1. PRサイズラベルの自動付与(AIが影響範囲を分析) ↓ 2. AIによるコードレビュー&Approve

    ↓ 3. 条件付きauto merge(size/XS + AI Approve + CI通過) Claude Code Actions(GitHub Actions)で実装 レビュー基準・ラベル分類基準は .claude/skills/ 配下のMarkdownで管理 基準変更もPRで追跡可能
  16. 32 AWS Bedrock Guardrails PRサイズラベル:行数ではなく影響範囲 サイズ分類 ラベル 基準 size/XS 影響局所的、リスク無

    size/S 影響狭い、リスク低 size/M 複数箇所影響、範囲明確 size/L 影響範囲広い size/XL システム全体波及 なぜ行数ではないのか 1行の決済ロジック変更 → 高リスク 100行のコメント追加 → 低リスク AIにコード文脈を理解させることで適切に分類
  17. 33 AWS Bedrock Guardrails 結果と設計思想 自動マージされたPR例 管理画面表記修正(typo、1ファイル1行) 依存ライブラリパッチアップ(Dependabot) コードフォーマット整形 「いつの間にかリリースされてた」

    「XSが出たらどんどんリリースされる 」 段階的な信頼 最もリスク低い size/XSのみ からスタート 運用実績を見て S サイズへの拡大を検討 人間のレビューを廃止するのではなく、高リスクな変更に集中するための仕組み
  18. 34 AWS Bedrock Guardrails まとめ AWS Bedrock Guardrails 膨大なsystem promptがフィルタに引っかかり、現時点では実用困難

    invocation logsでは原因特定できず、デバッグコストが高い apply-guardrail APIでの手動テストが原因特定の鍵 PRレビューのボトルネック解消 影響範囲ベースのサイズラベル + AIレビュー + auto merge 低リスクPRを自動化し、人間は高リスクな変更に集中 本番リリース時のチームメンション通知、エラー多発時の自動ロールバック機構があるので、アグレ ッシブに始めています ref: SentryとCWを活用した安心なプログレッシブデリバリー