Amazon Bedrock ガードレール、エージェント型 loop向けのInvokeGuardrailChecks APIを追加

AWS は 2026年6月16日、Amazon Bedrock ガードレール の新しい InvokeGuardrailChecks API を発表しました。エージェント型 AIアプリケーションの任意のステップで個別の安全性チェックを呼び出し、アプリケーション側でしきい値や対応を決められるようにする更新です。

要点

• InvokeGuardrailChecks API は、ガードレールリソースを事前作成せずに、個別の保護策をリクエスト単位で実行できます。
• APIはdetect-onlyで動作し、ブロックやマスクを自動実行せず、数値スコアを返します。
• content filters、プロンプト attack detection、sensitive information filtersに対応します。
• プロンプト attack detectionは、jailbreak、プロンプト injection、プロンプト leakageを個別カテゴリとして扱えます。
• bedrock:InvokeGuardrailChecks はリソース不要 APIのため、IAMでは Resource: "*" が必要になり、リージョンやネットワーク条件で絞る設計が説明されています。

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

InvokeGuardrailChecks API は、Amazon Bedrock ガードレールをエージェントの多段処理に合わせて使いやすくする更新です。従来の単純な生成AIアプリケーションでは、ユーザー入力を受け、モデルが応答し、その前後に同じガードレールを当てる構成でも十分な場合があります。しかし、エージェント型 AIでは、ユーザー入力、計画、ツール呼び出し、ツール結果、再計画、最終応答がループし、それぞれのステップでリスクが変わります。たとえば、最初の入力ではプロンプト injection、ツール結果では外部データ由来の不正な指示、最終応答では有害表現や個人情報漏えいを見たい、というように確認点が分かれます。

新APIの特徴は、ガードレールリソースを作ってバージョン管理してから適用するのではなく、必要なチェックをリクエスト内で指定できることです。AWSはこれをリソース不要な設計として説明しています。エージェントの一時的な中間ステップごとにガードレールリソースを作成・削除する運用は現実的ではありません。InvokeGuardrailChecks なら、たとえば「このツール出力だけPIIを確認する」「このシステム/ユーザーペアだけプロンプト leakageを確認する」といった使い方に寄せられます。

もう一つ重要なのは、APIがdetect-onlyである点です。APIは検出結果とスコアを返しますが、ブロック、マスク、書き換えを自動では行いません。content filtersやプロンプト attack detectionでは重大度 score、sensitive information filtersでは信頼度 scoreが返り、いずれも0から1の離散的な値として示されます。これにより、アプリケーション側は「高スコアならブロック」「中間なら人手レビュー」「低スコアなら監査ログだけ残す」といった業務別の対応を実装できます。

ただし、自由度が高い分、設計責任も利用側に移ります。detect-onlyである以上、スコアを見て何もしなければ安全性は上がりません。どのカテゴリをどのステップで見るのか、どのスコアで止めるのか、例外時に再試行するのか、人へ回すのか、ログへ残すのかを明確にする必要があります。特に複数ツールを使うエージェントでは、ユーザー入力だけでなく、ツール結果やモデルの中間出力も評価対象に入れるべきです。

IAM面では、リソース不要 APIであるため、ポリシー上のリソースは * になります。AWSは、これが他のBedrockリソースへのアクセスを広げるものではなく、bedrock:InvokeGuardrailChecks だけに適用されると説明しています。そのうえで、aws:RequestedRegion、aws:SourceIp、aws:SourceVpc、aws:PrincipalTag などで利用範囲を狭めることが推奨されます。安全性チェックのAPI自体も、誰でも呼べる補助機能ではなく、エージェント基盤の重要な統制点として管理したいです。

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

Amazon Bedrock ガードレールをエージェントやアプリケーションの途中ステップで使いたい開発者、セキュリティレビュー担当、運用担当に関係します。入力と出力の最終チェックだけでなく、ツール実行前後の安全確認を設計するチーム向けです。

実務で確認したいポイント

• エージェントの入力、計画、ツール呼び出し、ツール結果、最終応答ごとに、どの保護策を実行するかを決める。
• detect-onlyのスコアに対して、block、再実行、human 確認、ログなどの対応を実装する。
• プロンプト attack detection、PII検出、有害コンテンツ検出を同じ基準で扱わず、ステップごとのしきい値を分ける。
• bedrock:InvokeGuardrailChecks のIAM権限を、リージョン、ネットワーク、PrincipalTagなどで絞る。
• 監査ログに、チェック対象、スコア、実行した対応を残せるか確認する。

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

InvokeGuardrailChecks API は、エージェント型 AIの安全性確認を「一つの固定ガードレール」から「ループ内の各地点で必要な検査を行う仕組み」へ近づける更新です。便利な一方で、APIが返すのは判断材料であり、最終的な停止・継続・レビューの設計は利用者側に残ります。Bedrockで複数ステップのエージェントを作るチームは、機能追加としてではなく、実行制御と監査の設計材料として読むべきです。