AIエージェントの各ステップに安全策を乗せる — Bedrock Guardrails新API（InvokeGuardrailChecks）と3形態の使い分け
Amazon Bedrock Guardrails に新API InvokeGuardrailChecks が追加されました。guardrailリソースを作らず（リソースレス）、エージェントの各ステップにリクエスト単位で安全策を適用でき、ブロックはせず（detect-only）severityスコアを返すので遮断はアプリ側で実装します。インライン／ApplyGuardrail／InvokeGuardrailChecks の3形態の使い分け、対応する3ポリシー（コンテンツフィルタ・プロンプト攻撃・PII）、各ステップ適用のコスト設計、Strands Agents/自前ループへの組み込みを、AWSフリーランス実務目線で整理します。対応ポリシーの線引きや料金は公式の最新情報もご確認ください。
- #Amazon Bedrock
- #Guardrails
- #生成AI
- #AIエージェント
- #LLMセキュリティ
- #プロンプトインジェクション
私自身、生成AIエージェント（自分でツールを呼びながら多段でタスクを進める生成AI）を本番に載せる相談を受けるたびに、安全策を「どの段で・どうかけるか」で悩む場面が少なくありません。エージェントは「入力 → ツール呼び出し → モデル生成 → 出力」を何段も回します。入口に一律のガードレール（不適切な入出力を検査・制御する仕組み）を一度かけるだけでは、途中の各ステップで起きることまでは見きれない、というのが実感です。
2026年6月16日、その課題に効きそうな発表がありました。Amazon Bedrock Guardrails に新しいAPI InvokeGuardrailChecks が追加された、というものです。この記事では、Guardrails の3つの形態をどう使い分けるか、新APIで各ステップにどう安全策を乗せるか、そして「自動ブロックはしない（detect-only）」という挙動をどう正しく扱うか、コスト設計と対応ポリシーの線引きまで、実装目線で整理してみましょう。煽らず、断定できないところは正直に「公式をご確認ください」と書きます。なお、安全策は「これを入れれば完全に防げる」というものではなく、多層防御の一部だという前提で読んでください。
背景：エージェントは多ステップ、一律ガードレールが合わない
まず、エージェントで気をつけたいリスクを挙げます。不適切なトピックや有害な出力、個人情報（PII）の漏れ、そして プロンプトインジェクション（悪意ある指示を紛れ込ませてモデルの振る舞いを乗っ取ろうとする攻撃）などです。
従来のガードレールは、モデル呼び出しの入口・出口にまとめてかける使い方が中心でした。しかしエージェントは多段で動くため、「このツール呼び出しの前だけ厳しく見たい」「中間生成だけ別の基準で確認したい」といった、ステップごとの細かい制御がしたくなります。今回の新APIは、まさにこの「各ステップに軽く挟む」用途に向いた追加だと位置づけられます。
Guardrails 3形態の使い分け
Bedrock Guardrails には、今回の追加で3つの形態ができました。優劣ではなく、役割の違いとして押さえると選びやすくなります。
表にも整理しておきます。
| 形態 | リソース | ブロック | 適用単位 | 主な使いどころ |
|---|---|---|---|---|
インライン（Converse guardrailConfig） | 要 | 自動ブロック/マスク | モデル呼び出しに統合 | Converse/Invoke対応モデルで定常的に適用 |
ApplyGuardrail | 要 | 自動ブロック/マスク | 任意テキスト（モデル独立） | 恒久ポリシーの自動強制／非Converseモデルのラップ |
InvokeGuardrailChecks（新） | 不要 | しない（detect-only） | リクエスト単位・各ステップ | エージェント各ステップを軽量に検知（遮断はアプリ実装） |
ここで インライン は Converse の guardrailConfig にガードレールを統合する形、ApplyGuardrail はガードレールのリソースを使って任意のテキストを単独で検査する形です。ApplyGuardrail はモデルから独立して呼べるため、Converse 非対応のモデル（たとえば Grok）でも入出力を前後で挟んで使えます。判断の軸はシンプルで、「恒久的なポリシーで自動的に遮断したいなら ApplyGuardrail、エージェントの各ステップを軽く検知したいなら InvokeGuardrailChecks」です。
新API（InvokeGuardrailChecks）で各ステップに安全策を乗せる
ここが実装の本題です。新しい InvokeGuardrailChecks は、bedrock-runtime クライアントから invoke_guardrail_checks(messages, checks) のように呼び出します。ガードレールのリソースを事前に作る必要がなく（リソースレス）、評価したいテキストと走らせたいチェックを渡すだけで結果が返ります。モデル呼び出しも不要です。
組み込み先はAgentCore（エージェントの本番運用基盤）に限りません。公式の解説では Strands Agents（エージェント開発のフレームワーク）の hook（処理の節目に自分のコードを差し込む仕組み）として、BeforeInvocationEvent／AfterToolCallEvent／AfterInvocationEvent といったタイミングでチェックを挟む例が示されています。つまり、自前やサードパーティのエージェントループにも組み込めます。
対応する安全策は3種類です。コンテンツフィルタ（hate／violence／sexual／insults／misconduct）、プロンプト攻撃検知（jailbreak・prompt injection・prompt leakage を独立したチェックとして評価）、そして 機微情報（PII）フィルタ（メールアドレスや電話番号、クレジットカード番号など31種類）です。ひとつ正確に書いておきます。denied topics（禁止トピック）・contextual grounding（根拠に基づくか）・word filters（語句フィルタ）は、この新APIの対象ではありません。これらが要る場合は、従来のリソースベース（ApplyGuardrail やインライン）を併用します。この線引きはプレビュー期で動く可能性があるため、利用前に公式の最新情報をご確認ください。
detect-onlyの正しい扱い：遮断はアプリ実装＝多層防御
新APIで最も誤解しやすいのが、detect-only（検知のみ）という挙動です。InvokeGuardrailChecks は、ブロックもマスクも書き換えもしません。各チェックについて 0〜1の離散的な severity スコア（0／0.2／0.4／0.6／0.8／1.0）（どれだけ強く該当したかの度合い）を返すだけです。
つまり、スコアを受け取った後に、しきい値の判定・遮断・再試行・マスキング・ログ記録を自分のアプリで実装する必要があります。「このAPIを入れれば安全」ではなく、「検知 → しきい値 → アクション」を自分で設計してこそ機能する、という性格のものです。だからこそ、ガードレールはあくまで多層防御の一要素として位置づけ、これだけで完全に防げると考えないことが大切です。裏を返せば、しきい値やアクションを用途に合わせて細かく決められる柔軟さがある、とも言えます。
コスト設計：各ステップ適用の料金
各ステップで呼ぶとなると、気になるのがコストです。新APIには専用の料金体系があります（per 1,000 text units・2026年6月17日時点の参考値）。
| チェック | 料金（1,000 text unitsあたり） |
|---|---|
| コンテンツフィルタ | $0.07 |
| プロンプト攻撃 | $0.08 |
| 機微情報（PII） | $0.10 |
ポイントは、標準のガードレール（コンテンツフィルタは $0.15）より安く設定されていることです。とくにプロンプト攻撃を独立したチェックとして安価に回せるため、各ステップで細かく呼ぶエージェント用途と相性がよい料金設計だと言えます。ただし、各ステップで呼ぶということは、呼び出し回数 × text units でコストが積み上がるということでもあります。「どのステップに、どのチェックをかけるか」を設計し、必要なところだけに絞るのが現実的です。月額がいくらになるかは呼び出し設計次第なので、ここで具体的な金額は断定しません。料金は改定され得るため、必ず公式の最新の料金ページでご確認ください。
対応ポリシーの線引きと、業務で使えるか
最後に採用判断です。前述のとおり、新APIが対応するのはコンテンツフィルタ・プロンプト攻撃・PII の3種です。禁止トピックの制御や根拠に基づく出力の確認（contextual grounding）、語句フィルタが必要なら、従来の ApplyGuardrail やインラインのガードレールを併用する、という選び方になります。新APIは「各ステップを軽量に検知する」ための追加であって、従来のリソースベースを置き換えるものではない、と捉えるのが正確です。
提供状況も整理します。東京（ap-northeast-1）を含む複数のリージョンで提供され、日本でも利用できます。発表は「available today」という表現で、「generally available」という明示の語は確認できていないため、「2026年6月16日に提供開始」という事実として捉えておくのが安全です。クォータ（呼び出しの上限）は公式に明示されていないため、Bedrock 一般の割り当てに従う前提で考えてください。また、Converse 非対応のモデル（Grok など）でも、テキストを渡して評価する仕組み上は前後に挟んで使えると読めますが、公式に明言されているわけではないので、利用前に公式でご確認ください。
まとめ
ポイントを3つに絞ります。
- 新API
InvokeGuardrailChecksは、リソースを作らず（リソースレス）・detect-only でエージェントの各ステップを軽量に検知できます。本番運用基盤のエージェントにも、Strands Agents や自前のループにも組み込めます。 - 3形態の使い分けが肝心です。恒久ポリシーで自動遮断するなら
ApplyGuardrail、各ステップを軽量に検知するなら新API、という軸で選びます。 - 遮断はアプリ側で実装する多層防御であり、対応は3ポリシー、料金は各ステップの設計次第です。対応ポリシーの線引きや料金は、公式の最新情報をご確認ください。
生成AIエージェントを実装・本番化していく流れの中で、安全策とガバナンスをどう設計するかは、受託の現場でも評価されやすいテーマだと感じています。本メディアではエージェントの本番運用基盤として Amazon Bedrock AgentCore を扱っているほか、Grok 4.3 on Bedrock のように Converse 非対応のモデルへ ApplyGuardrail で安全策を当てる方法や、AWS Blocks の Agent ブロックのようなエージェント機能についても取り上げていますので、あわせて設計の引き出しにしてみてください。