# Guardrailsとは — 指示ではなく強制で止める防御層

> Guardrailsの定義、Instructionとの違い、内容を検査する分類器と実行を止めるPolicy Hookの二系統、発動の監査と評価までの運用を整理します。

Canonical URL: https://labs.eastbraver.com/guides/guardrails
Published: 2026-07-14
Updated: 2026-07-24
Category: field-guide
Tags: safety, ai-agent, governance

Guardrailsは、LLMアプリケーションの入力・出力・実行を、モデルへの指示ではなく機械的な検査と制御で守る防御層です。

このサイトのGuideは繰り返し「Instructionは強制力ではない」と書いてきました。ではどこに強制力を置くのか。その答えがGuardrailsです。

このGuideは、2026年7月14日時点の一次情報を基準にしています。Providerの提供機能は追加が続いているため、採用時には利用する基盤の最新ドキュメントを確認してください。

## Guardrailsは二系統に分けると設計しやすい

一口にGuardrailsと呼ばれるものには、性質の違う二つの系統があります。この分け方はこのサイトの整理です。

| 系統 | 判定の性質 | 例 |
| --- | --- | --- |
| 内容を検査する層 | 確率的 (分類器) | 有害コンテンツ検出、PII検出、Prompt Attack検出 |
| 実行を止める層 | 決定的 (Policy) | Tool権限、実行前Hook、承認、Network制限 |

### 入出力とTool実行を守るGuardrails

GuardrailsはLLMの前後だけでなくTool callの実行境界にも必要です。入力検査、出力検査、Policy hookを組み合わせることで、不許可の処理をToolへ到達させない構成になります。

- Input guardrailsがUser Inputを検査してからLLMへ渡します。
- Output guardrailsがLLM出力を検査してResponseを返します。
- Tool callはPolicy hookで許可または拒否され、許可時だけToolへ進みます。

*InputからResponseとToolへ分岐する多層防御*

## 内容を検査する層は、確率的な分類器

[Amazon Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html)は、有害コンテンツやPrompt Attackを検出するContent filters、Denied topics、Word filters、PIIをブロック・マスクするSensitive information filters、RAGの回答が根拠から逸脱していないかを見るContextual grounding checksなどを、入力と出力の両方へ適用できます。`ApplyGuardrail` APIを使えば、モデル呼び出しと独立に検査だけを実行することもできます。

[OpenAIのModeration](https://developers.openai.com/api/docs/guides/moderation)も、テキストと画像を複数の有害カテゴリへ分類するAPIを無料で提供しています。

この層の本質は分類器です。未知の表現も拾える代わりに、誤検知と見逃しが必ずあります。確率的な層だという前提で、閾値・カテゴリ・誤検知時の扱いを決めます。

## 実行を止める層は、決定的なPolicy

もう一つの系統は、モデルの出力内容ではなく、実行そのものを決定的に制御します。

[Claude Codeのhooks](https://code.claude.com/docs/en/hooks)はその具体例です。PreToolUseなどのライフサイクルイベントへ利用者定義のコマンドを差し込み、`permissionDecision: "deny"`を返すことで、Tool呼び出しを実行前に確実に拒否できます。危険なコマンドパターンをshellスクリプトで照合して拒否するdeny-guardは、この仕組みの典型的な使い方です。

この層に入るものは他にもあります。

- [Tool](/guides/tool)ごとの権限と[IdentityとAuthorizationの分離](/guides/ai-identity-authorization)
- 取り消せない操作の[実行前承認](/guides/human-in-the-loop)
- 実行環境側のfile・Network制限

決定的な層は、定義した条件を確実に止めます。代わりに、列挙していないものは素通りします。分類器と逆の性質です。

## 二系統を重ねて、発動を観測する

どちらか一方では足りません。[プロンプトインジェクション](/guides/prompt-injection)で整理した多層防御と同じで、既知の危険は決定的な層で確実に止め、未知の表現は分類器で確率を下げる。両方を重ねた上で、通ったときの影響を小さくします。

運用側の設計も防御の一部です。

- Guardrailの発動を[Trace](/guides/observability-tracing)へ残し、何がどの層で止まったか追えるようにする
- ブロック時に利用者へ何を伝えるか決める (無言の失敗にしない)
- 誤検知率を監視する (正当な入力を止め続けると、利用者が回避策を探し始める)
- Guardrail自体をVersion管理し、攻撃ケースと正常系の両方で[評価](/guides/ai-agent-evaluation)する

## よくある誤解

### 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は、機能しているのか使われていないのか区別できません。

強制力の無い防御を防御と数えない。ここを守るだけで、構成はだいぶ整理されると思います。

## 関連記事

- [AI Agent 時代に、エンジニアは何を設計する人になるのか](/blog/ai-development-20260706)
- [エージェント基盤は非同期運用へ](/digest/ai-digest-20260708)
- [モデル選定とエージェント運用が接続](/digest/ai-digest-20260714)

## 検証範囲

- 一次情報: 公式ドキュメント / 設計面からの分析
- ローカル検証: コードは動かしていません
- 実運用: 本番運用の実績については、このGuideでは触れていません

## 変更履歴

- 2026-07-24: Mermaid図にテキスト等価物を追加
- 2026-07-15: 検証範囲と根拠区分を明示
- 2026-07-14: 初版公開