Guardrailsは、LLMアプリケーションの入力・出力・実行を、モデルへの指示ではなく機械的な検査と制御で守る防御層です。
このサイトのGuideは繰り返し「Instructionは強制力ではない」と書いてきました。ではどこに強制力を置くのか。その答えがGuardrailsです。
このGuideは、2026年7月14日時点の一次情報を基準にしています。Providerの提供機能は追加が続いているため、採用時には利用する基盤の最新ドキュメントを確認してください。
Guardrailsは二系統に分けると設計しやすい
一口にGuardrailsと呼ばれるものには、性質の違う二つの系統があります。この分け方はこのサイトの整理です。
| 系統 | 判定の性質 | 例 |
|---|---|---|
| 内容を検査する層 | 確率的 (分類器) | 有害コンテンツ検出、PII検出、Prompt Attack検出 |
| 実行を止める層 | 決定的 (Policy) | Tool権限、実行前Hook、承認、Network制限 |
GuardrailsはLLMの前後だけでなくTool callの実行境界にも必要です。入力検査、出力検査、Policy hookを組み合わせることで、不許可の処理をToolへ到達させない構成になります。
- Input guardrailsがUser Inputを検査してからLLMへ渡します。
- Output guardrailsがLLM出力を検査してResponseを返します。
- Tool callはPolicy hookで許可または拒否され、許可時だけToolへ進みます。
内容を検査する層は、確率的な分類器
Amazon Bedrock Guardrailsは、有害コンテンツやPrompt Attackを検出するContent filters、Denied topics、Word filters、PIIをブロック・マスクするSensitive information filters、RAGの回答が根拠から逸脱していないかを見るContextual grounding checksなどを、入力と出力の両方へ適用できます。ApplyGuardrail APIを使えば、モデル呼び出しと独立に検査だけを実行することもできます。
OpenAIのModerationも、テキストと画像を複数の有害カテゴリへ分類するAPIを無料で提供しています。
この層の本質は分類器です。未知の表現も拾える代わりに、誤検知と見逃しが必ずあります。確率的な層だという前提で、閾値・カテゴリ・誤検知時の扱いを決めます。
実行を止める層は、決定的なPolicy
もう一つの系統は、モデルの出力内容ではなく、実行そのものを決定的に制御します。
Claude Codeのhooksはその具体例です。PreToolUseなどのライフサイクルイベントへ利用者定義のコマンドを差し込み、permissionDecision: "deny"を返すことで、Tool呼び出しを実行前に確実に拒否できます。危険なコマンドパターンをshellスクリプトで照合して拒否するdeny-guardは、この仕組みの典型的な使い方です。
この層に入るものは他にもあります。
- Toolごとの権限とIdentityとAuthorizationの分離
- 取り消せない操作の実行前承認
- 実行環境側のfile・Network制限
決定的な層は、定義した条件を確実に止めます。代わりに、列挙していないものは素通りします。分類器と逆の性質です。
二系統を重ねて、発動を観測する
どちらか一方では足りません。プロンプトインジェクションで整理した多層防御と同じで、既知の危険は決定的な層で確実に止め、未知の表現は分類器で確率を下げる。両方を重ねた上で、通ったときの影響を小さくします。
運用側の設計も防御の一部です。
- Guardrailの発動をTraceへ残し、何がどの層で止まったか追えるようにする
- ブロック時に利用者へ何を伝えるか決める (無言の失敗にしない)
- 誤検知率を監視する (正当な入力を止め続けると、利用者が回避策を探し始める)
- Guardrail自体をVersion管理し、攻撃ケースと正常系の両方で評価する
よくある誤解
System Promptに禁止事項を書けばGuardrailになる
Instructionはモデルの判断材料で、防御層ではありません。Guardrailsは、モデルが従わなくても効く場所に置きます。
Guardrailsを入れればPrompt Injectionは解決する
分類器はPrompt Attackの成功率を下げる一層です。権限・承認・出力の取り扱いと重ねて、通ったときの影響を絞ります。
Deny listを増やせば安全になる
列挙型の防御は、列挙外の表現に回避されます。決定的な層は既知の危険を確実に止める役割と割り切り、未知への備えは分類器と権限設計で持ちます。
ブロックできれば仕事は終わり
発動ログの監査と誤検知の評価まで含めて運用です。発動が多すぎるGuardrailは、設計か上流の入力に問題があるSignalでもあります。
EastBraver Labsの判断基準
EastBraver Labsでは、Guardrailsの設計を「止めたい操作を、モデルへ頼まずに止められるか」という問いから始めます。
先に敷くのは決定的な層です。Tool権限、実行前Hook、承認。実運用でも、Agent CLIのPreToolUse hookにshellのdeny-guardを置き、危険なコマンドをパターン照合で実行前に拒否しています。その上へ、内容検査の分類器を必要な範囲で重ねます。
発動は監査対象です。何が・どの層で・なぜ止まったかをTraceへ残し、誤検知は評価セットへ戻します。止まった記録の無いGuardrailは、機能しているのか使われていないのか区別できません。
強制力の無い防御を防御と数えない。ここを守るだけで、構成はだいぶ整理されると思います。