クラウドキャリアフリーランス
技術記事 2026/7/12

『Guardrailsを入れた＝安全』ではない — 生成AIエージェントを脅威モデルから6層で守る設計

Bedrock Guardrailsは強力ですが、それ単独では生成AIエージェントを守り切れません。攻撃面（OWASP LLM Top10 2025）から6層のdefense-in-depthを設計し、AWS公式3原則（多層防御／認可はモデルと独立／ツール最小権限＋HITL）を実装に落とす考え方を整理します。攻撃手法は扱わず防御設計に閉じます。情報は2026年6月時点、tier・東京対応は公式でご確認ください。

  • #生成AI
  • #エージェント
  • #セキュリティ
  • #プロンプトインジェクション
  • #OWASP LLM Top10
  • #Bedrock Guardrails
  • #最小権限
  • #HITL
  • #defense-in-depth

生成AIエージェントがツールを呼び、外部のデータを読み込む瞬間に、プロンプトインジェクションと過剰権限という現実のリスクが立ち上がります。ここで「Bedrock Guardrails を入れたから安全」と考えてしまうと、守りに穴が残ります。AWS公式自身が、Guardrails は強力な予防統制だが単独ではなく層状の統制で強化すべきだと示しています。本記事は、ツール実行やRAG、外部データ取り込みを伴う生成AIエージェントを本番に出す責任を負う実務者に向けて、攻撃面（脅威モデル）から6層の多層防御を設計し、残存リスクを受容・監視に落とす考え方を整理します。なお攻撃手法そのものは扱わず、防御設計に閉じて述べます。サービスの対応カテゴリやtier、リージョン対応は2026年6月時点として、適用前に公式の最新情報をご確認ください。

なぜ脅威モデル起点で考えるのか

エージェントの難しさは、その自律性にあります。エージェントは状況に応じてツールを選び、複数の操作を連鎖させて目的を達成します。つまり、全実行経路を設計時に予測しきれません。予測できない以上、特定の攻撃を一つずつ塞ぐ発想では守り切れず、想定外の挙動が起きてもスコープを限定できる多層の統制が必要になります。

リスクの根っこにあるのが、信頼境界の問題です。LLMは「命令」と「データ」を同じチャネルで処理します。そのため、取り込んだデータの中に命令のような文字列があると、それを新たな指示として解釈してしまう余地が生まれます。これがインジェクションの本質です。だからこそ、どこからが信頼できない入力で、どこで検証し、どこで権限を絞るのかという境界設計が、セキュリティの中心になります。以降では、まず攻撃面を体系的に把握し、6層でどう止めるか、信頼境界をどう設計するか、そして残りのリスクをどう扱うかを順に見ていきます。

何から守るか — エージェントの攻撃面

攻撃面の体系的な見取り図として、OWASP Top 10 for LLM Applications（2025）が観点整理の枠になります。本記事はこれを順位や文言の解説としてではなく、防御を設計するためのチェック観点として参照します。順位や定義は版で変わるため、利用時には最新版をご確認ください。

ツール実行やRAGを持つエージェントでは、次の観点が特に現実化します。

OWASP観点（2025）エージェントでの現れ方効く防御層
LLM01 Prompt Injection入力や取得データ経由で意図しない指示が混入入力検証・取得データのuntrusted扱い
LLM02 Sensitive Information Disclosure機微情報が応答やログに漏れる出力検証・PIIマスク・ログ保護
LLM05 Improper Output Handling検証前の出力が下流（DB/シェル/API）で実行される出力の信頼境界
LLM06 Excessive Agency過大なツール権限・監督不足で意図しない操作モデルと独立した認可・最小権限・HITL
LLM08 Vector and Embedding WeaknessesRAGの埋め込み・取得経由の間接的な汚染取得元の権限分離・grounding

ここで扱うのは「どの観点をどの層で潰すか」であって、攻撃の手順ではありません。攻撃面を把握したら、次はそれぞれを防御の層に割り当てます。

どの層で止めるか — 6層の多層防御

AWS公式が一貫して示すのは、単一機能ではなく層で守るという姿勢です。エージェントのセキュリティは、入力から監視までの6つの層に分けて設計できます。

攻撃面から入力・取得データ・モデル認可・ツール実行・出力・監視の6層で防御を局所化する多層防御マップの図
図1: 6層 defense-in-depth マップ（攻撃面をどの層で止めるか）

第1層は入力です。Bedrock Guardrails の Content filters に含まれる Prompt Attack 検知で、jailbreak やプロンプトインジェクション、プロンプトリークの兆候を入力段階で捉え、instruction hardening（指示の堅牢化）と併用します。ここで設計判断になるのが tier の選択です。プロンプトリーク検知、多言語（extensive language）対応、クロスリージョン推論などは Standard tier の機能で、Classic tier は対応言語が限られリーク検知も持ちません。日本語や多言語で運用するなら実質的に Standard tier が前提となり、その tier 対応リージョンには東京が含まれます（対応範囲は公式で確認してください）。

第2層は取得データです。RAGで外部から取り込むデータは、信頼できない入力（untrusted）として扱います。これが間接プロンプトインジェクションへの基本姿勢です。Contextual grounding checks で、応答が取得元に根拠づけられているか、クエリに関連するかを検査し、逸脱をブロックまたはフラグします。

第3層はモデル認可です。後述するとおり、認可はモデルの判断に委ねず独立して強制し、ツールには最小権限を割り当てます。第4層はツール実行で、影響の大きい操作には人間承認（HITL）を挟み、action group の user confirmation やサンドボックスで実行範囲を限定します。第5層は出力で、応答を下流のDBやシェル、他APIに渡す前に信頼境界を置き、PIIのマスクや出力検証を行います。第6層は監視で、監査ログとトレースで異常を検知します。各ステップを個別に評価したい場合は、InvokeGuardrailChecks（GA 2026-06、東京対応）を detect-only でエージェントループの各ステップに当て、severity や confidence を数値で受け取ってカスタム閾値で判定できます。なお、Guardrails でブロックされた内容は、ログが有効な場合に Model Invocation Logs へ平文で記録されます。これは監査の材料として有用な一方で、機微なデータがログ側に残るということでもあり、ログそのものへのアクセス制御や保護も設計対象に含めます。

信頼境界を設計する — 認可はモデルと独立・ツールは最小権限・HITL

6層のうち、設計の要になるのが信頼境界です。AWS公式の3原則、すなわち多層防御、認可はモデルと独立、ツール最小権限と人間承認は、この境界設計に集約されます。

ユーザー入力から入力検証、モデル、独立認可ゲート、ツール実行、出力検証、下流へと流れ、RAG取得データをuntrustedとしてモデル手前で合流させる信頼境界フローの図
図2: エージェントの信頼境界フロー（認可はモデルと独立・出力は境界で検証）

最も重要な原則が、認可をモデルと独立に強制することです。どのツールをどの権限で実行できるかの判断を、モデルの出力に委ねてはいけません。モデルが「この操作をしてよい」と判断したかどうかとは別に、認可ゲートで権限を確かめます。モデルはインジェクションで誘導されうるため、権限の最終判断をモデルの外側に置くことが、被害の連鎖を断つ前提になります。

次に、ツールは最小権限で与えます。これはIAMの最小権限原則をエージェントのツールに適用する話で、OWASP の Excessive Agency の核でもあります。広いツール権限と監督不足が重なると、意図しない操作、開発者が想定しないツールの連鎖、低権限ツールの組み合わせによる権限昇格が起こりえます。各ツールには必要十分な権限だけを割り当て、影響の大きい操作には人間承認（HITL）を挟みます。

そして、取得データはuntrusted、出力は信頼境界で検証します。RAGで合流する外部データはモデルの手前で信頼できない入力として扱い、間接インジェクションの影響をその範囲に局所化します。モデルの出力は、下流に渡る前に検証の関門を通し、検証前の文字列がそのままDBやシェル、APIに流れ込まないようにします。

層主なAWSの道具対応するOWASP観点
入力Guardrails Content filters（Prompt Attack）・tier選択LLM01
取得データContextual grounding checksLLM01・LLM08
モデル認可独立した認可・IAM最小権限LLM06
ツール実行user confirmation（HITL）・サンドボックスLLM06
出力Sensitive information filters・出力検証LLM02・LLM05
監視Model Invocation Logs・トレース・InvokeGuardrailChecks横断

残存リスクを受容し、監視でカバーする

層を重ねても、完全な防御は存在しません。重要なのは、何を残存リスクとして受容し、何を監視で補うかを設計として明示することです。

ここで陥りやすいのが過剰防御です。フィルタの強度を最大にし、確証のない入力をすべて遮断すると、正当な利用まで弾いてUXを損ないます。Guardrails のカテゴリ別の強度設定や、InvokeGuardrailChecks の detect-only による段階導入を使えば、まず検知だけを回して誤検知の傾向を把握し、影響を見ながらブロックへ移行できます。防御の強さは、守る対象の重要度と利用体験のバランスで決めます。

加えて、安全性は一度設計して終わりではありません。プロンプトインジェクションやjailbreakに対する耐性も、評価（eval）で継続的に検証する対象です。代表的な攻撃パターンに対する回帰テストをリリースゲートに組み込めば、変更のたびに防御が崩れていないかを確かめられます。検知ログやトレースは、セキュリティ監査と本番運用の可観測性の両面で活きます。安全性の継続検証はエージェントの評価設計の領域、監査ログやトレースの運用はエージェント本番運用の領域と、それぞれの専門記事に接続して深めるのが実務的です。

まとめ

生成AIエージェントのセキュリティは、Guardrails を入れて終わりではなく、攻撃面の把握から6層の防御、残存リスクの受容と監視までを通した設計判断です。要点は3つです。第一に、Guardrails は強力な一要素であって、多層防御の前提に置きます。第二に、AWS公式の3原則、多層防御・認可はモデルと独立・ツール最小権限とHITLを、信頼境界の設計言語に翻訳します。第三に、取得データはuntrusted、出力は下流の信頼境界で検証し、完全防御を前提とせず残存リスクを監視とevalで管理します。攻撃面（OWASP LLM Top10）を観点の枠に使い、どの層で止めるかを一つずつ設計していくことが、エージェントを本番で安全に動かす近道です。

出典

For Freelancers

AWSフリーランス案件、お探しですか？

案件探しから単価交渉・契約手続き・参画後のフォローまで、専任コンサルタントが伴走します。 お名前とメールだけで、まずは無料でご相談いただけます。

案件を探す