Bedrock ガードレールをコード生成の境界で適用する設計

AWSが、Amazon Bedrock ガードレールをコード生成へ適用する際、ストリームの全断片を検査するのではなく、信頼境界で検査する設計を紹介しました。安全性とスループットを両立するための実装指針です。

要点

• ガードレール消費量は文字数と有効な保護策種別の積で増える
• 長いストリームを細かく検査するとクォータとコストを急速に消費する
• 利用者入力、完成成果物、ファイル保存・コミット前を検査点にする
• 機密情報、プロンプト攻撃、禁止話題をリスク別に分ける

今回のブログ記事で語られていること

Bedrock ガードレールはプロンプト攻撃、個人情報や認証情報、危険内容、禁止話題を検出できます。ただしコード生成は通常の短いチャットより出力が長く、セッションが続き、複数開発者が同時に使い、同じシステムプロンプトや過去コンテキストを繰り返し送ります。記事の例では15人が各関数約5,000文字を生成し、50文字ごとにガードレールを評価すると毎秒1,500 リクエストになります。さらに3種類の保護策を有効にすると、評価するテキスト単位も3倍になります。

消費の基本単位は1,000文字です。一つのポリシー内の分類数ではなく、内容フィルター、禁止話題、機密情報フィルターなど異なるポリシー種類ごとに乗算されます。従って短い試行で問題がなくても、チーム全体へ広げると流量制限が起こり、応答が途中で止まる可能性があります。クォータ追加だけではなく、評価頻度と検査対象を変える必要があります。

AWSが示す中心的な方式はコミット前フック型です。モデルが生成する全トークンを逐次で検査する代わりに、信頼されていないな利用者入力が入る時、完成したコード成果物を表示・保存する時、リポジトリへコミットする時など、信頼水準が変わる境界でApplyGuardrailを使います。途中の思考や未完成コードを繰り返し検査せず、共有・実行される完成物へ重点を置きます。ただし即時に危険なツールを実行するエージェントでは、ツール呼び出し前など追加境界が必要です。リスクの高いワークフローへ一律に検査を減らすのではなく、実行可能性とデータ機密度に合わせて組み合わせます。

段階ごとの検査件数と文字量を記録しておけば、クォータ追加が必要なのか、検査位置の見直しが必要なのかを切り分けやすくなります。

今回のブログ記事が関係する人

AI コーディングアシスタント、Claude Code on Bedrock、コード生成 APIを運用する基盤・セキュリティチームに関係します。実測の文字数、同時利用者、ポリシー種類、ストリーム断片、クォータを使って処理能力を計算してください。

結局、今回のブログ記事をどう読むべきか

ガードレールを多く呼ぶほど安全とは限りません。危険が確定する境界へ検査を置き、途中データの重複評価を減らしながら、保存・実行される成果物は必ず検査する設計が要点です。