AWS Bedrock Guardrails 機密情報の入力・出力をブロックする 中山一仁 / GMOペパボ SUZURI・minne事業部 2026-02-24 

2 自己紹介 中山一仁 / GMOペパボ株式会社 minne事業部 ハンドメイドマーケット「minne」の開発 Claude Code（AWS Bedrock経由）の社内活用を推進 Claude Code Actionsの導入と活用推進 

自身でのClaude Code活用 はもちろん、チーム・組織 でのClaude Code活用によ り強い関心 

ということで、私の今日の お話もチーム・組織で Claude Codeをどのように 活用するか、について焦点 を当てた内容となります 

背景 minneにおけるAI活用と課題 

6 AWS Bedrock Guardrails minneとClaude Code minneではClaude Code（AWS Bedrock経由）を業務に活用 CS（カスタマーサポート） もClaude Code Actionsで問い合わせ調査を実施 現在の業務フロー 

7 AWS Bedrock Guardrails 課題：個人情報の入出力リスク CSがお問い合わせ内容を調査する際、ユーザーの個人情報に触れる場面がある 細心の注意を払っていても、パーソナルな情報を入力してしまう可能性 入力も出力もガードしたい 機密情報の入力をそもそも許したくない 機密情報がレスポンスとして返却されることも許したくない → AWS Bedrock Guardrails で解決できるのでは？ 

AWS Bedrock Guardrails 仕組みと設定方法 

9 AWS Bedrock Guardrails Guardrailsの仕組み モデルの呼び出しの前後に検査が挟まる 1. ユーザー入力 ↓ 2. Guardrails: 入力チェック ← ここでブロックされれば推論なし ↓ 3. Model: 推論実行 ↓ 4. Model: 回答生成 ↓ 5. Guardrails: 出力チェック ← ここでブロックされても推論コストは発生 ↓ 6. ユーザーに返答 

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管理もできる 

11 AWS Bedrock Guardrails フィルタータイプ フィルター 役割 例 Content filters 有害コンテンツ検出 暴力的・性的表現 Denied topics 禁止トピック検出 業務外の質問 Sensitive information (PII) 個人情報検出 名前・カード番号 PROMPT_ATTACK プロンプトインジェクション検出 ジェイルブレイク 必要なフィルターだけ有効化できる（課金もフィルターごと） 

これはめっちゃ便利やな 

やってみた結果 期待と現実のギャップ 

14 AWS Bedrock Guardrails 動いた！…が 期待した動作 ❯ 中山一仁、という名前のユーザーのお問い合わせを確認して Sorry, the model cannot answer this question. (using AWS Guardrails) 個人名を含むクエリがブロックされた！ 

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) 何を聞いてもブロックされる 

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が全リクエストを止めている 

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とし て検出 

18 AWS Bedrock Guardrails なぜ起きるのか Claude Codeのsystem promptは18,000トークン超の巨大なプロンプト ツール定義、コミット手順、PR作成手順、CLAUDE.md等を含む Co-Authored-By: Claude などPII該当情報も含まれる Guardrailsは system promptも評価対象 → ユーザーの入力に関係なく、system prompt自体がフィルタに引っかかる 

PII検出の深掘り 

20 AWS Bedrock Guardrails Claude Codeユーザーお馴染み 

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 "}}]' → "action": "GUARDRAIL_INTERVENED" → EMAIL PIIとして検出 

22 AWS Bedrock Guardrails BLOCKとMASKの挙動差 BLOCK MASK INPUT検査 即座にブロック 素通り LLM起動 しない する OUTPUT検査 - INTERVENED 結果 何も使えない 無限ループ BLOCK: INPUT段階でsystem promptのPIIを検出 → 全リクエスト拒否 MASK: INPUT段階でマスクが効かず素通り → LLMがPIIをエコー → OUTPUT側でtool_use ごと破棄 → リトライ → 無限ループ 

23 AWS Bedrock Guardrails MASKの無限ループの様子 

学びと知見 調査を通じて得られたもの 

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で手動テス トが必要 

26 AWS Bedrock Guardrails 課金体系の注意点 ケース Guardrail課金 モデル推論課金 入力でブロック あり なし 出力でブロック あり（入力+出力） あり ブロックなし（正常） あり（入力+出力） あり 1 text unit = 最大1000文字 使用したフィルターのみ課金される Guardrailsでブロック ≠ コスト削減（むしろ出力ブロックは最も高額） 

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のデバッグには不十分 

28 AWS Bedrock Guardrails おまけ 

PRレビューのボトルネック 人間がボトルネックなので、仕組みでなんとかする 

30 AWS Bedrock Guardrails AI時代のPR量問題 エンジニア：複数タスクを同時にPR化できるように 非エンジニア（CS・ディレクター）：Claude Code ActionsでPR生成が可能に → 1日のPR生成量が加速度的に増加 ボトルネックになるPR typo修正（1行変更） 依存ライブラリのバージョンアップ コードフォーマット修正 コメント追加・修正 → 低リスクなPRに人間のレビューリソースが奪われている 

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で追跡可能 

32 AWS Bedrock Guardrails PRサイズラベル：行数ではなく影響範囲 サイズ分類 ラベル 基準 size/XS 影響局所的、リスク無 size/S 影響狭い、リスク低 size/M 複数箇所影響、範囲明確 size/L 影響範囲広い size/XL システム全体波及 なぜ行数ではないのか 1行の決済ロジック変更 → 高リスク 100行のコメント追加 → 低リスク AIにコード文脈を理解させることで適切に分類 

33 AWS Bedrock Guardrails 結果と設計思想 自動マージされたPR例 管理画面表記修正（typo、1ファイル1行） 依存ライブラリパッチアップ（Dependabot） コードフォーマット整形 「いつの間にかリリースされてた」 「XSが出たらどんどんリリースされる 」 段階的な信頼 最もリスク低い size/XSのみ からスタート 運用実績を見て S サイズへの拡大を検討 人間のレビューを廃止するのではなく、高リスクな変更に集中するための仕組み 

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

Thank you! ご質問・フィードバックはお気軽にどうぞ